Skill 渐进式知识管理

学习目标

读完本章后，你将能够：

理解三层渐进式披露的知识加载策略
设计有效的 Skill 触发短语
组织 SKILL.md、references/ 和 examples/ 的内容边界
避免上下文浪费和触发失效

核心概念

三层渐进式披露

Skill 系统的核心设计原则是渐进式披露（Progressive Disclosure）：知识按需加载，而非一次性全部注入上下文窗口。

三层职责：

层级	内容	大小约束	加载时机
SKILL.md	触发短语、核心流程、关键约束	~1,500-2,000 词	触发短语匹配时
references/	详细参数说明、API 参考、迁移指南	每文件 ~300-800 词	需要深度信息时
examples/	可复制的工作示例、配置模板	按需	需要示例参考时

触发短语设计

触发短语决定了 Skill 何时被激活。好的触发短语应满足：

强信号，低噪音：

# 好的触发短语 — 明确的意图信号
- 用户询问"如何创建插件"
- 用户提到"plugin structure"、"plugin.json"
- 用户请求"开发 Claude Code 插件"

# 差的触发短语 — 过于宽泛
- 用户提到"file" → 几乎每次对话都会触发
- 用户提到"code" → 几乎每次对话都会触发

第三人称描述（用于 Skill 的 description 字段）：

This skill should be used when the user wants to develop a Claude Code plugin, create plugin components, or publish a plugin to a marketplace.

命令式/不定式正文（用于 SKILL.md 内部指令）：

To create a new plugin, do the following:
1. Create `.claude-plugin/plugin.json` with metadata
2. Add component directories
3. Implement each component

知识加载策略

Skill 加载知识的方式直接影响上下文窗口的利用效率：

策略 1：核心指令常驻，深度参考按需

SKILL.md 中只保留触发条件、核心流程和关键约束。详细参数、API 参考、边缘情况放入 references/，仅在被主动请求时加载。

策略 2：示例分离

工作示例放在 examples/ 目录，不在 SKILL.md 中嵌入大段代码。示例需要时被完整读取，不需要时不占用上下文。

策略 3：技能互调

一个 Skill 可以通过 Skill 工具调用另一个 Skill：

When creating a new hook, first load the hookify:writing-rules skill to understand the rule file format.

这使得知识模块化，避免重复。

写作标准

一致性标准（以 plugin-dev 的 7 个 Skill 为例）：

维度	标准	示例
描述	第三人称	”This skill should be used when…”
触发短语	具体用户查询模式	”如何创建 hook”、“plugin settings”
正文格式	命令式/不定式	”To do X, do Y”
SKILL.md 大小	~1,500-2,000 词	超过则拆分到 references/
References 数量	2-4 个/技能	每个专注一个子主题

四层技能发现与优先级

在某些 Agent 实现中（如 Gemini CLI），技能不仅来自单一位置，而是通过多层发现机制加载，并按优先级覆盖：

优先级规则：同名技能以高优先级来源为准，低优先级的同名技能被覆盖。

Agent 技能别名：.agents/skills 目录下的技能作为 Agent 能力的扩展，与常规技能并行加载，支持 Agent 在执行过程中动态获得新能力。

运行时技能激活

除了被动触发外，Agent 还可以通过专用工具（如 activate-skill）在运行时主动激活某个技能。这使得：

Agent 可以自行判断当前任务需要什么知识，主动加载
用户无需知道技能名称，Agent 自行发现和激活
技能可以保持”待激活”状态，不占用上下文直到实际需要

自动技能提取

高级 Agent 系统在对话空闲时自动从历史会话中提取新技能（SkillExtractionAgent）：

后台任务检测空闲时间超过阈值（如 3 小时）
批量处理未索引的会话历史
使用专用 Agent 分析对话模式，提取可复用的工作流
将提取结果注册为新 Skill，下次会话可直接使用

节流机制：两次提取之间至少间隔 30 分钟，避免频繁运行影响性能。

文件锁协调：使用 .extraction.lock 文件防止多个 CLI 实例同时运行提取任务。

陷阱与对策

