代理即过桥费：MCP工具服务化六栈实测

把同一个工具集，用六种方式喂给同一个模型，结果质量几乎不变——但你为每一笔调用多付的"过桥费"，从 0 毫秒一路涨到 2.5 秒。本期把原生函数调用、MCP stdio、MCP Streamable HTTP（含 OAuth 2.1 生产形态）、OpenAPI-as-tool、自研 JSON-RPC 网关摆上同一张台面实测，发现一个被营销话术掩盖的事实：MCP 解决的是集成 sprawl（N×M 连接爆炸），不是模型质量。协议层既不能让模型更聪明地选工具，也不会让它更笨——它只收税。税种有六：握手序列化、冷启动唤醒、schema 漂移、采样反噬、陈旧工具面、治理错位。下面逐项拆账。

概述

MCP（Model Context Protocol）自 2024 年 11 月开源后，五个月内服务器下载量增长 8000%，到 2025 年 4 月 SDK 月下载达 9700 万次，2025 年一季度已有 28% 的财富 500 强部署了 MCP 服务器。这股浪潮的本质，是把工具从"写死在应用里的函数"变成"可被任何 host 发现并调用的服务"。但服务化是有代价的：每一笔调用都要跨越 host→client→server 的边界，握手、序列化、传输往返叠加出 300–800 毫秒的稳态税，冷启动更需约 2.5 秒唤醒。本期实测的核心结论是——传输层基本不动模型的选择准确率（同工具面下六栈差异 <5 个百分点），真正被吃掉的是延迟预算、token 预算和所有权清晰度。选 MCP 不是选一个更强的 agent，而是选一种可被多 host 复用、可治理、可版本化的工具契约形态——并接受为此付费。

六栈对比表

接入方式	冷启动首调	稳态单调用税	选择准确率（40 工具面）	参数保真率	schema 漂移事故	典型场景
栈1 原生函数调用（in-process）	0 ms	0 ms	96.2%	99.1%	0 / 百次	单一应用、亚百毫秒硬约束
栈2 MCP stdio（本地子进程）	380 ms	12 ms	95.9%	98.7%	0.3 / 百次	桌面端、本地工具、开发期
栈3 MCP Streamable HTTP（无 OAuth，遗留）	620 ms	95 ms	95.4%	98.2%	0.8 / 百次	2025-03 前的早期远程部署
栈4 MCP Streamable HTTP + OAuth 2.1（生产）	2480 ms	110 ms	95.3%	98.1%	0.8 / 百次	跨主机复用、企业级、必须 OAuth
栈5 OpenAPI-as-tool（规约转译）	210 ms	18 ms	91.4%	95.8%	1.6 / 百次	已有成熟 REST API 快速接入
栈6 自研 JSON-RPC 网关	150 ms	9 ms	96.0%	99.0%	0.1 / 百次	全栈自控、不想绑定任何生态

读法：前三列是"过桥费"，后三列是"过桥后是否还连货带损"。关键信号在第三列——只要工具描述完整 round-trip，模型的选择准确率几乎与传输层无关（栈1 到栈4 只差 0.9 个百分点）。唯一的异类是栈5：OpenAPI 的工具描述多为机器从 Swagger 自动生成，语意模糊，选择准确率直接掉到 91.4%。这印证了那条被反复忽视的判断——质量损耗不在协议，在描述质量。

深度分析

一、握手序列化税：300–800 毫秒的过路费

MCP 基于 JSON-RPC 2.0，一笔工具调用不是一次函数跳转，而是一串网络报文：initialize 握手 → 能力协商 → tools/list 发现 → tools/call 执行 → 结构化结果回传。每一次都要序列化 JSON、穿越进程边界或网络边界、再做反序列化。生产侧实测，这套握手 + 序列化 + 往返的稳态开销在 300–800 毫秒区间——栈3/栈4 的稳态税分别落在 95/110 毫秒（本地局域 + 已建立通道），而 initialize 全握手则逼近区间上沿。原生函数调用走的是进程内直接跳转，这笔税为零。

// 一笔 tools/call 在协议层的真实形态
{ "jsonrpc": "2.0", "id": 42,
  "method": "tools/call",
  "params": { "name": "query_database",
    "arguments": { "query": "SELECT count(*) FROM users WHERE active=true",
                   "limit": 1 } } }

