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_factorylist) # 工作记忆区 history_summary: list field(default_factorylist) # 历史摘要区 failure_log: list field(default_factorylist) # 失败记录区 step_count: int 0 consecutive_failures: int 0这个状态结构对应4.1节说的四块区域。用dataclass是为了让字段清晰实际项目里你可能需要序列化到外部存储以支持断点续跑。5.2 循环主体的代码骨架循环主体就是一个带终止条件的while结构但每个节点的职责要写清楚。def run_loop(task, max_steps20, max_consecutive_failures3): state LoopState(task_definitiontask) 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年爆火有它实打实的价值但也有被过度包装的成分。价值在于它把智能体开发里那些散落的工程经验——状态管理、失败恢复、终止条件、反馈校验——收拢到了一个统一的框架下让讨论有了共同语言。被过度包装的地方在于循环本身不是什么新发明把它捧成范式革命有点过了。我实际用下来的体会是循环工程真正改变的不是你写不写循环而是你对待智能体行为的态度。以前是希望它一次做对现在是假设它会错设计好纠错路径。这个态度转变带来的工程质量提升是真实的比任何具体框架都值钱。如果你现在要上手我的建议是从最小骨架开始别一上来就搭复杂的多循环系统。先把单循环的状态结构、终止条件、反思节点这三样做扎实跑一批真实任务看失败模式再决定要不要扩展。循环工程的收益来自对失败模式的针对性设计没有真实失败数据支撑的复杂架构大概率是过度设计。最后分享一个我踩过的坑早期我为了让循环更智能把反思节点做得特别重每轮都做完整的外部验证。结果成本翻了三倍效果提升却很有限。后来改成规则校验每轮做、外部验证按需做成本降下来了效果基本没损失。反思的力度要和决策的风险匹配不是越重越好。这个平衡点得靠实测找别人的参数只能参考不能照搬。 
长河君 · 2026/11/3 16:14:09 · 阅读 1.2k 循环工程：从提示词到闭环，提升智能体多步任务稳定性
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_factorylist) # 工作记忆区 history_summary: list field(default_factorylist) # 历史摘要区 failure_log: list field(default_factorylist) # 失败记录区 step_count: int 0 consecutive_failures: int 0这个状态结构对应4.1节说的四块区域。用dataclass是为了让字段清晰实际项目里你可能需要序列化到外部存储以支持断点续跑。5.2 循环主体的代码骨架循环主体就是一个带终止条件的while结构但每个节点的职责要写清楚。def run_loop(task, max_steps20, max_consecutive_failures3): state LoopState(task_definitiontask) 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年爆火有它实打实的价值但也有被过度包装的成分。价值在于它把智能体开发里那些散落的工程经验——状态管理、失败恢复、终止条件、反馈校验——收拢到了一个统一的框架下让讨论有了共同语言。被过度包装的地方在于循环本身不是什么新发明把它捧成范式革命有点过了。我实际用下来的体会是循环工程真正改变的不是你写不写循环而是你对待智能体行为的态度。以前是希望它一次做对现在是假设它会错设计好纠错路径。这个态度转变带来的工程质量提升是真实的比任何具体框架都值钱。如果你现在要上手我的建议是从最小骨架开始别一上来就搭复杂的多循环系统。先把单循环的状态结构、终止条件、反思节点这三样做扎实跑一批真实任务看失败模式再决定要不要扩展。循环工程的收益来自对失败模式的针对性设计没有真实失败数据支撑的复杂架构大概率是过度设计。最后分享一个我踩过的坑早期我为了让循环更智能把反思节点做得特别重每轮都做完整的外部验证。结果成本翻了三倍效果提升却很有限。后来改成规则校验每轮做、外部验证按需做成本降下来了效果基本没损失。反思的力度要和决策的风险匹配不是越重越好。这个平衡点得靠实测找别人的参数只能参考不能照搬。