1. 为什么 Agent 自进化必须靠工程闭环而不是靠“换个更贵的模型”做 Agent 开发的人大概都经历过这样一个阶段第一版 Demo 跑通的时候特别兴奋觉得这玩意儿简直无所不能结果上线两周用户反馈越来越离谱同一个问题今天答得对、明天答得错昨天刚纠正过的错误今天又犯。你打开日志一看模型没换、Prompt 没改、工具也没动但行为就是飘了。这时候很多人的第一反应是“换个更强的模型试试”但换完之后你会发现问题只是换了个形式出现——该记的没记住该改的没改掉该测的测不出来。这就是我为什么一直强调Agent 的自进化能力本质上不是一个模型能力问题而是一个工程闭环问题。所谓自进化指的是 Agent 在持续运行过程中能够通过评测发现问题、通过记忆沉淀经验、通过 Skill 更新固化能力形成一个“跑得越久、表现越好”的正向循环。这个循环里模型只是其中一个环节真正决定上限的是评测体系够不够准、记忆结构够不够稳、Skill 更新机制够不够安全。我见过太多团队把精力全砸在 Prompt 调优上结果做了半年Agent 的能力还是停留在“人工喂一条、它学一条”的水平。原因很简单没有闭环所有的优化都是一次性的今天调好的东西明天就丢了。而搭好闭环之后你会发现 Agent 的迭代速度会发生质变——它开始自己发现问题、自己积累经验、自己验证改进人只需要在关键节点做审核和兜底。这篇文章我想聊的就是这套闭环到底怎么搭。我会从评测集构建、长短期记忆设计、Skill 更新机制三个核心环节拆开讲每个环节都会给出我实际用过的方案、踩过的坑以及一些不太方便写在官方文档里的经验。适合正在做 Agent 项目、已经过了 Demo 阶段、开始面对真实用户反馈的开发者。如果你还在纠结“Agent 是什么”这个层面这篇文章可能稍微超前了一点但提前了解闭环思路也没坏处。2. 评测环节没有评测集自进化就是瞎进化2.1 评测集不是测试用例而是 Agent 的“体检标准”很多人一听到“评测集”脑子里浮现的就是传统软件测试那套东西写一堆输入输出对跑一遍看通过率。这个理解放在 Agent 上会出大问题。传统软件的输入输出是确定的Agent 的输出是概率性的同一个问题问十遍可能给你十个不同的答案而且有些答案“看起来不一样但都对”。所以 Agent 的评测集不能只记录标准答案还要记录判定标准。我自己的做法是把评测集拆成三层硬性断言层那些绝对不能错的比如工具调用的参数格式、必须包含的关键信息、不能出现的敏感内容。这一层用代码判定不依赖模型。语义匹配层答案不唯一但语义要对齐的比如“帮我总结这段文本”这类任务。这一层用另一个模型做裁判但裁判模型要固定版本不能今天用 A 明天用 B。行为轨迹层不只看最终答案还要看 Agent 中间走了哪些步骤、调了哪些工具、有没有绕远路。这一层最容易被忽略但恰恰是自进化最需要的信号。提示评测集的规模不需要一开始就很大我建议从 50 到 100 条高质量样本起步覆盖核心场景和已知的边界情况。质量比数量重要得多一条精心设计的边界用例价值超过一百条随便凑的常规问题。2.2 评测集怎么构建从真实日志里“捞”而不是拍脑袋想新手最容易犯的错误就是坐在工位上凭空想评测用例。你想出来的用例往往是你已经知道怎么解的问题测不出 Agent 的真实短板。正确的做法是从真实运行日志里捞。具体操作上我会做这么几件事。第一把线上 Agent 的完整对话日志存下来包括用户输入、Agent 的每一步输出、工具调用记录、最终结果。第二定期抽样人工标注标出哪些是“答得好”、哪些是“答得差”、哪些是“答得模棱两可”。第三把“答得差”的样本整理成评测用例同时把“答得好但走弯路”的样本也收进来作为行为轨迹层的评测项。这个过程听起来很笨但实测下来是最有效的。我做过一个项目前两周靠人工从日志里捞了 80 条用例跑出来的失败率是 37%团队一开始很沮丧。但正是这 37% 的失败样本帮我们定位到了三个核心问题工具描述有歧义、记忆检索策略不对、Skill 触发条件太宽。修完这三处之后失败率降到 11%。如果当初拍脑袋写用例这三个问题可能半年都发现不了。2.3 评测频率与自动化别让评测变成“想起来才跑一次”评测集建好之后最大的挑战是坚持跑。人都是有惰性的改了一版 Prompt觉得“应该没问题”就懒得跑评测了。结果上线之后翻车回头一查是某个边缘场景被改坏了。我的建议是把评测做成 CI 的一部分。每次 Skill 更新、每次 Prompt 调整、每次记忆策略变更都自动触发一轮评测。评测结果不通过就不允许合并。这个机制一开始会让人觉得麻烦但跑顺之后它会成为你最大的安全感来源。自动化评测的架构大概是这样的一个调度器负责拉起评测任务一个执行器负责跑 Agent一个判定器负责打分一个报告器负责输出结果。判定器里硬性断言用代码语义匹配用固定版本的裁判模型行为轨迹用规则加人工抽检。整个流程跑一轮 100 条用例大概需要十几分钟完全可以接受。评测层级判定方式适用场景注意事项硬性断言层代码规则格式、关键词、敏感内容规则要定期review避免过时语义匹配层固定裁判模型总结、改写、问答裁判模型版本必须锁定行为轨迹层规则人工抽检工具调用、步骤合理性抽检比例不低于10%2.4 评测结果怎么用不是看通过率而是看失败模式评测跑完最没用的动作就是看一眼通过率然后关掉。通过率只是一个数字真正有价值的是失败模式。我会把失败样本按类型聚类看看是“工具调用错”、“记忆检索错”、“推理链断裂”还是“输出格式错”。每一类失败背后对应的是闭环里不同的环节需要优化。比如工具调用错可能是 Skill 描述不清楚记忆检索错可能是长短期记忆的权重分配有问题推理链断裂可能是 Prompt 里的思考步骤需要调整。把失败模式映射到闭环环节优化才有方向。这个映射关系我建议做成一张表每次评测完更新一次时间长了你会发现某些环节反复出问题那就是需要重点投入的地方。3. 记忆环节长短期记忆不是“存下来”就完事3.1 双网络记忆模型为什么单一记忆库一定会崩关于 Agent 记忆网上讨论最多的就是“怎么存”、“存哪里”。但我实测下来比存储更重要的是记忆的分层结构。单一记忆库的问题在于它把不同时效性、不同重要性的信息混在一起检索的时候要么召回一堆过时信息要么漏掉关键信息。我目前用的是双网络记忆模型思路是把记忆分成两个网络短期工作记忆网络和长期经验记忆网络。短期网络负责当前会话的上下文容量小、更新快、检索优先级高长期网络负责跨会话的经验沉淀容量大、更新慢、检索优先级低但覆盖面广。两个网络之间有一个“晋升”机制短期网络里反复出现、被验证有效的信息会晋升到长期网络长期网络里长期未被检索到的信息会降权甚至归档。这个结构的好处是Agent 在处理当前任务时优先看短期记忆保证响应速度和相关性当短期记忆不够用时再去长期记忆里捞经验。两个网络的检索结果会做加权融合权重根据任务类型动态调整。3.2 记忆的写入策略不是所有对话都值得记很多 Agent 项目的问题不是“记不住”而是“记太多”。把每一轮对话都塞进记忆库结果就是检索的时候噪音太大真正有用的信息被淹没。我的做法是给记忆写入设门槛。短期记忆的写入相对宽松当前会话的所有轮次都保留但会做压缩把冗长的对话压缩成关键信息点保留意图、实体、决策和结果。长期记忆的写入则严格得多只有满足以下条件之一才会写入用户明确纠正了 Agent 的错误、Agent 在某类任务上表现显著优于平均水平、某个 Skill 被反复调用且效果稳定。注意记忆写入一定要有“去重”和“冲突检测”。我踩过的坑是同一个事实被反复写入检索时返回一堆重复内容浪费上下文窗口。后来加了一层去重逻辑相似度超过阈值的记忆只保留最新版本同时标记旧版本为“已过期”。3.3 记忆的检索策略时间半衰期是个好东西记忆检索的核心问题是给定当前任务应该召回哪些记忆。最简单的做法是向量相似度检索但实测下来纯相似度检索会召回一堆“语义相似但时效性差”的记忆。比如用户三个月前问过类似问题当时给的答案现在已经不适用了但相似度很高还是会被召回。我的解决方案是在相似度基础上加一个时间半衰期因子。每条记忆有一个“新鲜度”分数随着时间衰减。检索时最终得分 相似度 × 新鲜度权重。新鲜度权重根据记忆类型调整事实类记忆衰减慢操作类记忆衰减快偏好类记忆几乎不衰减。具体参数上我用的半衰期是这样的事实类 30 天操作类 7 天偏好类 180 天。这些数字不是拍脑袋定的是根据实际业务场景调的。比如操作类记忆衰减快是因为工具和流程变化频繁三个月前的操作步骤可能已经失效了。偏好类衰减慢是因为用户的喜好相对稳定。记忆类型半衰期衰减曲线检索权重事实类30天指数衰减0.4操作类7天指数衰减0.35偏好类180天线性衰减0.253.4 记忆的更新与遗忘会忘的 Agent 才是好 Agent记忆更新不只是“写入新信息”还包括“修正旧信息”和“遗忘无用信息”。修正旧信息的触发条件通常是用户反馈或评测发现错误。比如用户说“你上次说的不对”这时候要定位到相关记忆标记为“待验证”然后根据新信息更新。遗忘机制则更微妙。很多团队不敢做遗忘怕丢了信息。但实测下来不遗忘的 Agent 会越来越“固执”总是拿旧经验套新问题。我的做法是定期做记忆清理长期未被检索到的记忆降权连续多个周期未被检索到的归档归档超过一定时间的删除。这个周期我一般设成 30 天做一次降权评估90 天做一次归档180 天做一次清理。4. Skill 更新环节让 Agent 自己学会新技能但别让它乱学4.1 Skill 是什么不是函数而是“可复用的行为模式”在 Agent 语境里Skill 经常被理解成“工具调用”或者“函数”。这个理解太窄了。我定义的 Skill 是可复用的行为模式它可能包含多个工具调用、一段推理逻辑、一套输出格式甚至是一种特定的交互风格。比如“帮用户做会议纪要”这个 Skill可能包含调用日历工具获取会议信息、调用转录工具获取文字、用特定格式总结、按用户偏好分发。这一整套东西打包起来才是一个完整的 Skill。理解这一点很重要因为 Skill 更新的粒度不是单个工具而是整个行为模式。当评测发现“会议纪要”这个 Skill 效果不好时你要优化的是整个模式而不是只换一个转录工具。4.2 Skill 的发现从评测失败和用户反馈里找信号Skill 更新不是凭空创造而是从现有运行数据里发现“缺什么”和“什么不好用”。我一般从三个来源找信号第一是评测失败样本。如果某类任务反复失败而且失败原因不是模型能力问题而是“不知道怎么组合工具”那就说明缺一个 Skill。第二是用户反馈。用户说“你能不能帮我做某某事”如果这个需求反复出现就值得做成 Skill。第三是行为轨迹分析。如果 Agent 在某类任务上总是走弯路说明现有 Skill 的效率不够需要优化。发现信号之后不要急着写新 Skill。先做一件事确认这个 Skill 的边界。它解决什么问题、不解决什么问题、输入输出是什么、失败时怎么兜底。边界不清楚的 Skill写出来也是坑。4.3 Skill 的编码与测试先写测试再写实现Skill 的编码我坚持一个原则先写测试用例再写实现。测试用例从评测集里来覆盖正常场景、边界场景和失败场景。写实现的时候每完成一个功能点就跑一次测试确保不破坏已有行为。Skill 的实现形式可以很多样可以是一段 Prompt 模板可以是一个工作流编排也可以是一段代码逻辑。选择哪种形式取决于 Skill 的复杂度和稳定性要求。简单、稳定的 Skill 用 Prompt 就够了复杂、需要精确控制的 Skill用工作流或代码更靠谱。提示Skill 的命名很重要。我见过太多项目用“skill_001”、“skill_002”这种命名过两周自己都忘了是干嘛的。命名要能体现功能比如“meeting_summary”、“code_review”、“data_clean”一看就知道是什么。4.4 Skill 的更新与回滚灰度发布是必须的Skill 更新最大的风险是“改坏了”。新版本 Skill 可能在某些场景下表现更好但在另一些场景下表现更差。所以更新必须灰度。我的做法是新 Skill 先在 10% 的流量上跑同时跑评测集。如果评测通过率不低于旧版本且没有新的失败模式出现再逐步放量到 50%、100%。如果评测发现回退立即回滚到旧版本同时保留新版本的失败样本用于分析。回滚机制要提前准备好不能等出问题了再临时搭。我一般会把每个 Skill 的多个版本都保留通过配置切换。切换过程要能秒级生效避免影响用户体验。更新阶段流量比例评测要求回滚条件灰度110%通过率≥旧版本出现新失败模式灰度250%通过率≥旧版本5%通过率下降全量100%通过率稳定用户投诉增加4.5 Skill 的版本管理别让 Agent 用错版本Skill 多了之后版本管理就成了大问题。我见过最离谱的情况是同一个 Skill 有三个版本在跑Agent 自己都不知道该用哪个。解决方案是给每个 Skill 一个明确的版本号Agent 调用时指定版本或者由调度器根据场景选择版本。版本管理还要和记忆联动。如果某个 Skill 的某个版本在特定场景下表现好这个“场景-Skill-版本”的对应关系应该被记到长期记忆里下次遇到类似场景直接调用。这样 Agent 就真的在“进化”而不是每次重新试错。5. 工程闭环的串联评测、记忆、Skill 怎么互相喂数据5.1 闭环的数据流从评测到记忆到 Skill 再回到评测单独看评测、记忆、Skill每个环节都不难。难的是把它们串成一个闭环让数据在三个环节之间流动。我画的闭环数据流是这样的评测跑完失败样本进入分析环节分析结果分两路一路更新评测集把新的失败模式加进去一路更新记忆把“什么情况下会失败”记到长期记忆里。记忆更新后Agent 的行为会变化变化后的行为再次被评测。同时如果分析发现是 Skill 缺失或 Skill 有问题就触发 Skill 更新更新后的 Skill 再次进入评测。这个闭环跑起来之后你会发现 Agent 的迭代速度明显加快。以前是人发现问题、人改代码、人验证现在是评测发现问题、记忆沉淀经验、Skill 自动更新、评测自动验证。人只需要在关键节点审核。5.2 闭环的节奏不是越快越好闭环跑得太快会出问题。比如评测刚发现一个失败样本就立即更新记忆和 Skill结果可能是过度拟合——为了修一个边缘 case把主流程改坏了。所以闭环要有节奏。我的节奏是这样的评测每天跑一次失败样本积累到一定数量再做分析记忆更新每周做一次批量处理Skill 更新每两周做一次走完整的灰度流程。这个节奏不是固定的根据业务变化速度调整。业务变化快就加快业务稳定就放慢。5.3 闭环的监控别让闭环自己跑偏闭环跑起来之后最大的风险是“闭环自己跑偏”。比如评测集过时了还在测一些已经不重要的场景记忆里积累了大量噪音检索质量下降Skill 版本越来越多管理混乱。所以闭环本身也需要监控。我一般监控这几个指标评测通过率的变化趋势、记忆检索的命中率和准确率、Skill 调用的成功率和耗时、用户反馈的情感倾向。这些指标异常时就要停下来检查闭环的某个环节是不是出了问题。注意闭环不是越自动越好。我坚持在 Skill 更新和记忆清理这两个环节保留人工审核。因为这两个环节一旦出错影响面很大而且很难回滚。人工审核虽然慢一点但能避免大事故。6. 实操中踩过的坑和排查技巧6.1 评测集“过拟合”为什么你的通过率涨了但用户还是不满意这是我最常遇到的问题。评测通过率从 60% 涨到 90%团队很高兴结果上线之后用户反馈还是差。原因通常是评测集过拟合——Agent 学会了“讨好评测集”而不是真正解决问题。排查方法定期用全新的、未参与过优化的样本做“盲测”。盲测通过率和评测通过率的差距就是过拟合的程度。如果差距超过 15%说明评测集需要更新了。更新方法是从最新日志里捞新样本替换掉那些已经被“刷熟”的旧样本。6.2 记忆“污染”错误信息被反复强化记忆污染是个隐蔽但致命的问题。比如 Agent 某次回答错了这个错误回答被写入记忆下次检索到之后又输出一遍用户纠正后如果纠正信息没有正确覆盖旧记忆错误还会继续传播。排查方法定期做记忆审计抽样检查记忆内容的准确性。发现错误记忆时不仅要修正这一条还要追溯它的来源看看是哪个环节写入了错误信息。我一般会在记忆写入时加一个“置信度”字段低置信度的记忆在检索时降权高置信度的才正常参与。6.3 Skill “打架”多个 Skill 同时触发怎么办Skill 多了之后经常出现多个 Skill 同时匹配当前场景的情况。比如用户说“帮我整理一下这个文档”可能同时触发“文档总结”和“格式转换”两个 Skill。如果两个 Skill 都执行结果可能冲突。解决方案是给 Skill 设优先级和互斥规则。优先级高的先执行执行完再看是否需要执行下一个。互斥的 Skill 只能选一个选择依据是场景匹配度。这个规则要写在 Skill 的元数据里调度器根据元数据决策。常见问题排查思路解决方法预防措施评测过拟合盲测对比更新评测集定期换样本记忆污染记忆审计修正追溯加置信度字段Skill打架检查触发日志设优先级和互斥元数据规范闭环跑偏监控指标异常暂停人工检查保留人工审核6.4 闭环“空转”数据在流动但没有效果闭环空转的表现是评测在跑、记忆在更新、Skill 在迭代但 Agent 的表现没有提升。原因通常是数据流是单向的没有形成反馈。比如评测结果没有真正影响记忆更新记忆更新没有真正影响 Skill 选择。排查方法追踪一条失败样本的完整生命周期看它从被发现到被修复中间经过了哪些环节每个环节是否真的产生了影响。如果某个环节只是“记录”而没有“行动”那就是空转点。7. 一些不太方便写在文档里的经验做 Agent 自进化这套东西技术方案只是一部分更多的是工程习惯和团队协作。我分享几个实际体会。第一评测集的维护比建设更重要。很多团队建完评测集就不管了半年后评测集里的场景已经和线上完全脱节。我的做法是设一个“评测集负责人”每周花半天时间更新评测集从最新日志里捞样本淘汰过时样本。这个投入看起来不大但回报很高。第二记忆的“遗忘”比“记住”更难做。人天生倾向于保留信息觉得删了可惜。但 Agent 的记忆如果不清理检索质量会持续下降。我一般会设一个硬性规则任何记忆超过 180 天未被检索到自动归档。这个规则执行起来会有人反对但实测下来利大于弊。第三Skill 更新要“小步快跑”。不要憋大招一次更新一堆 Skill。每次只更新一个 Skill灰度、评测、放量跑顺了再更新下一个。这样出问题时容易定位回滚成本也低。第四闭环的节奏要匹配业务节奏。业务变化快的时候闭环要加快业务稳定的时候闭环可以放慢。不要为了“自动化”而自动化闭环的目的是让 Agent 更好用不是让流程更酷。第五人工审核不是瓶颈是保险。我见过团队为了追求全自动把人工审核环节砍掉结果出了大事故。人工审核看起来慢但它能拦住那些自动化流程发现不了的问题。至少在 Skill 更新和记忆清理这两个环节我建议保留人工审核。这套闭环我跑了大概半年Agent 的评测通过率从最初的 52% 涨到 89%用户投诉率下降了七成。但更重要的是团队的工作方式变了以前是救火现在是迭代。评测发现问题、记忆沉淀经验、Skill 固化能力人只需要在关键节点做决策。这个转变比任何单点优化都值钱。