从 Loop Engineering 到 Agent Teams：构建自迭代的 AI 协作系统
一、什么是 Loop Engineering
起源：两句话掀起的浪潮
2026 年 6 月，AI 编程社区被一个概念点燃——Loop Engineering。
引爆点来自两句话。先是 Anthropic Claude Code 负责人 Boris Cherny 在一次公开演讲中说道：
"I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude and figuring out what to do. My job is to write loops."
（我不再直接提示 Claude 了。我有一套 Loop 在运行，它们负责提示 Claude 并决定下一步做什么。我的工作是编写 Loop。）
几天后，开发者 Peter Steinberger——开源 AI Agent 项目 OpenClaw 的创作者——发了一条十二个字的推文：
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
（你不应该再手动提示 AI 编程助手了。你应该设计让 Agent 自己提示自己的 Loop。）
这两句话精准地描述了一种很多人已经感受到但尚未命名的趋势：提示词写得好不好，已经不是瓶颈了；瓶颈在于你为 Agent 设计的整套运行系统。
随后，Google 工程师 Addy Osmani 将这一实践正式命名并系统化为 Loop Engineering，使其成为独立的工程学科。
AI 工程的演进
Loop Engineering 并非凭空而来，它是 AI 工具能力演进的自然结果：
| 阶段 | 核心思想 | 关注点 | 人的角色 |
|---|---|---|---|
| Prompt Engineering | 通过设计提示词获得更好的输出 | 怎么问问题 | 提问者 |
| Context Engineering | 组织并提供完整背景信息 | 给 AI 什么信息 | 信息组织者 |
| Harness Engineering | 连接模型、工具、数据形成工作流 | 如何调用能力 | 系统设计者 |
| Loop Engineering | 构建目标驱动的自主闭环系统 | 如何持续完成目标 | 规则制定者 |
什么是 Loop
一个 Loop 是一个递归目标系统：你定义一个目的，Agent 不断迭代，直到工作真正完成。
每个 Agent 在执行任务时已经内置了一个"内循环"：感知 → 推理 → 行动 → 观察，然后再次循环。Loop Engineering 工作在这个内循环的上一层：
- 内循环（Agent 内置）：Agent 自身驱动，读文件 → 修改代码 → 运行测试 → 读错误 → 再修改
- 外循环（你来设计）：你设计的系统驱动，按计划发现任务 → 分派 Agent → 验证结果 → 记录状态 → 开启下一轮
你不再坐在 Agent 旁边为每一步打下一条指令。你在设计一套外部系统，它替你驾驶内循环，而你去做更有判断价值的事。
四个层次的循环
LangChain 在其博客中系统性地将 Loop Engineering 拆解为四个可叠加的循环：
- Agent Loop（智能体循环）——最基础的循环，模型反复调用工具直到任务完成，实现自动化工作。
- Verification Loop（验证循环）——在智能体外层包裹一个"评分器"，对照标准检查输出，不达标时把反馈发回模型重试，保证质量。
- Event Driven Loop（事件驱动循环）——通过事件（新文档、定时任务、webhook）触发智能体运行，使其成为持续运行的系统组件。
- Hill Climbing Loop（爬山循环）——每次智能体运行都会产生 trace，分析智能体审查这些 trace，发现问题后直接改进内部的 prompt 或工具配置，实现自动化改进。
关键洞察在于：返回箭头不只是回到起点，而是深入内部直接更新智能体循环。 每一轮外层循环都让内层循环变得更有效。
二、什么是 Agent Teams
基本概念
Agent Teams 是 Claude Code 的一项实验性功能，它允许你协调多个 Claude Code 实例一起工作。一个会话充当团队负责人，协调工作、分配任务和综合结果。队友独立工作，每个都在自己的 context window 中，并直接相互通信。
与 Subagents 不同（Subagents 在单个会话中运行，只能向主代理报告），Agent Teams 的队友可以直接相互通信，共享任务列表，认领工作并进行讨论。
适用场景
Agent Teams 最适合用于并行探索能增加真实价值的任务：
- 研究和审查：多个队友可以同时调查问题的不同方面，然后分享和质疑彼此的发现
- 新模块或功能：队友可以各自拥有一个独立的部分，不会相互干扰
- 使用竞争假设进行调试：队友并行测试不同的理论，更快地收敛到答案
- 跨层协调：跨越前端、后端和测试的更改，每个由不同的队友负责
角色模型
在 Agent Teams 的架构中，天然存在以下角色：
- Leader（负责人）：接收需求，分析需求，协调团队，分配任务，综合结果
- Teammate（队友）：独立执行任务，在各自 context window 中工作，可以相互通信和协作
这种架构为我们实现 Loop Engineering 提供了天然的土壤。
三、用 Agent Teams 实现 Loop Engineering 的可行性
核心思路
Agent Teams 本身就支持多 Agent 协同，并且存在一个 Leader 角色来统筹全局。因此，我们可以通过合理配置，将 Agent Teams 改造成一个具备 Loop Engineering 能力的系统。
最基本的实现方式是配置一个具备 Leader → Plan → Execute → Verify 四个角色的团队：
| 角色 | 职责 |
|---|---|
| Leader | 接收需求，分析需求，传递给 Plan 角色 |
| Plan | 消化需求，分析上下文，形成可行性较高的执行方案 |
| Execute | 负责执行方案，并生产最终产物 |
| Verify | 负责验证产物是否满足需求 |
这样的架构本质上就是一个外循环系统：Leader 接收目标 → Plan 设计方案 → Execute 执行产出 → Verify 检查结果。每一轮循环都是对目标的逼近。
为什么 Agent Teams 天然适合
Agent Teams 相比传统单 Agent 模式的几个关键优势，使其成为 Loop Engineering 的理想载体：
- 独立的上下文窗口：每个 Agent 拥有自己的 context window，避免了一个巨大上下文带来的 token 浪费和注意力稀释
- 并行工作能力：多个 Agent 可以同时工作，互不干扰
- 直接通信：队友之间可以直接传递信息和结果，无需经过 Leader 中转
- 自我协调：共享任务列表让团队能够自我管理任务分配
四、为什么不用 Goal
什么是 Goal
Claude Code 的 /goal 命令允许你设置一个完成条件，Claude 会在没有你逐步提示的情况下持续朝着这个目标工作。每个回合后，一个小型快速模型会检查条件是否满足；如果不满足，Claude 会开始另一个回合，直到条件满足为止。
Goal 的局限性
虽然 Goal 提供了基础的循环能力，但它存在几个关键问题：
1. 缺乏迭代空间
Goal 本质上是以完成单次目标作为前进方向，不存在真正的迭代空间。它的工作方式是"朝着目标直行"，而不是"在循环中不断优化"。当目标达成时，循环就结束了——没有回顾、没有总结、没有下一次迭代的改进。
2. 上下文膨胀问题
在单一 Goal 的任务下，Leader 需要维护一个极其庞大的上下文。随着回合数增加，所有历史对话、中间结果、失败尝试都堆积在同一个 context window 中，导致：
- Token 消耗急剧增加，成本飙升
- 模型注意力被稀释，越往后越容易遗漏关键信息
- 当 context window 逼近上限时，早期的信息可能被"遗忘"
3. 缺少内省和改进机制
Goal 没有内置的"从失败中学习"的能力。如果某个策略失败了，它只会尝试不同的做法，但不会分析失败原因，不会将经验沉淀下来改进未来的行为。
为什么 Agent Teams 更适合
Agent Teams 则不一样，稍加改造，可以实现自我迭代功能模块：
- 上下文隔离：通过任务分离到各个 Agent 身上，Leader 只需要维护需求 ↔ Agent 之间的任务关系，不参与实际 Agent 工作，Token 消耗更低
- 角色专业化：不同的角色（Plan、Execute、Verify）各自专注于自己的领域，互不干扰
- 可扩展性：可以随时添加新的角色来扩展系统的能力
五、改造：引入 Iteration 角色
当前的问题
在第三节中，我们探讨了 Agent Teams 对于 Loop Engineering 的最小化实现，Leader → Plan → Execute → Verify 构成了一个完整的工作流。但是，目前的架构依然不具备自我迭代的能力，因为从 Leader 到 Verify 依然只是单线任务，本质上与 Goal 模式没有区别——完成了就结束了。
引入 Iteration Agent
为了解决这个问题，我们需要引入一个新的 Agent 角色：Iteration。
Leader → Plan → Execute → Verify → Iteration → (下一轮)
Iteration 角色负责在 Verify 验证产物之后，进行以下工作：
- 回顾分析：分析本轮产物的质量、Verify 的反馈、执行过程中遇到的问题
- 功能探索：基于当前产物的状态，探索可以改进的方向或可以添加的新功能
- 制定新需求：将探索结果转化为下一轮的需求，传递给 Leader
- 启动下一轮：将新需求交给 Leader，开始新一轮的 Plan → Execute → Verify 循环
这样，系统就从一个"单次执行系统"变成了一个"持续迭代系统"——这正是 Loop Engineering 的核心精髓。
迭代循环的工作流程
六、引入知识库与审计机制
面临的问题
经过前面的改造，我们实际上已经实现了一个 Loop Engineering 系统。但仅靠迭代循环还不够，最终产物的质量可能差强人意。原因有二：
- 没有审计：只关注产物是否"可用"，不关注代码质量、可维护性、安全性
- 没有知识库/规范：每次 Loop 的功能模块实现方式存在差异，缺乏一致性
知识库
核心概念
在 AI Agent 工程中，知识库的核心思想可以用以下要点概括：
- AGENTS.md 是"目录"，不是"百科全书"：约 100 行的 AGENTS.md 注入上下文，指向结构化 docs/ 目录中的深层知识源
- 当 Agent 遇困时的黄金法则：从不回答"再试一次"，而是问"缺少什么能力，如何让它对 Agent 既可读又可执行？"
- 三大支柱：上下文工程 + 架构约束 + 垃圾回收（熵治理）
- 核心洞察：仓库之外的知识对 Agent 来说不存在——Slack 讨论、Google Docs、脑子里的决策，统统要版本化进仓库
在 Loop 中应用知识库
我们需要根据现有的项目，建立合适的知识库来规范 AI 的工作。具体来说：
- 在 Plan 阶段：Plan Agent 消化需求并形成执行方案时，必须基于知识库制定，确保所有代码都约束在一套框架下
- 知识库内容：包括代码规范、架构设计原则、命名约定、测试标准、安全要求等
- 持续更新：Iteration Agent 在回顾时，也可以将"学到的经验"更新到知识库中，让下一次迭代做得更好
代码审计：引入 Code-Auditer Agent
对于实际应用，我们不仅仅是一个简单的 Execute Agent 去实现所有代码工作。在复杂项目中，我们可能需要细分 Frontend 和 Backend。因此，针对不同领域的 Agent 独立引入代码审计非常有必要。
为什么需要专门的审计
- AI 自己生产代码，自己检查：AI 很有可能直接说服自己"我的代码一定没问题"，缺乏客观性
- 上下文污染：AI 自己生产代码、自己检查、自己修改，会导致整个工作流混乱，上下文严重污染
- Code-Auditer 只审计代码：不参与实际开发与需求理解，收到的上下文污染较低，审计结果更客观
工作流程
最终架构
整合所有改进后，完整的系统架构如下：
后话
Loop Engineering 代虽然可以很好的限制代码发挥以及工作流程，但是现阶段整体运行效率较低，很大程度上在于流程的繁琐性。但是如果不这样限制，大模型有时候还是很容易跑偏的，只能希望国内的模型一步步发展的更好吧。