把一个"懂事的同事"打包成 Skill：从异构痕迹蒸馏可检查、可修正、可回滚的 AI 技能

核心摘要

你有没有这种感觉——团队里那位真正"懂事"的老同事走了之后，新人花三个月也补不上他留下的判断力？他不是会写 API，他是知道哪种 API 设计在你们这套架构下两个月之后会爆。这种东西，文档写不下，记忆系统记不住，prompt 也凑不出来。

这篇 COLLEAGUE.SKILL（arXiv: 2605.31264）做的事情是：把这种散落在代码评审、设计文档、群聊决策里的"专家痕迹"，自动蒸馏成一个可调用、可检查、可修正、可回滚的 Skill 包。它不是又一个 persona prompt，也不是又一个 RAG 知识库——它把"能力"和"行为风格"分成两条独立的轨道（capability track + bounded behavior track），各自可单独调用，所有改动都生成可读的 Markdown 补丁，错了能 rollback。开源仓库 18.5k 星、画廊里 215 个 Skill 来自 165 个贡献者——这个量级在 2026 年中已经能说明一些东西了。

我读完最大的感受：这是一篇典型的"工件级"论文，它没有刷榜，也没有声称自己复刻了一个人。但它把一件大家都在做但都做得很糙的事——把人/角色塞进 Agent ——给出了一个有契约、有边界、有版本管理的工程范式。值不值得花时间细读？如果你在做 Agent Skills 生态、企业知识沉淀、或角色化 Agent，值得；如果你想看 SOTA 数字，那这篇没有。

论文信息

  • 标题：COLLEAGUE.SKILL: Automated AI Skill Generation via Expert Knowledge Distillation
  • arXiv：2605.31264（v1，2026 年 5 月 29 日）
  • 作者：Tianyi Zhou、Dongrui Liu、Leitao Yuan、Jing Shao、Xia Hu
  • 代码：开源系统，公开仓库与画廊均可访问

一、问题动机：人不是文档，人也不是 prompt

先说一个我自己踩过的坑。

之前在做企业内 Agent 的时候，老板说"你把张三那套审 API 的判断力做进去"。听起来是个明确的需求——直到我开始动手。张三的判断力分散在哪里？设计文档里有一些标准，代码评审里有一些反例，飞书群里有一堆"这次先这么干，下次记得查 X"，事故复盘里有"上次我们就是没注意 Y 才炸的"。这些东西凑在一起，才是张三。

那时候我们试过几条路，没一条特别舒服：

  • Prompt 工程：把张三的"风格"写成一段 system prompt。结果是模型学到了语气，但 API 评审的硬规则没学到——它会用张三的口吻给你一个张三看了想打人的方案。
  • RAG / 长记忆：把所有材料丢进向量库。模型确实能引用，但你没法看到模型到底"沉淀"了哪些规则——它只是临时检索。
  • Fine-tune：成本高、改起来更难、版权同意一关就过不去。

问题的本质是什么？人类专家的可操作知识，不是以"清晰指令"的形式存在的——它是嵌在异构痕迹（heterogeneous traces）里的。这些痕迹有一部分是事实知识（API 安全审查清单、限流模式、敏感数据规则），有一部分是程序判断（在什么场景下走升级流程），还有一部分是表面风格（张三说话直但不损人）。把这三种东西混在一起塞给模型，结果就是哪一种都做得不好。

而现有的 Skill 框架（Anthropic Agent Skills、Voyager 这类）解决的是"如何打包和调用一个能力"，没有解决"如何从一堆痕迹自动生成一个 Skill"。痕迹到 Skill 之间的那段路，没人走通。

这就是这篇论文的切入点。

二、方法核心：双轨蒸馏 + 工件契约

2.1 一句话讲清楚核心思路

给定一个人/角色的异构材料，自动产出一个版本化的 Skill 包，它把"能力"和"行为约束"分到两条独立轨道，每条都能单独被 Agent 调用，所有更新都走自然语言反馈 → Markdown 补丁 → 版本号递增的生命周期。

注意几个关键词：自动、双轨、版本化、自然语言反馈驱动更新。

