你的 AI Agent 每次改技能都从零开始——腾讯让它记住了所有被否掉的方案

你花一个下午调教出一个完美的 Agent 技能。两天后环境变了，技能不 work 了，你让 Agent 自己改。

它改了。但你发现它把三天前已经否掉的方案又试了一遍。

这不是 Agent 不够聪明——是它根本不知道自己否过什么。现有的技能演进方法只保留最终版本，所有诊断、尝试、被否方案、评估证据全部丢弃。下一个来接手的 Agent 看到的只是一份"成品"，不知道这份成品经历了什么。

相当于每个新医生只看处方，不看病历。

腾讯的 SkillHone 就是来补这个病历的。它给 Agent 技能演进加上了持久决策历史——每一次诊断、每一次修订、每一条被否掉的证据、每一个接受/拒绝的结果，全部记录在案。论文在 GAIA 基准上比商业深度研究 Agent 高出 15.8 个百分点。

问题：技能演进为什么需要记忆

先理清现状。Agent 技能（Skill）是扩展 LLM Agent 功能的核心机制——一个命名好的、可加载的任务程序包，包含 SKILL.md 指令、scripts 脚本、references 参考文档。当任务或环境变化时，技能需要迭代改进。

现有的演进方法（如 SkillOpt、Hermes Self-Evolution）把技能改进当作一次性运行：跑一遍优化 → 保留最终 SKILL.md → 丢弃中间过程。

问题来了：

• 重复旧修复：Agent 不知道某个方案已经被尝试并否决，可能再次提出
• 撤销有益更改：Agent 不知道某次更改是有意为之，可能在新一轮优化中覆盖掉
• 反馈失据：Agent 看到评估结果，但不知道上一次面对同样问题时的决策逻辑

SkillHone 的核心洞察：技能演进需要的不仅是"改了什么"，更是"为什么这样改、还试过什么、为什么被否了"。

架构：病历本 + 双团队 + 权限墙

SkillHone 的系统形式化为 M = (T_opt, T_eval, D)，三个组件：

1. 持久决策历史（病历本）

每一步开发被表示为一条决策记录：

h_t = (q_t, r_t, e_t, o_t)

q_t = 诊断（这次出了什么问题）
r_t = 候选修订（打算怎么改）
e_t = 经过编辑的评估证据（改了之后怎么样）
o_t = 结果（ACCEPT / REVISE / REJECT / DEFER）

到第 t 次迭代，决策历史为 H_t = {h_1, ..., h_t}。这不是一个 diff——它把更改与目标问题、评估证据、最终决策关联起来。后续 Agent 可以检查 H_t 来判断：这个失败是不是新的？类似的修复之前试过没？为什么上次的方案被拒绝了？

2. 双向仓库（技能库 + 评估库）

两个仓库物理隔离。优化团队看不到未编辑的探测目标和验证器——防止"偷答案"。评估团队不能写技能仓库——防止"既当裁判又当运动员"。

3. 权限隔离子 Agent（双团队）

• 优化子 Agent 团队 T_opt：检查当前技能、读取决策历史和失败摘要、形成诊断、提出修订、审查候选更改、记录接受结果。无法访问未编辑的探测目标、验证器或执行追踪。
• 评估子 Agent 团队 T_eval：检查参考目标和追踪、运行当前技能、分析失败、生成编辑后报告。无法写入技能仓库。
• 运行时调度器 D：消息路由器而非决策机构——观察公共状态、派遣子 Agent、路由编辑后证据和审查请求、记录结果。

权限隔离不是靠 prompt 约定，而是靠代码路径和文件系统权限强制执行。这意味着即使 Agent 想"偷看"评估数据，也做不到。

Whole-Skill 优化：改的不只是 SKILL.md

这是 SkillHone 和 SkillOpt、Hermes SE 的关键差异。

SkillOpt 和 Hermes SE 只优化 SKILL.md 文本。SkillHone 的每次合并 PR 可以同时改 SKILL.md、加一个 helper 脚本、扔一个参考文档——一个原子变更，通过回归测试门控。

这意味着什么？SkillOpt 改的是"指令文本"，SkillHone 改的是"整个工具箱"。

GitHub 式可观测性：本地跑，不用上云

SkillHone 把每一步都落盘为 Git 工件：

• 诊断 → GitHub Issue
• 修订 → Git Branch + Commit
• 审查 → Pull Request
• 知识沉淀 → Wiki

