无人值守（autopilot）的 loop engineering 实战：我们开源了解放您双手的新 agent skill

上一篇讲 design-review 和 build-phases 的时候，我引了 Addy Osmani 那句话：loop engineering 是把「反复推动 agent 的那个人」换成机制。那一对 skill 做的，就是把我从两个 terminal 里的 copy paste 里换下来。可换下来之后人并没有消失，工位只是挪了一下：不再答二十个细节，改成盯着一个窗口，等它停下来问下一步。那种累和写代码不一样。写代码的时候人至少在想，等 agent 停下来的时候，人是在值班。

这几个月我们没怎么对外讲的，是后面四个 skill：issue-review、issue-sweep、pr-review、pr-sweep。有了它们，开发者的主业不再是对着 terminal 操作 AI agent，而是开 issue，看 issue，看 PR，回答那些真正需要人拍板的问题。调度交给定时任务，Claude 上的 routine 或者本机 crontab 一类的东西，到点拉起一次 agent session，扫完就走，夜里也转。我自己的感觉是，这一跳不亚于从手工写代码转到用 code agent，吞吐大概是原来的三到五倍。这不是对照实验，是这几个月用下来的体感。更重要的是人不那么累了，因为不用坐在那儿等它停。

很多人听到「无人值守」或者 autopilot，会以为人终于可以从决策、审美和责任里撤出去了。恰恰相反。琐碎的推进交给 agent 自动干，人反而更专注于那几件撤不掉的事：这值不值得做，做成的东西好不好看、好不好用，出了问题谁认账。 解放的不是参与，是值班。人没有离开工程，是回到工程里真正需要人的那一层。

上一对 skill 把人换下来了，但人还在当调度

design-review 解决的是计划会漂：每一轮派一个没参与过对话的 agent 来冷读，改到文件里，再派下一个。build-phases 解决的是执行会漂：一个阶段做完，验证过了，才进下一阶段。这两件事做完，人已经不用再当那个被追问细节的人，可人还是那个按一下回车、看它跑完、再告诉它下一步的人。循环会不会往前走，取决于这个人还在不在窗口前面。

所以真正要换掉的，不是「人还要不要参与」，是「人是不是还得守着会话」。上一篇已经写过：细节交给 agent，方向留给人。 四个新 skill 做的，是把「守着会话」也交出去。方向、口味、最后那次签字，还在人这儿。变的只是，人不用为了守住它们通宵盯着窗口。

人的工作面换成了 GitHub

有人会觉得这不过是把 terminal 换成了网页。差在谁先动。以前是人先动：打开 agent，描述任务，等它问，答完再等。agent 是工具，人是调度。现在是 issue 先动。人把要做的事写下来，一轮 sweep 扫到它，能做的做掉、开出 PR；碰到分叉，把问题和推荐写成一条评论，挂在 issue 或 PR 上，再去处理下一项。隔几个小时回来，看到的是已经推进过的一批，加上少数真正需要判断的问题。在 GitHub 上普通回一条评论就行，下一轮会读到。

这四件事里，最容易被低估的是最后一件。agent 不是不会做，它是碰到分叉了。要不要改架构方向，这条安全边界能不能放，这个交互该紧一点还是松一点，A 和 B 选哪个。它把选项、已经核验过的部分、它的推荐，写成一条人能直接答的问题。人答一个字或选一项，下一轮接着干。人被叫住的次数少了，每次被叫住的问题变重了。 那才是决策、审美和责任真正发生的地方，也才是人该干的活。

开 issue 也不是随便丢一句话。写得清楚的 issue，循环能自己走很远；写得含糊的，它会先回来问。这跟 IDD 是同一件事：先把「要什么」写清楚。入口不再是一份单独的 intent 文件，是团队已经在用的 GitHub issue。意图写得越清楚，后面留给人的就越是判断，而不是补作业。

四个 skill，其实是两对

issue-review 处理一条 issue：读正文和评论，对照已经落地的代码，给出带证据的判断，必要时开修复、开文档更新，或者停下来问人。pr-review 处理一个 PR：读 diff，对照现实代码，跑验证，给出能不能合的判定。它们是引擎，单独用也行，人点名一条就审一条。issue-sweep 和 pr-sweep 是定时司机。一轮扫过去，找出有新人输入、或者上次没做完的那些，把每一条交给对应的引擎。issue 这边推进到开出 PR，PR 这边推进到能合的合，不该合的留下问题和证据。

两对是对称的。一边吃 issue，一边吃 PR。中间那条线，就是团队本来就该有的工作流，不是我们发明的新仪式。这里有一条听起来很笨、但决定这套东西能不能长期跑的规则：没有新输入，就不要重做。 已经看过、人没回、代码也没变的，下一轮直接跳过。否则每个钟头都会把同一批评论再刷一遍，人也被刷屏烦死。循环要能夜里接着转，先得学会闭嘴。

