当 Loop 成为工程单位：从 Prompt 到 Context 到 Loop 的范式迁移

skill engineering 回答了"经验怎么编码"，loop engineering 回答"经验怎么执行"。上一篇拆解 ResearchStudio 时，我们看到微软把人类导师的判断编码为 skill 文件——经验被冻结在文件里。但经验只有在运行时才有生命。谁来决定经验何时触发？谁来检查执行结果？谁来纠错？谁来决定"够了，可以停了"？答案是一个运行着的循环系统。这就是 loop engineering 要解决的问题。

一、一句话引发的范式讨论

2026 年 6 月，Boris Cherny——Anthropic Claude Code 的创造者和负责人——在一次采访中说了一段让开发者圈地震的话：

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

我不再给 Claude 写 prompt 了。我有循环在跑，它们去 prompt Claude，决定要做什么。我的工作是写循环。

几乎同一时间，Peter Steinberger（OpenClaw 创造者）在 X 上发了一条帖子，达到了约 650 万次浏览：

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

你不应该再手动 prompt 编程 agent 了。你应该设计那些 prompt agent 的循环。

然后 Google Cloud AI 总监 Addy Osmani 在 2026 年 6 月 7 日发表了一篇长文，给了这个实践一个名字：Loop Engineering。

三条来自三个不同公司、不同产品的声音，指向同一件事：人机协作的杠杆点移动了。过去你优化的是 prompt 怎么写，现在你优化的是循环怎么设计。

Andrew Ng（吴恩达）在 DeepLearning.AI 的 The Batch 专栏（2026-06-30）中，总结了自己使用的三个循环：agentic coding loop（编码循环）、developer feedback loop（开发者反馈循环）、external feedback loop（外部反馈循环）。Business Insider 报道这个词已经在使用 OpenAI Codex、Anthropic Claude Code、Cursor 和 OpenClaw 的开发者群体中扩散。

但大部分讨论停留在"loop engineering 是什么"的科普层面。这篇文章要回答更深的问题：为什么循环成了工程的单位？把它建好到底难在哪？什么样的循环是脆弱的，什么样的循环能扛住生产环境？

二、四层演进：Prompt → Context → Harness → Loop

理解 loop engineering，需要先看它从哪里来。Addy Osmani 和后续的多位作者梳理了一条清晰的演进线：

第一层：Prompt Engineering（2022–2024）

核心技能是措辞。给模型一个角色，把任务拆成步骤，加几个例子，让它 think step by step。Prompt engineering 优化的是表达——怎么把你的意图翻译成模型最容易被理解的格式。

它的天花板很硬：一个写得再好的 prompt，也无法让模型知道它从来没看过的信息。如果你的代码库用了一个冷门框架，模型不知道它的 API，prompt 写得再好也编不出来。

第二层：Context Engineering（2024–2025）

核心技能是环境构建。不只写 prompt，还要把相关文档、代码片段、API 定义、历史决策、项目规范——所有模型需要的背景信息——打包进 context window。

Anthropic 的 Boris Cherny 自己说："prompt engineering 是约 10% 的工作，context engineering 是约 90%。"这意味着 Claude Code 团队把大部分工程精力放在了"怎么给模型足够的上下文"上，而不是"怎么措辞"。

Context engineering 的突破在于：它意识到 LLM 是无状态的（stateless）。每次调用之间，模型什么都不记得。所有持久化的信息——项目规则、历史决策、中间结果——必须存在于模型之外，在磁盘文件、git 仓库或结构化记忆里。context engineering 就是在构建这个外部记忆层。

但 context engineering 有一个隐含假设：人在回路里。人读模型的输出，判断对不对，写下一个 prompt。人既是调度器也是质量门。

第三层：Harness Engineering（2025）

Simon Willison 在 2025 年 9 月写了 "Designing agentic loops"，第一次清晰描述了这个中间层：你不再只是给模型提供 context，你开始设计 agent 运行的环境——安全沙箱、工具集、凭证权限、自动测试、YOLO 模式（不需要逐步审批）。

Harness 是 agent 的"工位"：一个隔离的代码仓库（worktree）、一套工具（shell、文件系统、浏览器、API）、一套权限（只读？可以发 PR？可以部署？）、一组反馈信号（测试通过率、lint 结果、类型检查）。

