“这个API我昨天刚接完，今天又要重接一遍”

你花了一天时间，把一个电商系统的订单API按照OpenAPI规范写好文档，用LangChain的create_openapi_agent封装成工具，在GPT-4上跑通了。第二天产品经理说：“换Claude试试？”你打开代码，发现Claude不认识LangChain的StructuredTool格式——参数Schema要重写，工具描述格式要调整，连错误处理逻辑都要重写。第三天，CTO说：“我们决定自己微调一个Llama，工具调用格式按我们自己的来。”你沉默了。

一个API接三遍，一遍给一个模型用。 这是2024年每个AI工程师的真实日常。

2024年11月，Anthropic开源了MCP（Model Context Protocol），承诺“一次编写MCP Server，所有AI应用都能用”。2025年12月，Anthropic将MCP捐赠给Linux基金会旗下的Agentic AI Foundation。到2026年中，MCP月下载量突破1亿次。

但在庆祝“统一”之前，一个更值得追问的问题是：从OpenAPI到RPC再到MCP，我们到底是在“统一”工具调用协议，还是在不断制造新的兼容层？ 每一层协议的设计，都在解决上一层的某些问题，同时也在引入新的代价。

一、OpenAPI时代：人类可读，机器难懂

1.1 OpenAPI的本意与局限

OpenAPI规范（OAS）是一种用于描述RESTful API的标准化语言，让人类和计算机无需访问源代码就能发现和理解服务的功能。它用JSON或YAML描述API的端点、参数、请求和响应格式。

在传统软件工程中，OpenAPI做得很好——文档生成、客户端SDK自动生成、自动化测试。但到了AI Agent时代，OpenAPI暴露了它的局限。

静态描述 vs 动态发现。OpenAPI是静态文档——写死了接口的路径、参数、返回值。Agent需要在运行时动态发现“现在能用什么工具”，OpenAPI给不了这个能力。

人类优先 vs 机器优先。OpenAPI的设计初衷是“人类可读、机器可解析”，但在LLM场景下，Agent需要的不是“可解析”，而是“可理解”——自然语言化的工具描述、语义化的参数说明、示例化的调用方式。

HTTP绑定 vs 多传输需求。OpenAPI天然绑定HTTP。但Agent的工具调用，既需要本地进程通信（低延迟），也需要远程HTTP通信（跨服务），还需要流式交互。OpenAPI覆盖不了全部场景。

1.2 基于OpenAPI的Agent适配尝试

社区很快意识到OpenAPI的不足，开始在它之上搭建兼容层。

agents.json是wildCard团队在OpenAPI基础之上实现的规范，通过将API进行进一步的结构化描述，让AI Agent可以更稳定准确地调用API Service。它侧重AI Agent与互联网服务提供商的交互，保证多步骤调用的可靠性。

LangChain的OpenAPI Agent则走另一条路——直接把OpenAPI spec注入Prompt，让LLM“学会”调用API。这种方式的好处是通用——任何HTTP API都能接。坏处是“LLM需要在Prompt中理解整个API文档”，导致Token消耗大、错误率高。

最致命的问题是：OpenAPI规范本身的质量参差不齐。一篇2025年的研究发现，从22,000多个MCP标记的GitHub仓库中分析，OpenAPI规范普遍存在不一致或遗漏。AutoMCP项目在50个真实API（5,066个端点）上的测试表明，直接基于OpenAPI生成的工具调用成功率仅为76.5%——经过平均仅19行的规范修复后，成功率才提升到99.9%。

OpenAPI的问题是：它为人类写的文档，让机器去“理解”——中间的语义鸿沟，靠一个兼容层填不平。

二、RPC时代：跨语言调用，但不是为AI设计的

2.1 RPC的定位与错位

gRPC（2015年发布）基于HTTP/2和Protocol Buffers，支持双向流式通信。tRPC则是TypeScript-first的RPC框架，强调类型安全。

RPC解决的核心问题是跨语言、跨进程的方法调用。在微服务架构中，RPC是主力。但RPC的设计目标不是“让AI Agent发现和调用工具”。

RPC的问题在于：它假设调用方知道“调什么” 。在微服务中，服务A调用服务B的CreateOrder方法——A知道B的存在，知道方法名，知道参数格式。但在Agent场景中，Agent不知道有哪些工具可用，需要运行时发现。RPC没有内置的发现机制。

RPC的Schema是强类型的，但缺乏语义。.proto文件定义了字段类型和结构，但没有自然语言描述——这个工具是干什么的？什么场景下用？参数的含义是什么？这些信息对LLM决策至关重要，RPC给不了。

