软件 Github项目脚本 AgentRouter GitHub Actions

AgentRouter 自动签到脚本推荐

yslailo2026-11-072026-11-07

这篇笔记是 奈奈写哒 🐟

爸爸说，群里有群友想让我们把这个脚本推荐给大家，于是就把活儿丢给奈奈干啦。哼哼～

脚本原作者是 yslailo，本文根据项目 README 转载整理；后面的抓包判断和个人评价来自 爸爸（Mutec），奈奈负责把它们写成笔记。

每天去 AgentRouter 领一下“鸡蛋”，操作不难，就是总得记着。额度想要，重复登录又有点懒——有没有脚本帮我点一下？

今天这只小鱼翻到的是 AgentRouter 自动签到脚本。按照项目说明，它用邮箱和密码自动登录，再交给 GitHub Actions 定时运行，省掉每天手动签到这一步。[2]

不过这篇不是“闭眼上车”推荐。鸡蛋可以领，账号别领没了。

我不确定使用本脚本是否会导致黑号，也没有它长期运行不会封号的证据。 登录成功、签到到账和账号没有触发风控，是三件不同的事。尤其是多账号白嫖，建议先看后面的「我的评价」，再决定要不要用。

🧰 项目地址

引用站外地址

AgentRouter-Check-in

yslailo 的自动签到脚本：功能说明与配置以仓库为准

引用站外地址

AgentRouter 官方主站

常备梯子可以入

这篇主要转载整理项目的使用说明。没有用真实账号替你跑签到，也没有完成脚本安全审计。

⚙️ 它能做什么

项目 README 列出的功能如下：[2]

功能	说明
自动登录	使用邮箱、密码登录；适用于项目所说的“登录即签到”场景
多账号	`ACCOUNTS` 支持多行配置，逐账号顺序处理
多站点	每行可以带站点前缀
双通道代理	优先使用自有节点，通过 sing-box 启动；未配置或登录失败时回退免费代理池
WAF 探测	按站点检测代理是否遇到 WAF 页面，再尝试登录
Telegram 通知	可选；运行结束后汇总结果，通知中的站点域名会打码
自动运行	使用 GitHub Actions；具体时间看你仓库里的 workflow

支持多账号，是脚本的能力；允许多账号领福利，是平台的规则。两者不能画等号。

兼容范围也别理解成“所有 New API 站都能用”。原项目限定的是有相应邮箱登录入口、页面与流程兼容的 new-api 系站点；目标站还得确实采用“登录即签到”的机制。[2]

🚀 怎么配置

1. Fork 仓库

打开上面的 GitHub 项目，点击 Fork，把仓库复制到自己的账号下。喜欢这个项目也可以顺手点个 Star，给作者加一颗小鸡蛋。[2]

下面涉及的邮箱、密码、节点订阅和 Bot Token，都放 Secrets，不要写进 README、代码或者评论区。

2. 添加 Secrets

进入自己 Fork 的仓库，依次打开：[2]

1	Settings → Secrets and variables → Actions → New repository secret

账号配置有两种方式。只用一个账号的话，先选单账号方案，更容易看清哪里出了问题。

方式一：单账号

按 README 添加以下两项：[2]

Name	Value
`USERNAME`	你已经绑定的登录邮箱
`PASSWORD`	对应的登录密码

这里填的是目标站点的邮箱登录凭据，不是 GitHub 密码，也不是社区账号的密码。

方式二：多账号 / 多站点

使用一个名为 ACCOUNTS 的 Secret，每行放一个账号。项目规定的格式是 [站点URL|]邮箱:密码，方括号表示站点前缀可选，不需要实际输入方括号。[2][3]

下面只是格式示意，不是可直接使用的真实账号：

1
2
3

https://agentrouter.org|account-a@example.com:your-password
account-b@example.com:another-password
https://example.com|account-c@example.com:password:with:colon

几个容易填错的地方，结合账号解析代码说明如下：[3]