还有一条边界必须写进句子里，不然听起来像在卖无人公司。pr-review 只判断、只评论，自己不合。低风险、测试过、PR 标题和正文说的事跟 diff 对得上的，pr-sweep 可以合；碰到安全、破坏性变更、方向没定，或者「这样好不好看」这种口味问题，它停下来等人。同一条 issue 上开了两个重复 PR，它留一个，把另一个关掉。所以「解放双手」不是「人不用看了」，是人不用再当那个守着窗口的调度。看，还是要看的，看的是结果和判断题，不是看它一步步打字。责任也还在人这儿：agent 可以推进，不能替人签字。

过去那对 skill，是在这里被接上的

四个新 skill 不是另起炉灶。上一篇开源的那一对，正好接到这条循环里。issue-sweep 碰到一个真正多阶段的 feature issue，能起步就跑 design-review 把方案磨扎实，再交给 build-phases 按阶段做。小而明确的改动不走这套，直接修、验证、开 PR。判断标准和上一篇写的一样：担心的是不是「做到一半发现方向错了」。是，才启动那对；不是，别杀鸡用牛刀。

pr-review 每一轮都新开一个 agent 来读 PR，看不到上一轮的对话。这和 design-review 每一轮派一个全新审计者，是同一条原理。写过的那个会话不能评自己，它只能看到磁盘上的文件和这条 PR 的 diff，没法靠「我们上一轮讨论过了」蒙混过去。几个 agent 同时改代码，还是各用一份独立的工作目录，也就是 git worktree，免得一个人切分支把别人正在用的目录也带走。收工怎么避免把硬盘吃满，还是 git-hygiene 那篇的事。

所以我们不是做了四个新玩具。是把已经验证过的那几块，接到 GitHub 这个团队已经在用的工作面上，再加一个会按时来扫的司机。人省下来的注意力，正好拿去看方向对不对、东西好不好、这口责认不认。

怎么用

它们是 agent skill，装进 Claude Code 或 Codex 之后用斜杠命令跑。不绑定某一个厂商，只是我们日常用这两个。安装和系列里其它 agentloop skill 同一条路：

npx add-skill arcblock/agentloop

人在场、要处理一条具体的 issue 或一个 PR（把编号换成仓库里的）：

/agentloop:issue-review 115
/agentloop:pr-review 420

让循环自己转：

/agentloop:issue-sweep
/agentloop:pr-sweep
/agentloop:pr-sweep --merge

想先看它打算做什么、不写回 GitHub，三条都可以加 --dry-run。默认的 pr-sweep 只审、只关同一条 issue 上的重复 PR、只评论，不合。--merge 才打开合并。打开之后仍然过闸：测试要过，PR 里写的事要跟 diff 对得上，安全、高风险、以及需要人看一眼的口味问题，仍然停给人。夜里接着转，靠的不是人通宵，是把两条 sweep 写进 Claude 的 routine 或者本机 crontab，到点跑同一条斜杠命令。人异步回 issue、回 PR，普通评论就行；下一轮扫到回复接着干，人没回它闭嘴。仓库要已经接上 GitHub，跑这些命令的环境也要能操作那个仓库。完整实现在各自的 SKILL.md 里：issue-review、issue-sweep、pr-review、pr-sweep。

什么时候不适合

适合试的场景很具体：工作已经在 GitHub issue 和 PR 上走，积压开始把人按在窗口前面值班。一个人、一个 terminal、改一个小 bug，直接让 agent 做完跑个测试就行，为这个启动 sweep 是把厨房开火说成要建一座发电厂。团队还没有把工作放进 GitHub，这套也转不起来。它吃的是已经写下来的工作，不是还没说出口的想法。先有工作流，再谈循环。

就想坐在那儿把设计聊清楚，用已经介绍过的 design-review 就够了，不必为了「上 loop」把一次面对面的讨论拆成隔夜的评论往返。它更不适合用来逃避判断。循环会把判断题送回来；既不回 issue、也不看 PR，它就停在那儿。7×24 转的是机器，不是替人想，更不是替人签字。autopilot 接过的是飞行中那些重复的微调，不是航线、也不是落地那一下。

人不用再值班了

上一篇的结尾说：intent 的打磨可以交给 agent，人守住的是方向，以及最后那次「这是不是我要的」。四个 skill 把这句话从一次任务里，推到了日常。人守住的还是这些，而且守得更紧：做什么、好不好、出了问题算谁的。变的是人不用再为了守住它们，一直坐在 terminal 前面。

Addy Osmani 说 loop engineering 是 replace yourself as the person who prompts the agent。^[1] 上一对 skill 换掉的，是那个在两个窗口之间粘贴的人。这四个换掉的，是那个守着窗口、等它问下一步的人。剩下的，才是人真正该在的位置。不是从工程里撤走，是终于有时间待在决策、审美和责任这三件撤不掉的事上。

GitHub: github.com/ArcBlock/agent-skills

系列相关：

参考

1. The Pragmatic Engineer, What is loop engineering? https://newsletter.pragmaticengineer.com/p/what-is-loop-engineering ↩