**循环工程详解**作者 Akshay

你刷到的信息流里，突然有一半都在说同一件事：别再对着你的智能体（Agent）写提示词了，去设计循环吧。

打造过全球最热门编程智能体之一的 Boris Cherny 曾直言不讳：“我不再给 Claude 写提示词了。我让循环自己跑，我的工作就是写循环。”

既然打造顶尖编程智能体的人都不再写提示词，那他到底在干什么？

这正是“循环工程”的核心理念。接下来，我们来拆解一下为什么它比表面看起来要难得多。

**首先，循环本身**

智能体不是什么魔法盒子。它的核心就是一个普通的 `while` 循环：```pythonwhile True: response = model(context) if response.has_tool_calls(): results = run_tools(response.tool_calls) context += results else: break```模型读取上下文，请求调用工具。你运行工具并将结果喂回给模型。模型再次读取，如此反复，直到它不再请求调用工具为止。

模型 → 工具 → 上下文 → 循环往复。

这里有个让人意外的地方：这个循环本身早就不是难题了。每个严肃的智能体框架最终都会收敛到上面这六行代码左右。没有人会在 `while` 语句上展开竞争。

既然循环如此简单，大家到底在“工程”什么？

**工作重心已转移到模型之外**

AI 的核心重心正在不断偏离模型本身。

- **提示词工程（Prompt engineering）**：你发送的文本。- **上下文工程（Context engineering）**：模型看到的所有内容，而不仅仅是你的指令。- **执行框架工程（Harness engineering）**：包裹在模型外围的代码，负责运行工具、追踪状态和处理错误。- **循环工程（Loop engineering）**：驱动整个系统迈向目标的自主运行周期。

每一层都包裹着内层。你并没有不再关心提示词，只是意识到提示词只是一个庞大系统里的一小块拼图。

LangChain 总结得很到位：智能体 = 模型 + 执行框架。如果你不是模型本身，那你就是在做执行框架。

这里有一个应该重塑你优先级的发现：**执行框架现在比模型更重要**。许多团队保持模型不变，只修改周围的代码，就能在基准测试中从垫底一跃进入前五。同样的“大脑”，不同的“循环”。

循环工程，就是为这个“大脑”构建整个运行环境的学科。让我来展示一下真正容易出问题的环节。

**难点一：知道何时该停止**

这是没人警告过你的问题。

当智能体不再请求调用工具时，它只是结束了“当前轮次”。这并不等于“完成了任务”。

想象一个编程智能体：它写了一些代码，环顾四周，看到有进展，就宣布完工了。但测试依然失败。它还是宣告了胜利。

一条终端消息结束了轮次，但没有结束任务。混淆这两者，是循环出错最常见的原因。

优秀的循环会因为“正确的原因”而停止，因此你需要叠加几道刹车机制：- **最大迭代次数**：硬性上限，防止卡住的智能体无限运行。- **预算和时间限制**：为 Token、资金和运行秒数设定天花板。- **无进展检测**：如果它用相同的参数重复相同的调用，说明它在空转。- **真正的完成度检查**：一个能证明任务已完成的自动化条件。

最后一点至关重要。“完成”应该意味着测试通过，而不是智能体对自己的工作感觉良好。

**难点二：保持上下文干净**

长循环会从内部腐烂。

智能体运行的轮次越多，上下文里堆积的垃圾就越多，比如过期的工具输出、死胡同和失效的推理。随着这堆垃圾的增长，模型的表现会下降。业界称之为“上下文腐烂（Context rot）”。

循环会使其陷入恶性循环。腐烂的上下文导致更差的决策，进而产生更多噪音，进一步加剧上下文腐烂。人们称之为“末日循环（Doom loop）”，你肯定体会过：智能体运行时间越长，表现就越蠢。

对抗它的方法是：把上下文当作“预算”来管理，而不是一个无底洞：- **压缩（Compaction）**：对话变长时进行摘要总结，然后基于摘要继续。- **卸载（Offloading）**：将巨大的输出推送到文件中，上下文中只保留你需要的切片。- **子智能体（Sub-agents）**：把混乱的子任务交给独立的智能体，只让它返回干净的结果。

人的直觉是“以防万一，全都留着”。但真正的技巧在于知道该扔掉什么。

**难点三：提供智能体真正能用的工具**

循环的上限，取决于里面工具的质量。

塞给它一百个工具，智能体就会迷失，不知道该用哪个。一套精简、专注且不重叠的工具才是赢家。Anthropic 的经验法则很犀利：如果连人类工程师都无法确定该用哪个工具，智能体就更没戏了。

有两点比人们预期的更重要：- **让写入操作支持安全重试**。循环会重试，如果重试“创建客户”时又建了一个，你醒来就会发现重复的记录和双倍扣费。任何改变状态的操作都必须支持安全地调用两次。- **错误信息写给智能体看，而不是人类**。好的错误信息会告诉智能体下一步该怎么做。在工具上线前，问一问：大语言模型读到这个报错，知道下一步该怎么走吗？

在循环中，错误不是死胡同，而是下一步的指令。

**难点四：需要一个能说“不”的机制**

自主循环有一种隐蔽的失败模式：如果任由智能体自己运行，它往往会盲目认同自己。

整场辩论中最一针见血的评论是：“设计循环只完成了一半的工作，另一半是在循环中放入一个能说‘不’的东西，比如测试、类型检查或硬性报错。”

没有批评者的循环，只是一个智能体在对自己的工作连连点头。

解决办法是**将“制造者”与“检查者”分离**。一个模型负责干活，另一个检查机制（通常是单独的模型或硬性测试）负责打分。干活的人不能自己批改作业。

**真正的转变**

现在，Cherny 的那句话就说得通了。

写提示词，是你一步步手动驾驶智能体；循环工程，是你构建自动驾驶系统，然后退居幕后。

你的工作从“给出指令”变成了“设计三样东西”：1. **目标**：写成智能体可以自我核对的成功标准。2. **循环**：配备合理的刹车机制，确保它能妥善停止。3. **验证器**：让“完成”是被证明的，而不是被宣称的。

Andrej Karpathy 完美概括了这种心态：别告诉模型该怎么做，给它成功标准，然后看它自己跑。他会让研究循环在夜间自动运行：修改脚本、测试、保留有效的、丢弃无效的，而他自己完全不在循环中。他只需配置一次，然后按下启动键。

这就是核心转变。你不再是那双“手”，而是设计这台机器的人。

**从哪里开始**

你不需要第一天就搞出一个彻夜自主运行的智能体。可以循序渐进：1. 从基础循环开始，立刻加上最大迭代上限、超时机制和成本天花板。2. 在开始运行前就把“完成”定义为自动化检查，而不是事后凭感觉判断。3. 保护上下文。压缩长运行，卸载大输出，隔离混乱的子任务。4. 审查你的工具。保持精简专注，确保写入操作可安全重试，重写错误信息以便智能体能据此采取行动。5. 在循环中加入批评者。只有当你信任那个能说“不”的机制时，才能完全放手。

**核心要点**

循环工程不是一个框架，也不是一个安装就能用的工具。它是你发力重心的转变。

模型正在变成大宗商品。围绕它的循环，才是真正体现工程价值的地方。

最优秀的构建者不再问“我该告诉智能体做什么？”，而是问“**如果没有我，什么系统能做成这件事？**”

把这个问题回答好，你也会停止写提示词的。

下图是这份报告的摘要