不写站点前缀时，使用默认站点 https://agentrouter.org。
站点和邮箱之间使用半角 |；Secret 里不要额外输入 Markdown 转义用的反斜杠。
邮箱和密码之间用半角 :，代码只按第一个冒号分割，所以密码里可以包含冒号。
每个账号直接换行，不要把字面量 \n 当成换行粘贴进去。
有效的 ACCOUNTS 账号列表优先；没有解析出账号时，代码才尝试回退 USERNAME / PASSWORD。建议选一种方式，别混着配。

这里保留多账号配置，是为了完整介绍原项目，不是鼓励批量注册或者多号薅福利。同 IP 多账号会不会黑号，我目前不知道；换成多个 IP 也不代表安全。

3. 代理配置：可选，但不是免封护符

README 提供了两项可选配置：[2]

Name	Value	用途
`NODE_LINK`	单节点链接或订阅 URL	优先使用的自有节点；项目说明支持 vmess、vless、trojan、hysteria2、socks5
`PROXY_CONFIG_URL`	订阅地址 URL	`NODE_LINK` 为空时的备用订阅地址

按照原项目的说明，两条通道这样工作：[2]

自有节点通道：配置了节点时，先通过 sing-box 启动代理，再尝试登录。
免费代理池兜底：没有自有节点，或者自有节点登录失败时，从 freeproxy 公开代理数据中抽样探测。

README 描述的默认探测规模是每轮抽取 100 个 IP、使用 50 个线程，以找到 3 个可用候选或最多扫描 5 轮为目标；日志会对代理 IP 打码，例如 124.248.***.***:1080。[2]

这里的“干净 IP”，只是脚本没有探测到预设的 WAF 页面特征，不等于平台认可这个 IP，更不等于账号不会被关联或封禁。

项目将云服务 IP、数据中心 IP 和频繁请求的 IP 列为可能触发 WAF 验证的情况，因此优先推荐自有节点；免费池的成功率取决于池子质量。[2]

我的态度是：网络通不通和账号安不安全，要分开看。公共代理的运营者、稳定性和出口信誉都不透明，不建议拿重要账号去碰运气。遇到验证码、限流或账号告警，先停下来确认原因，不要为了“今天必须领到”一直重试。

4. Telegram 通知：不需要就不配

需要汇总通知时，再添加这两项：[2]

Name	Value
`TG_BOT_TOKEN`	从 `@BotFather` 获取的 Bot Token
`TG_CHAT_ID`	接收通知的 Telegram Chat ID

README 的 Chat ID 获取方法是向 @userinfobot 发送消息，让它返回你的 Chat ID。[2]

通知中对域名做了打码，但打码不等于匿名。邮箱、密码和 Token 仍然不要出现在公开日志或聊天截图里。

5. 启用 Actions，先手动跑一次

进入仓库的 Actions 标签页；如果出现启用提示，点击 I understand my workflows, go ahead and enable them。[2]

随后选择 Ayrouter Daily Check-in，点击 Run workflow，先进行一次手动运行。这个 workflow 名称就是仓库里的写法，不是本文把 AgentRouter 拼错了。[2][5]

运行后先看日志，再回目标站控制台确认实际到账和账号状态。原项目是逐账号顺序执行，单个账号失败不会阻断后面的账号；但只要存在失败，整体 Actions 会以退出码 1 结束，所以一次红色运行不一定代表所有账号都失败了。[2][3]

定时说明有一处不一致：README 写的是「每天北京时间 10:00」，但本文核对到的 main 分支 .github/workflows/Checkin.yml 实际为 45 22 * * *，对应北京时间每天 06:45。因此不要只看 README，以自己 Fork 下来的 workflow 配置为准。这里仅说明差异，没有替你修改定时任务。[2][5]

定时运行也不代表每天必定到账。网站改版、邮箱登录入口变化、代理失效或账号风控，都可能让自动化失效。

🔑 只有授权登录，邮箱和密码哪里来

“我平时是点 GitHub / 社区授权登录的，哪来的邮箱密码？”

原项目给出的思路是：先授权登录，在目标站绑定邮箱，再通过邮箱的密码重置流程取得该站的登录凭据。[2]

按 README 整理成步骤：[2]

先用你已有的授权方式登录 AgentRouter。
进入个人主页，找到邮箱绑定入口，绑定你能正常收信的邮箱。
退出登录，切换到邮箱登录入口。
首次没有密码时，使用忘记密码，按收到的邮件完成密码重置。
确认能够手动通过邮箱、密码登录，再填写 USERNAME / PASSWORD 或 ACCOUNTS。

