你的 Agent 有一千个技能，然后它开始挑错——问题不在模型，在检索
- 关联论文：2606.11435
你的 Agent 平台上线三个月，技能库从 40 个涨到 1200 个，里面躺着"发邮件""生成周报""查数据库"……名字清楚，描述规范。
然后 Agent 开始挑错技能了。要做的事明明有 weekly_report_v2，它选了 weekly_report_v1。你第一反应是：模型不行，换个更贵的模型。
但 2026 年 6 月这篇《Agent Skill 评估与演化:框架与 Benchmark 综述》指出的原因更朴素也更致命：技能库超过几百条，靠"skill 名字 + 描述"让 LLM 自己挑，就显著不可靠了。必须上 retriever + reranker 二级管线——这不是模型不够强，是架构问题：你让生成模型干了本该检索系统干的活。
一、这问题为什么重要
2025–2026 年 Skill 生态（tool card、skill directory、procedural knowledge）从几十条膨胀到上万条。痛点归成三个：评估缺失（能不能用、好不好用、安不安全，没公认方法）、缺乏演化路径（技能写完几乎不更新）、检索失效——就是开头那个。
论文给出的统一形式化定义，让"评估"和"演化"终于有了共同语言：$\mathcal{S} = (C,\ \pi,\ T,\ \mathcal{R})$，分别是触发条件、执行策略、终止条件、"能与其他 skill 组装"的接口。论文还把 Skill 与 prompt engineering 划清界限：prompt 是一次性指令，Skill 是可复用、多步、调用外部工具的"过程性知识"。
二、核心机制：使用三层 + 演化四范式
论文把"技能被使用"拆成三层：(a) Retrieval（召回一小撮相关 skill）、(b) Routing（每一步决定调哪个）、(c) Management（维护、组织、版本化、剔除不安全 skill）。
核心洞察落在 (a)：仅靠 LLM 按名字 + 描述做选择，在库超过几百条后显著不可靠，必须引入 retriever + reranker 二级管线。
演化方法按学习信号的来源与粒度归成四个象限：
| 范式 | 信号粒度 | 代表工作 |
|---|---|---|
| 执行反馈 | step 级 | SkillForge / CoEvoSkills / Skills-Coach / AutoSkill |
| 轨迹蒸馏 | sequence 级 | SPARK / Trace2Skill / Memento-Skills / XSkill |
| 压缩与增强 | library 级 | SkillNet / SkillX / SkillReducer / SkillFoundry |
| 强化学习 | task 级奖励 | D2Skill / SkillRL / SkillOS / Skill1 |
四类正交而非互斥，可以叠加。论文给了一条特别值得拎出来的结论："结构化失败诊断"与"重写生成"分离的设计（SkillForge / CoEvoSkills）在跨任务上系统性优于端到端 raw-trace 模型（AutoSkill / SkillClaw）。别把原始 trace 直接喂给模型重写——先诊断根因，再让它改。
三、证据边界
这是综述，论文自述"汇总而非直接实验"。能支撑的："Skill 选择不再可仅靠描述"这一定性结论——大规模库（数百条以上）下 LLM 自我选择精度显著低于 retriever + reranker；"结构化失败诊断 → 改写"分离系统性优于 raw-trace；两个规模锚点 WildClawBench（60 tasks / 6 类，真实 OpenClaw 环境 + Docker 隔离评分）与 SkillForge Benchmark（3,737 tasks / 5 类云技术场景）。
不能支撑的：综述本身不报告单一数字，所有比例、p-value、reward 提升幅度都不在摘要口径内——解读层刻意不引用任何百分比，那些多半是二手推断。四范式之间缺 head-to-head，论文自己承认。检索结论是定性的，"显著更低"是否对应量化比较需回 PDF 核实。时间窗止于 2026 年 6 月。安全维度偏薄——只在摘要级提到，而这恰是实践中最要命的。
四、工程局限：五个坑
坑 1：检索质量依赖 description 写作质量。 很多团队的 skill description 是 LLM 生成或随手写的，信息密度极低，reranker 再好也救不了。修复：规范定死必填触发条件 / 输入输出 schema / 已知 failure case。
坑 2：演化循环的 reward 噪声大。 显式反馈（👍👎）稀疏，隐性反馈有延迟。修复：把"完整 task 的 success/fail"当作 skill 级 reward 而非 step 级，能减少噪声。
坑 3：Skill 版本爆炸。 没有版本化系统（git tag + changelog），时间一长团队自己都不知道哪个版本在生产。修复：skill 库用与代码同级的版本管理，先接受多版本共存、在 router 分发。
坑 4：Skill Security 是实际最大坑。 论文这块最薄，但现实里有害 skill（返回错误信息、绕过权限检查）是最快造成破坏的向量。修复：把"skill 权限验证"做成独立组件，而不是信任 skill 自己。无成熟安全 benchmark，需自建对抗套件。
坑 5：多模态 skill 评测无基准。 视觉 / 工具调用混合的 skill 无现成基准。
最容易先跑起来的一件事：四范式里执行反馈最容易落地，不需要额外基础设施——给每次执行埋 skill_id / step_index / success_bool / error_type，跑 2–4 周后用 embedding 聚类失败 trace，同类错误 ≥3 次就触发审查。
一句话总结：这篇 2026 年综述的第一性贡献，是把"skill 怎么被评估"和"skill 怎么自己变好"拆进同一张地图：使用策略分检索/路由/管理三层，演化分执行反馈/轨迹蒸馏/压缩增强/强化学习四范式。最实用的硬结论是——skill 库大到几百条以上，"让 LLM 按名字和描述自己挑"就走不通了。不是模型不够强，是架构选错了。
论文 arXiv：https://arxiv.org/abs/2606.11435 项目页：https://github.com/Cassie07/AgentSkill_Survey
三个标题变体
痛点版：一千个技能之后，Agent 开始挑错——问题不在模型，在检索 方法版：Skill 演化四范式：执行反馈、轨迹蒸馏、库级压缩、强化学习 反直觉版：别让模型按名字挑技能了，库一大就得换架构
📱 小红书风格卡片文案（可直接发布）
🧩 你的 Agent 有一千个技能，然后它开始挑错
你以为是模型不行。其实是架构选错了。
🔍 2026 年首篇 Skill 综述的硬结论：
技能库超过几百条后，仅靠"skill 名字 + 描述"让 LLM 自己挑就显著不可靠 必须上 retriever + reranker 二级管线
这跟"换更贵的模型"是两回事 👉
📐 论文给的完整地图： 使用三层：检索 / 路由 / 管理 演化四范式（按学习信号粒度分） 1️⃣ 执行反馈（step 级） 2️⃣ 轨迹蒸馏（sequence 级） 3️⃣ 压缩与增强（library 级） 4️⃣ 强化学习（task 级） → 四者正交可叠加
⚠️ 5 个最贵的坑： - description 写得烂，reranker 也救不回来——先定规范：触发条件/输入 schema/输出 schema/已知 failure case - 别把原始 trace 直接喂给模型重写——"结构化失败诊断 → 改写"分离，系统性优于端到端 raw-trace - reward 噪声大——用 task 级 success/fail，别用 step 级 - 多版本 skill 会炸——git + changelog 管起来 - 安全是最大的坑——有害 skill 是最快造成破坏的向量，权限验证要做成独立组件
🚀 最容易先跑起来的一件事：给每次 skill 执行埋 skill_id / step_index / success_bool / error_type，然后聚类失败模式——同一 skill 同类错误 ≥3 次就触发审查
🔗 arXiv：https://arxiv.org/abs/2606.11435