一句话讲清楚👉🏻 腾讯微信团队提出 SkillHone 框架，把 Agent 技能优化过程中的诊断、修改、评估证据和决策结果全部持久化记录，让后续会话能继承”为什么这样改”的上下文，在 GAIA 和 WebWalkerQA 上分别比商用 Deep Research Agent 高出 15.8 和 3.2 个百分点。
-
论文标题：SkillHone: A Harness for Continual Agent Skill Evolution Through Persistent Decision History
-
论文链接：https://arxiv.org/abs/2606.08671
-
Github 链接：https://github.com/Tencent/SkillHone
-
项目链接：https://zwlijay.github.io/SkillHone-Project
一个真实会发生的场景
你维护过 Claude Code 或 Codex 里的 Agent Skill 吗？第一次写 SKILL.md 时，搜索脚本跑通了，验证也过了。两周后 DuckDuckGo 改了接口， Agent 开始频繁超时。你让模型”再优化一下技能”，它把超时重试逻辑改回去了——恰好是你第一轮已经试过、后来证明会拖慢整体流程的方案。
问题不在模型不够聪明，而在上一轮优化的决策上下文丢了。后来的 Agent 只拿到最新的 SKILL.md 快照，看不到：当时诊断出了什么、哪些补丁被拒绝、评估探针暴露了哪种失败模式、为什么最终选了 A 方案而不是 B 。
腾讯微信团队的新论文 SkillHone ，瞄准的就是这个被忽视的缺口：技能进化既要产出更好的 Skill 包，也要留下可跨会话复用的决策历史。
只保留最终技能产物时，后续 Agent 可能重复已废弃的修复，让后续优化更难推进。
Agent Skill 已成主流，但维护仍是手工活
过去两年，技能（ Skill ） 从 Claude Code 、 Codex 到 Hermes ，几乎成了扩展 LLM Agent 能力的标准单元。一个 Skill 通常打包了：
SKILL.md）把它想成”可热插拔的操作手册”就行： Agent 遇到某类任务时加载对应 Skill ，按既定流程搜索、解析、验证、输出。
但 Skill 从来不是一锤子买卖。 API 会变、网页结构会变、免费搜索接口会限流。一个能在今天跑通的 Deep Research Skill ，下个月可能就卡在同一个边界情况上。创建—调试—扩范围—打补丁 这个循环，在 Skill 的整个生命周期里反复出现。
现有改进路线大致分两类：
合成式构建（如 Anthropic 的 Skill-Creator ）：从任务描述或样例生成一个可加载 Skill ，交给后续会话直接用。
反射式优化（如 Hermes-SE ，基于 GEPA ）：在单次优化轮次里做变异、评估、选择，迭代改进 Skill 、 Prompt 、工具描述甚至代码。
这两条路都能在一轮有界优化内把 Skill 做得更好，但共同点是：最终只留下优化后的产物。 Git diff 能告诉你改了哪几行，却回答不了”为什么改”和”试过什么没成”。
论文要回答的方法论问题
SkillHone 论文把核心问题写得很清楚：后续 Agent 如何在多次开发会话之间继续改进 Skill ，同时不丢失早期改动的依据？
这里的”依据”包括三层信息：
如果只保留 （最终 Skill 快照），后续会话面对新故障时，只能从零开始猜——这和软件工程里”只有最终代码、没有 commit message 和 PR review”是一个困境。
Agent Skill 生态的三股力量
理解 SkillHone 的位置，需要先看清 2025–2026 年 Agent Skill 生态的三条主线：
平台侧： Claude Code 、 OpenAI Codex 、 Hermes 等运行时把 Skill 变成一等扩展单元，用户可加载、卸载、组合 Skill ，像插件一样切换任务模式。
社区侧： ClawHub 、 SkillHub 等平台涌现大量社区 Skill——搜索、爬虫、文献综述、代码审查等，质量参差不齐但覆盖广。
研究侧： SkillsBench 问”Skill 到底有没有用”； Skill-R1 、 SkillForge 等探索自动发现和强化学习进化； GEPA/Hermes-SE 把反射式优化引入 Skill 组件。
SkillHone 填的是第四块拼图： Skill 已经存在、已经在跑，如何在长达数月的生命周期里持续维护，且不把每次优化的上下文丢进垃圾桶。这和”怎么生成第一个 Skill”是不同问题，论文的贡献列表也按这个切口组织。
合成式 vs 反射式：各自擅长什么
Skill-Creator 路线 适合冷启动：你有一个任务描述、几份样例文档，想快速得到一个可加载的 Skill 包。它的优化发生在”生成阶段”，产物交给后续会话后，维护责任就转移给了用户或下一个 Agent 。
Hermes-SE / GEPA 路线 适合单轮改进：在同一轮优化里对 Skill 正文、 Prompt 、工具描述做反射式变异，用标量验证分数决定接受或跳过。这在有界轮次内有效，但轮次结束后历史通常不保留——下一轮优化又从 和标量信号重新开始。
SkillHone 与上述两条路线互补，专注解决 轮次与轮次之间的连续性断层。你可以用 Skill-Creator 生成 ，再用 SkillHone 在数月内持续打磨；也可以把 Hermes-SE 的一轮输出当作种子，接入 SkillHone 的长期维护环。
从架构图读设计：左侧改 Skill ，右侧跑探针
架构图（ Figure 2 ）把 SkillHone 画成左右两团子 Agent 团队，中间是 Agent 运行时（ Claude Code / Codex / …）和仓库操作层。
左侧优化 Agent 团队 维护 Skill 仓库：诊断员读脱敏报告和历史做诊断，探索员整合既往资源和失败维基，提案员起草类型化修订并开 PR 。它们能改 SKILL.md、脚本、参考文档、模板，但永远碰不到探针的标准答案。
右侧评估 Agent 团队 维护 Skill-Eval 仓库：执行员在探针上跑候选 Skill ，分析员分析执行轨迹，报告员输出脱敏问题报告。它们能查看探针、验证器和轨迹，但不能写 Skill 仓库。
中间持久决策历史 按时间轴串联维基、 Issue 、 PR 、合并/拒绝操作——每一轮迭代都在这条轴上留痕。后续会话的诊断员可以先翻阅这条轴，再决定本轮要不要重新打开旧 Issue 。
这种布局的工程含义是：SkillHone 不绑定特定 Agent 产品，只要求运行时能按需启动权限隔离的子任务——Claude Code 、 Codex 、 Hermes 都能接。
开源仓库里有什么
GitHub 仓库 https://github.com/Tencent/SkillHone 已公开，项目页 https://zwlijay.github.io/SkillHone-Project 提供补充材料。对想复现的读者，建议按这个顺序读：
复现门槛主要在 评估仓库建设：公开基准的最终测试集不能进优化循环，你需要自建练习探针，或按论文规范划分训练/验证 split 。
读者画像与本篇读法
本篇默认读者：有技术背景、关注 AI/Agent 工程实践，但不是 Skill 优化方向专家。
如果你主要写 Skill 、维护 Agent 工作流，重点读「五轮进化实录」「三条实操建议」和 Figure 4 轨迹对比；如果你做 Agent 平台，重点读角色边界和脱敏设计；如果你跟进 Agent 研究，重点读和 GEPA/Hermes-SE 的差异轴及消融实验。
问题形式化： Skill 是什么， SkillHone 优化什么
论文对 Skill 的定义很克制：一个可移植产物，打包 Agent 完成某类任务所需的说明、流程、参考文档和输出约定。 SkillHone 固定模型后端和外部工具，专注在 Skill 产物本身如何跨会话维护。
它维护两个关联仓库，接受修订后产生 Skill 序列 ，整个过程由练习反馈和持久决策历史共同引导。
优化侧只看到脱敏报告，看不到未脱敏的目标、验证器或执行轨迹——这是整个框架能扩展的前提：练习反馈不能变成直接死记硬背的目标，否则 Agent 只是在探针上背答案，学不到流程。
SkillHone 的核心主张：决策历史比最终产物更重要
SkillHone 的出发点很直接——把 Skill 修订和评估证据都当作带决策信息的记录，文件 diff 只是其中一环。
每条决策记录包含四个要素：
到第 轮，完整历史是 。
这和版本 diff 的区别在于：diff 只描述”变了什么”，决策记录把变化绑回到”针对什么问题、依据什么证据、最终为什么接受或拒绝”。当环境再次变化——比如限流策略升级——后来的子 Agent 可以查 ，判断这是新故障还是旧问题复发，避免把已经证伪的补丁又加回来。
用人话翻译上面四个符号： 是”我觉得哪里坏了”， 是”我打算这样修”， 是”跑探针后脱敏的体检报告”， 是”这版补丁合并还是拒绝”。四者绑在一起，才构成可审计的一轮进化步骤；缺任何一项，后续 Agent 都会猜。
论文还强调 决策结果不止接受/拒绝二元，还有”要求再改一版”和”暂缓、等更多证据”。这对应真实维护里常见的”方向对但补丁不完整”——SkillHone 允许部分接受路径，而不是 Hermes-SE 式的整包跳过。
Figure 1 在警告什么
开篇示意图（ Figure 1 ）画的是一个具体失败链条：限流来了 → Agent 加重试 → API 改版 → 下一轮优化又把重试加回来，因为看不到上一轮拒绝重试的证据。 SkillHone 的应对是：把”因拖慢整体流程而拒绝重试”写进 ，下次调度先检索这条记录，直接跳过已知无效补丁。
SkillHone 架构：优化侧维护 Skill 仓库，评估侧维护探针与验证集；角色隔离的子 Agent 按需调度，脱敏证据与仓库操作共同构成持久决策历史。
双仓库 + 角色隔离：怎么把”记忆”落地
SkillHone 把整个框架形式化为：
两个关联仓库
Skill 仓库 存当前 Skill 包：SKILL.md、脚本、参考文档、模板等。
Skill-Eval 仓库 存评估资产：练习探针、标准目标、验证器、回归集、执行轨迹、脱敏报告等。
优化侧只能看到脱敏报告，看不到未脱敏的探针答案、验证器和完整轨迹。这样练习反馈不会变成直接背答案的捷径。
角色边界为什么关键
评估侧子 Agent 可以查看探针和轨迹，在探针上跑当前 Skill ，分析失败并输出脱敏报告——但不能写 Skill 仓库。
优化侧子 Agent 可以改 Skill 、读历史决策——但不能碰未脱敏的探针目标。
调度器只是消息路由器：把脱敏证据和审查请求在两侧之间转发，记录被接受的决策结果。接受/拒绝由有相应权限的一侧做出，保证决策历史和产生它的权限边界一致。
论文把反复出现的调度模式列成表（附录 E ），典型角色包括诊断员、探索员、提案员、报告员、分析员、执行员等——全部在运行时按需创建，每个任务权限受限、范围明确。
算法循环
整体流程对应 Algorithm 1 ：
多轮之后输出最终 Skill 和完整决策历史 。
逐步直觉：
SKILL.md、加参考文档等），不是整篇重写论文强调 调度器 不是决策权威：它只路由消息、记录结果，避免中央编排器变成瓶颈或单一偏见来源。
GitHub 式工作流：让进化过程可审计
实现上， SkillHone 用类似 GitHub 的仓库工作流承载决策历史：
附录 Table 4 展示了一次 Deep Research Skill 的五轮进化：从 DuckDuckGo 搜索脚本、错误处理、时间管理，到合并前两轮优点、加入 Wikidata SPARQL ，再到回滚预算参数同时保留名字格式规则——每一轮改了哪些文件、多少行增删，都有 PR 记录。
第 5 轮尤其说明问题：探针显示预算从 20 提到更高后性能下降， SkillHone 只回滚预算相关改动，保留名字格式规则和 SPARQL 脚本。这种”局部回滚”在只有最终产物的优化框架里很难做到。
五轮进化实录： Issue/PR 里到底发生了什么
附录 Table 4 记录了一次 Deep Research Skill 从种子到第五轮的完整仓库操作——它展示了 SkillHone 如何同时改 SKILL.md、 shell 脚本和 Python 脚本，而不是 Hermes-SE 那样主要重写单一 SKILL.md 正文。
第 1 轮： DuckDuckGo 超时频发 → 加重试逻辑 + 补 wiki/wikidata 脚本 → 合并。探针显示搜索链路稳定，但写入策略仍偏保守。
第 2 轮：真实网页搜索仍偶发失败 → 把 ddg shell 换成 Python 实现，加 Jina 抓取 → 合并。证据显示 Python 版错误处理更可控。
第 3 轮：前两轮各有优点（第一轮脚本全、第二轮抓取稳）→ 读 做精准合并，减轻验证负担、收紧预算 → 合并。这是决策历史价值的典型时刻。
第 4 轮：名字格式解析失败 → 加 Wikidata SPARQL 脚本 + 收紧预算 → 合并。诊断链写进 Issue #15 ，后续 Agent 知道 SPARQL 为何存在。
第 5 轮：预算调高后探针分数下降 → 只把预算回滚到 20 ，保留名字规则和 SPARQL → 合并。若无 #15/#19 的关联记录，这一步几乎不可能精准执行。
（附录 Table 4 还列出了每轮 PR 的文件级 diff 行数，此处从略。）
各调度角色分工
附录 E 的权限表把反复出现的模式拆得很细，核心几类：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
失败维基是优化侧维护的失败摘要库，和 Issue 链互补： Issue 记录单次诊断，维基沉淀跨迭代的失败模式。新调度任务可以先查维基，再决定是否重新打开旧诊断。
实验设计：在”裸网”环境里测 Deep Research
论文选 Deep Research 作为评测场景，因为信息检索是 Agent 最广泛的工作负载之一，天然需要可复用 Skill ：搜索、导航、抽取、验证、失败恢复要跨不断变化的网页源组合，免费接口还会限流、挂掉、改格式。
两个基准各自考什么
GAIA 的纯文本验证子集强调多跳信息检索： Agent 要在网页、文档、表格等异构源之间跳转，最终给出有据可查的答案。 L1/L2/L3 难度递增， L2 往往要求”先搜到 A ，再用 A 里的线索搜 B ，最后交叉验证”。
WebWalkerQA-EN 更偏网页遍历：给定起始 URL 或站点， Agent 要在 DOM 结构里导航、定位、抽取。 Easy 档可能是单页抽取， Med./Hard 需要多跳点击和上下文跟踪。
Deep Research 作为工作负载的选取理由：这两类能力恰好是社区搜索 Skill 要编排的——关键缺口在流程层：何时用哪个 Skill 、失败后如何换路。 SkillHone 的增益集中在流程层，和基准设计意图对齐。
两种评测设定
精选检索（ Curated search ）： Deep Research Agent 使用商业检索服务，不自建搜索栈。
裸网开放网页（ Raw open-web ）： Agent 没有预集成搜索工具，只有通用运行时、公网访问和可移植 Skill 包。 Skill 必须自己组织搜索、解析、抽取、恢复流程，并处理限流和页面格式变化。
裸网对比从共享社区 Skill 池 起步——从 ClawHub 和 SkillHub 里由 Agent 选出 10 个搜索相关 Skill ，所有可比系统用同一套起点，差别只在怎么进化这些 Skill。
社区 Skill 池完整列表如下，公平对比的关键是所有人从同一套”半成品”出发：
Existing-Skills 直接用这堆 Skill ； Skill-Creator 在此基础上迭代优化； Hermes-SE 用 GEPA 反射； SkillHone 跑完整框架。输出接口统一：可移植 Skill 包——一个 SKILL.md 入口加可选脚本/参考/模板。
为什么刻意分离控制器和骨干模型
实验设计里有一个容易忽略的细节：优化 Skill 的控制器和执行基准的骨干模型是分开的。
这样最终分数反映的是 Skill 流程在固定执行模型上的效果，避免”Opus 自己写、自己跑、自己评”的闭环过拟合。 Figure 3 的跨骨干模型迁移实验进一步验证：换 Claude Sonnet 4.6 执行， SkillHone 仍领先 10+ 点。
精选检索对照组代表什么
精选检索设定下的 Deep Research Agent 使用商业检索服务，不自建搜索栈。它在 GAIA 平均 48.8%， WebWalkerQA-EN 63.2%。裸网设定下的 SkillHone 在 GAIA 上反超 15.8 点，说明流程化 Skill + 进化机制 可以在没有托管检索的条件下，组织公网信息检索达到更高准确率的子集； WebWalkerQA 上差距较小（+3.2 ），可能因为导航类任务更依赖页面交互细节，商业栈仍有优势。
基线
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
开发期控制器用 Claude Opus 4.6 读反馈、做诊断、改 Skill ；执行与评测骨干模型固定为 Qwen3.6-35B-A3B 。最终基准分数由后者跑出，避免”开发模型和执行模型是同一个”带来的过拟合。
Existing-Skills 基线为什么重要
Existing-Skills （ GAIA 平均 41.7%）代表 “有 Skill 但不进化” 的下界。它比 Deep Research Agent （ 48.8%）还低，说明商业检索在精选设定里仍有价值；但在裸网设定里，一堆未整合的社区 Skill 甚至会互相干扰——Agent 不知道加载顺序、冲突策略和兜底路径。
Skill-Creator 提到 44.1%，略高于 Existing-Skills 但 WebWalkerQA 上反而更低（ 40.8% vs 48.5%），暗示盲目迭代可能破坏社区 Skill 的互补结构。 Hermes-SE 50.4% 证明反射式优化有效，但仍差 SkillHone 14.2 点——决策历史 + 角色边界 的边际贡献在困难分档上被放大。
数字速查：和商用 Deep Research 的差距
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GAIA 上 15.8 点的差距是在 SkillHone 没有预集成搜索栈 的前提下取得的——这对自建 Agent 栈的团队是实质性信号：流程组织可以部分替代托管检索。
论文摘要里的核心主张拆解
摘要四句话，每句对应一个可验证命题：
命题 1 （问题）： Agent Skill 针对的任务和环境持续变化；现有方法在有界轮次内改进 Skill ，只保留最终产物，丢弃后续 Agent 解读历史修订所需的决策历史。
命题 2 （方法）： SkillHone 把 Skill 修订和评估侧证据配对，记录诊断、修订、证据、结果的结构化历史；角色隔离的子 Agent 在练习探针上跑候选 Skill ，用脱敏报告提出修订方案。
命题 3 （公开基准）： Deep Research 基准上， SkillHone 无预集成搜索栈，仍超商用 Deep Research Agent （ GAIA +15.8 、 WebWalkerQA-EN +3.2 ），也超先前的技能进化方法。
命题 4 （内部部署）：内部工具驱动分析场景上，七个设定平均准确率 +18.8 百分点。
读全文时可以用这四命题当核对清单——方法节验证命题 2 ， Table 1/Figure 3 验证命题 3 ， Table 3 验证命题 4 。
术语小词典
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
裸网设定的现实意义
精选检索代表”有预算买商业检索”的部署场景；裸网代表 创业公司、内网、或合规限制下只能用公网免费接口 的场景。 SkillHone 在后者设定下反超前者 GAIA 分数，对”没法接 Exa/Tavily/自建索引”的团队尤其相关。
裸网的难点在 接口间歇性失败、 HTML 结构漂移、限流 三者的叠加，搜索 API 质量只是其中一环。 Skill 里必须写恢复流程：换搜索引擎、换抓取路径、降级验证、写中间结果防超时——这些步骤不会出现在”只靠 Prompt”的优化里，需要脚本 + 参考文档 + 决策历史共同维护。
主结果：没商业搜索栈，反而更强
Table 1 的数字值得逐行看。
GAIA
|
|
|
|
|
|
|
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SkillHone | 76.2 | 66.7 |
|
64.6 |
SkillHone 平均 64.6%，比带商业检索的 Deep Research Agent （ 48.8%）高 15.8 个百分点。在裸网内部，比 Hermes-SE 高 14.2 点，比 Existing-Skills 高 22.9 点。
L2 级别从 40.9% 拉到 66.7%，说明增益集中在需要决定怎么搜、怎么验、怎么从失败路径恢复 的难例上——恰好是 Skill 组织流程的价值所在，远超”多挂几个搜索脚本”能带来的提升。
WebWalkerQA-EN
|
|
|
|
|
|
|
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SkillHone | 53.7 | 69.2 | 68.4 | 66.4 |
平均 66.4%，比 Deep Research Agent 高 3.2 点； Med. 难度从 51.5% 跳到 69.2%，是主要贡献来源。
论文的判断是：把相关 Skill 暴露给 Agent 不够， SkillHone 把它们组织成何时广搜、何时跟源、何时验证、何时换路 的任务流程，主要增益来自流程组织 而非组件堆叠。
开发骨干模型（ Qwen3.6-35B-A3B ）与迁移骨干模型（ Claude Sonnet 4.6 ）上的 GAIA 准确率。 Skill 包未经额外优化直接换模型执行。
跨模型迁移：流程可迁移，而非过拟合单一模型
Figure 3 把同一套 Skill 包直接放到 Claude Sonnet 4.6 上跑，不做额外优化：
相对 Hermes-SE / Existing-Skills / Skill-Creator 分别高出 10.2 / 15.7 / 24.4 点。开发用 Qwen 、评测换 Claude 仍保持领先，说明提升来自 Skill 流程本身——换骨干模型不需要重新优化，流程可迁移。
GAIA 分级细读： L1/L2/L3 各说明什么
GAIA 按难度分 L1/L2/L3 。 SkillHone 在 L1 76.2%、 L2 66.7%、 L3 31.6%。
Deep Research Agent 在 L3 只有 26.3%， SkillHone 略高，但 L3 整体仍是开放问题。读数时要避免只看平均忽视分层：Skill 进化对中等复杂度的多步任务帮助最大，这恰好是生产环境 Agent 最常见的负载区间。
WebWalkerQA 分级细读
WebWalkerQA-EN 按 Easy/Med./Hard 分档。 SkillHone Easy 53.7% 与 Hermes-SE 持平，Med. 69.2%（+17.7 vs Hermes-SE ）和 Hard 68.4%（+13.1 ） 贡献主要增益。 Med. 档通常需要多跳导航 + 页面内定位， Skill 里的抽取和恢复步骤是否写清楚，直接决定 Agent 会不会在 DOM 变化时迷路。
优化轨迹：局部回滚 vs 整包接受
Figure 4 在同一条练习探针验证集上对比 SkillHone 和 Hermes-SE ，两者从同一种子 Skill 出发，跑五轮优化。
SkillHone 从 30% 爬到 70%，中间有两次修订导致性能回退——后续轮次针对出问题的那部分做跟进修正，保留其他有用改动。图上的点标注了每轮接受的修订内容。
Hermes-SE 则在标量验证信号下整包接受或跳过 Prompt 候选，缺少”哪一段改坏了”的粒度。
SkillHone 与 Hermes-SE 在五轮优化中的探针验证集轨迹。 SkillHone 可在回退时保留有用编辑； Hermes-SE 以标量信号整包接受或拒绝。
这个对比把”决策历史”从抽象概念拉到了可操作层面：当一次修订部分有效、部分有害时，有历史就能局部回滚；没有历史就只能全接受或全拒绝。
Figure 4 还有一个细节： SkillHone 曲线上的点标注了每轮接受的修订内容，读者可以直接看到”哪一步改了什么、分数如何响应”。 Hermes-SE 曲线缺少这种标注，因为整包接受不保留部分归因——优化器只知道”这版整体更好/更差”，不知道”更好是因为 A 改动还是 B 改动”。
对生产维护的启示：当你的 Skill 优化工具只给总分时，你实际上在 Hermes-SE 范式里；要进入 SkillHone 范式，需要 修订级日志 + 修订级评估。
消融：决策历史贡献更大
在相同裸网设定和 Qwen3.6-35B-A3B 骨干模型下：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
去掉决策历史： GAIA 掉 13.4 点， WebWalkerQA 掉 10.9 点。
去掉角色隔离：分别掉 6.4 和 5.3 点。
两项机制都有贡献，决策历史的权重更大——符合论文叙事：跨会话可复用的”为什么这样改”，比单次轮次内的权限切分更稀缺。
脱敏评估的形式化
评估侧对探针 跑 Skill 得到输出，验证器 给出结果 ：
优化侧收到的只是脱敏报告：
摘要失败模式、聚合结果和诊断假设，不暴露 未脱敏目标、验证器和轨迹。最终基准评测在优化循环之外进行。
为什么脱敏是硬需求
如果优化侧能直接看到探针的标准答案，最常见的退化是： Agent 在 SKILL.md 里硬编码探针特征或验证器触发条件，练习集分数虚高，最终基准崩盘。 SkillHone 用团队边界从机制上切断这条路径——优化侧只能看到”哪类失败模式占比上升””哪条脚本路径超时率偏高”这类聚合信号。
脱敏函数 的具体策略在附录 D 展开：保留诊断假设和失败分类，去掉 （标准答案）、完整 轨迹和验证器内部逻辑。工程上这意味着 Skill-Eval 仓库和 Skill 仓库的访问权限必须物理分离，不能靠 Prompt 自觉。
“去掉决策历史”变体在做什么
消融里去掉决策历史的版本保留角色隔离的子 Agent ，但每步只从最新 Skill 产物出发，在标量信号上优化——本质上接近反射式基线的行为。 GAIA 从 64.6% 掉到 51.2%，说明 仅有角色隔离不够，没有 就无法做针对性回滚和避免冗余编辑。
去掉角色隔离的版本保留历史，但允许单个子 Agent 同时访问 Skill 仓库和未脱敏评估资产。掉 6.4 点，部分原因可能是信息泄漏导致过拟合练习探针，部分原因是缺少干净的审计轨迹。
内部部署：七个场景平均 +18.8 点
公开基准之外，团队把 SkillHone 接到微信内部反复出现的工具驱动分析场景——计数、聚合、结构解析、密度估计、跨度检索、过滤排序、列表过滤等，每个场景有固定精确匹配评测集。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
七个场景平均 +18.8 点。增益最大的几类，共同点是种子 Skill 里可复用的分析步骤描述不足——SkillHone 通过多轮诊断和修订，把这些步骤写清楚、写稳定。
列表过滤持平，说明不是所有 Skill 都有大幅优化空间；论文没有回避这个零增益案例。
内部场景和公开基准的互补关系
公开基准测的是裸网 Deep Research ；内部七个场景测的是 工具驱动分析——Agent 调用内部工具做计数、聚合、结构解析等，失败模式更结构化（字段类型错、聚合维度漏、跨度边界偏一位等）。计数 +30.0 、聚合 +26.3 这类大跃升，通常对应种子 Skill 里步骤顺序和异常分支没写全， SkillHone 几轮 Issue/PR 后把流程补完整。
过滤排序只 +5.9 ，列表过滤 +0.0 ，暗示这类 Skill 的种子版本已经较成熟，或精确匹配评测对流程微调不敏感。读部署表要和公开基准对照：SkillHone 的价值不只在一个排行榜上刷分，而在反复出现的工作流里持续降维护成本。
和现有工作的关系
Prompt/系统优化： DSPy 把语言模型流水线编译成可优化程序； Reflexion 用文字反馈跨尝试改进； GEPA 对语言系统组件做反射式进化； Hermes-SE 把这套方法扩展到 Skill/Prompt/工具/代码。共同局限是 单轮标量信号——每次尝试常从零开始。 SkillHone 走不同轴：局部回滚 + 持久 ，后续 Agent 从上一轮停下的地方继续。
Skill 获取与评测： SkillsBench 测 Skill 在多样任务上的效用； SWE-Skills-Bench 问真实软件工程里 Skill 是否有帮助； Skill-R1 、 SkillForge 探索强化学习/领域自动构建。这些回答”怎么得到 Skill”； SkillHone 回答”怎么让 Skill 活下去”。
多 Agent 协作： MetaGPT 用标准流程组织角色产出软件式产物； SWE-Agent 用 Agent-Computer Interface 做 issue 修复。 SkillHone 借鉴角色分离，但产出是 可审计的进化历史，而不只是单次 PR 合并。
三条路线的本质差异
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Skill-Creator 在 WebWalkerQA 上甚至低于 Existing-Skills （ 40.8% vs 48.5%），说明盲目迭代可能破坏已有社区 Skill 的互补结构。 Hermes-SE 强于 Skill-Creator ，但在 GAIA L2 上仍差 SkillHone 25.8 点——反射式进化缺历史时，难例上的流程组织仍是短板。
局限与我的判断
论文坦诚了当前边界：
论文还提到：多个相互依赖 Skill 的联合进化 是未来方向——现实里 Deep Research Skill 往往和解析 Skill 、验证 Skill 耦合，单 Skill 隔离进化是简化假设。
另一个未充分展开的问题是 决策历史的压缩与检索：当 增长到数百条记录，后续调度如何高效检索相关历史？论文用失败维基和 Issue 链做初步索引，但大规模生产可能需要向量检索或层次化摘要——这是开放的工程问题。
结论要点
论文结论强调四点：角色隔离的子 Agent 、脱敏练习反馈、持久历史串联问题/修订/证据/结果； GAIA/WebWalkerQA 超基线和商用 Agent ；内部 7 场景 +18.8 百分点； Skill 包跨骨干模型迁移无需重新优化。局限明确 目前一次只进化一个 Skill。
用工程语言说：SkillHone 证明”会记笔记的 Skill 优化器”在公开基准和内部工作流上都比”只交最终稿的优化器”更耐用。 笔记的内容就是 ；笔记的载体就是 Issue/PR/History 。
三条贡献，对应三个读者问题
问：现有 Skill 优化缺什么？
答：缺持久决策历史——后续 Agent 需要知道历史修订的依据、被拒绝的备选方案和评估证据，而不只是最新产物。
问： SkillHone 怎么补？
答：面向 Agent 的通用框架，角色隔离子 Agent + 脱敏练习反馈 + 结构化记录 。
问：有没有硬证据？
答： GAIA/WebWalkerQA 上超商用 Deep Research Agent 和先前方法； Skill 包跨 Claude Sonnet 4.6 迁移仍领先；内部 7 场景平均 +18.8 百分点。
谁应该关注这篇工作
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
对 Agent 工程师的三条实操建议
第一，给 Skill 维护建评估仓库，不要只写 README 。 至少准备一小套练习探针和验证器，每次改 Skill 先跑验证集内评测，再合并。 SkillHone 的 Skill-Eval 仓库就是这个思想的系统化。
第二， commit message 级不够，要 Issue 级诊断链。 记录”失败现象 → 假设原因 → 尝试修订 → 证据 → 决策”，下次会话先读历史再动手。 Table 4 的五轮 PR 就是模板。
第三，权限隔离要当真。 写 Skill 的 Agent 和跑探针的 Agent 分开，报告必须脱敏。否则练习集上的分数会骗人——Agent 背答案，流程没学到。
和 Claude Code / Codex Skills 用户的关系
如果你已经在 Claude Code 或 Codex 里积累十几个 Skill ， SkillHone 提供的是 Skill 之上的元框架：帮你管理”改 Skill 这件事本身”。
具体映射：
SKILL.md ↔ Skill 仓库里的主产物你不必立刻 fork 整个 SkillHone 代码库；可以先在现有工作流里手动维护一个 EVOLUTION.md，按 四元组记录每轮改动——这就是决策历史的最小可行版本。 SkillHone 的价值在于把这套规范系统化、角色隔离、可扩展。
从工程视角看， SkillHone 把基准分数之外的价值写在了架构里：Agent Skill 维护从”改文件”升级成”带审计日志的进化过程”。 Claude Code Skills 、 Codex Skills 的用户一旦 Skill 超过三个、维护周期超过两周，就会碰到上下文丢失问题——SkillHone 的 GitHub 式 Issue/PR/History 模式，比再训一个更大的模型更贴近实际运维。
Deep Research 场景里 15.8 点的 GAIA 领先也传递了一个信号：在开放网页上，流程化 Skill + 持续进化，可以补平甚至超过商业检索栈的信息组织优势——前提是你要愿意维护决策历史，定期跑诊断—修订—评估循环，而不是偶尔让模型重写一遍 SKILL.md。
如果你已经在用 Agent Skills ，建议先看 GitHub 仓库里的 Skill-Eval 仓库结构和调度权限表，对照自己的 Skill 维护流程：你的”第 N 轮优化”是否还在重复第 1 轮试过的失败补丁？如果是， SkillHone 要解决的问题，可能就是你明天的工程债。
一句话收束：Agent 时代的竞争力，越来越取决于能否把 Skill 进化过程变成可继承、可审计、可续跑的知识资产。 SkillHone 给出了第一版系统答案；开源仓库已经在那，值得克隆一份按自己的评估仓库试跑。
