做Agent的朋友应该都有过类似体验：系统跑起来不难，难的是让它越用越顺手。我见过太多项目，第一版Agent效果惊艳，跑了两周之后还是老样子，遇到同样的问题继续踩同样的坑。很多人把"把上一次结果贴进下一轮Prompt"当成自我改进，这其实不是改进，只是续写。真正的 self-improving agent，核心在于能不能从执行结果里抽象出可复用的经验，主动调整自己的行为策略，并且在长时间运行后整体表现保持上升。这篇文章我想把这类系统背后最关键的几个技能点拆开讲清楚，包括反思机制、经验记忆、评估信号和策略调整，也会聊到我在搭这类系统时踩过的坑。
如果你正在用大模型做工作流Agent，或者想给现有系统加一层"越用越聪明"的能力，这篇内容应该能帮你少走不少弯路。
1. self-improving agent 的进化闭环：先搞懂它在修什么
1.1 普通Agent和能够自我改进的Agent，差距不在模型
普通Agent的工作链路大家都熟：接收任务、拆解计划、调用工具或生成模型、返回结果。这条链路里所有的"智能"其实都固定在了Prompt和工具配置里。任务形态一变、环境假设一失效、提示词里写的格式一过时，表现就打回原形。它的问题不是模型不够强，而是没有任何机制把"这次的经验"带到"下一次任务"里。
self-improving agent 在基础执行链路上多了一条反馈回路：执行结果会经过评估，评估结论会写回记忆库，下一次任务开始前，系统会先检索相关经验并调整策略。差别不在于单次跑得快不快，而在于下一次跑的时候，它是否比这一次更清楚"什么方案在这个场景下大概率有效"。
我用一个生活化的类比：普通Agent像一个只背了菜谱的厨师，菜谱上没写的菜就不会做；能够自我改进的Agent像一个会记住今天客人哪些菜没吃完、为什么没吃完、下次怎么调整火候的厨师。它不只是执行者，还是个会复盘的人。
1.2 进化闭环的五段链路：执行、评估、反思、沉淀、调整
一个完整的自我改进闭环，我建议拆成五段来看：
- 执行（Execution）：当前策略驱动Agent完成一次任务，产出最终结果、工具调用记录、过程日志。
- 评估（Evaluation）：判断结果是否符合预期，找出偏差发生在哪个环节，是计划错了、检索错了、工具调用错了还是生成错了。
- 反思（Reflection）：把偏差翻译成自然语言教训，比如"当用户输入是模糊请求时，必须先追问约束条件，再去查数据源"。
- 沉淀（Consolidation）：把教训写进经验库，同时压缩、去重、建立索引，供后续任务检索。
- 调整（Adjustment）：在下次任务开始前，根据检索到的经验修改Prompt、工具选择策略或任务拆分方式。
很多人写自我改进系统时只盯着反思那一环，把大量精力花在怎么让大模型写出漂亮的总结上。但实际项目里，评估和沉淀才是真正的分水岭。评估信号不可靠，反思就是在往错误的方向使劲；沉淀环节做不好，经验库膨胀成一堆无法检索的文本垃圾，反思得再精彩也没用。
我在某工作流Agent项目里一开始只加了"反思后修改临时Prompt"这一层，结果并不理想。后来复盘发现，我们没有把反思结果接入经验库，每次反思只改了一次性Prompt，下次又回到原点。真正把记忆库打通之后，系统才表现出可累积的进步。
2. 反思技能：从一次失败里提取"下次可用"的教训
2.1 三层反思法，比"总结一下"好用得多
反思不是简单地对大模型说"总结一下哪里做得不好"。我试过很多种反思指令，包括让模型自由回答、让模型列失败原因、让模型模仿某框架的格式输出，实际效果差异巨大。最好用的是三层反思法，从结果、过程、假设三个层面逐层往下挖。
- 结果层：目标是否达成？交付物是否符合约束？可量化指标是多少？比如任务完成率、字段完整度、调用成功率。
- 过程层：哪一步耗时最长？哪一次工具调用报错？从哪个决策点之后结果开始偏离预期？
- 假设层：当前Prompt依赖了哪些隐含假设？比如"用户输入的一定是完整地址""外部接口一定能返回JSON""数据库里不存在重复记录"。本次任务里哪些假设不成立，下次什么条件下可能再次不成立。
每一层回答完，最终要产出一条格式化的经验条目，而不是一段散文。这条经验条目要被后续的检索模块直接使用，如果是一大段自然语言，检索命中率和准确率都会很糟糕。我见过不少团队在反思阶段生成了一堆"很好读"的文字，结果存进向量库之后根本查不回来，就是这个原因。
结构化不仅是给机器看的，也是给人看的。我在人工抽查反思质量的时候，能快速扫一眼字段就知道这条经验是否值得采纳。如果是一个自由文本总结，我根本没法快速判断它有没有用。
2.2 反思指令的骨架与 trigger_condition 字段
下面是一个我实际用过的反思Prompt骨架，用模板结构表示，你可以直接改造成自己的版本：
请基于下面的执行记录进行反思。 - 任务目标：{目标} - 执行计划：{计划} - 工具调用日志：{日志} - 最终结果：{结果} - 评估结论：{评估} 要求： 1. 先按"结果/过程/假设"三个层面分别说明偏差。 2. 每条偏差必须给出一个可复用的改进建议，建议要能应用于未来的任务，不能只说"下次要更小心"。 3. 为每条建议补充 trigger_condition 字段，说明什么情况下这条建议应当被触发。 4. 输出格式为JSON数组，字段为：layer, issue, advice, trigger_condition。 5. 不要输出与上述格式无关的内容。这里最关键的字段就是trigger_condition。我一开始没加这个字段，结果反思出来的建议全是"下次要更仔细检查SQL""下次要注意数据格式"这类正确的废话。它们听起来没错，但没有任何触发条件，每条任务都能匹配，等于每条都不匹配。
加了触发条件之后，经验条目才真正具备可执行性。举一个真实例子：某数据清洗Agent的反思产物中有这样一条——"当用户请求中包含多个地址时，应逐个地址单独查询，避免在SQL中使用逗号拼接字符串"。触发条件就是"检测到用户输入中出现两个及以上地址关键词"。这个条件可以精确匹配，后续检索模块才能把它捞出来并用上。
2.3 反思也要设门槛，不然噪音比高到没法用
还有一个很容易被忽略的点：反思要有门槛。如果系统每次失败都反思，经验库会迅速被低频的、任意的、无法泛化的噪声淹没。以某客服调度Agent为例，它每天执行几千次任务，失败率哪怕只有百分之五，一天也能产生几百条反思结果。如果不加过滤，三天下来经验库就是上千条混杂的记录，检索模块根本无从下手。
我在实际项目里设定了一套简单的过滤规则：
- 同类失败出现两次以上，才沉淀为经验。
- 单次随机失败，比如外部API临时超时，只记录日志，不写入经验库。
- 反思生成的建议如果和目标任务的语义相似度低于阈值，直接丢弃。
- 建议内容与当前任务类型无关的，比如在数据查询任务里反思"文案应该更感性"，予以拦截。
这套规则看起来笨，但效果立竿见影。我们的经验库运行一周后依然只有几百条高质量条目，而不是几千条废话。在现代大模型应用里，经验库的质量直接决定自我改进的上限。宁可漏掉一些潜在经验，也不能让噪声把检索管道堵死。
3. 记忆技能：经验库的工程化，比想象中更重要
3.1 经验条目的结构设计：向量加上结构化元数据
反思只是产生了经验原材料，真正决定自我改进系统能走多远的是记忆模块。很多团队把经验库简单地做成了一个向量数据库，每次把反思文本Embedding一下存进去就完事。这种做法的检索效果非常随机，因为 Embedding 捕捉的是语义相似，不是逻辑触发关系。
我的做法是给每条经验配一套结构化元数据。除了反思生成的字段之外，还额外存这些信息：
- 来源任务类型（比如"多地址批量查询""订单状态跟踪"）
- 任务领域标签（比如"客服调度""数据清洗""内容生成"）
- 该经验被检索命中并使用的次数
- 该经验生效后的任务成功率变化
- 最后触发时间，用于淘汰过期经验
有了这套元数据，经验库就不只是一个"文本池子"，而是一张可以查询、统计、下线的数据表。我在某金融信息抽取Agent上做过一次实验，给经验库加结构化元数据之前，Top-3 检索准确率不到五成；加了之后，先按元数据过滤再按向量相似度排序，准确率直接拉到八成以上。中间差的就是"语义相似但逻辑上不该出现"的噪声。
3.2 写入、去重、淘汰：经验库的三段式管理
经验库的写入流程不能是"来了就存"。我建议做一个三段式管线：
第一步是去重。新经验进来之后，先和已有经验做语义相似度比对，相似度超过阈值就进入"合并候选"，而不是直接新增。比如"当用户输入包含多个地址时，应逐个查询"和"多个收货地址需要分开处理"很可能是同一条经验，合并时保留更具体、带有更多触发条件的那一条。
第二步是评分。给每条经验一个初始分数，这个分数由三个因素决定：触发条件的具体程度、建议的操作步骤是否可执行、来源失败是否具有代表性。初始分决定了经验进入经验库时的优先级。
第三步是淘汰。定期扫描经验库，把使用次数低、成功率低或长期未命中的条目降权甚至删除。这一条特别重要。系统的业务方向是会变化的，三个月前的经验可能已经不再适用，如果一直不淘汰，过时经验会在检索时占据大量窗口，把新经验挤出去。
3.3 检索策略：先硬过滤，再向量排序
经验检索是决定改进是否真正生效的最后一环。我踩过一个大坑：最初直接把所有经验做向量检索，取Top-K塞进Prompt上下文。结果经常出现检索出来的经验跟当前任务毫无关系，上下文窗口被无关内容占满，模型行为反而被带偏。
后来我改成了"先硬过滤，再向量排序"的两阶段检索。
第一阶段，用结构化元数据和触发条件做硬性过滤。比如当前任务类型是"订单状态跟踪"，那就只保留任务类型匹配、且触发条件可能命中的经验条目。这一步把候选范围从几千条缩到几十条。
第二阶段，在候选集内做向量相似度排序，取Top-K。这样既保证了召回的相关性，又避免了纯向量检索强拉语义的随机感。
硬过滤规则看起来是"手工规则"，但它的作用非常关键。它像一个索引，指向真正可能适配当前场景的经验；向量排序只是在索引结果里做精细化排序。两阶段合起来，才是我认为比较可靠的经验检索方式。
4. 评估技能：没有老师打分，系统怎么知道自己在变好
4.1 三层反馈信号的搭建
自我改进系统最容易被低估的环节是评估。反思再强，如果评估信号是错的，系统会沿着错误方向一路狂奔。我的经验是，评估信号至少要有三层，不能只依赖单一来源。
第一层是环境硬反馈。任务是否成功、约束是否满足、交付物是否通过校验。这些信号最可靠，但覆盖范围有限，因为很多开放式任务没有直接的成功/失败定义。
第二层是过程软反馈。工具调用失败率、重试次数、单步耗时、上下文截断次数、任务拆分的步数波动。这些指标不直接说明结果好坏，但能反映系统行为是否健康。比如某Agent的SQL调用重试率突然上升，说明工具选择策略很可能出了问题。
第三层是模型自评。用一个独立的评估模型，对生成结果按若干维度打分，比如完整性、格式合规、逻辑一致性。模型自评的问题是分数容易虚高，这是我在多个项目里反复验证过的事实。单独看模型自评分，满意度普遍在九成以上，但实际业务验收通过率只有七成。所以模型自评只能作为辅助信号，不能作为唯一依据。
4.2 看趋势而不是看单点
评估信号天然有波动。外部API偶尔超时、用户输入偶尔极端、模型输出偶尔抽风，任何一个都会让单次任务的评估结果异常。如果系统依据单次评估就触发反思和调整，策略会变得非常敏感，整天在两种行为之间来回切换。
我的做法是引入滑动窗口，看移动平均。比如统计最近五十次任务的成功率，和上一个五十次窗口做对比。窗口期内的变化趋势比单点结果要可靠得多。只有当趋势明显下滑或者持续偏离基线时，才开始触发反思流程。
这一点在实践中的意义特别大。某Agent明明整体表现稳步上升，但某一天因为外部数据源故障，单次成功率跌到五成，如果我们基于单点触发反思，就会把问题归因到Prompt上，然后做出一堆无效修改。用趋势判断之后，这样的干扰被自然过滤掉了。
4.3 新旧策略A/B对比是最可靠的验证方式
移动平均能过滤随机波动，但无法解决另一个问题：策略调整之后，效果到底是变好了还是变差了。浮动可能来自模型版本变化、输入分布变化，也可能来自外部环境变化，并不一定代表改进生效。
最可靠的验证方式还是A/B对比。保留旧版本策略，把新旧策略分别跑同一批任务，比较评估结果。我曾经在某代码生成Agent上做一个调整，把经验库的Top-K从三提到五。观察整体指标是提升了一点点，但用A/B对比拆分来看，新策略在"测试用例通过率"上确实更高，可同时也让"响应时间"显著变长。没有A/B对比，我只会看到整体指标微涨，根本发现不了这个取舍。
搭建A/B对比不需要很重的实验平台。最简单的做法是，把任务流量按用户ID或任务ID哈希分桶，一部分走旧策略，一部分走新策略，各跑一段时间，然后把两边的结果指标拉出来对比。对于大多数Agent系统来说，这个粒度已经够了。
5. 调整技能：把经验变成行为，而不是留在文档里
5.1 三种调整方式：改Prompt、改工具选择、改任务拆分
反思和记忆做的都是"信息处理"，最终要改变的是Agent的行为。我的经验是，调整手段本身也需要分层，不同层面的调整成本不同、风险也不同。
第一层是调整Prompt上下文。这是最直接也最常用的方式，把检索到的经验作为额外上下文注入当前任务的Prompt。风险最低，但效果受限于"大模型是否愿意遵循这段上下文"。如果经验条目的表述太模糊，模型可能会忽略。
第二层是调整工具选择策略。比如发现某个工具调用失败率很高，就可以在工具路由逻辑里调低它的权重，优先尝试替代工具。这个调整比改Prompt更精准，因为它直接改变了Agent的执行路径。
第三层是调整任务拆分方式。这一层最重但最有效。比如某数据处理Agent反复在"多条件过滤"这个子任务上出错，反思结论是"过滤条件之间互相冲突时，应拆成多个子步骤逐一过滤"。这种调整不只是改一段提示词，而是直接改变Agent的任务计划模板。
我建议调整的层级从小往大试：先调上下文，不行再调工具选择，最后才动任务拆分。一上来就改计划模板风险很高，因为你很难判断问题到底出在哪个环节，可能只是Prompt表达不清，结果你把整个任务流程都重写了。
5.2 从"调整"到"技能沉淀"：固化可复用操作序列
大部分自我改进系统把经验停留在"提示词上下文"级别，已经能获得不少收益。但如果想让系统能力有质变，还需要把高频复用的经验固化成新技能模块。
举个例子。某信息抽取Agent多次发现"从非结构化文本中提取日期范围"这个操作频繁出现，而且每次都用同样的处理步骤。这时候可以把这一系列操作编排成一个新的工具函数，封装成独立技能，注册到工具列表里。之后的Agent可以直接调用这个工具，不再需要每次靠提示词引导生成。
技能沉淀的价值在于：它把"模型每次都要临时思考的流程"变成"确定性执行的代码模块"，既降低了出错率，也省掉了大量推理时间。我在实际项目里观察到，固化一个高频技能之后，端到端响应时间能缩短百分之三十以上，效果非常明显。
不过这个操作需要人工把关，至少前期要人工确认这个操作序列是稳定、通用、边界清晰的，才适合固化成工具。系统自动生成的技能模块，我认为目前还是只适合作为候选推荐，不适合直接全自动上线。
5.3 版本控制与回滚，给自我改进装上安全阀
自我改进系统有一个隐性问题：改进并不总是正向的。某次策略调整可能在当前任务集合上表现更好，但损害了另一类任务。如果没有版本控制，系统会持续累积这种"局部最优但全局变差"的改动，很难定位是哪一步调整引入了问题。
我在系统里给策略层加了简单但严格的版本控制。每一轮调整都会生成一个版本号，记录调整内容、触发原因、生效时间。每次调整前，系统会把当前策略参数做成快照，方便随时回滚。当一个版本在滑动窗口内表现不及前一版本，自动回滚到上一个快照。
这个东西听起来很基础，但在接入自我改进能力的早期尤其重要。因为没有版本控制，出了问题你根本不知道是反思错了、经验库检索错了还是策略调整错了。有了版本快照，排查链路会清晰很多。
6. 踩坑实录：四个让自我改进失效的常见陷阱
6.1 改进震荡：策略在两个方案之间来回横跳
最早做自我改进时，我遇到最多的现象就是"策略震荡"：系统今天改成方案A，明天发现A表现不好退回B，后天觉得B也不行又切回A。来回调整，消耗不少算力，进步却几乎没有。
问题出在触发调整的门槛太低，以及没有设置稳定观察期。一种调整生效后，至少要运行一个窗口期再评判；如果在观察期内仅是因为随机波动导致指标下降，不应触发回滚或再次调整。我给系统加了一条规则："每个策略版本至少运行两百次任务才能被替换，除非出现硬错误率超标。"这个缓冲机制让系统不再反复横跳，改进才开始真正累积。
6.2 经验过拟合：在新场景里变笨
另一个非常隐蔽的问题是经验过拟合。经验库里的高权重条目，通常都来自高频场景。检索排序时这些条目因为历史表现好，会被优先选中，但它们在其他类型的任务里可能完全不适用，甚至会误导Agent的行为。
某内容生成Agent就有过一次典型翻车：经验库中关于"生成列表式内容"的经验权重很高，结果遇到需要深度分析的任务时，Agent也强行采用列表式结构，完全忽略了用户要求的论述完整性。原因是检索阶段把"高权重经验"直接当作"适用当前任务的经验"注入Prompt，没有做场景校验。
解决思路是给经验的适用场景加更严格的任务类型约束，同时在检索排序里引入"场景不匹配惩罚项"。经验权重高，不代表所有任务都该用。
6.3 自我评估幻觉：模型给自己打的分不可信
模型自评的分数虚高问题，我在多个项目里都验证过。不管是通用模型还是经过偏好对齐的模型，给自己的生成结果打分时都存在明显乐观偏差。尤其在开放式任务上，自评分和人工验收结果常常相差两成以上。
在自我改进系统里，自评幻觉的危害比想象中大。它会让系统误判"我已经改得很好了"，从而停止反思和调整，或者把优化方向带偏。我给项目的处理方式是：不把自评作为策略是否调整的决策依据，只作为辅助参考；真正的调整决策以环境硬反馈和人工抽样评价为准。如果某项任务没有环境硬反馈，宁可保守一点，不要把自评分当事实。
6.4 反馈管道断裂：日志缺失导致无法归因
还有一类问题是工程层面的，但它对自我改进系统的打击是致命的：日志不全导致无法归因。如果工具调用日志只记录了成功和失败，却没有记录失败时的具体报错信息、输入参数快照、上下文截断情况，那么反思模块根本无从判断失败原因。
某支付流程Agent遇到过一个问题：转账任务偶尔失败，但日志里只有"Transaction timeout"一行字，没有请求参数、没有超时阶段、没有重试记录。反思模块也只能生成"建议优化超时处理"这种毫无信息量的条目。这个教训提醒我，在做自我改进之前，先花时间把执行日志的结构补齐。日志的信息密度决定了反思的上限。
7. 什么任务适合自我改进，什么任务别硬上
最后聊一聊边界问题。self-improving agent 并不是所有场景的银弹。我对项目的判断标准很简单：任务是否重复、反馈是否可得、环境是否相对稳定。
适合的场景通常具备三个特征：一是同类型任务反复出现，呈现"高频多形态"特征；二是存在可靠的成功/失败信号，至少能稳定判断任务是否完成；三是输入分布虽然变化，但不是毫无规律地剧变。比如客服工单分类、数据清洗、SQL生成、例行报告撰写，这类任务就非常适合。
不适合的场景也有三类：一是一次性创意任务，比如策划一场全新营销活动，根本没有足够的历史经验可供参考；二是外部反馈不可得的任务，模型输出后没有任何验证手段，自我评估又不可靠，硬做只会积累垃圾经验；三是环境变化极其剧烈的任务，调用的接口三天两头改版本，策略还没来得及累积就被旧假设带偏了。
给Agent接入自我改进能力之前，先花一天时间梳理它的反馈信号在哪里。如果连"这次做得好不好"都没有稳定答案，就别急着让它自我反思。我自己的习惯是，每轮改造之前先画清楚一条线：谁评估结果、用什么标准评估、评估结论怎么回流。这条线画清楚了，反思、记忆、调整才有意义；画不清楚，只是在系统上堆了一个漂亮的装饰物。
