这两年我打交道最多的 AI 项目，从插件式的问答机器人到能连续跑几十步、调用十几个工具的多智能体系统，几乎都绕不开同一个灵魂问题：你部署出去的智能体，到底能不能自己发现问题、自己改、自己往前走。这里的“自己改、自己往前走”，用稍微学术一点的说法，就是智能体系统的自主迭代能力。它比“会不会用工具”重要得多，直接决定了你的 Agent 是只能走固定流程的流水线，还是一个能在真实环境里持续自我纠错、自我优化的数字员工。这篇综述会围绕自主迭代这个核心，把当前主流的技术路线、工程实现方式、记忆机制、常见的坑以及我自己的实战判断完整过一遍，适合正在做 Agent 产品、想把原型变成稳定自动化流程的工程师和研究者参考。
1. 先把“自主迭代”这件事说清楚
1.1 智能体系统的标准循环与迭代环节
现代智能体系统的基本运行方式，可以用一个闭环来描述：模型接收用户目标，通过规划模块把目标拆成可执行的步骤，调用工具与环境交互，然后观察执行产生的反馈，再规划下一步动作。业内一般把这个循环称为“感知-规划-行动”循环，加上反思环节之后，就成了四段式：感知、规划、行动、反思。
注意，反思这一步并不是标配。很多早期 Agent 系统根本没有这个环节，它只是拿着用户的指令，一次性把工具调用完，然后输出结果。如果途中某个工具返回了错误，它就简单报错，或者原样重试一次同样的动作。这种系统在演示的时候挺像回事，一放到真实环境里就露馅，因为真实任务的失败模式太多了：参数格式不对、接口限流、依赖服务返回了意外结构、权限不足，任何一个环节出错，都需要智能体根据反馈调整自己的行为，而不只是把同一个动作再跑一遍。
自主迭代恰恰是把“反思”从可选项变成核心项。所谓迭代，不是同一动作的机械重试，而是让智能体基于上一次结果形成判断，改变下一步的动作、策略甚至目标拆解方式。技术研究里常说的“试错-学习循环”，落到智能体上就是这个过程。它的关键不是“多次尝试”，而是“每一次尝试都比上一次更有信息量”：系统能从失败轨迹里提取出失败原因、形成修正方案，并且在下一次尝试中真正采纳这个方案。
我在实际项目里见过一个典型的反例。某个团队做了一个文档处理 Agent，遇到解析失败就原样重试三次，三次都失败后直接抛出“处理失败”给用户。这其实是重试，不是迭代，因为系统的行为没有因为失败产生任何变化。后来我们把它改成带结构化反思的回环，让模型先描述失败时工具返回了什么异常、猜测哪个参数可能是元凶、把猜测写进下一次调用的 prompt，成功率直接拉升了二十多个百分点。这一条改动没有换模型、没有改工具，只是把“迭代”真的做进去了。
1.2 自主迭代的三个层级：修正、优化与演进
现在研究中讨论的自主迭代，粒度差异很大。我在看论文和做工程时习惯把迭代能力分成三个层级，这样比较容易对齐思路。
第一个层级是修正型迭代。任务执行过程中出现错误、异常或者结果不符合约束，智能体能够定位问题并纠正。例如代码生成类 Agent 在跑单元测试失败后，通过读取报错信息修改代码；或者爬虫 Agent 在请求被拒绝后，切换备用解析方案。这个层级的目标是“把一件事做对”，衡量指标通常是任务完成率、修复成功率。
第二个层级是优化型迭代。任务本身没有报错，结果也基本满足要求，但智能体可以在多轮执行中发现更好的路径。比如同一个数据分析任务，第一次跑通了但耗时很长，系统通过观察发现某几步可以合并，就自动调整执行顺序。这个层级的目标是“把一件事做得更好”，它在工程上更依赖评估器的精细度，因为“更好”往往是软性指标，不像报错那么显性。
第三个层级是演进型迭代。系统不局限于当前任务，而是在持续运行中沉淀经验、形成新技能，甚至回灌到模型训练阶段。代表方法包括自我指令生成、基于 AI 反馈的偏好优化等。这个层级目前研究很热，但真正落到生产环境的还不多，因为它涉及训练流程、数据合规和系统稳定性，工程代价要高一个量级。
我判断一个智能体系统“有没有自主迭代能力”，通常不看它的宣传文档，而是做一个很朴素的测试：把一个任务故意改错一个环节，观察它能在几轮内自己修正，修正过程是否稳定。如果一轮就崩、或者绕了半天又回到同样的错误路径，那本质上还是“伪迭代”。这个测试我建议所有做 Agent 的团队在验收时都跑一遍，成本很低，暴露问题很快。
2. 智能体自我修正的主要技术路线
2.1 Reflexion：把“反思”变成可复用的经验
Reflexion 是自主迭代方向绕不开的代表性工作。它的核心思想是：智能体在执行任务失败后，不是简单地把错误信息拼接到下一轮 prompt 里，而是先让语言模型输出一段结构化的“反思”，总结这次失败的根本原因和下次应该采取的不同策略，再把这段反思写入记忆，作为下一轮尝试的额外上下文。
这套方案的好处非常明显：它把强化学习中“从经验中学习”的思路搬到了推理阶段，完全不需要更新模型权重，也不需要标注数据。研究者用它在编程问答、决策推理等任务上都实现了显著的效果提升。实现时最关键的变量是反思文本的质量。如果反思只写“我失败了，下次要注意”，几乎没有任何帮助；真正起作用的是包含具体因果链的反思，比如“上次失败是因为我误以为 sort 函数会原地返回列表，实际上它返回 None，下次应该先赋值再操作”。
工程上落地 Reflexion 时有一个容易被忽略的细节：反思不是越写越长越好。我见过有人在 prompt 里塞五段历史反思，上下文被占掉一大半，结果模型反而被旧信息干扰。我的经验是，反思记忆需要做裁剪和去重，通常保留最近的两到三条关键反思就足够。再早的要么已被后来的尝试覆盖，要么会导致模型过度纠结于过时的失败模式，反而忽略当前轮的实际状态。
2.2 Self-Refine：让同一个模型既当选手又当评委
Self-Refine 采用的思路比 Reflexion 更轻量：在生成初始输出之后，同一个语言模型先对输出进行自我评价，指出其中的问题和改进建议，再根据建议重新生成输出。这个过程可以重复多轮，直到模型认为自己给出的版本足够好，或者达到预设轮数上限。
这种做法和 Reflexion 的本质区别在于，它不需要把任务执行拆成多轮完整重放，而是聚焦在“输出”这个层面的迭代优化。比如让模型写一段技术文档，它先生成初稿，然后自己检查语法、逻辑、遗漏点，再重写。文章质量通常在第一轮重写后就有明显提升，第二三轮也能继续小幅改进，但边际收益会快速递减。
不过在真实业务里，Self-Refine 有个明显的坑：自我评价环节如果缺乏外部校验，模型很容易陷入“自我感觉良好”的状态。尤其是当任务本身超出模型的知识边界时，它既答不对，也评不出哪里不对，Refine 之后只是在错误的区域里继续打转。我的使用建议是，把 Self-Refine 用在模型知识覆盖比较好、但表达或结构可能不够理想的任务上。它适合做“润色型迭代”，不适合做“知识型纠错”。
2.3 验证器驱动：让执行结果说话
比纯语言反馈更可靠的迭代信号，来自环境的执行结果。在代码生成类智能体里，单元测试、静态检查、编译输出都是高置信度的反馈信号；在操作类智能体里，环境状态的变化、接口返回码、页面元素的存在性，也都是比模型“自说自话”更可信的验证手段。
这条技术路线的代表范式是“生成-执行-反馈-修复”循环。智能体生成候选方案后，直接在沙箱环境里执行，把执行结果（报错信息、测试报告、输出对比）返回给模型，让模型基于真实反馈进行修复。这比起纯粹让模型评价自己的输出，信息密度和可信度都高了一个量级。
我也要提醒一句：执行结果虽然是高置信信号，但不一定总是完整可解释的。比如一段代码运行超时，返回的是 TimeoutError，模型得自己判断是死循环、网络阻塞还是数据量过大。所以验证器驱动并不能完全替代模型推理，它提供的是可靠的“错题标记”，但“为什么错”“怎么改”仍然要靠模型结合上下文进行推理。
工程上这套循环的收敛速度，很大程度上取决于你给模型反喂的报错信息是否经过清洗。我在项目里会把几千字符的堆栈信息先用规则提取出异常类型、出错行号和相关变量值，再拼进反馈 prompt。这么处理之后，模型修复效率明显优于直接堆原始日志，token 消耗也能降下来。
2.4 技术路线对比与选型建议
为了不让选型时晕头转向，我把 Reflexion、Self-Refine、验证器驱动和“多智能体互评”这几种常见路线放在一起做了个对比。
| 路线 | 迭代信号来源 | 适用场景 | 主要风险 | 工程成本 |
|---|---|---|---|---|
| Reflexion | 结构化自我反思 + 历史记忆 | 长链路任务、决策类问题 | 反思质量不稳定、上下文膨胀 | 中 |
| Self-Refine | 同一模型的自评 | 内容生成、输出润色 | 自评盲区、边际收益递减快 | 低 |
| 验证器驱动 | 环境执行结果、测试用例 | 代码、接口、自动化流程 | 需要搭建沙箱环境、信号工程量大 | 高 |
| 多智能体互评 | 其他 Agent 的评判与建议 | 复杂方案设计、对抗性场景 | 成本成倍增加、共识难以统一 | 高 |
需要说明的是，这几种路线并不互斥。实际生产里最稳的组合是：用验证器作为硬性把关，把它的输出作为硬反馈；再用模型反思作为软性策略调整，负责解释验证器给出的错误并规划新的执行路径。硬反馈保证不跑偏，软反思保证有策略，两者合在一起才是高效的自主迭代闭环。
3. 记忆机制：自主迭代的本质是“记住教训”
3.1 短期记忆：上下文窗口里的信息预算管理
自主迭代天然会产生大量中间过程：每一步的决策、每一次的失败原因、每一次的修正尝试，如果全部不加处理地留在上下文里，很快会把窗口撑爆。所以短期记忆管理本质上是在“有限的 token 预算”里决定保留哪些信息。
常用的手段包括滑动窗口、摘要压缩和关键信息提取。滑动窗口适合保留最近几轮完整交互，因为最近的执行状态往往最相关。摘要压缩适合把早期探索过程浓缩成几句话，保留结论性的经验。关键信息提取则是用规则或模型从原始日志里挑出异常类型、出错的工具名、失败步骤编号等结构化字段。三种手段可以叠加使用。
我一般遵循的预算是：完整保留当前轮的执行细节，压缩保留上一轮的失败摘要，再往前只保留经验性的反思。展开来说，如果上下文预算是一万 token，我会把五千留给当前任务的执行轨迹，三千留给上一轮失败摘要，两千留给历史反思和工具说明。这个比例可以根据任务复杂度调整，但总的原则是：当前信息优先，历史经验只留结论。
3.2 长期记忆：把失败经验变为跨任务资产
如果一个智能体只在单个任务里迭代，短期记忆就够了；但真实系统往往需要跨任务复用经验。这就引出长期记忆：把失败的教训、成功的路径、工具的注意事项写入外部存储，在后续任务启动时通过检索拉取相关经验。
主流实现方式是把经验文本做向量化后存入向量库，每个任务开始时先检索和当前目标最相近的经验片段，注入到系统提示词中。这有两个好处：一是新任务不需要从零开始试错，可以站在过往教训的肩膀上；二是跨任务的泛化能力更强，比如你在数据库类任务里总结出的“连接超时先检查服务状态”经验，在后续任何涉及数据库的任务里都可能被检索到。
长期记忆的工程难点不在“存”，而在“检”。检索到不相关甚至矛盾的经验，反而会误导模型。我的做法是给每条经验标注适用范围标签，比如“适用工具：PostgreSQL”“适用场景：批量写入”“置信度：高/中/低”，检索时结合标签做过滤。这个细节看着小，但对迭代成功率的提升非常明显。另外，长期记忆最好支持“更新”而不是只支持“追加”，同一条教训如果被反复触发，说明之前的描述可能不够准确，需要在旧条目上做修订，而不是每触发一次就新增一条。
3.3 记忆写入策略：不是所有反思都值得保存
很多团队做记忆系统时容易犯一个错误：只要模型生成了反思，就不管三七二十一写进长期记忆。结果库里什么都有，有真知灼见也有胡言乱语，检索的时候噪声比信号还大。记忆写入必须要设门槛。
我的筛选标准有三条。第一条，这条经验是否能对应到一个具体的环境反馈？如果反思里没有提到任何实际的报错、状态变化或者用户评价，大概率是模型在自说自话，不值得入库。第二条，这条经验是否包含了可执行的行动建议？比如“下次应该先检查 schema 再生成 SQL”，这就有用；“这次做得很失败”就没用。第三条，这条经验是否和已有记忆冗余？如果库里的经验已经覆盖了同一个要点，再做一次合并或更新比简单追加更合适。
提示：记忆质量的优先级远高于记忆数量。一个只有五十条高质量经验的记忆库，往往比一个存了五千条噪声的库更有用。写入前多想一步，检索时就能少错十次。
4. 从工程角度搭一个能自主迭代的 Agent
4.1 最小可行架构和选型思路
如果你现在要在项目里做一个带自主迭代能力的智能体，我的建议是从最小闭环开始，不要一上来就上多智能体、向量库、训练管线这些重武器。一个最小可行系统只需要四个模块：一个调用了若干工具的主 Agent、一个反馈获取器、一个反思生成器、一个经验存储器。反馈获取器负责从环境拿信号；反思生成器基于信号生成修正策略；经验存储器决定哪些反思值得沉淀。
理由很简单：自主迭代的核心不是组件多，而是闭环通。先跑通“失败-反馈-反思-重试”这条最短路径，验证它确实能提升任务完成率，再去叠加长期记忆、多智能体协作这些增强项。我见过太多项目一开始就搭了六七个微服务，最后迭代链路反而断在某个反馈接口上，调试成本极高。
选型方面，主 Agent 优先选择支持工具调用和较长上下文窗口的模型，方便在迭代中保留足够信息。反思生成器可以用和主 Agent 相同的模型，也可以用一个更便宜的模型，因为反思本身对推理深度的要求并不一定高于执行，关键是给它的上下文要组织好。经验存储器初期可以用一个简单的 JSON 文件或者 SQLite 表，字段包括失败摘要、修正建议、适用范围、触发次数，等数据量大了再迁到向量库。
4.2 迭代循环的关键实现节点
有了架构，接下来是循环里的几个关键实现节点。第一个节点是退出条件：最多迭代几轮？大部分任务三到五轮就能达到收益拐点，超过这个轮数还在失败，说明问题不在尝试次数，而在方案本身的正确性或环境条件不满足，继续重试纯属浪费。我用一个简单的动态规则：前两轮可以放开到五轮以内，一旦某轮的执行结果和上一轮完全相同，立即终止循环并上报错误。这算“同轨失败检测”，防止模型用同样的错误动作反复撞墙。
第二个节点是反馈的组织方式。前一节的反馈要精炼，不要堆原文。举个例子，代码执行返回了四屏日志，你需要提取的是异常类型、失败函数名、关键变量值，而不是把日志整段塞给模型。我在实践中发现，直接把大段原始日志交给模型，它也能在里面找到信息，但在几十轮的长任务里，token 浪费和注意力分散加在一起，会显著拖慢收敛速度。所以反馈获取器里，一定要有一层清洗与提取逻辑。
第三个节点是反思注入的时机与位置。反思注入到重试路径的什么位置，我建议放在当前任务目标之后、具体执行计划之前，让模型先明确目标，再看到历史教训，再生成新计划。这样反思会作为“约束”参与计划生成，而不是作为背景噪声被忽略。
典型的迭代循环可以写成这样：
for round in range(1, max_rounds + 1): output = agent_execute(task, context, memory) status, signal = extract_env_feedback(output) if status == "success" or signal == "no_change": break reflection = generate_reflection(signal, history) context = compress_context(task, reflection, history) memory = maybe_store_reflection(reflection)这个循环里，agent_execute 是主 Agent 的完整执行过程，extract_env_feedback 负责清洗反馈，generate_reflection 负责生成修正策略，compress_context 负责把新旧信息压缩成下一轮的输入。整个循环跑通之后，再把长期记忆、多智能体协作等能力逐步加进去。
4.3 反馈信号怎么设计才有效
做自主迭代时，最常被低估的是反馈信号的设计。很多人写完“失败后继续尝试”的逻辑就完事了，结果发现系统只是更优雅地反复失败。问题的根源在于反馈太模糊。你可以把反馈设计分成三个层次，从低到高分别是：状态反馈、原因反馈、行动反馈。
状态反馈只告诉系统“你失败了”，比如“接口返回错误”；原因反馈补上“为什么失败”，比如“接口返回 500，可能是请求参数里缺少鉴权头”；行动反馈再进一步指出“接下来怎么做”，比如“建议检查 token 是否过期，并补充 Authorization 头后重试”。理论上，反馈层级越高，模型花在试错上的步数就越少。但并不是所有场景都能直接拿到高层的行动反馈，很多行动反馈要靠反思生成器自己补全。
所以反馈信号设计的核心工作有两个：一是让环境给出的原始反馈尽量完整，比如在调用失败时，把 HTTP 状态码、响应体片段、请求参数摘要一起带回来；二是让反思生成器把原始反馈补成“原因+行动”双结构。我在一个内部知识库问答实验里做过对比：同一个模型、同一个任务集，只给状态反馈的版本最终准确率是 61%，把反思生成器改成“原因+行动”双结构后，准确率提升到 78%。这个差距不是模型能力带来的，纯粹是反馈信息密度带来的。
5. 实战中反复踩过的坑
5.1 反思也会产生幻觉，越改越离谱
这是我在自主迭代系统里遇到最大的坑。模型在执行阶段产生了幻觉，跑到第五步才露出马脚；反思阶段它在失败原因上又产生新的幻觉，把责任归到一个完全无关的环节，然后新一轮就在错误方向上加倍努力。最终表现就是：迭代轮数越多，系统越自信地走在错误的路上。
解决思路有两个。第一，为反思生成器引入“证据约束”：要求模型在反思里明确引用自己观察到的报错或日志片段，如果引不出来，宁可输出“证据不足，保持原策略”，也不要编造原因。第二，引入外部验证作为反思的路由器：先用规则或测试把高置信度的失败分类，比如“超时类”“权限类”“缺失参数类”，再让模型在这个分类框架内做原因推理。把开放式归因变成有范围的归因，幻觉率能压下去不少。
5.2 循环失控：无限重试的成本黑洞
另一个现实问题是成本。很多系统的迭代逻辑是“失败就重来”，没有任何上限，结果单任务 token 消耗跑到成功任务的几十倍。我踩过最狠的一次是某个数据处理任务，模型在一个错误的文件路径上反复碰壁，迭代了四十多轮才在人工介入下终止。账单出来时，这笔任务消耗了相当于平时一百多单的 token。
对策也很简单：强制轮数上限、对同轨失败做检测、设置单任务成本预算。轮数上限我一般设 4 到 6 轮；同轨失败检测是如果当前轮的行动和上一轮完全相同，就立刻停；成本预算是把“再迭代一轮的预期收益”和“已投入成本”做比较，超出就不值得继续。建议你至少在日志里记录每个任务的迭代轮数分布，一旦发现长尾任务消耗异常，优先处理它们的原因，而不是简单地提高轮数上限。
5.3 自评模型与外挂验证器怎么选
经常有人问我，让模型自己给自己打分到底靠不靠谱。我的答案是：分场景。如果是事实性检查、计算结果校验，自己打分完全不靠谱，必须外挂验证器。如果是代码质量、表达流畅度、方案合理性这种高度主观的维度，自评的有效性也有限，但配上明确的评分准则后，它可以作为筛选信号使用，把明显不合格的输出先过滤掉。
在实际的迭代体系里，我建议按照信号的可信度排序使用：环境执行结果 > 确定性规则 > 外部专用模型 > 当前模型自评。能用环境信号就不用自评，能用规则就不用模型。很多迭代效果不佳的系统，问题不是模型不够聪明，而是反馈链路用了太多最低可信度的自评信号。
5.4 现场问题排查速查表
我把这些年遇到的典型问题整理成一张速查表，方便你在现场排查时对照。
| 现象 | 可能原因 | 处理建议 |
|---|---|---|
| 迭代后结果变差 | 反思时引入幻觉，错误归因 | 加证据约束，要求反思引用实际日志 |
| 反复执行同一个错误动作 | 缺少同轨失败检测 | 比对当前轮与上一轮行动，一致则终止 |
| 几轮之后上下文混乱 | 短期记忆管理缺失 | 引入摘要压缩，只保留关键失败信息 |
| 长期记忆检索出无关经验 | 缺少适用范围标签 | 为经验标注工具、场景、置信度字段 |
| 成本飙升 | 没有轮数上限与预算控制 | 设置动态轮数上限，检测收益拐点 |
| 自评得分高，实际结果差 | 自评盲区，缺少外部验证 | 引入规则或验证器，降低自评权重 |
6. 从“会迭代”走向“会进化”
6.1 训练信号回流：让迭代反哺模型进化
当前很多智能体系统的迭代还停留在推理阶段：模型权重不变，只是每次用不同的 prompt 上下文适配任务。这种方式的优点是灵活、成本低，但天花板也很明显：你只能在一个固定的能力范围内做策略调整，模型学不会的新技能就是学不会。
演进型迭代想解决的问题，正是把自主迭代过程中积累的高质量轨迹和反馈变成训练信号，回灌到模型微调或偏好对齐中。近几年关于自我奖励模型、自我指令生成的研究，本质上都在跑这条路径。它们让模型在交互中不断生成新任务、自主评估输出质量、用反馈优化自身参数，形成一个持续进化的闭环。这套思路在学术实验里已经看到了不少让人兴奋的结果，但工程落地时，数据质量过滤、防遗忘、评估漂移等问题都还远没有解决。
6.2 多智能体协同迭代：相互挑刺更有效
多智能体是当前很流行的一种迭代形态。它的核心思路是让多个角色分工，比如一个 Agent 负责生成方案，另一个负责评审挑刺，第三个负责执行验证，通过角色之间的相互制衡实现反馈闭环。这种方式比单智能体的自评多了一层“外部视角”，能有效缓解自我盲区问题。
但多智能体不是银弹。首先，它的成本是线性甚至超线性增长的，四个 Agent 跑一个任务，消耗可能是单个 Agent 的五六倍。其次，评审 Agent 自身也可能犯错，当生成方和评审方意见冲突时，如何裁决是个麻烦问题。我在做多智能体协作时，会坚持一个原则：角色分工要顺应当前任务的真实需求而设计，不要为了“看起来高级”而强行拆角色。方案设计任务拆一个“出方案-挑毛病-修改”三人组是合理的；一个简单的字段抽取任务也拆三个智能体，那就是纯粹的浪费。
6.3 我对这个方向的一点个人体会
说了这么多技术方案，最后聊一点个人判断。做智能体系统这几年，我最大的感受是，自主迭代能力在某种意义上就等于系统可靠性。一个智能体光会调用工具不太值钱，它必须在调用错误的工具、遇到意外的环境反馈时，依然能自己绕回正轨。所谓“智能感”真正落地的地方，往往就是这个自我修正的过程。有一套扎实的迭代闭环设计，远比堆砌模型参数和工具数量更能提升体验。
如果你正打算做自己的 Agent 产品，建议先花小半天时间，把最简陋的“失败-反馈-反思-重试”循环跑通，再用它去处理一个真实任务集看看效果。大部分情况下你会发现，这个最小闭环本身可改进的空间就很大，而你对自主迭代的理解，也会比被动地读十篇综述要深刻得多。迭代能力不是一个可以最后贴上去的功能模块，它应该从系统设计的第一天就被考虑进去。
