Prompt、Agent、MCP 和 Skills：大模型时代的“工具栈”到底在干嘛

这两年，AI 圈的新名词一波接一波：Prompt、Agent、Function Calling、MCP、Skills……

看着都眼熟，真让你解释清楚它们之间是什么关系，很多人会卡壳。

• Prompt 不就是提示词吗，为什么又分 system / user？
• Agent 被叫成“智能体”，那它和普通聊天机器人到底差在哪？
• MCP 被说成“AI 时代的 USB 协议”，那它真能像 USB 一样随便插工具吗？
• Anthropic 推出的 Skills，又和 MCP 撞概念，到底有什么不同？

这篇文章不堆概念，也不玩术语堆砌，而是沿着一个清晰问题线，把这几个核心概念串起来：

从 Prompt 开始，一路走到 Agent、Function Calling，再到 MCP 和 Skills，最后给一个整体视图。

一、从 Prompt 说起：system 和 user 到底差在哪

最早用 GPT 的时候，绝大多数人只看到一个聊天框：

• 你说一句话（User Prompt）
• 模型回一句（Model Response）

一开始，所有信息都塞在 user prompt 里，包括“人设”。

比如你想让模型扮演女朋友，可能会这么写：

你现在扮演我的女朋友。我说我肚子疼，你就回一句“滚一边去，我也疼”。

问题来了：

“你现在扮演我的女朋友”这句话，其实不是我们真正想表达的内容，而是对角色和风格的设定。频繁写在 user prompt 里，很别扭，也不利于复用。

于是人们把这类信息单独拎出来，放进 system prompt：

• system prompt：
• 描述模型扮演的角色、风格、边界
• 例如“你是一个严谨的后端工程师”“你永远用中文回答”等
• user prompt：
• 保留用户真正的问题或指令

每次请求时，系统会自动把 system prompt + user prompt 一起发给模型。

结果是：对话更自然，人设更稳定，提示词更好维护。

你可以把它理解成：

system prompt 决定“这是谁在说话”，user prompt 决定“现在要干什么”。

二、从“回答问题”到“主动干活”：Agent 是怎么登场的

仅有 Prompt 的模型，本质上还是“问答模式”：

• 你问：帮我找一下某个文件
• 模型回：大概怎么找、用什么命令
• 真正执行命令的，是你自己

大家自然会问：

能不能让模型直接帮我动手？

1. 第代尝试：AutoGPT 式 Agent

AutoGPT 之类的项目，做了一件简单粗暴但有效的事：

1. 你在本地写好一堆函数当“工具”（Agent Tool）

• 比如 list_files()、read_file()、write_file()、browse_web()……

2. 把这些工具的功能说明、参数格式，用自然语言写进 system prompt
3. 把用户的目标（比如“帮我找到原神的安装目录”）作为 user prompt
4. 模型按照说明书，输出一段结构化文本，告诉 Agent：

• 要调用哪个工具
• 用什么参数

Agent 解析这段文本，真的去调用工具，再把结果丢回给模型，反复多轮，直到任务完成。

这整个“在用户、模型、工具之间来回传话”的程序，就被称为 AI Agent。

2. 但用自然语言写“工具说明书”，有个硬伤

自然语言写说明书有几个现实问题：

• 模型是概率模型，不总听话
• 虽然你在 system prompt 写了“调用工具时用 JSON 格式输出”，它有时候还是会写错格式
• Agent 端不得不做大量“重试”与“纠错”逻辑，稳定性一般，token 浪费也严重

这就是 Function Calling 出场的背景。

三、Function Calling：大厂给“工具说明书”上的统一格式

OpenAI、Anthropic、Google 很快给出一个标准化方案：Function Calling。

核心思想可以概括成一句话：

工具描述别再用随意的自然语言，改成固定结构的 JSON。

比较一下差异：

• 传统做法：
• 在 system prompt 里自然语言描述：
• 工具名称、功能说明、参数字段、返回格式
• 模型“看懂就行”，但容易偏
• Function Calling 做法：
• 用 JSON 定义 tools：
• name：工具名
• description：简要说明
• parameters：参数结构（一般用 JSON-Schema）
• 调用工具时，模型必须输出固定结构的 JSON

好处有三个：

