------理解 Agent 的"技能树"如何工作---
一、Skills 是什么：一个精准定义
Skills 是 Claude Code 的可插拔能力扩展模块。
用一个比喻：
· 模型 = 大脑（通用推理引擎）
· Agent = 指挥官（决策与执行循环）
· Skills = 技能包（特定领域的知识、流程、工具组合）
每个 Skill 本质上是一个结构化的指令集，它告诉 Agent："当你遇到某类任务时，应该按照这个流程、使用这些工具、遵循这些规范来做。"
二、Skills 在系统里的定位：三层架构的中间层
Claude Code 的完整架构是：
```
┌─────────────────────────────────┐
│ Agent 层 │
│ 规划、调度、执行循环、安全控制 │
├─────────────────────────────────┤
│ Skills 层 │
│ 专项能力模块（可插拔、可组合） │
├─────────────────────────────────┤
│ 模型 层 │
│ 通用推理、代码生成、理解 │
└─────────────────────────────────┘
```
Skills 是夹在 Agent 和模型之间的"能力加速器"：
· 没有 Skill：Agent 接到任务 → 用模型通用能力推理 → 执行。能做，但遇到特定领域可能不够专业。
· 有 Skill：Agent 接到任务 → 匹配到相关 Skill → 加载 Skill 的指令和流程 → 模型在 Skill 的框架内推理 → 执行。结果更专业、更一致。
三、Skills 不是什么：澄清边界
Skills 不是：
· 另一个 Agent
· 独立运行的程序
· 替代模型的推理
· 能绕过安全机制的后门
Skills 只是：
· 一套结构化的提示词 + 工具配置
· 被 Agent 加载后，注入到模型上下文中
· 告诉模型"在这种场景下，你应该这样做"
它们没有自己的执行循环，没有独立的工具权限，完全依赖 Agent 调用。
四、Skills 的类型：两类加载模式
- 自动匹配型 Skill
· 定义时声明了触发条件
· Agent 执行任务时，会自动扫描已安装的 Skill，匹配到相关的就加载
· 例如：一个"React 最佳实践" Skill，当 Agent 检测到你在写 React 代码时自动激活
- 手动调用型 Skill
· 需要用户显式调用
· 适合一些不是每时每刻都需要、但特定场景很好用的能力
· 例如："生成周报"、"代码审查报告"、"转换成中文注释"
五、Agent 什么时候读取 Skill：加载时机全链路
这是最关键的问题。Skill 的加载不是一个简单的"启动时读一下"，而是一个多阶段、动态匹配的过程：
阶段一：启动时（索引建立）
Agent 启动时，扫描所有已安装的 Skill，建立索引：
· 每个 Skill 的名称、描述、触发条件、适用场景
· 不会加载完整内容，只是建立目录
阶段二：任务接收时（意图匹配）
你下达任务后，Agent 在规划开始前，做一轮匹配：
· 分析任务意图
· 扫描索引中哪些 Skill 的触发条件匹配当前任务
· 将匹配到的 Skill 完整加载到上下文
这是 Skill 最主要、最核心的加载时机。
阶段三：执行中途（动态补充）
Agent 在执行过程中，如果遇到新的子任务，会再次扫描：
· 当前子任务需要什么能力？
· 有没有之前没加载但突然相关的 Skill？
· 有就补充加载
阶段四：出错或切换时（重新匹配）
如果执行出错、方向调整、或你给了新指令，Agent 会：
· 重新评估当前需要什么 Skill
· 卸载不再需要的，加载新匹配的
六、一个完整的加载时序图
```
你：帮我把这个项目重构成 TypeScript
┌─ 阶段一：Agent 接收指令
│ ├─ 分析意图：这是一个"迁移重构"类任务
│ └─ 扫描 Skill 索引
│ ├─ 匹配到 "TypeScript 迁移规范" Skill → 加载
│ ├─ 匹配到 "代码风格检查" Skill → 加载
│ └─ 没匹配到 "React 最佳实践" → 不加载
│
├─ 阶段二：Agent 开始规划
│ ├─ 规划子任务：1.分析项目 2.逐文件迁移 3.跑测试
│ └─ 所有子任务都在已加载 Skill 的框架内生成
│
├─ 阶段三：执行第一个子任务"分析项目"
│ ├─ 发现项目中用到了 GraphQL
│ └─ 动态扫描 → 匹配到 "GraphQL 类型生成" Skill → 补充加载
│
├─ 阶段四：执行到一半，测试报错
│ ├─ 报错与类型相关
│ ├─ 重新扫描 → 匹配到 "常见 TS 错误修复" Skill → 加载
│ └─ 在 Skill 指导下修复
│
└─ 任务完成，所有 Skill 保持在上下文中直到会话结束
```
七、Skills 的优先级和冲突处理
当多个 Skill 同时匹配时，Agent 的处理逻辑：
-
优先级声明：Skill 可以声明自己的优先级（高/中/低）
-
手动覆盖：你可以在指令中明确指定用哪个 Skill
-
冲突检测：如果两个 Skill 对同一操作有矛盾指令，Agent 会暂停并询问你选择哪个
-
上下文窗口管理：如果加载太多 Skill 导致上下文不够，Agent 会按优先级裁剪，低优先级的先卸载
八、Skills 与 MCP 的关系
这俩经常被混淆，澄清一下：
Skills MCP 服务器
本质 结构化指令集（提示词 + 流程） 外部工具连接器
作用 告诉 Agent "怎么做" 给 Agent 提供"新工具"
举例 "生成代码时要加中文注释" 连接数据库、浏览器、Jira
输出 影响模型的推理方式 提供新的工具调用接口
关系 可以引用 MCP 工具 独立运行，被 Agent 调用
一个 Skill 里可以调用 MCP 工具。比如一个"自动发周报" Skill，内部可能调用 Jira MCP 拉任务，再用 GitHub MCP 拉提交记录，然后生成报告。
九、Skills 的设计原则
Anthropic 在 Skills 系统上遵循了几个原则：
-
无侵入：Skill 不修改 Agent 的核心循环，只是注入上下文
-
可组合：多个 Skill 可以同时生效，像叠加 buff
-
声明式：Skill 声明"什么场景该做什么"，不写具体的执行代码
-
用户可控：你可以随时查看、禁用、删除 Skill
-
安全边界：Skill 不能绕过 Agent 的权限系统，操作仍需用户确认
十、什么时候该写一个 Skill
不是所有重复性任务都值得写成 Skill。一个好的 Skill 满足：
· 场景明确：有清晰的触发条件
· 高频重复：你经常做同类任务
· 流程固定：步骤和方法相对标准化
· 需要一致性：你希望每次执行结果风格统一
适合写 Skill 的例子：
· 公司代码规范（命名、注释风格、文件结构）
· 特定框架的最佳实践（Next.js、FastAPI）
· 常见问题修复流程（TypeScript 类型报错诊断）
· 自动化工作流（生成 CHANGELOG、代码审查清单）
不适合写 Skill 的例子：
· 一次性任务
· 高度依赖判断力、无法标准化的事
· 极短的一句话指令就能完成的事
十一、总结：Skills 在整个系统里的位置
```
用户指令
↓
Agent 接收 ──→ 扫描 Skill 索引（匹配）
↓
加载匹配的 Skill（注入指令框架）
↓
Agent 在 Skill 框架内规划子任务
↓
调用模型推理（受到 Skill 约束）
↓
调用工具执行
↓
观察结果，需要时补充加载新 Skill
↓
完成
```
一句话定位：Skills 是 Agent 的"专业技能培训教材"，不是另一个大脑，也不是另一个执行者。它让通用模型在特定场景下表现得更专业、更一致。
如果你想了解如何写一个自定义 Skill，或者想看一些社区里好用的 Skill 推荐，我可以继续展开。