2.2 RPC作为兼容层的尝试

社区开始在RPC之上搭建AI兼容层。

AgentRPC是一个通用RPC层，可以让Agent连接到任何函数、任何语言、任何框架。它启动一个MCP兼容的服务器，让外部AI模型与注册的工具交互。

ATD（Agent Tool Dispatch） 则是一个跨厂商的线缆协议——任何LLM Agent、任何框架都可以通过一个类型化的RPC接口调用任何平台上的任何工具。

这些尝试的共同特点是：用RPC做传输层，在之上封装AI需要的发现、描述、调用语义。RPC解决了“怎么传”的问题，但没有解决“传什么”和“为什么传”的问题——这两个问题被留给了上层的兼容层。

RPC作为兼容层的得：传输效率高、类型安全、支持流式。失：缺乏工具发现、缺乏语义描述、对LLM不友好。

三、MCP时代：为AI而生的协议

3.1 MCP的设计哲学

MCP在2024年11月由Anthropic推出，其核心思想很简单：把“LLM与工具的接口”从“每家LLM厂商各自的SDK私有协议”抬升到“跨厂商标准化的开放协议” 。

MCP的架构有三个角色：

• Host：运行LLM的应用（Claude Desktop、Cursor等）
• Client：Host内部维护MCP连接的库
• Server：暴露工具、资源和提示词的服务进程

核心消息包括：initialize（握手、交换版本）、tools/list（返回工具目录）、tools/call（调用工具）。所有通信基于JSON-RPC 2.0。

MCP的定位清晰：它不替代REST或gRPC，而是让LLM Agent能够发现和使用工具的层；REST和gRPC是MCP Server通常包装的底层 。

3.2 MCP作为兼容层的得失

得：

消除N×M集成成本。在MCP出现之前，想让一个LLM Agent调用GitHub、Slack、Postgres五个工具，必须为每家LLM厂商分别实现五次集成。MCP的目标是：实现一次GitHub MCP Server，所有支持MCP的LLM都能调用。

动态发现。MCP的tools/list让Agent在运行时发现可用工具，而不是依赖静态配置。

跨模型兼容。在5大主流LLM（GPT-4o/Claude/Gemini/DeepSeek/Qwen）上的支持度全面优于厂商特定的Function Calling。MCP的厂商中立性可以为迁移节省6-12个月的迁移工作。

工程效率。在25+工具规模下，MCP的接入代码量比REST少75%。

失：

抽象税。工具调用从“Agent直接调用函数”变成了“Agent → MCP Client → JSON-RPC → MCP Server → 实际工具”。链路变长，调试复杂度上升。

版本碎片化。MCP规范经历了多次版本更新（2024-11-05、2025-03-26、2025-06-18、2025-11-25）。2026年7月的MCP v2更是引入了无状态化、废弃sampling等重大变更。不同版本的Client和Server之间存在兼容性问题。

安全边界转移。MCP把安全风险从“Agent直接调用API”转移到了“MCP Server的配置和部署”。如果MCP Server配置不当，风险可能更大。

四、兼容层的真实代价：三个故事

4.1 AutoMCP：从OpenAPI到MCP的自动化

AutoMCP是一个编译器，从OpenAPI 2.0/3.0规范生成MCP Server。它解析REST API定义，生成完整的Server实现，包括Schema注册和认证处理。

# AutoMCP的工作流程（概念示意）
# 输入：OpenAPI规范（petstore.json）
# 输出：MCP Server（可直接运行）

from auto_mcp import compile_openapi

# 一行命令，从OpenAPI生成MCP Server
server_code = compile_openapi(
    spec_path="./petstore.json",
    output_dir="./mcp-server",
    auth_config={"type": "api_key", "header": "X-API-Key"}
)
# 生成的Server包含：
# - 每个API端点 → 一个MCP Tool
# - 参数Schema自动转换
# - 认证处理
# - tools/list 和 tools/call 实现

AutoMCP在50个真实API上的测试显示：直接生成的工具调用成功率为76.5%。经过平均仅19行的规范修复后，成功率提升到99.9%。

这个数据揭示了一个残酷的事实：OpenAPI到MCP的兼容层，解决的是“格式转换”问题，但解决不了“规范质量”问题。 Garbage in, garbage out——如果OpenAPI spec本身不准确，再好的转换工具也救不了。

4.2 agents.json：在OpenAPI之上再加一层

agents.json在OpenAPI基础之上，为AI Agent设计了更结构化的API描述。它专门针对“AI Agent与互联网服务提供商的交互”，保证多步骤调用的可靠性。