Harness engineering 把人在回路中的部分行为自动化了。人不再每次都手动判断"模型做得对不对"——测试套件和 lint 规则先跑一遍，只有它们过了，人才介入。

第四层：Loop Engineering（2026）

如果你把 harness 放在一个定时器上，让它自己发现工作、分配给 agent、检查结果、记住状态、决定下一步——你就得到了一个 loop。

Loop engineering 是在 harness 之上再加一层调度系统。用 Osmani 的话说："loop engineering 坐在 harness 的上一层。harness 是单个 agent 运行的环境，loop 是一个运行在定时器上的系统，它会自己生成小的帮手（sub-agents），会自己喂自己。"

四层之间的关系是嵌套的，不是替代的：

每一层都没有消失。你仍然需要写好 prompt（只是不再逐条写），仍然需要管理 context，仍然需要设计 harness。但你最大的杠杆点移到了 loop 层。

三、为什么循环是必要的：LLM 的无状态本质

Cherny 的那句"我的工作是写循环"听起来像宣言，但背后是一个冰冷的技术事实：每一个基于 Transformer 的 LLM 都是无状态的。

模型不记得上一次对话。不记得你昨天给它定的项目规范。不记得它自己三分钟前写的代码是否通过了测试。每次推理都是一张白纸。

这意味着，任何需要跨步骤持续的任务——写代码、修 bug、做研究、处理工单——都必须依赖模型外部的系统来维持状态。这个"系统"就是循环。

一个最简化的 agent 循环可以写成：

while not done:
    context = assemble_context(history, tools, memory)
    response = llm(context)
    action = parse_action(response)
    result = execute(action)
    history.append((action, result))
    done = check_goal(result)

这段伪代码出现在 2026 年一篇分析 Claude Code 架构的 arXiv 论文中（arXiv: 2604.14228）。论文把 Claude Code 的核心描述为"一个简单的 while 循环，调用模型，运行工具，然后重复"。

但"简单"只是表象。真正的工程量在循环之外：权限管理、上下文压缩、可扩展性、子 agent 委托、存储。这些工程决定了循环是稳定运行还是失控崩塌。

Claude Code 和 Codex 的工具趋同

一个值得注意的信号：Anthropic 的 Claude Code 和 OpenAI 的 Codex 虽然是竞品，但在 2026 年上半年，它们落地的循环原语几乎一模一样。Cobus Greyling 在他的 loop engineering 综述中指出："工具的趋同很显著——Claude Code 和 Codex 都落地了非常相似的原语，所以循环的形状正在变得跟工具无关。"

这意味着 loop engineering 不是某一家公司的产品特性，而是一个行业层面的工程共识正在形成。

两个生态共同确认的六个构建块（Osmani 框架）：

1. Automations（自动化触发）：定时器或事件触发的循环入口。不是你手动启动，而是 cron、webhook、文件变化、PR 创建等事件触发。触发后循环自己跑起来。
2. Worktrees（工作树隔离）：让多个 agent 在同一个仓库的独立分支上并行工作，互不干扰。没有 worktree 隔离，两个 agent 同时改同一个文件就是灾难。
3. Skills（技能文件）：把项目知识写成结构化文件（如 CLAUDE.md、AGENTS.md），让 agent 不用猜。Skills 就是经验的外化——上一篇 ResearchStudio 文章讲的 ideation patterns、anti-patterns，本质就是 skills。
4. Connectors（连接器）：把 agent 接入你已有的工具链——GitHub、Slack、Jira、数据库、浏览器。连接器决定 agent 能触及的操作边界。
5. Sub-agents（子 agent）：让一个 agent 生成想法，另一个 agent 审查。Osmani 强调"sub-agents so one of them has the idea and a different one checks it"——这是把"生成-验证"分离写进了系统结构。
6. Memory（持久记忆）：循环的每次迭代从零开始，除非你记录了什么 happened。没有记忆，循环不会改进，只会反复撞同一堵墙。Osmani 有一句话被反复引用："The agent forgets, the repo doesn't."（agent 会遗忘，但仓库不会。）Anthropic 官方文档里也建议："Provide a place to write notes, as simple as a markdown file."

这六个构建块回答了一个核心问题：当你不在场的时候，什么在维持系统的运行？

四、88% 的失败率：demo 到生产之间的工程鸿沟