1. 工具定义从 system prompt 里剥离出来，结构清晰
2. 模型可以针对这种固定格式做专项训练
3. 即便模型偶尔输出格式错误，服务端也能自动检查并重试，用户无感

结果是：

Agent 写起来更简单，工具调用更稳定，token 也相对省。

不过新的问题来了——每家大厂 Function Calling 的接口都不一样，很多开源模型还不支持。

如果你想写一个“跨模型通用”的 Agent，依旧很麻烦。

四、MCP 出场：不是“更聪明的模型”，而是“更通用的工具层”

上面讲的，都是 Agent 和模型之间怎么沟通工具信息。

MCP（Model Context Protocol）解决的是另一侧的问题：

Agent 和工具服务之间，怎么通信更统一、更可复用？

先看一个现实痛点：

• 你写了一个网页爬虫 / 向量库 / 内网文档搜索服务
• 很多 Agent 都可能用到
• 如果每个 Agent 都复制一份工具代码，维护地狱
• 接口变动时，所有 Agent 一起爆炸

于是大家想到一个看起来最“工程师思维”的办法：

把工具封装成独立服务（Server），让所有 Agent 通过统一协议来调。

MCP 就是在这种背景下诞生的：

• MCP 定义了一套协议，专门用来规范 Agent 与工具服务 的交互方式
• 工具服务被称为 MCP Server
• 调用它们的 Agent 被称为 MCP Client
• 承载 Client 的宿主程序，就是 MCP Host（例如 Claude 桌面客户端、VS Code 插件等）

要注意一点：

MCP 本身和“大模型”没有直接关系。

它只关心工具怎么暴露出去、怎么被发现和调用。

五、MCP 具体在做什么？两条链路说清楚

从工程视角看，MCP 主要涉及两条通信链路：

1. MCP Client ↔ MCP Server
2. MCP Client ↔ 大语言模型

1. Client 和 Server 怎么说话？

官方规范目前支持两种模式：

• 同机模式：标准输入 / 输出（STDIN / STDOUT）
• Host 启动一个 Server 进程作为子进程
• 通过子进程的标准输入输出完成双向通信
• 适合本地工具，比如本机脚本、命令行程序
• 跨机模式：HTTP + SSE
• 使用 HTTP + Server-Sent Events 建立长连接
• 一条通路负责 Client 发请求
• 一条通路负责 Server 流式返回结果
• 适合部署在远程服务器上的 MCP Server

无论哪种传输方式，协议层统一基于 JSON-RPC 2.0：

请求、响应、通知全部走标准 JSON-RPC 格式，便于调试和扩展。

在建立连接阶段，MCP Server 会向 Client 报告：

• 自己有哪些工具（tools）
• 工具的功能和参数定义
• 有哪些资源（resources）、提示模板（prompts）可用

之后，Client 就可以按规范调用这些工具，获取数据或执行操作。

2. Client 和大模型怎么说话？

有意思的是：

MCP 规范并没有规定 Client 必须怎么和大模型通信。

• 有的实现用 Function Calling：
• 把 MCP 工具映射为模型侧的函数
• 由模型通过函数调用请求 MCP Client 调用工具
• 也有实现完全不用 Function Calling：
• 直接把工具说明塞进 system prompt
• 让模型按约定格式用“标记 + JSON”告诉 Client 该调用什么

在一次抓包分析中，有人发现某些 VS Code MCP 插件采取的是后者：

• 把所有工具说明直接拼到 system prompt，长达数万字符
• 约定模型用类似 <UseMCPTool>... 这样的标签来请求工具调用
• 实际运行看，模型用这种“朴素方式”也能很好地遵守协议

这说明了一件事：

MCP 只是解决 Agent ↔ 工具服务这半边的问题，

至于 Agent ↔ 模型这一侧，是开放的，可以自行选择 Function Calling 或“纯 Prompt”方案。

六、Skills 和 MCP：不是“谁替代谁”，而是“信任模型程度不同”

说完 MCP，我们再看 Anthropic 推出的 Skills。

很多人第一眼会以为：这不就是“另一种 MCP”吗？

其实，核心差异不在功能，而在设计哲学：

MCP 的态度是：我不太信任模型，必须严密协议约束。

Skills 的态度是：我更信任模型，只要给清晰说明书就够。

1. Skills 的极简思路

一个典型的 Skill，长这样：

my-skill/

├── skill.md # 必须：说明书 + 元数据

