1. 为什么 Agent 自进化必须靠工程闭环而不是靠堆模型做 Agent 开发这两年我最大的感受是模型能力只是起点真正决定一个 Agent 能不能长期稳定干活的是它背后那套评测、记忆、Skill 更新的工程闭环。很多人一上来就想着换个更强的模型、加更长的上下文结果跑了两周发现Agent 该犯的错还是犯该忘的还是忘Skill 该过时的还是过时。问题不在模型在于你没有给它装上一套“自我进化”的机制。所谓 Agent 自进化说白了就是让 Agent 在真实使用过程中能够自己发现问题、记住经验、更新技能形成一个越用越顺的循环。这个循环拆开来看核心就三块评测负责判断“这次干得好不好”记忆负责沉淀“哪些经验值得留”Skill 更新负责把沉淀下来的经验固化成可复用的能力。三块缺一不可缺了评测就是瞎进化缺了记忆就是每次从零开始缺了 Skill 更新就是永远在重复踩同一个坑。我见过太多项目评测靠人工看几条 case记忆就是往向量库里塞聊天记录Skill 全靠手写 prompt。这种搭法在 demo 阶段能跑通一旦上量、一旦场景变复杂立刻崩盘。原因很简单没有闭环就没有反馈没有反馈就没有进化。你的人工评测跟不上 Agent 的调用量你的向量库塞满了噪声你的 prompt 越写越长最后自己都维护不动。这篇文章我想把这两年踩过的坑、试过的方案、最后跑通的架构完整讲一遍。适合谁看如果你正在做 Agent 项目不管是客服、代码助手、还是自动化工作流只要你想让它“越用越聪明”而不是“越用越乱”那这套闭环思路你应该能用上。我会从整体设计讲到每个模块的具体实现包括参数怎么定、阈值怎么设、坑在哪里尽量让你看完能直接抄作业。2. 整体架构设计评测、记忆、Skill 三者怎么咬合2.1 先想清楚“进化”到底进化什么在动手搭之前得先回答一个问题Agent 自进化进化的对象到底是什么我的答案是三个层面。第一层是行为策略也就是 Agent 在什么情况下该调用什么工具、该走什么流程。比如一个代码助手遇到报错时是先查文档还是先看堆栈这就是策略。第二层是知识记忆也就是那些一次学会、长期受用的领域知识比如某个内部 API 的调用规范、某个业务的黑话映射。第三层是技能封装也就是把高频、稳定的操作序列固化成一个个 Skill让 Agent 不用每次重新推理。这三层对应到工程上就是评测系统、记忆系统、Skill 管理系统。它们不是并列关系而是流水线关系评测产生信号记忆沉淀信号Skill 固化信号。信号从评测流向记忆再从记忆流向 Skill最后 Skill 又反过来影响 Agent 的行为行为再被评测捕捉形成闭环。我一开始犯的错就是把这三块当成独立模块来做评测归评测记忆归记忆结果数据不通评测出来的问题没法自动变成记忆记忆里的经验也没法自动升级成 Skill。后来改成流水线之后整个系统的“进化速度”明显上来了。2.2 闭环的数据流长什么样具体的数据流我画不出来图这里也不方便用图但可以用文字描述清楚。一次 Agent 调用结束后会产生三类原始数据输入上下文、执行轨迹、最终结果。这三类数据先进入评测层评测层根据预设的指标打分输出一个结构化的评测报告里面包含“这次任务成功还是失败”“失败在哪个环节”“有没有更优解”。评测报告里标记为“值得学习”的样本会进入记忆层。记忆层不是无脑存而是要做筛选、压缩、归类。筛选是去掉噪声压缩是把长轨迹提炼成短经验归类是把它放到合适的记忆分区里。记忆层输出的是一条条结构化的“经验条目”每条都带元数据比如适用场景、置信度、时间戳。经验条目积累到一定数量、且置信度足够高时触发 Skill 更新流程。Skill 更新不是简单地把经验拼成 prompt而是要做抽象和泛化把多条相似经验归纳成一个可复用的 Skill 定义然后经过一轮回归测试确认新 Skill 不会破坏已有能力才正式上线。这条流水线跑通之后Agent 的每一次调用都在为下一次调用做贡献这才是真正的自进化。2.3 为什么不用“全自动”而是“半自动 人工兜底”这里我要泼一盆冷水完全无人的自进化目前阶段非常危险。我试过让系统自动把评测通过的经验直接写进 Skill结果两周后 Skill 库里多了一堆互相矛盾的定义Agent 行为开始漂移排查了半天才发现是某几条错误经验被误判为“值得学习”。所以我的建议是半自动 人工兜底。评测和记忆可以高度自动化但 Skill 更新这一步尤其是涉及核心能力的更新一定要有人工审核环节。具体做法是系统自动生成 Skill 候选自动跑回归测试测试通过后进入待审核队列人工确认后才上线。这样既保证了进化速度又守住了质量底线。3. 评测系统怎么让 Agent 自己知道自己干得好不好3.1 评测集构建别指望一套评测集打天下评测集构建是很多人忽略的一环。我见过有人拿几十条手工 case 当评测集跑完就宣称 Agent 准确率 90%这种数字没有任何意义。评测集必须分层我一般分三层。第一层是冒烟集20 到 50 条覆盖最核心的场景每次代码改动都跑要求秒级出结果主要看有没有明显回归。第二层是回归集200 到 500 条覆盖主要业务路径和已知的边界情况每天跑一次看整体指标波动。第三层是挑战集专门收集线上真实失败 case持续更新用来发现新问题。这三层的构建方式也不一样。冒烟集靠人工精选回归集靠历史 case 沉淀挑战集靠线上监控自动捞。我特别想强调的是挑战集它是自进化的燃料。线上每出现一次失败就自动把这条 case 脱敏后加入挑战集Agent 下次评测就会遇到它逼着它学会。3.2 评测指标准确率只是冰山一角只盯准确率是新手最容易犯的错。Agent 的评测指标至少要覆盖四个维度。维度指标说明建议阈值效果任务成功率端到端完成目标的比例核心场景 85%效果召回率该找到的信息有没有找到 90%效率平均步数完成任务消耗的推理步数越低越好设上限效率平均耗时端到端响应时间按场景定一般 30s稳定方差同一 case 多次跑的波动越小越好安全越界率调用未授权工具或输出敏感内容必须为 0我实测下来召回率和平均步数是最能反映 Agent 健康度的两个指标。召回率掉了说明记忆或检索出了问题步数涨了说明策略在退化。这两个指标比单纯的准确率敏感得多。3.3 自动评测的实现LLM-as-Judge 怎么用才靠谱自动评测现在主流做法是 LLM-as-Judge就是用一个强模型来给 Agent 的输出打分。这个方案好用但坑也多。第一个坑是评分标准太模糊。你如果只告诉 Judge“给这次回答打分”它给的分基本没法用。必须给它结构化的评分维度比如“信息准确性 1-5 分”“完整性 1-5 分”“是否调用正确工具 是/否”每个维度都要有明确的评分说明。第二个坑是位置偏见。Judge 容易偏向它先看到的内容。解决办法是交换顺序跑两次取平均分或者用多个 Judge 投票。第三个坑是成本。全量用强模型评测成本扛不住。我的做法是分层评测冒烟集用规则匹配 小模型回归集用中等模型只有挑战集和争议 case 才动用强模型。# 一个简化的 LLM-as-Judge 评分 prompt 结构 judge_prompt 你是一个严格的评测员。请根据以下维度给 Agent 的回答打分 1. 信息准确性1-5分回答中的事实是否正确有无编造 2. 任务完整性1-5分是否完整解决了用户的问题 3. 工具使用是/否是否调用了正确的工具有无多余调用 用户问题{question} Agent 回答{answer} 参考答案{reference} 请以 JSON 格式输出{{accuracy: int, completeness: int, tool_correct: bool, reason: str}} 这段 prompt 我调了很多版关键点是维度要少而精每个维度要有明确定义输出要结构化。维度太多 Judge 会顾此失彼定义模糊 Judge 会自由发挥输出不结构化你后面没法自动处理。3.4 人工评测怎么和自动评测配合自动评测再强也替代不了人工。我的经验是自动评测负责筛人工评测负责校准。具体做法是自动评测每天跑全量把分数处于“中间地带”的 case比如成功率 60% 到 80% 之间的挑出来人工重点看这些。分数特别高和特别低的反而不用看高的说明稳低的说明明显有问题直接进挑战集。人工评测的结果要反哺自动评测用来校准 Judge。比如人工发现某条 case 其实是对的但 Judge 打了低分那就要调整 Judge 的 prompt 或评分标准。这个校准过程要持续做不然 Judge 会越来越偏。4. 记忆系统长短期记忆怎么分层怎么防止越记越乱4.1 双网络记忆模型短期和长期各管什么记忆系统我踩过最大的坑就是什么都往一个库里塞结果检索出来的东西又杂又乱Agent 反而被带偏。后来改成双网络模型短期记忆和长期记忆分开管效果立竿见影。短期记忆管的是当前会话或最近几次会话的上下文特点是容量小、更新快、时效性强。它主要解决“刚才说到哪了”的问题比如用户上一句提到的偏好、当前任务的中间状态。短期记忆一般放在内存或高速缓存里会话结束就衰减。长期记忆管的是跨会话的稳定知识特点是容量大、更新慢、置信度高。它解决的是“这个用户/这个场景长期来看是什么样”的问题比如用户的固定习惯、某个业务领域的通用规则。长期记忆要持久化而且要定期做压缩和整理。两者之间的桥梁是记忆晋升机制短期记忆里反复出现、且被评测确认有效的经验才晋升到长期记忆。这样既保证了长期记忆的质量又不会让短期记忆无限膨胀。4.2 记忆的写入策略不是所有对话都值得记新手最容易犯的错是把每一轮对话都写进记忆库。这样做的后果是记忆库里 90% 是噪声检索的时候真正有用的信息被淹没。我的写入策略是三重过滤。第一重是价值过滤只有包含新信息、新偏好、新规则的对话才值得记纯寒暄、纯确认的直接丢弃。第二重是置信度过滤用户明确陈述的事实置信度高Agent 自己推理出来的结论置信度低后者要谨慎写入。第三重是去重过滤写入前先检索一下如果已有相似记忆就做合并或更新而不是新增。def should_write_to_memory(turn, existing_memories): # 价值过滤是否包含新信息 if not contains_new_info(turn): return False # 置信度过滤来源是否可靠 if turn.source agent_inference and turn.confidence 0.8: return False # 去重过滤是否与已有记忆高度相似 similar find_similar(turn, existing_memories, threshold0.9) if similar: update_memory(similar, turn) return False return True这段逻辑看着简单但阈值怎么定很关键。相似度阈值我试过 0.85、0.9、0.95最后定在 0.9。太低会误合并把不同信息当成同一个太高会漏合并导致记忆库冗余。这个值要根据你的 embedding 模型和业务特点调没有万能值。4.3 记忆的检索策略怎么在正确的时候想起正确的事记忆检索的核心矛盾是召回率和精确率的平衡。召回率低了Agent 想不起该想的事精确率低了Agent 被无关记忆干扰。我的做法是多路召回 重排序。多路召回包括向量相似度召回、关键词召回、时间衰减召回。向量召回负责语义相关关键词召回负责精确匹配时间衰减召回负责让近期记忆有更高权重。三路结果合并后再用一个重排序模型精排取 top-k 注入上下文。这里有个细节记忆的分数不能只看相似度还要看时间。我用的公式是score 相似度 * 时间半衰期因子时间半衰期因子随时间指数衰减。这样既保证了相关性又让新鲜记忆有优势。半衰期设多长要看场景客服场景可能 7 天知识库场景可能 30 天。4.4 记忆的压缩与遗忘该忘的必须忘记忆系统最反直觉的一点是遗忘和记忆同样重要。一个只记不忘的系统最后一定会被自己的历史压垮。我的压缩策略是定期聚类 摘要。每周跑一次把长期记忆里的条目做聚类同一类的多条记忆合并成一条摘要记忆。比如用户提过五次“喜欢简洁的回答”就合并成一条“该用户偏好简洁风格置信度 0.95”。遗忘策略是置信度衰减 容量上限。长期没被检索到的记忆置信度会缓慢衰减衰减到阈值以下就归档或删除。同时给每个记忆分区设容量上限超了就淘汰置信度最低的。这样保证记忆库始终是“精华”而不是“垃圾场”。5. Skill 更新从经验到可复用能力的最后一公里5.1 Skill 到底是什么和 prompt、工具的区别很多人搞不清 Skill 和 prompt、工具的区别。我的理解是prompt 是给模型的指令工具是模型能调用的函数Skill 是封装好的、可复用的能力单元。一个 Skill 通常包含一段 prompt、一组工具调用逻辑、以及一些前置条件和后置校验。举个例子“查询订单状态”这个能力如果只写 prompt模型每次都要自己推理该调哪个 API、怎么解析参数如果封装成 Skill模型只需要判断“用户想查订单”然后调用这个 Skill剩下的参数填充、API 调用、结果解析都由 Skill 内部完成。Skill 的价值在于把高频、稳定的操作序列固化下来减少模型的推理负担和出错概率。5.2 Skill 的生成从记忆条目到 Skill 定义Skill 的生成不是拍脑袋写而是从记忆条目里归纳。具体流程是先筛选出高置信度、高频出现的经验条目然后对这些条目做聚类同一类的经验归纳成一个 Skill 候选。归纳的过程可以用 LLM 辅助。给 LLM 一批相似的经验条目让它总结出“这些经验共同描述了一个什么能力”“这个能力的输入输出是什么”“执行步骤是什么”。LLM 输出的结果就是 Skill 定义的初稿然后人工审核、补充边界条件、写测试用例。skill_generation_prompt 以下是一批相似的经验条目请归纳出一个可复用的 Skill 定义 {experience_entries} 请输出 JSON 格式 {{ skill_name: 技能名称, description: 技能描述, input_schema: {{参数名: 类型和说明}}, output_schema: {{返回值: 类型和说明}}, steps: [执行步骤1, 执行步骤2], preconditions: [前置条件], edge_cases: [边界情况处理] }} 这个 prompt 的关键是要求结构化输出而且要把边界情况单独列出来。我见过太多 Skill 定义只写了 happy path一遇到异常就崩。边界情况必须显式定义这是 Skill 能不能上生产的关键。5.3 Skill 的回归测试新 Skill 不能破坏老能力Skill 更新最大的风险是新 Skill 和已有 Skill 冲突或者新 Skill 上线后导致某些场景退化。所以每次 Skill 更新必须跑回归测试。回归测试分两部分。第一部分是新 Skill 自身的测试用专门为它写的测试用例验证它在各种输入下都能正确工作。第二部分是全量回归把整个评测集跑一遍对比更新前后的指标确认没有明显退化。我设的回归门槛是核心场景成功率不能下降超过 1%整体平均步数不能上升超过 5%。超过这个门槛更新就打回人工排查原因。这个门槛看着严但实测下来是必要的因为 Skill 之间的相互影响往往很隐蔽不严格卡就会慢慢累积成大问题。5.4 Skill 的版本管理与灰度上线Skill 一定要做版本管理。每次更新都生成新版本旧版本保留出问题可以快速回滚。版本号我一般用skill_namev1.2.3这种格式主版本号表示不兼容变更次版本号表示新增能力修订号表示 bug 修复。上线要走灰度。先在小流量上跑观察指标没问题再逐步放量。灰度期间要重点看新 Skill 的调用频率、成功率、以及它对其他 Skill 的影响。我遇到过新 Skill 上线后因为它的触发条件太宽把原本该走另一个 Skill 的请求抢过来了导致那个 Skill 的成功率下降。这种问题只有灰度才能发现。6. 常见问题与排查技巧实录6.1 评测分数忽高忽低怎么办这是最常见的问题。原因通常有三个评测集本身不稳定、Judge 有随机性、Agent 输出有随机性。排查顺序是先固定 Agent 的随机性temperature 设 0再固定 Judge 的随机性同样设 0或者多次采样取平均最后看评测集。如果固定了随机性分数还是波动那就是评测集里有歧义 case需要人工清洗。我一般会维护一个稳定性监控同一批 case 每天跑记录分数的方差。方差突然变大说明系统某处出了问题要立刻排查。6.2 记忆检索总是召回无关内容这个问题八成是embedding 模型和业务不匹配。通用 embedding 模型在垂直领域往往表现不好因为领域术语的语义它理解不了。解决办法是用领域数据微调 embedding 模型或者至少做一轮领域适配。另一个原因是记忆条目太长。一条记忆如果几百字embedding 会把它压缩成一个模糊的向量检索时自然不准。解决办法是记忆条目要短一条记忆只讲一件事长内容拆成多条。6.3 Skill 更新后 Agent 行为漂移行为漂移通常是Skill 之间的优先级没定义清楚。多个 Skill 都能处理同一个请求时Agent 不知道该用哪个就会随机选表现就是行为不稳定。解决办法是给 Skill 定义优先级和互斥规则。比如“查询订单”和“查询物流”有重叠就明确“如果用户明确提到物流优先用查询物流”。这些规则要写进 Skill 的元数据里Agent 决策时参考。6.4 常见问题速查表问题现象可能原因排查方向解决手段评测分数波动大随机性未固定检查 temperature设 0 或多次采样记忆召回不准embedding 不匹配看召回样本微调 embedding记忆库膨胀写入无过滤看写入量加三重过滤Skill 冲突优先级未定义看调用日志定义优先级规则行为漂移Skill 更新未回归对比更新前后严格回归门槛响应变慢记忆注入过多看上下文长度限制 top-k6.5 几个我踩过的坑第一个坑是过早追求全自动。我一开始想让整个闭环全自动跑结果 Skill 库被污染花了整整一周清理。后来改成半自动效率反而更高。第二个坑是评测集一成不变。评测集不更新Agent 就会过拟合评测集线上表现和评测分数脱节。必须持续往评测集里加线上 case。第三个坑是记忆只增不减。记忆库涨到几十万条之后检索延迟飙升而且噪声越来越多。后来加了压缩和遗忘机制才稳住。第四个坑是Skill 粒度过细。一开始我把每个小操作都封装成 Skill结果 Skill 数量爆炸Agent 选择困难。后来合并成粗粒度 Skill效果好很多。Skill 的粒度应该以“用户意图”为单位而不是以“操作步骤”为单位。7. 我个人的一些实操体会这套闭环我前后迭代了大半年从最开始的手工评测、单库记忆、硬编码 Skill到现在半自动评测、双网络记忆、版本化 Skill中间踩的坑能写一本书。如果让我给正在做 Agent 的朋友几条建议我会说这几条。先把评测做扎实再谈自进化。评测是闭环的入口入口不准后面全白搭。我见过太多项目评测都没做明白就急着上记忆和 Skill最后做出来的东西自己都不敢信。记忆系统的核心是“筛选”而不是“存储”。存储谁都会难的是判断什么该存、什么该忘。把筛选逻辑做对记忆系统就成功了一大半。Skill 更新一定要有人工兜底。至少在现阶段完全自动的 Skill 更新风险太大。人工审核不是拖慢速度而是保证质量长期看反而更快。闭环的每一环都要有监控。评测的分数、记忆的命中率、Skill 的调用分布这些指标要实时看。任何一个环节异常都要能第一时间发现。最后分享一个小技巧给闭环设一个“进化速率”指标比如每周新增多少条有效记忆、每月更新多少个 Skill。这个指标能直观反映你的 Agent 是不是真的在进化。如果这个数字长期是零那你的闭环大概率是断的得回去查哪一环没跑通。