SkillHone:通过持久化决策历史实现持续代理技能进化的框架 SkillHone: A Harness for Continual Agent Skill Evolution Through Persistent Decision History
通过持久化决策历史和角色分离的子代理机制,实现AI Agent技能的持续改进与跨会话维护
前置知识
Agent Skills
Agent技能是一种可加载的软件包,包含特定任务类的指令、程序、脚本、引用和输出约定,类似于传统软件中的函数或模块,但针对LLM代理进行了优化。Agent可以按需调用这些技能来完成特定类型的工作,比如搜索技能、代码审查技能、数据分析技能等。技能的优势在于可以复用、共享和持续改进,是扩展LLM代理能力的关键机制。
读懂本文需要理解技能作为可复用能力的概念,以及技能在部署的代理系统(如Claude Code、Codex、Hermes)中的核心地位
Persistent Decision History
持久化决策历史是指将技能开发过程中的每一步决策都记录下来,包括诊断问题qt、候选修订rt、评估证据et和结果ot。与版本控制系统只记录代码变更不同,决策历史还记录了为什么做出这个修改、使用了什么证据、考虑了哪些替代方案、为什么接受或拒绝。这使得后续的代理可以追溯每个修改的动机,避免重复失败的尝试,或在环境变化时做出更合理的调整。
这是本文的核心创新点,理解它有助于区分本文与现有技能改进方法的本质差异
Role-Bounded Subagents
角色分离的子代理机制是指将开发任务分配给具有不同权限范围的子代理。优化团队(Optimization Agent Team)包括Diagnoser、Explorer、Proposer、Reviewer和Decider,负责修改技能;评估团队(Evaluation Agent Team)包括Executor、Diagnoser、Reporter和Auditor,负责测试技能。关键是权限边界:优化团队只能访问脱敏的评估报告,不能看到probe目标、验证器或执行轨迹;评估团队可以检查这些敏感信息,但不能修改技能。这种分离防止了评估信息直接成为记忆目标。
理解这个机制有助于解释SkillHone如何在保持评估信息完整性的同时,为优化提供有意义的反馈
研究动机
现有的Agent技能改进方法(如Skill-Creator和Hermes-SE)存在一个根本性问题:它们将技能改进视为产生更好产物的过程,只保留最终的技能文件,却丢失了决策上下文。当环境变化时,后续的代理继承了最新的技能,但无法理解之前的修改动机——不知道哪个诊断触发了修订、考虑了哪些替代方案、观察到了什么评估证据、为什么接受某个结果。这个问题同样适用于评估证据:当后来的代理依赖probe、验证器、追踪或脱敏报告时,它们也需要知道这些证据反映了什么失败模式、如何塑造了之前的决策。论文用Figure 1生动地展示了这个问题:在API变更、限流、页面格式变化的情况下,没有决策历史的新代理可能会重复之前已经成功的修复(但已不适用于当前失败模式),或者使后续优化变得更困难。
本文的目标是本文的目标是设计一个面向代理的框架(harness),用于持续进化和维护Agent技能,使得技能不仅包含最终的执行逻辑,还保留了支持其改进的评估资产,并将技能修订和评估证据都视为决策单元。具体来说,框架需要能够记录诊断、修订、证据和结果之间的链接关系,使得后续代理能够在不重新推导先前决策的情况下继续改进技能。同时,框架应该保持优化端和评估端的结构性分离,防止评估信息直接成为记忆目标。
与已有工作不同的是,本文的独特切入点在于从"制品为中心"转向"决策为中心"的技能改进范式。现有方法(合成式构造和反思式优化)都关注于在单个优化运行内产生更好的技能,将输出视为改进的结果。而SkillHone关注的是技能的长期生命周期维护,将技能改进过程中的每一步决策都记录下来,形成持久化的决策历史Ht = {h1, ..., ht},其中每个ht = (qt, rt, et, ot)包含了诊断、修订、证据和结果的完整上下文。这使得后续代理能够在环境变化时恢复为什么做出每个修改,避免重新引入过时的修复。这个gap在之前的工作中没有被充分认识,因为大多数研究关注的是单次技能创建或改进,而不是跨多个开发会话的持续维护。
核心方法
SkillHone的整体思路是构建一个双仓库系统,通过角色分离的子代理和持久化决策历史来实现技能的持续进化。技能仓库存储正在修订的技能包(SKILL.md、脚本、引用、模板等),技能评估仓库存储评估资产(probe、oracle目标、验证器、追踪、脱敏报告等)。在每次开发步骤中,运行时调度器动态创建角色受限的子代理:优化团队维护技能仓库并提出基于诊断的修订,评估团队运行候选技能并导出脱敏问题报告。这两团队通过权限边界进行分离——优化团队不能访问未脱敏的probe目标、验证器或追踪,评估团队不能写入技能仓库。路由的证据、仓库操作和记录的结果形成了持久化的决策历史,后续代理可以复用这些历史进行持续的技能进化。这个框架的形式化定义为M = (Topt, Teval, D),其中Topt是优化代理团队,Teval是评估代理团队,D是运行时调度器。
SkillHone的核心创新点在于将"技能修订"和"评估证据"都视为决策单元,并通过持久化的决策历史将它们链接起来。这与现有方法的本质区别在于:现有方法在标量信号上优化,接受或拒绝整个候选技能,而SkillHone记录每个修改的完整上下文——包括它解决了什么问题、使用了什么证据、考虑了哪些替代方案。Figure 4通过优化轨迹生动地展示了这个区别:当SkillHone的某个修改导致性能回退时(例如第4次的更严格预算),后续迭代可以针对性地回退那个特定部分,同时保留有用的编辑。而Hermes-SE优化单个SKILL.md正文,在标量验证信号下接受或拒绝整个候选。另一个核心创新是角色分离的架构,这使优化与评估成为结构性的分离,而不仅仅是提示词层面的约束。Table 5详细列出了各角色的权限边界,这确保了实践反馈不会直接成为记忆目标。
方法步骤详情
SkillHone的完整工作流程如Algorithm 1所示。首先初始化决策历史H0为空集。对于t = 0到T-1的每次迭代,评估调度器运行当前技能St在评估仓库Re上,导出脱敏证据Et。优化调度器检索历史Ht,然后提出诊断qt和候选修订rt。评估调度器返回rt的脱敏证据et。系统根据可用证据做出决策ot,可以是ACCEPT(接受)、REVISE(要求进一步修改)、REJECT(拒绝)或DEFER(推迟诊断)。如果接受修订,则St+1 = APPLY(St, rt),否则St+1 = St。最后更新决策历史Ht+1 = Ht ∪ {(qt, rt, et, ot)}。这个循环持续进行直到达到T次迭代或满足停止条件。最终返回进化后的技能ST和完整的决策历史HT。在实际实现中(如附录B所述),SkillHone通过GitHub风格的仓库工作流来实现持久化决策历史:Issues记录诊断的失败模式,Pull Requests包含提议的技能修订,合并或拒绝决策记录接受的结果。
技术新颖性
SkillHone的技术新颖性体现在多个方面。首先,它引入了"决策历史"的概念,将技能改进从版本控制(只记录代码变更)扩展到决策审计(记录为什么变更、基于什么证据、考虑了什么替代)。这在持续维护场景中具有重要价值,因为API限流、变更和废弃会随时间到来,后续的优化步骤可能重复之前已经成功的修复(但不再匹配当前的失败模式)。其次,SkillHone的角色分离架构使优化与评估成为结构性分离,这比提示词层面的分离更可靠,因为子代理是在运行时动态创建的,并授予特定权限的调度。第三,SkillHone在"原始开放网络"设置下工作,没有预集成的搜索堆栈,这更接近真实部署场景。表4展示了一个完整的仓库工作流示例,说明SkillHone优化整个技能包(包括指令、脚本和引用),而不仅仅是重写单个SKILL.md正文。最后,技能包可以跨不同的执行骨干(从Qwen3.6-35B-A3B到Claude Sonnet 4.6)迁移而无需额外优化,这表明增益来自技能过程而非拟合特定模型。
实验结果
论文在两个深度研究基准上进行了广泛评估。在GAIA基准上,SkillHone在原始开放网络设置下达到64.6%的平均准确率,比深度研究代理(使用商业检索服务)高出15.8个百分点,比共享池技能开发基线高14.2-20.5个百分点。在WebWalkerQA-EN上,SkillHone达到66.4%的平均准确率,比深度研究代理高3.2个百分点,比基线高13.4-28.3个百分点。增益集中在更难的分割上(GAIA的L2/L3和WebWalkerQA-EN的Medium/Hard),这些分割要求决定如何搜索、提取证据、验证发现和从失败路径中恢复。跨骨干迁移实验表明,将技能包直接在Claude Sonnet 4.6上运行(无需额外优化)可达到72.4%的GAIA准确率,比Hermes-SE/Existing-Skills/Skill-Creator分别高出10.2/15.7/24.4个百分点。消融研究显示,决策历史占性能增益的较大份额:移除它会使GAIA/WebWalkerQA-EN下降13.4/10.9个百分点,而移除角色分离则下降6.4/5.3个百分点。部署研究在七个内部工具介导分析场景中,SkillHone改进了六个技能,平均提升18.8个百分点,最大增益出现在计数、聚合、结构解析和跨度检索上。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| GAIA (General AI Assistant benchmark) | Average accuracy across L1/L2/L3 levels | 64.6% (raw open-web), 72.4% (transfer to Claude Sonnet 4.6) | 48.8% (deep-research agent with curated search), 50.4% (Hermes-SE), 44.1% (Skill-Creator), 41.7% (Existing-Skills) | +15.8pp vs deep-research, +14.2pp vs Hermes-SE, +20.5pp vs Skill-Creator, +22.9pp vs Existing-Skills |
| WebWalkerQA-EN (web navigation and information extraction) | Average accuracy across Easy/Medium/Hard levels | 66.4% | 63.2% (deep-research agent), 53.0% (Hermes-SE), 38.1% (Skill-Creator), 50.2% (Existing-Skills) | +3.2pp vs deep-research, +13.4pp vs Hermes-SE, +28.3pp vs Skill-Creator, +16.2pp vs Existing-Skills |
| Internal deployment (7 recurring scenarios) | Accuracy improvement (pp) | +18.8 average | Seeded skills (0pp baseline) | +30.0 (Counting), +26.3 (Aggregation), +25.0 (Structure parsing), +23.1 (Density estimation), +21.5 (Span retrieval), +5.9 (Filtered ranking), +0.0 (List filtering) |
局限与改进
作者承认SkillHone当前只能独立进化单个技能,没有处理多个相互依赖技能的联合进化,包括跨共享资源的协调和重叠失败模式。此外,论文主要在深度研究任务上进行了评估,虽然也有内部部署研究,但场景仍然相对有限。我的观察是:首先,决策历史的维护可能会带来存储和检索开销,随着技能复杂度增加和迭代次数增多,历史记录会变得庞大,需要高效的索引和检索机制。其次,角色分离的架构虽然减少了信息泄露,但也可能限制了优化端对评估细节的理解,在某些情况下可能导致不够精确的修订建议。第三,论文假设了一个可以启动权限受限调度的代理运行时,这可能不是所有代理框架都支持的原语。最后,评估中使用了固定的开发时间骨干(Claude Opus 4.6)和执行时间骨干(Qwen3.6-35B-A3B),这表明性能可能对模型选择敏感。
独立分析的弱点
第一个弱点是决策历史的检索效率问题。当历史记录Ht包含大量决策记录时,后续代理如何高效地检索相关的先前记录?论文提到"从H<t中检索相关的先前记录",但没有详细说明检索机制和可能的幻觉风险。改进方向可以包括:引入语义检索机制,为每个决策记录嵌入向量,并基于当前诊断查询相关历史;或者使用层级索引,按失败模式、修订类型、时间戳等维度组织决策历史。第二个弱点是技能修订的粒度控制。虽然Figure 4显示SkillHone可以针对性回退特定修改,但如何确定修订粒度?太粗的修订可能引入不必要的副作用,太细的修订可能导致修改过小而难以产生显著改进。改进方向可以是:引入修订粒度的自动评估机制,或让Decider角色显式指定修订粒度。第三个弱点是跨技能依赖的处理。当前框架假设技能独立,但实际中技能可能共享组件、相互调用或形成层级结构。改进方向可以是:扩展框架支持技能依赖图,让决策历史跨技能链接,或引入联合优化策略。
未来方向
作者提出的未来工作方向是联合进化多个相互依赖的技能,包括协调跨共享资源和重叠失败模式。基于论文成果,可以延伸多个方向:首先是技能演化策略的自动化,当前框架假设代理可以基于历史做出合理决策,但如何学习更好的演化策略?可以引入强化学习或元学习框架,让系统从成功和失败的演化案例中学习。其次是决策历史的压缩和抽象,随着时间推移,决策历史会变得庞大,如何保留最重要的决策信息、抽象演化模式、遗忘不再相关的历史细节?可以引入重要性评分、模式提取、历史压缩等技术。第三是跨领域技能迁移,论文展示了跨骨干迁移,但能否跨任务领域迁移?例如将深度研究技能迁移到代码审查、数据分析等领域。可以研究领域无关的技能演化机制。最后是技能冲突检测和解决,当多个技能被同时激活时可能出现冲突,需要检测和解决机制。
复现评估
论文的开源情况在技能库层面提供了参考,https://github.com/Tencent/SkillHone链接指向技能库,项目页面https://zwlijay.github.io/SkillHone-Project提供额外信息。然而,论文没有明确说明完整的代码库、数据集和实验设置是否开源。从算力需求来看,实验使用了两个大模型:Claude Opus 4.6作为开发时间控制器,Qwen3.6-35B-A3B作为执行和评估骨干,这需要相当的计算资源。基准测试使用GAIA的验证子集和WebWalkerQA-EN的英文分割,以及从WebShaper数据集采样的20个项目作为开发数据。复现难度中等偏高:一方面,框架的核心思想相对清晰,可以用其他代理运行时实现;另一方面,需要设置两个仓库系统、实现角色分离的调度、配置probe和验证器,这些都需要相当的工作量。论文的附录提供了仓库工作流示例和子代理调度模式,这些信息有助于复现。
论文图表
这张图展示了一个两阶段的技能进化场景。左侧显示了"第1轮",一个代理发现DuckDuckGo搜索失败,提出修复(添加错误处理),接受修订。右侧显示了"第N轮",DuckDuckGo搜索再次失败,但新的代理不知道第1轮已经尝试过这个修复(虽然可能已不再适用),可能会重复这个优化或使未来改进更困难。图中用"×"标记了丢失的上下文信息:诊断、证据、替代方案、结果。图中还列出了环境变化:API限流、API变更、废弃。
这张图对理解论文至关重要,因为它直观地展示了论文要解决的核心问题——为什么制品中心的技能改进会丢失决策上下文,以及为什么这对持续维护是致命的。它为后续的方法动机和设计决策提供了直观的基础。