为什么讲这个案例：Skill 蒸馏把「Agent 能力扩展→ 自适应与自进化→ 失败分析→ 供应链与伦理安全」四个原本分散的主题串成一条主线，而且几乎零成本可复现——只需一份 SKILL.md 和一批任务轨迹即可动手。
阅读路径：§1 讲格式（是什么），§2 讲方法（怎么蒸），§3 讲运行时（怎么用），§4–§5 是本案例的核心伦理节（能不能用、对谁用），§6 讲评测（值不值），§7 讲失败（错在哪），§8 讨论练习，§9 实验接口预留。
1. Skill 是什么：一份可加载的"流程说明书"
在 agentskills.io 的约定里，一个 Skill 就是一个目录 + 一份 SKILL.md。SKILL.md 采用 front-matter（YAML 元数据）+ 正文（结构化流程说明）的两段式：front-matter 负责"何时被选中"，正文负责"选中后怎么做"。
1.1 front-matter：让 Agent 决定"要不要用"
name：Skill 唯一标识（小写短横线），供 Bot 按名加载 / 组合引用。description：一句话第三人称说明"做什么 + 何时触发"，这是命中判据——Agent 靠它做语义匹配。version：语义化版本（1.2.0），用于回滚与兼容性管理（的版本观）。tags：分类标签，供目录发现与筛选。
1.2 正文：触发条件 / 步骤 / 参数 / 示例 / 边界
正文不是散文，而是一份"给模型看的操作手册"。约定五个小节：触发条件（When）、步骤（How，编号可执行）、参数（Inputs）、示例（Example）、边界（Limits / 不做什么）。
代码块 A（Markdown）——一个完整的"周报生成" Skill（岗位流程场景，不涉及任何真实个人风格）：
---
name: weekly-report-gen
description: 当用户要求"写周报 / 汇总本周工作 / 生成本周进展"时，
按团队标准模板汇总任务、指标与风险，产出结构化周报草稿。
version: 1.2.0
tags: [office, report, template, weekly]
---
# Weekly Report Generation
## 触发条件 (When)
- 用户显式提到"周报 / 本周总结 / weekly status"。
- 已能访问本周任务清单（issue tracker 导出 / 日历 / 聊天记录）。
## 输入参数 (Inputs)
- `period`: 统计区间，默认"本周一至本周日"。
- `tasks_source`: 任务数据路径或只读句柄（必填）。
- `audience`: 汇报对象，影响措辞粒度（manager | team | client）。
## 步骤 (How)
1. 拉取 `period` 内已完成 / 进行中 / 阻塞三类任务。
2. 对每类任务提取：标题、负责人角色（非姓名）、状态、环比变化。
3. 按固定四段模板填充：①本周进展 ②关键指标 ③风险与阻塞 ④下周计划。
4. 指标段落优先引用可量化项（完成率、缺陷数、交付周期）。
5. 生成草稿并**标注每一处数据来源**，供人工核对。
## 示例 (Example)
输入：tasks_source = `exports/2026-W37.csv`，audience = `manager`
输出：见模板渲染结果（含"数据来源"脚注列表）。
## 边界 (Limits)
- 不臆造未出现在数据源里的任务或指标。
- 不记录 / 不推断任何员工个人绩效身份，仅按"角色"聚合。
- 数据源缺失时明确报缺，不用历史值填补。工程提示：把
description写成"第三人称 + 触发词 + 边界预告"，命中率和安全性都会显著提升——它同时是路由依据和能力契约。格式若与agentskills.io官方有出入，以官方仓库为准。
2. 蒸馏流程四步：观察 → 抽取 → 封装 → 验证
"蒸馏"借了知识蒸馏的比喻，但对象不是模型权重，而是行为模式：从多次 Agent 成功轨迹里发现可复用套路，抽象成参数化步骤，写成 SKILL.md，再用同类任务验证是否命中。注意——蒸的是"某类任务怎么做"，不是"某个人怎么说话"，这条界线在 §4 会展开。
四步里最容易被忽略的是②抽取时的"参数化"：把轨迹里"每次都不同但结构相同"的部分抽成 Inputs，把"每次都一样"的部分固化成 How 步骤。抽象太粗 → Skill 命中率低；抽象太细 → 换个任务就失效。
方法提示：蒸馏本质是 Agent 的能力自进化：把一次性成功变成可复用资产。但"闭环"必须是人机协同的——第④步的验证判据（成功率↑、步数↓）要提前定死，不能让模型自己既当运动员又当裁判。
3. Hermes Bot 与 Skill 生态
Hermes Bot 承担"运行时"角色：触发（按 description 语义匹配选中 Skill）、加载（把 SKILL.md 正文注入上下文）、组合（多 Skill 串成工作流）。Skill 目录则负责"发现"——按 tags 检索、按 version 拉取。
3.1 与 MCP 工具的边界：内流程 vs 外动作
| 维度 | Skill（内部流程） | MCP 工具（外部动作） |
|---|---|---|
| 本质 | 一段"怎么做"的说明文本，被加载进上下文 | 一次"做出去"的函数调用，触达外部系统 |
| 产物 | 规划 / 编排 / 判断，不直接改外部状态 | 读文件、发请求、写库等副作用 |
| 粒度 | 可跨多步、含分支与边界 | 通常是单原子动作 |
| 组合关系 | Skill 里可调用若干 MCP 工具 | 被 Skill 编排，本身不含流程知识 |
一句话：Skill 是"菜谱"，MCP 工具是"锅铲"。菜谱会写"先焯水再下锅"（流程 + 顺序 + 边界），锅铲只负责"翻一下"（执行一个动作）。
3.2 给 Hermes 加载本地 Skill 目录并触发
代码块 B（Python）——扫描本地 ./skills 目录、解析 front-matter、按自然语言意图命中并触发：
import os, re, yaml
def load_skill(path):
"""解析一个 SKILL.md：返回 (meta, body)。"""
text = open(path, encoding="utf-8").read
m = re.match(r"^---\n(.*?)\n---\n(.*)$", text, re.S)
meta = yaml.safe_load(m.group(1)) if m else {}
body = m.group(2) if m else text
return meta, body
class Hermes:
def __init__(self, skill_dir="./skills"):
self.skills = {}
for name in os.listdir(skill_dir):
fp = os.path.join(skill_dir, name, "SKILL.md")
if os.path.isfile(fp):
meta, body = load_skill(fp)
key = meta.get("name", name)
self.skills[key] = {"meta": meta, "body": body}
# 版本冲突检测（：F4 Skill 冲突）
if len(self.skills) < sum(1 for _ in os.listdir(skill_dir)):
print("[warn] 存在同名 / 非法 Skill，已跳过")
def match(self, intent, llm):
"""把候选 description 交给 LLM 做路由，返回最匹配的 skill_name。"""
cand = {k: v["meta"].get("description", "") for k, v in self.skills.items}
prompt = f"用户意图：{intent}\n候选技能：{cand}\n只输出最合适的 name，无匹配输出 NONE。"
return llm.complete(prompt).strip
def run(self, intent, llm, **inputs):
name = self.match(intent, llm)
if name == "NONE" or name not in self.skills:
return llm.plan_from_scratch(intent) # 回退：现场规划（对照组）
skill = self.skills[name]
ctx = f"[/skill {name} v{skill['meta'].get('version','?')}]\n" + skill["body"]
return llm.execute(ctx, inputs) # 按 SKILL.md 执行诚实提示：Hermes 的实际接口（加载方式、
match/run签名、Skill 目录约定）以其官方仓库为准；上文是最小可读实现，用于演示"触发—加载—组合"三件事，不含真实网络调用。
4. "人物蒸馏"的技术与合规边界（核心伦理节）
视频与社区里常出现"复现某位专家工作风格"的玩法——本质是拿某人公开发言 / 作品 / 聊天记录当语料，让模型模仿其表达与决策习惯。技术上可行，但合规与人格权风险极高，是的典型场景。
4.1 三种允许场景
- ✔ ① 虚构角色：蒸馏对象是创作者自己虚构的人物（无真实对应自然人），如架空助手"老周·项目经理"。
- ✔ ② 本人书面授权：真实人物明确、书面、可撤回地授权对其风格做限定用途蒸馏，授权链完整留档。
- ✔ ③ 岗位流程标准化：蒸馏的是"某岗位怎么做"而非"某人怎么想"——即本文 §1 的周报 Skill，只按角色聚合，不绑定姓名。
4.2 明确禁止
- ✘ 未经同意的真实第三方人物蒸馏：以肖像 / 声音 / 表达风格 / 声誉风险为代价，模仿一个未授权的真实在世个人。无论"只是模仿说话"还是"以其名义产出"，都触碰人格权与误导红线。
4.3 蒸馏对象 × 授权 × 场景 × 风险
表格 1——合规判定矩阵：
| 蒸馏对象 | 授权类型 | 允许场景 | 风险等级 |
|---|---|---|---|
| 虚构角色（无真实对应） | 创作者自有 | 助手人设、示例、产品 Demo | 低 |
| 岗位标准流程 | 组织内部规范 | SOP 沉淀、新人培训、周报/评审模板 | 低 |
| 真实在职个人 | 本人书面授权 + 留档 | 本人授权的自传播 / 数字分身，标明 AI 生成 | 中 |
| 真实公众人物（演讲/著作） | 无 / 模糊授权 | ❌ 不得以其风格对外产出并暗示为其本人 | 高 |
| 真实第三方个人（同事/客户） | 无同意 | ❌ 禁止：涉肖像/声音/人格权、声誉与误导风险 | 极高 |
伦理提示：判断"能不能蒸"的第一道闸门是问：数据里有没有可识别到真实自然人的部分？那个人授权了吗？ 只要两问有一问答"是/没有"，就必须走 §5 的审查表并默认拒绝。本文所有示例统一使用"虚构角色"或"岗位流程"，不使用任何真实人物。
5. 伦理与合规审查表
任何 Skill 上线（尤其涉及"风格/表达/人设"）前，过一遍这六项。缺任一项 → 不放行。对接供应链/伦理与安全。
- ① 数据源合法性：语料/轨迹来源是否合规、有无爬取或泄露痕迹。
- ② 授权链完整性：涉及真实主体时，书面授权是否可追溯、是否可撤回。
- ③ 肖像权与人格权：是否可能识别到特定自然人，是否触碰肖像/声音/名誉。
- ④ 输出可识别性：AI 生成内容是否清晰标注，避免"以某人名义"误导。
- ⑤ 场景风险等级：对外/对内、是否影响他人权益、是否规模化传播。
- ⑥ 下架与追责机制：出问题时能否快速停用该 Skill、责任主体是否明确。
代码块 C（YAML）——可直接复制填写的审查表模板：
skill_name: weekly-report-gen
skill_version: "1.2.0"
reviewer: "张三（合规）"
review_date: "2026-10-01"
checks:
data_source_legal: # ① 数据源合法性
pass: true
evidence: "内部任务系统导出，已脱敏"
note: ""
authorization_chain: # ② 授权链完整性
applicable: false # 岗位流程，不针对个人
pass: null
evidence: "蒸馏对象=岗位角色，非自然人"
personality_rights: # ③ 肖像权与人格权
identifiable_real_person: false
pass: true
note: "仅按角色聚合，无姓名/声音/肖像"
output_attributable: # ④ 输出可识别性
ai_generated_label: true
pass: true
scenario_risk_level: # ⑤ 场景风险等级
level: low # low | medium | high
rationale: "对内使用，不对外发布"
takedown_accountability: # ⑥ 下架与追责
kill_switch: true
owner: "平台运维组"
pass: true
decision: approve # approve | reject | pending
blocking_items: [] # 未通过的 ①-⑥ 编号，非空即不得 approve工程提示：把这张
skill-audit.yaml与 CI 打通——PR 里若blocking_items非空或decision!=approve，拒绝合并 Skill。合规从"事后道歉"变成"事前门禁"，正是想要的"把伦理做进流水线"。
6. 蒸馏前 vs 蒸馏后评测
Skill 到底值不值？做对照：同一批任务，无 Skill（每次让 LLM 现场规划）vs 有 Skill（按 SKILL.md 执行），沿三个维度比：成功率 ↑ / 平均步数 ↓ / token 成本 ↓。
代码块 D（Python）——最小评测器，落 traces.csv：
import csv, statistics as st
def eval_skill_vs_none(tasks, hermes, llm, k=3):
"""tasks: [{'intent':str,'accept':callable}, ...]；对每任务跑 无/有 两臂各 k 次。"""
rows = []
for tid, t in enumerate(tasks):
for arm in ("no_skill", "with_skill"):
for rep in range(k):
try:
if arm == "no_skill":
out = hermes.run(t["intent"], llm) # 回退到 plan_from_scratch
else:
out = hermes.run(t["intent"], llm, tasks_source=t["source"])
ok = bool(t["accept"](out))
except Exception as e: # 失败也记，供 §7 编码
out, ok = repr(e), False
rows.append(dict(
task_id=tid, arm=arm, rep=rep,
success=int(ok),
steps=getattr(llm, "last_step_count", 0),
tokens=getattr(llm, "last_token_count", 0),
skill_name=getattr(llm, "last_skill", ""), # 见 §9 schema
skill_version=getattr(llm, "last_skill_version", ""),
authorization_status=getattr(llm, "last_authz", "n/a"),
))
with open("traces.csv", "w", newline="", encoding="utf-8") as f:
w = csv.DictWriter(f, fieldnames=list(rows[0]))
w.writeheader; w.writerows(rows)
return rows
def summarize(rows):
print("arm 成功率 均步数 均tokens")
for arm in ("no_skill", "with_skill"):
g = [r for r in rows if r["arm"] == arm]
sr = sum(r["success"] for r in g) / len(g)
print(f"{arm:12s} {sr*100:5.1f}% "
f"{st.mean(r['steps'] for r in g):6.1f} "
f"{st.mean(r['tokens'] for r in g):8.0f}")表格 2——示意结果（示意，非实测值）：
| 臂 | 成功率 ↑ | 平均步数 ↓ | 平均 token 成本 ↓ |
|---|---|---|---|
| 无 Skill（现场规划） | 58% | 9.4 | ~4200 |
| 有 Skill（按 SKILL.md） | 83% | 5.7 | ~2300 |
度量提示：三指标要一起看。若某 Skill 让成功率涨了但步数/成本也涨，说明它过度规定了流程；真正的好 Skill 通常三向同时改善——因为"套路"替模型省掉了反复试错。
7. 失败案例编码（为 pr09 铺垫）
Skill 生态有它独有的失败面。给五类失败编码，供 §6 的 traces.csv 人工 / 双标注使用，Kappa 一致性分析见 pr09。
表格 3——失败编码本片段：
| 编码 | 定义 | 触发条件 | 严重度 | 处置建议 |
|---|---|---|---|---|
| F1 | 未授权蒸馏 / 越权 | Skill 语料含未同意真实个人且过不了 §5 | 极高 | 立即下架 + 走追责机制 |
| F2 | 幻觉步骤 | 执行时凭空补出 SKILL.md 里没有的操作 | 高 | 收紧 边界 段 + 加"缺数据即报缺" |
| F3 | 风格漂移 | 输出与 SKILL.md 约定模板/口径持续偏离 | 中 | 补示例、提温度约束或升版本 |
| F4 | Skill 冲突 | 多 Skill 命中同一意图，步骤互相矛盾 | 中 | 明确优先级 / 拆分 description |
| F5 | 触发误判 | 不该用该 Skill 的任务被匹配上 | 中 | 细化触发条件与负样本 |
归因提示：F1 是合规失败（走 §5 下架），F2–F5 是工程失败（回 §2 重蒸）。两者处置路径完全不同，编码时必须分清——这正是 pr09 用 Cohen's Kappa 校标注一致性的原因。
8. 讨论练习练习：AI 蒸馏与职场
三个开放议题，每题给正反方要点与"可核查证据清单"。建议先分头查证再辩论，避免空对空。
议题 A：岗位技能被标准化，是赋能还是取代？
正方：Skill 把重复劳动沉淀成资产，员工从"手工执行"升到"审校与创造"，新人上手更快。反方：可复用即"可替代"，标准化的深度可能压过人的剩余价值，议价权流向持有 Skill 库的一方。
可核查证据：所在团队引入 SOP/Skill 前后同类任务的人均耗时与错误率；岗位说明书是否随之改写。
议题 B：一个人的工作风格被蒸馏，这个 Skill 归谁？
正方：产出用了公司数据与算力，成果归组织。反方：风格源于个人长期积累，未经书面授权不应被固化为可转让资产。
可核查证据：劳动合同 / 职务作品条款；是否有书面授权与可撤回机制（对照 §4.1）。
议题 C："蒸馏"是否等于"复制"一个人？
正方：只抽流程与模板，不复制人格与生物特征，属正当抽象。反方：若输出可稳定还原个人表达且对外可识别，其社会效果已接近"数字复制"。
可核查证据：盲测——不知情者能否从输出反推到具体自然人（关联 §5 第③④项）。
动手提示：辩论结论不是"能不能蒸"，而是"在什么授权与标注前提下、蒸到什么粒度才可接受"。把每方的证据落到 §4–§5 的判定矩阵与审查表上，才算闭环。
9. 实验接口预留
沿用 pr03 的 traces.csv schema，为 Skill 蒸馏额外追加三列，让 pr08 度量、pr09 Kappa 编码、pr14 实证都能复用同一份轨迹：
skill_name：本条轨迹实际命中的 Skill（no_skill臂留空）。skill_version：命中的版本号，支撑回滚与版本对比。authorization_status：granted / fictional / role-based / denied，把 §4–§5 的合规判定写进数据，供下游按风险切片统计。
这三列是 pr08（度量与 A/B）、pr09（失败标注 + Cohen's Kappa）、pr14（实证研究）共用的接口。authorization_status=denied 的行应触发 F1，直接从质量指标里剔除并单独统计——把伦理维度变成可查询的数据列。
格式提示：追加列只做"加法"、不改 pr03 已有列名，保证旧脚本向前兼容。字段取值集若与官方后续定义冲突，以官方为准并在此注明版本。
一页纸总结：Skill = front-matter + 正文的可加载流程说明书；蒸馏 = 观察→抽取→封装→验证的自进化闭环；Hermes 负责触发/加载/组合（Skill 是菜谱、MCP 是锅铲）；人物蒸馏只允许"虚构角色 / 书面授权 / 岗位流程"三场景，未经同意的真实第三方一律禁止并用六项审查表 + 数据列（authorization_status）把它做进流水线；价值用"成功率↑/步数↓/成本↓"三维评测验证，失败用 F1–F5 编码归因。