Loop engineering 之所以在 2026 年成为焦点，不只因为 Cherny 和 Steinberger 说了什么，更因为一个冰冷的数据在行业里回响：88% 的 AI agent 项目在生产环境中失败。

这个数字来自 Digital Applied 对 2024–2025 年企业部署的分析。Gartner 2026 年 1 月的分析确认了同一方向：至少 50% 的生成式 AI 项目在 POC（概念验证）阶段后被放弃。McKinsey 2025 年 AI 状态报告发现，只有不到 20% 的 AI 试点在 18 个月内扩展到生产环境。

Fiddler AI 综合多项研究后给出了更详细的分解：在 WebArena 基准测试上，基于 GPT-4 的最佳 agent 的端到端任务成功率只有 14.41%，人类是 78.24%。卡内基梅隆大学的研究者发现 AI agent 在常见办公任务上约 70% 的时间失败。MIT 的报告发现 95% 的生成式 AI 试点无法在 P&L（损益表）上产生可衡量的影响。

问题来了：为什么 agent 在 demo 里好看，在生产里崩？

答案不是模型不够聪明。GPT-5.2 和 Claude 4.6 在各项能力测试上已经很强。真正的失败发生在模型之外的工程层。

失败模式分解

把多项研究和行业报告综合起来，agent 在生产环境的失败主要集中在七种模式：

1. 静默工具调用失败（Silent Tool Call Failures）

Agent 调用一个工具。工具返回了意外格式的数据——可能是 API schema 变了，可能是下游超时返回了空 payload，可能是认证 token 过期了。Agent 不知道这是一个错误，继续基于错误数据做决策。

这是最危险的失败模式，因为系统看起来在正常工作。没有报错日志，没有异常告警。Agent 在错误数据上建了一座完整的推理大厦。

2. 上下文窗口崩溃（Context Window Collapse）

长会话中，早期的指令逐渐失去权重。模型开始"忘记"项目规范，忽略之前定好的约束。Datadog 的 AI 工程状态报告指出，这不是模型 bug，而是 attention 机制的统计特性——越早出现的内容，在长上下文中的 attention 权重越低。

3. 无限执行循环（Infinite Execution Loops）

Agent 在一个失败的操作上反复重试。没有终止条件，或者终止条件依赖的信号本身出了问题。每一次重试都在烧 token，但没有人注意到。Datadog 2026 年 3 月的数据显示，LLM 调用中 2% 返回错误，其中近三分之一是 rate limit 错误——840 万次 rate limit 错误。当 agent 遇到 rate limit 却没有 backoff 策略，就会进入无效重试。

4. 检索腐败（Retrieval Corruption）

RAG 系统检索到低质量或不相关的 chunk，agent 基于这些 chunk 生成错误回答。问题不在模型，在检索层。但用户体验是"模型错了"。

5. 路由混乱（Routing Chaos）

生产系统通常路由到多个模型提供商——根据延迟、成本、可靠性动态切换。没有中央控制层时，跨提供商的路由行为不一致，导致同一类型的请求在不同提供商上产生完全不同的行为。

6. 集成复杂度（Integration Complexity）

Demo 跑在干净的 API 样本和文档完善的端点上。生产环境连的是有上千个自定义字段的 CRM、跑在遗留架构上的 ERP、文档为零的内部工具。Agent 的集成复杂度远超 demo 准备时的预期。

7. 成本失控（Cost Explosion at Scale）

一个 5 分钟跑一次的循环，每次生成一个实现 agent 和一个验证 agent，在有限额度的 API plan 上可能不到早餐时间就烧完预算。Token 成本在循环模式下不是线性增长——每一轮迭代都消耗 token，子 agent 的引入让消耗倍增。

这七种失败模式有一个共同点：没有一个是由模型智能不足直接导致的。它们全部是工程层（系统设计、工具集成、状态管理、错误处理）的缺失。

这就是 loop engineering 存在的理由。它不是锦上添花，是对一个已被证实的工程鸿沟的回应。

五、把循环当控制系统来设计

到这里，一个更深的认识浮现出来：loop engineering 本质上是把控制论的古老智慧搬到了 AI agent 的场景里。

一个 agent 循环跟一个工业控制系统在结构上没有本质区别。工业控制有传感器（测量温度、压力、流量），控制器（PID），执行器（阀门、电机），和反馈回路。Agent 循环有观察（工具调用结果），决策（模型推理），执行（动作），和反馈（成功/失败信号）。

