循环工程的本质：从自动化到可控智能体系统

过去两年，开发者圈子里新名词的迭代速度几乎超过了学习速度。前年大家还在讨论提示工程，去年上下文工程成为热词，今年三月又冒出了循环工程。每一个新词都宣称自己才是用好人工智能的关键。但如果把炒作的水分挤掉，会发现这些概念之间并不是替代关系，而是同一件事在不同阶段的侧重点。提示工程解决的是”怎么问”，上下文工程解决的是”给模型看什么”，而循环工程解决的是”怎么让模型持续地、可靠地做完一件事”。本文尝试把循环工程拆开，看看它到底在工程什么，以及一个真实的循环应该如何搭建。

一、四个工程，各在工程什么

要理解循环工程，先要把它放回演进的链条里。

提示工程关注单次交互的输入构造。它研究的是如何通过指令、示例、格式约束，让模型在一次调用中给出更符合预期的输出。它的边界很清晰：一次提问，一次回答。

上下文工程把视野扩大到模型的整个输入窗口。它关心的不只是那句提示，还包括检索到的文档、历史对话、工具返回结果、系统约束等。核心问题是：在有限的上下文预算里，放哪些信息能让模型表现最好。

循环工程则再往前一步。它承认一个现实：复杂任务不可能靠一次模型调用完成，甚至不可能靠一次精心构造的上下文完成。任务需要多轮执行、需要工具调用、需要中间结果回传、需要错误重试。循环工程要解决的是，如何设计这个反复执行的过程，使它既自动化又可控。

智能体工程是更上层的概念，它把循环、工具、记忆、角色分工整合成一个能自主行动的系统的总称。循环工程是智能体工程的核心子集，也是它真正运转起来的心跳。

四者不是谁取代谁，而是抽象层级不同：提示工程管一次输入，上下文工程管一次调用的信息环境，循环工程管多次调用的编排，智能体工程管整个系统的行为。

二、循环到底是什么

一个循环，本质上是一个”执行—观察—决策—再执行”的反复过程。用伪代码表达，它的骨架非常朴素：

while not task_done:
    context = build_context(memory, tools, task)
    action = model.decide(context)
    result = execute(action)
    memory.update(result)
    task_done = evaluate(result)

真正难的不是这个骨架，而是让这个骨架在真实环境里稳定运行所需的六个组件。它们分别解决六个不同层面的问题。

第一件：自动化，循环的心跳

没有自动化，循环就只是一次性脚本。自动化的含义是：循环能够自己触发、自己推进、自己判断是否继续。它需要一套调度机制来决定何时启动、何时暂停、何时终止，还需要明确的终止条件，否则循环会陷入无限重试或空转。

工程上的关键点在于：终止条件必须可判定，而不是依赖模型的模糊判断。常见做法是设置最大轮次、成功标志、错误预算三重保险。自动化不是让模型为所欲为，而是给它设定清晰的边界和节奏。

第二件：工作树，让并行不变成打架

当多个循环或同一循环的多个分支同时操作文件、数据或资源时，冲突几乎不可避免。工作树的作用是为每个执行单元提供隔离的工作空间，使并行任务互不干扰，最后再通过合并策略收敛结果。

这背后的工程思想与版本控制中的分支隔离一致：每个分支在自己的副本上修改，合并时处理差异。没有隔离，并行带来的是混乱；有了隔离，并行才真正带来吞吐。

第三件：技能，治好智能体的金鱼记忆

模型本身不擅长记住”这件事该怎么做”。每次调用都是相对独立的推理。技能就是把可复用的操作流程、领域知识、工具用法封装成模型可以按需加载的模块。

技能的价值在于把隐性知识显性化。与其在每次提示里重复描述步骤，不如把步骤固化成技能，让模型在需要时调用。这既节省上下文预算，也提高了一致性。技能是循环从”每次重新摸索”走向”按规程执行”的关键。

第四件：连接器，让循环摸到真实世界

模型本身只能处理文本，无法直接读写数据库、调用接口、操作文件系统。连接器就是循环与外部世界之间的桥梁，把模型的动作翻译成真实的系统调用，再把结果翻译回模型能理解的形式。

