很多人用 Claude Code、Codex 这类命令行 Agent 时都卡在同一处:人一关终端,活就停了;碰到一个需要拍板的问题,还得守在屏幕前。Agent Autoloop 是一个跑在本机的后台中台,把定时与事件交给已登录的命令行 Agent,遇到拿不准的事才发卡片找你决定,等你回答后再把原来的会话接起来做完。本教程按官方仓库 README 与 v1.8.3 发布说明六步落地:核对前置、安装并验零、跑一次带问答的试跑、写定时与事件两类规则、用预演命令验规则、最后把暂停补跑与追溯收口。整条链路在本机完成,不需要 GitHub 账号,但会产生真实的模型用量。
Node.js 24 或更新、Git、一个已登录的命令行 Agent,macOS 与 Linux 另需 curl;Windows 用 PowerShell。留出约 60 MB 空闲内存给中台本身,模型调用费用由你自己的账号承担。主线不新增 API Key,但 Agent 的登录态等同于账号凭据,别把凭据写进会提交到仓库的规则文件。先弄清:它管的是调度,不是模型能力
官方 README 把定位写得很直白:让命令行 Agent 在后台自己接活、自己跟进到底,平时不烦你,遇到拿不准的事才发卡片找你拍板。它不提供模型、不替你写代码,只负责三件事——按规则把事件派给 Agent、在 Agent 提问时把进程停下来等你、答完后接上原会话继续。仓库按层拆开:kernel/ 做决策与规则匹配、host/ 跑 Node HTTP 与 SQLite、worker/ 负责领活与回执、cli/ 与 bin/ 是你敲的命令、plugins/ 放内置的事件与通道插件。
| 你能写进规则的东西 | 作用 | 官方给出的字段 |
|---|---|---|
| 定时触发 | 按 cron 到点跑一轮 | when: {"cron": "0 9 * * *"} |
| 外部事件触发 | 来源登记后按事件类型派活 | when: {"source": "github", "types": ["issues.opened"]} |
| 交给谁、在哪干 | 指定 Agent 与工作目录 | to、cwd、prompt |
| 附加控制 | 任务技能与并行度 | skill、parallel |
版本口径要先对齐:本教程核对时官方最新 Release 是 v1.8.3(2026-11-13 发布),而 11 月初的第三方实测文章写的是 1.6.3;项目迭代很快,安装器与 agent-autoloop update 都装「通过了全部检查的最新版」。README 正文没有写死版本号,所以别把某个版本号当成命令的前提,以你安装当天 status 与仓库 Release 页为准。
Step 1:审阅安装脚本与本机前置
两条安装命令都是「下载脚本再交给 shell 执行」的管道形式,动手前先打开脚本看清楚它往哪里放文件、改了什么。同时逐项核对前置,缺一项都会在后面变成难排查的假故障。
# 核对运行时(官方要求 Node 24 或更新)
node --version
git --version
# macOS / Linux 另需 curl
curl --version
# 确认你的命令行 Agent 已登录且能出最终回复
# 例如:codex exec "只回复 OK" 或你的 CLI 等价命令
# 这一条只是自检,不写进规则文件
# 在线审阅安装脚本(浏览器打开也可以)
# https://raw.githubusercontent.com/KKKKhazix/agent-autoloop/main/install.sh
# https://raw.githubusercontent.com/KKKKhazix/agent-autoloop/main/install.ps1
# 重点看:安装目录、是否改 PATH、是否注册后台服务
# 准备一个可回滚的练习目录
git status --short
git log -1 --oneline
建议先在练习目录里把整条链路跑通,确认规则确实按预期派活,再迁到日常项目。中台会用你的 Agent 登录态在指定目录里执行动作,练习目录能让你随时看清改动范围。
管道执行属于高风险动作:curl ... | sh 与 irm ... | iex 会把远端脚本直接交给本机执行,脚本内容可能随仓库更新而变。先审阅、再执行;团队机器请先过一遍安全要求。另外,模型调用按你自己的账号计费,别用工作账号直接做无限轮次的试跑。
Step 2:安装并用 status 验零
官方给的两条安装命令按平台二选一。装完立刻跑 status:此时还没配任何规则,轮数、Token 与费用应当都读零,这比看到「安装成功」更有说服力。
# Windows PowerShell
irm https://raw.githubusercontent.com/KKKKhazix/agent-autoloop/main/install.ps1 | iex
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/KKKKhazix/agent-autoloop/main/install.sh | sh
# 安装后确认命令可用,并看初始状态
agent-autoloop status
# 预期:今天与最近 7 天的轮数 / Token / 费用都为 0
# 后续升级同样只取通过全部检查的 Release
agent-autoloop update
status 的统计口径在 v1.8.3 改过:各家 Agent 的输入都算上缓存,并写出缓存占比(例如「1.3 亿 Token,其中缓存 96%」);/v1/state 的 spending 多了 cached 字段。发布说明写明,升级前记下的 Claude 与 DSH 轮次仍是旧口径,一周后会自然对齐——所以升级刚完成时拿新旧数字直接对比并不可靠。Step 3:跑一次带问答的试跑,看它怎么停、怎么续
官方建议装好后用本机的 Agent 真实走一遍「提问 → 退出等回复 → 拍板 → 接着干完」。try 会发出一个事件,Agent 干完一轮后问你选哪个颜色,然后退出等待;这个中间状态是关键——没有 Agent 进程在跑,也不花 Token。
# 发起试跑
agent-autoloop try
# 终端输出大意:事件发出去了,Agent 开始干活……
# Agent 结束了这一轮,问了你一个问题。它现在不占进程、不花 Token。
# 【等你决定】#1 试跑:选一个颜色 1. 蓝色 2. 绿色
# 交互终端:直接输入数字回车
# 非交互终端:用命令回答(示例里的 1 2 选绿色)
agent-autoloop answer 1 2
# 再查状态,看它接上原会话把试跑做完
agent-autoloop status
# 预期:显示「你选了绿色,试跑通过」,以及今天 / 近 7 天的轮数、Token、费用
如果 answer 之后状态没有变化,先核对编号是不是对应当前那条待决定卡片,再看你用的 Agent 是否真的能打印最终回复。这一步验的是「会话能暂停再恢复」,不是模型答得对不对。
Step 4:写 rules.json 的定时与事件两类规则
规则文件在 ~/.agent-autoloop/rules.json,不需要写胶水代码。to 要填 agents 里已登记的名字;cwd 与 prompt 决定 Agent 在哪干活、干什么。保存后几秒内生效,外部的 github 来源要先按说明在 sources 里登记。
# 文件:~/.agent-autoloop/rules.json
{
"rules": [
{
"name": "早报",
"when": { "cron": "0 9 * * *" },
"to": "codex",
"cwd": "~/notes",
"prompt": "整理昨天的笔记和提交,写今天的早报。"
},
{
"name": "处理 issue",
"when": { "source": "github", "types": ["issues.opened"] },
"to": "codex",
"cwd": "~/code/app",
"skill": "handle-issue",
"parallel": 3
}
]
}
# 保存后先校验,不要直接等它自己触发
agent-autoloop check
两段规则分别对应定时与事件。parallel: 3 控制并行度,别一上来就开很大:同一时刻跑起来的都是你账号里的真实调用。规则模板里还带 skill 字段,启用带任务 Skill 的模板时要把它放进所用 Agent 的 skills 目录。
规则写错也不会立刻停摆:官方说明,改错了、文件被删或读不到,系统会继续按旧规则跑并发卡片提醒你。这能防止手滑导致中台空转,但也意味着「我没看到报错」不等于「新规则已生效」,所以每次改完都要用下一步的预演命令验证。另外 v1.8.3 给规则的 elsewhere 登记项加了可选 model 与 effort 字段;发布说明明确要求,退回旧版本前先把这两个字段从规则里去掉。
Step 5:用预演命令验证,再启用场景模板
官方给了三条低风险命令,用来在真正派活之前看清规则会怎么走:check 校验生效规则或一份草稿、rules explain 看生效规则与下次定时、emit --dry-run 预演一条事件会派给谁(不连接中台、不写日志)。
# 校验当前生效规则
agent-autoloop check
# 只校验一份草稿,不碰正在跑的中台
agent-autoloop check rules-draft.json
# 看生效规则与下次定时(也可指定草稿)
agent-autoloop rules explain
# 预演一条事件会派给谁
agent-autoloop emit issues.opened --dry-run
# 立即手动跑一轮,验证闭环
agent-autoloop run 早报
# 启用模板的顺序(以每日早报为例)
# 1. 打开 examples/recipes/ 里对应说明
# 2. 模板带任务 Skill 时,把它放进所用 Agent 的 skills 目录
# 3. 把示例规则合入 ~/.agent-autoloop/rules.json
# 4. 替换里面的电脑名与路径,再跑一次 agent-autoloop check
briefs/YYYY-MM-DD.md)、跟进 GitHub Issue(每 5 分钟查新 Issue,本地改代码并通知你查看,不提交、不推送、不回复 Issue)、线上告警排查、用户反馈处理、网站巡检、飞书周报与业务摘要、收件箱分诊、PR 自动交付。先用不带写权限的模板练手。模板里的样例数据是虚构的:官方明确写出,反馈处理、网站巡检、飞书摘要与收件箱分诊默认使用北京时间、只发本人的飞书私聊;脚本与回执只用本地 HTTP 和假飞书 CLI 验证过,没有在真实账号上跑过完整业务。要接真实飞书、GitHub 或邮箱,得自己补齐凭据、权限与合规审查,别把演示回执当成生产验收。
Step 6:暂停、补跑、追溯与升级收口
后台跑起来之后,真正考验的是「出事了能不能查清」。pause 与 resume 管单条规则,run 手动补一轮,runs 与 why 用来回溯;这些动作记在中台日志里,不改 rules.json。
# 暂停一条规则;暂停期间到点不跑、来事件不接也不排队
agent-autoloop pause 处理 issue
# 恢复:官方说明恢复后不自动补跑,会列出暂停期间跳过的事件
agent-autoloop resume 处理 issue
# 照给出的提示补跑,每条只补一次
agent-autoloop replay 处理 issue --since 2026-11-14T09:00
# 立即跑一轮 / 列做完的轮次 / 往前翻
agent-autoloop run 早报
agent-autoloop runs 早报
agent-autoloop runs 早报 --before 3
# 用轮次编号看来龙去脉
agent-autoloop why 3
# 升级前记下当前规则,升级后再核一次
agent-autoloop check
agent-autoloop update
agent-autoloop status
v1.8.3 还改了几处会影响排查的细节:卡片、桌面通知、Webhook 平台与 status 的待决定列表都会在标题下写出是哪条规则问的(标题本身就是规则名时不重复);飞书兼容旧版 lark-cli(如 1.0.66);GitLab 评论事件沿用所属 Issue 或 MR 的事项编号;接单程序找不到某个 Agent 程序时不再记住这个结果,程序装回来后不用重启就能用。
交付前自查:本教程的安装命令、规则字段、CLI 子命令与场景模板来自官方仓库 KKKKhazix/agent-autoloop 的 README;版本改动来自 v1.8.3 发布说明;项目按 MIT 许可发布,迭代速度较快,命令与字段请以你使用当天的 README 和 Release 页为准。规则会让 Agent 以你的登录态在指定目录执行动作,跑批量任务前先设好用量上限;接外部事件源所需的凭据、权限与数据合规由你自己负责。任何落地改动都请自行审 diff 并复跑测试后再提交。
做到哪一步算成功
五条验收都过,才算这套后台调度真的落地了:① status 能显示今天与近 7 天的轮数、Token 与费用,且你能说清 v1.8.3 之后输入含缓存的统计口径;② try 走完「提问 → 退出等待 → answer 拍板 → 接上原会话做完」,等待期间没有常驻 Agent 进程;③ rules.json 里至少有一条定时规则和一条事件规则,check、rules explain 与 emit --dry-run 的输出与你的预期一致;④ 用 run 手动跑过一轮,并用 runs 与 why 查到这轮的来龙去脉;⑤ 暂停与恢复走过一次,知道恢复不会自动补跑、要用 replay --since 按提示补,并且没有把演示模板里的虚构数据接到真实账号上。做到这些,再把规则文件纳入版本管理并写进团队的运维清单。
常见问题速查
| 你遇到的现象 | 大概率原因与处理 |
|---|---|
agent-autoloop 命令找不到 | 安装脚本没把入口加进 PATH,或终端没重开;重开终端再跑 status,必要时重新审阅安装说明 |
status 一直全零 | 还没配规则或没触发过;先用 run <规则> 手动跑一轮再看 |
| 改完规则看不到新行为 | 改错时系统会继续按旧规则跑并发卡片提醒;跑 check 与 rules explain 确认生效版本 |
| 事件规则始终不触发 | 来源没在 sources 里登记;先用 emit <类型> --dry-run 看派给谁 |
answer 后没有继续 | 编号与当前待决定卡片不对应,或 CLI Agent 没打印最终回复;重看 try 输出的编号 |
| 暂停期间的事件丢了 | 官方设定是不排队、不自动补跑;按 resume 给出的提示用 replay --since 补 |
| 升级后 Token 数字对不上 | v1.8.3 统一了含缓存的输入口径,升级前的旧记录一周后才自然对齐 |
| 退回旧版后规则读不了 | 规则里用了 v1.8.3 新增的 model / effort;回退前先移除这两个字段 |
| 照模板接飞书却发不出卡片 | 模板只用假飞书 CLI 验证过;检查 lark-cli 版本与真实凭据、权限配置 |