控制工程积累了近百年的经验，其中最核心的几条可以直接搬到 loop engineering：

停止条件不是可选的

控制系统的第一条规则：必须有终止条件。电机不能永远加速，阀门不能永远打开。

在 agent 循环里，终止条件有几层：

• 目标达成：任务完成（测试通过、PR 合并、文件生成）。
• 预算耗尽：token 用量达到上限、时间超过预算、调用次数超过限制。
• 收敛判定：连续 N 轮迭代没有改进（diminishing returns）。
• 异常升级：遇到了循环自身无法处理的错误，升级到人类。

Osmani 的警告很直白："a loop running unattended is also a loop making mistakes unattended."（一个无人值守的循环也在无人值守地犯错。）

Datadog 的数据给了一个具体数字：5% 的 LLM 调用 span 报告了错误。如果你有一个 20 步的 agent 循环，假设每步错误率独立，那一次完整循环的失败概率是 1 - 0.95^20 ≈ 64%。没有重试和修复机制，接近三分之二的循环会在某一步失败。

反馈信号的密度决定循环质量

Simon Willison 在 "Designing agentic loops" 里提出了一个核心观点：agent 是"用蛮力解决问题的工具"（brute force tools for finding solutions）。但蛮力要有效，需要密集的反馈信号——每一步迭代都要知道"离目标更近了还是更远了"。

Willison 强调自动化测试的价值："你从编程 agent 中获得的价值，被一个好的、干净通过的测试套件极大地放大了。"如果没有测试，agent 和你都不知道它写的代码对不对。循环就变成了盲目迭代。

这跟控制系统的道理一样：传感器越精确、采样频率越高，控制效果越好。Agent 的反馈信号包括：

• 自动化测试（单元、集成、端到端）
• Lint 和类型检查
• 编译结果
• 浏览器截图对比
• 日志检查
• 代码审查（人类或另一个 agent）

反馈信号的密度和准确性直接决定循环的收敛速度。信号稀疏的循环会反复在同一个错误上打转；信号丰富的循环能在几步之内收敛到正确结果。

分离生成和验证

Osmani 的五个构建块里，sub-agents 排第五不是偶然。"一个 agent 有想法，另一个检查它"——这是控制工程里的"双通道"设计：执行通道和监测通道物理隔离，一个出问题时另一个不受影响。

在 agent 场景里，这意味着：同一个模型，不同的 prompt 和 context，扮演不同角色。生成 agent 拿到的 context 强调"实现这个功能"，验证 agent 拿到的 context 强调"审查这个实现"。两个 agent 不共享中间状态，只共享最终产物。

Anthropic 的 Claude Code 和 OpenAI 的 Codex 都在产品层面支持了这个模式。Claude Code 的 sub-agent 机制允许主 agent 委托任务给独立的子 agent。Codex 的并行工作流允许同一任务被多个 agent 独立处理然后合并。

但这里有一个成本权衡：每次额外的验证 agent 都意味着更多的 token 消耗。一个"生成 + 验证"的双 agent 循环，token 成本是单 agent 的 2 倍以上。如果验证 agent 自己也需要调用工具（跑测试、查文档），成本更高。

预算门不是惩罚，是安全阀

控制工程的安全阀概念在 loop engineering 里对应的是 budget gate（预算门）。不是"花多了就停"的惩罚，而是"在造成不可逆损害之前停下来"的保护。

预算门可以在几个层面设置：

• 单次循环预算：每次循环最多花多少 token / 多少美元。
• 任务级预算：一个任务从开始到完成最多花多少。
• 日预算：一天内所有循环加起来最多花多少。
• 失败预算：连续失败多少次后停止（不是重试到天荒地老）。

TrueFoundry 在企业级 loop engineering 分析中提出了"standing permissions"的概念：循环里的每一步——触发、执行、验证、交付——都有独立的权限边界。权限不是给 agent 的，是给循环里的特定位置的。

六、理解债：循环做得越好，人理解得越少

Armin Ronacher（Flask 作者）写了一篇名为"The Coming Loop"的文章（2026-06-23），提出了 loop engineering 里最容易被忽视的风险：理解债（comprehension debt）。