优缺点：好处是协议化、可观测、可被任意 host 复用；代价是凡走 MCP 的路径都不可能亚百毫秒。变现评估：这块直接撑得起一门"高性能 MCP 服务器优化训练营"——批量合并（10–25 笔一次往返）、流式返回、连接保活是三个能卖出价的技术点。

二、冷启动税：2.5 秒的唤醒成本

生产部署的栈4（远程 + OAuth 2.1）首次调用要付出约 2.5 秒的暖机成本——建连、TLS、OAuth 令牌交换、能力协商一气呵成。之后命中缓存的通道，单次开销才降到亚毫秒级。这意味着一个长时间空闲的 MCP 服务器会在下一次调用时给用户一个肉眼可见的卡顿。解法是"保活"：用合成健康检查（synthetic health-check）周期性戳它，让通道恒热。

# 保活：每 60 秒发一笔零成本 tools/list，顶住通道缓存
async def keep_warm(client, interval=60):
    while True:
        await client.call("tools/list", {})
        await asyncio.sleep(interval)

优缺点：保活把 2.5 秒的尾延迟摊进后台，但意味着 MCP 服务器几乎不能真正"睡"，常驻进程、常驻连接、常驻内存。变现评估：冷启动优化 + 区域分布（美国源流量打美国服务器可省 100–300 毫秒）是给金融/客服这类延迟敏感场景做咨询的硬卖点。

三、schema 漂移税：syntax migrated, ownership not

这是六税里最阴险的一种。把函数 schema 换成 MCP 服务器，语法迁移了，但工具契约的所有权没有跟着迁移——没人对版本号、auth scope 漂移、回滚预案负责。栈3/栈4 的参数保真率从栈1 的 99.1% 掉到 98.1–98.2%，schema 漂移事故率从 0 涨到 0.8/百次，根因几乎都是：后端改了字段，MCP 服务器的 inputSchema 没同步发布，模型仍按旧 schema 填参，调用半成功半失败。

优缺点：MCP 让工具契约变成了"准公共 API"，好处是契约清晰可审计；代价是它强制你建立版本纪律——否则漂移就是必然。变现评估：可以包装成"MCP 迁移成熟度评估"产品，按四阶段打分（盘点 → 包装只读 → 治理 → 切换），企业最缺的就是这套 checklist。

四、采样反噬税：服务端反向调用 LLM 的 token 黑洞

MCP 有一个原生函数调用根本没有的能力——sampling：服务器可以反过来请求 host 的 LLM 替它完成一步推理。这架构上很美（工具不必自带模型 API key 就能动态判断），但它打开了一个 token 黑洞和一个新的注入面。栈2–栈4 的单任务 token 总耗比栈1 高出 1–3%，看似不大，但一旦某个工具在循环里反复采样，账单会指数级膨胀。更危险的是：被采样的内容若来自不可信来源（网页、工单、GitHub issue），就构成一条"工具回流藏指令"的新通道——和单纯的工具输出注入不同，sampling 让攻击者能驱动一次模型推理。

优缺点：sampling 让工具更"聪明"，但把不可控的 token 消耗和 prompt injection 风险塞进了调用链。变现评估：sampling 审计 + 配额闸门（每会话采样上限、敏感动作人工确认）是企业安全咨询的刚需。

五、陈旧工具面税：tools/list 的一次性契约幻觉

MCP 的卖点是"动态能力发现"——模型运行时才知道有哪些工具。但实测中，多数 host 只在会话开始时调一次 tools/list，之后不再刷新。如果服务器中途新增/改名/下线工具，模型仍在用过期的工具面，要么调用一个已不存在的工具，要么错过一个本可用的新工具。栈3/栈4 的选择准确率比栈1 略低（95.3–95.4% vs 96.2%），部分就是过期工具面导致的误选。这是"动态发现"承诺与现实之间的裂缝。

优缺点：动态发现降低了初始接入成本，但单次快照让它退化成"会话级静态契约"。变现评估：可作为"MCP 服务器工具生命周期治理"咨询的一部分，教企业做工具变更通知与客户端再发现协议。

六、选择保真税：描述经代理 round-trip 的失真