├── script.py # 可选：辅助脚本

└── 其他资源...

其中：

• skill.md 是写给模型看的自然语言说明书，外加一小段 YAML 元数据：
• 这个技能是做什么的
• 什么时候应该被调用
• 应该按什么步骤使用目录里的资源或脚本

Code Interpreter / Cloud Code 这类有“代码执行环境 + 文件系统访问”的产品，可以让模型：

1. 先通过简短元数据知道有哪些技能存在（未激活时只占几十个 token）
2. 当判断“这个任务可以用某个技能解决”时，再请求 Host 把 skill.md 全文加载进上下文
3. 按 skill.md 里的说明，进一步加载脚本、数据文件，驱动完整工作流

整个过程几乎不需要复杂协议，也很省 token。

前提是：你相信当前模型已经足够聪明，能读懂一份结构化说明书并按说明办事。

2. MCP 的“协议优先”思路

相比之下，MCP 选择的是另一条路：

• 把工具抽象成 Server / Client
• 用 JSON-RPC + 通信层规范保证行为一致
• 在“外部世界”构建一套通用、中立、可扩展的工具层

它的优点是：

• 对工具提供方更友好，可以一次接入，多方复用
• 对复杂企业环境更适合，可以做严格权限、审计、安全边界

但代价同样明显：

• 协议复杂度高，文档动辄十几页
• 官方实现的上下文消耗很快就能上万 token
• 要部署 Server，要配 Client，要做运维，对个人开发者不够“顺手”

3. 本质差异：你到底有多信任模型

综上，可以用一句话概括 MCP vs Skills 的差异：

• MCP：用协议把行为钉死，因为“不太信任模型”。
• Skills：把复杂度下沉给模型，因为“相信模型能看懂说明书”。

这两种路线并不存在谁替代谁的问题，而是：

• 企业级、多团队、多语言、多服务互通、需要强管控 → MCP 更合适
• 个人开发者、小团队、快速验证、偏本地自动化 → Skills 式轻量封装更顺手

七、把这些概念串起来：从一个问题出发的完整链路

最后我们用一个稍微“接地气”的问题，把整个链路完整走一遍：

“我问 AI：‘你现在有多少粉丝？’它怎么才能给出实时答案？”

1. 语言层：

• 你在前端输入的问题，是 user prompt
• 系统可能还追加一段 system prompt，比如“你是一个视频创作者助手”

2. Agent：

• 你写了一个爬虫程序，可以爬某平台主页，获取当前粉丝数
• Agent 把这个工具注册给自己，并把使用说明转化为 Function Calling 定义或 Skills/MCP 格式

3. 模型决策：

• 模型收到 user prompt + 工具说明书
• 发现要回答这个问题，必须用“爬粉丝数”的工具
• 按约定格式返回“我要调用工具 X，参数是 Y”

4. Agent 调用工具：

• 对于本地脚本，可以直接调用或通过 MCP Server 转发
• 工具跑完，把结果返给 Agent

5. 模型生成最终回答：

• 再次把工具输出发给模型
• 模型根据结果组织自然语言回答，例如：“截至刚刚，你有 12 万粉丝”

这条链路里，

Prompt、Agent、Function Calling、MCP、Skills 各自站在不同位置，

但其实只是围绕一个目标：让大模型更稳定、更安全、更高效地用上外部能力。

租用AI算力可以上 晨涧云GPU算力平台 ，试用高效的云算力服务。

八、结语：先别被名词吓住，从一个小 Agent 开始

最后说一点个人向的观点。

这些名词看起来很多：Prompt、Agent、Tools、Function Calling、MCP、Skills……

但它们并不是一夜之间从天上掉下来的，而是工程实践一步步演化出来的结果。

如果你刚入门，不必急着给每一个都写出教科书级定义。

更自然的路径是：

1. 先理解 user / system prompt 的基本分工
2. 再写一个最简单的 Agent，让模型能调用你的一两个本地脚本
3. 当工具多到难以管理时，再考虑 MCP 这类协议
4. 当你发现自己在反复教模型同一套流程时，再抽出来写成 Skill

站在这个视角看，

所谓“AI 时代的新名词”，其实都是在回答同一个问题：

在模型越来越强的前提下，

我们怎么用最少的制度和规范，

让它和真实世界高效协作。