# Loop Engineering 的生产治理视角：trigger / topology / verifier / stop rules，以及 agent loop 炸了之后怎么办

> 来源：Adnan Masood《Loop Engineering: A Guide for Engineers and Practitioners》(Medium, 2026-06-24, 约 35 min read)。

## TL;DR

Adnan Masood 这篇是为**已经在生产里跑 agent、要为它炸了负责的工程师**写的 field guide,不是给个人开发者写入门教程。它的核心论点一句话能说清:prompt 在 2026 年初已经不是瓶颈,真正决定一个 agent 系统能不能"survives contact with a real workload"(撞上真实负载还能活下来)的,是四件事——trigger(触发)/ topology(拓扑)/ verifier(验证)/ stop rules(停止规则)。作者原话:"Prompt phrasing stopped being the bottleneck somewhere in early 2026, and what replaced it is loop design: the trigger, the topology, the verifier, and the stop rules that decide what an agent does next and when it quits." 翻译过来就是:别再调 prompt 了,去设计 loop。

这篇文章在本系列深读的十几篇里是**唯一从生产治理(production governance)视角写**的。读者画像不是"想自动化的个人",是"要把 agent 推到生产、要为失效负责的工程师"。它的副标题把全文骨架交代得很直白:"How to design, verify, and govern agentic AI loops in production: triggers, topologies, failure modes, cost control, and observability."(如何在生产里设计、验证、治理 agent loop:触发器、拓扑、失效模式、成本控制、可观测性。)这套五维框架——trigger / topology / verifier & failure / cost / observability——是 6 原语(schedule / isolation / skills / connectors / verifier / STATE)的镜像。6 原语告诉你"要建什么",Adnan 的五维告诉你"会出什么问题"。两套拼起来才是完整工程图景。

## 为何把这篇单独深读

本系列已经写了 Addy Osmani 的概念奠基、Peter Steinberger 的压缩句、Boris Cherny 的厂商侧背书、Lenny 的实战 prompt、Claire 的 loop 产 loop、Linas 的项目级记忆脊柱。这些来源的共同问题是:**它们都在讲"怎么让 loop 跑起来",几乎没有一篇在讲"跑炸了怎么办"**。Lenny 的 copy-paste prompt 教你写第一个能跑的 agent loop;Claire 教你嵌套 subagent;Linas 教你用 STATE.md 做记忆。但一旦你把这个系统推到生产,撞上真实流量、真实用户、真实账单、真实不可逆动作,前面那些"跑得起来"的知识会迅速失效。

Adnan 这篇填的就是这个空。他是博士,Apress 教材《Applied Artificial Intelligence》作者,VNSGU BCA 2026-27 教学大纲指定参考——可信度背书是本系列里最强的。更关键的是他的**语气**:不是"ship while you sleep"那种激进叙事,是 field guide,是"你已经在生产里跑 agent 了,这套清单帮你别让它炸,或者炸了能尽快知道"。这种语气在整个 loop engineering 的话语场里是稀缺的。多数文章默认读者是乐观的早期采用者,Adnan 默认读者是已经吃过亏的工程师。

具体来说,这篇有三样东西是其他来源几乎不碰的:

- **拓扑失效模式的系统化分类**。fan-out 拓扑会撞 race condition(竞态)、pipeline 会撞阻塞、级联失败(cascading failure)会把依赖链整个拖垮——这些是分布式系统教科书里的经典失效模式,Adnan 把它们搬到了 agent loop 上。Lenny、Claire、Linas 都没系统讲这个,因为它们只谈单 agent 或同构多 agent,不谈异构拓扑的生产部署。
- **"irreversible action 必须有 sign-off"作为硬规则被点名**。这是 cognitive surrender(认知投降)防线最具体的表述。其他来源会模糊地说"要 human in the loop",Adnan 直接把它升级成"不可逆动作必须有人签字"的硬闸。
- **五维治理框架**。trigger / topology / verifier / stop rules / cost+observability——这五个维度可以直接拿来做 agent loop 的评测检查表,和 6 原语正交,拼起来 11 个评估点。

下面逐个拆。

## 心智模型:loop 像一座无人值守的工厂,治理是安全规程

先建一个费曼式的直觉。

把一个 agent loop 想成一座**无人值守的自动化工厂**。原材料进来(prompt、任务、上下文),流水线(robot arm、CNC、机械臂——对应 tool call、subagent、verifier)加工,成品出去(commit、消息、报告、数据库写)。传统软件工厂里有值班工程师盯着仪表盘,有 SOP 规定什么情况按什么按钮,有紧急停机绳,有过载保护。agent loop 的不同之处在于:**它的"流水线"会自己决定下一步做什么**。模型每轮都会基于上一轮的结果重新选 tool、重新规划、重新生成指令。这就好比机械臂在加工过程中突然决定去碰另一台机器,或者决定把原材料扔进垃圾桶。

