周末在咖啡店，宝宝睡着了，我偷到半小时。周一到周五连轴转，连思考的喘息都没有，这会儿咖啡下肚，脑子异常活跃，想法一个接一个往上冒。手边没带电脑，我怕它们溜走，就打开 Apple Notes，按住语音输入，把脑子里的东西一股脑倒出来。不管语法，不管先后，不管错别字，一口气口喷了七八条 idea，全是最近那个项目的新功能。
倒完我盯着这几条笔记，冒出一个问题：为什么每次都得我，把脑子里的东西搬运到 agent 面前？
这半年我一直在推 loop engineering 这件事。上一篇《Loop Engineering：能放手的是执行，不能放手的是方向》讲的是道理：人能放手的是执行，守住的是方向。这一篇是把它真跑了几天之后的话。跑下来我最大的体感是，当执行整段交出去，剩下那摊活根本不是"写代码"，是"带团队"。
Loop engineering 跑到实处，就是搭一个团队协作的闭环。这个团队里只有我一个真人，其余全是 agent。我的岗位，从执行者换成了那个定方向、决定做什么、设计大家怎么协作的人。
跑起来之后，我每天只剩两件事
那天在咖啡店想到的第一个落地，就是别再把想法憋在自己脑子里当"人肉中转"。Apple Notes 本来就是我平时记笔记的地方，它又能共享，那我 MacBook 上那个跑着 Hermes 的独立账号，正好可以和我共享同一批笔记。我照旧用我最顺手的方式记想法，需要"落实"或者进一步调研的时候，把这条笔记 handoff 给 agent。中间隔着一层共享的 Notes，等于给我和 agent 之间留了一个干净的隔离区。
我给这批笔记分了四层目录，每层就是一个状态：想法先丢进 Backlog；想认真做的，挪进 Kickoff，这个动作本身就等于"立项"，agent 看到就接手；干完了它放进 Done；中途撞上自己处理不了的坎，就退回 Blocked，等我来救。状态一变，我在 IM 上就收到一条通知。
为什么非得有"立项"这个动作，而不是在聊天窗口里直接跟 agent 说一句？因为我试过直接说。一个任务顺口一交代，后面再叠上几轮别的讨论，很快就串台了，agent 分不清哪句是这个任务的、哪句是那个任务的。而且一个任务几乎从来不是 one shot，中间人总要参与几次。正经做项目管理，光靠即时聊天是应付不过来的，你需要一个能把任务钉下来的协作看板。IM 适合派活和抽查，看板适合沉淀和纵览，这跟人跟人协作是一样的：简单的事喊一嗓子，复杂的事得落到板子上、盯起来。
这套跑通之后，我一天的活塌缩成两件事：往收件箱口喷想法，等 agent 交付完，自己再验一遍。
但我留了一手：PR 合并这一步，仍然必须我点头。信任是一点点给出去的，不是一步到位。一个人把事做得越来越靠谱，你才敢把越来越多的事交给他，agent 也一样。要把执行放心交出去，有三样得先立住：任务边界（它该做到哪、不该碰什么）、协作约定（我俩怎么配合）、以及任务 SOP（把它处理这类任务的套路，跟它一起沉淀成文档）。再加一条，执行过程要有日志，比如每五分钟汇报一次进度。不是我要盯着它，是必要时我能回看，它到底有没有跑在正确的轨道上。
一个 agent 不够，于是我想找一支"军团"
看板解决的是"任务怎么流转"，没解决"单个 agent 交付质量"这件事。一个 agent 干活，多少带着它自己的 bias，很容易做到某个程度就觉得"够了"。这不是它偷懒，是它没有一个跟它较劲的对手。
我在想的下一步，是把原本一个 agent 单兵包圆的全站开发，拆给几个被授予不同身份和视角的 agent。需求来了，先过一个做需求分析的 agent，把一句话的想法扩成 PRD，中间的假设和取舍它自己先掂量，跟总目标有矛盾的地方，必要时拉我确认，在开工前把路障扫掉。往下是设计的 agent，把 PRD 落成视觉和交互，有现成规范就复用，冒出新范式就先定范式再落地。再往下才是编码：写代码的 agent 自己写、自己自查，但它得把成果交给另一个 agent，最好是不同的模型，来挑它的毛病。不同模型的 bias 不一样，正好互相补，这也是我在《用 AI 评估 AI，靠谱吗》里琢磨过的那件事。
这么排的好处，是每个 agent 有自己的站位和屁股，各自守着各自那摊该较真的东西，一个任务就被打磨得更周全。而这些角色之间交接的接缝，恰好就是留给人的检查点。人类团队本来就是这么分工的：工程师写到单元测试就算交付得比较完整了，端到端测试、可用性测试自有别人接手，免得一个人被压垮。
但这套目前还只是我在验证的方向，没跑成战绩，我得说清楚。真做起来，最难的不是让 agent 干活，是协调它们。我得摸清每个 agent 适合干什么、预期产出大概什么样，把它调度到合适的环节，还要给它指引、给它划协作的边界。这些活换个说法，就是"管理"。
而且军团不是随便什么任务都值得上。复杂任务、或者设计可能大改的时候，多几双眼睛交叉查漏是划算的；可要是只改一个页面、一个小模块，还摆开军团阵仗，那点协作成本立刻变成内耗，沟通花的时间比干活还多。所以我现在缺的，其实是一个给 agent 用的"协作平面"，还是前面那块看板：有的往里塞任务，有的认领、解决、交付。这跟我之前拆 harness 时看到的那一章"agent 自己上看板认领任务"（Agent Harness 剖析），撞上了同一个需求。
人退到哪去了：决定做什么
把执行交出去之后，我发现自己每天真正花时间的地方，挪到了"决定做什么"上。现在我大部分的活就是写 spec：想清楚要做什么，把大致的实现路径和交付标准跟 agent 对齐，这条 spec 变成一张 ticket，扔给 agent 去完成。具体怎么编码，已经不那么重要了。
有人会问，那"让 agent 自己找活干"呢？我在《把整个组织喂给 agent》和《个人靠第一推力，组织靠智能中枢》里，主张过让 agent 从"被 @ 才动"长成"自己发现该干什么"。这两件事不打架。我自己写 spec 下发，本身就是一种 trigger；让 agent 定期 review 项目、监控线上反馈，是另一种 trigger，区别只在于后者是在给它塑造主动性。关键是这些 trigger 最好都指向真正的"问题"。
trigger 好不好使，取决于任务有没有客观的对错。有明确好坏的，agent 能自己闭环：比如上线后盯错误日志，某个错误冒出来、或者冒得很多，agent 自动触发修复，几个 agent 先充分讨论再动手，复现、验证、跑通，把 PR 递到我面前。越是没有对错、越是价值判断的任务，越得我在场。而"决定做什么"正是价值判断最密集的地方，它勾着真实的商业目标，在 agent 的 context 还没铺到组织每个角落之前，它的判断难免带偏。所以这块暂时攥在我手里，不是它不能碰，是现在还没到能放手的时候。
我的思考
跑了几天，几个判断对我更清楚了。
第一，loop engineering 的实处是带团队，而不是写更复杂的编排。 它要的是一个团队该有的东西：对齐的愿景、清晰的目标、有共识的协作规则、有效的沟通和纠错机制，再把能自动化的环节自动化掉，别占用有限的带宽。这个团队里只有我一个真人，可我依然得是那个定方向、立愿景、决定做什么的人。
第二，软件工程学非但没过时，反而更吃紧了。 被 agent 接手的只是中间那些执行环节，而每个 agent 都有自己的能力上限和 bias，有些地方它的上限比人高得多，有些地方它会想不到、需要反复。怎么把系统架构成能适应组织需求和功能演化的样子，怎么让代码仓库不只对 agent 友好、也对人友好，这些老问题一个都没少。
第三，大部分我们说的"错误"，其实不是错误，是"没对齐"。 The Pragmatic Programmer 里有一句话我一直记着："No one knows exactly what they want。"人自己都未必清楚要什么，把它准确传给 agent 就更难。沟通必然有损耗，我和 agent 怎么把这份损耗压到最低，是这套协作里绕不过去的功课。我在《语言的边界，就是协作的边界》里担心过的那件事，在这里又被验证了一遍。
第四，这套东西不是一次顶层设计就位的，是在做的过程里长出来的。 agent 对产品目标了解得越多、这些理解越是沉进代码仓库，我需要去 prompt 它的地方就越少，因为规范、约束、开发流程都已经长在架构里了。所以它不是画一张大图就能收工的活，是边跑边沉淀出来的。
跑到这一步我才发现，把执行交出去并没有让我更清闲，只是把我从一个埋头干活的人，变成了一个要把这支只有一个真人的团队带明白的人。这活不轻，但大概就是 agent 时代，该轮到人干的那部分。
参考
- Loop Engineering：能放手的是执行，不能放手的是方向
- Agent Harness 剖析
- 把整个组织喂给 agent
- 个人靠第一推力，组织靠智能中枢
- 用 AI 评估 AI，靠谱吗
- 语言的边界，就是协作的边界
- David Thomas & Andrew Hunt, The Pragmatic Programmer (1999)