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

本文用清晰的问题链，把 Prompt、Agent、Function Calling、MCP 和 Skills 这几个常被混淆的大模型概念串联起来。从 system/user prompt 的分工讲起，到 Agent 如何调用工具、MCP 如何统一工具层通信，再到 Skills 与 MCP 的本质差异——不堆术语，只讲清楚它们各自在解决什么问题。

AI算力小知识

621人浏览 · 2026-02-27 10:33:37

AI算力小知识 · 2026-02-27 10:33:37 发布

AI 圈这两年新词涌现的速度，有时候比模型迭代还快。

Prompt、Agent、Function Calling、MCP、Skills……单个词看起来都眼熟，真让你说清楚它们之间是什么关系，很多人会卡在那里。这篇文章不打算堆概念，而是沿着一条问题线，把这几个东西一路串下来——从 Prompt 开始，走到 Agent，再走到 MCP 和 Skills，最后给一个整体视图。

一、System Prompt 和 User Prompt：一个分工问题

最早用 GPT 的时候，绝大多数人只看到一个聊天框：你输入，模型回答，仅此而已。

那时候，什么设定、什么角色，都会往 user prompt 里塞。想让模型扮演某个角色，你会在开头写一句"你现在扮演我的女朋友"，然后才说你真正想说的事。这有点别扭——"你现在扮演什么角色"这件事，本质上不是你的问题，而是对话的背景设定，频繁写在 user prompt 里，既啰嗦又难复用。

于是有了 system prompt 这个位置：专门放角色定义、风格约束、边界限制，比如"你是一个严谨的后端工程师"或"永远用中文回答"。每次请求时，系统会自动把 system prompt 和 user prompt 一并发给模型。

理解起来也很简单：system prompt 决定"这是谁在说话"，user prompt 决定"现在要干什么"。

这个分工让人设更稳定，提示词也更容易维护。但这只是第一步。

二、Agent：从"告诉你怎么做"到"直接帮你做"

只有 Prompt 的模型，本质上还是一个问答系统。你问"帮我找这个文件"，它会告诉你可以用什么命令——但真正去执行的是你自己。

能不能让模型直接帮我动手？ 这个问题催生了 Agent。

早期 AutoGPT 之类项目的做法相当直接：把一堆函数当成"工具"，比如 list_files()、read_file()、browse_web()，然后把工具的功能说明和参数格式，用自然语言写进 system prompt。用户输入目标之后，模型按照说明书输出一段结构化文字，告诉程序要调用哪个工具、用什么参数。程序解析这段文字，真的去调用工具，把结果再喂回模型，反复多轮，直到任务完成。

这个"在用户、模型、工具之间来回传话"的程序，就是 AI Agent。

但用自然语言写工具说明书，有一个硬伤。模型是概率模型，不总是听话。你在 system prompt 里写了"调用工具时请用 JSON 格式输出"，它偶尔还是会偏。Agent 端就不得不做大量重试和纠错逻辑，稳定性一般，token 也浪费不少。

三、Function Calling：给工具说明书定个统一格式

OpenAI、Anthropic、Google 给出的解法是：工具描述别再用随意的自然语言，改成固定结构的 JSON。 这就是 Function Calling。

以前的做法是在 system prompt 里自然语言描述工具名称、功能、参数，模型"看懂就行"，容易跑偏。Function Calling 改成用 JSON 来定义工具，包含工具名 name、简要说明 description、参数结构 parameters（通常是 JSON Schema 格式）。模型调用工具时，必须输出固定格式的 JSON，而不是随意发挥。

这带来了三个好处：工具定义从 system prompt 里彻底剥离出来，结构清晰；模型可以针对这种固定格式专项训练；就算偶尔格式有误，服务端也能自动检查重试，用户无感。

总体结果是：Agent 写起来更简单，工具调用更稳定，token 相对也更省。

不过新问题随之而来——每家大厂的 Function Calling 接口各不相同，很多开源模型还不支持。如果你想写一个跨模型通用的 Agent，依然很麻烦。

四、MCP：解决的是"工具层"的问题，不是"模型层"的问题

前面讲的，都是 Agent 和模型之间怎么沟通工具信息。MCP（Model Context Protocol）解决的是另一侧：Agent 和工具服务之间，怎么通信更统一、更可复用。

