企业官网建设流程全解析

一、当前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。