循环工程：控制面与失败模式

Loop 的可靠性不来自自动化程度，来自控制面：六个组件各管一种漏法，五种死法各有对应的工程动作。

把 loop 的可靠性寄托在自动化程度上，是最常见的误判。定时重放一个 prompt，谁都能在一个下午搭起来；让它在第三周还值得信任，靠的是另一套东西——你把状态、验证、权限和停止条件写进了工程流程的哪一层。Addy Osmani 把这件事说成：不再是那个提示 agent 的人，而是设计提示 agent 的系统的人 addy-loop-engineering。本篇讲这个系统里面装什么、会怎么坏；什么时候该建、凭什么算停，在 循环工程：准入与停止。

自动化程度不是重点，控制面才是

一个能工作的工程 loop 有六个动作：读取外部状态、判断下一步、执行任务、验证结果、把结论写到对话之外、判断是继续还是收手 taobao-loop-engineering。少了第五步，它只是一次会话；少了第六步，它就是烧 token 的定时器。判断一个 loop 的成色，数它自动化了几个环节没有用，要看每个环节外面有没有控制件。

四种工程的分工也按这个层次排：prompt engineering 关心一句话怎么写，context engineering 关心给模型什么材料，harness engineering 关心工具、权限和运行环境，loop engineering 关心这些东西如何持续运转 taobao-loop-engineering。Harness：模型之外的工程控制层 管一次运行的能力与约束，loop 管多次运行之间的触发、状态与验证——前者是控制件，后者是调度与闭环。只有调度没有控制件，是定时犯错；只有控制件没有循环，还是一次性工具 boeckeler-harness。

工程师的位置因此变了，但责任没变：从每一轮的操作者，变成循环机制的设计者和最终责任人。什么值得自动化、哪些权限可以放开、哪些 diff 必须人工读、停止条件写在哪，仍然全是你的事 taobao-loop-engineering。

六个组件各管一段，缺一个就漏一种坏法

一个能跑的 loop 由六种组件拼成，每种组件对应一种它会漏掉的坏法 taobao-loop-engineeringaddy-loop-engineering。

唤醒件只负责心跳，不负责大脑。 定时唤醒是最容易被误解成「智能」的组件：它按计划把任务叫醒，判断标准却要你提前写进 prompt。一份能用的唤醒 prompt 要同时写两样东西——前馈约束（开始前必须知道的：只看哪个 PR、不能碰哪些目录、什么风险必须停）和后馈传感器（做完后必须接受的：跑哪个测试、贴哪个浏览器录制、让哪个 reviewer 读 diff）boeckeler-harness。没有前馈，agent 到处试；没有后馈，它会把「我觉得可以」当成完成。同样是每天检查项目，「读取最近 24 小时失败的 CI，只处理当前 PR 相关的失败，稳定复现才建最小修复，每轮最多改三个文件，遇权限与安全变更停止交人」是操作规程；「有问题就修一下」是愿望清单——后者把判断权交给了模型猜。

隔离件解决机械冲突，不解决理解带宽。 多个 agent 同时改一个 repo，第一类失败不是推理失败而是文件冲突，给每个任务一个独立工作副本能挡住它。但并行只该用于低耦合任务，合并仍要按人的理解能力限流：你每天让八个 agent 各开一个 PR，而你只能认真读两个 diff，系统吞吐没有提升，只是把瓶颈从「写代码」挪到了「理解代码」——而且这种瓶颈不报错，PR 都很小、测试都可能是绿的。

知识件把项目知识移到对话外面。 没有技能文件的 loop，每次醒来都像新来的同事：重新猜测试命令、重新理解目录结构、重新发现团队不接受哪种写法。它省的不只是 token，还有误判——项目约定没写下来的时候，agent 会用开源世界的常见模式补空白，你的项目越特殊，这种补空白越危险 taobao-loop-engineering。技能要小而明确，因为 agent 是根据描述决定是否加载它的。

工具件接通真实系统，权限要跟着能力一起收紧。 只看文件系统的 loop 很快不够用，真实工程状态分散在代码托管、工单、告警、日志和 CI 里。这里要分清三样东西：接入协议、面向具体系统的连接、把技能和配置打包分发的机制——装一个包不等于权限、审计和审批都已经设计好 taobao-loop-engineering。能力变强以后权限设计要更严格：能读日志和能改生产数据库不是同一种权限，能开 PR 和能自动合并也不是。

查写件把做事的人和裁判分开。 写代码的 agent 不适合做唯一裁判——它刚刚花了几轮说服自己这条路线成立，很容易继续相信自己的结果 taobao-loop-engineering。一个稳妥的分工是探索、修改、验证、审查各归各的 agent，安全审查单独一路。但 sub-agent 不是免费午餐：它增加 token 成本，也增加协调成本，只有检查环节和可以并行的读多写少任务才值得配；任务很小的场景，一个执行加一个验证通常够了。拆分的判据见 多 Agent 什么时候才值得。