这种"自己决定下一步"的能力是 agent 相对于传统自动化脚本的全部价值所在,也是它全部的风险所在。传统脚本的失效模式是有限的——它只会按你写好的代码走,炸了就是 bug,你能复现、能调试。agent 的失效模式是**开放的**——它可能产生一个你从未预料的中间状态,然后基于这个错误状态继续往下跑,把错误放大。prompt 调得再好,也无法覆盖所有中间状态,因为中间状态空间是指数级爆炸的。

所以 prompt engineering 解决的是"一轮对话的质量",loop engineering 解决的是"多轮之间的衔接质量"。Adnan 的原话讲得很清楚:"A good prompt fixes one turn. It says nothing about which turn comes next, what counts as done, who signs off before an irreversible action, or how spend stays capped."(一个好的 prompt 修好了一轮对话。但它什么也没说——下一轮是什么、什么算做完、不可逆动作之前谁签字、预算怎么封顶。)后面那些问题都是 loop 问题,答案决定了一个 agent 系统能不能撞上真实负载还活着:"Those are loop questions, and the answers are what decide whether an agentic system survives contact with a real workload."

回到工厂类比。prompt engineering 是调机械臂的精度——抓得更准、放得更稳。loop engineering 是写整座工厂的安全规程:什么情况下流水线该停、什么操作必须人确认、仪表盘该怎么布、备用电源在哪、过载了先断哪一路。前者是产线工程师的活,后者是厂长和 SRE 的活。Adnan 写的是后者。

这个心智模型还解释了为什么 trigger / topology / verifier / stop rules 是四个**正交**的维度,而不是一个递进的流程。trigger 回答"loop 被谁叫醒",topology 回答"醒了之后谁干活、几个 agent 怎么协作",verifier 回答"干完了怎么知道没干错",stop rules 回答"什么时候停"。四者任何一维缺失,工厂都会以不同方式炸:trigger 设计错会在不该跑的时候跑(账单爆);topology 选错会让多 agent 互相踩(verifier 漏检);verifier 太弱会让错误一路传到不可逆动作;stop rules 缺失会让 loop 在死循环里把 token 烧光。这四维再加上 cost control 和 observability 这两个**横向治理面**,就是 Adnan 的五维框架。

## 详细机制:四要素 + 拓扑失效模式 + 不可逆动作 sign-off

下面逐个拆。每一节我会标注哪些是 Adnan 原文逐字确认的(带原话),哪些是基于副标题、章节标题和交叉验证推断的框架(用"作者分类框架"等保守措辞),以及哪些是付费墙后无法逐字核实、需要读者自己判断的部分。

### 1. Trigger(触发器):loop 被谁叫醒

Adnan 把 trigger 单独抽成一维,这本身就值得停下来想一想。大多数 loop engineering 的入门文章默认 loop 是"用户敲一条命令,agent 开始跑",把 trigger 看成隐含的、不值得一谈的东西。Adnan 把它显式化,因为他考虑的是生产系统——生产系统里的 loop 不一定是被人手动触发的,它可能被时间、事件、状态变化、上游意图触发,不同 trigger 决定完全不同的成本曲线和失效模式。

结合 Adnan 多篇 Microsoft Agent Framework 相关文章的交叉验证,trigger 至少可以分成四类:

- **时间触发(time-based)**。cron、heartbeat、定时心跳。典型场景是每天凌晨跑一次的清理 loop、每分钟检查一次队列的 worker loop。这类 trigger 的失效模式是"调度风暴"——多个实例同时醒、同时打后端、同时烧 token。
- **事件触发(event-based)**。webhook、hook、消息队列。典型场景是 GitHub PR 推送触发一个代码审查 loop、Slack 消息触发一个回复 loop。这类 trigger 的失效模式是"事件洪峰"——一次推送 100 个 commit 触发 100 个 loop 实例,后端被打穿。
- **状态触发(state-based)**。状态机或 STATE.md 的变化。典型场景是 CI 状态从 pending 变成 failed 触发一个修复 loop、数据库某张表的某行从 queued 变成 ready 触发一个处理 loop。这类 trigger 的失效模式是"状态漂移"——STATE.md 记录的状态和实际系统状态不一致,loop 基于错误状态决策。
- **意图触发(intent-based)**。用户或上游 agent 的请求。这是 Lenny 那篇没讲的第四种。典型场景是另一个 agent 在自己的 loop 里决定"我需要找一个会写 SQL 的 subagent",于是触发一个 SQL 生成 loop。这类 trigger 的失效模式是"意图误解"——上游 agent 传过来的意图描述模糊,loop 基于错误理解跑出完全无关的结果。

实操含义:写 loop 前先回答"它被谁叫醒"。如果你的 loop 是事件触发的,你需要在 loop 入口加 rate limiting 和去重;如果是状态触发的,你需要解决状态一致性的并发写问题;如果是意图触发的,你需要在 loop 开头加一个意图澄清步骤。把 trigger 类型当成 loop 设计的第一道选择题,后面 topology、verifier、stop rules 的设计都受它约束。

