一、当前 MCP 调用的实现方式

在当前的 MCP 体系中，Agent 调用 Skill 的过程大致如下：用户输入自然语言请求；Agent 将请求和 Skill 列表一起放入 Prompt，发送给大模型；大模型理解请求，决定需要调用哪个 Skill，并按照约定格式输出 JSON 调用指令；Agent 解析 JSON，构造 MCP Action，通过 MCP 客户端发送给网关；网关执行策略、转发到Skill；Skill 返回结果；Agent 将结果再次发送给大模型，让模型生成最终回复。

这个过程可以工作，但存在明显的效率问题。大模型输出 JSON 调用指令需要额外的 token，这些 token 不产生业务价值。JSON 的格式冗余，同样的信息用 XML 或原生函数调用格式可能更紧凑。Agent 需要维护 Skill 列表和调用历史，上下文可能快速增长。模型输出的 JSON 可能格式错误或不完整，需要 Agent 做容错处理。

更根本的问题是，大模型对 MCP 协议本身没有感知。模型不知道什么是 Action、Context、Permission。它只是被训练成输出特定格式的文本。这意味着模型无法利用 MCP 的语义信息来做出更好的决策。

二、原生支持的含义

大模型原生支持 MCP 意味着模型在训练和推理时，将 MCP 协议作为一等公民。具体来说，模型应该理解MCP 的核心概念：Action、Context、Permission、Skill、Result。模型能够直接生成结构化的 Action，而不是先输出 JSON 再被解析。模型能够理解 Context 中的信息，如用户身份、会话状态、记忆。模型能够感知策略约束，知道哪些操作是被允许的，哪些是被禁止的。模型能够处理流式调用，直接消费 Skill 返回的流式事件。

原生支持可以带来巨大的收益。首先是效率提升，减少 token 浪费，降低延迟。其次是可靠性提升，模型输出的 Action 直接是协议兼容的，不需要额外的解析和验证。第三是能力增强，模型可以利用 MCP 的语义信息做出更智能的决策。第四是简化 Agent 框架，不需要复杂的 Prompt 工程来格式化输出。

三、模型层的技术路径

实现大模型原生支持 MCP 可以有几种技术路径。

路径一：微调

在现有模型的基础上，使用 MCP 相关的数据进行微调。训练数据包括自然语言请求和对应的 MCP Action 序列。模型通过微调学会将用户意图映射为 MCP Action。这种方法不需要修改模型架构，只需要准备高质量的训练数据。挑战是需要大量的标注数据，且微调后的模型可能在其他任务上性能下降。

路径二：函数调用扩展

OpenAI、Anthropic、Google 等模型提供商已经支持函数调用功能。Agent 可以声明一组可用的函数，模型决定调用哪个函数以及传入什么参数。MCP Action 可以自然地映射为函数调用格式。模型提供商可以将 MCP 协议作为内置的函数调用模式。这样，Agent 不需要在 Prompt 中描述 Skill 列表，而是通过 API 参数传递。模型在响应中直接返回结构化的函数调用，而不是文本。

这种方法实现起来相对简单，不需要修改模型，只需要扩展 API。模型提供商可以在服务端将 MCP 的 Skill 列表转换为函数调用定义。

路径三：协议层内置

在模型的下一个版本中，将 MCP 协议作为内置能力。模型原生理解 Action、Context、Permission 等概念。模型可以直接输出 MCP 协议的二进制表示，而不是文本。这需要修改模型架构和训练目标。挑战是成本高、周期长，但收益也最大。

路径四：适配器层

在模型和 Agent 之间增加一个适配器层。适配器负责将模型的输出转换为 MCP Action。适配器可以使用一个小模型或规则系统。这种方法的优点是模型不需要修改，缺点是增加了复杂度和延迟。

Peta 正在探索多种路径，并与模型提供商合作推动原生支持。

四、原生支持对 Agent 框架的影响

当大模型原生支持 MCP 后，Agent 框架的职责将发生变化。

简化 Prompt 工程

当前 Agent 框架需要在 Prompt 中包含大量关于 Skill 的描述、调用格式、示例。这些内容占用大量 token，且需要精心设计。原生支持后，Agent 只需要声明可用的 Skill 标识符，模型内部已经知道这些 Skill 的语义和调用方式。Prompt 大大简化。