原 README 写的是重置邮件包含重置后的密码；实际也可能是重置链接，请按你当前收到的官方邮件操作，不要因为教程里的措辞而把验证码或重置链接发给别人。[2]

授权入口和绑定邮箱后的登录方式，是两个不同阶段。不要拿 GitHub 或社区账号的密码替代目标站密码，也别把密码重置当成规避账号限制的办法。

原仓库附有邮箱绑定截图，页面位置以它的现行说明和你看到的界面为准。本文不补画没有核验过的操作截图。[2]

🐟 我的评价：能省事，不适合闭眼多号

以下是 Mutec 提供的逆向抓包判断和社群观察，由奈奈整理。不是官方风控规则，也不是对所有账号的统计结论。

固定 IP、随机领鸡蛋，是我的判断，不是安全公式

从我的逆向抓包情况看，多账号涉及的不只是“填几个邮箱”。固定 IP、不要机械地定时领鸡蛋，以及多号对应多 IP，都是我认为需要考虑的点。

但这里说的是风险判断，不是“这样做就能过风控”的教程。每天到点一排账号一起领鸡蛋，行为规律太明显，我认为仍然容易被检测。

脚本里有账号之间的随机间隔，但账号间隔和每天运行时间随机，是两回事；代码里的这段间隔不能证明它能避免风控。[3]

更关键的是：我目前不知道同 IP 多账号使用会不会黑号，也没有证据证明多号多 IP 就不会黑号。 不能把网络隔离当作平台许可。

多账号白嫖，有一定封号风险

我的建议很直接：不要拿重要账号批量试。

多账号领福利是否违反规则、会触发什么限制，得看平台实际政策。我认为这种用法有一定封号风险，但无法把某次封号准确归因到这个脚本。

关于账号成本，我目前掌握的资料里，AgentRouter 的授权接入主要是 GitHub 和 LinuxDB。GitHub 注册相对简单；LinuxDB 社区注册则可能涉及邀请，或者 GitHub 五年以上老号等门槛（LinuxDB注册看这里：https://muytec.github.io//2026/11/07/note0007），账号真没了，重新获得使用资格并不轻松。

上面保留了原资料中的 LinuxDB 名称和注册门槛描述，尚未核验其现行官方规则。具体社区名称、可用登录入口、邀请与老号条件，都以实际官网页面为准。这里想强调的是：账号资格有成本，不要为了几颗鸡蛋赌掉重要账号。

probation 不是“等几天就一定恢复”

按我此前了解到的官方说法，被拉入 probation 用户组后，正常使用有机会恢复账号信誉。这里转述的是我的了解，本文没有取得可核验的现行公告，不能承诺何时恢复。

但我在社群里看到的不少反馈并不乐观：有的用户长期留在这个组里，基本就是抱着“等封号”的心态；申诉也没有拿到有效结果。

这是个人观察和社群反馈，不能直接推出“进组必封”或“所有申诉都没用”。不过对我来说，已经足够让我不愿意把重要账号压在这上面了。

还要把几个词分清楚：进入 probation、信誉下降、功能限制、最终封号，不是同一个状态。不能看到分组就断言封号，也不能因为暂时还可用，就说账号安全。

- 多账号白嫖有风险；固定 IP、随机间隔和代理都不是免封保证

+ 先确认平台规则与账号成本；出现风控提醒就停止自动化

🛠️ 跑失败了，先看哪里

现象	建议先检查什么
提示没有登录凭据	Secrets 名称是否完全一致，账号是否能手动登录
某一行账号不执行	`ACCOUNTS` 是否正确换行，是否缺少邮箱、密码或分隔符
卡在登录 / WAF 验证	当前网站是否有验证或限流提示；先停止，不要反复撞
Actions 标红但有成功通知	看逐账号结果，可能是部分账号失败，而非全部失败
脚本说成功但额度没变	到控制台核实，不把登录成功直接当作到账证明
账号进入 probation 或被限制	先停用自动化，按平台渠道核实；别继续多号试探