Agent Skill、MCP与Prompt的区别详解

一、对比背景：为什么这几个概念总被混为一谈

在智能体（Agent）相关的技术面试与选型讨论中，Prompt、MCP、Agent Skill 这几个词经常同时出现，再加上 Function Calling（函数调用），四个概念恰好分布在智能体架构的不同层次，却因为都在讲“让模型干活”，而被不少人误认为是一组可以互相替代的竞争方案。典型的误解是：“某某机制是 A 厂商提出的，某某协议是 B 厂商提出的，它们是不同时期的竞争产物，系统里选一个就够了。”

这种理解的根本问题在于：把不同层的东西放到了同一层来比。实际上，它们是一组自下而上、层层叠加的协作关系：Prompt 解决“怎么向模型表达意图”，Function Calling 解决“模型怎么发起一次结构化调用”，MCP 解决“外部工具怎么以统一方式暴露给模型”，Agent Skill 解决“拿到工具之后按什么流程把任务做好”。每一层都以下层为前提，各有不可替代的职责。

本文以标题中的三个对象——Agent Skill、MCP、Prompt 为核心对比对象；同时，由于层级关系必须借助函数调用机制才能讲清楚，会将其作为背景一并纳入，使分层图景完整。

从发展脉络看：函数调用机制最早由头部模型服务厂商推出，随后成为主流模型服务的通用能力；MCP 由业界以开放协议的形式提出，用于统一工具接入方式；Skill 则是各类智能体框架普遍采用的上层封装思路。三者诞生有先后，但定位不同，并非竞争关系。

二、对象定义：先建立直觉——四句话的主语都不一样

• Prompt 是“人（开发者/用户）对模型说：请按我的要求做这件事”；
• Function Calling 是“模型对程序说：我要调用这个函数，参数是这些”；
• MCP 是“工具服务对模型说：我能提供这些标准化能力”；
• Agent Skill 是“技能库对模型说：做这类事，请按这套流程来”。

主语不同、对话对象不同、粒度不同，这就是四者的本质差异。下面逐一展开。

2.1 Prompt：表达层的“任务指令单”

Prompt 是开发者以自然语言向模型传达意图的方式，涵盖系统提示词、角色设定、输出格式约束、示例引导等。它不依赖任何协议与外部组件，成本最低、迭代最快。但它的能力边界同样明显：复杂流程全部塞进 Prompt，会导致文本冗长、指令冲突、上下文被挤占。一句话概括：Prompt 决定模型“知道要做什么”，但不保证模型“有能力去做”。

2.2 Function Calling：调用协议层的“结构化语言”

函数调用让模型在接收工具描述后，输出“调用哪个函数、传什么参数”的结构化结果，由应用程序执行实际调用，再把结果回传给模型。它解决的是最基础的协议问题——把模型的“意图”转译成程序可执行的“指令”。没有这一层，模型与外部世界之间就只有纯文本，没有可靠的执行通道。

2.3 MCP：工具生态层的“标准化工具箱”

当应用里的工具越来越多、多团队需要共享工具时，“每个应用各自定义函数、各自写接入逻辑”的重复建设问题就会暴露。MCP 在函数调用机制之上做工具供给侧的标准化：把数据库查询、检索、文件读写、业务 API 等能力封装成符合统一协议的服务，并规范服务发现、工具描述、调用与回传的流程。核心收益是“一次实现、处处复用”——工具提供方实现一次，任何支持该协议的智能体都能接入，工具描述与权限也得以统一治理。

agent-skill-">2.4 Agent Skill：知识流程层的“成套操作手册”

有了调用语言和工具箱，还剩一个问题：面对一类复杂任务（如生成数据周报、执行发布检查），模型该按什么步骤、什么标准去组合使用工具？Agent Skill 把“完成某类任务所需的知识、步骤、判断标准、脚本与模板”打包成可复用模块，按需加载。技能内部通常包含提示词模板、流程编排说明、参考示例与质量标准，本质是把领域老手的经验工程化。它不发明新工具，而是教模型“怎么把工具用好”。