默认用 Forgejo（轻量 Git 服务器），可以完全跑在你本地机器上。打开 UI 就是熟悉的 PR 界面——评审者不需要学新工具，整个决策路径一目了然。

这是真正的工程化：不是日志文件里的一行 debug 输出，而是可以 review、revert、cherry-pick 的 Git 工件。

实验结果：15.8 个百分点怎么来的

SkillHone 在原始开放网络（raw open-web）环境下评测——Agent 必须在没有预集成搜索堆栈的情况下组织检索。使用 Qwen3.6-35B-A3B 作为评估时期的骨干模型。

15.8 个百分点的差距来自哪里？论文的论点是：持久决策历史让 Agent 能够将实践反馈转化为更强的技能包——不是从零开始推理，而是在已有决策基础上继续演进。

但要注意：骨干模型是 Qwen3.6-35B-A3B（35B 参数的 MoE 模型），不是 GPT-5.6 或 Claude Opus。更强的模型会不会缩小差距？论文没做这个消融实验。

6 个技能，1 个标准

SkillHone 仓库包含 6 个技能目录：

所有技能遵循 agentskills.io 标准——不需要运行时适配器。任何支持 skills 的 Agent 运行时都能直接加载：Claude Code、Codex、OpenClaw、Hermes，以及未来任何说同一协议的运行时。

没有适配器要维护——这是一个被低估的设计决策。SkillOpt 和 Hermes SE 各自绑定特定运行时，SkillHone 用开放标准实现了一次编写、到处运行。

代价清醒

Star 仅 47，Fork 4。 相比 SkillOpt 的 12,443★ 和 Hermes SE 的 4,646★，SkillHone 的社区关注度极低。创建于 2026-06-09，不到 5 周。

1 人贡献。 zwliJay 贡献 14 次，是唯一的核心开发者。巴士因子 = 1。论文作者 Zhiwei Li 和 Yong Hu 来自微信/Tencent——这是企业研究项目，不是社区驱动项目。

依赖 Forgejo。 本地 Git 服务器是可观测性的基础，但也意味着你需要维护一个 Forgejo 实例。对于个人开发者来说，这是一份额外的运维负担。

论文实验用的是 35B MoE 模型。 在 GPT-5.6 Sol 或 Claude Opus 级别模型上，持久决策历史的边际收益可能显著降低——强模型可能不需要那么多的历史上下文就能做出正确决策。论文没有做这个消融。

训练数据不可见。 评估仓库中的"练习探测"和"参考目标"是 SkillHone 工作的前提，但论文没有公开这些数据。你需要在实际场景中自己构建。

安全边界。 SkillHone 的 AGENTS.md 明确警告："某些 SkillHone 工作流可能使用 Claude Code bypass 模式和本地命令执行"。权限隔离防止了评估数据泄露，但没有防止优化子 Agent 执行任意命令。在非隔离环境中运行有安全风险。

SkillHone 解决的是"演进"问题，不是"冷启动"问题。 如果你连第一个版本的技能都没有，SkillHone 帮不了你。你需要先用 skillhone-prd 定义任务规格，用 skillhone-seed 生成初始技能，然后才能进入优化循环。

判断

SkillHone 的核心贡献不是"又一个技能优化框架"，而是证明了"为什么"和"是什么"一样重要。

现有方法只保留技能的"是什么"（最终版本），SkillHone 保留了整个"为什么"链（诊断→修订→证据→结果）。这在持续演进场景下至关重要——不是因为新 Agent 不聪明，而是因为没有上下文的聪明等于从零开始。

对于 Agent 开发者，SkillHone 提供了一条可工程化的路径：Git 工件替代日志文件、权限隔离替代 prompt 约定、开放标准替代运行时绑定。但前提是你接受 Forgejo 的运维成本和 35B 模型的能力天花板。

对于研究者，SkillHone 的"持久决策历史"概念值得更深入的探索：不同模型规模下历史的边际收益、历史长度的取舍（记太多是不是也会干扰？）、跨技能迁移历史的可能性。

记住被否掉的方案，和记住通过的方案一样重要。 这条原则不仅适用于 AI Agent，也适用于人类团队。

论文：https://arxiv.org/abs/2606.08671 GitHub：https://github.com/Tencent/SkillHone 项目主页：https://zwlijay.github.io/SkillHone-Project