2.2 系统架构总览

图1：COLLEAGUE.SKILL 系统架构总览

图1：从异构人物痕迹（左侧：工作文档、代码评审、访谈、私人聊天等）经过收集器/解析器、分析器、构建器、写入器，输出版本化的 Skill 包（右侧：可被多种 Agent 主机加载、可修正、可回滚、可选择性发布到画廊）。

整张图我建议你慢慢看一下，因为它把整个系统的"流向"讲得很清楚。从左到右：

左：输入是什么。三类典型输入——同事场景（飞书/钉钉/Slack 工作记录、代码评审、事故复盘）、公众人物（第一人称著作、长访谈、公开决策）、私人关系（个人互动历史）。注意一点：输入是异构的、非结构化的——不是一份干净的指令文档。

中：处理链路。collector → parser → analyzer → builder → shared writer。这条链路最关键的是 analyzer 这一步——它要从原始痕迹里分离出三类不同的东西：能力（procedures、心智模型、决策启发式）、行为（沟通风格、交互规则）、元数据（来源、边界、引擎兼容性）。

右：输出是什么。一个版本化的 Skill 包，可以装到不同的 Agent 主机（Claude Code、OpenClaw、Codex、Hermes 等都支持），可以被自然语言反馈修正，可以回滚到旧版本，也可以发布到公开画廊。

我读到这里第一反应是：这套链路其实跟一个编译器很像——前端做词法/语法分析（collector + parser），中端做语义分析（analyzer），后端做代码生成（builder + writer）。区别在于源语言是"人类痕迹"，目标语言是"Agent Skill"。这个类比让我对这套设计的稳健性更有信心了一点。

2.3 三个预设：同一个机制，不同的边界

图2：三个域预设（同事/公众人物/关系）共享同一管道但治理要求不同

图2：Colleague、Celebrity、Relationship 三个预设建立在同一个 person-grounded skill pipeline 之上，但各自在证据范围、治理要求、调用别名上做了差异化配置。

这张图我觉得很值得多看两眼，因为它体现了一个做平台型系统的人的成熟思路：不是给三种场景各做一套，而是抽出一个共用机制，在外面包一层 preset。

预设 证据来源 治理要点 典型场景
Colleague（同事） 工作文档、代码评审、群聊决策、事故笔记 企业访问控制、组织同意 团队知识转移、新人上手
Celebrity（公众人物） 第一人称著作、访谈、公开决策、表达风格 公开证据边界、必须有来源标注、薄弱处降低置信度 心智模型学习、思考方式参考
Relationship（关系） 私人互动历史 本地所有权、删除权、隐私默认非公开 个人互动模式记录

这里有个细节我特别欣赏：Celebrity 预设里要求"证据薄弱时降低置信度，避免用通用人物文本填补空白"。说人话就是：如果材料不够，就坦白材料不够，不要瞎编。这一句话其实划清了一条很重要的线——这个系统不是在做 deepfake，它是在做有边界的工件。

Relationship 预设我会觉得是这套系统里最容易出问题的那个 preset——也是论文里反复强调治理要求最严格的那个。如果你的产品方向真的要碰这块，建议把 Limitations 那一节多读几遍。

2.4 双轨表示：为什么能力和行为必须分开

这是整篇论文我觉得最值得抠的设计——也是它跟普通 persona prompt 拉开差距的关键。

把"事实知识"、"程序判断"、"表面语调"混在一起，是 persona 类系统的原罪。

它给的解决方案是把 Skill 拆成两条 track：

Capability Track（能力轨道，work.md）

装的是"专家在工作中真正会用的判断"——程序、标准、启发式、任务模式。比如同事场景下：

  • API 评审时检查认证、输入校验、限流、响应模式、敏感数据暴露
  • 事故分类的启发式（"这种症状大概率是 X，先查 Y"）
  • 升级流程的阈值规则（"超过这个量级的影响必须升级"）

Bounded Behavior Track（行为轨道，persona.md）

装的是"这个人/角色怎么说话、怎么互动"——表达偏好、交互规则、修正历史。注意"bounded"这个词——不是开放式模拟，是受约束的行为规则。