三、相同点：它们为什么常被当成一类东西

1. 目标一致：都服务于“让大模型可靠地完成更复杂的任务”，不改变模型本身的参数与能力上限，属于模型外围的工程手段；
2. 都以文本为最终载体：Prompt 是自然语言；工具的名称、功能说明、参数结构，以及技能的流程文档，最终都会被转写为模型可读的文本；
3. 天然互补、往往共存：成熟系统中四者通常同时在场，而不是多选一；
4. 都需要持续迭代：Prompt 要调优，工具描述要打磨，技能文档要随业务演进，任何一层都不存在“一次配置、永久有效”。

四、核心差异：四个维度拆开看

4.1 层级与依赖关系（最关键）

四者构成自下而上的依赖链：Function Calling 依赖模型的结构化输出能力；MCP 依赖函数调用机制作为运行时的执行通道——协议定义的是“工具如何暴露与发现”，模型侧的实际触发仍要走结构化调用；Skill 依赖下层工具可用，再把工具组织成流程；Prompt 则贯穿始终，每一层最终都以文本形式呈现给模型。因此“选一个、弃其余”不成立：没有下层，上层封装就是空中楼阁；没有上层，下层能力只能靠临时拼凑。

4.2 结构化程度与形态

• Prompt：自然语言，自由度最高，机器校验最弱；
• Function Calling：结构化输出，函数名与参数可校验；
• MCP：标准化协议，接口契约、服务发现与调用语义有明确规范；
• Skill：模块化封装，内部是“提示词 + 流程 + 脚本/模板”的组合体，对外呈现为一个可声明、可加载的能力单元。

越往上，约束越强、稳定性越好，改造成本也相应上升。

4.3 复用粒度与维护主体

• Prompt：粒度最小，通常服务于一类任务，由提示词作者/开发者维护；
• Function Calling：复用于单个应用的函数注册表，由应用开发者维护；
• MCP：跨应用、跨团队、跨模型复用，由工具提供方统一维护，消费方只做接入；
• Skill：跨任务、跨场景复用，往往由“领域专家 + 工程团队”共同沉淀，属于组织级知识资产。

4.4 成本与稳定性权衡

Prompt 成本最低、见效最快，但换模型后行为漂移明显；函数调用需要编写执行逻辑并应对“参数幻觉、误选函数”，稳定性靠校验与兜底换取；MCP 接入成本较高，换来的是生态级复用与统一权限管控；Skill 沉淀成本最高，换来的是复杂任务的高成功率与执行一致性，属于前期重投入、后期高回报。

五、对比表格

维度	Prompt	Function Calling	MCP	Agent Skill
所处层级	交互表达层	调用协议层	工具标准化层	知识与流程封装层
解决的问题	怎么向模型表达意图	模型怎么发起结构化调用	工具怎么统一暴露与复用	任务按什么流程完成
形态	自然语言文本	结构化调用意图	标准化工具服务协议	可复用模块（提示词+流程+脚本+模板）
复用范围	单任务/单应用	单应用内	跨应用、跨模型	跨任务、跨场景
维护主体	提示词作者	应用开发者	工具提供方	领域专家+工程团队
接入成本	低	中	中高	高
典型风险	指令冲突、行为漂移	参数幻觉、误选函数	工具描述质量差、权限过宽	流程僵化、文档挤占上下文

六、用一个例子串起四层

以“查询上周销售额并生成分析报告”为例，用伪代码示意四层如何协作：

