三者的本质定位
| 机制 | 本质 | 生命周期 | 谁来写 |
|---|---|---|---|
| Skill | 静态知识 + 工作流说明 | 与 Session 同生 | 领域专家 |
| MCP Server | 对外部动态系统的 RPC 协议 | 独立进程,长期运行 | 平台 / 基础设施团队 |
| Tool | 原子可调用操作 | 单次调用 | Skill / MCP 开发者 |
一句话:Skill 告诉 Claude 怎么思考、MCP 让 Claude 触达系统、Tool 是执行动作。
场景对比:查公司财务健康度
方案 A: 只用 Tool
Tool: get_stock_data(ticker) -> {...}
用户: "苹果的财务怎么样?"
Claude: 调 get_stock_data("AAPL") → 拿到 50 个字段 →
自己琢磨怎么评价 → 给出不稳定的结论
问题:Claude 每次自己"琢磨"分析方法,前后不一致;没有公司统一的评分标准。
方案 B: 只用 Skill
Skill: sec-10k-analyzer(含评分规则 + 行业调整)
用户: "苹果的财务怎么样?"
Claude: 激活 Skill → 按工作流走 → 发现要最新数据,
但 Skill 里没访问金融数据的方式 → 跑偏
问题:Skill 知道怎么分析,但拿不到数据。
方案 C: Skill + MCP + Tool 协作(正确)
Skill: sec-10k-analyzer ← 分析方法、评分规则
MCP Server: finance-data ← 实时股价、历史财报
Tool: bash ← 执行 Skill 的脚本
用户: "苹果的财务怎么样?"
Claude 流程:
1. 激活 sec-10k-analyzer Skill
2. 读 SKILL.md 工作流,知道需要 10-K 数据
3. 调用 finance-data MCP 的 get_10k("AAPL") 拿到数据
4. 调用 bash 运行 scripts/score.py 算评分
5. 读 references/banking-adjustments.md 处理行业特殊性
6. 返回结构化报告
每层各司其职:Skill 是"怎么做的剧本",MCP 是"数据的管道",Tool 是"手和脚"。
边界判断:三个问题
问题 1:这件事的信息是静态的还是动态的?
静态(API 规范、业务口径、评分规则)→ Skill 的 references。动态(实时股价、当前订单状态)→ MCP。
问题 2:这是一个原子动作还是一套流程?
原子(查一次、改一字段)→ Tool 或 MCP endpoint。流程(多步、决策、交付物)→ Skill。
问题 3:谁拥有这个能力的版本控制?
业务团队(财务、营销、法务)→ Skill(他们熟悉 markdown)。平台团队(数据、基础设施)→ MCP(他们写服务)。
一个 Agent 架构示意
┌──────────────────────┐
│ Claude API Request │
│ │
│ skills = [...] │ ← Anthropic 托管静态能力
│ mcp_servers = [...] │ ← 长连接到外部服务
│ tools = [bash, ...] │ ← 原子能力
│ messages = [...] │
└────────────┬─────────┘
│
┌────────────▼─────────┐
│ Claude │
│ (Opus 4.7 / Sonnet) │
└─┬───────┬──────┬─────┘
│ │ │
┌──────────┘ │ └──────────┐
▼ ▼ ▼
[Skill 激活] [MCP 调用] [Tool 调用]
SKILL.md finance_data. bash(script.py)
references/ get_10k(AAPL) str_replace
scripts/
典型组合拆解
组合 1: Skill + Bash Tool
最常见。Skill 的 scripts/ 跑业务逻辑,Bash 执行。不需要 MCP 就能端到端。
例子:PDF 表单填写(第 2 章)——纯本地,Skill + Bash 足够。
组合 2: Skill + MCP + Bash
需要接公司内部系统。Skill 告诉 Claude 怎么用数据,MCP 提供数据通道。
例子:内部工单智能指派——
- Skill 写"指派规则"(哪类工单给哪组)
- MCP 对接 Jira / 工单系统
- Bash 处理附件下载 / 归档
组合 3: 多 Skill 协同
复杂任务拆给多个 Skill。SKILL.md 可以直接引用其他 Skill 名。
## 工作流
1. 识别客户行业 → 调用 industry-classifier skill
2. 按行业分析财务 → 调用 sec-10k-analyzer skill
3. 生成报告 → 调用 report-writer skill
Claude 会依次激活引用的 Skill,像调用子程序。
Skill 要不要取代 MCP?
有人问:"我可以把 MCP Server 的能力全写成 Skill 脚本吗?"
可以,但通常不应该:
Skill 每次要带走一份数据快照
MCP 是实时 RPC,Skill 脚本每次重新建连、认证、处理——频繁调用成本高。
Skill 难做流式 / 长连接
MCP 支持 streaming、subscription。Skill 脚本是 request-response。
MCP 可以被多个 Skill / Agent 共用
一个
finance-data MCP,既给 sec-10k-analyzer Skill 用,也给 portfolio-tracker Skill 用,还给 slack bot 用。反向问:"我可以把 Skill 的 references 挪到 MCP 里吗?"
也不应该——静态规范放 Skill 的 references,是为了 Claude 能 grep,渐进加载。塞进 MCP 意味着每次要 RPC 去取,慢且无法被 grep。
调度权:Skill 指挥 Tool,还是 Claude 直接调 Tool?
SKILL.md 里明确调用链,比让 Claude"自由发挥"可靠得多:
## 工作流
1. 一定先调用 `finance-data.get_10k(ticker)` 获取最新 10-K
2. 一定不要直接用 web_search 找 10-K,数据不权威
3. 如果 10-K 缺失,才用 web_search 找 SEC EDGAR 链接
Claude 会按你给的优先级决策,而不是随机选最顺手的工具。
安全与权限
Skill / MCP / Tool 各自的权限模型:
| 机制 | 权限控制 |
|---|---|
| Skill | allowed-tools frontmatter 限定可用工具;启用 Skill 需要用户或 API 显式加载 |
| MCP | MCP Server 本身的 auth(OAuth / token);连接时需要白名单 |
| Tool | API 请求里 tools 字段显式声明;Bash 有 allow-list / deny-list 配置 |
企业部署时,三层配合做权限最小化:敏感数据走 MCP(可审计 RPC 日志)、操作用 Skill(工作流可 review)、Bash 做 deny-list(不许 rm -rf)。
本章小结
- Skill = 静态知识 + 工作流剧本(业务专家写)
- MCP = 对外部动态系统的 RPC 协议(平台团队写)
- Tool = 原子可执行操作(bash / editor / str_replace)
- 三者协作:Skill 指挥,MCP 取数,Tool 执行
- 边界判断:静态 vs 动态 / 原子 vs 流程 / 谁拥有版本
- SKILL.md 明确调度顺序,不要指望 Claude"随便选"