一文分清Prompt、Agent、Function Call、Skill与MCP

一、对比背景：为什么这五个概念容易被混为一谈

在大模型应用开发实践中，Prompt、Agent、Function Call、Skill、MCP这五个词出现频率极高，而且经常出现在同一句话里：“基于MCP协议扩展Agent的工具能力，通过Skill封装领域知识，利用Function Call对接企业内部系统，再用Prompt驱动整体流程。”不少刚接触的开发者因此产生困惑：它们是并列的竞争关系，是可以互相替代的方案，还是各司其职的不同层次？

实际上，这五个概念并不在同一维度上互相竞争，而是分别位于大模型应用技术栈的不同层级：Prompt是最基础的交互表达方式，Function Call是模型侧的结构化工具调用能力，Skill是可复用的能力封装单元，MCP是工具与上下文的标准化接入协议，Agent则是整合上述要素的应用架构形态。理解它们的层次关系，比死记各自的名词定义更重要。

二、对象定义：五个概念分别是什么

2.1 Prompt（提示词）

Prompt是你输入给AI的文本指令，是人与模型交互的最小单元。它可以是简单的一句话，也可以是包含角色设定、任务描述、约束条件、输出格式与示例样本的复杂结构化文本（即系统提示词或提示词模板）。可以用餐厅类比：你去餐厅点菜时说“来一份宫保鸡丁”，这句话就是Prompt，模型就是接收需求并给出结果的一方。

需要强调的是：Prompt本质上是“表达需求”的方式，它决定了模型“理解到什么”，但不保证模型“能做到什么”。当任务涉及实时数据或真实操作时，再精巧的Prompt也无法凭空补足能力缺口，这正是其他四个概念存在的理由。

2.2 Function Call（函数调用）

Function Call是模型侧的一项结构化输出能力：开发者预先定义一组函数（含函数名、参数结构与用途描述），模型在对话中判断当前任务是否需要借助工具，若需要，则以结构化格式（通常为JSON）输出函数名与参数；应用侧负责真正执行该函数，并把执行结果回传给模型，由模型生成最终回答。

两个关键点值得注意：其一，模型本身并不执行任何函数，它只负责“决策调用并给出参数”，真正的执行发生在你的应用运行时；其二，Function Call解决的是“让模型从说话变成行动”的接口问题，是工具使用的最小闭环。

2.3 Skill（技能）

Skill是把某一类能力打包封装后的复用单元。一个Skill通常包含：完成特定任务的提示词模板、依赖的工具集、执行流程与约束条件。例如一个“日程管理技能”可能封装了查询日程、创建日程两个工具调用，以及处理时间歧义、确认操作等提示词逻辑。Skill强调复用性与标准化治理，让多个Agent或多个应用共享同一套能力，而不是各自维护一份零散的提示词和工具副本。

2.4 MCP（模型上下文协议）

MCP（Model Context Protocol，模型上下文协议）是业界提出的一种开放协议标准，用于规范AI应用与外部工具、数据源之间的连接方式。它采用客户端—服务端架构：工具或数据的提供方实现协议服务端，对外暴露工具、资源与上下文信息；AI应用作为客户端统一接入。类比硬件领域统一接口标准的思路，MCP希望解决的是“每个应用都要为每个工具单独编写适配”的N×M集成问题，让工具接入趋近“即插即用”。

agent-">2.5 Agent（智能体）

Agent是以大模型为“大脑”的完整应用架构形态。一个典型Agent包含四个核心要素：规划（把目标拆解为可执行步骤）、工具使用（通过Function Call或协议化接入调用外部能力）、记忆（维护会话上下文与长期状态）、反思（根据执行结果修正策略）。如果说Prompt是“提一个需求”，Agent就是“雇一位员工”：你给它目标，它自主规划、多步执行、遇到异常自行调整，直到任务完成或主动求助。

三、相同点分析

尽管层次不同，这五个概念有三个共同点：