状态件让系统活在对话之外。 上下文会压缩，线程会中断，模型会忘，agent 还会重复尝试同一条死路。外部状态层不是锦上添花，是 loop 能不能接着跑的前提：当前目标、已处理事项、已尝试方案、失败原因、已通过的验证、待人工判断的问题、下一轮入口，都要有对话之外的一个落点 taobao-loop-engineering。强约束放在仓库文档而不是平台记忆里——团队规则要可 review、可版本化、可共享。一句话：模型可以忘，系统状态不能忘。

五种死法，每一种都有对应的工程动作

目标函数太粗。「提升质量」「优化体验」会被 agent 翻译成自己能做的动作：重构、改文案、加测试、删重复代码。动作看起来都合理，但未必解决你的问题。目标要写成可验证条件——「让哪几条失败用例通过、不许改断言、不许动哪块生产逻辑」这种形状，判据见 先定义完成，再写第一行代码。

验证被 agent 自己吞掉。 日志很长时，agent 会总结成「测试通过大部分，只剩少量无关问题」——这句话在 loop 里应该直接判失败。验证结果必须结构化：至少记录跑了什么命令、退出码、哪些用例失败、是否满足停止条件 taobao-loop-engineering。Amplitude 的 Ralph loop 实验里有个做法可以借：让 agent 给自己产出的功能埋点，下一轮用数据看哪些路径被用过、哪里卡住，每个 PR 附一段浏览器录制作验证证据 amplitude-ralph。验证不靠自述，靠证据。

状态文件没人读。 写状态只是第一步，下一轮 prompt 必须显式要求先读状态文件、按状态决定是否继续，否则它只是一份没人看的日报 taobao-loop-engineering。

并行制造理解债。 并行 agent 很容易让人产生产能翻倍的错觉。合并之后的系统你是否还理解，才是更难回答的问题——只看 summary 不读 diff，这笔债积累得很快 taobao-loop-engineering。这和 让验证速度追上生成速度 的剪刀差是同一件事的两面：产出量超过验证吞吐时，不报错，但你已经说不清系统里发生了什么。

成本没有上限。 loop 的 token 成本不是账单问题，是架构问题——没有上限的 loop 最后一定会被成本、噪音或误操作叫停 taobao-loop-engineering。每个 loop 都要有预算：每轮最多几次尝试、每天最多开几个 PR、多久没有进展必须停止、什么情况必须交给人。预算的归因方法见 成本要能归因到每一步。

权限一级一级放

按风险分层给权限，不要一步到位：第一级只读，允许总结和分类；第二级允许生成 patch 或 PR，但不允许合并；第三级可执行外部动作，关键步骤需要人批准；第四级才给低风险、可回滚、验证强的任务 taobao-loop-engineering。大多数团队不该从第四级开始——前两级做扎实，收益已经很明显，而且失败代价只是一个待审的 patch，不是一次生产事故。审批请求本身要能被验证（对什么动作、影响哪些资源、何时过期），细节见 沙箱、凭证与人机边界。

EurekAgent 论文把同样的意思讲成了环境工程：权限、产物、预算和 human-in-the-loop 不是配套设施，它们直接改变 agent 做事的方式——给有边界的执行和隔离的评估，agent 的表现和放任状态下不是一个物种 eurekagent。

让 harness 自己长大

有一种 loop 不直接交付功能，却让后面的功能 loop 都更稳：每周读最近合并的 agent PR 和 review 评论，找出重复出现的失败模式——误改公共接口、漏跑迁移、测试只覆盖正常路径、过度重构。找到之后分两类处理：能用确定性工具拦住的，优先补 lint、类型检查、架构规则或测试夹具；只能靠语义判断的，才去更新审查技能或验证 prompt。每次只改一个控制件，并记录这个控制件拦住了什么问题、有没有带来误报 taobao-loop-engineering。

很多团队先迷上「让 agent 写更多代码」，但更该先问的是：怎样让 agent 少犯同一种错。这个判断也补上了一条准入条件——这个 loop 的产物能不能沉淀：一次性的对话失败了只留下聊天记录，一个好的 loop 失败了，应该留下更好的夹具、更明确的规则、更小的技能，或者一条以后能复用的流程 taobao-loop-engineering。否则你只是在反复购买同一份现场发挥。把可靠流程沉淀成可复用、受约束的工作流而不是每次临场发挥，也是那篇 workflow store 论文的核心论点 workflow-store。

什么时候不该做成 loop

直接提示 agent 仍然有用，很多任务就该在一轮对话里解决。不要为了显得先进，把所有事都做成 loop；重复发生、边界清楚、验证明确、风险可控的工程任务，才值得付这份工程成本 taobao-loop-engineering。

最后可以用一个朴素的标准验收：这个 loop 是让你更理解系统，还是让你更少读代码、更少判断、更少承担责任。前者是杠杆，后者只是更快地欠债 taobao-loop-engineering。