做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接入自我改进能力之前先花一天时间梳理它的反馈信号在哪里。如果连这次做得好不好都没有稳定答案就别急着让它自我反思。我自己的习惯是每轮改造之前先画清楚一条线谁评估结果、用什么标准评估、评估结论怎么回流。这条线画清楚了反思、记忆、调整才有意义画不清楚只是在系统上堆了一个漂亮的装饰物。