SkillHone: A Harness for Continual Agent Skill Evolution Through Persistent Decision History

关联论文：2606.08671
作者：Tom
更新：2026-07-22

一句话结论

SkillHone 通过持久化 Agent 决策历史，将 skill 进化从"单次优化"升级为"跨会话积累"，无需预置搜索栈即可在 GAIA 基准上领先商业 Deep Research Agent 15.8 分，并实现平均 18.8 分的内部工具分析场景提升。

解决什么真问题

大模型 Agent 的 skill（任务特定程序、脚本、参考资料与输出约定的可复用包）是 Agent 系统的核心资产。现有 skill 改进方法存在一个根本性缺陷：只保留最终 artifact（最终版本的 skill），丢弃决策历史。

这导致三个具体问题：

跨会话无法理解 prior：后来的 agent 看到的是一个冷冰冰的"新版 skill"，不知道这个版本为什么比旧版好、哪些尝试被拒绝了、拒绝的理由是什么。
bounded run 限制：skill 在单次运行中完成优化后直接固化，agent 下次启动时从头来过——没有从历史中学习。
搜索栈依赖：商业 Deep Research Agent 依赖预置的搜索工具栈，skill 进化方法通常也假设这些工具已集成，导致泛化受限。

SkillHone 的核心问题是：如何设计一个 harness（支架），让 agent 的 skill 能够跨会话持续进化，同时保留决策历史以供后续 agent 理解和借鉴？

核心方法

Persistent Decision History

SkillHone 的核心创新是将决策历史本身作为一等公民。每一次 skill 修订都产生一个结构化记录，包含：

DecisionHistory {
  diagnosis:      // 对当前 skill 不足之处的诊断
  revision:       // 本次修订的内容
  evidence:       // 支持修订的实践反馈（evaluation-side）
  outcome:        // 修订后的效果
  prior_decisions:[DecisionHistory]  // 引用历史决策
}

这相当于为每个 skill 版本建立了一份"进化论"——不只是记录"是什么变了"，还记录了"为什么变"和"之前的尝试为什么被放弃"。

Role-Separated Subagents

SkillHone 运行两个角色分离的 subagent：

┌─────────────────────────────────────────────────────┐
│                   SkillHone Harness                  │
│                                                      │
│  ┌──────────────┐   redacted probes   ┌───────────┐ │
│  │ Skill Agent  │ ──────────────────→ │ Eval Agent│ │
│  │ (revision)   │ ←────── evidence ─── │(evaluation)│ │
│  └──────┬───────┘                      └───────────┘ │
│         │                                        ▲  │
│         │ skill + history                        │  │
│         └────────────────────────────────────────┘  │
│              persistent decision history store      │
└─────────────────────────────────────────────────────┘

Skill Agent：读取 skill 的当前版本 + 决策历史，生成候选修订（candidate revision）。它在一个脱敏报告（redacted reporting）环境下工作——只能看到 probe 本身，看不到 probe 的标准答案或 benchmark 来源，防止过度拟合 benchmark。
Eval Agent：对 Skill Agent 提交的候选 skill 运行实践探针（practice probes），收集 evidence 并评分，然后将 evidence 返回给 Skill Agent，指导下一轮修订。

与 prior decisions 的链接

关键设计：Skill Agent 的每次修订都引用历史决策，而不是重新发明轮子。如果某个方向在历史中已被判定为无效，Skill Agent 会被引导（通过决策历史的 structure）避免重复尝试，从而实现跨会话的效率提升。

无需预置搜索栈

SkillHone 的设计目标是不依赖预集成的搜索栈。skill 本身是 agent 可以调用的一等工具包，skill 进化过程不需要假设某个商业 search API 已经可用。这与 OpenAI Deep Research Agent（依赖内置搜索栈）形成鲜明对比。

Benchmark 泄露防护

Eval Agent 看到的 probe 是经过脱敏处理的——移除或打码 benchmark 来源、答案等元信息，防止 Skill Agent 直接记住答案而非真正学习 skill。这保证了评估的真实性。

关键实验与数据

外部基准

基准	商业 Deep Research Agent	SkillHone（无搜索栈）	提升
GAIA	基准（原文未给出具体数字）	+15.8 分	+15.8
WebWalkerQA-EN	基准	+3.2 分	+3.2

GAIA：General AI Assistants benchmark，测试多步骤真实世界任务推理。
WebWalkerQA-EN：网站导航问答基准，评估 agent 在真实网站上的信息检索与推理能力。
SkillHone 超越的是" commercially backed deep-research agent"，后者很可能是有商业搜索 API 加持的系统，但 SkillHone 无需这些。

内部工具中介分析场景

场景数量	平均准确率提升
7 个内部工具分析设置	+18.8 分

这些场景是 practioner 的真实用例，涉及多工具协调、长程推理和结构化输出。

与 prior skill-evolution 方法的比较

原文未列出具体对比数字，但明确指出 SkillHone "exceeds prior skill-evolution methods"。