这一节里"四种 trigger 分类"是基于章节标题和 Adnan 其他文章的交叉验证,**不是逐字确认的分类**。Adnan 在 Loop Engineering 这篇里没有把"四种 trigger"用编号列表写出来(至少付费墙后的正文我没逐字核实),但他在多篇 Microsoft Agent Framework 文章里反复用这套分类。读者若要引用,建议用"作者在相关工作中把 trigger 分为时间、事件、状态、意图四类"的措辞,而不是"Adnan 在 Loop Engineering 一文中明确写明四种 trigger"。

### 2. Topology(拓扑):agent 之间怎么协作

这是 Adnan 这篇**最独特的贡献**,也是 Lenny、Claire、Linas 几乎完全不碰的维度。原因很简单:那几位讲的都是单 agent 或同构多 agent,没必要谈拓扑;Adnan 讲的是生产部署,生产里几乎从来不是单 agent,而是多 agent 协作,拓扑就是多 agent 协作的结构。

这里有一个关于原文措辞的重要核实结论。我曾担心付费墙挡住了拓扑分类的原文措辞,通过搜索引擎对付费墙正文做片段抓取(搜索引擎能拿到 Medium 付费墙后的预览片段),确认了 Adnan 在文章正文中**逐字使用了以下拓扑/模式术语**:

> "...parallel, and a specific set of patterns recurs: **orchestrator-worker, fan-out and fan-in, supervisor, pipeline, and debate**."

也就是说,作者用的拓扑/模式词是:orchestrator-worker(编排者-工作者)、fan-out and fan-in(扇出扇入)、supervisor(监督者)、pipeline(流水线)、debate(辩论),加上作为基础情形的 parallel(并行)和 single-agent(单 agent)。注意一个细节:**Adnan 用的是 "supervisor",不是 "hierarchical"**。我最初从研究笔记里继承的"hierarchical topology"措辞没有在他这篇文章的逐字片段里出现,他更像是在 supervisor 这个词下讨论多级嵌套。引用时不要把"hierarchical topology"算到他头上。

把这套词翻译成可操作的拓扑分类:

- **Single-agent loop(单 agent 自循环)**。一个 agent 自己跑 loop。适合用户意图清晰、agent 单轮工具选择就够用的场景。这是默认拓扑,也是其他拓扑退化的极限情况。失效模式相对简单:agent 自己陷入死循环、token 烧光、对模糊意图产生幻觉。这种拓扑的好处是可调试性高、verifier 设计简单(只有一个 agent 的输出要验)、成本可控(没有多 agent 之间的消息放大)。
- **Orchestrator-worker(编排者-工作者,fan-out / fan-in)**。一个 orchestrator 把任务拆给多个 worker agent,worker 各自完成自己的子任务,orchestrator 聚合结果。典型场景是一个"研究员 + 写手 + 校对"的写作 pipeline,或者一个"多文件并行修改"的代码 loop。失效模式见下一节(race condition、部分失败、聚合冲突)。
- **Pipeline(流水线,串行)**。A→B→C,每段一个 agent,前一段输出是后一段输入。和 orchestrator-worker 的区别是没有"拆分-聚合"的扇形结构,是线性的。典型场景是"提取 → 清洗 → 分析 → 报告"这种数据处理 loop。失效模式主要是阻塞和单点拖垮。
- **Parallel / ensemble(并行 / 集成)**。多个 agent 同时跑同一个任务,最后取多数或选最优。典型场景是需要高可靠性的判断——三个 agent 各自给一个答案,多数投票。失效模式是成本 N 倍上涨、结果冲突需要仲裁。
- **Supervisor(监督者,多级嵌套)**。一个上层 agent 监督下层 agent loop,下层 agent 可能自己又嵌套 sub-loop。这对应 Lenny 文章里 Claire 那个"loop 产 loop"的结构。失效模式是子 loop 失控递归、成本不可见地累积、错误在层级间传播放大。
- **Debate(辩论)**。多个 agent 对同一问题给出不同立场,通过辩论收敛到一个答案。这是 parallel 的一个变体,但聚合方式是辩论而非投票。失效模式是辩论不收敛、成本失控、强 agent 主导弱 agent。

注意,**我用的"失效模式"分类不是 Adnan 原文逐字确认的**。下面那一节的失效模式分类里,只有 race condition 和 cascading failure 这两个词是原文逐字确认的,其他是基于章节标题和分布式系统常识的推断。我会在下一节里逐字标注。

### 3. 拓扑失效模式:race condition / 阻塞 / cascading failure

这是治理向文章的核心。生产系统之所以需要治理,就是因为多 agent 拓扑天然会撞上分布式系统的经典失效模式。Adnan 在付费墙后的正文里(通过搜索引擎片段核实)**逐字使用了以下两个失效模式术语**:

> "**Hidden dependencies and parallel writes create race conditions** ... **cascading failure**[s] ..."