理解债是这样的：当循环越来越自动化，代码变得越来越容易被机器修改，但也越来越难被人类理解。Agent 在循环中写了大量代码，每一段单独看是合理的，但整体积累下来，系统的逻辑变成了一堆人类没有完全 review 过的变更。

Ronacher 的担忧不是理论上的。MIT 2026 年的一项研究（Forbes, 2026-06-10 报道）发现，AI 辅助编程让代码提交通量增加了约 180%，但发布频率只增长了 30%。多出来的代码去哪了？一部分被 review 后拒绝，一部分被接受但在生产环境中失败。

JetBrains 基于 IDE 行为数据的分析也显示"人人自动 10 倍提效"仍是少数场景。HN 上一位工程师的个人经验也指向同一方向："AI 让我产出 2-3 倍的代码，但如果要质量稳定，review 时间也是 2-3 倍。"（这是个人经验分享，非统计结论。）

这组数据指向同一个结论：循环提升了生成速度，但没有同比例提升验证速度。生成和验证之间的剪刀差就是理解债。

理解债的后果在循环自动运行时最严重。当你在睡觉，循环在跑——它发现了一个问题，尝试修复，修复引入了一个微妙的副作用，下一个迭代基于这个副作用继续工作。到早上你醒来，代码库的逻辑跟你走的时候已经不是一回事了。

Addy Osmani 自己也很清醒："如果我不自己审查代码，或者完全依赖自动循环来修，我的产品质量会下降。我可能会陷入一个向下螺旋，不断把自己推进更深的坑里。"

这不是反对循环。而是在说：循环做得越好，越需要投资人类可理解的反馈层。Agent 的循环需要一种"翻译"机制——把循环中发生的每一次变更和决策，以人类能快速理解的方式呈现出来。这跟传统软件的 audit trail 是同一个需求，只是在 agent 场景下复杂度高了一个量级。

七、Skill 是静态的经验，Loop 是动态的经验

回到上一篇 ResearchStudio 拆解文章结尾的问题。在那篇文章里，我们把 AI 系统的专业能力分为三层：

ResearchStudio 展示了经验可以被编码为 skill 文件，让 AI"像有经验的导师一样把关质量"。但它留下了一个未回答的问题：谁来调用这些 skill？谁来检查 hard gate 的结果？谁来决定"够了，可以停了"？

答案就是 loop。

Skill 是静态的经验编码——它定义了"在这种情况应该做什么判断"。Loop 是动态的经验执行——它在运行时决定"现在是不是这种情况，判断结果如何，下一步做什么"。

没有 skill 的循环是盲目的——它有执行能力但没有经验，会在循环中反复犯同类错误。

没有循环的 skill 是沉睡的——经验被写在文件里但永远不被触发，因为没有人手动调用它。

两者合在一起才是完整的：

• Skill 告诉 loop "在这种情况做什么"
• Loop 决定 "现在是什么情况"
• Skill 的 hard gate 告诉 loop "什么状态不可接受"
• Loop 的停止条件告诉系统 "够了"

ResearchStudio 的 Paper2Assets skill 本质上就是一个被循环调用的经验单元。它定义了论文提取的 5 个阶段、每阶段的输入输出契约、和 pass/fail gate。上一篇讲到的 IdeaSpark 5 阶段流水线和 4 道硬门禁，在 loop engineering 框架里可以精确映射：每个 Phase 对应循环中的一个执行步骤，每道 hard gate 对应循环中的一个验证检查点，Phase 2 不加载 anti-patterns 的经验决策对应循环中的一个 context 管理策略。让这些阶段按顺序跑起来、在失败时重试、在全部完成后交付结果，那是循环的工作。

这个视角也解释了为什么 88% 的 agent 项目失败：它们有模型（知识层），可能也有一些 prompt（context 层），但缺少 skill（经验层）和 loop（可靠执行层）。它们试图让一个无状态、无经验、无纠错能力的系统去完成需要持续判断的任务。

八、Loop Engineering 的经济学：Token 在循环中的复利效应

讨论 loop engineering 时，最容易被忽略但最具决定性的约束是 token 成本。

一个单次 prompt 的成本是可控的——你发一个请求，模型返回一个响应，你知道花了多少。但循环改变了成本结构：token 消耗不再是一次性的，而是复利式增长的。

来算一笔账。假设一个典型场景：

