别再混了！Proompt、MCP、Skills到底区别在哪

别怪自己记不住，是这些词真的太像了

使用Claude code和Codex这样工具的时候，最容易被一套“看起来都能让模型更能干”的名词暴击：Prompt、Custom Commands、MCP、Agent、Subagent……最近又多了个 Skills。

然后就开始怀疑人生：我到底该写 Prompt，还是该搞 Skills？接外部系统是不是就叫 Agent？Subagent 又是啥时候用？

那种“一个词没搞清楚，架构就越写越乱”的感觉，我太懂了。那个报错红框弹出来的时候，心态真的容易崩。

今天我们换个更省脑子的视角：不按“厂商怎么叫”，按“它到底解决哪类问题”来拆。你会发现它们其实各司其职，组合起来反而很顺。

1. Prompt：我们最常用的"临时指令"，但它天生不稳定

Prompt 的优点就一个字：快。今天要它解释一段代码、写个 SQL、总结个文档，直接开聊就行。

但 Prompt 的痛点也很直白：同一个问题你问 5 次，它可能给你 5 种风格；团队里每个人各写各的 Prompt，输出就更像在抽盲盒——完全看运气。

使用最顺手的方法是：当成一次性的"即时指令"。

举个例子：现在离春节还有点时间，你和好朋友准备去北京三日游，想用 AI 辅助做攻略。

这时候我们会对大模型说：

我们要在春节前去北京三日游、预算多少、更想逛胡同还是看博物馆、每天走路别太多、输出按 Day1/Day2/Day3 给我。

这一步的本质就是按下启动键：先把这次要做什么定下来。Prompt 就是那个临时的、实时的沟通渠道。

2. MCP：它不教模型怎么做事，它只负责“让模型能摸到外部世界”

继续刚才的例子：卡住我们的地方通常不是"模型不会写攻略"，而是"它拿不到真实的路线、时间、地点信息"。如果靠模型本身的知识库，它可能会编造一个并不存在的地铁站。

这时候发现高德地图提供了一个 MCP Server，把查路线、算时间、搜兴趣点这些能力暴露成标准工具，我们就能让模型用规范化协议去调用：比如让它查"酒店→故宫"的来往方式、自动预估耗时、再把结果无缝塞回行程里。

MCP (Model Context Protocol) 解决的是连接性：模型到底能访问哪些工具、资源、上下文。它把这件事做成标准协议，然后供模型使用¹。

关键点：MCP Server 可以对外暴露 tools、resources 等能力，模型则按规范去调用它们。这套标准化的做法有个好处：无论你换了什么底层模型，与外部工具的接口始终一致，不用每次都重新改代码。

关于高德的这个例子，大家可以看看官方文档（🔗 高德 MCP Server 介绍）。

3. Skills：把“正确姿势”沉淀下来，让团队输出更一致

有了 MCP 之后，我们还希望它“每次都按我们习惯的方式做攻略”，别一会儿像小红书、一会儿像论文。

这时 Skills 就出场了。我们提前做一堆行程规划的 Skills，比如"北京三日游模板"、"景点节奏控制（上午/下午/夜景）"、"预算与交通规则"。

模型在开始执行前，首先看到每个 Skill 的名字和描述这些元信息，然后只在命中对应任务时，才会深入加载那个 Skill 的完整内容。这叫渐进式披露（Progressive Disclosure），token 用得特别高效²。

大家试想一下，如果我们去图书馆查资料，图书管理员是把所有书的内容一股脑塞进我们脑子里，还是先给我们看书名和简介？肯定是后者。

Skills 的运行机制也是一样：

1. 先看“书名和简介”：模型启动时，只会快速扫描所有 Skills 的头部元信息（就是 name 和 description）。
2. 再看“全部内容”：只有当它发现用户的需求（比如“帮我理个计划”）完美命中了某个 description 时，它才会去加载那个 Skill 后面成百上千行的具体指令。

这样做有两个巨大的好处：一是省钱（Token 用得少），二是抗干扰（上下文里没那么多杂音）。

大家看下面这个真实的 Skill 文件头，模型在第一阶段其实只看得到这点东西：

---
name: agent-skills
description: Enables the model to identify, select, and execute external tools to fulfill complex user requests
---

而下面的具体的描述使用，则是看不到的。同时，只要你的 description 写得够精准，模型在解决不同问题的时候，就越能准确的调用不同的skills。

很多人把 Skills 当成"更聪明"的工具，但它最有工程价值的地方其实是 “更一致、能沉淀、能复用”。

它特别适合：重复出现的任务、希望稳定输出、团队想共享最佳实践（比如报告模板、代码审查规范、规范开发）。

💡 一图看懂：Skills vs MCP

它们不是替代关系，而是互补关系：MCP 给入口（能做什么），Skills 给用法（该怎么做）。

大家如果想找现成的 Skills 参考，可以逛逛这个市场：👉 Agent Skills 市场。

4. 自定义 Commands：把高频 Prompt 变成“快捷键”

如果我们发现“每次做攻略都要重复敲一大段 Prompt”，那心态真的容易崩。这时候就把高频那段话做成 Custom Commands。

它的逻辑比 Skills 更轻：它就是把一段做好的 Prompt 存成一个命令。

比如做一个 /beijing_trip 命令，里面写好固定模板（要问哪些问题、输出格式、要不要表格、每天步数上限）。下次只要敲 /beijing_trip 3天 预算3000 就直接展开执行。

• Claude Code: 支持 Markdown 定义的 slash commands，放在 .claude/commands/ 下³。
• OpenAI Codex: 也有类似的 Custom Prompts 机制⁴。

如何选择：如果只是想少打字，用 Commands；如果是想教模型一套复杂流程，用 Skills。

5. Agent：真正开始“干活”的闭环，不是大号 Prompt

当我们不满足于“给一份攻略”，而是希望它能自己跑完整个闭环——比如：先问缺失信息 → 调用高德 MCP 查路线 → 发现某天太赶再自动调整 → 最后检查预约/闭馆并给出最终版。

这就不是一条 Prompt 能搞定的了，这是 Agent 的典型工作方式：

规划 → 调用工具 → 根据结果迭代 → 直到满足验收标准。

很多人误会“Agent = 大 Prompt”，是因为只看到“指令”，没看到 Agent 的核心在于循环（Loop）和状态管理。

这里有个小坑：Claude Code 和 OpenAI Codex 其实都属于 Agent（而且是 Coding Agent）。它们提供了读代码、改代码、跑命令、结合仓库上下文、按任务迭代的能力，完全符合 Agent 的定义。

6. Subagent：把主对话从“信息垃圾堆”里救出来

最后一个小妙招是 Subagent。

试想一下，主 Agent 正在整理三日游大纲，这时我们需要查“路线细化/通勤耗时/换乘方案”。如果都在主对话里跑，你的屏幕会被一大堆 API 调用日志和中间数据刷屏。

这时候，我们把这个很碎的活丢给一个 Subagent 去跑（它像被主 Agent 当成一个工具来调用），跑完只回传精炼结果。

这样做的好处：

1. 干净：主上下文不会被污染。
2. 并行：可以同时派三个 Subagent 去查机票、酒店和门票。

这在 LangChain Deep Agents 里叫 Context Isolation（上下文隔离）⁵，非常实用的架构模式。

总结：一张图看清

为了方便大家理解，我把这 6 个概念整理成了一张架构图和对比表。方便大家理解。

参考资料