技能与 MCP 服务器的分工：什么时候该用哪个

Q: 四、决策表：什么场景用哪个

直接对照这张表判断，不用凭感觉： 场景用技能用 MCP说明固化一套操作步骤 / 检查清单✅❌流程性知识，提示词即可编码团队规范、踩坑经验✅❌非结构化知识，无法函数化编排多个动作的顺序与分支✅可配合技能做调度，MCP 提供原子能力调外部系统（DB/Git/Issue）❌✅有状态、需鉴权，必须用服务需要严格参数/返回schema校验❌✅MCP 的契约天然强类型多技能、多会话共用同一能力❌✅服务化避免重

玩到一定阶段，你会同时遇到两个词：技能（Skill）和 MCP 服务器（Model Context Protocol Server）。它们都能给 agent 加能力，但定位完全不同。不少同学把两者混着用，要么用技能硬扛重逻辑，要么为每个小功能都起一个 MCP 服务，最后系统又慢又难维护，自己也被绕晕。

本篇帮你看清边界，并给你一张可以直接照着用的「该用哪个」决策表。这是「老周」踩过不少坑之后，最想让徒弟们早懂的一课。

一、两者的本质区别

先用一句话区分，记住这句就够了：

技能（Skill）是「教 agent 怎么想、怎么做」的说明书。它主要是一段提示词 + 可选的辅助脚本，解决的是「该调用什么、按什么步骤做」。
MCP 服务器是「agent 能调用的外部工具接口」。它跑在 agent 之外，通过标准协议暴露一组确定的能力（函数、资源、数据源），解决的是「agent 如何连上真实系统取数据、做动作」。

打个比方：技能像师傅带徒弟时的「操作手册」，告诉徒弟遇到这种情况先干啥后干啥；MCP 像车间里那台真实的机床，徒弟按手册操作，但真正车零件的是机床。两者不在一个层面。

# 技能：偏「方法与流程」
skill:
  name: release-helper
  description: 指导如何做发布：打 tag、跑测试、发通知
  contains: 提示词 + 少量 shell 脚本

# MCP：偏「能力接口」
mcp_server:
  name: gitlab-mcp
  exposes: [create_tag, run_pipeline, post_comment]
  transport: stdio / sse

翻车点：以为装了 MCP 就不需要技能。MCP 只提供「原子能力」，agent 不知道什么时候该调、调完怎么串。没有技能做编排，agent 拿到一堆工具也不会用，像给了机床却没给操作手册。两者是互补，不是替代。

二、技能擅长什么

技能适合承载「流程性、知识性、决策性」的内容，总结成四类：

把一套固定工作流固化下来：比如「发布前检查清单」「代码评审要点」。agent 照着做就行，不需要真去连什么系统。
编码领域知识：某业务系统的特殊约定、你们团队的命名规范、踩坑经验。这些没法当函数暴露，但写成提示词 agent 立刻懂。
编排多个能力：先调 A 再调 B，B 的结果决定要不要调 C。这种「if/then 编排」用技能表达最自然，这也是技能的核心价值。
轻量本地动作：用 scripts/ 里的脚本做文件处理、文本转换，不需要常驻服务，随用随跑。

简单说：凡是「告诉 agent 怎么思考、怎么决策」的，放技能。技能是 agent 的「脑子」。

三、MCP 擅长什么

MCP 适合承载「需要稳定、确定、可复用接口」的能力，也是四类：

对接外部系统：数据库、Git 平台、Jira、Slack、云厂商 API。这些有状态、有权限、有副作用，用常驻服务管最稳。
需要强类型契约：输入参数、返回结构必须严格校验，不能靠 agent「自由发挥」。MCP 的 schema 天然适合干这个。
多 agent / 多客户端共享：一个 MCP 服务可以被不同技能、不同会话复用，避免每个技能重复造轮子。
重逻辑或长连接：要维持连接、做鉴权、缓存结果，放服务里比放脚本里靠谱得多。

简单说：凡是「agent 需要调用的真实工具、真实连接」的，放 MCP。MCP 是 agent 的「手脚」。

四、决策表：什么场景用哪个

直接对照这张表判断，不用凭感觉：

场景	用技能	用 MCP	说明
固化一套操作步骤 / 检查清单	✅	❌	流程性知识，提示词即可
编码团队规范、踩坑经验	✅	❌	非结构化知识，无法函数化
编排多个动作的顺序与分支	✅	可配合	技能做调度，MCP 提供原子能力
调外部系统（DB/Git/Issue）	❌	✅	有状态、需鉴权，必须用服务
需要严格参数/返回schema校验	❌	✅	MCP 的契约天然强类型
多技能、多会话共用同一能力	❌	✅	服务化避免重复实现
本地小脚本做文本/文件处理	✅	❌	轻量，无需常驻
需要长连接 / 缓存 / 鉴权态	❌	✅	服务才扛得住

