循环工程：从提示词到闭环，提升智能体多步任务稳定性

1. 一条推文如何点燃一个工程范式

2026年6月7日，某个再普通不过的周日凌晨，一条不到三百字的推文在编程社区里被转发了几万次。推文的核心只有一句话："我们不再给智能体写提示词了，我们给它们设计循环。"配图是一张手绘的架构草图，画着感知、决策、执行、反思四个节点首尾相接的环形结构，旁边潦草地标注着"Loop Engineering v0.1"。

我是在当天下午刷到这条推文的。当时第一反应是——又是一个造词运动。毕竟过去几年里，"提示词工程""上下文工程""智能体编排"这些词轮番登场，每一个都宣称自己解决了上一个范式没解决的问题。但接下来两周发生的事情让我改变了看法：多个开源项目在一周内跟进实现了类似的循环框架，几个主流智能体开发平台悄悄更新了文档里关于"任务循环"的章节，社区里开始有人用"循环工程"这个词讨论生产环境中的智能体稳定性问题。

到2026年下半年，"循环工程"（Loop Engineering）已经从一个推文里的生造词，变成了智能体开发领域绕不开的工程话题。这一节我想做的事情很明确：把这场爆火的始末拆开来看，搞清楚它到底提出了什么问题、为什么这个问题在2026年这个时间点被集中引爆、以及作为一个实际写智能体代码的人，你应该从这套思路里拿走什么。

先说清楚这个内容适合谁看。如果你只是偶尔调用一下大模型接口做点文本处理，那循环工程对你来说可能还早了点；但如果你已经在做需要多步骤、长周期、带工具调用的智能体系统，并且被"智能体跑着跑着就偏了""同一个任务每次结果都不一样""出错之后不知道怎么让它自己纠正"这类问题折磨过，那这套东西值得你花时间。它不是什么银弹，但它提供了一个组织智能体行为的结构性视角，这个视角比具体的框架实现活得更久。

2. 爆火始末：从一条推文到一场工程讨论

2.1 那条推文到底说了什么

把那条推文的内容完整还原一下，它其实提出了三个递进的观点。第一，当前智能体的主要失败模式不是单步能力不足，而是多步执行中的误差累积——每一步看起来都合理，但十步之后整体偏离了目标。第二，解决误差累积的办法不是把每一步的提示词写得更精细，而是在系统层面引入闭环反馈，让智能体能够观察自己上一步的结果并据此调整。第三，闭环反馈的结构应该被显式设计，而不是藏在提示词里靠模型自己"悟"。

这三个观点单独拎出来都不新鲜。控制论里的反馈闭环是几十年前的东西，软件工程里的重试机制、状态机、监督者模式也都是老概念。但推文的巧妙之处在于，它把这些老概念和智能体的具体工程实践对接上了，并且给了一个足够抓眼球的名字。更关键的是，它配的那张草图虽然粗糙，却把"感知-决策-执行-反思"这个循环画得足够具体，让人一看就能往自己的项目上套。

我后来复盘这件事，觉得爆火有几个叠加因素。时间点上，2026年上半年正好是一批智能体产品从demo走向生产环境的阶段，大量团队在这个阶段撞上了稳定性墙，急需一套能解释问题、指导修复的框架。表达方式上，推文没有堆术语，而是用"我们不再写提示词，我们设计循环"这种对比句式，制造了清晰的范式切换感。传播路径上，最早转发的是几个做智能体基础设施的工程师，他们的受众恰好就是最痛的那批人。

2.2 为什么是2026年这个时间点

这个问题值得单独说，因为它决定了循环工程是昙花一现还是真有价值。我的判断是，2026年这个时间点被引爆，背后有三个技术条件同时成熟。

第一是长任务场景的普及。2024年到2025年，智能体的主流用法还是单轮或少数几轮的工具调用，比如查个天气、订个机票。到了2026年，越来越多的场景变成了长周期任务：代码库级别的重构、多文档的研究报告生成、跨系统的运维排障。这类任务的共同特点是执行步数多、中间状态复杂、单步错误会被后续步骤放大。误差累积问题从"偶发困扰"变成了"主要矛盾"。