修正记录的存储格式是这样的：

{
  "scene": "代码评审中遇到嵌套回调",
  "wrong": "这代码写得真烂",
  "correct": "这里嵌套有点深，建议拆成两个函数，可读性会更好"
}

这个三元组结构我特别想夸一下——它把"什么场景下、模型说错了什么、应该怎么说"形式化成了一个可机读的小数据点。每一次用户反馈"他不会这样说"，系统就生成一条这样的记录追加到 persona.md，未来调用时模型会先看这些约束。

为什么必须分开？

论文给了一个我觉得很关键的论证：有些场景下你只想要能力，不想要风格。比如你想用张三的 API 评审能力，但是不想让模型学张三那套带刺的语气——这时候你只调 work_skill.md，bypass 掉 persona。反过来，你想做一个"用张三的语气写周报"的玩具应用，那只调 persona_skill.md。

所以实际上 Skill 包暴露了三种调用模式：

  1. 完整模式：能力 + 行为，整个人
  2. 仅能力模式（work_skill.md 入口）：只要工作判断
  3. 仅行为模式（persona_skill.md 入口）：只要说话风格

这个设计在工程上的价值很大。我之前做角色 Agent 的时候踩过的一个坑就是——用户想要的"专业感"和"个性化"经常不在同一个 token 上，硬塞在一个 prompt 里就会互相干扰。这套双轨切分实际上把这个权衡显式化了。

2.5 工件契约：一个 Skill 包到底有什么

这是整套系统的"接口规范"。论文里列了一张表，我整理下：

文件 主消费者 内容
SKILL.md Agent runtime / 用户 组合后的可调用 Skill 入口（含 frontmatter、能力轨道、行为轨道、操作规则）
work.md 用户 / 更新器 可编辑的能力文档：程序、标准、启发式、任务模式
persona.md 用户 / 更新器 可编辑的行为文档：风格、交互姿态、边界、修正日志
work_skill.md Agent runtime 从 work.md 派生的"仅能力"入口
persona_skill.md Agent runtime 从 persona.md 派生的"仅行为"入口
manifest.json 安装器 / 画廊 入口点、工件清单、兼容运行时、slash 命令、工具链元数据
meta.json 生命周期工具 Schema、来源、生命周期版本、修正计数、兼容性字段

注意几个细节：

  1. work.md 和 work_skill.md 是分开的——前者是给人编辑的"原始文档"，后者是给 Agent 调用的"运行时入口"。两者的关系是 source-of-truth → derived view，避免人和机器抢同一份文件。
  2. meta.json 里有 correction count 和 lifecycle version——这就是版本管理和审计的基石。
  3. 当前 schema 是 v3——说明这套契约本身也在演化，不是一锤子定下来的。

这套设计本质上是把一个 Skill 当软件包来管理（有 manifest、有 meta、有 schema 版本）——而不是把它当一段提示词。这一点视角的差别会决定你后面的工程能不能扩展。

三、修正生命周期：让 Skill 可以"被改正"

图3：修正与版本生命周期

图3：用户的自然语言反馈被识别 → 分类为能力修正还是行为修正 → 生成 Markdown 补丁或 {scene, wrong, correct} 修正记录 → 旧版本归档、应用补丁、生命周期版本号 +1 → 重新生成派生工件。任何时候都可以回滚到先前版本。

这一块我觉得是这篇论文最有工程素养的一块。我们一条条看。

第一步：自然语言反馈被识别。用户不需要去手动改 markdown，只要说"他不会这样说"、"她在这里会反对，不会顺着用户"——系统会从这种自然语言里提取出修正意图。

第二步：分类。修正是关于"能力"还是"行为"？

  • 如果是能力修正（"评审 API 时还应该检查 CORS 配置"），系统会生成一个Markdown patch，找到 work.md 里对应的二级标题（比如 ## API Review Checklist），如果匹配到就替换该 section，匹配不到就追加。
  • 如果是行为修正（"她不会用感叹号"），系统会生成一条 {scene, wrong, correct} 记录追加到 persona.md 的修正日志里。

