Appearance
🐣 小a的进阶想法
学了 MCP,小a又想到:"工具是单点能力,那如果我想让 Agent 会一套完整的工作流(比如'写代码前先建分支、再改、再测'),是不是有比单个工具更高级的东西?"
老z:"有。它叫 Skill——比 Tool 更高一层的'能力打包'。 这一章我们讲它。"
11.1 Skill 是什么:一门"手艺"
🧙 Skill(技能)是比单个 Tool 更高一层的能力单元。它不是"一个函数",而是一组东西打包在一起:
- 提示词(instructions):告诉模型"用这个技能时该怎么做"
- 工具/资源:技能需要的具体能力
- 知识:这个技能领域的经验/规则
老z打比方:
- Tool 是一把螺丝刀(单个工具)
- Skill 是"换轮胎"这门手艺(包含几把工具 + 操作步骤 + 经验知识)
🐣 小a:"所以 Skill = 一组工具 + 说明书?"
🧙 "对。 但不止——它还包含'知识'(什么情况用什么工具、按什么顺序做)。Skill 是 Agent 的'职业培训':让它会做一类完整的事。"
11.2 Tool vs Skill:粒度对比
| Tool | Skill | |
|---|---|---|
| 是什么 | 单个可调用的函数 | 一组打包的能力 |
| 粒度 | 单点动作 | 一套流程 |
| 例子 | read(读文件) | "写代码"(读→改→测→验证) |
| 含什么 | 名字+描述+schema+执行 | 工具+提示词+知识 |
🧙 关系:Skill 是 Tool 的"组合拳"。 一个 Skill 内部通常调用多个 Tool,并按一定顺序组织。
11.3 Skill 为什么用 markdown 是好设计
🧙 很多 Skill 体系(如 pi)用 markdown 文件实现技能,这个设计很妙:
为什么 markdown?
- 人能读:打开技能文件,直接看懂这个技能是干嘛的
- 模型也能读:模型本身就是吃文字的,markdown 对它天然友好
- 门槛极低:不用学编程,会写文档就能加技能
- 可版本管理:markdown 是纯文本,能用 git 管理、diff、review
- 可分享:一个 .md 文件,发给同事就能用
🐣 小a感叹:"原来扩展 agent 不一定要写代码——写好一份说明书,模型照着做,就是技能了。"
🧙 "对。这是大模型时代的新玩法:以前扩展软件要编程,现在扩展 agent 可以'写文档'。"
11.4 Skill 长什么样(示意)
💡 一份技能文件的结构(示意,非真实):
markdown
---
name: add-llm-provider
description: 教 Agent 如何添加一个新的大模型厂商支持
---
# 添加 LLM 提供方
当你需要支持一个新厂商时,按以下步骤:
1. 查看现有 providers 目录,找最接近的模板
2. 复制并修改:baseUrl、auth、models
3. 注册到 all.ts
4. 跑测试验证🧙 注意 frontmatter 里的
name和description——它们是技能的"目录项",让 Agent 知道"有什么技能、什么时候该用"。
11.5 Skill vs Tool vs MCP:三者关系
| 是什么 | 粒度 | 谁定义 | 标准化 | |
|---|---|---|---|---|
| Tool | 一个可调用的函数 | 单个动作 | 框架内置/开发者 | 各框架不同 |
| Skill | 工具+提示词+知识打包 | 一门"手艺" | 用户写 markdown | pi 自己的体系 |
| MCP(第 10 章) | 工具/资源的统一协议 | 接口标准 | 行业标准 | 跨框架通用 |
一句话:
- Tool = 一把工具(单点能力)
- Skill = 一套手艺(打包的能力)
- MCP = 工具的 USB 标准(让工具能跨框架共享)
11.6 扩展的完整生态
🧙 Skill 只是扩展体系的一环。完整看,从"轻"到"重":
| 扩展方式 | 形式 | 门槛 | 适合 |
|---|---|---|---|
| Prompt 模板 | markdown | 极低(写文字) | 复用的提示词片段 |
| Skill | markdown + frontmatter | 低(写文字) | 一套操作流程/手艺 |
| Extension | 代码(TS) | 高(写代码) | 需要编程逻辑的扩展 |
🧙 看出设计哲学了吗?
- 简单需求 → 写个 markdown(prompt/skill),不碰代码
- 复杂需求 → 写代码(extension)
门槛分层,让不同需求的用户都能扩展。 这是"自扩展 Agent"的核心——Agent 不只是给你用,它让你能改、能加、能定制。
11.7 Skill 怎么被"想"起来:触发、加载与局限
"聊了半天 Skill 长什么样,"小a问,"那它什么时候起作用?模型怎么知道有这门手艺、该不该用?"
🧙 触发与加载,分两步:
第一步:扫描目录,知道"有什么"
Agent 启动(或新任务开始时)扫描技能目录,读取每个技能的
frontmatter(name + description)——相当于翻了一遍"技能清单",知道有哪些手艺、各自是干嘛的。第二步:按需加载,拼进提示词
当任务与某个技能的 description 匹配(或用户点名),Agent 就把这份技能 markdown 拼进 System Prompt(第 4 章的动态拼装!)——模型"看到"了这份说明书,就知道"这个任务我该按这套流程干"。
任务进来 → 查技能清单(description)→ 命中"code-review"技能 → 把技能 md 拼进 System Prompt → 模型按技能步骤干活(并调用技能声明的工具)
🐣 小a:"所以 Skill 的本质,是动态加载的 System Prompt + 工具组合?"
🧙 "对! 它和 4.4 的'System Prompt = 基础人设+工具+项目+偏好'完全打通了——Skill 就是给这个动态拼装加了一档'按需加载的能力包'。不用的技能不进 prompt(省 token、省缓存),用到的技能才拼进去。
Skill 的局限:它是"说明书",不是"强制命令"
⚠️ 诚实地说,Skill 有一个软肋:
- Skill 本质是提示词——它告诉模型"该这么做",但模型可以不听(可能跳过步骤、擅自简化)
- 它没有强约束:不写代码、不改 schema,就锁不死模型的行为
对比:
- 需要"建议性流程"(最佳实践、操作规范)→ Skill 足够
- 需要"必须执行,不许跳过"(比如危险操作必须先确认)→ 必须靠代码强制(工具校验、Hook 拦截,第 9 章)
所以扩展体系是分层的:prompt/skill 负责"教",extension/工具负责"管"。该用软约束(提示)还是硬约束(代码),是设计者要做的判断。
本章小结
🐣 小a的手艺课
┌──────── Skill ────────┐ │ │ │ • Skill = 打包的手艺 │ │ 工具+提示词+知识 │ │ │ │ • Tool 是螺丝刀, │ │ Skill 是换轮胎的手艺│ │ │ │ • markdown 技能: │ │ 人读/模型读/门槛低 │ │ /可版本/可分享 │ │ │ │ • 扩展三件套: │ │ prompt/skill/ │ │ extension(门槛递增) │ │ │ │ • 触发:扫目录→按需拼 │ │ 进 System Prompt │ │ │ │ • 局限:软约束(建议) │ │ → 必须执行的用代码 │ └────────────────────────┘
关键认知:Skill 是比 Tool 高一层的"能力打包"——一组工具+提示词+知识。用 markdown 实现让扩展门槛降到"会写文档"。它是"按需加载的动态 System Prompt",但本质是软约束(建议),必须执行的逻辑要靠代码强制。这是 Agent 自扩展的核心机制。
课后实验
- 读一个真实 skill:找 pi 或 Claude Code 的技能文件,读它的 frontmatter 和正文,看"手艺"怎么写的。
- 设计一个 skill:为你的 Agent 设计一个技能(如"代码 review"),列出它的工具、提示词、步骤。
- 对比扩展方式:一个能力该用 prompt/skill/extension 哪个?为什么?
- 体验触发:观察你用的 agent,故意抛一个"正好命中某技能描述"的任务,看它是否主动加载了那套流程。
- 找软约束边界:设计一个"必须执行"的步骤(如"发布前先跑全量测试"),试想如果只写在 skill 里,模型会不会跳过?该用哪种硬约束兜底?
下一章:一只小a忙不过来了——要不要养一群?多 Agent 的江湖,水有多深? → 第 12 章 · 多 Agent 的江湖