1. 为什么“能跑”的 Agent 离“能进化”还差一整套闭环我见过太多 Agent 项目卡在同一个地方Demo 阶段惊艳上线两周后开始退化。不是模型变笨了而是它没有一套机制把“跑过的路”变成“下次能少走的路”。评测分数掉了一点没人知道是哪一步退化的用户纠正过一次下次遇到同样场景还是犯同样的错新加了一个 Skill旧 Skill 的表现莫名其妙被带崩了。这些问题的根子不在模型能力而在于工程上缺了一条从评测到记忆再到Skill 更新的闭环链路。所谓 Agent 自进化不是让模型自己改自己的权重那是训练侧的事。工程侧的自进化指的是 Agent 在运行过程中能够通过评测发现问题、通过记忆沉淀经验、通过 Skill 更新把经验固化成可复用的能力然后再回到评测验证效果。这是一个可观测、可回滚、可度量的循环而不是玄学式的“越用越聪明”。这套闭环适合谁来搭如果你正在做 Agent 产品、Agent 平台或者团队里已经有多个 Skill 在跑但维护成本越来越高那这套东西就是刚需。如果你还在单轮问答阶段可以先收藏等 Skill 数量超过五个再回来看。下面我按实际搭建顺序把评测、记忆、Skill 更新这三段拆开讲每一段都会说清楚为什么这么设计、坑在哪里、怎么验证。2. 评测体系不是打分器而是自进化的触发器2.1 评测集构建别用“通用榜单”糊弄自己的业务很多团队做 Agent 评测第一反应是找现成的 benchmark。我理解这种心态省事。但实测下来通用榜单对业务 Agent 的指导价值极低。原因很简单你的 Agent 解决的是特定场景的任务通用榜单考的是通用推理两者分布不一致。榜单涨了三个点你的线上成功率可能纹丝不动。正确的做法是从真实流量里反向构建评测集。具体操作把线上 Agent 的完整执行轨迹输入、工具调用序列、中间结果、最终输出采样下来按任务类型聚类每类挑出高频场景和边界场景。高频场景保证覆盖主干边界场景保证不翻车。一个可用的业务评测集初期 200 到 500 条就够关键是每条都要有明确的判定标准。判定标准分三档硬性通过结果正确且格式合规、软性通过结果正确但路径冗余、失败结果错误或超时。不要只标对错路径信息才是后续优化的金矿。我踩过的坑是早期只标对错结果发现 Agent 答对了但调了八次工具成本是别人的四倍这种“假成功”在只看准确率的评测里完全被掩盖。2.2 评测频率与触发时机全量跑是奢侈品抽样跑才是日常全量评测集跑一遍如果每条都要真实调用模型和工具成本和时间都扛不住。我的经验是分三层冒烟层20 到 30 条核心用例每次 Skill 更新或 Prompt 改动后必跑五分钟内出结果。回归层完整评测集每天定时跑一次或者累积一定量线上反馈后触发。深度层带人工复核的抽样评测每周一次重点看软性通过和失败案例的归因。这里有个反直觉的点评测不是越频繁越好。跑得太密噪声会淹没信号团队会对分数波动脱敏。我见过一个团队每小时跑一次全量结果所有人都不看报告了。评测的价值在于“触发动作”分数掉了要有人去查、去改否则跑一万次也没用。2.3 从评测结果到可执行信号归因比分数重要评测跑完最没用的输出是“准确率 87.3%”。有用的输出是“相比上次工具调用超时的案例增加了 6 条集中在文件读取类任务”。这就引出了归因维度。我通常按四个维度切归因维度具体指标对应动作结果正确性通过率、失败率定位能力缺口执行效率平均工具调用次数、Token 消耗优化 Skill 路径稳定性同输入多次运行的方差排查随机性来源记忆命中历史经验复用率验证记忆有效性这张表是闭环的起点。比如“记忆命中率”低说明记忆写了但没被检索到问题出在检索策略而不是记忆本身。归因做细了后续的记忆更新和 Skill 更新才有方向否则就是盲目调参。3. 记忆层让 Agent 记住“该记的”忘掉“该忘的”3.1 长短期记忆的分工不是所有信息都值得进长期库Agent 记忆最容易犯的错是“什么都记”。对话历史全塞进去检索时一堆噪声模型反而被干扰。我的做法是明确分层短期记忆存当前会话的上下文生命周期就是这一次任务任务结束即释放。它解决的是“多轮对话不跑题”。长期记忆存跨会话的经验比如用户偏好、成功的问题解决模式、踩过的坑。它解决的是“下次遇到类似场景能复用”。关键判断标准这条信息下次遇到同类任务时还用得上吗用得上进长期用不上留在短期。举个具体例子用户说“帮我分析这份销售数据”短期记忆记的是这份数据的路径和字段长期记忆记的是“这个用户偏好按区域维度拆分且要求图表输出”。前者是一次性的后者是可复用的。3.2 记忆的写入策略score 时间半衰期的实战用法热词里提到的“记忆score时间半衰期”是个很实用的思路。单纯按时间排序老记忆会被新记忆淹没单纯按重要性排序过时的经验会一直霸占检索位。两者结合才合理。具体公式可以简化成最终权重 基础重要性分 × 衰减因子衰减因子按0.5^(经过时间/半衰期)计算。半衰期设多长取决于业务高频变化的场景比如新闻类半衰期可以设 3 到 7 天稳定的知识场景比如产品文档可以设 30 天甚至更长。写入时机也有讲究。我试过两种任务结束时批量写入和关键节点实时写入。批量写入的问题是任务失败时经验丢失实时写入的问题是可能写入半成品经验。折中方案是任务成功时批量写入完整经验任务失败时实时写入失败原因因为失败原因往往在失败瞬间最清晰。注意记忆写入一定要做去重和合并。同一个经验被写入十次检索时会挤占其他记忆的位置。我通常用语义相似度做合并相似度超过阈值就更新已有记忆的 score 和时间戳而不是新增。3.3 记忆检索召回率比精确率更值得关注检索环节很多人追求精确率怕召回无关记忆。但实测下来召回不足比召回过多更致命。召回多了模型可以自己判断哪些有用召回少了模型根本不知道有这条经验直接退化成无记忆状态。我的策略是宽召回 精排序。先用向量检索召回 Top 20再用一个轻量重排模型或者直接用规则筛到 Top 5 注入上下文。重排时综合考虑语义相似度、记忆权重、时间新鲜度。这样既保证不漏又控制注入量。还有一个坑记忆检索的 query 不等于用户输入。用户说“这个怎么弄”直接拿这句话去检索什么都召不回。正确的做法是先用当前任务的目标和上下文构造检索 query比如“文件读取失败的处理方式”。这一步做不好记忆库建得再漂亮也是摆设。4. Skill 更新把经验固化成能力而不是堆 Prompt4.1 Skill 的边界定义一个 Skill 只做一件事Skill 膨胀是 Agent 项目的通病。一开始一个 Skill 管所有文件操作后来发现它既读又写还删出错时根本不知道是哪段逻辑的问题。我的原则是一个 Skill 对应一个原子能力读文件、写文件、列目录分开。这样评测时能精确定位更新时能独立回滚。Skill 的组成至少包含四部分触发条件什么情况下用这个 Skill、执行逻辑具体步骤或工具调用、输入输出契约参数格式和返回格式、失败处理出错时怎么降级。很多团队只写了执行逻辑结果 Skill 被错误触发或者返回格式对不上排查半天。4.2 从记忆到 Skill 的转化路径什么经验值得升级不是所有记忆都值得变成 Skill。判断标准是这个经验是否高频、是否稳定、是否可标准化。高频但每次处理方式不同说明还没形成稳定模式继续留在记忆层观察。稳定但低频升级成 Skill 的性价比不高。只有三者都满足才值得固化。转化流程我通常走四步模式识别从记忆库里找出重复出现的成功路径比如“用户问数据对比时先查库再画图”出现了 20 次。抽象契约把这条路径抽象成输入输出输入是“对比需求描述”输出是“对比图表”。实现 Skill写成可调用的 Skill包含触发条件和失败降级。灰度验证新 Skill 先在小流量跑对比它和原有路径的成功率、效率。这里有个经验新 Skill 上线初期不要急着替换旧路径而是并行跑。用评测数据说话新 Skill 在成功率或效率上明显占优再切换。我见过直接替换导致线上崩掉的案例回滚都来不及。4.3 Skill 版本管理与回滚没有回滚能力的更新都是赌博Skill 更新必须版本化。每次更新记录改了什么、为什么改、评测结果对比。回滚要能做到一键切换而不是重新部署。我的做法是 Skill 配置和代码分离配置里带版本号运行时根据配置加载对应版本。出问题时改配置即可回滚不用动代码。还有一个容易忽略的点Skill 之间的依赖关系。Skill A 依赖 Skill B 的输出格式B 改了格式A 就崩了。所以更新 B 之前要跑一遍依赖 B 的所有 Skill 的冒烟测试。这个检查我建议做成自动化的人工检查迟早会漏。5. 闭环怎么合上评测、记忆、Skill 的联动机制5.1 数据流向一次任务执行如何驱动三端更新把三段串起来看一次完整的任务执行会产生三类数据执行轨迹给评测用、经验片段给记忆用、能力缺口信号给 Skill 更新用。这三类数据不是分开采集的而是从同一份轨迹里解析出来的。具体链路任务执行完轨迹先过评测模块判定成功或失败并归因成功的轨迹提取经验写入记忆失败的轨迹分析是能力缺失还是执行问题能力缺失进入 Skill 更新的候选池。这样一次执行就同时喂了三端不需要额外埋点。5.2 触发式更新 vs 定时更新什么时候该动什么时候该等闭环不是转得越快越好。我的经验是评测触发更新而不是定时更新。具体说冒烟评测连续两次失败触发 Skill 排查回归评测中某类任务成功率下降超过阈值触发记忆检索策略检查记忆命中率持续低于基线触发记忆写入质量审查。定时更新适合的是记忆的衰减和清理这个可以每天跑一次把权重低于阈值的记忆归档。Skill 更新和评测策略调整一定要事件驱动否则就是在没有信号的情况下瞎改。5.3 防止闭环退化成“自嗨循环”外部信号的必要性闭环最大的风险是自我强化Agent 用自己的评测集验证自己的更新分数一直涨但线上效果没变。这是因为评测集和线上分布脱节了。破解方法是引入外部信号线上用户的显式反馈点赞、纠正、隐式反馈任务完成率、重试率、人工抽检结果。这些信号定期注入评测集保证评测集和线上同步进化。我通常每月做一次评测集刷新把线上新出现的场景补进去把已经稳定通过的旧场景降权。评测集不更新闭环就是在一个过时的坐标系里打转。6. 实操中踩过的坑与验证方法6.1 记忆污染错误经验被固化后的清理过程早期我们没做记忆质量校验结果一条错误经验某个工具调用参数写错了被写入长期记忆之后每次遇到类似任务都被召回导致连续一周的失败率上升。排查过程很痛苦因为从表面看是模型能力问题最后逐条审查记忆库才发现是污染。修复方案是加了两道闸写入前校验新记忆和已有高权重记忆冲突时标记待审而不是直接写入和定期审计每周抽样审查高权重记忆的准确性。这个坑的教训是记忆库不是只进不出的仓库它需要和代码库一样的管理规范。6.2 Skill 更新后的回归验证别只看新 Skill 的表现新 Skill 上线大家习惯只看它自己的指标。但实测中我发现新 Skill 可能挤占了其他 Skill 的触发机会导致旧 Skill 退化。所以回归验证必须跑全量冒烟而不是只跑新 Skill 相关的用例。我现在的流程是新 Skill 灰度期间每天跑全量冒烟对比新旧路径的整体指标而不只是新 Skill 的局部指标。6.3 评测集漂移为什么三个月前的满分用例现在全挂了评测集漂移有两个来源业务变化用户需求变了旧用例不再代表真实场景和环境变化依赖的外部接口改了旧用例的预期结果失效。前者需要定期刷新用例后者需要把环境依赖也纳入评测管理。我的做法是给每条评测用例标注“有效期”和“环境依赖”。有效期到了自动提醒复核环境依赖变更时自动触发相关用例重跑。这样能避免“评测分数突然暴跌但不知道原因”的尴尬。7. 关于这套闭环我个人的几条实在建议搭这套闭环技术上最难的不是某个模块而是让团队接受“慢就是快”。评测、记忆、Skill 更新每一环都需要投入短期看不到收益。但根据我的经验Skill 数量超过十个之后没有闭环的团队维护成本会指数上升而有闭环的团队边际成本是递减的。如果让我给一个最小可行起步方案先建 30 条冒烟评测用例再做一个最简单的记忆写入和检索哪怕先用文件存最后挑一个高频 Skill 做版本化。这三件事做完闭环的骨架就有了剩下的都是在这个骨架上加肉。别一上来就追求全自动人工介入的环节先跑通再逐步自动化这样每一步都可控。还有一个我反复强调的点所有更新都要能回滚。记忆写入要能删Skill 更新要能退评测策略要能还原。没有回滚能力的自进化本质上是在裸奔。我见过太多团队因为一次无法回滚的更新把积累了几周的优化全部推翻。这个代价踩过一次就够了。