连接器的工程挑战在于可靠性和安全性：调用可能失败、可能超时、可能返回意料之外的数据。一个健壮的连接器需要处理重试、超时、鉴权、结果校验。循环能否落地，很大程度上取决于连接器是否扎实。

第五件：子智能体，写的人和查的人必须分开

让同一个执行者检查自己的工作，效果往往有限。子智能体模式把执行与审查拆成不同角色：一个负责生成方案或代码，另一个负责独立验证、挑错、提出改进。

这种分工的价值在于引入对抗性视角。审查者不受生成者思路的束缚，更容易发现盲点。在工程上，这意味着循环内部可以有多个不同职责的智能体，各自有独立的上下文和目标函数，最后通过某种协商或裁决机制收敛。

第六件：记忆，循环的命根子

如果循环每一轮都忘记上一轮发生了什么，它就永远在原地打转。记忆负责保存历史动作、中间结果、失败教训和成功经验，使后续决策建立在积累之上。

记忆通常分层：短期记忆保存当前任务的上下文，长期记忆沉淀跨任务的知识。工程难点在于写入什么、何时写入、如何检索、如何遗忘。记忆管理不当，要么上下文爆炸，要么关键信息丢失。

三、拼起来之后，一个真实的循环长什么样

把六个组件组装起来，一个可运行的循环大致是这样的：

1. 调度器触发任务，初始化工作树，为本次执行创建隔离空间。
2. 循环从记忆中加载相关技能和历史上下文，构建当前决策所需的输入。
3. 主智能体根据输入决定下一步动作，可能是生成内容、调用工具或委派子任务。
4. 连接器执行动作，把结果写入工作树和记忆。
5. 若涉及验证，子智能体独立检查结果，提出反馈。
6. 循环根据反馈决定继续、修正还是终止。
7. 终止后，工作树合并回主分支，记忆沉淀本次经验。

这个流程里，自动化提供节奏，工作树提供隔离，技能提供方法，连接器提供触达，子智能体提供制衡，记忆提供连续性。缺任何一环，循环都会在某个环节卡住。

四、工具已经追上来了，现在就能搭

好消息是，搭建一个基础循环的门槛已经大幅降低。多数云平台和开发框架都提供了调度、隔离环境、工具调用接口、状态管理等通用能力。开发者不需要从零实现所有组件，而是可以基于通用能力快速组装。

一个最小可行的起步路径是：

• 用支持定时或事件触发的调度能力作为心跳。
• 用容器或独立工作目录实现隔离。
• 把常用操作封装成可复用的函数或配置，充当技能。
• 通过标准接口调用外部服务，充当连接器。
• 先只做一个执行角色，验证流程跑通后再引入审查角色。
• 用简单的键值存储或文件记录中间状态，充当记忆。

三十秒搭出一个能跑的循环是可能的，但搭出一个可靠的循环需要持续打磨。

五、三盆冷水：循环越好用，这三个问题越尖锐

循环工程不是银弹。它越顺滑，三个问题反而越突出。

第一盆：验证仍然归你。 循环可以自动执行、自动重试，但”结果是否正确”这个判断，最终仍需人来定义标准。如果验证标准本身模糊，循环只会更快地生产出看似合理但未经确认的结果。自动化放大的是执行力，不是判断力。

第二盆：理解债，越顺滑涨得越快。 当循环自动完成越来越多步骤，开发者对中间过程的了解会逐渐减少。系统越顺滑，越容易形成”它能跑就行”的心态。一旦出问题，排查成本会高得惊人。理解债不会自动偿还，只会越积越多。

第三盆：认知投降，最舒服的姿势最危险。 循环降低了参与门槛，也降低了参与深度。当人习惯性地接受循环的输出而不加审视，批判性思考就会退化。最舒服的使用方式，往往是最危险的。工具越强，越需要使用者保持清醒。

结语

循环工程的本质，是把模型能力从”一次性的聪明”转化为”持续性的可靠”。它不神秘，也不轻松。六个组件各有其工程难点，三大风险各有其现实代价。真正用好循环的人，不是把一切交给自动化的人，而是清楚知道哪些环节必须自己把关的人。新词会继续出现，但底层的问题始终是那几个：如何编排、如何隔离、如何验证、如何积累、如何保持理解。想清楚这些，比追逐下一个热词更有价值。