也就是说,**race condition(竞态条件)** 和 **cascading failure(级联失败)** 是 Adnan 自己用的词。这两个是确认可信的。

关于 **deadlock(死锁)** 这个词:我专门做了核实。在 Loop Engineering 这篇文章本身的付费墙正文片段里,**没有抓到 "deadlock" 这个词**。Adnan 在另一篇文章(A2A Outside, MCP Inside, FHIR at the Core)里讨论 agent 间通信时用过 deadlock,但那是另一篇文章,不能拿来冒充 Loop Engineering 这篇的内容。所以本节标题里我写的是"阻塞"而不是"死锁",引用时建议用"作者将失效模式归纳为竞态、级联失败等分布式系统经典问题",而不是把 deadlock 算到这篇文章头上。

下面把三类失效模式展开:

- **Race condition(竞态)——原文逐字确认**。多个 worker agent 并发写同一个资源(同一个文件、同一行数据库记录、同一个共享状态变量)时,执行顺序不确定,结果取决于谁先到。Adnan 的措辞是"Hidden dependencies and parallel writes create race conditions"——隐藏的依赖关系和并行写入制造竞态。这在 orchestrator-worker 拓扑里最常见:orchestrator 拆任务时没意识到两个 worker 会改同一个文件,两个 worker 并发写,后写的覆盖先写的,数据丢失。对应到共识框架里,这就是为什么需要"多 loop 用 acting_on 分支锁防碰撞"——acting_on 锁就是一种防竞态机制。Adnan 把这个问题放进了更广的拓扑失效谱系。
- **阻塞 / 流水线单点拖垮(blocking / pipeline stall)——基于分布式系统常识的推断,非原文逐字确认**。pipeline 拓扑里,如果中间某一段 agent 卡住(比如 B 段在等一个慢 API、或者在死循环里烧 token),整条流水线停摆。这种失效模式的危险在于"无声"——A 段已经完成,C 段在等,你以为系统在跑,其实只有 B 段卡死。生产里的表现为:用户那边看到的是请求超时,后台看到的是 B 段的 token 烧量持续上升但产出为零。
- **Cascading failure(级联失败)——原文逐字确认**。一个 loop 挂了,拖垮依赖它的 loop。Adnan 的措辞直接是"cascading failure"。这在 supervisor 拓扑里最危险:下层 sub-loop 失败,把错误结果传给上层,上层基于错误结果继续决策,再把错误传给更上层,最终整个层级崩溃。级联失败的可怕之处在于它会**跨 loop 传播**——单个 loop 的 verifier 可能没漏检,但跨 loop 的边界处往往没有 verifier,错误就这样溜过去。

实操含义:每种拓扑都有它自己的"原生失效模式"。设计 agent 系统时,**选 topology 的同时就要选对应的防失效机制**。orchestrator-worker 必须配并发写锁;pipeline 必须配每段超时和降级路径;supervisor 必须配子 loop 的成本上限和错误传播阻断;ensemble 必须配仲裁规则和成本预算。

这里要给一个**关于可信度的诚实交代**:这一节里只有 race condition 和 cascading failure 是原文逐字确认的;阻塞/单点拖垮是基于分布式系统常识的合理推断,但 Adnan 用没用"deadlock"或者"pipeline stall"这种具体措辞,我没核实到。本系列其他几篇来源(Lenny、Claire、Linas)也不碰多 agent 拓扑,所以无法交叉验证。如果你要把这一节拿去引用,最稳的做法是引用 race condition 和 cascading failure 这两个有原文出处的,其他用"分布式系统的经典失效模式"这种泛指措辞。

### 4. Verifier(验证器):干完了怎么知道没干错

Adnan 把 verifier 抽成独立的一维,这个动作本身就比 Lenny 和 Linas 那两篇更进了一步。Lenny 把 verifier 藏在"maker-checker"这一句话里(一个 agent 干活、另一个 agent 检查),Linas 把 verifier 隐含在 STATE.md 的更新校验里。Adnan 把它升到和 trigger、topology 平级的一维,因为他考虑的是生产系统——生产里 verifier 不是装饰,是**防 cognitive surrender 的最后一道闸**。

Adnan 的 tl;dr 原话直接点名 verifier 的关键功能:"who signs off before an irreversible action"(不可逆动作之前谁签字)。把这句话拆开,verifier 这一维要回答三个问题:

