Skills + MCP 分层组合：Skill 在上编排、MCP 在下连接

你已经会接 MCP server 给 Agent 连接，也写过 Skill 教它做事。但真到了"让 Agent 帮我审 PR"这种活，你会发现单靠哪一个都不够：只接 GitHub 的 MCP，Agent 能读 PR 却不知道"按你团队的规范该怎么审"；只写审 PR 的 Skill，方法再好它也读不到 PR 里的代码。成熟的打法是两层叠加：MCP 在下给连接，Skill 在上做编排。 这一节用一个完整的"审 PR"例子，把这套分层走通。

这篇适合谁：已经分清了 Skills 和 MCP 各干什么、也都单独用过，现在想知道"怎么把它俩组合成一套真正能干活的方案"的人。读完你能设计自己的 Skill+MCP 组合。

---

先把两层的职责钉死

复习一句你早该刻在脑子里的话：MCP 给访问，Skills 教用法。 把它放进分层视角，就是：

• 连接层（MCP，在下）：负责"够得着"。给 Agent 接上外部系统的管子——能读 GitHub 的 PR、能查数据库、能调内部 API。它只管提供访问能力，不管"该怎么用这些访问干活"。
• 编排层（Skill，在上）：负责"会做事"。教 Agent 按你的规范、按一套流程，把下层那些访问能力组织起来完成一件具体的活。它只管方法和流程，不亲自去连任何系统。

两层一上一下，各管一段，谁也不越界。下面这张图把职责切清楚：

┌─────────────────────────────────────────────┐
│  编排层 · Skill（在上：教"按规范怎么干")        │
│  - 一套审 PR 的流程与标准（步骤、清单、口径)    │
│  - 调用下层的访问能力，按顺序把活走完           │
│  - 不写死"怎么连 GitHub"，只说"去读 PR 内容"    │
└───────────────────┬─────────────────────────┘
                    │ 调用（向下要数据/动作)
┌───────────────────▼─────────────────────────┐
│  连接层 · MCP（在下：给"能访问"的能力)          │
│  - GitHub MCP server：读 PR、读 diff、发评论    │
│  - 只管连得上、给得到数据，不管审查标准         │
└─────────────────────────────────────────────┘

记住这张图，剩下全是它的展开。

---

一个完整实例：MCP 给 GitHub 访问 + 审 PR Skill 编排

把"让 Agent 帮我审 PR"这件事拆到两层，看它怎么协作。

下层：GitHub MCP server 给访问

你接一个 GitHub 的 MCP server（现成的就有），它给 Agent 这几样访问能力：

• 读某个 PR 的元信息（标题、描述、改了哪些文件）。
• 读 PR 的 diff（具体改动的代码）。
• 在 PR 上发表评论 / 提交 review。

注意：这一层只提供"能读能写 GitHub"，完全不包含"什么是好 PR、该怎么审"。它是一根中性的管子。

上层：审 PR Skill 做编排

你写一个 SKILL.md，它不连任何系统，只写"按我们团队的规范，怎么一步步审一个 PR"。骨架像这样（触发字段与具体写法以 agentskills.io 标准 / 你客户端文档为准）：

---
name: review-pr
description: 当用户要求审查一个 GitHub PR 时使用。按团队规范走完一次完整 PR review。
---

# 审 PR 的流程

收到一个 PR 链接或编号后，按以下步骤做：

1. **拉取信息**：读这个 PR 的标题、描述和改动文件清单，读它的 diff。
   （用下层 GitHub 连接提供的读取能力，别在这写死怎么连)
2. **按清单审查**，逐条对照团队规范：
   - 有没有对应的测试？改了逻辑没补测试要指出。
   - 有没有硬编码密钥 / 调试代码残留？
   - 命名、错误处理是否符合我们的约定？
   - 改动是否超出 PR 描述的范围（夹带）？
3. **分级输出**：把问题分成"必须改 / 建议改 / 可选"三档，每条给出文件和行号。
4. **回写**：把审查结论作为评论发到 PR 上，必须改的项要明确标出。

两层怎么协作

Agent 接到"审一下 #128 这个 PR"时，发生的事是这样的：

1. 编排层（Skill）被触发：description 命中"审 PR"，Agent 加载这套流程。
2. 流程指挥 Agent 调用连接层：走到第 1 步"拉取信息"，Agent 就去调下层 GitHub MCP 的读取工具，把 PR 内容拿回来。
3. 编排层用拿回的数据按规范审：第 2、3 步是纯方法——对照清单、分级，不碰任何外部系统。
4. 再次下探连接层回写：第 4 步要发评论，Agent 又去调 GitHub MCP 的"发评论"工具，把结论写回 PR。

看清楚这个来回：Skill 是总指挥（按规范决定每一步做什么），MCP 是它伸出去的手（具体去 GitHub 拿数据、写评论）。 缺了 Skill，Agent 有手没章法；缺了 MCP，Agent 有章法够不着 PR。

---

为什么要分层：三个实打实的好处

