大多数人用 Claude Code 或 Codex 的方式，是坐在终端前面盯着它跑。你敲一句话，看它执行，等它问你下一步。窗口一关、人一走，这件事就断了。
Agent Autoloop 押的是另一个前提：终端不该是需要人守着的地方。它把这套东西拆成一个后台小服务，任务从定时、GitHub Issue、业务系统告警进来，自动派给你本机已经装好的命令行 Agent；Agent 干完一轮就退出，碰到要删数据、要停服务、要花钱这类事才给你推一张卡片，等你点完再接着干。
这个仓库 11 月 3 日才建，两天涨到 2878 Star。我在一台 Linux 沙箱里把它 clone 下来跑了自带的核心测试和模拟，也顺手核了几个 README 没写的东西。
它到底是个什么东西
一句话：一个任务调度中台，不是一个 Agent。它自己不会思考，也不调用任何模型。
拆开是四层。内核负责「什么事该派给谁」；外壳负责 Node 的 HTTP、SQLite、时钟这些落地的事；协议层定义 JSON 格式和校验规则；接单程序负责真正把 Agent 拉起来、盯着它跑、把最后一条回复交回去。
Agent 和中台之间只有一个约定：在最后一条回复里交代结果。办完了输出一句结论；要请示就在回复末尾贴一段带 agent-autoloop 标记的代码块，里面写你想问什么、有哪几个选项。这个约定有个好处——任何能打印最后一条消息的命令行工具都能接，不需要接入任何开发工具包，也不需要改 Agent 源码。
它把四套成熟的计算机工程做法搬了过来，这也是我认为它值得写的真正原因：
| 机制 | 一句话人话 | 借用自 |
|---|---|---|
| 挂起零消耗 | 等你拍板时进程直接退出，等待状态存在数据库里；你三天不回，这三天就没 Agent 在跑、不烧 Token | 消息队列里延后执行的任务 |
| 事件溯源 | 所有状态从一条只追加的日志算出来，日志和索引在同一个事务里落盘，写完才应答；进程被强杀，已确认的事不丢 | 记账式数据库 |
| 指令数据分离 | Issue 标题、正文这些外部文字只当资料放进文件，不拼进提示词；派给谁、在哪个目录、什么权限只由你本机的规则决定 | SQL 参数化查询 |
| 跳数熔断 | Agent 交回的事件会再派给 Agent，层数累加，超过 8 层只记录不派活，同时弹一张卡片告诉你 | 网络包能转发的跳数上限 |
第三条是这份代码里最值钱的判断。市面上那些把多个 Agent 串起来干活的工具，绝大多数把外部内容直接拼进提示词，然后指望模型自觉。这个项目反过来做：别人写的话进不了指令位，最坏的结果被限制在你规则给定的范围里。它自己在文档里也写得很老实——「这挡不住所有提示注入，但把最坏的结果限制在规则给定的范围里」。
实测：核心断言全过，README 那张表过期了
先说跑通的部分。
在沙箱里跑它的内核相关测试——架构纯净度、跳数熔断、协议校验、状态投影、内核行为五个文件，40 个断言全过，零失败零跳过。其中 purity.test.ts 这个文件我个人最喜欢，它用测试守架构：检查内核代码里不能出现任何厂商名字（Claude、OpenAI、飞书、GitHub 都不许出现）、不能发起任何网络请求、不能有运行时依赖、不能有界面、时间和随机数必须从外壳进。写了这条测试，架构约束就不再是文档里的一句口号。
再跑它自带的 20 万步随机模拟。这个模拟往系统里注入六类故障——丢包、重复提交、进程重启、离线、通道失败、时钟跳变，每类各注入约 16700 次，最后完成 16510 轮任务，1436 步每秒，全程断言不崩。同一种子能复现同一个结果。
然后是仓库的体量，这些是我自己数的：
| 项 | 我数出来的 | README 里写的 |
|---|---|---|
| 内核代码 | 12 个文件，1772 行 | “约 1800 行” ✓ / 性能表里”1651 行” ✗ |
| 运行时依赖 | 0（dependencies 是空对象） |
0 ✓ |
| TypeScript 代码 | 152 个文件，20524 行 | 未写 |
| 测试代码 | 68 个测试文件，444 个用例，11475 行 | 未写 |
| 场景模板 | 7 套，每套 3-5 个文件 | 7 套 ✓ |
| 开源许可 | MIT | MIT ✓ |
内核 1772 行，而围着它写的测试有 11475 行——测试代码是内核的 6.5 倍。这个比例说明作者把力气花在了「怎么证明它对」而不是「怎么多写功能」上，对一个才两天大的仓库来说，这是很少见的取舍。
唯一的出入是那 121 行。README 的性能表里写「内核行数（含空行和注释）1651」，同页正文写「约 1800 行」——正文对得上，表格没跟着更新。这不影响任何结论，但它恰好暴露了一个常见的小毛病：性能表这种东西，一行数据过期之后没人会回头重跑。数字一旦写进 README，就该有人定期复核，否则它只是在借当初的可信度。
还有三件 README 里没写、或者写了但要自己核的事：
第一，npm 上那个同名的包不是它的。agent-autoloop 这个包名在 npm 上被一个叫 iasiv5 的作者占着，版本 0.0.1，解压出来只有一个 index.js，内容是一行 module.exports，README 自己写着「占位包，用于保留包名」。也就是说 npx agent-autoloop 拿到的是一个空壳。这个项目只走 install.sh 从 GitHub clone，本来也没打算上 npm，但包名被占这件事迟早要处理。
第二，Windows 还不能用，而且这是个挂了两天、13 条评论的高频追问。README 里的说法很实在：作者人在外面出差，手边没有 Windows 机器，做不了真机测试，承诺周末回家后补上。
第三，它对 Node 版本的要求比我实测的严。安装脚本硬性校验 Node 主版本 ≥ 24，我这台机器是 22.23.3，直接装是装不上的；但把仓库 clone 出来手跑核心测试，40 个断言照样全过。这说明代码本身没用到 24 才有的东西，卡在安装脚本这一层。
最后必须说清一个我没跑完的部分：它的全量测试套件我在这台机器上跑不了。第一次报进程数上限（系统回了一个「资源暂不可用」的错误），把限额提到 2048 之后仍然超时。这大概率是我这台沙箱的限制而不是项目的问题——它的持续集成检查在 Ubuntu 和 macOS 上每天跑、263 次运行里最近几次都是绿的。但「我没跑完」和「它挂了」是两件事，我只能如实写前者。
普通人能拿它赚什么
这个项目离钱的距离是改造档：不是明天拿起来就能接单，但拼一拼能卖出活。
最常见的接法是给本地小商家做「网站巡检 + 告警」。它的场景模板里已经有一份现成的：每 5 分钟检查一次网站的状态和关键内容，第一次异常交给 Agent 排查，持续异常不重复打扰，恢复后更新原卡片。你要做的是把商家域名填进去、把飞书或企业微信的群接上，然后交付一个「网站挂了会自动在群里报，还会告诉你大概哪儿出了问题」的服务。这类活单独一家店一个月 300 到 800 元，按年收更稳，一个客户一年三五千；手上攒到五六个稳定客户，就是一笔能覆盖服务器和订阅费的被动收入。
第二个方向是给小团队做「Issue 自动跟进」。模板也有：每 5 分钟查新 Issue，在本机改代码、跑测试，然后通知人来看，但不提交、不推送、不回复 Issue。这个更适合接给独立开发者或者三五个人的小团队，按月收运维支持费，一单 800 到 2000 元一个月，具体看要接几个仓库。
第三个方向偏自己用：你手上如果同时跑好几个副业项目，把它当「项目管家」，每天早报、每周代码清理这些活让它在后台跑，省下的是你自己每天翻一遍仓库的那一小时。
但边界得说在前头。这几个数字的前提是你自己会配 Node 环境和 JSON 配置——它的配置全是 rules.json，没有图形界面，出错了要看得懂日志。它还要一台常年开着的机器（家里的小主机或一台便宜的云服务器），并且 Agent 的订阅费是你自己出的，跑得越多花得越多。前几单基本靠熟人介绍，第一个月很可能只有一个客户；如果客户那边的网站本来就是外包维护的，你很难插进去。不愿意跟商家来回改配置、看到命令行就头大的，这条路走不通。
和同类比，谁该用
跟「把多个 Agent 串起来的框架」不是一类。LangGraph 那类是把 Agent 的思考流程画成图，给你的是一套写代码的固定套路；这个项目不碰 Agent 怎么想，它管的是「活从哪来、派给谁、干到哪了、什么时候该找你」。两者可以叠着用。
跟「定时任务 + 脚本」也不是一类。cron 跑脚本，出了错只有退出码；它把每一轮的来龙去脉记进日志，一条 why 命令就能查清某一轮为什么跑、结果是什么、花了多少 Token。
适合三类人。一类是手上已经有好几个项目的独立开发者，缺一个不打搅人的管家。一类是给客户做网站运维的个人或小工作室，巡检、告警、跟进这套活可以标准化交付。还有一类是团队里管持续集成与发布流水线的人：它的交付流水线从打标签开始，审代码、等检查通过、合并、等部署、核对线上版本全程自己跟，而且审查和交付配置只从主分支读，绝不在接单的机器上跑 PR 里的代码——这条设计在供应链安全上是对的。
不适合两类人。一类是不会写代码、指望装完就能用的人：它没有界面，所有配置都是 JSON。另一类是只想让 Agent 自动干活、不需要记录和追溯的人：那用一个定时脚本加一个 Agent 就够了，这个中台是给「要长期跑、跑错了得查得出来」的场景准备的。
几个该写在明处的局限。它目前只在 macOS 和 Linux 上验证过，Windows 支持是承诺不是事实。内置的四种 Webhook 模板（钉钉、企微、Slack、Discord）作者自己说只在本地模拟服务上验证过，没连过真实账号。飞书是跑通了发送、按钮回调和卡片更新的，Claude Code 和 Codex 是跑通了多轮问答和跨进程续接的——这两条作者写得很具体，可信度比那句笼统的「已支持」高得多。
判断
两天 2878 Star，这个热度里有多少是「命令行 Agent 自动化」这个方向本身的势能，有多少是这个项目自己的分量，现在还看不出来。但代码本身经得起看。
它做对的那件事很朴素：把一个容易写成一坨胶水脚本的东西，拆成了四个各自可替换的方向（事件、Agent、通道、交付），中间用一个 1772 行、零依赖、不主动发请求的内核连起来。内核小到能被人读完，这是它最大的可信度来源——你不需要相信作者的描述，你可以自己读完那 1772 行。
如果要试，建议先别急着接单。装上跑一遍 agent-autoloop try，走一遍「提问 → 退出等回复 → 拍板 → 接着干完」，确认它真的不占进程、真的能续上会话，再决定要不要往客户那边铺。它的价值不在功能多，在于你终于可以把一批「需要人守着」的活交出去。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：