一、对比背景与核心命题
在大模型驱动的智能体（Agent）开发中，开发者经常面临一个困惑：Skill、Prompt、MCP（模型上下文协议）和Function Calling 这四个概念看起来都在”让模型做更多事情”，它们到底有什么区别？能不能互相替代？
先给出核心结论：它们不是同一层的四个竞品，而是在Agent执行链路中各自承担不同职责的协作能力。 把它们放到一条完整的用户请求处理链路中观察，关系就会非常清晰。
本文将围绕以下四个对象展开对比：
- Prompt（提示词）：用户或系统发给模型的自然语言指令。
- Function Calling（函数调用）：模型在推理过程中主动触发预定义函数的机制。
- Skill（技能）：围绕特定任务封装的可复用能力单元，通常包含Prompt、工具调用逻辑、参数约束等。
- MCP（模型上下文协议）：一种标准化的协议层，用于连接模型与外部工具、数据源和服务。
二、对象定义与各自解决的问题
2.1 Prompt：最基础的指令层
Prompt 是用户对模型最直接的输入形式。比如用户说”帮我分析这份报表”，这就是一条Prompt。它解决的是”模型如何理解用户意图”的问题，是整个交互的起点。
Prompt 的特点是轻量、灵活，但本身不具备调用外部系统的能力。它只是把”你要做什么”告诉模型。
2.2 Function Calling：模型主动触发工具的机制
Function Calling 是模型在推理过程中，根据上下文判断需要调用某个外部函数，并以结构化方式输出函数名和参数的能力。它解决的是”模型如何从被动回答升级为主动执行操作”的问题。
例如，模型判断用户需要查询天气，就会输出一个调用天气查询接口的结构化请求。但 Function Calling 通常依赖开发者预先定义好的函数列表和参数模式。
2.3 Skill：面向任务的能力封装单元
Skill 是更高一层的封装。它不只是一段Prompt或一个函数调用，而是把完成某一类任务所需的全部要素——包括指令描述、参数约束、工具调用顺序、错误处理逻辑、输出格式——打包成一个可复用、可组合的单元。
比如”生成周报”这个Skill，内部可能包含：读取数据源的函数调用、数据聚合逻辑、格式化输出的Prompt模板、以及异常时的兜底策略。Skill 解决的是”如何把零散能力组织成可管理、可复用的任务模块”的问题。
2.4 MCP：标准化的连接协议层
MCP 是一种协议规范，它定义了模型与外部工具、数据源之间如何进行标准化的连接、发现和交互。它解决的是”如何让不同的工具和服务以统一方式接入Agent”的问题，类似于一个”通用适配层”。
MCP 的价值在于降低集成成本：只要工具提供方遵循MCP规范，任何兼容的Agent都可以直接使用，无需为每个工具单独写适配代码。
三、相同点分析
尽管四者定位不同，但在以下方面存在共性：
- 目标一致：都是为了让大模型在Agent场景中具备更强的任务执行能力，从纯文本生成走向实际操作。
- 都依赖模型推理：无论是Prompt理解、Function Calling触发、Skill编排还是MCP协议交互，最终都需要模型进行语义理解和决策。
- 可组合使用：在一条Agent执行链路中，它们往往同时出现。例如，用户Prompt触发Agent，Agent通过Skill调度，Skill内部使用Function Calling调用工具，工具通过MCP协议接入。
四、核心差异分析
4.1 技术架构层次
| 维度 |
Prompt |
Function Calling |
Skill |
MCP |
| 层次定位 |
输入层 |
推理机制层 |
能力封装层 |
协议连接层 |
| 系统边界 |
用户与模型之间 |
模型与预定义函数之间 |
任务逻辑与多组件之间 |
工具服务与Agent之间 |
| 依赖组件 |
仅需模型 |
模型+函数定义 |
模型+函数+逻辑编排+可能的MCP |
遵循协议的工具服务端与客户端 |
4.2 功能能力覆盖
- Prompt：仅负责传递意图，不具备执行能力。覆盖范围最窄，但灵活性最高。
- Function Calling：赋予模型调用外部函数的能力，但需要开发者逐一注册函数并定义参数模式。覆盖单个操作，缺乏任务级编排。
- Skill：覆盖完整任务流程，可以包含多步函数调用、条件分支、结果校验等。是面向业务语义的封装，复用性和可维护性更强。
- MCP：覆盖工具接入的标准化问题，不直接定义业务逻辑，但为Skill和Function Calling提供统一的工具接入通道。
4.3 接入方式与开发成本
- Prompt：接入成本最低，写一段自然语言即可，但效果高度依赖提示工程能力，且难以处理复杂任务。
- Function Calling：需要开发者定义函数签名、参数模式、错误返回格式，有一定开发量，但机制清晰。
- Skill：开发量最大，需要设计任务流程、编写内部Prompt模板、配置工具调用链、处理异常。但一旦封装完成，后续复用成本极低。
- MCP：需要工具提供方实现MCP服务端，Agent侧实现MCP客户端。前期有协议适配成本，但长期看降低了每新增一个工具的集成代价。
4.4 性能与扩展性
- Prompt：无额外性能开销，但复杂任务仅靠Prompt往往需要很长的上下文，影响响应速度和token成本。
- Function Calling：每次调用有一次模型推理的开销，多步调用会累积延迟。
- Skill：由于内部可以做逻辑优化（如合并调用、缓存中间结果），在设计良好的情况下可以比直接多次Function Calling更高效。
- MCP：作为协议层，本身不影响业务性能，但标准化带来的可扩展性优势明显——新增工具只需遵循协议，无需改动Agent核心逻辑。
4.5 安全与合规
- Prompt：需要注意注入风险，用户恶意Prompt可能导致模型行为偏离。
- Function Calling：函数参数需要严格校验，防止模型生成不合规参数导致安全问题。
- Skill：可以在Skill层面统一做权限控制、输入清洗、输出审核，安全边界更清晰。
- MCP：协议层可以定义认证与授权机制，为工具接入提供统一的安全框架。
4.6 运维复杂度
- Prompt：运维简单，但Prompt效果漂移需要持续调优。
- Function Calling：需要维护函数列表和参数模式的版本管理。
- Skill：需要版本管理、测试覆盖、依赖追踪，运维复杂度最高，但也最可控。
- MCP：需要维护协议兼容性、服务端可用性监控。
五、典型场景与选型建议
场景一：简单问答与文本生成
推荐以Prompt为主。 任务单一、无需外部操作时，精心设计的Prompt就足够。引入Skill或MCP属于过度工程。
场景二：模型需要查询实时数据（如库存、天气）
推荐Function Calling + MCP。 定义一个查询函数，通过MCP协议接入数据服务。如果此类需求频繁且模式固定，可以进一步封装为Skill。
场景三：复杂业务流程（如自动生成并发送周报、多系统协同审批）
推荐Skill作为核心编排单元，内部使用Function Calling，工具通过MCP接入。 Skill提供任务级的逻辑编排和异常处理，Function Calling提供单步操作能力，MCP提供工具标准化接入。
场景四：企业需要统一接入多类内部工具
推荐以MCP为基础设施层。 先推动内部工具服务遵循MCP规范，再在上层构建Skill或直接通过Function Calling使用。这样每新增一个工具的集成成本最低。
选型原则总结
- 团队规模小、任务简单时，优先从Prompt和Function Calling入手，快速验证。
- 任务复杂度上升、需要复用和维护时，引入Skill封装。
- 工具数量多、来源杂、需要统一管理时，引入MCP协议层。
- 四者不是替代关系，而是从内到外、从简单到复杂的协作层级。
六、迁移与使用注意事项
- 从纯Prompt迁移到Function Calling：需要梳理哪些意图需要外部数据或操作，设计合理的函数签名，注意参数校验和错误回传。
- 从Function Calling迁移到Skill封装：需要识别可复用的任务模式，设计内部流程，注意Skill版本管理和测试。
- 引入MCP协议：评估现有工具是否支持协议改造，考虑协议版本兼容性和长期维护成本。
- 混用时的边界问题：避免在Skill内部过度依赖硬编码的Function Calling而忽略MCP的通用接入能力，否则会失去标准化带来的扩展优势。
- 稳定性与兼容性：模型版本升级可能影响Function Calling的触发稳定性，Skill内部逻辑需要做兼容性测试。
七、总结
回到最初的问题：Agent Skill 与 Prompt、MCP、Function Calling 的区别是什么？
它们是Agent能力体系中不同层次的组成部分：
- Prompt 是起点，传递意图；
- Function Calling 是机制，让模型能动起来；
- Skill 是封装，把能力组织成可复用的任务模块；
- MCP 是协议，让工具接入标准化、可扩展。
选型时不应问”用哪个”，而应问”在这条链路的哪个环节需要什么能力”。理解它们的协作关系，才能构建出既灵活又可维护的Agent系统。百度智能云在AI应用开发领域也提供了丰富的模型能力与工具生态，开发者可结合自身业务需求，合理组合上述能力，构建高效智能的应用架构。