第三步：版本管理。关键在这里——旧版本不会被覆盖，会被归档。生命周期版本号 +1，meta.json 里的 correction count +1。

第四步：派生工件重新生成。work.md 改了，work_skill.md 跟着重生成；persona.md 改了，persona_skill.md 跟着重生成；SKILL.md（组合入口）也跟着更新。

第五步：任何时候都可以回滚。这是最让我觉得"成熟"的一点。Skill 不是越改越好的——你可能改了之后发现新版本反而把某些原本对的判断改错了，这时候 rollback 是救命的。

我之前做类似系统的时候没做版本管理，结果就是一条线性叠加，改飞了之后没法回去——只能从头再来。这套机制把一个 Skill 包做成了类似 git 的可追溯结构，这对长期维护一个企业内部知识资产来说是刚需。

四、部署与生态：18.5k stars 是怎么来的

图4：截至 2026-05-28 的公开部署计数器

图4：观测到的部署与分发表面统计——215 个 Skill、55 个元 Skill、165 个贡献者、画廊技能卡累计 100k+ stars、GitHub 仓库 18.5k stars。论文明确强调：这些是"分发表面"指标，不是任务表现或行为保真度的指标。

我特别想强调论文这里的措辞："these counts represent deployment and distribution surface, not measures of task performance, behavior fidelity, or quality of adoption."

翻译一下：这些数字代表"有多少人愿意在这套契约下生产和分享 Skill"，不代表"这些 Skill 跑起来的效果有多好"。

这是一句很克制、很干净的话。看到这种自我边界划得清的论文我是有好感的。很多论文喜欢把"用户增长曲线"包装成"方法有效性证明"，这篇没有这么干。

但反过来说——18.5k stars 和 165 个贡献者本身确实说明了一些东西：这套契约的设计至少在分发层面是被市场接受的。如果 SKILL.md / work.md / persona.md / manifest.json 这套接口不友好，是不可能积累出这么多贡献者的。这是一个生态指标，不是性能指标，但它在这个领域是有意义的。

支持的 Agent 主机现在覆盖了 Claude Code、OpenClaw、Codex、Hermes 几个主流——基本是冲着"跨主机可移植"去的。这一点跟 Anthropic 自己提的 Agent Skills 规范是兼容的，论文里也明确说了"采用此新兴包格式"——它没有自己另起炉灶造一套不兼容的 Skill 标准，这是正确的工程选择。

五、批判性审视：这篇论文的几个可疑之处

我读完之后有几个地方是想皱眉的，列出来供你参考。

5.1 没有任何任务级别的实验

整篇论文没有 benchmark、没有 baseline 对比、没有 ablation。所有的"评估"都是"工件级"的——这套契约能不能产出工件、产出的工件能不能装到 host、能不能 rollback。

论文自己也承认了这一点。在 Limitations 里写得很直白：

Whether the colleague skill captures the same review concerns as the source expert; whether the work-only variant preserves utility without persona risks; whether relationship skills encourage over-attachment; whether corrections improve behavior without regression — all require human and task-based studies.

这是一个克制的、负责任的免责声明——但也意味着，你看完这篇论文不能下结论说"这套方法 work"。你能下的结论只有"这套接口设计合理、生态在生长"。

5.2 双轨分离的代价没有被讨论

"能力和行为分轨"是一个非常漂亮的设计原则，但实际操作中——有些判断是能力还是行为，本来就是模糊的。

举个例子：一个高级工程师在评审里说"这种写法虽然能跑但维护起来会很痛苦"——这句话里"维护性判断"是能力，"痛苦"这种修辞是行为。analyzer 怎么切？切错了会怎样？切多了怎么办？

论文里 analyzer 的实现细节给得很少，主要靠 LLM 推断。这块是不是真的稳，需要更多案例支撑——我自己的经验是这种"语义切片"任务在 LLM 上是经常翻车的。

5.3 Trace-to-Skill 的真实压力测试缺失

如果给一个完全陌生的领域（比如一个律师的工作痕迹），这套系统能产出有用的 Skill 吗？还是只在"软件工程师同事"这个被过度优化的场景下表现良好？

