循环工程（Loop Engineering）详解

你的信息流突然全在说同一件事。别再提示你的智能体了，开始构建循环吧。

Boris Cherny，Claude Code 的创造者，说得直截了当：“我不再提示 Claude 了。我运行着循环。我的工作就是编写循环。”

这位地球上最流行的编码智能体之一的创造者都不提示它了。那他到底在做什么？

这就是循环工程背后的全部理念。现在我们来分析一下，为什么它比看起来要难得多。

首先，循环本身

智能体不是一个魔法盒子。在核心层面，它只是一个简单的循环：

python while True: response = model(context) if response.has_tool_calls(): results = run_tools(response.tool_calls) context += results else: break

模型读取上下文。它要求调用工具。你运行工具并将结果反馈回去。模型再次读取，如此重复，直到它不再请求工具。

模型 → 工具 → 上下文 → 重复。

这里有一点会让很多人感到意外。这个循环已经被解决了。 每个严肃的智能体框架最终都会落地到大致这六行代码上。没有人会在 while 语句上竞争。

所以，如果循环本身是微不足道的，那大家究竟在工程化什么呢？

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

人工智能的重心一直在从模型本身向外漂移。

• 提示工程（Prompt engineering）。 你发送的文字。

• 上下文工程（Context engineering）。 模型看到的一切，不仅仅是指令。

• 框架工程（Harness engineering）。 模型周围运行工具、追踪状态、处理错误的代码。

• 循环工程（Loop engineering）。 驱动整个系统朝着目标前进的自主循环。

每一层都包裹着前一层。你并没有停止关心提示。你只是意识到，提示只是一个更大系统中很小的一部分。

LangChain 说得很清楚。智能体 = 模型 + 框架。如果你不是模型，你就是框架。

这里有一个发现，应该让你重新排列优先级。框架现在比模型更重要。 团队保持模型不变，只改变模型周围的代码，就能从基准测试的中游跃升到前五名。同一个大脑，不同的循环。

循环工程就是构建大脑运行所需一切环境的学科。让我展示一下实际出问题的部分。

难点一：知道何时停止

这是没人提醒你的问题。

当一个智能体停止请求工具时，它的本轮交互就结束了。但这并不等同于完成了任务。

想象一个编码智能体。它写了一些代码，环顾四周，看到取得了进展，然后宣布完成了。但测试仍然失败。它还是宣告了胜利。

终端消息结束的是本轮交互，而不是任务。 混淆这两者是最常见的循环出错方式。

良好的循环会因正确的理由停止，所以你需要叠加几个刹车机制：

• 最大迭代次数。 一个硬性上限，防止卡住的智能体无限运行。

• 预算和时间限制。 代币、金钱和时间的上限。

• 无进展检测。 如果它用相同的参数重复调用相同的工具，那就是在空转。

• 真正的完成检查。 一个自动化的条件，证明任务已经完成。

最后一项承担了大部分重量。“完成“应该意味着测试通过，而不是智能体自我感觉良好。

难点二：保持上下文清洁

长循环会从内部开始腐烂。

智能体运行的轮次越多，堆积到上下文中的垃圾就越多，比如旧的工具输出、死胡同、陈旧的推理。随着垃圾堆积，模型性能下降。这个领域称之为上下文衰减（context rot）。

循环会加剧这种螺旋。衰减的上下文会产生更糟糕的决策，决策又增加更多噪音，噪音进一步腐烂上下文。人们称之为“厄运循环（doom loop）“，你肯定感受过。智能体运行得越久，就越笨。

对抗它的方法是将上下文视为预算，而不是一个桶：

• 压缩（Compaction）。 当对话变长时进行总结，然后从总结继续。

• 卸载（Offloading）。 将巨大的输出推到文件中，只保留你需要的片段。

• 子智能体（Sub-agents）。 将混乱的子任务交给一个单独的智能体，只让其干净的结果返回。

本能是保留一切，以备不时之需。但真正的技能在于知道该丢掉什么。

难点三：智能体能真正使用的工具

一个循环的好坏，取决于其中的工具。

堆积一百个工具，智能体就会搞不清该用哪个。一套精炼、专注、不重叠的工具才能取胜。Anthropic 的经验法则很尖锐：如果一个人类工程师都不能确定哪个工具合适，那智能体更没戏。

有两件事比人们预期的更重要：

• 让写操作可安全重复。 循环会重试，如果重试的“创建客户“调用产生了第二个客户，你醒来就会发现重复记录和双重计费。任何改变状态的操作都必须安全，可以多次调用。

• 为智能体而不是人类编写错误信息。 一个好的错误信息会告诉智能体下一步该做什么。在工具上线前，问问自己：一个 LLM 读到它的报错，能否知道下一步行动？

在循环中，错误不是死胡同。它是下一个指令。

难点四：能说“不“的东西

自主循环有一个寂静的失效模式。一个被独自留下的智能体倾向于自我肯定。

整个讨论中最犀利的评论一针见血。设计循环是工作的一半，另一半是在循环中放入能说“不“的东西，比如测试、类型检查或真正的错误。

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

解决办法是将制造者和检查者分开。一个模型做工作。另一个不同的检查，通常是另一个模型或硬性测试，来评估它。工作者不给自己的作业打分。

真正的转变

现在 Cherny 的话就说得通了。

提示是你一步步地引导智能体。循环工程是你构建一个能自我引导的系统，然后退居幕后。

你的工作从下达指令，转变为设计三件事：

• 目标（The goal）， 写成智能体可以自我核验的成功标准。

• 循环（The loop）， 配备合理的刹车，以便它能良好地停止。

• 验证器（The verifier）， 确保“完成“是被证明的，而非声称的。

Andrej Karpathy 捕捉到了这种心态。不要告诉模型该做什么，给它成功标准，然后看着它执行。他通宵运行研究循环，自动调整脚本、测试、保留有效部分、丢弃无效部分，而他自己完全不在循环内。他一次性安排好，然后启动。

这就是全部转变。你不再是那双执行的手，而是成为设计机器的人。

如何开始

你不需要在第一天就实现一个通宵自主的智能体。循序渐进：

• 从基本循环开始， 并立即添加最大迭代次数限制、超时和成本上限。

• 将“完成“定义为一个自动化检查， 在开始之前就定义好，不要靠事后的感觉。

• 保护上下文。 压缩长运行，卸载大输出，隔离混乱的子任务。

• 审计你的工具。 保持数量少且专注，让写操作可安全重复，重写错误信息以便智能体能据此行动。

• 在循环中放入一个批评者。 只有在信任那个能说“不“的东西之后，才进入完全放手模式。

核心要点

循环工程不是一个你可以安装的框架或工具。它是一种努力方向的转变。

模型正在变成一种商品。它周围的循环才是真正工程学现在所在之处。

最优秀的构建者不再问“我应该告诉智能体做什么？“ 他们开始问“什么样的系统可以代替我完成这件事？“

如果你能很好地回答这个问题，你也会停止提示。

以下是关键要点的总结。

循环工程中的关键要点。

循环工程中的关键要点。

感谢阅读！

干杯 :) Akshay.