一个现实场景：你写了一个网页爬虫或内网文档搜索服务，很多 Agent 都会用到。如果每个 Agent 都复制一份工具代码，一旦接口变动，所有 Agent 一起爆炸。

解决思路其实很工程：把工具封装成独立服务，让所有 Agent 通过统一协议来调。 MCP 就是这个协议。

MCP 里有三个角色：工具服务被称为 MCP Server，调用它的 Agent 叫 MCP Client，承载 Client 的宿主程序叫 MCP Host（比如 Claude 桌面客户端、VS Code 插件等）。

需要特别说明一点：MCP 本身和大模型没有直接关系。 它只关心工具怎么暴露出去、怎么被发现和调用。

五、MCP 的两条链路

从工程视角看，MCP 主要涉及两段通信：Client ↔ Server，以及 Client ↔ 大模型。

Client 和 Server 怎么说话？ 官方规范支持两种模式。本机模式通过标准输入输出（STDIN/STDOUT）通信，Host 启动 Server 进程作为子进程，适合本地工具。跨机模式通过 HTTP + SSE 建立长连接，一条通路发请求，一条通路流式返回结果，适合部署在远端的 MCP Server。无论哪种方式，协议层统一基于 JSON-RPC 2.0。

连接建立时，MCP Server 会向 Client 报告自己有哪些工具、资源和提示模板。之后 Client 就可以按规范调用。

Client 和大模型怎么说话？ 这里有个有意思的地方：MCP 规范并没有规定 Client 必须怎么和大模型通信。 有的实现用 Function Calling，把 MCP 工具映射为模型侧的函数；也有实现直接把工具说明拼进 system prompt，约定模型用特定标签来请求工具调用。有人在抓包某些 VS Code MCP 插件时发现，工具说明直接被拼进 system prompt，长达数万字符，模型用这种"朴素方式"同样运行得不错。

这说明了一件事：MCP 只解决 Agent ↔ 工具服务这半边，Agent ↔ 模型那一侧是开放的，可以自选方案。

六、Skills：另一种哲学——更信任模型

说完 MCP，再来看 Anthropic 推出的 Skills。很多人第一眼以为"这不就是另一种 MCP"，但核心差异不在功能，而在设计哲学。

一个典型的 Skill 长这样：

my-skill/
  ├── skill.md      # 必须：说明书 + 元数据
  ├── script.py     # 可选：辅助脚本
  └── 其他资源...

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

在有代码执行环境和文件系统访问的产品里，模型可以先通过简短元数据知道有哪些技能存在（未激活时只占几十个 token），判断某个任务适合用某个技能之后，再请求 Host 把 skill.md 全文加载进上下文，接着按说明加载脚本和数据文件，驱动完整工作流。整个过程几乎不需要复杂协议，也很省 token。

前提只有一个：你相信当前模型足够聪明，能读懂一份结构化说明书并照着做。

MCP 选择的是另一条路：用 JSON-RPC 加通信层规范把行为钉死，对工具提供方更友好，能一次接入多方复用，也适合需要严格权限和审计的企业环境。但代价是协议复杂度高，上下文消耗容易上万 token，部署和运维成本对个人开发者不够友好。

一句话总结：

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

两条路线没有谁替代谁。企业级、多团队、多语言服务互通、需要强管控，MCP 更合适；个人开发者、小团队、快速验证、偏本地自动化，Skills 式轻量封装更顺手。

七、一条完整链路

最后用一个具体问题把整个链路走一遍：

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

首先，你在前端输入的问题是 user prompt，系统可能还有一段 system prompt，比如"你是一个视频创作者助手"。接着，Agent 把一个爬虫工具注册进来，并把使用说明转化成 Function Calling 定义或 Skills/MCP 格式。模型收到问题和工具说明书之后，发现必须调用"爬粉丝数"工具，按约定格式返回调用请求。Agent 调用工具，把结果拿回来，再交给模型，模型根据结果生成最终回答："截至刚刚，你有 12 万粉丝。"

Prompt、Agent、Function Calling、MCP、Skills 在这条链路里各站各的位置，但围绕的始终是同一个目标：让大模型更稳定、更安全、更高效地用上外部能力。