Agent Skill、Prompt与模型上下文协议的区别解析

一、先说结论：不是同一层的四个竞品

初次接触智能体开发的开发者，常常会陷入这样的困惑：模型已经能通过提示词理解任务，也能通过函数调用使用工具，那“技能”是不是多余的？反过来，既然有了技能，提示词工程是不是就不重要了？

这些疑问的根源，在于把四个不同层级的事物放到了同一维度上比较。事实上，Agent Skill（智能体技能）、Prompt（提示词）、Function Calling（函数调用，也常称工具调用）与模型上下文协议（一类用于连接模型与外部工具、数据源的标准化协议）并不是互相替代的竞争关系，而是 Agent 执行链路中四个不同层级的协作组件。把它们放回一条完整的任务执行链路里，各自的位置会一目了然。

二、逐一定义：四者各自是什么

1. Prompt：意图与上下文的载体

Prompt 是用户或系统输入给模型的文本信息，承载着任务意图、约束条件与背景上下文。从技术视角看，它是模型推理的直接输入；从使用视角看，它是人与智能体之间的交互界面。Prompt 工程的核心目标，是通过清晰、结构化的表达，让模型准确理解“要做什么、做到什么程度、有哪些限制”。它解决的是“意图如何被模型正确理解”的问题。

2. Function Calling：模型的结构化调用能力

Function Calling 是模型层的一种能力：模型在理解任务后，能够判断“这件事仅靠文本生成完不成，需要借助外部工具”，并按照约定格式输出一次结构化的调用请求（工具名加参数）。需要强调的是，真正执行工具的是外部运行时环境，模型只负责“决定调用什么、传什么参数”。它解决的是“模型如何发起对外部世界的操作”这一问题，是智能体从“能说”走向“能做”的关键一步。

3. 模型上下文协议：工具连接的标准化规范

当模型应用需要接入的工具越来越多——文件系统、数据库、检索服务、代码执行环境等——如果每接一个工具就编写一套对接代码，开发和维护成本会迅速失控。模型上下文协议这类标准化协议的出现，正是为了把“工具如何描述、如何被发现、如何被调用、结果如何回传”统一为一套开放规范。它解决的是连接层的问题：工具提供方按协议实现一次，就能被所有遵循该协议的模型应用复用，从而把“点对点集成”变成“标准化接入”。

agent-skill-">4. Agent Skill：任务能力的封装单元

Agent Skill 是更高一层的能力封装：把完成某类任务所需的知识、流程说明、配套脚本与参考资源，打包成一个可被智能体按需加载的技能单元。一个典型的技能通常包含三部分：一是说明文档，告诉模型这类任务应按什么步骤推进、有哪些注意事项与输出规范；二是可执行脚本，把复杂、易错的操作固化成确定性代码，减少模型的“即兴发挥”；三是参考资源，如模板、示例数据等。它解决的是“成熟的任务经验如何沉淀、复用与共享”的问题。

三、放进一条执行链路看：以“帮我分析这份报表”为例

假设用户对智能体说：“帮我分析这份报表。”这句看似简单的话，会在链路中依次经过四个组件的接力：

用户输入："帮我分析这份报表"          ← Prompt：表达意图与上下文
        ↓
模型理解任务，规划执行步骤            ← 模型推理
        ↓
判断需要读取文件、解析表格、执行计算，
输出结构化调用请求                    ← Function Calling：模型能力层
        ↓
运行时按标准协议完成工具发现、
参数传递与结果回传                    ← 模型上下文协议：连接层
        ↓
命中"报表分析"技能，加载其说明文档
与配套脚本，按既定流程执行            ← Agent Skill：能力封装层
        ↓
汇总结果，生成最终回答

从这个例子可以清晰看到四者的分工：用户那句话是 Prompt，负责表达意图；模型“知道该调工具、并能输出规范请求”依赖 Function Calling 能力；工具能被统一发现与调用，依赖模型上下文协议；而“报表分析该按什么套路做”这套经验，则以技能的形式预先封装，在任务匹配时被加载生效。任何一环缺失，这次任务要么无法完成，要么完成得不稳定。