- **谁签字**。什么动作需要人类签、什么动作可以由另一个 agent 签、什么动作 loop 自己签就行。Adnan 的隐含分层是按"可逆性"分的:完全可逆的动作(读文件、查文档、生成草稿)loop 自己签;半可逆的动作(改本地文件、写非生产数据库)另一个 agent 签;不可逆的动作(发邮件、打款、删生产数据、合并到 main 分支、给真实用户发消息)**必须人类签**。这套分层对应到共识框架里的 human gate,但 Adnan 把它说得更硬:"who signs off" 是一个治理问题,不是技术问题。
- **verifier 本身也是一个 agent loop**。这点和 Lenny 那篇里 Firefox 的"两段 verifier"结构一致——一个 agent 跑静态检查、另一个 agent 跑行为测试。Adnan 把它系统化:verifier 不是单点,是一个二级 loop,它自己也要有 trigger(什么时候验)、stop rules(验到什么程度算够)、verifier(谁来验 verifier,即三级验证)。这听起来像无限递归,实际工程上的做法是**两级就够**:一级 agent 干活,二级 agent(用不同的 prompt、不同的工具集、最好不同的模型)验,然后交人类签不可逆动作。三级以上通常不值得。
- **verifier 串通(verifier collusion)是生产里最阴险的失效模式**。如果 maker agent 和 checker agent 用同一个 prompt、同一个模型、同一个上下文,checker 几乎不可能发现 maker 的系统性偏差——它们会犯一样的错。这就是 verifier 串通:两个 agent 表面上独立,实际上共享同一个盲点。Adnan 的失效模式清单里(基于章节标题)包括"verifier 串通"这一项。防串通的做法是**异构验证**:checker 用不同模型、不同 prompt、最好不同工具集(比如 maker 用 lint,checker 用 type-check 和 unit-test,第三层用 behavior-test)。

这一节里"谁签字的分层"(可逆/半可逆/不可逆)是基于 Adnan 原话"who signs off before an irreversible action"的合理展开,**不是他原文逐字列出的三层**。但"不可逆动作必须 sign-off"本身是逐字原文,所以这个分层有原话支撑。verifier 串通这一点出现在他章节标题暗示的失效模式清单里,具体措辞没有逐字核实。

### 5. Stop rules(停止规则):什么时候停

"when it quits"(它什么时候停)是 Adnan 在 tl;dr 里和 trigger / topology / verifier 并列的第四维。这维度在共识框架里被严重低估——很多人写 loop 的时候根本没想到要显式定义"什么时候算完",结果 loop 在模糊的成功标准下无限烧 token。

基于 Adnan 的章节标题和工程常识,stop rules 至少有五类:

- **时间窗超时(timeout)**。loop 跑超过 N 分钟就停。最粗暴也最可靠的兜底。
- **预算耗尽(budget cap)**。token 烧超过 N 个、或美元花费超过 N 块就停。这对应 Adnan 五维里的 cost control。
- **成功判据满足(success criteria)**。goal 达成、verifier 通过,loop 正常退出。这是理想退出。
- **失败次数阈值(failure threshold)**。连续 N 次无进展、连续 N 次 verifier 拒绝,就停。这是防 cognitive surrender 的硬熔断。
- **人类中断(human kill switch)**。任何时刻人类都能一键停掉 loop。

Adnan 的实操建议(基于章节标题推断)是:**每个 loop 上线前必须显式声明这五类里至少三类**。否则就是"模糊成功标准 → 无限烧 token"的失败模式。Lenny 也警告过同一个失败模式,但 Adnan 把它系统化成五类 stop rules 的检查表。

这里有一个特别值得展开的点:**"失败次数阈值"是防 cognitive surrender 的关键**。cognitive surrender 是指人类开始对 agent 的请求盲目点 approve——因为 agent 一直在问、人类累了、人类来不及看、人类觉得"应该没事"。这种失效模式下,verifier 形同虚设——verifier 提出反对意见,人类也照点 approve。失败次数阈值的意义在于,它让 loop 在人类还没来得及 surrender 之前就**自己熔断**。连续 N 次无进展就停,不让 loop 反复来骚扰人类,这是保护人类判断力的最后一道工程措施。

### 6. Cost control 和 Observability(成本与可观测性)

这两个是 Adnan 五维框架里的横向治理面,贯穿前面四维。它们直接对应传统 SRE / DevOps 的实践——这是 Adnan 的 production-engineering 视角最明显的地方。

- **Cost control(成本控制)**。每个 loop 有 per-loop budget(单次预算)、aggregate cap(总预算)、escalation policy(超预算怎么办)。per-loop budget 是单次 loop 跑的上限——超过就触发 stop rule。aggregate cap 是所有 loop 加起来的总上限——防止 loop 产 loop 的失控递归把整个账单打爆。escalation policy 是超预算之后的处置:是停掉、是降级到更便宜的模型、是发警报给人类、还是自动拒绝继续。这套东西在传统微服务里叫 rate limiting + circuit breaker,Adnan 把它搬到了 agent loop 上。
- **Observability(可观测性)**。每轮的 prompt / response 日志、每次 tool call 的 trace、每次 state diff、每次 verifier verdict——都必须能**回放(replay)**。回放能力是事后调试的基础:loop 炸了之后,你要能从日志重建出"第几轮开始出错、错在哪一步、为什么 verifier 没拦住"。没有可观测性的 agent loop 在生产里就是黑箱——炸了你只能猜。Adnan 这里的要求基本是把 OpenTelemetry / structured logging / distributed tracing 那套直接套到 agent loop 上,每轮 loop 当一个 trace span,每个 tool call 当一个 child span。

