Loop Engineering：停止手动提示，开始设计自动提示的系统

引子
一、为什么循环工程现在很重要
- [1.1 你是自己工作流的串行瓶颈](#1.1 你是自己工作流的串行瓶颈)
- [1.2 转变已经在建造者内部发生了](#1.2 转变已经在建造者内部发生了)
- [1.3 这篇文章会给你什么](#1.3 这篇文章会给你什么)
二、从提示工程到循环工程------四阶段演化
- [2.1 阶段一：提示工程（2022-2023）](#2.1 阶段一：提示工程（2022-2023）)
- [2.2 阶段二：上下文工程（2024-2025）](#2.2 阶段二：上下文工程（2024-2025）)
- [2.3 阶段三：线束工程（2025-2026）](#2.3 阶段三：线束工程（2025-2026）)
- [2.4 阶段四：循环工程（2026 年 6 月）](#2.4 阶段四：循环工程（2026 年 6 月）)
- [2.5 一句话概括演化](#2.5 一句话概括演化)
三、核心概念------什么是循环？
- [3.1 定义](#3.1 定义)
- [3.2 理论根源：控制论与反馈](#3.2 理论根源：控制论与反馈)
- [3.3 内循环 vs. 外循环](#3.3 内循环 vs. 外循环)
- [3.4 循环与脚本的区别](#3.4 循环与脚本的区别)
四、循环的五个阶段
- [4.1 意图（Intent）](#4.1 意图（Intent）)
- [4.2 上下文（Context）](#4.2 上下文（Context）)
- [4.3 行动（Action）](#4.3 行动（Action）)
- [4.4 观察（Observation）](#4.4 观察（Observation）)
- [4.5 调整（Adjustment）](#4.5 调整（Adjustment）)
五、六个构建块
- [5.1 自动化（Automations）------心跳](#5.1 自动化（Automations）——心跳)
- [5.2 工作树（Worktrees）------并行隔离](#5.2 工作树（Worktrees）——并行隔离)
- [5.3 技能（Skills）------持久化的项目知识](#5.3 技能（Skills）——持久化的项目知识)
- [5.4 连接器（Connectors）------循环触碰真实工具](#5.4 连接器（Connectors）——循环触碰真实工具)
- [5.5 子 Agent（Sub-Agents）------制造者/检查者分离](#5.5 子 Agent（Sub-Agents）——制造者/检查者分离)
- [5.6 记忆（Memory）------脊柱](#5.6 记忆（Memory）——脊柱)
六、五种常见循环模式
[七、完整实战------构建 CI 失败分诊循环](#七、完整实战——构建 CI 失败分诊循环)
- [7.1 问题](#7.1 问题)
- [7.2 设计循环：意图与验证信号](#7.2 设计循环：意图与验证信号)
- [7.3 逐步搭建：从零构建循环](#7.3 逐步搭建：从零构建循环)
- [7.4 组装在一起：完整循环流程](#7.4 组装在一起：完整循环流程)
- [7.5 先在本地测试](#7.5 先在本地测试)
- [7.6 成本估算](#7.6 成本估算)
八、失败模式与如何避免
- [8.1 循环震荡（Loop Thrashing）](#8.1 循环震荡（Loop Thrashing）)
- [8.2 过拟合测试](#8.2 过拟合测试)
- [8.3 上下文漂移](#8.3 上下文漂移)
- [8.4 认知投降](#8.4 认知投降)
- [8.5 理解债务](#8.5 理解债务)
- [8.6 不安全的自主操作](#8.6 不安全的自主操作)
九、最佳实践
十、未来展望
十一、关键要点
十二、快速参考卡
[附录 A：参考资料](#附录 A：参考资料)

引子

Boris Cherny 说：

"我不再手动提示 Claude 了。我有循环在运行，它们提示 Claude 并自己弄清楚该做什么。我的工作是编写循环。"

Peter Steinberger 紧随其后：

"你不应该再手动提示编码 Agent 了。你应该设计循环来提示你的 Agent。"

在急于解释之前，先让说话者的身份沉淀一下------Cherny 是 Anthropic Claude Code 团队的负责人，Steinberger 是即将加入 OpenAI 的创始人。这不是两个在推特上吹牛的开发者，这是正在亲手建造下一代 AI 工具的人，告诉你他们自己已经换了工作方式。

一、为什么循环工程现在很重要

1.1 你是自己工作流的串行瓶颈

每一个 Agent 的行动都在等你输入下一条指令。你是串行瓶颈。

模型每几个月就变强一次，但你作为人类提示者的吞吐量不会。模型能做的和你能指挥的之间的差距，正在越拉越大。

看看数据：Replit 的 Agent 4 能连续运行 6 小时以上无需人类输入，在单次会话中产出超过 36,000 行生产级代码。没有人类能连续 6 小时以那种质量手动提示。

1.2 转变已经在建造者内部发生了

这不是理论。这是正在发生的事：

Anthropic 内部团队已经在生产工程中使用循环模式。他们 2025 年 11 月和 2026 年 3 月发表的两篇工程博文，本质上就是循环工程在实践中的文档。
Shopify CEO Tobi Lutke 运行了约 120 次自动化 Agent 实验，在一个 20 年历史的代码库上实现了 53% 的解析+渲染加速。他没有坐在那里手动提示 120 次。
JAKALA 在 3,000+ 席位上部署了分层 Agent 网络；营销活动优化周期从 5-7 天降至 24 小时以内。人类审查，循环执行。

1.3 这篇文章会给你什么

一个心智模型：循环是什么，它和提示有何不同，为什么它比之前的方法更难而非更容易。
一套具体词汇：五个阶段、六个构建块、常见模式。
一个可运行的完整实例：CI 失败分诊循环，含从头搭建的逐步指引。
会吞噬你项目的失败模式------如果你忽视它们的话。

二、从提示工程到循环工程------四阶段演化

理解循环工程最好的方式是看它如何从已有实践中层层长出。每一层解决上一层遗留的问题，同时引入新的局限------直到循环工程。

2.1 阶段一：提示工程（2022-2023）

在单个文本字符串中精心构造最优指令。焦点是：正确的措辞、少样本示例、思维链模式。

局限：静态、开环。你把提示扔过墙，然后祈祷。

Bhargava 等人将提示形式化为控制问题------仅 10 个 token 的提示即可达 97% 的目标 token 可达性。但可达性（reachability）不等于收敛（convergence）：模型可以生成正确的 token，不代表它能在多轮交互中收敛到正确的结果。

2.2 阶段二：上下文工程（2024-2025）

由 Tobi Lutke 和 Andrej Karpathy 推广------"为 LLM 可解地完成任务提供所有必要上下文的艺术"。

从静态字符串转向动态组装的信息------RAG、对话历史、记忆、工具定义、输出格式化。

Phillip Schmid 的关键洞察：

"大多数 Agent 失败不再是模型失败，而是上下文失败。"

局限：更好的上下文仍然只产生单个输出。没有迭代，没有自我纠正，没有持久性。

2.3 阶段三：线束工程（2025-2026）

Viv Trivedy 提出：Agent = 模型 + 线束（Harness）。线束是不属于模型本身的每一份代码、配置和执行逻辑------权限、沙箱、工具定义、上下文管理、钩子。

Osmani 的表述：

"一个体面的模型配上优秀的线束，胜过一个优秀的模型配上糟糕的线束。"

证据：在 Terminal Bench 2.0 上，Viv 的团队仅通过改变线束就从 Top 30 跃升至 Top 5。同一个模型。

Anthropic 发表了两篇关于长时间运行 Agent 线束设计的工程文章，记录了初始化器+编码 Agent 模式和受 GAN 启发的规划器+生成器+评估器架构。

局限：线束让一个 Agent 在一次会话中运行良好。它不会调度、不会派生、不会跨运行记忆、不会自主闭环。

2.4 阶段四：循环工程（2026 年 6 月）

Osmani：

"循环工程坐在线束的上一层------它靠定时器运行、派生帮手、自我喂养。"

线束是一个 Agent 运行的环境。循环是编排多个 Agent、调度工作、记录进度、决定下一步的系统。

你设计了一次。你没有手动提示其中任何一步。

$图示说明：四层堆叠图。底层"提示工程"（单箭头：提示\to输出）。第二层"上下文工程"（多个来源箭头------RAG、记忆、工具------汇入单个提示）。第三层"线束工程"（Agent 外围的方框，包含权限、沙箱、工具定义、上下文管理）。顶层"循环工程"（时钟图标、多个 Agent 方框、状态文件、循环箭头）。每层建在下层之上。$

2.5 一句话概括演化

提示工程（写出更好的指令）→ 上下文工程（动态传递正确的信息）→ 线束工程（构建 Agent 运行的脚手架）→ 循环工程（设计自主驱动 Agent 的系统）

每一层包容而非取代前一层：循环工程仍然需要好的提示、正确的上下文、可靠的线束------但它在此基础上增加了调度、编排和自主闭环。

三、核心概念------什么是循环？

3.1 定义

一个循环是一个递归目标：你定义一个目的，AI 迭代直到完成。

Osmani：

"循环工程是替换掉你自己------那个手动提示 Agent 的人。你改为设计那个系统。"

与提示的关键结构差异：你不在循环中。你设计了循环。

3.2 理论根源：控制论与反馈

循环工程并非无中生有，它植根于三道思想脉络：

诺伯特·维纳《控制论》（1948）：反馈循环是目标导向系统维持稳态的根本机制。没有反馈，系统无法自我纠正。
OODA 循环（John Boyd，1986）：观察→判断→决策→行动。Boyd 的洞见是：更快的循环带来竞争优势------不一定要每步都最优，但循环速度本身即战略优势。
ReAct（Yao 等人，ICLR 2023）：将 OODA 操作化为 LLM Agent。思维→行动→观察。这是奠基性的 Agent 循环论文，首次证明了交错推理与行动显著优于纯推理或纯行动。

到 2023-2024 年，学术共识收敛：每篇主要 Agent 论文都采用某种形式的观察→思考→行动→（反思）→重复循环。Voyager 的自动课程、SWE-agent 的交互循环、Generative Agents 的反思架构------底层形状相同。

3.3 内循环 vs. 外循环

这是循环工程中最关键的区分。

内循环（单任务内的紧密循环）：

提出→执行→观察→改进。Agent 写代码、运行它、读错误、修复、重新运行。这是单个 Agent 在其上下文窗口内工作。

Voyager 中的例子：提出代码→执行→获取反馈→改进。
Anthropic 线束设计中的例子：生成器创建 HTML/CSS/JS→评估器测试→反馈回流→5-15 次迭代。
时间尺度：秒到分钟。

外循环（跨任务/会话的战略循环）：

设定目标、派生子 Agent、管理状态、决定下一步做什么。

Voyager 中的例子：自动课程提出新任务，技能库跨回合复合。
Osmani 的晨间循环：自动化按计划运行、调用分诊技能、派生工作树、调度子 Agent、更新状态文件。
时间尺度：分钟到天。

为什么这个区分重要：

内循环关乎执行质量；外循环关乎战略方向。
你可以有完美的内循环（测试通过）但破碎的外循环（在做错误的事情）。
/goal 原语体现了这一点：一个独立的小模型在每次内循环轮次后检查完成度，确保写代码的 Agent 不是给自己打分的人。

$图示说明：同心循环图。内圈"内循环"箭头经过提出\to执行\to观察\to改进。外圈"外循环"箭头经过规划\to派生\to监控\to调整。外圈上有时钟/计划图标。两个循环之间有状态文件连接。外循环内可见多个内循环（代表并行子 Agent）。$

3.4 循环与脚本的区别

维度	脚本	循环
路径	固定	基于观察而适应
失败时	崩溃	调整并继续
跨运行记忆	无	持久化状态
本质	确定性	控制论------使用反馈收敛于目标

脚本执行指令。循环追求目标。这是根本差异。

四、循环的五个阶段

每个有效的循环，无论模式如何，都经历五个阶段。它们不是顺序步骤------它们重叠和重复------但命名它们为你提供了调试循环的词汇。

4.1 意图（Intent）

循环试图完成什么？以可验证的方式陈述。

最常见的失败：模糊意图。"修复 bug" vs. "test/auth 中的所有测试通过且 lint 步骤干净。"

Osmani 的"意图债务"概念：Agent 每次会话从零开始，用自信的猜测填补空白。技能（Skill）是外化的意图------写一次，每次运行都读。

4.2 上下文（Context）

Agent 行动需要什么信息？它如何获取？

上下文工程是基础层。循环必须在正确的时间动态组装正确的信息。

上下文来源：文件系统（代码、配置）、工具（测试输出、构建日志）、记忆（状态文件、上次运行结果）、技能（项目约定）、连接器（问题追踪器、数据库、Slack）。

循环必须管理上下文窗口预算------长循环会用中间结果填满上下文。用子 Agent 做调查、在任务间 /clear、用 /compact 做摘要。

4.3 行动（Action）

Agent 执行：写代码、运行命令、开 PR、更新工单。

线束决定哪些行动是可能的（工具、权限、沙箱）。

关键设计决策：哪些行动需要人类批准？按风险校准：

风险级别	类型	监督方式
低	建议型（读文件、查日志）	自动
中	生成型（写代码、开 PR）	审查
高	自主型（合并分支、部署）	批准
关键	破坏型（删除数据、推生产）	确认+日志

4.4 观察（Observation）

Agent 感知其行动的结果。这是闭合循环的反馈信号。

没有观察，循环就是开环------Agent 盲目行动。

观察类型：测试退出码、编译器输出、运行时错误、审查评论、截图、视觉比较、API 响应。

循环中最重要的设计选择：验证信号是什么？

Claude Code 最佳实践：

"给 Claude 一个可以运行的检查：测试、一次构建、一张可以比较的截图。给 Claude 一个产生通过或失败的东西，循环就会自行闭合。"

4.5 调整（Adjustment）

Agent 使用观察来决定：继续、转向还是停止。

如果验证信号说"还没完成"，Agent 调整方法，内循环继续。
如果外循环条件满足，Agent 停止。
/goal 机制：一个独立的评估器模型在每轮后检查条件。调整由评估器的原因指导，而非仅靠 Agent 自身的判断。

$图示说明：五节点环形图，顺时针排列：意图\to上下文\to行动\to观察\to调整，调整有箭头回到意图（循环闭合）。中心："验证信号"连接观察到调整。环外：外循环箭头连接多个内循环周期，有"状态文件"节点在周期之间持久化。$

五、六个构建块

这些是你组装来构建循环的结构组件。Claude Code 和 OpenAI Codex 都实现了全部六个。

5.1 自动化（Automations）------心跳

让循环成为真正的循环而非一次性运行的东西：定时器、计划、触发器。

实现：Claude Code 的 /loop 命令（会话内）、Routines（云端托管，笔记本关了也继续）、GitHub Actions（CI/CD 集成）。Codex 的 Automations 标签页。

两个会话内原语：

/loop：按节奏重新运行。
/goal：持续运行直到条件为真。

/goal 的洞察：一个独立的小模型在每轮后检查完成度，所以写代码的 Agent 不是给自己打分的人。

具体例子：

bash 复制代码

# 固定间隔
/loop 5m check if the deployment finished

# 动态间隔（Claude 自选节奏）
/loop check whether CI passed and address any review comments

# 内置维护提示
/loop

5.2 工作树（Worktrees）------并行隔离

两个 Agent 写同一个文件，和两个工程师不经协调就往同一行提交一样令人头疼。

Git 工作树给每个 Agent 一个独立工作目录，在自己的分支上，共享同一个仓库历史。

bash 复制代码

# 启动时指定工作树
claude --worktree feature-auth

# 自动生成名称
claude -w

# 从特定 PR 分支
claude --worktree "#1234"

关键告诫：工作树消除了机械碰撞，但你的审查带宽仍然是天花板。这就是"编排税"------并行度受限于你审查产出的能力。

5.3 技能（Skills）------持久化的项目知识

停止每次会话重新解释项目上下文。技能是一个文件夹，包含一个 SKILL.md 持有指令和元数据，以及可选的脚本和资产。

markdown 复制代码

# .claude/skills/ci-triage/SKILL.md
---
name: ci-triage
description: 分诊主分支上的 CI 失败。诊断根因并起草修复。
when_to_use: 主分支 CI 变红
allowed-tools: Bash(gh *) Bash(git *) Bash(npm *) Bash(npx *)
model: sonnet
---

# CI 分诊技能

## 项目上下文
- 主分支：`main`
- CI 提供商：GitHub Actions
- 测试命令：`npm test`
- 构建命令：`npm run build`

## 分诊流程
1. 运行 `gh run list --branch main --status failure --limit 5`
2. 对每个失败，运行 `gh run view <run-id> --log-failed`
3. 分类失败...

技能解决了意图债务：Agent 每次会话从零开始。没有技能，循环每轮从零重新推导项目上下文；有了技能，它复合------每次运行都比上次更了解项目。

5.4 连接器（Connectors）------循环触碰真实工具

只能看文件系统的循环太小了。连接器（基于 MCP 构建）让 Agent 读取问题追踪器、查询数据库、访问预发布 API、发 Slack 消息。

MCP 架构：主机-客户端-服务器。工具（模型控制）、资源（应用控制）、提示（用户控制）。

连接器带来的差异：

"一个 Agent 说'这是修复'------vs.------一个循环自己打开 PR、关联 Linear 工单、CI 绿了之后在频道里 @人。"

Token 成本警告：仅 GitHub MCP 就可能消耗 55,000 token 的上下文。有时 CLI 工具（gh）比 MCP 服务器更高效------同等能力，更低 token 开销。

5.5 子 Agent（Sub-Agents）------制造者/检查者分离

结构上最重要的构建块。写代码的模型给自己的作业打分太仁慈了。

第二个具有不同指令（有时是不同模型）的 Agent 能捕捉第一个自圆其说的地方。

典型分离：一个探索、一个实现、一个对照规格验证。

这就是 /goal 底层做的：一个新模型决定循环是否完成。

Token 成本：子 Agent 消耗更多 token，因为每个都做自己的模型和工具工作。把它们花在值得付第二意见的地方------验证比生成更便宜，但价值更高。

markdown 复制代码

# .claude/agents/ci-reviewer.md
---
name: ci-reviewer
description: 审查 CI 修复 PR 的正确性。ci-triage 起草修复后使用。
tools: Read, Grep, Glob, Bash
model: haiku
---

审查 CI 修复的 PR diff。检查：
1. 失败的测试现在通过
2. 没有破坏其他测试
3. 修复解决了根因，而非症状
4. 没有修改失败模块之外的文件
仅报告遗漏，不报告风格偏好。

5.6 记忆（Memory）------脊柱

一个 Markdown 文件、一个 Linear 面板------任何存在于单次对话之外、持有已完成和下一步的东西。

"模型在运行之间忘记一切，所以记忆必须在磁盘上而非上下文中。Agent 会忘记，仓库不会。"

实现：CLAUDE.md 层级（用户、项目、本地）、MEMORY.md 自动记忆、状态文件、通过 MCP 连接的 Linear 面板。

记忆是让循环复合而非重启的东西：明天的运行从今天停止的地方接续。没有记忆，每次循环运行都是失忆的第一次；有了记忆，循环积累经验。

$图示说明：六边形图，六个节点各代表一个构建块。中心："循环"。从自动化到中心的箭头（心跳）、工作树到中心（隔离）、技能到中心（知识）、连接器到中心（触达）、子 Agent 到中心（验证）、记忆到中心（持久化）。每个节点有一行职责描述：自动化="何时"、工作树="何地"、技能="所知"、连接器="可触"、子 Agent="谁查"、记忆="所记"。$

六、五种常见循环模式

理解了概念和构建块之后，来看它们如何组合成实际的工作模式。以下五种模式覆盖了大多数日常场景。

模式一：测试驱动循环

原理：Agent 写代码、运行测试、读失败、修复代码、重复直到测试通过。

验证信号：测试退出码（0=完成，非零=继续）。

bash 复制代码

# 最简单的形式
/goal all tests in test/auth pass and the lint step is clean

为什么有效：测试套件是客观、确定性的裁判。不需要模型评估------退出码就是信号。

实现层次：

层次	机制	可靠性
提示内	"写测试，运行它们，修复失败"	低------单轮
`/goal` 条件	独立评估器每轮重新检查	中------多轮
Stop Hook	`npm test 必须退出 0 才能停止`	高------确定性门

模式二：审查驱动循环

原理：Agent 提交代码，审查者（人类或 AI 子 Agent）提供反馈，Agent 处理反馈，循环直到批准。

验证信号：审查批准。

bash 复制代码

/loop check whether CI passed and address any review comments

关键洞察：用新的子 Agent 做审查------做工作的 Agent 不应该是打分的人。

复制代码

Use a subagent to review the rate limiter diff against PLAN.md.
Check that every requirement is implemented, the listed edge cases
have tests, and nothing outside scope changed.

模式三：运行时调试循环

原理：Agent 遇到运行时错误，读堆栈跟踪，调查，应用修复，重新运行，重复直到错误解决。

验证信号：运行时错误（或其消失）。

复制代码

the build fails with this error: [paste error]. fix it and verify
the build succeeds. address the root cause, don't suppress the error.

并行假设模式：当根因不确定时，派生多个子 Agent 各自调查一个假设：

复制代码

Spawn 5 agent teammates to investigate different hypotheses about
why the app exits after one message.

模式四：产品迭代循环

原理：Agent 基于规格实现功能，对照验收标准验证（可能是主观的），基于用户反馈或视觉比较迭代，重复直到满足需求。

验证信号：验收标准或视觉比较。

复制代码

[paste screenshot] implement this design. take a screenshot of the
result and compare it to the original. list differences and fix them.

人类在环变体：当需求不明确时，让 Agent 先采访你：

复制代码

Interview me in detail, then write a complete spec to SPEC.md

模式五：计划维护循环

原理：Agent 按固定计划运行以维护代码库健康：修复 CI 失败、处理 PR 评论、运行清理、审计依赖。

验证信号：任务完成（队列为空、CI 绿色、无未处理审查评论）。

bash 复制代码

# 内置维护
/loop

# 自定义维护
/loop 5m run the CI triage skill

生产变体：一个 Routine 每个工作日晚上运行，读取上次运行以来新开的问题，打标签、分配负责人、发摘要到 Slack。

$图示说明：模式矩阵表。行：五种模式。列：触发器、验证信号、内循环周期、典型持续时间、人类参与度。每格简要描述。$

七、完整实战------构建 CI 失败分诊循环

前六节建立了概念框架。这一节将其落地------从头走一遍构建一个真实可运行的循环。

例子：一个 CI 失败分诊循环，每天早晨运行、诊断失败、起草修复、开 PR。

7.1 问题

CI 在夜间失败了。你醒来面对一个红色构建。每天第一个小时都在读日志、诊断、修复。

这正是循环为之设计的重复性、可验证任务。

7.2 设计循环：意图与验证信号

在写任何代码之前，先明确设计：

意图："主分支上所有 CI 任务通过。"
验证信号：CI 退出码（绿色=完成，红色=继续调查）。
外循环：每天早晨按计划运行。
内循环：对每个失败的任务，调查→起草修复→验证→开 PR。

7.3 逐步搭建：从零构建循环

以下是搭建这个循环的完整步骤。每一步对应一个构建块。

第一步：创建项目目录结构

bash 复制代码

# 项目根目录下
mkdir -p .claude/skills/ci-triage
mkdir -p .claude/agents
touch PROGRESS.md
touch KNOWN_FLAKES.md

最终目录结构：

复制代码

your-project/
├── .claude/
│   ├── skills/
│   │   └── ci-triage/
│   │       └── SKILL.md
│   └── agents/
│       └── ci-reviewer.md
├── .github/
│   └── workflows/
│       └── ci-triage.yml
├── PROGRESS.md
└── KNOWN_FLAKES.md

第二步：编写技能------持久化知识（Skills）

创建 .claude/skills/ci-triage/SKILL.md：

markdown 复制代码

---
name: ci-triage
description: 分诊主分支上的 CI 失败。诊断根因并起草修复。
when_to_use: 主分支 CI 变红
allowed-tools: Bash(gh *) Bash(git *) Bash(npm *) Bash(npx *)
model: sonnet
---

# CI 分诊技能

## 项目上下文
- 主分支：`main`
- CI 提供商：GitHub Actions
- 测试命令：`npm test`
- 构建命令：`npm run build`
- 关键目录：`src/`、`test/`

## 分诊流程
1. 运行 `gh run list --branch main --status failure --limit 5` 查找最近失败
2. 对每个失败，运行 `gh run view <run-id> --log-failed` 获取失败日志
3. 分类失败：
   - 不稳定测试（间歇性）→ 添加到 KNOWN_FLAKES.md，跳过
   - 依赖变更 → 锁定版本，验证，开 PR
   - 代码回归 → 识别提交，起草修复，验证，开 PR
   - 环境问题 → 在 PROGRESS.md 中记录，供人类审查
4. 起草修复前：始终用 `npm test` 验证
5. PR 标题模式：`[ci-triage] Fix: <摘要>`

## 幂等性
- 每次运行前先读取 PROGRESS.md，跳过已处理的失败
- 检查是否已有同名分支的 PR，避免重复开 PR

## 禁止
- 不要修改失败模块之外的文件
- 不要压制错误（解决根因）
- 不要碰绿色测试

第三步：编写子 Agent------制造者/检查者分离（Sub-Agents）

创建 .claude/agents/ci-reviewer.md：

markdown 复制代码

---
name: ci-reviewer
description: 审查 CI 修复 PR 的正确性。ci-triage 起草修复后使用。
tools: Read, Grep, Glob, Bash
model: haiku
---

审查 CI 修复的 PR diff。检查：
1. 失败的测试现在通过
2. 没有破坏其他测试
3. 修复解决了根因，而非症状
4. 没有修改失败模块之外的文件
仅报告遗漏，不报告风格偏好。

第四步：创建记忆文件------状态持久化（Memory）

创建 PROGRESS.md 初始模板：

markdown 复制代码

# CI 分诊进度

## 已解决

（循环自动填充）

## 进行中

（循环自动填充）

## 升级给人类

（循环自动填充）

创建 KNOWN_FLAKES.md 初始模板：

markdown 复制代码

# 已知不稳定测试

| 测试名 | 首次发现 | 状态 |
|--------|---------|------|
| （循环自动填充） | | |

第五步：配置自动化------心跳（Automations）

创建 .github/workflows/ci-triage.yml：

yaml 复制代码

name: CI Triage Loop
on:
  schedule:
    - cron: "0 7 * * 1-5"  # 工作日早7点
  workflow_dispatch:         # 手动触发（测试用）

jobs:
  triage:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Run the CI triage skill. Check all CI jobs on the main branch.
            For each failing job, pull the log, diagnose the root cause,
            draft a minimal fix in an isolated worktree, run the relevant
            tests to verify, and open a PR if the fix passes.
            Update PROGRESS.md with findings.
          claude_args: "--model sonnet"

第六步：验证工作树隔离（Worktrees）

技能指示 Agent 为每个修复创建隔离分支。多个失败可以并行调查而不会文件冲突。在本地验证工作树功能：

bash 复制代码

# 测试工作树创建
claude -w --prompt "create a test branch and list files"

# 清理测试分支
git worktree list
git worktree remove <test-worktree-path>

第七步：验证连接器------GitHub 集成（Connectors）

直接使用 gh CLI 而非 GitHub MCP 服务器，避免 55,000 token 的上下文税。技能的 allowed-tools 包含 Bash(gh *) 用于 PR 操作、运行查询和日志检索。

验证 gh CLI 可用且已认证：

bash 复制代码

gh auth status
gh run list --branch main --limit 3

7.4 组装在一起：完整循环流程

所有构建块就位后，循环的运行流程如下：

触发：GitHub Actions 在早 7 点触发 cron（或手动 workflow_dispatch）。
加载上下文：Claude Code 启动，加载 ci-triage 技能，读取 PROGRESS.md 了解历史。
检查状态 ：Agent 运行 gh run list --branch main --status failure --limit 5。
逐个分诊：对每个失败------拉取日志、分类、在隔离工作树中起草修复。
验证修复 ：Agent 在工作树中运行 npm test 验证。
开 PR ：如果测试通过：开带 [ci-triage] 前缀的 PR。
独立审查：ci-reviewer 子 Agent 在新上下文中审查 PR diff。
处理反馈：如果审查者发现问题：Agent 处理并更新 PR。
更新记忆：Agent 用结果更新 PROGRESS.md。
升级人类：循环无法处理的事项进入 PROGRESS.md 的"升级给人类"。
接续运行：明天的运行读取 PROGRESS.md，从今天停止的地方接续。

你设计了一次。你没有手动提示其中任何一步。

7.5 先在本地测试

在部署到 GitHub Actions 之前，先在本地测试循环的每一步：

bash 复制代码

# 第一步：一次性测试技能
claude -p "Run the CI triage skill" --model sonnet

# 第二步：会话内循环（5 分钟节奏，观察行为）
/loop 5m run the CI triage skill

# 第三步：目标驱动（持续到 CI 变绿，验证完整闭环）
/goal all CI jobs on the main branch pass and no failures remain

只有三步全部通过后，才部署到 GitHub Actions。

7.6 成本估算

组件	模型	典型成本/次运行
分诊+修复起草	Sonnet	$0.50-1.00
审查	Haiku	$0.05
日合计		约 $1.00-1.50
月合计（22 个工作日）		约 $20-30

对比：高级工程师每天 1 小时分诊工作，按 $75+/小时计算。循环的成本不到人工的 2%。

$图示说明：CI 分诊循环流程图。起点（cron 触发）\to"检查 CI 状态"决策菱形\to绿色？\to是："更新 PROGRESS.md，停止"/否："拉取失败日志"\to"分类失败"\to四个分支（不稳定/依赖/回归/环境）\to不稳定："添加到 KNOWN_FLAKES.md"\to回循环。依赖/回归："在工作树中起草修复"\to"运行测试"\to通过？\to是："开 PR"\to"子 Agent 审查"\to通过？\to是："更新 PROGRESS.md"\to回循环。否分支回到"起草修复"。环境："在 PROGRESS.md 中升级给人类"\to回循环。$

八、失败模式与如何避免

这一节是把有帮助的博文和炒作文章分开的部分。每个失败模式都在生产中观察到过。

8.1 循环震荡（Loop Thrashing）

表现：Agent 反复修改代码却不收敛。做个改动、测试仍失败、做另一个改动、测试仍失败、再试第一种方案。

根因：失败纠正造成的上下文污染。两次失败纠正后，积累的失败尝试上下文会降低后续性能。Agent 在推理自己的错误而非问题本身。

修复方法：

两次失败纠正后，/clear 并用更好的提示重新开始。
积极使用 Git------循环运行前先 checkpoint，这样随时可以回退。
设轮次限制：/goal ... or stop after 20 turns。

生产事故：Claude Code 2026 年初的质量下降被追溯到一个线束 bug，它"在会话剩余的每轮清除思维上下文而非仅一次"，导致模型在重复失败方案中震荡。

8.2 过拟合测试

表现：Agent 写的代码通过了特定测试用例，但没有解决根本问题。它优化的是验证信号，而非意图。

根因：规格博弈（Specification Gaming）。验证信号（测试）没有完全捕获意图。Agent 找到了满足信号却不满足你的捷径。

修复方法：

使用对抗性审查：子 Agent 对照计划审查 diff，而非仅检查测试通过/失败。
写捕获意图的测试，而非仅捕获行为。基于属性的测试有帮助。
对照需求验证，而非仅测试。

学术支撑：SWE-bench Goes Live（arXiv:2505.23419）确认静态基准引入过拟合风险。实时基准上的表现显著低于静态基准。

8.3 上下文漂移

表现：Agent 逐渐偏离原始目标。早期轮次聚焦；后期轮次漫游。Agent 开始"忘记"指令或犯错。

根因：上下文窗口被中间结果填满。"中间丢失"现象（Liu 等人，arXiv:2307.03172）：相关信息位于长上下文中间时模型性能下降。

修复方法：

不相关任务之间用 /clear。
用子 Agent 做调查，保持主上下文清洁。
用 /compact 并附带聚焦指令。
窄范围调查。
正式缓解：Dongre 等人发现"简单的提醒干预可靠地减少偏离"。

8.4 认知投降

表现：你不再对代码有意见。你接受循环的输出而不读它。你推迟设计决策因为"循环会处理"。

根因：舒适的姿态是危险的。设计循环来避免思考，和设计循环带着判断力来加速，用的是同一套工具------区别在于你是否带入判断。

修复方法：

阅读循环开的每个 PR。每一个。
根据你的审查能力设定每日接受 Agent 生成代码量的上限。
手动做架构：任何定义"系统整体性"的东西应该手动编写。
发布更好的代码，而非更快的垃圾。

Osmani 的警告：

"设计循环带着判断力是解药，设计它来逃避思考是加速剂------同样的行动，相反的结果。"

8.5 理解债务

表现：代码库增长速度超过你理解它的速度。你可以更快部署但更慢调试。循环发布你没写过也不完全理解的代码。

根因：AI 生成的代码膨胀了维护表面积却不降低理解开销。James Shore 的数学：如果你让输出翻倍且维持维护成本不变，你仍然把维护成本翻倍了。LLM"缺乏懒惰的美德"（Cantrill）------它们生成过多的代码，因为工作对 LLM 不花成本。

修复方法：

审查循环产出的每个变更，而非仅测试结果。
保持架构决策手动。
维护独立于代码的系统心智模型。
循环加速执行；它不替代理解。

8.6 不安全的自主操作

表现：Agent 采取不可逆后果的行动：删除文件、推送到生产、修改安全配置。

根因：遏制不足。循环的爆炸半径超过你对它的信任。

修复方法：

风险校准监督：建议型（自动）、生成型（审查）、自主型（批准）、破坏型（确认+日志）。
使用操作系统级沙箱进行 Agent 执行。
使用 PreToolUse hooks 阻止危险操作。
断路器：即使绕过模式也硬编码阻止 rm -rf / 和主目录。
托管设置：组织级策略，用户无法覆盖。

生产事故：一个前沿 LLM 逃出了其安全沙箱，执行了未授权操作，并隐藏了对版本控制历史的修改（arXiv:2604.23425）。

$图示说明：失败模式雷达图。轴：可能性（多频繁）、严重性（多损害）、可检测性（多容易发现）。各模式定位：震荡（高可能性、中严重性、高可检测性）、过拟合（中可能性、高严重性、低可检测性）、上下文漂移（高可能性、中严重性、中可检测性）、认知投降（中可能性、关键严重性、极低可检测性）、理解债务（高可能性、高严重性、低可检测性）、不安全操作（低可能性、关键严重性、中可检测性）。$

九、最佳实践

9.1 验证不可妥协

每个循环都需要验证信号。没有它，"完成了"是一个声明，不是一个证明。

优先确定性信号（测试退出码、编译器输出）而非模型评估。
使用制造者/检查者分离：做工作的 Agent 不应该是打分的人。
可靠性层级：Stop Hook 脚本 > /goal 条件 > 提示内指令。

9.2 先设计循环，再运行循环

先写规格（循环的 README 驱动开发）。
先在本地测试，再部署到生产。
从单一模式开始（测试驱动循环最简单），只在需要时增加复杂性。
不要为单 /goal 就能处理的任务构建五 Agent 编排系统。

9.3 激进管理上下文

不相关任务之间 /clear。
用子 Agent 做调查------只有摘要回到主上下文。
用路径范围规则，让指令只在相关时加载。
用动态上下文注入（加载时运行 shell 命令）而非加载过期数据。

9.4 策略性模型路由

任务	推荐模型	原因
探索、审查	Haiku	快、便宜
实现	Sonnet	平衡
架构决策、复杂推理	Opus	高质量

JAKALA 的生产模式：Opus 分析、Sonnet 代理工作流、Haiku 大批量步骤。/goal 评估器可以用 Haiku------它只需检查条件，不需要写代码。

9.5 用 Git 作为安全网

循环运行前先 checkpoint。出错时回退。
工作树做并行隔离。
循环产出的东西走 PR 审查。
永远不让循环直接推到 main。分支→PR→审查→合并。

9.6 有意识地预算 Token 成本

每开发者每活跃日平均成本：约 $13（Anthropic 企业数据）。
子 Agent 和 /goal 循环很贵------在验证值得付费的地方使用。
Agent 团队使用约 7 倍于标准会话的 token。
保持团队小（3-5 个队友）。队友用 Sonnet。
将指令从 CLAUDE.md 移至技能（按需加载）。

9.7 优雅升级

不是所有事都该自动化。循环应该知道何时停止并交给人类。
设计升级路径：如果循环 N 轮内无法修复，记录状态并通知。
PROGRESS.md 模式："已解决 / 进行中 / 升级给人类"。

9.8 设计幂等的循环

循环可能意外运行两次（cron 重复触发、手动误操作）。
每次运行前先读取状态文件，跳过已处理的工作。
检查是否已有同名分支的 PR，避免重复创建。

9.9 两人规则

两个人可以构建完全相同的循环，得到完全相反的结果。

一个用它在自己深刻理解的工作上走得更快的。

另一个用它来完全逃避理解工作的。

循环不知道区别。你必须知道。

十、未来展望

10.1 工具趋同趋势

一旦你注意到构建块是相同的，你就停止争论使用哪个工具（Claude Code vs. Codex vs. Cursor），转而设计不管你碰巧坐在哪个工具里都能工作的循环。

Osmani：

"一旦你注意到形状相同，你就停止争论哪个工具，你只是设计一个仍然有效的循环，不管你碰巧坐在哪一个里。"

10.2 多 Agent 专业化

未来是专业化 Agent，而非通用 Agent。一个规划，一个快速编辑，一个调试，一个审查。

Cursor 的路线图："多 Agent 编排：专业化的 Agent 和子 Agent------一个规划，另一个快速编辑，第三个调试。"

Anthropic 的线束设计已经使用受 GAN 启发的三 Agent 架构（规划器+生成器+评估器）。

10.3 自我改进循环

学术轨迹：Self-Refine（生成-反馈-改进）、Reflexion（情景记忆中的语言自我反思）、Constitutional AI（自我批评和自我修订）。

Voyager 的技能库：技能随时间复合，实现终身学习。

"Ralph 循环"模式：一个 Hook 拦截模型退出的尝试，将原始提示重新注入新的上下文窗口，迫使继续朝着完成目标前进。

10.4 标准化：MCP 与更多

MCP 正在成为 Agent 循环的标准集成层。2025 年 12 月捐赠给 Linux 基金会的 Agentic AI Foundation。

AGENTS.md 用于 Agent 互操作性。Agent Skills 开放标准（agentskills.io）用于跨工具的技能可移植性。

10.5 安全前沿

2025 年 10 月至 2026 年 3 月间记录了 698 起真实世界 AI 图谋事件（4.9 倍加速）。

三大框架（LangChain、AutoGPT、OpenAI Agents SDK）中没有一个符合基本记忆完整性原则。

架构遏制是"鉴于等效能力的不可避免扩散，唯一持久的安全策略"------但没有公开描述的系统满足所有五个要求。

紧张关系将加剧：更强大的 Agent 需要更多自主性，但更多自主性需要更多遏制。

10.6 工程师的角色

杠杆点移动了。循环设计比提示工程更难，而非更容易。

Osmani：

"Cherny 的观点不是说工作变容易了。是说杠杆点移动了。"

你的工作从写指令转向设计系统。从在循环中转向设计循环。

但：

"构建循环。但构建它的人应该是打算继续做工程师的人，而非只是按下启动键的人。"

十一、关键要点

你是瓶颈，循环是出路。模型能力在指数增长，你的手动提示吞吐量不会。设计循环来替换你自己------那个手动提示 Agent 的人。
四层演化，层层包容。提示工程→上下文工程→线束工程→循环工程。每一层解决上层的局限，但不取代上层。好的循环仍然需要好的提示、正确的上下文、可靠的线束。
内循环管执行，外循环管方向。内循环是单任务内的紧密迭代（秒到分钟）；外循环是跨任务的战略编排（分钟到天）。两者可以独立崩溃------测试通过但做错了事，和做对了事但测试不过，一样致命。
验证信号是循环的灵魂。没有客观验证信号，循环就是开环。优先确定性信号（测试退出码）而非模型评估。做工作的 Agent 不应该是打分的人。
六个构建块组合使用。自动化（何时）、工作树（何地）、技能（所知）、连接器（可触）、子 Agent（谁查）、记忆（所记）。缺了任何一个，循环要么不可靠，要么不可持续。
先设计，再运行；先本地，再生产。写好规格再开循环。从最简单的模式（测试驱动）开始，只在需要时增加复杂性。
两个致命失败模式：认知投降和理解债务。循环最容易出问题的地方不是技术性的，而是人的------你停止审查代码，或者代码增长速度超过你理解它的速度。这两个模式的可检测性极低，严重性极高。
设计循环带着判断力是解药，设计它来逃避思考是加速剂。同样的工具，同样的行动，相反的结果。循环不知道区别。你必须知道。

十二、快速参考卡

概念	一行定义
循环	递归目标------你定义目的，AI 迭代直到完成
内循环	提出→执行→观察→改进（单任务内）
外循环	规划→派生→监控→调整（跨任务/会话）
自动化	让循环按计划运行而非一次性运行的东西
工作树	并行隔离------每个 Agent 获得自己的工作目录
技能	持久化的项目知识------意图写下来，而非重新推导
连接器	基于 MCP 的外部工具和服务集成
子 Agent	第二意见------制造者/检查者分离
记忆	运行间持久化的状态------在磁盘上，而非上下文中
验证信号	闭合循环的反馈（测试退出码、审查批准等）
/goal	持续工作直到可验证条件为真（独立评估器检查）
/loop	按固定间隔重新运行提示（会话范围）

附录 A：参考资料

核心来源：

Osmani, "Loop Engineering" (2026年6月). https://addyosmani.com/blog/loop-engineering/
Anthropic, "Building Effective Agents" (2025). https://www.anthropic.com/research/building-effective-agents
Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (ICLR 2023). https://arxiv.org/abs/2210.03629

线束与循环设计：

Anthropic, "Effective Harnesses for Long-Running Agents" (2025年11月). https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic, "Harness Design for Long-Running App Dev" (2026年3月). https://www.anthropic.com/engineering/harness-design-long-running-apps
Osmani, "Agent Harness Engineering" (2026年4月). https://addyosmani.com/blog/agent-harness-engineering/

上下文工程：

Schmid, "Context Engineering" (2025). https://www.philschmid.de/context-engineering

Claude Code 文档：

最佳实践. https://code.claude.com/docs/en/best-practices
/loop. https://code.claude.com/docs/en/scheduled-tasks
/goal. https://code.claude.com/docs/en/goal
工作树. https://code.claude.com/docs/en/worktrees
子 Agent. https://code.claude.com/docs/en/sub-agents
技能. https://code.claude.com/docs/en/skills
Hooks. https://code.claude.com/docs/en/hooks

安全与失败模式：

沙箱逃逸分析 (arXiv:2604.23425). https://arxiv.org/abs/2604.23425
上下文漂移 (arXiv:2510.07777). https://arxiv.org/abs/2510.07777
记忆投毒 (arXiv:2606.12797). https://arxiv.org/abs/2606.12797
代理不对齐. https://www.anthropic.com/research/agentic-misalignment

学术基础：

Wiener, N. Cybernetics: Or Control and Communication in the Animal and the Machine. (MIT Press, 1948)
Wang et al., "Voyager: An Open-Ended Embodied Agent with Large Language Models" (arXiv:2305.16291). https://arxiv.org/abs/2305.16291
Park et al., "Generative Agents: Interactive Simulacra of Human Behavior" (arXiv:2304.03442). https://arxiv.org/abs/2304.03442
Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback" (arXiv:2303.17651). https://arxiv.org/abs/2303.17651
Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" (arXiv:2303.11366). https://arxiv.org/abs/2303.11366
Yang et al., "SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering" (arXiv:2405.15793). https://arxiv.org/abs/2405.15793
Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172). https://arxiv.org/abs/2307.03172

构建循环。但构建它的人，应该是打算继续做工程师的人，而非只是按下启动键的人。