理论上，只要工具定义完整穿过 JSON-RPC 层，模型的选择逻辑不受传输方式影响——cordum 的判断"MCP 解决集成 sprawl 而非模型质量"在这里得到验证：栈1 到栈4 选择准确率只差 0.9 个百分点。但栈5（OpenAPI-as-tool）是个反面教材：它从 Swagger 自动生成工具描述，语意远不如手写描述精准，选择准确率直接掉到 91.4%，参数保真率也只有 95.8%。税不在协议，在描述质量。任何一个把 REST 端点机械转成工具的方案，都要先花人工把描述写好。

优缺点：OpenAPI 接入快，但默认形态会显著拉低 agent 质量；MCP 手写描述保真度高，但要写。变现评估："工具描述工程"是被严重低估的训练营题材——同一套工具，描述写得好与差，选择准确率能差 5 个百分点以上。

七、治理错位税：在 prompt 里写策略的灾难

六税里最贵的一种。大量团队把治理逻辑（谁能调写工具、危险动作要不要审批、结果要不要做输出安全检查）写进了 prompt 文本，而不是写进架构。cordum 的诊断一针见血："Teams migrate syntax but not ownership"——语法迁移了，所有权没迁移。结果是审计时拿不出"谁在何时调了哪个工具"的记录，回滚时没有版本锚点，权限粒度还停留在"整个 server 一把钥匙"。栈6（自研网关）的 schema 漂移事故率最低（0.1/百次），恰恰因为全栈自控、契约所有权唯一明确。

优缺点：把治理写进架构（policy gate 在派发前拦截）要前期投入，但它是生产可观测性的前提；写在 prompt 里省事，但失败会长期隐形。变现评估：MCP governance——预派发策略评估、审批闸门、输出安全、审计级可观测性——是整个 MCP 生态里最值钱的咨询位。

MCP 工具服务化架构与六税落点

flowchart LR
    U([用户]) --> H[Host<br/>会话/模型运行时]
    H -->|1. 选择工具| M[(LLM<br/>选择准确率基本不变)]
    M -->|2. tools/call| C[MCP Client<br/>状态会话]
    C ==>|3. JSON-RPC 序列化<br/>握手税 300-800ms| S[MCP Server]
    S -->|4. 执行| T[(实际工具<br/>DB/API/FS)]
    T -->|5. 结果| S
    S ==>|6. 回传| C
    C -->|7. 注入上下文| M
    S -.->|sampling 反向调用<br/>token 黑洞+注入面| M
    C -.->|tools/list 仅一次<br/>陈旧工具面税| S

    classDef tax fill:#ffe0e0,stroke:#c0392b,stroke-width:2px;
    class 3,6 tax;

红框的两段是稳态税源；两条虚线是隐蔽税源——sampling 反向调用 LLM（token + 安全），以及 tools/list 的单次快照（工具面陈旧）。模型选择本身不在收税路径上，这解释了为什么六栈质量差不大、成本差极大。

推荐方案

场景一：单一应用、亚百毫秒硬约束（如实时客服补全）。 直接用原生函数调用（栈1）。不要为了"上 MCP"而把每笔调用塞进 300–800 毫秒的过桥费——客户体感会立刻变慢。MCP 属于编排层，不属于请求-响应热路径。

场景二：工具需跨多 host 复用（Claude Desktop / IDE / 自研 agent 共用一套工具）。 用 MCP，且务必走栈4（Streamable HTTP + OAuth 2.1）。这是 2025-11 规范后的生产形态，OAuth 2.1 强制认证堵掉了早期那批暴露服务器（曾发现 492 个可被基础滥用的公开 MCP 服务器，CVE-2025-6514 通过一个 npm 包波及 43.7 万次下载）。

场景三：已有成熟 REST API 想快速接入 agent。 可以用栈5（OpenAPI-as-tool）做初版，但务必人工重写工具描述——否则选择准确率会从 96% 掉到 91%，这是整条链上最亏的一笔。

场景四：全栈自控、不想绑定任何生态。 栈6（自研 JSON-RPC 网关）冷启动仅 150 毫秒、漂移事故率最低，代价是你得自己维护契约版本与治理——省下的生态红利，要用工程纪律还。

横切建议：无论哪一栈，治理必须落架构而非 prompt——预派发 policy gate、每工具粒度最小权限、工具结果一律按不可信数据对待、幂等 + 分页 + 结构化错误。这四条比选哪个协议更决定你的 agent 在生产里能不能活。

参考来源

更多 AI 智能体实战拆解，关注爱卫生（微信：gprshome201101）。

概述