第二是模型能力的平台期。单步推理能力的提升速度在2026年明显放缓，靠换更强的模型来解决多步任务稳定性的边际收益在下降。这逼着工程侧从"堆模型能力"转向"堆系统结构"。循环工程本质上是一种系统结构上的投入，它假设模型单步能力够用，问题出在组织方式上。

第三是成本结构的倒逼。长任务意味着大量的模型调用，token成本成为实打实的生产约束。朴素的"每一步都重新问一遍"的做法成本高得离谱，而循环工程里的状态管理、缓存复用、失败快速终止等机制，恰好能显著压低无效调用。经济账算得过来，工程实践才有动力跟进。

2.3 社区跟进的真实节奏

推文发出后的第一周，社区反应以讨论为主，真正动手实现的不多。转折点出现在第六天，一个开源智能体框架的维护者发了一篇长文，把自己框架里原本叫"agent executor"的模块重构成了显式的循环结构，并公开了重构前后的失败率对比数据。那篇长文里的一个细节我印象很深：重构后代码行数增加了约四成，但生产环境里的任务中断率下降了六成多。这个"代码变多、故障变少"的对比，说服了很多持观望态度的人。

第二周开始，跟进的项目明显增多，但质量参差不齐。有的项目只是把原来的while循环改了个名字叫"loop engine"，本质上什么都没变；有的项目则认真设计了状态快照、循环终止条件、反思节点的触发策略。这个分化过程本身就很有教育意义——它说明循环工程的核心不在"有个循环"这个形式，而在循环内部的状态管理和反馈设计。后面几节我会重点拆这部分。

3. 循环工程的核心思路拆解

3.1 从"写提示词"到"设计循环"到底变了什么

要理解这个范式切换，得先看清楚传统提示词工程的隐含假设。传统做法假设：只要把指令写清楚、把上下文给足，模型就能一次性把任务做对。这个假设在单步任务上基本成立，但在多步任务上会迅速失效，因为多步任务里每一步的输入都依赖上一步的输出，而上一步的输出质量是不确定的。

循环工程换了一个假设：模型单步会犯错，但错误可以被检测和纠正。基于这个假设，工程的重点从"如何让模型不犯错"转移到"如何让系统在模型犯错时能发现并恢复"。这是一个从开环到闭环的转变，类比一下就是：开环控制像蒙眼开车，全靠事先算好方向盘角度；闭环控制则是看着路况不断微调。

这个转变带来的直接后果是，工程师的关注点变了。以前大家花大量时间打磨系统提示词，现在更多时间花在设计状态结构、定义成功判据、规划失败恢复路径上。提示词依然重要，但它从"主角"变成了"循环里的一个组件"。

3.2 循环的四个基本节点及其职责

推文草图里的四个节点，在后续的工程实践中被反复细化，逐渐形成了比较稳定的职责划分。我用一张表把它们说清楚。

这张表里最容易被低估的是反思节点。很多初版实现把反思做成了"让模型自己说做得对不对"，结果模型倾向于说"做得不错"，反思形同虚设。有效的反思需要外部信号支撑——比如代码能不能跑通、测试有没有通过、检索结果和问题是否相关。反思节点的质量，很大程度上决定了整个循环能不能真正收敛。

3.3 为什么显式循环比隐式循环更可靠

有人会问：模型自己在推理过程里不就在循环吗？思维链本质上就是一种隐式循环。这话没错，但隐式循环有几个工程上致命的缺陷。

隐式循环的状态是不可观测的。模型在内部想了什么、在哪一步走偏了，外部系统看不到，也就无法干预。显式循环把每一步的状态都暴露出来，你可以记录、可以回放、可以在特定条件下打断。这在生产环境里是刚需——出了问题得能定位。

隐式循环的终止条件是不可控的。模型可能陷入反复自我怀疑的死循环，也可能过早自信地结束。显式循环里，终止条件是你写的代码，可以是步数上限、可以是成功判据满足、可以是连续失败次数超阈值，完全可控。

隐式循环的成本是不可预估的。你不知道模型内部会展开多少步推理，token消耗就是个黑箱。显式循环里每一步都是一次明确的调用，成本可以精确核算，也就可以做预算控制。

这三点合起来，就是"为什么要显式设计循环"的完整答案。它不是否定模型自身的推理能力，而是把不可控的部分纳入工程管理。

4. 核心细节与实操要点