215 个 Skill 里"元 Skill"占了 55 个——也就是说大约 1/4 是关于"如何用这个系统"的元 Skill 而不是真正的领域 Skill。这个比例值得注意一下。

5.4 跟同期工业界方案的关系没说清

2026 年中这个时间点上，类似的"角色化 Agent + 知识沉淀"方案在工业界已经不少。比如 Anthropic 自己的 Agent Skills 生态、各家公司的 Memory 系统、各种 persona 框架。

论文 Related Work 里提到了 Voyager、SkillX、PersonaAgent、Character-LLM 等等，但和这些方法的对比是在"做什么"层面，没有在"做得好不好"层面。这部分如果能加一张定性对比表，会更有说服力。

六、几条工程启发

聊点能落地的。如果你也在做类似的方向，这篇论文里我觉得值得直接抄的几个设计：

1. 把 Persona / Skill 当软件包管理

manifest.json + meta.json + schema version 这套结构，是把 Skill 从"提示词"提升到"软件工件"的关键。一旦你引入了 schema 版本、修正计数、兼容性字段，你后面要做审计、合规、版本回滚、跨主机部署，都有抓手。

2. 把"能力"和"行为"做强分离

不要再用一段 system prompt 把所有东西糊在一起。即使你不做完整的双轨系统，至少在 prompt 模板里把这两类内容分成两个明确的 section——你会发现模型在 ablation 调试时能给你更稳定的行为。

3. 修正用 {scene, wrong, correct} 三元组

这个数据结构非常工程友好。它比"自由文本反馈"更结构化，又比"完全形式化的规则"更灵活。每条修正都是一个小数据点，未来甚至可以拿来训一个修正分类器。

4. 任何"在线学习"系统都必须有版本归档和 rollback

我反复踩过的坑——线上系统没做版本管理就上"自动学习"，等模型行为飘了根本回不去。这篇论文里把 rollback 做成一阶设计，是经验之谈。

5. 给"证据薄弱"留口子

Celebrity 预设里"证据薄弱时降低置信度"这一条，可以扩展到任何 RAG / Persona 系统——不要追求 100% 覆盖，而是允许"我不知道"和"这一块证据不够"作为合法输出。这个原则在合规和用户信任上的回报远大于多覆盖几个 case 的收益。

七、我的判断

这篇论文的真实定位是什么？

它不是一篇方法论文（没有新的训练算法、没有新的架构），它也不是一篇评测论文（没有 benchmark）。

它是一篇系统论文 + 工件契约论文 + 早期生态报告——它告诉你"如果你想把人类专家痕迹工程化为 Agent 可用的 Skill，这套接口是值得参考的"。

亮点： - 双轨分离 + 工件契约的设计是真的清晰 - 修正生命周期 + 版本回滚是工程上的成熟思路 - 跟 Anthropic Agent Skills 规范兼容，没有另起炉灶 - 对自己的限制说得很清楚，没有过度包装

短板： - 缺乏任务级别的实验，无法证明"提取出来的 Skill 真的好用" - analyzer 的稳定性靠 LLM，没有压力测试 - 跨领域泛化性没有充分验证 - Related Work 的对比深度不够

值不值得花时间细读？

  • 如果你在做 Agent Skills 生态、企业知识沉淀工程、或角色化 Agent 平台——值得读，特别是工件契约和修正生命周期那两节
  • 如果你在做学术评测、想看 SOTA 数字——不值得，这不是这种类型的论文
  • 如果你在做 persona / memory / RAG 框架——值得快速扫一遍，至少把"能力/行为分离"和"{scene, wrong, correct} 修正记录"两个想法拿走

这类系统型论文在 2026 年的 LLM Agent 社区会越来越多——做大模型的人开始意识到，算法刷不出来的东西，工程契约可以做出来。这篇论文是这个趋势里一个挺干净的样本。

最后一句话：如果你看完这篇论文最大的收获是"哦原来 Skill 也可以做版本管理和 rollback"——那它的价值就达到了。 别去苛求它给你一个 SOTA 数字。

参考链接

  • 论文 arXiv: https://arxiv.org/abs/2605.31264

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我