什么是循环工程？AI智能体自动化工作流全解析

提示词工程的热度还没退，一个新概念已经在AI开发圈里悄悄冒头——循环工程（Loop Engineering）。它被不少人看作是提示词工程的升级版：不再纠结于写出某一条完美提示词，而是设计一套系统，让AI智能体在目标、行动、观察、调整的闭环里自己跑起来。

这个说法来自B站UP主的一期科普视频，核心观点很明确：循环本身只有四个阶段，并不复杂，真正值得工程化的是围绕循环搭建的那一整套组件，以及人类在环路中不可让渡的职责。下面逐层拆解。

从提示词工程到循环工程：思路的转变

提示词工程的范式是"人写一条完美提示词 → 模型返回结果 → 人再写下一条"，人始终在驱动循环。循环工程则把驱动权交给系统：给智能体派一个任务，系统负责检查它的工作成果，再自动给它发下一条提示词，往复循环直到完成，人工干预被压到极低。

用视频里的例子说：一个结算服务有一堆单元测试挂了，任务就是让这些测试全部通过。循环从此启动——智能体打开文件、修改代码（行动），运行测试观察输出（观察），根据结果决定下一步（调整）。测试变绿就处理下一个，还是红的就换个修法再来一轮。这个"目标—行动—观察—调整"的四阶段闭环，本身确实简单得不像一门"学科"。

好目标是循环的锚点

循环每转一圈，目标都会被重新评估一次，它直接决定智能体是继续还是收工。所以目标必须可验证、有停止条件。"让结算快一点"是典型的坏目标——没有可衡量的检验标准，智能体可能永远绕下去，也可能跑一轮就宣布胜利。"当结算套件里每个单元测试都通过时停止"才是好目标，智能体能明确判断达成与否。

这一条看似基础，却是整个循环能否收敛的前提。目标模糊的循环，跑得越快偏得越远。

围绕循环的工程组件

真正撑起"工程"二字的，是循环外面的这套基础设施。

触发器：让循环自己启动

循环需要一个启动器。最常见的是定时调度，比如每晚跑一次结账循环，很多团队用传统定时任务就能实现。另一种是事件驱动的钩子——文件变动、拉取请求创建等特定事件发生时自动触发。视频提到，开发者主要把钩子用在安全和质量场景，比如强制执行策略。

上下文管理：对抗信息堆积

每绕一圈都会产生新的上下文——测试输出、文件内容、日志，越堆越多，智能体的注意力会被稀释。上下文工程要解决的就是"挑哪些内容真正喂给循环"。手段包括压缩，以及渐进式披露（类似智能体技能的做法：把某个重复性任务怎么做写成说明，按需展开）。

渐进式披露（progressive disclosure）借鉴自交互设计与文档写作，指不一次性把所有信息塞给使用者，而是先给概要，待需要时再逐层展开细节。在智能体场景中，它的典型形态是“智能体技能”（Agent Skills）：把某类重复任务的完整操作说明写成独立文档，主提示词里只保留一句简短索引，等循环真正遇到该任务时再读取全文。这样做的好处是每轮上下文窗口只承载当前决策必需的信息，避免测试日志、历史记录等长尾内容挤占注意力。与之配合的压缩手段则是对已有上下文做摘要或裁剪，两者一“按需取用”、一“事后瘦身”，共同对抗循环中信息随轮次线性膨胀的问题。

主干：持久化的记忆

视频里把循环内的一种持久化状态称作"主干"，可能是几个markdown文件，智能体在里面记录自己做了什么、成没成功。这些记录为后续迭代提供参考：什么奏效了，什么可能不奏效。没有它，智能体每一轮都在失忆状态下重新摸索。

这里的“主干”对应智能体领域常说的外部持久化记忆（external memory / scratchpad），区别于模型权重内隐的知识和单次对话的上下文窗口。用 markdown 文件等纯文本形式保存状态有几个实际优势：人类可直接阅读和编辑，便于审计；不依赖特定厂商的存储接口，可版本化管理；出问题时能回溯每一轮的决策依据。它与上下文管理是互补关系——主干负责“记住什么”，上下文管理负责“这一轮喂什么”，前者是全量存档，后者是按需检索。缺乏持久化记忆时，智能体在多轮循环中容易重复踩同一个坑，或在长任务后期丢失早期结论。

工具访问：连接外部世界

行动阶段往往需要调用外部资源，通过工具访问实现——用MCP（模型上下文协议）这类标准，或直接走API做工具调用。执行代码、访问文件系统、在终端跑命令、查询数据库，都归这一层。

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年底推出的一种开放标准，目标是统一大语言模型与外部工具、数据源之间的连接方式。在 MCP 出现之前，每接入一个工具（数据库、文件系统、第三方 API）往往要写一套定制集成代码，模型厂商、工具提供方和开发者之间形成 N×M 的重复适配。MCP 用客户端—服务器架构把这层适配标准化：工具方实现一个 MCP 服务器暴露能力，智能体侧作为客户端按统一协议调用，从而做到一次接入、多处复用。它与传统的函数调用（function calling）并不冲突，后者更偏向单次请求内的结构化输出，而 MCP 侧重长期、可发现、可组合的工具生态。对循环工程而言，MCP 这类标准的意义在于让行动阶段的能力扩展不必每次重写胶水代码。

子智能体：独立的检查者

让写代码的同一个智能体去检查自己的代码，效果有限。循环工程的做法是引入第二个智能体充当检查员和同事，它可以有自己的指令、自己的上限，背后的模型甚至可能和主智能体不同，验证完再把结果发回去。这种"写审分离"的结构，是循环可信度的关键一环。

人类在环路中的位置：四个陷阱

即便循环搭得再完整——有触发器、有检查器、有主干——它仍然需要人类参与。视频作者强调，人在环路中是避免自动化代码生成最危险陷阱的手段，并列出了四个陷阱。

未经核验的代码。 检查器子智能体说到底也只是个智能体，上线代码的责任最终在人类开发者身上。真人必须阅读并核验代码。

理解债务。 系统里代码的总量与人类真正理解的程度之间的差距，就是理解债务。智能体写得越多、人查得越少，这笔债涨得越快。等到需要处理紧急生产故障或规划架构迁移时，它就会集中爆发。

意图债务。 智能体知道系统在做什么，却难以理解为什么这么做——除非这些被写下来，比如放在架构文档里。缺了意图记录，智能体可能做出技术上无懈可击、却违背项目目标的改动。视频里的例子很典型：智能体通过放宽折扣码验证规则修好了一个测试，从测试角度是完美修复，从商业底线看却糟糕透顶。

认知投降。 最隐蔽也最危险的一个：人盲目接受循环产出的任何结果——"既然是AI做的，那肯定没错"。一旦如此，理解债务会进一步攀升，因为根本没人再试图理解AI生成的内容。

所以"最小化人工干预"不等于"零干预"。视频给出的结论是：人类需要写出带停止条件的目标，把意图写下来放在智能体找得到的地方，并持续阅读智能体的输出。做到这三点，循环工程才能发挥最佳效果。

小结

循环工程与其说是新技术，不如说是一种工作方式的重新分工：把机械的提示迭代交给系统，把目标定义、意图记录和结果核验留给人。四阶段闭环谁都能搭，但触发器、上下文、主干、工具和子智能体的组合质量，以及人类是否守住了核验这条底线，决定了这个循环是在提效还是在制造债务。

你会在自己的工作流里设计智能体循环吗？