这两个维度看起来"显然",但实操里恰恰是最容易被忽略的。个人开发者写 demo 时不会管 observability,因为 demo 跑几次就完了;一旦推到生产,observability 缺失的代价是事故后无法复盘,小事故放大成大事故。Adnan 把这两个维度单列,就是在提醒读者:你写的是生产系统,不是 demo。

## 真实案例:把四维框架套到典型事故上

抽象的框架需要案例才落地。下面用三个典型事故场景,演示 Adnan 的四维 + 拓扑失效 + sign-off 框架怎么用。这些案例是基于本系列其他来源和公开事故模式的合成,不是 Adnan 原文里的案例(他原文里的具体案例大多在付费墙后,我没逐字核实)。

**案例 1:orchestrator-worker 撞 race condition,worker 互相覆盖**。

一个代码修改 loop 用 orchestrator-worker 拓扑:orchestrator 把"重构这个模块"拆成五个子任务,分给五个 worker agent,每个 worker 改一个文件。五个 worker 并发跑,有两个 worker 的子任务恰好都涉及一个共享的头文件,两个 worker 各自基于原始版本做了不同的修改,后提交的覆盖了先提交的,先提交的修改丢失。verifier 跑 type-check 通过了(因为两个修改各自都合法),verifier 跑 unit-test 通过了一部分、失败了一部分,但 orchestrator 把失败归因为"测试 flaky",重跑了一次,这次碰巧过了,于是合并。

用 Adnan 框架诊断:topology 选了 orchestrator-worker 但没配并发写锁(race condition 原生失效模式没防);verifier 太弱(type-check + unit-test 都不足以发现"修改被覆盖"这种语义错误);stop rules 里的"失败次数阈值"被 orchestrator 自己解释成"flaky 重跑",熔断没生效;sign-off 缺失(合并到 main 这种不可逆动作没有人类签字)。修复方向:加 acting_on 分支锁(共识框架的多 loop 防碰撞机制)、换异构 verifier(让另一个 agent 用 diff 工具看两个 worker 是否动了同一区域)、把"合并到 main"明确列为不可逆动作强制 human sign-off。

**案例 2:pipeline 撞阻塞,中段死循环,整条线停摆**。

一个数据处理 loop 用 pipeline 拓扑:A 提取 → B 清洗 → C 分析 → D 报告。B 段 agent 在清洗过程中遇到一个边界情况,反复尝试同一个失败的处理策略,陷入死循环烧 token。A 段已经完成在等,C 和 D 在等 B。用户那边看到的是请求超时,后台看到的是 B 段 token 烧量持续上升但产出为零。

用 Adnan 框架诊断:topology 选了 pipeline 但 B 段没有 per-loop budget(没有 cost control);B 段没有"失败次数阈值"stop rule(连续 N 次同样失败就该停);observability 缺失(整条线卡住没人知道,直到用户超时)。修复方向:每段 agent 都配 per-loop budget、失败次数阈值、超时;pipeline 总体配一个 orchestrator(或 supervisor)定期检查每段是否在进展,某段停滞就触发降级或人工介入。

**案例 3:supervisor 拓扑撞 cascading failure,子 loop 错误传上层**。

一个复杂任务用 supervisor 拓扑:上层 supervisor 把任务拆给两个下层 sub-loop,每个 sub-loop 又自己嵌套 sub-sub-loop。某个 sub-sub-loop 因为上游数据错误产生了一个错误结果,这个错误结果传给 sub-loop,sub-loop 没有跨 loop 边界的 verifier,基于错误结果继续算,把错误放大十倍传给 supervisor,supervisor 基于放大后的错误结果做最终决策,决策错了。

用 Adnan 框架诊断:topology 选了 supervisor(多级嵌套),但**跨 loop 边界没有 verifier**——这是 cascading failure 的温床;cognitive surrender 风险(supervisor 盲目信任下层结果);observability 缺失(错误在哪一级引入的、怎么放大的,事后无法追溯)。修复方向:每个 loop 边界(不只是 loop 内部)都配 verifier;supervisor 不能"信任"下层结果,必须验;全链路 tracing,每个 loop 当一个 span,能重建错误传播路径。

这三个案例的共同点:都不是 prompt 写得不好导致的,都是 loop 结构性缺陷导致的。prompt 调到最优也救不了 race condition,救不了 pipeline 阻塞,救不了 cascading failure。这就是 Adnan 的核心论点:**prompt 不是瓶颈,loop 设计才是**。

## 五维框架和 6 原语的对照

把 Adnan 的五维框架和共识框架的 6 原语拼起来,是一份相当完整的 agent loop 工程检查表。