4.1 状态结构设计：循环的骨架

循环工程里最基础也最容易被做砸的，是状态结构的设计。状态就是循环在每一轮之间传递的那份数据，它决定了智能体"记得什么""忘了什么""基于什么做决策"。

我见过的最常见的错误是把状态设计成一个不断追加的消息列表。这种做法在短任务里没问题，但长任务里会迅速膨胀，最终撑爆上下文窗口，而且早期无关信息会干扰后期决策。正确的做法是把状态分成几个明确的区域，各自有不同的生命周期。

一个经过实践检验的状态结构大致包含四块：任务定义区（目标、约束、成功判据，全程不变）、工作记忆区（当前轮次相关的中间结果，滚动更新）、历史摘要区（已完成步骤的压缩记录，定期归档）、失败记录区（踩过的坑和对应的规避策略，只增不减）。这四块的分工逻辑是：不变的东西别重复存，变的东西别无限存，重要的教训别丢掉。

提示：工作记忆区的滚动更新策略很关键。我的经验是保留最近三到五轮的完整细节，更早的压缩成一句话摘要移入历史摘要区。这个阈值不是拍脑袋定的，而是根据你的任务平均步数和单步信息量调出来的，需要实测。

4.2 终止条件：让循环知道什么时候该停

循环最怕两件事：该停的时候不停，不该停的时候停了。前者烧钱，后者出错。终止条件的设计要覆盖三类情况。

成功终止：成功判据被满足。这里的关键是成功判据必须可机器验证，不能是"看起来差不多对了"。代码任务用测试通过，文档任务用关键信息覆盖率检查，数据任务用校验规则。判据越硬，循环越可靠。

失败终止：连续失败次数超过阈值，或者遇到不可恢复的错误。这里要区分"可重试的失败"和"不可重试的失败"。工具超时是可重试的，参数格式错误重试也没用，得先修参数。把这两类混在一起处理，是很多实现效率低下的根源。

预算终止：步数或成本超过上限。这是兜底机制，防止前两类条件因为设计缺陷而永远不触发。预算值怎么定？我的做法是先跑一批样本任务，统计正常完成所需的步数分布，取95分位数再上浮三成作为上限。这样既不会误杀正常任务，又能拦住失控的循环。

4.3 反思节点的三种实现层次

反思节点是循环工程里技术含量最高的部分，也是区分"真循环"和"假循环"的分水岭。按可靠性从低到高，我把它分成三个层次。

第一层是模型自评。让模型看自己的输出，判断是否达标。这层最省事，但可靠性最差，因为模型对自己的输出有系统性偏袒。它适合作为辅助信号，不适合作为唯一判据。

第二层是规则校验。用确定性的检查来判断结果。代码能不能编译、JSON能不能解析、必填字段全不全、数值在不在合理区间。这层可靠性高，但覆盖面有限，只能检查形式正确性，检查不了语义正确性。

第三层是外部验证。引入独立于生成过程的验证信号。跑测试用例、做交叉检索比对、用另一个模型做独立评审。这层最可靠，但成本也最高。

实际工程里通常是三层组合：规则校验做第一道过滤，快速拦掉形式错误；外部验证做关键节点的把关；模型自评只在两者都给不出明确结论时作为补充。这个组合策略的意图是——用便宜的手段拦掉大部分问题，把昂贵的手段留给真正需要判断的地方。

4.4 循环内的上下文管理策略

长循环里上下文管理是个持续的战斗。每一轮都要把状态组装成模型能吃的输入，组装策略直接影响效果和成本。

我的基本策略是分层组装、按需加载。任务定义区永远全量加载，因为它是决策的锚点。工作记忆区全量加载，因为它和当前决策最相关。历史摘要区只加载最近若干条，更早的按相关性检索加载。失败记录区只加载和当前动作类型相关的条目，比如当前要调某个工具，就加载这个工具历史上的失败教训。

这个策略背后的逻辑是：上下文窗口是稀缺资源，每一段塞进去的内容都应该对当前决策有直接帮助。无关信息不只是浪费token，还会稀释注意力，让模型抓不住重点。我实测过一个对比，同样的任务，分层组装的版本比全量塞入的版本，任务完成率高出一截，token消耗反而更低。

5. 实操过程：从零搭一个最小可用的循环

