自进化Agent技能综述：19种方法、10个基准与3个评估盲区

你给 Agent 写了一个技能——比如“自动处理客户工单”。第一天它跑得很好。第三天遇到新类型的工单，它开始犯错。你是手动改？还是让它自己学会改？如果让它自己改，你怎么知道它改对了，还是改出了新的隐患？

这篇来自 Rutgers 大学和 UNC Charlotte 的 survey，第一次系统梳理了 Agent 技能的进化与评估全貌。它覆盖了 19 种技能进化方法 和 10 个评估基准，但最值得注意的结论不是方法有多丰富，而是——当前没有一个 benchmark 能追踪技能在多轮反馈后是否真正变好了，评估体系还停在“过不过”的原始阶段。

技能是什么，为什么不能“写好就完”

Agent 技能不是一段 prompt，也不是一个 API 调用。它是一个结构化包：什么时候该用（触发条件）、怎么执行（策略）、什么时候停（终止条件）、能不能和其他技能组合（复用接口）。

当技能库只有几个的时候，手动维护还行。但当技能规模上来，手动维护就不现实了——一个过时或有缺陷的技能，会沿着下游任务传播错误。所以技能需要持续进化，而不是写好就完。

技能进化有四条路，信号来源各不同

这篇 survey 把技能进化分成四个范式，按照“信号从哪来”和“信号粒度多细”来区分：

这四条路不是互斥的，但代表了最主流的设计选择。

一个关键发现：把“诊断失败”和“重写技能”分开的系统，跨任务效果明显更好。 SkillForge 和 CoEvoSkills 先用验证器做根因分析，再让模型针对性改写，效果显著强于直接在原始轨迹上让模型自己改的 AutoSkill 和 SkillClaw。原因是原始轨迹里的噪声太多，模型容易把任务特异性的偶然行为当成可复用的模式。

另一个值得关注的趋势是 库级压缩——当技能库膨胀到成百上千，技能之间开始重叠和冲突，导致冗余探索和泛化变差。SkillX 的做法是：合并相似技能、拆分复杂技能、评估泛化能力，优先探索那些“还没被充分测试”或“经常失败”的工具。

RL 进化的根本矛盾：分不清是技能进化了还是模型变强了

强化学习 这条路有一个被忽视的根本问题。

标准 RL 每次只奖励单个任务，但技能的真正价值在于 跨任务复用。D2Skill 的做法是：对每个任务跑两次（带技能 vs 不带技能），用成功率差距作为更稳定的奖励信号。Skill1 更进一步，用一个策略同时完成技能搜索、选择、任务求解和技能进化。

但所有这些方法都依赖任务级奖励，而 任务级奖励会把技能质量和模型能力混在一起——你看到的性能提升，到底是因为技能变好了，还是因为模型本身变强了？目前没有任何方法能干净地拆开这两个因素。

评估体系的三个结构性盲区

这篇 survey 对 10 个技能评估基准做了系统分析，发现了三个结构性问题：

盲区一：没有纵向追踪。 没有任何 benchmark 追踪技能在多轮反馈后是否真正改善。你只能知道“这一轮过了没有”，但不知道“技能是不是在变好”。

盲区二：指标只有“过不过”。 评估几乎全是二元通过率，忽略了 token 成本、延迟、错误类型 这些实际部署中至关重要的因素。SkillsBench 的数据显示，精选技能能把平均通过率从 16% 提升，但提升幅度从软件工程的 +4.5pp 到医疗的 +51.9pp 不等——这种巨大差异本身说明，单一通过率指标掩盖了太多信息。

盲区三：安全只做一次性检查。 SkillGuardBench 标注了 581 个技能包的三类攻击模式（隐藏覆写、伪装传输、远程引导），但现有安全审计把技能安全当作“进门检查”，而非“持续监控”。不受控的技能自进化可能悄悄剥离已有的安全约束，而当前评估框架对这种风险几乎无能为力。

这对搭建 Agent 系统的人意味着什么

技能不是静态代码，而是需要像软件一样持续迭代的 活资产。但当前的评估基础设施，连软件工程最基本的“版本号”和“回归测试”都没有。

这篇 survey 最核心的判断是：技能生态应该被视为持续进化的基础设施，而不是写完就用的静态工具。 持续评估和进化是可靠使用、依赖控制和真实部署的核心——但现在的评估体系，离支撑这件事还差得远。

论文标题: Agent Skill Evaluation and Evolution: Frameworks and Benchmarks
论文链接: https://arxiv.org/abs/2606.11435v1
GitHub: https://github.com/Cassie07/AgentSkill_Survey