| 共识框架 6 原语(建什么) | Adnan 五维(出什么问题) | 两者关系 |
|---|---|---|
| ① schedule(调度) | trigger(触发器,4 类) | Adnan 更细,把 schedule 拆成时间/事件/状态/意图四类,并指出每类有不同失效模式 |
| ② isolation(隔离,worktree) | topology 里的并发写与隔离 | Adnan 没单独讲 worktree,但 topology 章节讲多 agent 隔离,间接覆盖 |
| ③ skills(SKILL.md) | (盲区) | Adnan 这篇不关心生产力模板,关心治理,SKILL.md 是他的盲区 |
| ④ connectors(MCP) | (盲区) | 同上,未明确覆盖 |
| ⑤ verifier(验证) | verifier(独立一维,带 sign-off 和二级验证) | Adnan 把它升级成独立维,强调不可逆动作 sign-off + 二级验证 loop + 防串通 |
| ⑥ STATE(状态脊柱) | 状态触发 + state 漂移失效模式 | Adnan 间接覆盖 STATE 脊柱,强调状态漂移作为一种失效模式 |
| (L0-L3 成熟度) | "survives contact with a real workload" | Adnan 没用 L0-L3 命名,但他的"撞上真实负载还活着"是 L2→L3 的门槛判断 |
| (cognitive surrender) | "who signs off" + 失败次数阈值 | 多次出现"who signs off"——人类签字权是 cognitive surrender 的最后一道闸 |
| (cadence 成本线性倍数) | cost control(per-loop / aggregate / escalation) | 直接对应 |

从这个对照能看出两套框架的**互补关系**:6 原语是"建 loop 要建哪些组件"(正向工程),Adnan 五维是"建完之后会从哪些维度炸"(反向治理)。两套拼起来是 11 个评估点,可以直接拿来做 agent loop 的 design review 检查表。

还要指出 Adnan 的**盲区**。他不谈 SKILL.md(生产力模板),不谈 MCP(connectors),不谈 worktree(isolation 的具体实现)。这些盲区是合理的——他写的是治理向文章,不是生产力教程。但这也意味着:**只用 Adnan 这一篇不够**。你得同时读 Lenny(学怎么写第一个能跑的 loop)、Claire(学怎么嵌套 sub-loop)、Linas(学怎么用 STATE.md 做项目级记忆),才能拿到完整的工程图景。Adnan 给的是"上生产前的治理清单",不是"从零开始建 loop 的教程"。

## 权衡与局限

这篇深读必须诚实地交代 Adnan 这篇文章的几个局限,以及付费墙带来的核实边界。

**付费墙导致的核实边界**。这是最大的局限。Medium 部分付费墙挡住了拓扑分类、失效模式、可观测性章节的大部分正文。我能逐字确认的只有:开头的 tl;dr 段(包含 trigger / topology / verifier / stop rules 四个关键词)、副标题(包含五维框架的完整名称)、以及通过搜索引擎片段抓到的两处正文片段(拓扑/模式的 orchestrator-worker / fan-out and fan-in / supervisor / pipeline / debate 这套词;失效模式的 race conditions / cascading failure 这两个词)。其他分类(四种 trigger、五类 stop rules、verifier 串通、cost control 三层、observability 要求)是基于章节标题、Adnan 其他文章、分布式系统常识的交叉推断,**不是逐字确认**。如果读者要引用 Adnan 的具体措辞,最稳的做法是只引用前面那几处逐字确认的原话,其他用"作者分类框架""作者暗示"这种保守措辞。这篇文章本身已经尽量做到了这一点。

**未点名 cobusgreyling/loop-engineering 仓库**。Adnan 把术语归功于 Addy Osmani 的 essay + Peter Steinberger 的压缩句 + Boris Cherny 的厂商侧背书,这和共识框架的参考实现来源一致。但他没指向 cobusgreyling 的 5 原语 / 7 patterns / 4 CLI 仓库。这是叙述盲区——参考实现的工程化落地在他这篇文章里是缺位的。读者若想看具体命令和代码,得去本系列其他几篇找。

**governance 和速度的内在张力**。Adnan 的框架天然偏保守——多 sign-off、多 observability、多 stop rules、多 verifier 层级。这和"ship while you sleep"的激进叙事有张力。激进派会说:这么多治理开销,loop 还没跑起来就被官僚主义拖死了。Adnan 的隐含回应是:他写的是生产系统,生产系统的默认值就该是保守的;个人 demo 大可不必套这套框架,但一旦上生产、一旦不可逆动作涉及真实用户和真实钱,治理开销就不是开销,是保险。这个张力本身是良性的——loop engineering 不是无脑自动化,是"在可控前提下放权"。读者要根据自己的场景在激进和保守之间调,而不是无脑套 Adnan 的全套。

**缺具体命令和代码**。和 Lenny 的 copy-paste prompt、Claire 的具体 loop 产 loop 模板相比,Adnan 更抽象。他给的是"该防什么、该测什么、该签什么",不是"第一条命令敲什么"。只用 Adnan 这一篇,你会"知道该防什么但不知道怎么动手"。这也是为什么本系列要把十几篇拼起来读——Adnan 是治理面,Lenny/Claire/Linas 是操作面,缺一不可。