5.1 环境与依赖准备

这一节给一个可以直接照着搭的最小实现。语言用Python，不依赖特定框架，目的是把循环的骨架露出来，方便你理解后再往自己的技术栈里搬。

依赖很简单：一个大模型调用客户端、一个状态存储（内存字典就够起步）、一个简单的日志模块。不需要向量数据库，不需要复杂的编排框架，先把循环跑通再说。

import json import time from dataclasses import dataclass, field from typing import Any @dataclass class LoopState: task_definition: dict # 任务定义区，全程不变 working_memory: list = field(default_factory=list) # 工作记忆区 history_summary: list = field(default_factory=list) # 历史摘要区 failure_log: list = field(default_factory=list) # 失败记录区 step_count: int = 0 consecutive_failures: int = 0

这个状态结构对应4.1节说的四块区域。用dataclass是为了让字段清晰，实际项目里你可能需要序列化到外部存储以支持断点续跑。

5.2 循环主体的代码骨架

循环主体就是一个带终止条件的while结构，但每个节点的职责要写清楚。

def run_loop(task, max_steps=20, max_consecutive_failures=3): state = LoopState(task_definition=task) while True: # 终止条件检查 if state.step_count >= max_steps: return {"status": "budget_exhausted", "state": state} if state.consecutive_failures >= max_consecutive_failures: return {"status": "failure_limit", "state": state} # 感知：组装当前上下文 context = build_context(state) # 决策：模型决定下一步 action = decide_next_action(context) # 执行：调用工具或产出结果 result = execute_action(action) # 反思：评估结果 verdict = reflect(action, result, state) # 状态更新 update_state(state, action, result, verdict) if verdict.is_success: return {"status": "success", "result": result, "state": state}

这段骨架的价值在于它把四个节点的边界划清楚了。每个节点是一个独立函数，可以单独测试、单独替换。比如你想把决策节点从纯模型推理换成规则加模型的混合策略，只需要改decide_next_action，其他部分不动。这种可替换性是循环工程相比"一大段提示词"的核心工程优势。

5.3 关键参数的计算与选择

参数不是拍脑袋定的，这里说几个关键参数的确定方法。

最大步数：前面提过，用样本任务的步数分布取95分位数上浮三成。假设你跑了50个样本，正常完成步数的95分位数是12步，那上限就定在16步左右。这个值需要随任务类型调整，代码重构类任务步数天然多，研究报告类相对少。

连续失败阈值：这个值太小会导致过早放弃，太大则浪费预算。我的经验值是3。理由是：连续三次失败通常意味着当前策略方向有问题，继续重试同一策略的期望收益很低，不如终止后人工介入或切换策略。

工作记忆保留轮数：和单步信息量负相关。单步输出很长的任务（比如生成长文档），保留2到3轮就够；单步输出短的任务（比如工具调用返回一个状态码），可以保留5到8轮。判断标准是工作记忆区的总token量不超过上下文预算的四成。

反思触发频率：不是每一轮都需要完整反思。我的做法是规则校验每轮都做（便宜），外部验证只在关键节点做——比如生成了最终产物、或者连续两轮结果相似度极高（可能陷入循环）时触发。

5.4 一次完整的运行记录

拿一个具体任务走一遍，看看循环实际怎么转。任务设定为"从一组日志文件中找出导致服务异常的根因并给出修复建议"。

第一轮，感知节点加载任务定义和日志文件列表，决策节点判断需要先读取日志，执行节点调用文件读取工具拿到前若干行，反思节点用规则校验确认读取成功、内容非空，状态更新，进入第二轮。

第三轮时出现了一个典型情况：决策节点想调用一个日志过滤工具，但参数格式错了，执行失败。反思节点识别出这是参数格式错误（不可重试类），把这条教训写入失败记录区，同时把错误信息放入工作记忆区。第四轮决策时，上下文里包含了这条失败记录，模型修正了参数格式，调用成功。

第七轮，反思节点的规则校验发现生成的根因分析里引用的日志行号超出了实际文件范围，判定为形式错误，触发重试。第八轮修正后通过规则校验，同时触发外部验证——用一个独立的检查流程核对引用的日志行是否真实存在。验证通过，成功终止。