• 你有一个每 5 分钟跑一次的循环（一天 288 次）
• 每次循环触发一个 triage agent（~2000 token）
• 如果 triage 发现有可做的工作，触发一个 implementer agent（~8000 token）
• implementer 完成后，触发一个 verifier agent（~5000 token）
• 假设 30% 的循环触发了 implementer

一天的成本：

• Triage: 288 × 2000 = 576,000 token
• Implementer: 288 × 0.3 × 8000 = 691,200 token
• Verifier: 288 × 0.3 × 5000 = 432,000 token
• 总计：约 170 万 token/天

按 2026 年 7 月公开定价（各提供商官方定价页面）：

• GPT-5.2 Pro：$21/$168 per MTok → 约 $17.8/天（输入）+ 可能更多输出成本
• Claude 4.6 Opus：$5/$25 per MTok → 约 $4.2/天
• DeepSeek V4-Flash：¥1/¥2 per MTok → 约 ¥1.7/天（不到 $0.25）
• GLM-4-Flash：¥0.1/MTok → 约 ¥0.17/天

旗舰模型一天的循环成本大约 $18–50，一个月 $540–1500。这还是一个非常保守的估算——实际场景中循环往往更复杂，子 agent 更多，context 更长。

如果用开源模型（DeepSeek、GLM），成本可以低一到两个数量级。这也是为什么 Cobus Greyling 在他的 loop engineering 实践指南中反复强调："triage should be cheap; sub-agents should spawn only when state says actionable"（分拣应该便宜；子 agent 只在状态显示有可行动项时才生成）。

成本不是 loop engineering 的副作用，它是架构决策的主要输入之一。好的循环设计跟好的系统设计一样——在满足功能需求的前提下最小化资源消耗。

九、未解决的问题和判断

Loop engineering 在 2026 年中期处于一个尴尬的位置：概念已经清晰，工具已经落地，但工程实践远未成熟。几个关键问题悬而未决。

循环的"民主化"门槛

目前能跑 loop engineering 的开发者，基本是那些已经深度使用 Claude Code 或 Codex 的早期采用者。他们熟悉命令行工具，理解 agent 架构，有能力设计 worktree、写 skill 文件、配置权限。

但 loop engineering 的真正价值在于让更多人受益——包括那些不会写循环的开发者。Osmani 的文章、Steinberger 的帖子、Cherny 的采访，都在试图把这件事从"高手的暗号"变成"人人可用的方法"。

门槛在哪？你需要理解几个概念：worktree（Git 工作树隔离）、sub-agent（委托和验证分离）、context engineering（背景管理）、budget gate（预算控制）、skill file（经验编码）。每一个单独不难，但组合在一起需要系统思维。

Cobus Greyling 在 GitHub 上开源了一个 loop-engineering 仓库，提供了 loop-init、loop-audit、loop-cost 等 CLI 工具，试图把最佳实践打包成可执行的命令。这是一个好的方向——把工程智慧封装进工具，而不是靠每个人的直觉。

"停止"和"成功"是两个不同的问题

Addy Osmani 的 Substack 评论区里，一位读者 Penelope Lawrence 留言："backpressure just tells you the loop stopped, not that it worked. had a triage loop exit clean this week and fix exactly nothing. stopping condition and success condition are completely different problems."（反压只告诉你循环停了，不告诉你循环成功了。本周有一个分拣循环干净退出，什么也没修。停止条件和成功条件是完全不同的问题。）

这指出了 loop engineering 的一个深层难题：循环的退出条件容易定义（预算用完、时间到、连续 N 轮无改进），但成功条件极难定义。在传统的自动化测试里，成功 = 测试通过。但测试覆盖率永远不完整——测试通过不等于代码正确。Agent 可能在测试全绿的情况下引入了一个微妙的安全漏洞或性能退化。

更深层的问题是：什么样的成功信号才足够？自动化测试、lint、类型检查是最容易自动化的。但代码风格、架构一致性、业务逻辑正确性——这些需要人类或更高级的判断。在循环中引入人类审批（human-in-the-loop）是一种方式，但它打破了循环的自治性，回到了"人在线"的模式。

治理层：当循环获得了操作权

Osmani 在 LinkedIn 上的后续讨论中引入了一个重要维度：runtime governance（运行时治理）。

一旦循环可以跨工具、仓库、工单系统、API 和生产系统操作，问题就不再只是"循环有没有完成任务"，而是"循环里的每一个操作是否在授权范围内、是否有证据支持、是否被允许变成后果"。