减少解析开销

当前 Agent 需要解析模型输出的 JSON，处理各种格式错误。原生支持后，模型直接输出结构化的 Action，Agent 不需要解析。容错逻辑大幅简化。

更好的流式支持

当前流式调用需要 Agent 同时处理模型输出的文本流和 Skill 返回的事件流。原生支持后，模型可以直接消费Skill 的事件流，Agent 只负责转发。这简化了 Agent 的实现。

更强的上下文感知

当前 Agent 需要手动维护 Context 并传递给模型。原生支持后，模型可以直接从 MCP Context 中读取信息，Agent 不需要在 Prompt 中重复。

五、对 Skill 生态的影响

大模型原生支持 MCP 对 Skill 生态也是重大利好。

模型感知的 Skill 发现

模型可以根据当前任务动态推荐可用的 Skill。用户不需要事先知道 Skill 的存在，模型会主动提示。例如，用户说“帮我分析这份数据”，模型可以推荐“你可以使用数据分析 Skill”。

Skill 的自描述能力

Skill 的规范可以直接作为模型的输入。模型能够理解 Skill 的输入输出格式、副作用、权限需求。这使得模型可以更智能地决定何时调用哪个 Skill。

模型辅助的 Skill 开发

模型可以帮助开发者编写 Skill。给定一个 API 规范，模型可以生成 Skill 的代码框架和 MCP 接口定义。这可以显著降低 Skill 开发的入门门槛。

六、Peta 的角色

Peta 作为 MCP 控制平面的实现，在大模型原生支持的演进中扮演着重要角色。

标准化接口

Peta 推动 MCP 协议的标准化，为大模型厂商提供稳定的接口定义。模型厂商可以根据 Peta 的实现来测试和验证原生支持。

性能基准

Peta 提供了 MCP 调用的性能基准，可以用于评估原生支持的效率提升。模型厂商可以根据这些基准优化实现。

测试工具

Peta 提供了 MCP 协议合规性测试工具，可以验证模型的原生支持是否正确实现了协议。这有助于确保不同厂商的实现之间互操作。

开发者文档

Peta 为开发者提供了如何利用原生支持的文档和示例。当模型厂商推出原生支持后，开发者可以快速上手。

七、未来展望

在未来的一到两年内，我们可以期待以下进展。

短期（6-12 个月）

模型提供商通过函数调用扩展支持 MCP Action 输出。Agent 框架开始适配，减少 Prompt 中的 Skill 描述。开发者可以体验更简洁的 Agent 开发体验。

中期（12-24 个月）

模型开始原生理解 Context，能够自动利用用户身份、会话状态等信息。流式调用与模型输出流整合。Skill 发现机制开始出现。

长期（24-36 个月）

模型原生支持完整的 MCP 协议，包括 Action、Context、Permission、流式调用。Agent 框架大幅简化，接近于声明式配置。Skill 生态爆发式增长，模型成为 Skill 发现的入口。

八、小结

本章的核心结论可以总结为以下几点。

第一，当前 MCP 调用通过 Prompt 工程实现，存在效率低、可靠性差、模型对协议无感知等问题。

第二，大模型原生支持 MCP 意味着模型理解 Action、Context、Permission 等核心概念，能够直接生成结构化的调用。

第三，技术路径包括微调、函数调用扩展、协议层内置、适配器层。

第四，原生支持将简化 Agent 框架，减少 Prompt 工程和解析开销，增强上下文感知和流式处理。

第五，对 Skill 生态的影响包括模型感知的 Skill 发现、Skill 的自描述能力、模型辅助的 Skill 开发。

第六，Peta 在演进中扮演标准化接口、性能基准、测试工具、开发者文档等角色。

第七，未来一到三年内，我们可以期待从函数调用扩展到完整协议原生支持的逐步演进。

大模型原生支持 MCP 是 Agent 系统走向成熟的关键一步。它将使 Agent 开发从繁琐的 Prompt 工程中解放出来，让开发者专注于业务逻辑。

在下一章，我们将讨论 MCP 与区块链的集成——不可否认的审计与智能合约 Skill。