这个记录里值得注意的点是：失败记录区在第四轮真正发挥了作用，如果没把第三轮的教训存下来，第四轮很可能重蹈覆辙。这就是显式状态管理的价值——它让"从错误中学习"变成了系统行为，而不是寄希望于模型在上下文里自己记住。

6. 常见问题与排查技巧实录

6.1 循环不收敛的四种典型表现

实际跑循环，最头疼的就是不收敛。我整理了几种典型表现和对应的排查方向。

这四种里，第二种"反复执行相似动作"最常见，也最隐蔽。因为每一轮单看都合理，只有把多轮放在一起看才发现是在原地打转。解决办法是在状态里维护一个已执行动作的指纹集合，决策前先查重，命中就强制换策略。

6.2 反思节点失效的排查

反思失效是循环工程里最伤的问题，因为它让整个闭环名存实亡。症状是：循环跑完了，结果却是错的，而且循环过程中反思节点一直说"没问题"。

排查分三步走。先看反思用的是什么信号，如果只有模型自评，那失效是大概率事件，得补规则校验或外部验证。再看校验规则本身对不对，我遇到过校验规则写反了的情况，把"包含关键词"写成了"不包含关键词"，导致所有正确结果都被判错。最后看反思的输入是否完整，有时候反思节点拿不到执行结果的完整信息，只能基于残缺信息判断，自然会误判。

注意：反思节点的日志一定要详细记录。它判断了什么、基于什么信号、给出了什么结论，这些都要落盘。反思失效时，这份日志是唯一的排查依据。

6.3 成本失控的预防

长循环烧钱是实打实的风险。预防手段有几个层次。

最外层是预算终止，前面说过，设步数和成本上限。中间层是缓存复用，相同的感知上下文不要重复调用模型，把决策结果缓存起来。内层是决策粒度优化，能一步做完的事不要拆成三步，每多一步就多一次调用。

还有一个容易被忽略的点：失败重试的成本。有些实现里，失败后无脑重试，每次重试都是完整的一轮，成本翻倍。更好的做法是失败后先做轻量诊断，判断是参数问题还是策略问题，参数问题直接修参数重试（便宜），策略问题才走完整循环（贵）。

6.4 从单智能体循环到多循环协作

当任务复杂到单个循环搞不定时，会自然演化到多个循环协作。比如一个主循环负责总体规划，若干子循环负责具体子任务。这时候新的问题出现了：循环之间的状态怎么传递、子循环失败怎么向上汇报、主循环怎么判断子循环的结果可信。

我的经验是保持接口简单：子循环对外只暴露"输入任务定义、输出结果加可信度评分"两个东西，内部状态不向上暴露。主循环根据可信度评分决定是采纳、重试还是换策略。这个设计的好处是子循环可以独立演进，不会因为内部改动影响主循环。代价是主循环拿不到子循环的细节，调试时得多花点功夫看子循环的日志。

7. 我对这套东西的实际判断

写到这里，说点个人看法。循环工程这个概念在2026年爆火，有它实打实的价值，但也有被过度包装的成分。价值在于它把智能体开发里那些散落的工程经验——状态管理、失败恢复、终止条件、反馈校验——收拢到了一个统一的框架下，让讨论有了共同语言。被过度包装的地方在于，"循环"本身不是什么新发明，把它捧成范式革命有点过了。

我实际用下来的体会是：循环工程真正改变的不是你写不写循环，而是你对待智能体行为的态度。以前是"希望它一次做对"，现在是"假设它会错，设计好纠错路径"。这个态度转变带来的工程质量提升是真实的，比任何具体框架都值钱。

如果你现在要上手，我的建议是从最小骨架开始，别一上来就搭复杂的多循环系统。先把单循环的状态结构、终止条件、反思节点这三样做扎实，跑一批真实任务看失败模式，再决定要不要扩展。循环工程的收益来自对失败模式的针对性设计，没有真实失败数据支撑的复杂架构，大概率是过度设计。

最后分享一个我踩过的坑：早期我为了让循环"更智能"，把反思节点做得特别重，每轮都做完整的外部验证。结果成本翻了三倍，效果提升却很有限。后来改成规则校验每轮做、外部验证按需做，成本降下来了，效果基本没损失。反思的力度要和决策的风险匹配，不是越重越好。这个平衡点得靠实测找，别人的参数只能参考，不能照搬。