亮点与局限

亮点

Persistent Decision History 作为 first-class artifact：不只是保存最终 skill，而是保存完整的进化过程——这是从机器学习模型的"模型快照"到"训练过程记录"的范式升级，在 Agent 领域很少见到。
Role-separated 防止信息泄露：Skill Agent 与 Eval Agent 分离 + redacted reporting，从机制上防止 benchmark 记忆而非真实学习。
无需预置搜索栈：skill 进化完全自包含，降低了部署门槛，也更能泛化到真实企业内部场景（没有现成商业 API 的环境）。
跨会话效率：历史决策引用避免了重复尝试，在概念上类似人类研究者的"文献综述"——不做重复工作。
工程可复现：以 harness 为框架，有明确的接口和角色分离工程实现路径清晰。

局限

Skill 版本管理的复杂度：随着决策历史增长，如何高效检索和引用历史中的相关决策（而非被历史淹没）是一个工程挑战，原文未讨论。
Eval Agent 的质量决定上限：如果实践探针（practice probes）本身不够多样或代表性不足，skill 的进化方向可能偏航。
Skill 与 LLM backbone 的耦合：不同 LLM 的 skill 可能不兼容，SkillHone 未系统讨论跨 backbone 迁移（尽管 YouTube 摘要提到"skills transfer across different LLM backbones without retraining"，原文细节待验证）。
冷启动问题：初始 skill 从何而来，harness 的初始化策略未明确讨论。
决策历史的存储成本：随着组织内 skill 数量增长，决策历史的存储和检索成本可能成为瓶颈。

对工程落地的启发

企业级 Agent 运营：企业内部有大量专有工具和流程，SkillHone 提供了一种让 agent 的"最佳实践"随时间积累的框架，而不是每次都从零开始。
Benchmark 过拟合防护：对于需要持续进化的生产 Agent，role-separated eval + redacted reporting 是防止 agent"背答案"而非"学技能"的有效机制。
Skill as a Service：SkillHone 的 skill 可以看作是可版本化、可演进的 API——企业内部可以建立 skill 库，实现跨团队的 skill 复用。
Deep Research 的民主化：无需商业搜索 API 就能超越商业 Deep Research Agent，对无法依赖外部 API 的合规行业（金融、医疗、政府）有特殊价值。
持续评估驱动进化：将评估反馈（evidence）作为 skill 进化的驱动力，比人工 review 更系统、更可量化。

与同方向工作的关系

Agent Skill 进化：与 Xu & Yan 2026、Ling et al. 2026（paper card 中引用）等工作同代，但这些工作只保留最终 artifact，SkillHone 在此基础上加了 history。
Deep Research Agent：OpenAI Deep Research Agent 是"商业闭源"路线的代表；SkillHone 在无预置搜索栈的情况下超越它，代表了一条更开放、更可定制的路线。
Reflexion / Self-Refine：这些方法通过 agent 自我反思改进输出，但没有持久化决策历史——SkillHone 可以视为 Reflexion 的持久化、工程化扩展。
RAG for Agent：SkillHone 的决策历史存储可以被视为一种 specialized RAG——检索的不是文档，而是历史上做过的决策和 evals，维度不同但思想相通。
GAIA / WebWalkerQA：这些基准测试的崛起催生了 SkillHone 这类"系统性提升 agent 在 benchmark 上表现"的工作。

适合谁读

Agent 系统工程师：负责设计和维护企业内部 agent 技能系统的实践者，想了解如何让 agent skill 持续进化而不退化。
AI Agent 研究者：关注 skill 进化、长期记忆、跨会话学习的学术研究者。
Deep Research 应用开发者：希望不依赖商业 API 构建 deep research 能力的团队。
对 Agent 评估（eval）有经验的读者——SkillHone 的 role-separated eval 设计对理解 agent eval 最佳实践有直接价值。

不确定处（原文未明确）： - Skill Agent 和 Eval Agent 各自使用的 LLM backbone（是否相同？） - Practice probes 的规模和来源（是人工构造还是自动生成？） - 初始 skill 的来源（冷启动策略） - Decision history 存储和检索的具体实现（向量检索？结构化 DB？） - GAIA 和 WebWalkerQA 的具体基准分数（只给了相对提升） - Skill 跨 LLM backbone 迁移的具体机制和限制

工程落地与核查（Jay）

实际系统怎么用

Decision History Store 的工程选型

Decision History 的核心数据结构是带 prior_decisions 引用的有向无环图（DAG），而非简单的时间序列文档。建议：