陷阱	表现	对策
SKILL.md 过长（>3,000 词）	每次触发都浪费大量上下文窗口	将细节迁移到 references/，SKILL.md 只保留核心
references/ 与 SKILL.md 不一致	模型得到矛盾指令	修改 SKILL.md 时同步更新 references/
触发短语太宽泛	误触发，干扰正常对话	收窄触发短语，使用多条件组合
触发短语太具体	漏触发，用户需要手动调用	增加常见变体到触发列表
Skill 互调循环	A 调 B，B 调 A，无限循环	使用 `context: fork` 避免自我调用
四层优先级冲突	工作区技能覆盖内置技能导致行为不一致	高优先级目录中同名技能应显式声明覆盖意图
自动提取质量不稳定	提取的 Skill 过于泛化或不准确	设置最低对话轮次阈值（如 ≥10 轮用户消息）

设计取舍

为什么用 Markdown 而非 JSON/YAML 定义 Skill？

Markdown 对人类和模型都友好。人类可以阅读和编辑，模型可以直接理解其中的自然语言指令。JSON/YAML 需要额外的解析和转义。

为什么 SKILL.md 限制在 ~2,000 词？

上下文窗口是有限资源。如果每个 Skill 都携带大量知识，触发判断会变慢，且容易超出窗口限制。2,000 词是经验上的平衡点——足够表达核心指令，又不至于过度占用上下文。

为什么示例放在独立文件而非内联？

内联示例会膨胀 SKILL.md，增加每次触发的上下文开销。独立示例文件仅在需要时读取，保持了核心指令的精简。

OpenHands 补充：集中式 Skill 加载与多层分发

在 OpenHands 的 V1 架构中，Skill 加载遵循中心化加载 + 多层分发模式，与前述的渐进式披露（SKILL.md → references → examples）互补。

核心特征：

维度	OpenHands 实现
加载架构	App Server 作为薄代理，HTTP 转发到 Agent Server 的 `/api/skills` 端点
四层来源	public → user → project → org，可通过 `load_public/load_user/load_project/load_org` 开关控制
技能格式	Markdown + YAML frontmatter（name, triggers, agent, mcp_tools），无 references/examples 分层
触发类型	KeywordTrigger（关键词匹配）与 TaskTrigger（斜杠命令，triggers 以 `/` 开头）
V0→V1 迁移	同一批文件同时服务 V0 Microagents 和 V1 Skills，文件名不变
组织级分发	Org Skills 存储在独立配置仓库（如 `owner/.openhands`），通过认证 URL 拉取

与渐进式披露的差异：

OpenHands 的 Skill 格式更轻量——单个 Markdown 文件即包含触发条件和完整内容，没有 SKILL.md + references/ + examples/ 的三层分离。这降低了创建门槛，但也意味着每次加载的上下文开销更不可控。

组织级技能的认证传递：

Org Skills 需要从用户的组织配置仓库拉取，涉及 Git 认证信息的安全传递：

App Server → 构建 OrgConfig（含 org_repo_url + provider）
           → HTTP POST 到 Agent Server（含 X-Session-API-Key）
           → Agent Server 使用认证 URL 克隆/拉取仓库
           → 解析 .openhands/skills/ 目录下的 Skill 文件

陷阱：

Org 级 Skill 依赖外部仓库权限，用户离职或 token 过期后静默失效
触发词过于宽泛（如 code、file）会导致几乎每次对话都加载该 Skill
Agent Server 不可达时 Skill 加载返回空列表而非报错，不会阻塞对话启动

补充：CLI-Anything 的 SKILL.md 自动生成与双路径分发

来源：CLI-Anything（HKUDS/CLI-Anything）cli-anything-plugin/skill_generator.py + HARNESS.md Phase 6.5，commit 7862c92

从 Click 装饰器自动提取元数据

CLI-Anything 的 skill_generator.py 展示了从 CLI 框架自动提取技能元数据的模式：

解析 Click CLI 的 @click.group 和 @click.command 装饰器获取命令树
从 README.md 提取软件简介和系统包依赖
从 setup.py 提取版本号和包名
生成标准化的 YAML frontmatter（name + description 触发元数据）
生成包含命令组、使用示例、Agent 指南的 Markdown 体

与手动编写 SKILL.md 的差异：大多数 Skill 系统由人类编写 SKILL.md，CLI-Anything 展示了从结构化代码自动生成的路径——元数据直接从 Click 装饰器、README、setup.py 中提取，而非人工填写。

Canonical vs Compatibility 双路径分发

skills/cli-anything-<software>/SKILL.md        ← Canonical（repo-root）
cli_anything/<software>/skills/SKILL.md        ← Compatibility（pip 安装后）

Canonical 路径：在 monorepo 中的统一技能文件位置，npx skills 发现时使用
Compatibility 路径：随 pip 包分发的拷贝，确保 pip install 后 REPL Banner 仍能显示技能路径