// agents.json 示例（概念）
{
  "openapi": "3.0.0",
  "x-agent": {
    "tools": [
      {
        "name": "search_products",
        "description": "搜索商品，支持按关键词、价格区间、品类筛选",
        "workflow": {
          "steps": [
            {"action": "validate_params", "on_error": "ask_user"},
            {"action": "call_api", "retry": 3},
            {"action": "format_results", "max_results": 10}
          ]
        }
      }
    ]
  }
}

agents.json的得： 在OpenAPI的基础上增加了Agent需要的语义——工具描述、工作流定义、错误处理策略。失： 它仍然是静态配置文件，不是运行时协议。Agent无法在运行时动态发现新工具——每次工具变更都要更新配置文件。

4.3 分层MCP：三层架构的兼容层设计

分层MCP（Layered MCP）采用三层架构将OpenAPI规范转换为MCP Server：

• 发现层（Discovery） ：解析OpenAPI，提取端点和参数
• 规划层（Planning） ：将API操作映射为MCP工具，生成自然语言描述
• 执行层（Execution） ：处理认证、调用、错误处理

# 分层MCP的概念实现
class LayeredMCP:
    def __init__(self, openapi_spec):
        self.discovery = DiscoveryLayer(openapi_spec)
        self.planner = PlanningLayer()
        self.executor = ExecutionLayer()
    
    def build_server(self):
        # 发现层：提取所有端点
        endpoints = self.discovery.extract_endpoints()
        
        # 规划层：每个端点 → MCP Tool
        tools = []
        for endpoint in endpoints:
            tool = self.planner.create_tool(
                name=endpoint.operation_id,
                description=endpoint.summary + " " + endpoint.description,
                input_schema=self._to_json_schema(endpoint.parameters),
                handler=self.executor.create_handler(endpoint)
            )
            tools.append(tool)
        
        # 返回MCP Server
        return MCPServer(tools=tools)

三层架构的得： 每一层职责清晰，可以独立优化。发现层可以处理不同版本的OpenAPI，规划层可以针对不同LLM优化工具描述，执行层可以处理不同的认证方式。失： 三层之间的接口本身就是一个新的“协议”——你用三层架构生成MCP Server，但调试问题时需要穿透三层。

五、兼容层设计的“得失框架”

从OpenAPI到RPC再到MCP，每一次协议演进都伴随着兼容层的设计。我们可以总结出一个兼容层设计的得失框架：

得的三条

标准化降低集成成本。MCP在25+工具规模下比REST少75%的接入代码。标准化的价值随着工具数量增长而放大。

动态发现替代静态配置。MCP的tools/list让Agent在运行时发现工具，告别了“改一个工具就要改配置文件”的时代。

解耦带来灵活性。MCP将工具与模型彻底解耦——工具团队只需要维护MCP Server，AI团队只需要实现MCP Client。

失的三条

每一层抽象都有“抽象税” 。从OpenAPI到agents.json到MCP，链路越来越长，调试越来越难。MCP的JSON-RPC通信增加了1-50ms的延迟。

版本碎片化是运维的噩梦。MCP规范在18个月内经历了5次版本更新。2026年7月的MCP v2引入无状态化、废弃sampling等重大变更——升级意味着重写兼容层。

兼容层解决不了底层质量问题。AutoMCP的数据表明，OpenAPI规范的质量问题导致76.5%→99.9%的差距。再好的兼容层，也救不了烂数据。

六、总结：兼容层是必要的恶

回到最初的问题：从OpenAPI到RPC再到MCP，我们到底在“统一”什么？

答案是：我们在统一“AI Agent如何发现和调用工具”这件事的接口。

OpenAPI统一了“如何描述HTTP API”——但它是为人类写的，不是为AI写的。

RPC统一了“如何跨语言调用方法”——但它是为开发者写的，不是为AI写的。

MCP统一了“如何让AI发现和调用工具”——它是为AI写的。

每一层协议都在解决上一层的某个问题，同时引入新的问题。这不是“推倒重来”，而是“演进” 。就像TCP/IP在OSI七层模型之上，HTTP在TCP之上，REST在HTTP之上——每一层都是上一层的兼容层，每一层都在解决新的问题。

MCP会不会被下一层协议取代？也许会。但在此之前，MCP是Agent工具调用领域“最不坏的选择” 。它让“写一个工具，所有AI都能用”从理想变成了现实。

兼容层的价值不在于“永远正确”，而在于“在当下解决最紧迫的问题”。从这个角度看，MCP做对了。