进阶 📋 6 个步骤 第 621 / 623 篇

用 Agent Autoloop 让命令行 Agent 在后台接活:安装试跑、rules.json 定时与事件规则、问答闸门与补跑追溯实操

Agent Autoloop 是跑在本机的后台中台,把定时与外部事件交给已登录的命令行 Agent,遇到需要拍板的问题才发卡片找你,回答后接上原会话做完。本教程按官方 README 与 v1.8.3 发布说明六步落地:核对 Node 24 与 Git 前置、安装并用 status 验零、从 try 到 answer 走完一次问答暂停恢复、写 rules.json 的 cron 与 source 两类规则、用 check 与 emit --dry-run 预演,最后用 pause / replay / runs / why 做补跑与追溯。主线不需要 API Key,但模型调用按你的账号计费。

2026.11.14· 18 分钟阅读· 约 3671 字· 🔁 Agent Autoloop / ⏰ 定时与事件规则

很多人用 Claude Code、Codex 这类命令行 Agent 时都卡在同一处:人一关终端,活就停了;碰到一个需要拍板的问题,还得守在屏幕前。Agent Autoloop 是一个跑在本机的后台中台,把定时与事件交给已登录的命令行 Agent,遇到拿不准的事才发卡片找你决定,等你回答后再把原来的会话接起来做完。本教程按官方仓库 README 与 v1.8.3 发布说明六步落地:核对前置、安装并验零、跑一次带问答的试跑、写定时与事件两类规则、用预演命令验规则、最后把暂停补跑与追溯收口。整条链路在本机完成,不需要 GitHub 账号,但会产生真实的模型用量。

🔁 适合谁:已经装好并能正常对话的命令行 Agent(Claude Code、Codex 或任何「给一段提示词、打印最终回复」的 CLI 工具),想让日报、Issue 跟进这类任务自己跑起来的开发者。前置准备: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:审阅安装脚本与本机前置

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 验零

2 装完先确认中台是空的

官方给的两条安装命令按平台二选一。装完立刻跑 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:跑一次带问答的试跑,看它怎么停、怎么续

3 try 到 answer 再到 status

官方建议装好后用本机的 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 是否真的能打印最终回复。这一步验的是「会话能暂停再恢复」,不是模型答得对不对。

💡 把「等待期间不占进程、不花 Token」当成验收点:它决定了这类工具值不值得用来跑长任务。若你的 Agent 在提问后仍挂着一个常驻进程,说明链路没按官方设计走通,先排查 CLI 调用方式再往下配规则。

Step 4:写 rules.json 的定时与事件两类规则

4 写清「什么事、交给谁、在哪个目录干」

规则文件在 ~/.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:用预演命令验证,再启用场景模板

5 check / explain / emit 三条都不碰线上

官方给了三条低风险命令,用来在真正派活之前看清规则会怎么走: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
💡 官方内置的场景模板包括:每日早报(默认每天 8 点整理本地笔记与 Git 提交,写入 briefs/YYYY-MM-DD.md)、跟进 GitHub Issue(每 5 分钟查新 Issue,本地改代码并通知你查看,不提交、不推送、不回复 Issue)、线上告警排查、用户反馈处理、网站巡检、飞书周报与业务摘要、收件箱分诊、PR 自动交付。先用不带写权限的模板练手。

模板里的样例数据是虚构的:官方明确写出,反馈处理、网站巡检、飞书摘要与收件箱分诊默认使用北京时间、只发本人的飞书私聊;脚本与回执只用本地 HTTP 和假飞书 CLI 验证过,没有在真实账号上跑过完整业务。要接真实飞书、GitHub 或邮箱,得自己补齐凭据、权限与合规审查,别把演示回执当成生产验收。

Step 6:暂停、补跑、追溯与升级收口

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 版本与真实凭据、权限配置
← 返回教程中心