四、核心区别一览

维度	Prompt	Function Calling	模型上下文协议	Agent Skill
本质	输入信息	模型能力	通信规范	能力封装单元
所处层级	交互层	模型层	连接层	应用封装层
解决的问题	让模型理解意图	让模型会发起调用	让工具接得上、可复用	让任务经验可沉淀、可复用
典型形态	自然语言文本	结构化调用请求机制	协议规范与接口约定	说明文档+脚本+资源包
主要提供方	用户或系统	模型本身	工具方与运行时	开发者或团队

五、为什么说 Skill 不是前三者的替代品

第一，技能的说明书本身就是提示词。技能被加载后，其说明文档会作为上下文参与模型推理，本质上是一种“结构化的、可复用的 Prompt”。技能并没有取代提示词，而是把提示词工程的成果产品化、资产化。

第二，技能中的脚本要真正执行，依然依赖 Function Calling 机制发起调用。技能改变了“做什么、按什么步骤做”，但没有改变“模型如何发起调用”这一底层机制。

第三，技能的发现、加载与内部工具的对接，通常也借助标准化协议完成。协议解决“接得上”，技能解决“用得好”，二者是上下游关系而非竞争关系。

因此，四者是层层依赖、各司其职的关系：Prompt 定义交互入口，Function Calling 提供模型能力，模型上下文协议打通工具连接，Agent Skill 沉淀并复用任务经验。去掉任何一层，执行链路都会出现能力缺口。

六、典型适用场景

• 只需 Prompt 即可覆盖：一次性问答、文案润色、简单归纳推理等不依赖外部系统的任务，此时引入更多组件只会增加复杂度。
• 需要 Function Calling：模型需要获取实时数据或执行实际动作的场景，例如查询订单状态、写入业务系统、调用计算服务。
• 需要模型上下文协议：工具数量多、来源异构，或希望工具接入一次即可被多个智能体应用复用的场景，常见于企业内多系统集成。
• 需要 Agent Skill：某类任务流程稳定、已有明确最佳实践，且希望在团队内部或多个智能体之间复用的场景，例如报表分析、代码审查、数据清洗、合规检查等。

在实际工程中，无论是基于自建运行时开发，还是使用百度智能云等云平台提供的大模型服务与智能体开发组件，上述分层协作逻辑都是通用的：先明确任务特征，再决定在哪一层引入能力。

七、使用注意事项

1. 按需分层引入，避免过度设计。简单任务用清晰的 Prompt 即可；只有当任务需要外部能力时才引入调用与协议；只有当任务经验需要沉淀复用时才封装技能。
2. 技能描述决定触发准确率。技能的元信息与用途描述写得越清晰，模型在任务匹配时越能准确加载对应技能；描述含糊会导致漏触发或误触发。
3. 管理好上下文预算。技能文档、工具列表都会占用模型上下文窗口，技能数量膨胀后应引入按需加载与优先级筛选机制。
4. 重视安全与权限控制。技能内脚本具备实际执行能力，应运行在受控环境中，遵循最小权限原则，对文件、网络、系统命令等敏感操作做白名单与审计。
5. 版本化与可观测。技能应像代码一样进行版本管理，避免“隐式行为变更”；同时记录完整的调用链路，便于定位“模型为什么这样决策”的问题。

八、总结

回到最初的问题：Agent Skill、Prompt、Function Calling 与模型上下文协议的区别是什么？一句话概括：它们不在同一层，也不构成竞争——Prompt 是意图入口，Function Calling 是模型能力，模型上下文协议是连接规范，Agent Skill 是经验封装。理解这种分层协作关系，比记住任何一个单独的定义都更重要：它决定了构建智能体应用时，应该在哪一层发力、引入哪一层的能力，从而避免用错工具、重复造轮子，让系统结构清晰、边界明确、长期可维护。