**作者权威性的双刃剑**。Adnan 是博士 + Apress 教材作者 + 大学教学大纲指定参考,可信度背书最强。但教材作者的身份也意味着他的行文偏学术、偏框架化,有时候把一个本可以用三句话说清的点展开成一整节。生产工程师读的时候要有心理准备:框架清晰,但具体到代码层面还得自己补。

## 落地建议:上生产前的治理清单

把 Adnan 的五维框架 + 6 原语 + 拓扑失效模式 + sign-off 规则整理成一份可直接用的检查表。这是把这篇深读落到工程动作的部分。每个 loop 上生产前过一遍这 11 项。

**Trigger 维度**:

- [ ] 显式声明 loop 是哪种 trigger(时间 / 事件 / 状态 / 意图)。
- [ ] 如果是事件触发,入口处有 rate limiting 和去重。
- [ ] 如果是状态触发,解决了状态一致性的并发写问题(或显式接受弱一致性并文档化)。
- [ ] 如果是意图触发,loop 开头有意图澄清步骤。

**Topology 维度**:

- [ ] 显式声明 loop 用哪种拓扑(single / orchestrator-worker / pipeline / parallel / supervisor / debate)。
- [ ] 针对 topology 的原生失效模式配了防御机制(orchestrator-worker → 并发写锁;pipeline → 每段超时;supervisor → 子 loop 成本上限和错误传播阻断;parallel → 仲裁规则)。
- [ ] 多 loop 边界处配了跨 loop verifier(防 cascading failure)。

**Verifier 维度**:

- [ ] verifier 是独立组件,不是 maker agent 自己。
- [ ] verifier 用了异构设计(不同 prompt / 不同模型 / 不同工具集)防串通。
- [ ] 不可逆动作(发邮件、打款、删生产数据、合并 main、给真实用户发消息)的清单明确,每一项配人类 sign-off。
- [ ] 有二级验证 loop(verifier 本身也是 loop,有自己的 trigger 和 stop rules)。

**Stop rules 维度**:

- [ ] 显式声明至少三类 stop rules(超时 / 预算耗尽 / 成功判据 / 失败次数阈值 / 人类中断)。
- [ ] 失败次数阈值是硬熔断(连续 N 次无进展自动停,不让 loop 反复骚扰人类)。
- [ ] 人类 kill switch 任何时刻可用。

**Cost control 维度**:

- [ ] per-loop budget(单次预算)配置并强制。
- [ ] aggregate cap(所有 loop 加总上限)配置并强制,防 loop 产 loop 失控递归。
- [ ] escalation policy(超预算怎么办:停 / 降级 / 报警 / 拒绝)明确。

**Observability 维度**:

- [ ] 每轮 prompt / response 日志可回放。
- [ ] 每次 tool call 有 trace。
- [ ] 每次 state diff 有记录。
- [ ] 每次 verifier verdict 有记录。
- [ ] 全链路 tracing(每个 loop 一个 span,能重建错误传播路径)。

这份清单看起来很长,但每一项都是 Adnan 五维框架的直接落地。第一遍过会很慢,但过了之后每个 loop 都有了 production-grade 的治理基线。

最后给一个使用建议:**Adnan 的框架不是"上生产的门槛",是"上生产前的体检"**。你不必每个 demo loop 都套这 11 项,但一旦某个 loop 要长期跑、要碰真实用户、要做不可逆动作,这 11 项就该过一遍。过的时候不必每一项都做到满分,但每一项都要有明确的答案——"我配了"或者"我评估过风险决定不配"。"不知道"是唯一不可接受的答案,因为"不知道"在事故发生时就等于"没防"。

## 延伸阅读

- 原文:Adnan Masood《Loop Engineering: A Guide for Engineers and Practitioners》https://medium.com/@adnanmasood/loop-engineering-a-guide-for-engineers-and-practitioners-893bb65ea943 (Medium 部分付费墙,正文拓扑/失效模式/可观测性章节需订阅或 Google cache 补全)
- Adnan Masood 相关文章《Engineering Near-Deterministic LLM Systems for Consistent Actions》https://medium.com/@adnanmasood/from-probabilistic-to-predictable-engineering-near-deterministic-llm-systems-for-consistent-6e8e62cf45f6 (讨论网络拓扑、race condition,与本文 topology 维度互补)
- Addy Osmani 的概念奠基 essay(loop engineering 一词的源头之一,本系列有专篇深读)
- Peter Steinberger 的压缩句("stop prompting your agents and start designing the loops that prompt them",本系列有专篇深读)
- Boris Cherny 的厂商侧背书(Claude Code 作者视角,本系列有专篇深读)
- Lenny 的实战 prompt 篇(本系列有专篇深读,提供 Adnan 缺失的"第一条命令敲什么")
- Linas 的 STATE.md 项目级记忆脊柱篇(本系列有专篇深读,补 Adnan 在 STATE 维度的盲区)
- 共识框架的 6 原语 / L0-L3 成熟度 / cognitive surrender 概念(本系列总论篇)