1. 目标一致：都是为了让大模型从“能对话”走向“能做事”，缩短模型能力与真实业务之间的距离。
2. 都以模型的理解能力为前提：无论Function Call还是协议化工具接入，底层都依赖模型对指令与工具描述的语义理解；Prompt质量不佳，Agent的规划同样会跑偏。
3. 可组合共存于同一系统：一个生产级的Agent系统，往往同时包含精心设计的系统Prompt、Function Call能力、若干Skill、以及基于MCP等标准接入的工具生态，五者是协作关系而非互斥关系。

四、核心差异分析

4.1 所处层次不同（最本质的差异）

用一个分层视角可以快速建立全局认知：

第5层  应用架构层：Agent（规划·记忆·工具编排·反思）
第4层  能力封装层：Skill（提示词模板+工具+流程的复用包）
第3层  协议标准层：MCP（工具与数据源的统一接入协议）
第2层  能力接口层：Function Call（模型的结构化调用输出）
第1层  交互表达层：Prompt（人类向模型表达需求的文本）

层次越低越基础、通用性越强、改造成本越低；层次越高越贴近业务、能力越完整、工程投入越大。

4.2 解决的核心问题不同

• Prompt解决“如何把需求表达清楚”；
• Function Call解决“模型如何以可控方式触发外部动作”；
• MCP解决“工具接入缺乏统一标准、重复开发适配”；
• Skill解决“能力重复建设、难以复用与治理”；
• Agent解决“复杂多步任务的自主规划与执行”。

4.3 结构化与自主性程度不同

Prompt是自由文本，非结构化程度最高；Function Call输出的是结构化调用请求，属于单步受控；MCP定义了标准化的消息、工具与资源格式，本身不产生自主行为，只提供能力供给通道；Skill是结构化的能力包，流程相对固化；Agent则引入“感知—规划—执行—反思”的循环决策机制，自主性最强。按自主性大致排序：Prompt（无自主性）< Function Call / Skill（单步受控）< Agent（多步自主）。

4.4 接入方式与改造成本不同

• Prompt：改造成本最低，编写即可生效，适合快速迭代与A/B验证；
• Function Call：需定义工具描述、实现调用循环、执行真实函数并处理异常与超时，改造量中等；
• MCP：需要部署或接入协议服务端、管理连接与协议版本，前期投入较高，但工具越多边际成本越低；
• Skill：需按平台或团队规范封装能力，成本取决于能力本身的复杂度；
• Agent：需要搭建规划、记忆、工具编排与安全兜底的完整框架，改造量与运维复杂度最高。

4.5 一次工具调用的示意性流程（伪代码）

# 1. 用户 Prompt（交互层）
user_input = "帮我查明天北京的天气，如果下雨提醒我带伞"
# 2. 模型决策：输出 Function Call 意图（结构化，能力接口层）
model_output = {
    "function": "get_weather",
    "arguments": {"city": "北京", "date": "明天"}
}
# 3. 应用执行函数，获得真实结果（工具层，可经MCP标准化接入）
result = get_weather(city="北京", date="明天")  # => {"condition": "小雨"}
# 4. 结果回传模型，生成最终回答
final_answer = model(messages + result)
# => "明天北京有小雨，建议出门带伞。"

在简单场景中，第2步到第3步由应用直连完成；在工具生态复杂的场景中，第3步的工具会通过统一协议服务端暴露；若该能力属于高频复用能力，还可进一步封装为Skill；若任务需要连续完成“查天气—查日程—改行程”多个步骤并自动纠错，则上升为Agent编排。

五、对比表格：一表看全关键差异