记忆口诀：技能管「脑」（怎么想、怎么做），MCP 管「手」（能干什么活）。脑和手都要，就两者配合。判断不了的时候，问自己一句：这件事是「知识/流程」还是「真实连接/工具」？前者技能，后者 MCP。

还要提醒一种灰色地带：有些能力既像知识又像工具。比如「查公司内网的一篇文档」，如果只是偶尔读一次、用脚本 curl 一下，技能里的 scripts/ 完全够用，没必要专门起 MCP；但如果这个读取要鉴权、要缓存、还要被五个技能共用，那显然该抽成 MCP。判断标准是「复用范围」和「连接复杂度」：复用少、连接简单，技能内脚本搞定；复用多、连接重，服务化。别为了用而用 MCP，也别为了省事硬把重逻辑塞进技能。

五、两者配合的典型架构

现实里大多是这样：技能负责编排，MCP 负责执行。举一个「自动发布」的例子，技能负责想清楚步骤，MCP 负责真正干活：

# 技能 release-helper 的 SKILL.md 里这样写：
# 1. 调用 gitlab-mcp 的 create_tag 打标签
# 2. 调用 gitlab-mcp 的 run_pipeline 跑流水线
# 3. 轮询 run_pipeline 状态，成功后用 slack-mcp 发通知
# 4. 任一步失败，按本技能的回滚约定处理

// openclaw.json：技能编排，MCP 提供能力
{
  "skills": { "release-helper": { "enabled": true } },
  "mcpServers": {
    "gitlab-mcp": { "command": "npx", "args": ["-y", "gitlab-mcp"], "env": { "GITLAB_TOKEN": "..." } },
    "slack-mcp":  { "command": "npx", "args": ["-y", "slack-mcp"],  "env": { "SLACK_TOKEN": "..." } }
  }
}

技能里只描述「调哪个 MCP 的哪个能力、什么时候调」，真正的连接、鉴权、协议细节全在 MCP 服务里。这样技能保持轻、MCP 保持稳，各司其职，改动也收敛在各自一处。

翻车点：在技能里用 scripts/ 直接 curl 调外部 API 并手写鉴权。一开始能跑，后来接口变了、token 轮换了，你得挨个改技能脚本。正确做法是这类能力服务化（MCP），技能只做编排，改动收敛在一个地方，风险也小。

这里也顺带澄清一个误解：技能里的 scripts/ 不是不能用，而是只适合「轻、临时、本地」的动作，比如读个本地配置文件、做个文本格式转换、拼一个临时请求。一旦这个动作要跨网络、要身份、要被别人复用，它就该「毕业」去当 MCP。把 scripts 当成技能内部的小帮手，把 MCP 当成团队共享的能力基座，边界就清晰了。

六、翻车点汇总

把几个常见坑一口气列出来，避坑就靠它们：

重复造轮子：每个技能里都写一遍「调 GitLab」的脚本。统一成 MCP，技能只引用，别到处复制。
用技能扛重逻辑：涉及鉴权、长连接、共享状态，硬塞进 scripts/ 会脆弱易崩。交给 MCP。
有 MCP 没技能：只暴露原子能力，agent 不知何时用、怎么串。配一个技能做编排与决策。
schema 不校验：MCP 能力若不严管输入输出，agent 传错参数时错误难定位。用强类型 schema 兜底。
密钥散落：MCP 的 token 走 env 注入，别写死在技能脚本里；密钥管理遵循之前讲过的 env/沙箱原则，避免泄露。

最后给一个落地建议：不要一上来就上 MCP。新人最容易犯的错是，连一个技能的提示词都没写顺，就急着起 MCP 服务、配 transport、折腾鉴权。正确路径是反过来的——先用技能把流程和知识固化下来，跑通了；等你发现某个能力要被多个技能复用、或者要连真实外部系统时，再把它抽成 MCP。从技能起步，按需服务化，系统才不会一开始就过度设计、尾大不掉。

一句话收尾：技能是 agent 的「脑子」和「流程」，MCP 是 agent 的「手脚」和「真实连接」。脑子想清楚、手脚接稳系统，两者配合，你的 agent 才算真正能干活，而不是只会纸上谈兵。先把技能写顺，再按需服务化，这条渐进路线能让你少走很多弯路。