治理层包括：

• 授权边界：循环可以做什么、不可以做什么。不是模糊的"别搞砸"，而是具体的：可以提交 PR 但不能合并、可以读生产日志但不能写、可以创建 ticket 但不能修改优先级。
• 审计轨迹：循环中每一次 agent 决策的输入、输出、推理过程都需要被记录。不是为了 debug（虽然也有这个价值），而是为了在出问题时能回溯。
• 升级策略：什么情况自动处理，什么情况升级到人类。升级策略本身需要根据风险等级动态调整：低风险操作可以自动执行，高风险操作必须人类确认。

这跟传统软件的 IAM（身份与访问管理）和审计系统在需求上完全一致，只是 agent 的自治程度让风险面更大了。一个能自主操作的循环，如果权限设置不当，出错的速度和影响范围远超人类操作者。

十、判断：Loop Engineering 的真实位置

不是新概念，但是新实践

Loop engineering 的底层思想——用循环替代手动操作、用反馈信号驱动迭代、用预算和终止条件控制系统——在控制工程、CI/CD、DevOps 领域已经存在了几十年。Simon Willison 在 2025 年 9 月就已经清晰描述了 agentic loops 的设计原理，早于 2026 年 6 月的命名浪潮。

但 2026 年让它从"概念"变成"实践"的，是工具的成熟。Claude Code 和 Codex 落地了相似的原语（worktree、sub-agent、skill file、scheduled automation），让循环不再是理论模型，而是可以在终端里跑起来的东西。这是从"讨论该怎么设计"到"开始动手设计"的转折点。

核心价值不只在自动化，更在可靠性

很多人理解 loop engineering 时聚焦在"自动化"，让人不用再做重复的手动操作。自动化是手段，不是目的。真正的价值在可靠性：让 agent 的行为从"偶尔对、经常错、不知道什么时候错"变成"大部分时候对、错了能修、有明确的边界"。

这正是 88% 失败率要解决的问题。agent 在 demo 里好看的那些能力，一旦放进生产环境就会被七种失败模式拖垮。Loop engineering 的六个构建块（自动化、工作树、技能、连接器、子 agent、记忆）不是在给 agent 加功能，而是在给 agent 建围栏——让它的错误有界、可恢复、可观测。

谁应该关注，谁可以等等

Loop engineering 今天最直接的使用者是那些已经在用 Claude Code、Codex 或类似工具做日常开发的工程师。如果你每天都在手动 prompt agent 写代码、改 bug、跑测试，设计一个循环来替代你的"调度"角色是立竿见影的。

但如果你还没有进入 agent 辅助开发的工作流，loop engineering 不是你的入口——context engineering 和 harness engineering 才是。在跳到循环之前，你需要先回答：你的 agent 有足够的 context 吗？运行环境安全吗？工具集和权限合理吗？如果这三层没做好，循环只会让错误发生得更快。

对行业的判断

工具趋同是最大的信号。当 Anthropic 和 OpenAI——两家在模型能力上激烈竞争的公司——在循环原语上走向一致，说明这个工程范式不是某家的产品策略，而是 agent 大规模上生产的必经之路。

2026 下半年到 2027 年，我会关注三个信号：

1. 循环原语标准化：worktree、sub-agent、skill file 是否会走向跨工具的标准格式（就像 Docker 之于容器）。
2. 治理层产品化：授权边界、审计轨迹、升级策略是否会从"自己设计"变成产品内置。
3. 失败率拐点：88% 的失败率是否开始下降，如果有，loop engineering 的成熟度就可以被验证。

在信号明确之前，loop engineering 是一个值得理解但不急于 all-in 的工程实践。理解它让你知道 agent 的下一步往哪里走；不急于 all-in 是因为工具栈、最佳实践和治理框架都还在快速变化。

---

声明： 本文基于公开信息撰写，综合参考了 Addy Osmani 的 "Loop Engineering" 原文、Boris Cherny 和 Peter Steinberger 的公开采访/帖子、Simon Willison 的 "Designing agentic loops"、Datadog State of AI Engineering 报告、Fiddler AI 和 Digital Applied 的 agent 失败率分析、以及多篇 arXiv 论文和行业报告。不构成投资建议。文中数据截至 2026 年 7 月 10 日。