不嫌麻烦地分两层，换来的是这三样：

• 各管一段，单一职责：MCP server 只操心"怎么稳定地连 GitHub"，Skill 只操心"怎么审才符合规范"。改审查标准时你只动 Skill，碰都不用碰 MCP；GitHub 接口变了你只修 MCP，审查流程纹丝不动。
• 可替换：哪天你从 GitHub 换到 GitLab，底层换一个 MCP server 就行，上层那套审 PR 的 Skill 几乎不用动——因为 Skill 写的是"读 PR、按清单审、回写评论"，没写死"GitHub 的接口长啥样"。
• 可移植：Skill 遵循开放标准，这套"审 PR"的方法可以分给团队任何人、配上各自的 GitHub 连接就能用。方法（Skill）和连接（MCP）解耦，各自都能复用。

一句话：分层就是把"会做事"和"连得上"解耦，各自能独立替换和复用。 这是它比"一锅烩"强的根本。

---

Skill+MCP 分层设计图（设计你自己的组合）

要给自己的活设计一套 Skill+MCP 组合，按这个分工去填两层：

你要让 Agent 干的活：________（比如"按规范处理客诉工单")

┌── 编排层 Skill：写"按什么流程/规范干" ──────────┐
│  - 这件活分几步？每步的标准/口径是什么？        │
│  - 哪几步需要去外部系统拿数据或做动作？         │
│  - 输出长什么样、要回写到哪？                   │
│  ✗ 不写"怎么连系统"的任何细节                   │
└──────────────────┬──────────────────────────┘
                   │ 向下索取访问能力
┌──────────────────▼──────────────────────────┐
│── 连接层 MCP：把"要够得着的系统"接上 ──────────│
│  - 这活要读/写哪些外部系统？（工单库、CRM…)     │
│  - 接现成 server 还是自己写一个薄包装？         │
│  - 工具守 3-10 个、结构化错误、传输层鉴权        │
│  ✗ 不写"审查/处理标准"这类业务规范              │
└─────────────────────────────────────────────┘

设计口诀：先把活拆成"方法步骤"写进 Skill，凡是步骤里出现"去读/去写某系统"的地方，就对应到下层一个 MCP 能力。 方法归 Skill，访问归 MCP，泾渭分明。

---

避坑表

坑	后果	怎么破
全堆 MCP，没有编排层	Agent 有一堆访问能力却不知按什么规范干活，做得乱、不符合团队标准	上面补一层 Skill，把流程和标准写清楚
Skill 里写死连接细节（接口、字段、鉴权）	系统一变 Skill 就失效；换平台得重写 Skill	Skill 只写"去读 PR/去发评论"这类意图，连接细节全交给下层 MCP
把审查标准写进 MCP server	改规范要改 server 代码、还得重部署，可移植性没了	标准/方法属于编排层，留在 Skill 里，MCP 保持中性
两层职责混着写	改一处牵动另一处，可替换性丧失	守住分工：MCP 只管"连得上"，Skill 只管"会做事"
以为分层就是把一件事拆复杂	简单活也硬上两层，过度设计	真要外部访问才上 MCP；纯方法类的活一个 Skill 就够，别为分层而分层

---

动手挑战

1. 挑一件你常让 Agent 干、又需要读写某个外部系统的活（审 PR、处理工单、整理某个库的数据都行）。先把它拆成"方法步骤"写进一个 SKILL.md，凡是步骤里"要去拿数据/做动作"的地方先用文字标出来——这就是你下层 MCP 要提供的能力清单。
2. 给上一题接上对应的 MCP（现成的或自己写的薄包装），让 Skill 在执行到"拿数据"那步时真的调到下层。跑一遍完整流程，确认两层确实在协作。
3. 做一次"可替换性测试"：假设你要把底层系统换一家（GitHub→GitLab、工单系统 A→B），看看你的 Skill 需不需要改。如果要大改，说明你把连接细节漏写进 Skill 了——回去把它清干净。

---

小结 · 你现在掌握了什么

• 你看懂了成熟打法是两层叠加：MCP 在下给连接（够得着）、Skill 在上做编排（会做事），各管一段。
• 你跟着一个完整实例走通了协作：审 PR Skill 当总指挥按规范决定每步，GitHub MCP 当手去读 PR、回写评论——缺哪层都不成。
• 你知道分层换来的三个好处：单一职责、可替换（换底层系统不动上层方法）、可移植。
• 你有了一张分层设计图和口诀：方法步骤归 Skill，凡是"去读/写某系统"就对应下层一个 MCP 能力。
• 你能避开两个最常见的坑：全堆 MCP 没编排层、Skill 写死连接细节。

这是这一级（Skills 与 MCP）的收尾。从分清两者，到接/写 server、设计 server，再到这节的分层组合，你已经能给 Agent 搭出一套"既够得着、又会做事"的扩展体系。

下一步：往后是记忆、多 Agent 协作与编排。看 AI Agent 智能体阶梯 的后段；想看整条路的位置就对照 三支柱路线图。

👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。