维度	Prompt	Function Call	Skill	MCP	Agent
定位	输入指令文本	模型的结构化工具调用能力	可复用的能力封装单元	工具/上下文统一接入协议	自主任务执行的应用架构
所处层次	交互表达层	能力接口层	能力封装层	协议标准层	应用架构层
结构化程度	自由文本	结构化调用请求	结构化能力包	标准化协议消息	完整系统闭环
执行主体	模型生成文本	应用运行时执行函数	Agent或应用调用	协议服务端提供能力	Agent框架编排
自主性	无	单步受控	流程相对固化	不涉及（只供能力）	多步自主决策
接入成本	极低	中	中	中高（前期）	高
复用性	低（易复制走样）	中	高	高（跨应用共享）	视框架而定
典型用途	问答、内容生成	查数据、触发操作	跨应用沉淀领域能力	统一工具生态	复杂多步任务自动化
单独可用	是	需配合应用	需宿主环境	需客户端接入	需模型+工具+框架

六、典型场景选择

1. 内容生成与知识问答：纯Prompt即可满足，无需引入工具调用与Agent框架，保持系统复杂度最低。
2. 需要实时数据或简单操作：Prompt + Function Call。例如查询订单状态、调用内部接口、执行一次格式转换。
3. 多应用、多团队共享工具生态：引入MCP类标准化接入。工具提供方只需实现一次服务端，各应用统一接入，避免逐对开发与维护适配代码。
4. 沉淀可复用的领域能力：做Skill封装。将文档解析、表格处理、日程管理等高频能力打包，统一版本、权限与质量基线。
5. 复杂多步任务自动化：构建Agent。如跨系统的工单流转、多阶段数据处理流水线、需要检索与汇总的研究型任务，具备“目标明确、步骤不固定、需要多轮执行与纠错”的特征。

七、选型建议（条件化判断）

• 如果单轮Prompt即可解决，不必为“架构先进”而引入Agent：每多一层抽象，就多一份调试成本、延迟开销与不可控性。
• 如果只需要两三个固定工具，直连式的函数调用方案通常足够；当工具数量多、需要跨团队共享、或更换模型与应用较频繁时，标准化协议接入的价值才会明显。
• 如果同一能力要被多个应用复用，或希望由业务人员维护能力内容，Skill封装比各自维护提示词副本更利于治理与演进。
• 如果任务需要自主规划与多步执行，Agent才值得投入；同时必须配套权限边界、调用审计与人工介入机制，避免自主行为失控。
• 从工程落地看，主流大模型应用开发平台（如百度智能云等平台提供的大模型应用开发服务）通常将提示词管理、工具调用、Agent编排等作为通用能力内置，团队可优先评估托管化程度更高的组合方案，减少自研框架的长期运维负担。

八、迁移与使用注意事项

1. 模型兼容性：不同模型的函数调用输出格式可能存在差异，更换底座模型时需对工具描述与解析逻辑做回归测试；采用标准化协议可部分缓解，但协议版本升级仍需关注兼容性。
2. 安全与权限：工具一旦可被模型触发，就必须实施最小权限（限定可调用函数范围）、参数校验、敏感操作二次确认与调用审计；Prompt还面临提示注入风险，外部数据回填上下文前应做过滤与隔离。
3. 稳定性与成本：Agent的多轮循环会放大延迟与Token消耗，应设置最大执行步数、超时与循环检测，防止任务死循环导致成本失控。
4. 能力治理：Skill与协议化工具会随时间累积，需要版本管理、废弃机制与使用统计；否则“工具越多、模型选择越乱”，反而降低调用准确率。
5. 评估体系：无论处于哪一层，都应建立输入输出评测集；Prompt改动、工具描述改动、协议升级都要跑回归验证，避免“改一处、崩一片”。

九、总结

回到最初的困惑：Prompt、Agent、Function Call、Skill、MCP并不是“五选一”的竞争关系，而是一套协作体系的不同层次，Prompt负责表达需求，Function Call让模型能发起可控行动，MCP让工具接入有统一标准，Skill让能力沉淀为可复用资产，Agent把这一切组织成能自主完成任务的系统。选型的核心思路是“按需上层次”：从Prompt出发，需要外部数据与操作时引入函数调用，工具生态复杂时再标准化接入，能力需要复用时做Skill封装，任务确需自主多步执行时才构建Agent。理解层次、按需组合，才能既不过度设计，也不留下能力欠账。