ReplSkin 在运行时优先查找 Canonical 路径，回退到 Compatibility 路径。这使得：

Monorepo 开发时：单一事实源，修改即时生效
用户安装后：技能文件随 pip 包一起安装，无需额外步骤

CLI-Anything 的 REPL Banner 在启动时显示 SKILL.md 的绝对路径，Agent 可以阅读该路径了解 CLI 的完整能力。这是 Skill 发现与运行时 UI 的集成模式——不仅仅是”触发时加载”，而是在启动时就提示 Agent 有额外的技能文档可读。

补充：Agent Skills 的写作原则与反合理化设计

来源：Addy Osmani / agent-skills v0.6.1，docs/skill-anatomy.md + 23 个 skills/*/SKILL.md，commit 6ce0298

标准章节流模式

Agent Skills 定义了 Skill 的标准章节结构，成为多个项目的事实参考：

# Skill Title

## Overview          → 1-2 句电梯演讲
## When to Use       → 触发条件 + 排除条件（NOT for Y）
## Core Process      → 编号步骤或阶段的工作流
## Techniques/Patterns → 详细技术指南
## Common Rationalizations → 反合理化表
## Red Flags         → 违反行为的可观察信号
## Verification      → 退出标准检查清单

等价标题可接受：How It Works、Workflow、Steps 等当它们传达相同目的时。

六条写作原则

#	原则	含义
1	过程优于知识	Skill 是工作流，不是参考文档。是步骤，不是事实。
2	具体优于一般	”运行 `npm test`” 优于 “验证测试”。
3	证据优于假设	每个验证检查框都需要证据（测试输出、构建结果、截图）。
4	反合理化	每个可能被跳过的步骤都需要一个反驳论证。
5	渐进式披露	主 SKILL.md 是入口。支撑文件按需加载。
6	Token 意识	每个章节必须证明其存在的必要性。如果删除它不会改变 Agent 行为，就删除它。

描述字段的关键约束

Frontmatter 中的 description 字段不应包含流程步骤——如果描述中包含过程步骤，Agent 可能会看摘要而不读全文。描述应该只告诉 Agent “这个 Skill 提供什么”和”什么时候激活它”。

反合理化表设计

反合理化表是 Agent Skills 最独特的特征。每个 Skill 包含一个表格：

Rationalization	Reality
Agent 用来跳过步骤的借口	为什么这个借口是错的（事实性反驳）

典型示例：

“这个很简单，不需要规格” → “简单任务不需要长规格，但仍需要验收标准。两行规格也可以。”
“我会稍后补测试” → “Bug 会复合。Slice 1 的 Bug 让 Slice 2-5 都错。每片都测试。”
“一次性全部做更快” → “感觉更快，直到某处坏了而你找不到 500 行变更中哪行导致的。”

反合理化表与 Hard-Gate 的配合：表格是认知层面的防御（改变 Agent 的推理），Gate 是流程层面的防御（阻止进入下一阶段）。两者缺一不可。

验证的非协商性

每个 Skill 以 Verification 检查清单结束。“看起来对”永远不够——必须有证据（测试通过、构建输出、运行时数据）。这是 Agent Skills 区别于普通提示工程的核心设计。

文件引用规则

从 SKILL.md 到支撑文件的引用只深一层——直接从 SKILL.md 链接到 supporting files，不创建多层嵌套引用链。这确保了按需加载时的可预测性。

脚本与内联代码的取舍

当 Skill 需要可运行的辅助工具时，优先使用独立脚本（scripts/*.sh）而非内联代码：

脚本执行不消耗上下文（只有输出消耗）
脚本通过 /mnt/skills/user/{skill-name}/scripts/{script}.sh 路径引用
不含 runnable helpers 的 Skill 不应创建空的 scripts/ 目录

参考来源

Claude Code Skills 文档 — Skill 系统的官方规范
源码验证: OpenHands app_server/app_conversation/skill_loader.py — 集中式 Skill 加载实现

补充：Hermes Agent 的 Curator 自动归档与 Provenance 追踪

来源：Hermes Agent（NousResearch/hermes-agent）agent/curator.py、tools/skill_usage.py、tools/skill_provenance.py，commit 2517917

Curator 后台技能维护系统

Hermes 的 Curator 是一个后台自动维护系统，跟踪 Agent 自主创建的技能的使用情况并自动归档：

状态转换管线：

active → stale → archived

active：正常使用中的技能
stale：超过 stale_after_days 天未使用的 Agent 创建技能
archived：超过 archive_after_days 天仍未使用的技能，移至 ~/.hermes/skills/.archive/

关键不变量：

Curator 只处理 created_by: "agent" 的技能 — 内置和用户安装的技能不受影响
永远不会删除，最大破坏操作是归档
被 Pin 的技能不参与任何自动转换和 LLM 审查
归档的技能可随时通过 hermes curator restore 恢复

使用统计 Sidecar：~/.hermes/skills/.usage.json 跟踪每个技能的 use_count、view_count、patch_count、last_activity_at、state、pinned。

技能 Provenance（来源追踪）

tools/skill_provenance.py 使用 ContextVar 标记每次技能写入的来源：

created_by: "agent" — Agent 自主创建（Curator 可管理）
created_by: "human" — 人工编写（Curator 不碰）
后台审查线程运行在独立线程上，带有独立的 ContextVar，确保写入来源正确标记

可选技能分发（optional-skills/）

Hermes 有两层技能分发：

目录	默认加载	安装方式	内容
`skills/`	是	自动可用	核心技能（25 分类）
`optional-skills/`	否	`hermes skills install official/<cat>/<skill>`	重型/小众技能

这种区分避免了启动时加载过多技能描述导致模型注意力分散，同时保留了按需扩展的能力。

SKILL.md 硬性标准

Hermes 对技能文档有严格的写作标准（ enforced by CI）：

description ≤ 60 字符，一句话，以句号结尾
工具引用必须使用反引号标注 Hermes 工具名（如 `terminal`、`read_file`）
platforms: 门控必须与实际脚本导入一致
正文使用现代 section 顺序：标题 → 简介 → When to Use → Prerequisites → How to Run → Quick Reference → Procedure → Pitfalls → Verification

补充：CrewAI 的 Skills 注册表与三级渐进式披露

来源：CrewAI（crewAIInc/crewAI）lib/crewai/src/crewai/skills/，commit 77a6127

SKILL.md 标准与三级披露

CrewAI 的 Skill 系统基于 SKILL.md 文件标准，实现了三级渐进式披露：

级别	加载内容	触发方式
`METADATA=1`	仅元数据（name, description, license, compatibility, allowed_tools, version）	目录扫描发现
`INSTRUCTIONS=2`	包含指令内容（SKILL.md 正文）	`activate_skill()`
`RESOURCES=3`	包含资源文件（references/, examples/ 等）	`load_resources()`

与通用渐进式披露的差异：通用 Skill 系统（如 Claude Code）在触发时一次性加载 SKILL.md + 按需加载 references；CrewAI 将披露分为三个阶段，每个阶段明确可控。这使得 Agent 可以先了解有什么 Skill（METADATA），再决定是否需要加载指令（INSTRUCTIONS），最后才加载资源文件（RESOURCES）。

三级注册表解析

CrewAI 的 Skill 来源分三个层级：

1. 项目本地：./skills/{name}/SKILL.md
2. 全局缓存：~/.crewai/skills/{org}/{name}/SKILL.md
3. 远程 API：从 CrewAI+ API 下载

支持 @org/name 格式的注册表引用。解析顺序：本地 → 全局缓存 → 远程 API。

SkillNotCachedError：在 CI/非交互模式下，如果远程 Skill 尚未缓存到本地，会抛出此错误而非自动下载。这确保了生产环境的可重复性——不依赖外部 API 的可用性。

格式化为提示词

format_skill_context() 方法将 Skill 内容生成为 XML 包装的提示词注入：

<skill name="skill-name">
  <metadata>...</metadata>
  <instructions>...</instructions>
  <resources>...</resources>
</skill>

这种 XML 格式使得 LLM 可以清晰区分不同 Skill 的指令，减少多 Skill 同时激活时的指令混淆。

补充：Warp 的多 Provider 技能目录兼容

来源：Warp crates/ai/src/skills/skill_provider.rs，commit 94d29fe

Warp 实现了一个独特的多 Provider 技能目录兼容层，允许同一个 Skill 系统被 10 种不同的 AI 工具识别和加载：

// 伪代码：多 Provider 目录映射
static SKILL_PROVIDER_DEFINITIONS: &[SkillProviderDefinition] = &[
    SkillProvider { name: Agents,    path: ".agents/skills" },    // 标准兼容
    SkillProvider { name: Warp,      path: ".warp/skills" },      // Warp 自有
    SkillProvider { name: Claude,    path: ".claude/skills" },    // Claude Code 兼容
    SkillProvider { name: Codex,     path: ".codex/skills" },     // Codex 兼容
    SkillProvider { name: Cursor,    path: ".cursor/skills" },    // Cursor 兼容
    SkillProvider { name: Gemini,    path: ".gemini/skills" },    // Gemini 兼容
    SkillProvider { name: Copilot,   path: ".copilot/skills" },   // GitHub Copilot 兼容
    SkillProvider { name: Droid,     path: ".factory/skills" },   // Factory Droid
    SkillProvider { name: Github,    path: ".github/skills" },    // GitHub Skills
    SkillProvider { name: OpenCode,  path: ".opencode/skills" },  // OpenCode 兼容
];

三层 Scope：

Scope	路径	用途
`Home`	`~/.agents/skills`、`~/.claude/skills` 等	用户全局安装的 Skill
`Project`	`{repo}/.agents/skills`、`{repo}/.claude/skills` 等	项目特定的 Skill
`Bundled`	Warp 内置 Skill	随 Warp 分发的默认 Skill

优先级排序：定义在数组中的顺序即为优先级（Agents > Warp > Claude > Codex > …）。当同一 Skill 名在多个 Provider 目录下都存在时，优先级高的覆盖优先级低的。

与 Claude Code Skills 标准的兼容：Warp 识别 .claude/skills 目录和 SKILL.md 文件格式，同时使用 npx skills CLI 工具管理 Skill 的安装和更新（通过 skills-lock.json 锁文件确保版本一致性）。

设计优势：

零迁移成本：用户已有 Claude Code Skill 可以在 Warp 中直接使用，无需复制
统一体验：在 Warp 中编写的 Skill 也可以被其他工具识别
冲突处理：通过优先级排序自动解决同名冲突，而非报错

陷阱：script/bootstrap 会安装 skills-lock.json 中列出的 Skill。如果用户同时在项目级和全局级安装了同名 Skill，Warp 会报错并拒绝启动——这是一个安全设计，防止意外的 Skill 覆盖。锁文件还防止一个 checkout 的全局 Skill 被另一个 checkout 的不同锁版本静默覆盖。

补充：Oh-My-ClaudeCode 的三层技能注入模型

来源：Oh-My-ClaudeCode（Yeachan-Heo/oh-my-claudecode）skills/、hooks/hooks.json、docs/ARCHITECTURE.md，commit ed7800dd，版本 v4.14.4

公式化技能组合

OMC 引入了一种不同于传统渐进式披露的技能组合模型——公式化组合（Formulaic Composition）：

[Execution Skill] + [0-N Enhancement Skills] + [Optional Guarantee Skill]

层级	角色	示例	特性
Execution（执行层）	定义主工作流	`autopilot`、`team`、`ultrawork`、`default`	必选，每个任务有且仅有一个
Enhancement（增强层）	添加额外能力	`git-master`（自动提交）、`frontend-ui-ux`（UI 规范）	可选，0 到 N 个
Guarantee（保证层）	强制完成约束	`ralph`（不完成不停止）	可选，最多一个

示例：ultrawork: refactor API with proper commits

执行层：ultrawork（最大并行执行）
增强层：default（标准构建流程）+ git-master（原子化提交）
保证层：无

技能注入 vs 技能替换

传统 Skill 系统（如 Claude Code 原生 Skill）在被触发时替换主 Agent 的行为——Skill 的指令覆盖默认系统提示。

OMC 的技能注入模型则不同：技能叠加到现有 Agent 行为之上，不替换核心系统提示。这意味着：

原始系统提示 + Skill A 指令 + Skill B 指令 = 组合后的行为

优势：多个技能可以同时生效，各自贡献不同维度的指导。代价：技能间可能产生指令冲突，需要优先级排序（项目级 > 用户级）。

魔关键词驱动的隐式激活

OMC 的 keyword-detector Hook 在 UserPromptSubmit 事件上扫描用户输入，检测 14+ 魔关键词并自动激活对应 Skill：

关键词	激活 Skill	优先级
`cancelomc` / `stopomc`	cancel	最高（立即停止）
`ralph`	ralph	高（持久循环）
`autopilot`	autopilot	高（自主执行）
`ultrawork` / `ulw`	ultrawork	中（并行执行）
`ccg`	ccg	中（三模型协同）
`ralplan`	ralplan	中（共识规划）

关键词检测由 scripts/keyword-detector.mjs 在 Hook 中执行（5 秒超时），通过 <system-reminder> 标签注入激活指令。

技能作用域与优先级

目录	作用域	优先级
`.omc/skills/`	项目级	高（覆盖用户级）
`~/.omc/skills/`	用户级	低（回退）

项目级技能随 Git 仓库提交和共享，适合团队协作；用户级技能全局可用，适合个人工作流。

陷阱

技能冲突：两个 Enhancement Skill 可能给出矛盾的指令——优先级排序解决，但可能导致非预期行为
组合爆炸：3 个 Execution × N 个 Enhancement × 1 个 Guarantee = 可能的组合数随 N 线性增长
Hook 超时：关键词检测 Hook 只有 5 秒超时，复杂模式匹配可能超时失败
隐式触发不可见：用户可能不知道自己的输入触发了哪个 Skill，调试困难

补充：langchain4j-skills 企业级集成模式

来源：JeecgBoot v3.9.2，fillSkillsParams()、AiChatConfig、AIChatParams，commit 3f826c4

Skills 目录双路径配置

langchain4j 从 1.12.x 版本开始支持 Agent Skills 能力，企业级平台通常支持两类 Skills 目录：

目录类型	配置字段	内容	执行方式
`skillsDir`	标准 Skills	Markdown 格式技能定义	LLM 自主阅读和调用
`skillsShellDir`	Shell Skills	可执行脚本技能	通过 shell 命令执行

这种双路径设计让平台同时支持声明式技能（LLM 阅读后自主调用）和命令式技能（shell 脚本直接执行）。

运行时上下文自动注入

Skills 执行时需要运行时环境信息，企业级平台通过 skillsContext 字段自动注入：

以下信息由系统自动注入，Skill执行时可直接使用：
- **API_BASE**: `https://example.com/api`
- **X-Access-Token**: `eyJ...`
- **X-Tenant-Id**: `0`

安全设计：

Token 从当前 HTTP 请求提取，不写入配置文件
租户 ID 从请求头传递，确保多租户隔离
Skills 只能访问当前用户有权访问的 API

Skills 与业务工具共存

在企业级应用中，Skills 与平台内置工具（如用户管理、角色分配、数据查询）并行存在：

AIChatParams.tools = {
    // 内置业务工具（JeecgToolsProvider）
    "create_user": ...,
    "grant_user_roles": ...,

    // MCP 工具（McpToolProvider）
    "external_api_tool": ...,

    // Skills 工具（langchain4j-skills）
    "skill_1": ...,
    "skill_2": ...,
}

LLM 在响应时可自主选择合适的工具或 Skill，无需人工编排。

设计取舍

为什么用 Skills 而非 MCP？

Skills：人类可读的 Markdown 定义，适合描述复杂的多步骤操作指南
MCP：标准化的工具协议，适合简单的单步 API 调用
两者互补：MCP 处理标准工具，Skills 处理需要上下文理解的复杂操作

版本信息

📅 2026-05-24

参考来源

文档: Claude Code Skills

Skill 渐进式知识管理

Skill 渐进式知识管理

学习目标

核心概念

三层渐进式披露

触发短语设计

知识加载策略

写作标准

四层技能发现与优先级

运行时技能激活

自动技能提取

陷阱与对策

设计取舍

OpenHands 补充：集中式 Skill 加载与多层分发

补充：CLI-Anything 的 SKILL.md 自动生成与双路径分发

从 Click 装饰器自动提取元数据

Canonical vs Compatibility 双路径分发

REPL Banner 与 Skill 路径联动

补充：Agent Skills 的写作原则与反合理化设计

标准章节流模式

六条写作原则

描述字段的关键约束

反合理化表设计

验证的非协商性

文件引用规则

脚本与内联代码的取舍

参考来源

补充：Hermes Agent 的 Curator 自动归档与 Provenance 追踪

Curator 后台技能维护系统

技能 Provenance（来源追踪）

可选技能分发（optional-skills/）

SKILL.md 硬性标准

补充：CrewAI 的 Skills 注册表与三级渐进式披露

SKILL.md 标准与三级披露

三级注册表解析

格式化为提示词

补充：Warp 的多 Provider 技能目录兼容

补充：Oh-My-ClaudeCode 的三层技能注入模型

公式化技能组合

技能注入 vs 技能替换

魔关键词驱动的隐式激活

技能作用域与优先级

陷阱

补充：langchain4j-skills 企业级集成模式

Skills 目录双路径配置

运行时上下文自动注入

Skills 与业务工具共存

设计取舍

版本信息

标签

参考来源