1. 为什么能跑的 Agent 离越跑越强还差一整套闭环我见过太多 Agent 项目卡在同一个地方Demo 阶段惊艳上线两周后开始退化。不是模型变笨了而是它没有一套机制把跑过的路沉淀下来。你给它加个新工具它可能把旧工具用错你修好一个高频 bug下次遇到同类问题它照样踩你换了台机器部署之前积累的偏好、案例、修正记录全丢了。这就是能跑和越跑越强之间的鸿沟。所谓Agent 自进化说白了就是让 Agent 在真实任务流里形成评测发现问题 → 记忆沉淀经验 → Skill 固化能力 → 再评测验证的工程闭环。注意这里的关键词是工程闭环不是让模型自己反思一下这种玄学。反思只是闭环里的一个动作真正难的是把评测、记忆、Skill 更新这三件事串成一条可观测、可回滚、可复现的流水线。这篇内容适合三类人看一是正在搭 Agent 框架、被记忆到底怎么存折磨的开发者二是手里有评测集但不知道怎么和线上反馈打通的工程同学三是想把零散 prompt 和工具调用整理成可复用 Skill 的团队。我会按评测怎么建 → 记忆怎么分层 → Skill 怎么更新 → 闭环怎么串起来不崩这条主线讲中间穿插我自己踩过的坑和具体参数选择。先给一个整体心智模型后面所有细节都挂在这上面环节核心问题产出物失败信号评测怎么知道它变好还是变坏评测集 打分器分数涨了但线上投诉变多记忆经验存在哪、怎么取短期上下文 长期库检索到无关记忆、污染上下文Skill怎么把经验固化成能力可调用 Skill 单元Skill 越加越多、互相冲突闭环三者怎么自动流转流水线 回滚机制更新后整体退化、无法定位这张表是我做项目时的体检表任何一个环节的失败信号出现就说明闭环有断点。下面逐个拆。2. 评测集不是越大越好Agent 评测的构建逻辑与打分器设计2.1 先分清能力评测和回归评测很多人一上来就想搞一个覆盖所有场景的大评测集结果维护成本爆炸跑一次要半小时最后没人愿意跑。我的做法是分两层能力评测集Capability Set用来回答这个 Agent 到底会不会某类任务。样本少而精每个样本代表一类能力比如多步工具调用长文档摘要歧义澄清。这类集子更新慢是北极星指标。回归评测集Regression Set用来回答这次改动有没有把以前能做的搞坏。样本来自线上真实失败案例只增不减每次改动必跑。能力集我一般控制在 50~150 条回归集可以到几百上千条但必须能并行跑完。这里有个反直觉的点回归集的价值远大于能力集。因为能力集涨分往往靠换模型而回归集才是防止你改 A 坏 B的安全网。2.2 打分器别只信 LLM-as-Judge用大模型当裁判很方便但它有三个坑位置偏见偏爱第一个答案、长度偏见偏爱长答案、自我偏好偏爱和自己风格像的答案。我在实际项目里的组合是规则打分能确定性判断的绝不交给模型。比如工具调用是否命中正确函数、参数 JSON 是否合法、是否包含必须字段。这部分用代码写死零成本零波动。LLM 打分只用于主观质量比如回答是否切题、语气是否合适。关键是打分 prompt 要固定版本和被测 Agent 的 prompt 分开管理否则你分不清是 Agent 变了还是裁判变了。人工抽检每周抽 20~30 条 LLM 打分结果复核算一个裁判一致率。如果一致率低于 85%说明打分 prompt 需要修而不是 Agent 有问题。提示LLM 打分一定要做成对比较而不是绝对打分。让裁判在A 和 B 哪个更好里选比让它打 1~10 分稳定得多。绝对分数在不同批次之间根本不可比。2.3 评测集构建的实操路径从零建评测集我推荐这条路径成本最低第一周手动写 30 条理想任务覆盖你 Agent 的核心场景。每条包含输入、期望行为、必须满足的硬约束。第二周起把线上真实请求脱敏后按失败类型归类每类挑 5~10 条进回归集。失败类型可以粗分为工具选错、参数错、多轮丢上下文、幻觉编造、该问不问。持续每次线上出现新失败模式先补一条回归样本再修问题。先有测试再有修复这个顺序不能反否则你永远不知道修没修好。评测集的存储我建议用最简单的 JSONL一行一条字段固定id、input、expected_behavior、hard_constraints、tags、sourcemanual/online、added_at。别急着上数据库JSONL 配合 git 就能做版本管理diff 清晰回滚方便。3. 记忆分层短期上下文、长期库与该记什么的判断3.1 记忆不是越多越好是要分层Agent 记忆最容易被做成一坨把所有历史对话塞进向量库检索时 top-k 一捞结果捞出一堆无关内容污染上下文。我现在的分层是这样的工作记忆Working Memory当前任务的完整上下文就是对话历史加中间工具结果。容量受模型上下文窗口限制需要主动压缩。情景记忆Episodic Memory过去完成的具体任务记录包括任务描述、采取的动作、最终结果。用于我以前遇到过类似情况吗。语义记忆Semantic Memory从多次情景中提炼出的稳定知识比如这个 API 的分页参数是 page_size 不是 limit。用于我知道这个事实。程序记忆Procedural Memory固化成 Skill 的操作流程这个下一节展开。这四层对应不同的存储和检索策略。工作记忆放内存情景记忆放向量库语义记忆放结构化存储键值或小表程序记忆放 Skill 注册表。混在一起存是灾难的开始。3.2 短期记忆的压缩策略上下文窗口再大也会满压缩是必须的。我试过几种方案实测下来最稳的是滑动窗口 摘要锚点保留最近 N 轮完整对话N 取 6~10看任务复杂度。更早的内容压缩成一段结构化摘要包含任务目标、已完成步骤、关键决策、未解决问题。摘要不是让模型自由发挥而是用固定模板填充保证信息不丢。摘要模板长这样任务目标一句话 已完成步骤列表每步一行 关键决策决策 理由 当前状态进行中/阻塞/待确认 未解决问题列表用固定模板的好处是可解析。你可以在下一轮把摘要里的未解决单独拎出来提醒 Agent而不是让它自己从一大段自然语言里找。3.3 长期记忆的写入与检索长期记忆最大的坑是写入太随意。我的原则是不是所有对话都值得记只有满足以下条件之一的才写入任务成功完成且过程非平凡用了 3 步以上工具调用。出现了明确的纠错用户说不对应该是……。提炼出了可复用的事实或偏好。写入时一定要带元数据时间戳、任务类型、成功与否、来源。检索时不能只靠向量相似度要加过滤条件。比如检索情景记忆时优先同任务类型、优先近期、优先成功的。关于时间衰减热词里提到记忆score时间半衰期这个思路是对的。我的打分公式大致是final_score similarity * w1 recency_score * w2 success_bonus * w3其中recency_score 0.5 ** (days_elapsed / half_life)半衰期我一般设 30 天。success_bonus成功任务加 0.1失败任务减 0.1。权重 w1/w2/w3 我常用 0.6/0.3/0.1但这个要按你的场景调——如果任务高度依赖历史偏好recency 权重可以调高。注意检索回来的记忆一定要限量。我一般最多取 3~5 条且总长度不超过上下文窗口的 15%。记忆塞太多Agent 反而会抓不住当前任务重点这是实测出来的。3.4 记忆的跨环境迁移问题热词里反复出现换账号/换电脑如何保留记忆这其实是记忆存储设计的问题。如果你的记忆存在本地文件或某个账号绑定的云端迁移就是噩梦。我的做法是记忆与运行环境解耦记忆统一存到一个独立的存储层可以是本地目录 同步也可以是自建服务。Agent 通过标准接口读写记忆不关心底层在哪。记忆导出用标准格式JSONL 元数据导入时做去重和冲突检测。这样换环境时只要把记忆库搬过去Agent 立刻恢复记忆。冲突检测的逻辑是同 id 保留新的不同 id 合并语义重复的做一次去重。4. Skill 更新把经验固化成可调用单元的正确姿势4.1 Skill 到底是什么和工具的区别在哪很多人把 Skill 和工具Tool/Function搞混。我的定义是工具是原子能力查天气、发邮件Skill 是完成一类任务的编排逻辑给客户发跟进邮件这个任务包含查客户信息、查历史沟通、起草、发送四步。工具是动词Skill 是动词的套路。所以 Skill 更新不是加一个新函数而是把某类任务该怎么做这套知识固化下来。它通常包含触发条件、步骤序列、每步用哪个工具、参数怎么填、异常怎么处理。4.2 Skill 从哪来三条生成路径人工编写最可靠适合核心高频任务。缺点是慢。从成功轨迹提炼Agent 成功完成一个非平凡任务后把轨迹抽象成 Skill 草稿。这是自进化的关键。从失败修正提炼用户纠错后把正确做法固化成 Skill 或修正已有 Skill。第二条路径最有价值也最难。我的做法是任务成功后用一个独立的提炼器可以是另一个 LLM 调用把轨迹转成 Skill 草稿格式固定{ skill_name: customer_followup_email, trigger: 用户要求给某客户发跟进邮件, steps: [ {action: get_customer_info, params: {customer_id: $customer_id}}, {action: get_communication_history, params: {customer_id: $customer_id, limit: 5}}, {action: draft_email, params: {context: $history}}, {action: send_email, params: {to: $customer_email, body: $draft}} ], exceptions: [ {condition: 客户信息不存在, handler: 询问用户确认客户标识} ] }注意草稿不能直接用必须经过验证才能进 Skill 库。验证方式就是拿它去跑回归集里相关任务通过率达标才准入。4.3 Skill 库的版本管理与冲突处理Skill 越加越多必然冲突。两个 Skill 触发条件重叠、步骤矛盾Agent 就懵了。我的管理策略每个 Skill 带版本号更新是新增版本而非覆盖旧版本保留可回滚。触发条件做互斥检查新 Skill 入库前扫描现有 Skill 的 trigger如果语义相似度超过阈值我常用 0.85强制人工确认是替换还是并存。Skill 有优先级和适用范围不是所有 Skill 都全局可用按任务类型打标签检索时先按标签过滤。冲突类型表现处理方式触发重叠两个 Skill 都想响应同一请求提高优先级或合并步骤矛盾同一任务两种做法保留通过率高的另一个降级参数不兼容工具签名变了 Skill 没更新版本绑定工具变更触发 Skill 复审覆盖不全新场景无 Skill 可用走通用流程并记录事后提炼4.4 Skill 更新的触发时机不是每次任务成功都更新 Skill那样会爆炸。我的触发条件是同一类任务连续成功 3 次以上且没有对应 Skill才提炼新 Skill。已有 Skill失败率超过 20%按周统计触发复审。用户明确纠错立即触发对应 Skill 的修正流程。这个阈值是调出来的。太低会导致 Skill 库噪声大太高会错过进化机会。3 次和 20% 是我在中等复杂度任务上的经验值你可以按自己场景微调。5. 闭环怎么串让评测、记忆、Skill 自动流转而不互相打架5.1 闭环的数据流把前面三块串起来数据流是这样的线上任务执行产生轨迹。轨迹进评测流水线打分并归类。成功且非平凡的轨迹 → 提炼情景记忆 Skill 草稿。失败轨迹 → 进回归集 触发相关 Skill 复审。Skill 草稿/更新 → 跑回归集验证 → 通过则入库。新 Skill 和记忆 → 影响后续任务执行 → 回到第 1 步。这条链路里最容易断的是第 5 步。很多人提炼了 Skill 直接就用结果引入回归。验证环节不能省哪怕只是跑一个 20 条的小回归集。5.2 防止自进化变成自退化自进化最大的风险是正反馈失控Agent 自己提炼的 Skill 有偏差用这个偏差 Skill 又产生更多偏差轨迹越滚越歪。三个防护措施准入门槛Skill 入库必须过回归集通过率不低于现有基线。灰度发布新 Skill 先在小流量任务上用观察一周再全量。一键回滚Skill 库和记忆库都要有快照出问题能退回上一个稳定版本。我踩过最惨的一次坑一个从成功轨迹提炼的 Skill 在特定边界条件下会死循环调用工具因为提炼时没覆盖那个边界。后来加了单任务工具调用次数上限作为硬约束任何 Skill 超过 15 次调用就强制中断并上报。这个上限救过我好几次。5.3 可观测性没有日志就没有闭环闭环要能运转前提是每一步都可观测。我必埋的日志点每次任务输入、用到的 Skill、工具调用序列、最终结果、耗时、token 消耗。每次记忆检索查询、召回的记忆 id、最终用了哪几条。每次 Skill 更新新旧版本、触发原因、回归集通过率。每次评测批次 id、各指标分数、和上一批的 diff。这些日志用结构化格式JSON打到统一的地方方便做聚合分析。我一般用一个简单的看板展示Skill 库规模趋势、回归集通过率趋势、记忆命中率、平均任务步数。这四个指标任何一个异常波动就说明闭环某处出问题了。5.4 一个最小可跑的闭环实现如果你现在什么都没有我建议按这个顺序搭两周能跑起来最小闭环第 1~2 天定义轨迹日志格式所有任务执行都落盘。第 3~4 天手写 30 条回归样本写一个规则打分脚本。第 5~7 天实现情景记忆的写入和检索先用最简单的向量库。第 8~10 天实现 Skill 的 JSON 格式和注册表手动加 2~3 个 Skill。第 11~12 天写一个提炼器把成功轨迹转 Skill 草稿。第 13~14 天把验证环节接上草稿必须过回归集才能入库。这个最小闭环跑通后再逐步加时间衰减、冲突检测、灰度发布这些高级特性。先跑通再优化别一上来就设计完美架构那样永远上不了线。6. 几个我反复踩过的坑和对应的解法6.1 记忆污染检索到看起来相关但实际无关的内容向量检索的相似度高不等于有用。我遇到过检索出语义相似但任务类型完全不同的记忆Agent 照着做直接跑偏。解法是混合检索向量相似度 元数据过滤任务类型、时间范围、成功状态。元数据过滤能砍掉大部分噪声剩下的再按相似度排。6.2 Skill 膨胀加了 200 个 Skill 反而更笨Skill 太多Agent 选择困难触发准确率下降。解法是分层 Skill高频核心 Skill 常驻长尾 Skill 按需加载。具体做法是给 Skill 打场景标签任务开始时先判断场景只加载该场景下的 Skill。我实测把常驻 Skill 控制在 20 个以内触发准确率明显回升。6.3 评测和线上脱节分数涨了体验没涨评测集如果全是自己编的理想样本和线上真实分布差太远。解法是定期用线上流量刷新评测集保证评测集里至少有 50% 来自真实请求。另外评测指标要和业务指标对齐比如你关心的是任务完成率就别只盯着回答质量分。6.4 更新不可回滚改坏了只能干瞪眼早期我没做版本管理一次 Skill 更新把线上搞挂只能手动改回来。现在所有 Skill 和记忆库都做快照每次更新前自动备份出问题一条命令回滚。这个成本极低但救命。7. 关于这套闭环我个人的几点体会搭这套东西两年多最大的感受是Agent 自进化不是让模型自己变聪明而是让工程系统帮它把经验管好。模型能力是天花板闭环决定你能不能摸到天花板。我见过模型很强但闭环稀烂的项目上线就退化也见过模型一般但闭环扎实的项目越跑越稳。如果只让我保留一个环节我会保留回归评测集。它是整个闭环的地基没有它记忆和 Skill 的更新都是盲目的。记忆和 Skill 是上层建筑可以慢慢加但评测集必须从第一天就有。最后一个实操建议别追求全自动。我现在的闭环里Skill 入库和记忆清理这两个环节都保留了人工确认。全自动听起来酷但一旦出错排查成本远高于省下的那点人力。半自动、可观测、可回滚才是能长期跑下去的形态。
1. 为什么能跑的 Agent 离越跑越强还差一整套闭环我见过太多 Agent 项目卡在同一个地方Demo 阶段惊艳上线两周后开始退化。不是模型变笨了而是它没有一套机制把跑过的路沉淀下来。你给它加个新工具它可能把旧工具用错你修好一个高频 bug下次遇到同类问题它照样踩你换了台机器部署之前积累的偏好、案例、修正记录全丢了。这就是能跑和越跑越强之间的鸿沟。所谓Agent 自进化说白了就是让 Agent 在真实任务流里形成评测发现问题 → 记忆沉淀经验 → Skill 固化能力 → 再评测验证的工程闭环。注意这里的关键词是工程闭环不是让模型自己反思一下这种玄学。反思只是闭环里的一个动作真正难的是把评测、记忆、Skill 更新这三件事串成一条可观测、可回滚、可复现的流水线。这篇内容适合三类人看一是正在搭 Agent 框架、被记忆到底怎么存折磨的开发者二是手里有评测集但不知道怎么和线上反馈打通的工程同学三是想把零散 prompt 和工具调用整理成可复用 Skill 的团队。我会按评测怎么建 → 记忆怎么分层 → Skill 怎么更新 → 闭环怎么串起来不崩这条主线讲中间穿插我自己踩过的坑和具体参数选择。先给一个整体心智模型后面所有细节都挂在这上面环节核心问题产出物失败信号评测怎么知道它变好还是变坏评测集 打分器分数涨了但线上投诉变多记忆经验存在哪、怎么取短期上下文 长期库检索到无关记忆、污染上下文Skill怎么把经验固化成能力可调用 Skill 单元Skill 越加越多、互相冲突闭环三者怎么自动流转流水线 回滚机制更新后整体退化、无法定位这张表是我做项目时的体检表任何一个环节的失败信号出现就说明闭环有断点。下面逐个拆。2. 评测集不是越大越好Agent 评测的构建逻辑与打分器设计2.1 先分清能力评测和回归评测很多人一上来就想搞一个覆盖所有场景的大评测集结果维护成本爆炸跑一次要半小时最后没人愿意跑。我的做法是分两层能力评测集Capability Set用来回答这个 Agent 到底会不会某类任务。样本少而精每个样本代表一类能力比如多步工具调用长文档摘要歧义澄清。这类集子更新慢是北极星指标。回归评测集Regression Set用来回答这次改动有没有把以前能做的搞坏。样本来自线上真实失败案例只增不减每次改动必跑。能力集我一般控制在 50~150 条回归集可以到几百上千条但必须能并行跑完。这里有个反直觉的点回归集的价值远大于能力集。因为能力集涨分往往靠换模型而回归集才是防止你改 A 坏 B的安全网。2.2 打分器别只信 LLM-as-Judge用大模型当裁判很方便但它有三个坑位置偏见偏爱第一个答案、长度偏见偏爱长答案、自我偏好偏爱和自己风格像的答案。我在实际项目里的组合是规则打分能确定性判断的绝不交给模型。比如工具调用是否命中正确函数、参数 JSON 是否合法、是否包含必须字段。这部分用代码写死零成本零波动。LLM 打分只用于主观质量比如回答是否切题、语气是否合适。关键是打分 prompt 要固定版本和被测 Agent 的 prompt 分开管理否则你分不清是 Agent 变了还是裁判变了。人工抽检每周抽 20~30 条 LLM 打分结果复核算一个裁判一致率。如果一致率低于 85%说明打分 prompt 需要修而不是 Agent 有问题。提示LLM 打分一定要做成对比较而不是绝对打分。让裁判在A 和 B 哪个更好里选比让它打 1~10 分稳定得多。绝对分数在不同批次之间根本不可比。2.3 评测集构建的实操路径从零建评测集我推荐这条路径成本最低第一周手动写 30 条理想任务覆盖你 Agent 的核心场景。每条包含输入、期望行为、必须满足的硬约束。第二周起把线上真实请求脱敏后按失败类型归类每类挑 5~10 条进回归集。失败类型可以粗分为工具选错、参数错、多轮丢上下文、幻觉编造、该问不问。持续每次线上出现新失败模式先补一条回归样本再修问题。先有测试再有修复这个顺序不能反否则你永远不知道修没修好。评测集的存储我建议用最简单的 JSONL一行一条字段固定id、input、expected_behavior、hard_constraints、tags、sourcemanual/online、added_at。别急着上数据库JSONL 配合 git 就能做版本管理diff 清晰回滚方便。3. 记忆分层短期上下文、长期库与该记什么的判断3.1 记忆不是越多越好是要分层Agent 记忆最容易被做成一坨把所有历史对话塞进向量库检索时 top-k 一捞结果捞出一堆无关内容污染上下文。我现在的分层是这样的工作记忆Working Memory当前任务的完整上下文就是对话历史加中间工具结果。容量受模型上下文窗口限制需要主动压缩。情景记忆Episodic Memory过去完成的具体任务记录包括任务描述、采取的动作、最终结果。用于我以前遇到过类似情况吗。语义记忆Semantic Memory从多次情景中提炼出的稳定知识比如这个 API 的分页参数是 page_size 不是 limit。用于我知道这个事实。程序记忆Procedural Memory固化成 Skill 的操作流程这个下一节展开。这四层对应不同的存储和检索策略。工作记忆放内存情景记忆放向量库语义记忆放结构化存储键值或小表程序记忆放 Skill 注册表。混在一起存是灾难的开始。3.2 短期记忆的压缩策略上下文窗口再大也会满压缩是必须的。我试过几种方案实测下来最稳的是滑动窗口 摘要锚点保留最近 N 轮完整对话N 取 6~10看任务复杂度。更早的内容压缩成一段结构化摘要包含任务目标、已完成步骤、关键决策、未解决问题。摘要不是让模型自由发挥而是用固定模板填充保证信息不丢。摘要模板长这样任务目标一句话 已完成步骤列表每步一行 关键决策决策 理由 当前状态进行中/阻塞/待确认 未解决问题列表用固定模板的好处是可解析。你可以在下一轮把摘要里的未解决单独拎出来提醒 Agent而不是让它自己从一大段自然语言里找。3.3 长期记忆的写入与检索长期记忆最大的坑是写入太随意。我的原则是不是所有对话都值得记只有满足以下条件之一的才写入任务成功完成且过程非平凡用了 3 步以上工具调用。出现了明确的纠错用户说不对应该是……。提炼出了可复用的事实或偏好。写入时一定要带元数据时间戳、任务类型、成功与否、来源。检索时不能只靠向量相似度要加过滤条件。比如检索情景记忆时优先同任务类型、优先近期、优先成功的。关于时间衰减热词里提到记忆score时间半衰期这个思路是对的。我的打分公式大致是final_score similarity * w1 recency_score * w2 success_bonus * w3其中recency_score 0.5 ** (days_elapsed / half_life)半衰期我一般设 30 天。success_bonus成功任务加 0.1失败任务减 0.1。权重 w1/w2/w3 我常用 0.6/0.3/0.1但这个要按你的场景调——如果任务高度依赖历史偏好recency 权重可以调高。注意检索回来的记忆一定要限量。我一般最多取 3~5 条且总长度不超过上下文窗口的 15%。记忆塞太多Agent 反而会抓不住当前任务重点这是实测出来的。3.4 记忆的跨环境迁移问题热词里反复出现换账号/换电脑如何保留记忆这其实是记忆存储设计的问题。如果你的记忆存在本地文件或某个账号绑定的云端迁移就是噩梦。我的做法是记忆与运行环境解耦记忆统一存到一个独立的存储层可以是本地目录 同步也可以是自建服务。Agent 通过标准接口读写记忆不关心底层在哪。记忆导出用标准格式JSONL 元数据导入时做去重和冲突检测。这样换环境时只要把记忆库搬过去Agent 立刻恢复记忆。冲突检测的逻辑是同 id 保留新的不同 id 合并语义重复的做一次去重。4. Skill 更新把经验固化成可调用单元的正确姿势4.1 Skill 到底是什么和工具的区别在哪很多人把 Skill 和工具Tool/Function搞混。我的定义是工具是原子能力查天气、发邮件Skill 是完成一类任务的编排逻辑给客户发跟进邮件这个任务包含查客户信息、查历史沟通、起草、发送四步。工具是动词Skill 是动词的套路。所以 Skill 更新不是加一个新函数而是把某类任务该怎么做这套知识固化下来。它通常包含触发条件、步骤序列、每步用哪个工具、参数怎么填、异常怎么处理。4.2 Skill 从哪来三条生成路径人工编写最可靠适合核心高频任务。缺点是慢。从成功轨迹提炼Agent 成功完成一个非平凡任务后把轨迹抽象成 Skill 草稿。这是自进化的关键。从失败修正提炼用户纠错后把正确做法固化成 Skill 或修正已有 Skill。第二条路径最有价值也最难。我的做法是任务成功后用一个独立的提炼器可以是另一个 LLM 调用把轨迹转成 Skill 草稿格式固定{ skill_name: customer_followup_email, trigger: 用户要求给某客户发跟进邮件, steps: [ {action: get_customer_info, params: {customer_id: $customer_id}}, {action: get_communication_history, params: {customer_id: $customer_id, limit: 5}}, {action: draft_email, params: {context: $history}}, {action: send_email, params: {to: $customer_email, body: $draft}} ], exceptions: [ {condition: 客户信息不存在, handler: 询问用户确认客户标识} ] }注意草稿不能直接用必须经过验证才能进 Skill 库。验证方式就是拿它去跑回归集里相关任务通过率达标才准入。4.3 Skill 库的版本管理与冲突处理Skill 越加越多必然冲突。两个 Skill 触发条件重叠、步骤矛盾Agent 就懵了。我的管理策略每个 Skill 带版本号更新是新增版本而非覆盖旧版本保留可回滚。触发条件做互斥检查新 Skill 入库前扫描现有 Skill 的 trigger如果语义相似度超过阈值我常用 0.85强制人工确认是替换还是并存。Skill 有优先级和适用范围不是所有 Skill 都全局可用按任务类型打标签检索时先按标签过滤。冲突类型表现处理方式触发重叠两个 Skill 都想响应同一请求提高优先级或合并步骤矛盾同一任务两种做法保留通过率高的另一个降级参数不兼容工具签名变了 Skill 没更新版本绑定工具变更触发 Skill 复审覆盖不全新场景无 Skill 可用走通用流程并记录事后提炼4.4 Skill 更新的触发时机不是每次任务成功都更新 Skill那样会爆炸。我的触发条件是同一类任务连续成功 3 次以上且没有对应 Skill才提炼新 Skill。已有 Skill失败率超过 20%按周统计触发复审。用户明确纠错立即触发对应 Skill 的修正流程。这个阈值是调出来的。太低会导致 Skill 库噪声大太高会错过进化机会。3 次和 20% 是我在中等复杂度任务上的经验值你可以按自己场景微调。5. 闭环怎么串让评测、记忆、Skill 自动流转而不互相打架5.1 闭环的数据流把前面三块串起来数据流是这样的线上任务执行产生轨迹。轨迹进评测流水线打分并归类。成功且非平凡的轨迹 → 提炼情景记忆 Skill 草稿。失败轨迹 → 进回归集 触发相关 Skill 复审。Skill 草稿/更新 → 跑回归集验证 → 通过则入库。新 Skill 和记忆 → 影响后续任务执行 → 回到第 1 步。这条链路里最容易断的是第 5 步。很多人提炼了 Skill 直接就用结果引入回归。验证环节不能省哪怕只是跑一个 20 条的小回归集。5.2 防止自进化变成自退化自进化最大的风险是正反馈失控Agent 自己提炼的 Skill 有偏差用这个偏差 Skill 又产生更多偏差轨迹越滚越歪。三个防护措施准入门槛Skill 入库必须过回归集通过率不低于现有基线。灰度发布新 Skill 先在小流量任务上用观察一周再全量。一键回滚Skill 库和记忆库都要有快照出问题能退回上一个稳定版本。我踩过最惨的一次坑一个从成功轨迹提炼的 Skill 在特定边界条件下会死循环调用工具因为提炼时没覆盖那个边界。后来加了单任务工具调用次数上限作为硬约束任何 Skill 超过 15 次调用就强制中断并上报。这个上限救过我好几次。5.3 可观测性没有日志就没有闭环闭环要能运转前提是每一步都可观测。我必埋的日志点每次任务输入、用到的 Skill、工具调用序列、最终结果、耗时、token 消耗。每次记忆检索查询、召回的记忆 id、最终用了哪几条。每次 Skill 更新新旧版本、触发原因、回归集通过率。每次评测批次 id、各指标分数、和上一批的 diff。这些日志用结构化格式JSON打到统一的地方方便做聚合分析。我一般用一个简单的看板展示Skill 库规模趋势、回归集通过率趋势、记忆命中率、平均任务步数。这四个指标任何一个异常波动就说明闭环某处出问题了。5.4 一个最小可跑的闭环实现如果你现在什么都没有我建议按这个顺序搭两周能跑起来最小闭环第 1~2 天定义轨迹日志格式所有任务执行都落盘。第 3~4 天手写 30 条回归样本写一个规则打分脚本。第 5~7 天实现情景记忆的写入和检索先用最简单的向量库。第 8~10 天实现 Skill 的 JSON 格式和注册表手动加 2~3 个 Skill。第 11~12 天写一个提炼器把成功轨迹转 Skill 草稿。第 13~14 天把验证环节接上草稿必须过回归集才能入库。这个最小闭环跑通后再逐步加时间衰减、冲突检测、灰度发布这些高级特性。先跑通再优化别一上来就设计完美架构那样永远上不了线。6. 几个我反复踩过的坑和对应的解法6.1 记忆污染检索到看起来相关但实际无关的内容向量检索的相似度高不等于有用。我遇到过检索出语义相似但任务类型完全不同的记忆Agent 照着做直接跑偏。解法是混合检索向量相似度 元数据过滤任务类型、时间范围、成功状态。元数据过滤能砍掉大部分噪声剩下的再按相似度排。6.2 Skill 膨胀加了 200 个 Skill 反而更笨Skill 太多Agent 选择困难触发准确率下降。解法是分层 Skill高频核心 Skill 常驻长尾 Skill 按需加载。具体做法是给 Skill 打场景标签任务开始时先判断场景只加载该场景下的 Skill。我实测把常驻 Skill 控制在 20 个以内触发准确率明显回升。6.3 评测和线上脱节分数涨了体验没涨评测集如果全是自己编的理想样本和线上真实分布差太远。解法是定期用线上流量刷新评测集保证评测集里至少有 50% 来自真实请求。另外评测指标要和业务指标对齐比如你关心的是任务完成率就别只盯着回答质量分。6.4 更新不可回滚改坏了只能干瞪眼早期我没做版本管理一次 Skill 更新把线上搞挂只能手动改回来。现在所有 Skill 和记忆库都做快照每次更新前自动备份出问题一条命令回滚。这个成本极低但救命。7. 关于这套闭环我个人的几点体会搭这套东西两年多最大的感受是Agent 自进化不是让模型自己变聪明而是让工程系统帮它把经验管好。模型能力是天花板闭环决定你能不能摸到天花板。我见过模型很强但闭环稀烂的项目上线就退化也见过模型一般但闭环扎实的项目越跑越稳。如果只让我保留一个环节我会保留回归评测集。它是整个闭环的地基没有它记忆和 Skill 的更新都是盲目的。记忆和 Skill 是上层建筑可以慢慢加但评测集必须从第一天就有。最后一个实操建议别追求全自动。我现在的闭环里Skill 入库和记忆清理这两个环节都保留了人工确认。全自动听起来酷但一旦出错排查成本远高于省下的那点人力。半自动、可观测、可回滚才是能长期跑下去的形态。