# 第一层（Prompt）：表达意图
prompt = "查询上周销售额，按渠道拆分，并生成一份分析报告"
# 第二层（MCP）：标准化工具发现与描述
tools = tool_service.list()   # [query_sales_db, make_chart, export_report, ...]
# 第三层（Function Calling）：模型输出结构化调用意图
call = {"name": "query_sales_db", "arguments": {"period": "last_week"}}
# 应用侧执行后把结果回传模型，模型继续发起后续调用……
# 第四层（Agent Skill）：技能中预置"数据报告"的标准流程
# 步骤1 校验数据口径 → 步骤2 查询 → 步骤3 校验数值合理性
# → 步骤4 生成图表 → 步骤5 按模板输出报告 → 步骤6 自查格式与结论

可见：Prompt 给出“做什么”，MCP 提供“有什么可用”，Function Calling 决定“这次调哪个”，Skill 规定“整体按什么顺序与标准做”。任何一层缺失，其余层都要付出额外的补偿成本。

七、典型场景下的组合选择

1. 纯生成类任务（写文案、摘要、翻译）：精心设计的 Prompt 基本够用，引入更多层反而增加复杂度；
2. 需要外部数据的简单任务（查订单、算运费）：Prompt + 少量函数调用即可，重点把参数校验与异常兜底做扎实；
3. 多应用、多团队共享工具（内部数据查询、检索、办公系统能力）：适合用 MCP 统一接入，避免重复封装，也便于权限统一治理；
4. 高频复现的复杂流程任务（周期性报告、发布检查、标准化处理流程）：在下层工具稳定后沉淀为 Skill，用流程约束换成功率与一致性；
5. 从原型到生产的常见演进路径：先写好 Prompt 验证可行性 → 引入函数调用打通执行 → 工具增多后用 MCP 收敛 → 流程稳定后封装成 Skill。

八、选型建议

选型时不要问“三者选哪个”，而要问“当前瓶颈在哪一层”：

• 模型理解任务没问题，但输出不稳定、格式跑偏 → 优先投入 Prompt 工程与输出约束；
• 模型需要触发外部动作，却缺乏可靠执行通道 → 引入函数调用机制，配套做好参数校验、超时重试与结果回传设计；
• 工具在多个应用间重复封装、描述口径不一、权限分散 → 用 MCP 统一接入与治理；工具描述质量直接决定模型选对工具的准确率，值得重点打磨；
• 某类任务已打磨出稳定流程，希望“一次沉淀、处处复用” → 封装为 Skill，注意粒度设计：太粗难以复用，太细则失去封装价值；
• 团队工程资源有限时，建议从轻量方案起步，避免一上来搭建全套体系导致维护不动。

九、迁移与落地注意事项

1. 渐进迁移而非推倒重来：既有函数调用逻辑与统一协议层可以共存，优先迁移复用价值高的工具，长尾工具保留原方式；
2. 权限随层级上收：工具统一暴露后调用方增多，必须同步收敛权限模型（最小授权、按调用方隔离、审计日志），否则“一次实现处处复用”会变成“一次泄露处处可见”；
3. 上下文预算是隐性约束：工具描述与技能文档都会消耗模型的上下文窗口，注册工具越多、文档越厚，挤占越明显，需要做按需加载与描述精简；
4. 更换模型时分层评估：Prompt 对模型版本最敏感，结构化调用的可靠性依赖模型的指令遵循水平，协议层相对稳定，迁移时应做分层回归测试；
5. 技能需要治理：技能本质是文档化的知识资产，要像代码一样做版本管理与评审，避免“手册过期”与业务标准脱节。

十、总结

回到最初的问题：Agent Skill、MCP 与 Prompt 的区别是什么？一句话概括——Prompt 是表达意图的“任务指令单”，Function Calling 是发起调用的“结构化语言”，MCP 是统一暴露能力的“标准化工具箱”，Agent Skill 是沉淀经验的“成套操作手册”。它们不是可以互相替代的竞争方案，而是智能体架构中自下而上、层层依赖的分工协作：下层提供执行通道与生态复用，上层提供流程知识与执行一致性。选型时先定位瓶颈所在层，再决定投入方向；落地时按“Prompt 优化 → 函数调用 → 标准化接入 → 技能沉淀”的路径渐进演进，通常是更稳妥的路线。