LLM agent 今年最热的叙事之一，是“技能进化”。框架会把一次成功经验保存成 skill、SOP、recipe 或 playbook，下次遇到相似任务时复用。这个想法很自然：人类会沉淀经验，软件团队会写 runbook，agent 也应该能把成功轨迹变成可复用技能。
问题是，很多 demo 只证明 agent 能把经验写下来，没有证明这些经验真的带来可迁移能力。更尖锐地说，连续执行任务时的性能提升，可能只是上下文里残留了前面任务的信息，并不是技能库在发挥作用。
arXiv 近期的 ContinualSkillBench 正好切中这个问题。它问的不是“agent 能不能写技能”，而是“agent 能不能在连续任务中真正进化能力”。这比单次 benchmark 更难，也更接近生产环境。
论文要解决的问题
现有 agent 技能系统通常有三步。
第一，执行任务并观察结果。
第二，把成功经验或失败修正总结成技能。
第三，在未来任务中检索或触发这些技能。
听起来合理，但里面有几个未被充分验证的假设。技能是否足够抽象？触发条件是否准确？旧技能会不会误导新任务？技能库变大后检索是否更难？弱模型总结出的技能是否只是“这次这么做”的局部笔记？
ContinualSkillBench 的贡献，是把这些问题放到动态任务序列里评估。任务不是互相独立的选择题，而是有递增难度和复用机会的子任务。这样才能观察 agent 是否从前面的经验中获得可迁移收益。
Benchmark 设计的关键
论文设置了五个代表性领域，每个领域包含 100 个互相关联、难度递增的子任务。这个设计比随机任务集合更适合测技能进化，因为真实技能必须跨任务复用。
如果任务完全无关，技能库当然没用。如果任务几乎重复，缓存答案也能拿高分。好的持续学习评测应该处在中间：任务有共享结构，但不能靠复制粘贴解决。
这里的核心评估对象不是模型单点能力，而是不同机制在连续执行中的表现。例如：
- 只靠上下文历史，不显式维护技能。
- 执行后把经验写入技能库。
- 后续任务从技能库检索相关技能。
- 比较不同模型在同一机制下的收益。
这种设置能拆开一个常被混淆的问题：性能提升来自模型适应上下文，还是来自显式技能抽象。
主要发现
论文最值得注意的发现，是顺序执行通常会提升表现，但提升幅度因模型和领域差异很大。这说明连续任务确实提供了可利用信息，但不同 agent 是否能把信息变成技能，还没有稳定答案。
第二个发现更关键：平均来看，显式技能维护并不总是明显优于 in-context learning。换句话说，把经验写成技能文件，并不自动创造可复用能力。有些提升可能只是模型在长上下文中看到了先前反馈，然后临时调整行为。
第三个发现是，显式技能在某些任务上仍有选择性收益。尤其是需要重复过程、固定格式、精确输出或多步操作的任务，技能可以减少重复探索。这很符合工程直觉：runbook 对确定流程有用，对开放式判断不一定有用。
第四个发现是，能力较弱的模型往往积累更多、更碎片化的任务特定技能。这一点对生产系统很危险。一个看似勤奋的 agent 可能在不断写经验，但技能库逐渐变成局部补丁集合，检索时噪声越来越大。
对 Agent 框架的提醒
很多框架把 skill memory 做成“成功就总结，失败就反思，再追加到库里”。ContinualSkillBench 提醒我们，这种追加式设计容易失控。
技能库需要治理，而不是只需要存储。至少要有四种元数据。
第一，触发条件。技能适用于什么任务，不适用于什么任务。
第二，证据来源。技能来自哪次任务、哪条测试、哪个人工 review。
第三，失败样本。技能在哪些相似任务中失败过。
第四，版本和回滚。技能被改写后，旧版本是否还能追溯。
没有这些元数据，技能库就像没有测试的公共函数库。短期看会提高成功率，长期看会积累隐性负债。
为什么上下文适应会伪装成技能进化
连续任务中，模型可能通过上下文获得很多临时线索。例如前一个任务刚刚解释过 API 用法，下一个任务又使用同一 API。即使没有技能库，模型也能从聊天历史里借用信息。
这并不是坏事。上下文适应本身就是 LLM 的能力。但如果产品宣称“agent 学会了技能”，就必须证明信息被压缩成了可迁移资产，而不是只在本次会话里有效。
一个简单判断方法是 replay。把技能拿出来，在新会话、无历史上下文、相似但不重复的任务上测试。如果性能仍然提升，才更接近真实技能复用。如果离开原会话就失效，那它更像临时上下文提示。
工程落地建议
第一，不要无限追加技能。给技能库设置容量、合并和淘汰机制。低频、低收益、高冲突的技能应该被降权或删除。
第二，技能必须有测试。一个技能如果声称“修改 React 表单校验时应同步更新 schema 和测试”，就应该有至少几个 replay 任务证明它减少错误。
第三，区分 procedure skill 和 preference skill。前者是操作流程，例如发布版本步骤；后者是偏好，例如团队喜欢小函数。两者触发和验证方式不同。
第四，让强模型负责技能整理，弱模型负责执行时检索。论文发现弱模型容易写碎片技能，这意味着技能库维护最好不要完全交给最便宜模型。
第五，技能应该可以被人工 review。尤其在代码、安全、数据和运维场景里，agent 自动生成的技能相当于新的内部流程，必须进入审计。
与近期技能论文的关系
本站最近已经覆盖过 SkillProx、SkillGuard、skill 类工具和 agent harness 评测。ContinualSkillBench 的位置不同：它不只是提出一个新的技能更新算法，而是追问评测本身是否能区分“看起来在学习”和“真的形成可复用能力”。
这类 benchmark 会让 agent 技能系统从 prompt 工程进入软件工程。以后讨论技能库，不应该只展示一段自我反思文本，而要展示 replay set、触发精度、误触发率、技能冲突率和长期维护成本。
局限
任何 benchmark 都有覆盖边界。五个领域和 100 个子任务能提供结构化比较，但真实生产任务还有权限、数据漂移、多人协作、代码变更和业务约束。论文结果不能直接推出某个具体框架必然无效。
另外，技能的定义也会影响结论。如果技能只是文本规则，收益有限很正常。如果技能包含可执行脚本、类型检查、测试夹具和状态机，效果可能不同。因此工程团队读这篇论文时，不应把结论简化成“技能没用”，而应理解为“技能需要更强评测和治理”。
结论
ContinualSkillBench 的价值在于把 agent 技能进化从叙事拉回证据。它告诉我们：连续任务表现提升不等于技能库有效，显式技能维护也不是免费午餐。
对开发者来说，正确态度是把 skill 当成软件资产。它要有触发条件、适用边界、测试、版本、审计和清理机制。否则 agent 只是在把每次会话里的偶然经验写进一个越来越大的文本抽屉。
参考来源：ContinualSkillBench arXiv、Hugging Face Papers、Can LLMs Actually Use Skills in Agentic Harnesses、Learning Globally Reusable Skills for Coding Agents。