--- title: "Loop Engineering 详解：从 SRE 黄金信号到状态机设计与三层架构" source_url: "https://mp.weixin.qq.com/s/nl3JUGXmWkjYOUdc7K2aSA" author: "若飞" source: "架构师（JiaGouX）" ingested: 2026-07-01 sha256: placeholder --- 架构师（JiaGouX） 我们都是架构师！ 架构未来，你来不来？ 最近聊 Loop 的人越来越多。 Claude Code 把 Loop 放进代码任务里，Codex 用 goal 把任务往验收条件上推，Mira 这类入口又把循环带到聊天、日程和日常协作里。 这些工具看起来差别很大。一个在 IDE 里，一个在编码工作流里，一个更接近日常聊天入口。 但从工程视角看，它们绕不开同一个问题： 当 AI 从"一次回答"走向 持续执行 以后，系统怎么证明它没有跑偏？ 一个 Agent 可以每天整理邮件、修 CI、写会议纪要、更新工单。它也可能每天重复同一个错误，只是把总结写得越来越像"已经处理过"。 如果放回今年我们一直梳理的那条线里，这并不突然。从《AI-First不是多装几个Agent》到《Cursor 的 Harness 方法论》，我们一直在研究模型外面的软件工程；后来写过程资产、/goal 和 Loop Engineering，问题又往前走了一步：经验、目标、反馈和停止条件，最后都要落到系统里。 所以我看 Loop 时，先不急着看入口，也不急着看它能自动做多少事，而是先看几个更朴素的问题：反馈 从哪里来，状态 能不能留下，什么时候停，人能不能接手。 Loop 不难启动。难的是每跑一轮以后，系统能不能拿到可信反馈，能不能记住上轮发生了什么，能不能在边界不清时停下来，把事情交还给人。 这几件事没设计好，Loop 看起来是在持续工作，实际可能只是稳定地产生错觉。 先别被工具名带着走 Loop 可以从提示词开始，也可以接上定时任务，但它要稳定跑起来，还需要反馈、状态和退出机制。 更贴近工程的说法是：Loop 是一套带反馈、状态和停止条件的小型运行机制。 目标要能判断完成，反馈要能从环境里拿回来，状态要能被下一轮继承，停止条件要提前写清楚。少了其中任何一项，Loop 都容易变成"模型一直在忙"，但没人说得清它到底推进了什么。 代码场景最早跑起来，是因为代码有测试、构建、类型检查、lint、diff 这些外部裁判。日常工作流更麻烦，因为邮件、会议、群聊、内容草稿这些东西，很多时候没有硬标准。 放到架构设计里，我对 Loop 的看法会稍微保守一点。 Loop 的关键在于让系统更容易 验证、暂停、复盘和接手。 先用一张图把这层关系摆出来： 图 1：Loop 的位置 放回高可靠架构，它并不陌生 如果把产品名先放一边，Loop 不是一个陌生结构。 它更像把 Agent 放进一套高可靠运行体系里：有目标，有健康检查，有故障处理，有恢复策略，有人工接管，也有成本和容量边界。 这条线，云架构、SRE、微服务这些年已经讲过很多遍。 AWS Well-Architected 的可靠性支柱讲自动故障恢复、恢复流程测试、容量管理。Google SRE 把可靠性落到 SLO 和错误预算上，用延迟、流量、错误、饱和度这些信号观察系统。Azure 架构中心讲熔断、重试、隔舱、健康检查。 换到 Agent Loop 里，这些老办法并不过时。只是对象变了：以前我们保护的是服务和数据链路，现在还要保护一段会自己调用工具、生成动作、更新状态的执行过程。 高可靠问题 放到 Loop 里怎么理解 SLO / 错误预算 允许多少失败、返工、误判和人工兜底 健康检查 每轮是否有证据，工具是否可用，结果是否还在变化 超时 / 重试 / 熔断 一轮跑多久，失败重试几次，什么时候 该停 隔舱 / 配额 任务、工具、账号、数据权限、token 和并发要隔开 降级 / 补偿 结果不可信时，退回草稿、建议或人工确认 可观测 留下输入、动作、工具调用、结果、错误和 证据链 这么看，Loop 的重点不在"会重复执行"。 重复执行太容易了，脚本、定时任务、工作流引擎都能做到。 更要盯的，是这个循环在失败时怎么表现：会不会无限重试，会不会打爆依赖，会不会把小错写进真实系统，会不会让人完全不知道它刚才做了什么。 这也是 Claude、Codex、Mira 放在一起看有意思的地方。它们入口不同，但都在把 AI 放进一个更长期、更真实的运行环境里。到了这一步，问题就变成了：它能不能可靠地自动做事。 状态机比聊天记录可靠 很多 Agent Loop 早期看起来像一段很长的对话：模型读上下文，决定下一步，调用工具，再把结果塞回上下文。 这个形态跑 demo 很顺，放到工程里就会遇到几个老问题。 步骤依赖藏在聊天记录里，谁先谁后不够清楚。失败恢复靠模型临场判断，容易一轮轮重试。执行历史不断被改写，出了问题很难复盘。 2026 年那篇《From Agent Loops to Structured Graphs》提到的方向，正好提醒了这一点：当 Loop 变长以后，控制流最好不要只藏在上下文里，而要尽量外置成可检查的结构，比如静态图、状态机或工作流。 这也可以和此前整理《Harness之后：Agent可靠性的关键，是状态边界和失败闭环》放在同一条线上看：长任务麻烦的地方，不只是模型能不能想出下一步，更是系统能不能分清哪些只是候选动作，哪些已经验证，哪些已经写进了真实世界。 我不觉得每个团队都要立刻上复杂 DAG。先把关键状态说清楚，尤其是失败状态，就已经很有帮助。 比如一个最小可用的 Loop，可以有这些状态： 待触发 -> 运行中 -> 等待验证 -> 验证通过 -> 完成 | -> 验证失败 -> 重试 | -> 风险超界 -> 交还给人 | -> 无新增证据 -> 停止 放成状态图会更直观： 图 2：一个最小 Loop 的状态机 有了状态机，失败就不再是一句含糊的"没做好"。它可以被拆成验证失败、工具失败、风险超界或没有新增证据。下一步是重试、降级、停止，还是交给人，也就有了依据。 这和架构设计里面的熔断器思路是不是很像？ 服务连续失败时，熔断器不会继续把请求压上去，而是先打开熔断，让下游有时间恢复。过一段时间再半开，放少量请求试探；恢复了再关闭，没恢复就继续保护。 Loop 也需要类似机制。 连续几轮没有新证据，就别继续让模型"再试一次"。外部 API 已经限流，就别让十个 Agent 一起重试。写权限开始碰生产数据，就别再自动闭环。 这听起来不如"自动完成任务"酷，但对生产系统很重要。 系统出问题时，更值得看的不是模型当时"想了什么"，而是它处在哪个状态，拿到了什么证据，为什么进入下一步。 先别把 Loop 想大 写代码时，很多人已经从"一句句提示词"走到"让 Agent 按循环推进任务"。 这件事容易被误读成"以后不用写 prompt 了"。 我的理解不是这样。 Prompt 没有消失，只是位置变了。过去它是一句临时输入： 帮我总结一下这封邮件。 到了 Loop 里，它更像一段运行协议： 当新邮件满足这些条件时， 读取这些字段， 按这个标准判断优先级， 把摘要写到这里； 如果涉及合同、付款、客户投诉， 停止并提醒我。 这仍然是提示，只是它开始和触发、权限、工具、状态、验证、预算、停止条件绑在一起。 早一点的 Agent 研究，其实也一直在讲这条线。 ReAct 讲的是推理、行动、观察交错进行。Reflexion 讲的是把反馈写成文字记忆，影响下一轮尝试。Voyager 讲的是在环境反馈中积累技能。2026 年那篇《From Agent Loops to Structured Graphs》则提醒我们：普通 Agent Loop 容易把步骤依赖藏在上下文里，失败恢复也可能没有边界。 这些东西合在一起看，Loop 并不神秘。 它还是那个老问题：模型行动之后，环境返回了什么，系统又怎样把这份反馈变成下一步。 Claude 和 Codex 为什么先在代码里跑起来 Claude Code 的 /goal、/loop，Codex 的 /goal，看起来都是新命令。拆开看，最有价值的还是一件事：完成条件能不能被证据证明。 一个模糊目标是： 帮我优化一下 auth 模块。 更稳的目标会写成： /goal auth 相关测试全部通过，lint 干净， 改动只限 src/auth 和 tests/auth， 无法继续时汇报阻塞原因。 后者的差别不在语气，而在边界：范围被限定住，验收可以用测试和 lint 证明，失败时也有地方停下来，不会把半成品说成完成。 这就是代码 Loop 先成熟的原因。代码天然有测试、构建、类型检查和代码审查，很多反馈可以直接从环境里拿回来。 如果测试不通过，Loop 不能继续自信地写总结。如果连续几轮没有新增证据，它也不该继续耗着。每一轮有没有产生新证据，比它写了多少过程说明更重要。 这和前面整理《Loop Engineering实用指南：先写刹车，再写循环》是一条线。先有刹车，再谈循环。先有证据，再谈自动化。 从经典架构看，代码场景还有一个优势：它的"传感器"很成熟。 测试、类型检查、lint、CI、diff、PR review，都是现成的反馈层。工具调用以后，环境很快给出结果。通过就是通过，失败就是失败，中间空间相对少。 这也是为什么 /goal 这类能力在代码里更容易讲清楚。它的价值不在于让模型一直努力，而在于把目标写成可验证条件，让 Loop 有机会围绕证据往前走。 代码 Loop 可以粗略看成这样： Goal -> Plan -> Change -> Test/Build/Lint -> Diff Review -> Continue or Stop 这里更有价值的是后半段：验证和审查。 没有 Test/Build/Lint，前面的规划再漂亮，也很难证明它没有跑偏。 Mira 这类入口把问题带到日常工作流 Loop 不只会发生在 IDE 里，也会发生在聊天、邮件、日程和协作文档里。 这类入口看起来更接近日常工作：人说一句话，Agent 记住上下文，协助拆任务、写草稿、整理日程、同步文档，甚至连到 Gmail、GitHub、Notion 这些工具。 这件事值得关注。但我更关心的是，入口变轻以后，工程边界会不会被一起变轻。 代码 Loop 面对的是仓库、测试、构建和 PR。 日常 Loop 面对的是邮件、日程、群聊、会议、承诺、账号、隐私和人际关系。 这两类场景最大的差别，是反馈强度。 代码测试失败就是失败。会议纪要"好不好"、邮件回复"得不得体"、内容计划"有没有价值"，经常没有一个机器能立刻判定的硬标准。 所以日常 Loop 不能简单照搬代码 Loop。它要分级。 任务类型 更稳的做法 日程摘要、未读整理、群聊要点 可以自动生成，但保留来源 会议纪要、邮件草稿、工单初稿 先出草稿，人确认后使用 对外承诺、付款、删数据、改权限 默认不自动闭环，只准备依据 这个表不复杂，但能挡住不少风险。 这里的差别可以再压成一张图： 图 3：代码 Loop 和日常 Loop 的差别 日常 Loop 第一版不用追求"像人一样处理一切"。能少漏事、留证据、可撤回、能接手，就已经有价值。 架构上看，Mira 这类入口把另一个问题推到前台：聊天正在成为工作流入口。 过去我们做系统，通常会先设计页面、表单、流程和权限。现在很多动作可能从一句聊天开始：整理会议、生成任务、更新文档、提醒日程、同步工单。 入口变轻了，后面的约束没有消失。甚至更麻烦。 一个日常工作流 Loop，至少要把传统系统里的几件事补回来：权限边界要清楚，审计记录要可追溯，重复触发不能制造重复动作，发错、删错、改错以后要能补偿。涉及对外承诺、付款、删数据这类动作时，还要明确在哪一步交还给人。 是不是很熟悉？ 这些不是 AI 时代才有的新问题，都是经典业务系统里的老问题。 只不过过去它们藏在服务端、审批流和数据库事务里；现在被聊天入口重新暴露出来了。 先用一个小筛子 一个任务适不适合做 Loop，不用一上来就讨论模型和平台。 我通常先问四个问题：它是不是重复发生，流程是不是相近；有没有测试、规则、审批、日志或人工复核这类反馈；出错后能不能撤回；每轮输入、动作、证据和未确认事项能不能留下。 前两个条件不满足，先别急着做 Loop。普通提示词、脚本或人工流程可能更划算。后两个不过，就别急着自动闭环，先让 Agent 只做整理、草稿和建议，把最终动作留给人。 这个筛选不复杂，但能挡掉很多看起来先进、实际很难收拾的自动化。 再往系统层看，触发、状态、验证、权限、补偿和成本要提前写清楚。触发最好先手动，再定时，最后才接事件；状态不要只留在聊天记录里；验证尽量交给测试、规则、审查人或独立 verifier；权限默认只读，确认稳定后再逐步开放写能力。 工具会变，但这些问题不会变。 如果团队真的要长期运行 Loop，我还会给它单独建一组"黄金信号"。这和《Cursor 的 Harness 方法论》里那条线很近：Agent 质量不能只看模型分数，还要看真实流程里的退化、错误、保留率和可回滚性。 不一定照搬 Web 服务的指标，但思路类似： 传统 SRE 信号 Loop 里可以怎么量 延迟 单轮耗时、从触发到交付的总时间 流量 每天触发多少次、并发多少个 Loop 错误 验证失败率、人工打回率、工具调用失败率 饱和度 token 消耗、队列积压、API 配额、人工审核积压 这些信号没有，就很难谈高可靠。 因为团队不知道它是在稳定交付，还是在稳定消耗。 从一个小 Loop 试起 如果明天要在团队里落一个 Loop，我不会从"全自动开发"开始。更稳的起点，是一个低风险、重复、可复核的小任务。 比如：每天早上整理昨天的 CI 失败和相关 PR。 第一版可以写得很窄： 名称：每日 CI 失败分流 触发：每天 9 点运行一次 输入：失败 job、相关 PR、日志摘要、当前 open issue 动作：归类失败原因，生成处理建议 限制：只写 triage 文档，不直接改代码 验证：每条结论需要带日志片段或 PR 链接 停止：处理完、超过 30 分钟、找不到证据 交还：涉及回滚、删测试、生产配置时只给建议 这不酷，但能用。 它知道自己看过什么、做过什么、哪些地方没把握，也知道什么时候停。出了问题，人能接上，不用重新翻一遍聊天记录。 很多团队缺的未必是更聪明的 Agent，更常见的是这种朴素的运行账本。 这也正好接上《长周期 Agent 详解：从 Ralph Loop 到可接管 Harness》那篇。Memory 记录的是过去发生过什么；运行账本和 Skill、Runbook 这类过程资产，记录的是"这类事以后怎么做、怎么验、怎么停"。 可以更简单一点，每轮只记五项： 本轮输入： 执行动作： 证据链接： 未确认事项： 是否继续： 有了这五项，Loop 才有机会从个人玩法变成团队资产。 再往前走一步，可以把它拆成三层，不一上来做成"大而全"的 Agent 平台： 第一层：运行账本 记录输入、动作、证据、未确认事项、下一步。 第二层：验证接口 把测试、日志、规则、人工复核接进来。 第三层：触发入口 最后再接定时任务、Webhook、群聊消息或工单事件。 这个顺序看起来不新鲜，但很稳。 很多团队想先做第三层，因为它看起来最像自动化。我的经验刚好相反：账本和验证没打牢，触发越自动，事故越难查。 最容易出问题的是跳级 Loop 失败，很多时候未必是模型不够强，更可能是团队跳级了。 一次手动运行还没稳定，就上定时。 人工都验不清楚，就让模型自评。 权限边界还没写，就接真实工具。 预算、日志、停止条件都没有，就开始并行跑多个 Agent。 更稳的顺序是： 1. 先让一次手动执行稳定； 2. 把规则沉淀成 Skill、Runbook 或项目文档； 3. 加上验证和停止条件； 4. 最后再接定时、事件和外部工具。 所以在工程里看 Loop，它更像 Harness 和 Environment 之间的一层反馈接口。 Harness 规定 Agent 怎么跑。 Environment 返回真实世界的变化。 Loop 决定这些变化怎样进入下一轮，什么时候不该继续。 这里还有一个容易忽略的点：Loop 不一定非要做成开放式。 开放式 Loop 让模型自己选路径，适合探索未知问题。闭合式 Loop 先把步骤、验收和停止条件写清楚，适合生产任务。 放到真实系统里，默认先选闭合式会更稳。 因为它的成本更可控，权限更容易收住，失败也更容易定位。等团队知道哪些环节稳定、哪些地方还要人判断，再局部打开空间。 人的位置会变，但不会消失 聊 Loop Engineering 时，最容易被误解的一点是：人是不是要退出工作流了。 我不这么看。 人的位置没有消失，只是从"每一轮都亲自推动"，慢慢挪到"设计规则和看结果"。 以前人站在每一轮对话里，告诉模型下一步做什么。现在人更多是在 Loop 外面，设计它能看什么、能做什么、怎么判断、怎么停、怎么留证据。 这对做工程的人反而提出了更高要求。 一段 prompt 写得差，通常只会得到一次差结果。 一个 Loop 设计得差，会稳定地产生差结果。如果它还接了外部工具，差结果就可能被写回真实系统。 Addy Osmani 有句提醒我很认同：done 只是一个声明，不是证明。 放到我们自己的工作里，可以换成一句更普通的话： 别只看 Agent 有没有说完成，还要看证据能不能证明完成。 写在最后 Loop 值得认真看，是因为它把 AI 从"一次回答"推到了"持续工作"。 但我的理解会更保守一些：Loop 不等于"AI 可以自己把所有事做完"。它更像一种把重复工作变成反馈系统的方式。 这个系统好不好，不取决于它用了 Claude、Codex 还是 Mira。更关键的是几件很普通的事：输入是否清楚，权限是否克制，反馈是否可信，状态是否可追，失败是否能停，人是否还能接手。 这些问题回答得清楚，Loop 才值得跑起来。 回答不清楚，先别急着自动化。 Prompt 是一句话，Harness 是工作台，Environment 是工作现场。Loop 夹在中间，负责让工作持续发生，也负责在该停的时候停下来。 从高可靠架构看，它更像一个小型工作流引擎，也像一套需要 SLO、限流、熔断、隔离和可观测的运行系统。 只是这一次，调度器里多了模型，执行器连到了真实工具，状态里混进了上下文和记忆。 这是我最近看 Loop 最想留下的一点。