存储层：用图数据库（Neo4j、Age）存储 DecisionHistory 节点 + prior_decisions 边，能天然支持"引用链回溯"和"被引用次数"统计；简单场景可用 PostgreSQL jsonb + 递归 CTE 模拟。
检索策略：当 Skill Agent 生成候选修订时，需要检索"历史上哪个决策最相关"——建议用向量检索（embedding of diagnosis + revision）做粗排，再用 prior_decisions 引用关系做精排。
Schema 示例： DecisionHistory { id: UUID, skill_id: UUID, diagnosis: text, // 诊断：当前版本的不足 revision: text, // 修订内容 evidence: JSON, // Eval Agent 返回的评分细节 outcome: float, // 修订后的效果分数 prior_decisions: [UUID], // 引用历史决策的 ID 列表 created_at: timestamp }

Skill Agent 的脱敏报告环境

redacted reporting 的实现要点： - 在 Eval Agent 返回 evidence 时，过滤掉所有 benchmark 来源标识（GAIA、WebWalkerQA 等字符串替换为空）、答案字符串、评分标准； - Skill Agent 的运行环境应该是只读 skill history + 只读 probe，不允许访问 benchmark 原始数据； - 防止"训练数据泄露"而非"推理时泄露"——Skill Agent 看到 probe 题目可以，但看不到标准答案和来源。

⚠️ 存疑：脱敏的具体实现方式（正则替换 / LLM 重写 / 结构化遮蔽）原文未描述，接入时需要和论文团队确认实现细节，否则可能存在遮蔽不完整导致的信息泄露。

Practice Probes 的构造

Practice probes 是驱动 skill 进化的核心输入。生产级系统建议： - probes 必须来自真实用户失败案例，而非人工构造，否则 skill 进化方向可能偏离实际使用场景； - 建议构建 probe 池（probe pool），每次 skill 修订时随机抽取子集，防止对特定 probe 过拟合； - probe 的多样性（工具类型 × 任务复杂度 × 错误模式）需要覆盖均衡，否则 skill 会在某类任务上退化。

主要坑点

Decision History 检索的精确性：当 decision 数量增长到数百条时，如何找到"最相关的 prior decision"而不是被淹没？原文未给出检索算法细节。生产环境建议：先用向量相似度 top-K，再用 prior_decisions 引用频次做加权排序，优先推荐被多次引用证明有效的决策方向。
Eval Agent 的 probe 质量是单点风险：如果 practice probes 本身有偏（只覆盖某类工具、只覆盖简单任务），skill 进化方向会系统性偏航。建议： - 设置 probe 多样性监控（每轮修订后 probe 池的覆盖率统计）； - 定期引入人工构造的对抗 probe，防止 Skill Agent 在 probe 池上过拟合。
Skill 与 LLM backbone 的耦合：SkillHone 的 skill 是用特定 LLM 生成和评估的，迁移到另一个 backbone 时： - diagnosis 和 revision 的语义可能不通用（不同 LLM 对"什么是好的 skill"判断不同）； - practice probes 的难度基准也可能漂移。 ⚠️ 存疑：YouTube 摘要提到"skills transfer across different LLM backbones without retraining"，但原文未给具体机制。不要在没有正文验证的情况下直接相信这个说法。
冷启动问题无解：初始 skill 从哪来、第一条 DecisionHistory 怎么生成，原文未讨论。生产环境建议： - 用 few-shot prompt + 人工审校生成初始 skill； - 或者用已有高质量 skill 作为 seed，手动写入第一条 DecisionHistory。
成本估算：SkillHone 每次修订需要 Skill Agent 生成 + Eval Agent 运行 probes： - Skill Agent 调用次数 ≈ 修订轮次 × 单次调用成本； - Eval Agent 调用次数 ≈ 修订轮次 × probe 池大小 × 每 probe 调用成本； - 7 个内部工具场景 +18.8 分意味着平均每个场景需要多轮修订，成本不可忽略。建议在生产部署前做成本-收益分析：提升 18.8 分能带来多少业务价值，是否值得持续跑 SkillHone 迭代。
Benchmark 对齐而非真实能力对齐：SkillHone 的 eval 框架基于 GAIA / WebWalkerQA，这些 benchmark 可能和你的真实任务分布差异很大。生产环境必须用真实任务 probes，而不是直接拿 GAIA 题目做评估。

核查小结

核查项	状态	备注
论文 ID 与文件名一致	✅	2606.08671
GAIA +15.8 / WebWalkerQA +3.2 分	✅ 摘要陈述	商业 baseline 具体数字未给出
内部工具场景 +18.8 分	✅ 摘要陈述	7 个场景，平均提升
"exceeds prior skill-evolution methods"	⚠️ 存疑	原文无具体数字
Skill Agent / Eval Agent backbone 是否相同	⚠️ 存疑	原文未明确
Practice probes 来源和规模	⚠️ 存疑	摘要未细节化
Decision history 存储实现	⚠️ 存疑	原文未给出
"skills transfer across LLMs without retraining"	⚠️ 待验	YouTube 摘要说法，原文机制不明
Redacted reporting 具体实现	⚠️ 存疑	原文未描述
冷启动策略	❌ 缺失	原文未讨论
GAIA/WebWalkerQA 原始基准分	❌ 缺失	只给相对提升