MCP 冷启动税：工具服务器开销如何在智能体第 7 步发生累加

一个 200 毫秒的工具调用在火焰图（flame graph）上看起来就像是杂音。但在 Agent 循环中堆叠七个这样的调用，杂音就变成了信号 —— 模型在 800 毫秒内完成了思考，但用户却等待了 4.5 秒，因为每一次工具调用都在重新支付首个调用已经吸收掉的启动成本。残酷之处在于，这种成本在任何单一的追踪（trace）中都不会显示为异常。它表现为干脆利落的 Demo 与反应迟缓的生产环境 Agent 之间的差异，而大多数团队会将其归咎于模型。

Model Context Protocol (MCP) 已成为 Agent 工具链的默认集成界面，这意味着它也成了延迟（latency）堆积的重灾区。MCP 的设计 —— 基于 stdio 或可流式 HTTP 的 JSON-RPC、能力协商（capability negotiation）、动态工具发现 —— 对于一个必须桥接任意客户端和服务器的协议来说是正确的。但它隐含的单次调用成本结构对于 Agent 实际的访问模式并不友好。Agent 的模式不是“每个会话调用一次工具”，而是“每轮对话调用七个工具，每个会话进行四十轮对话”。

这篇文章将探讨这种错配：冷启动税究竟存在于何处，为什么它在长生命周期的 Agent 中是叠加而非被摊销（amortize）的，以及如何通过“预热池”（warm-pool）规范将数秒的惩罚降低到 100 毫秒以下。

“冷”工具调用的三层叠加成本

当 Agent 在会话中决定首次调用远程 MCP 工具时，会依次发生三次握手，每一次在孤立来看都是合理的。

首先是 传输层握手（transport handshake）。如果服务器基于可流式 HTTP，则涉及 TCP 建立连接，然后是 TLS —— 而没有会话恢复（session resumption）的 TLS 需要一个完整的往返（round-trip）加上密钥派生。在跨区域调用中，这在传输单个字节的有用负载之前就需要 80–150 毫秒。如果认证流程中途还需要刷新 OAuth 令牌，则需再加上一次到身份提供商（identity provider）的往返。

其次是 MCP 能力协商（capability negotiation）。客户端发送 initialize，服务器响应其支持的协议版本和能力，客户端发送 initialized，只有在这之后会话才可用于工具调用。对于健康的服务器，这通常在 100 毫秒以内，但它是强制性且串行的 —— 客户端无法在协商完成之前提前流水线化（pipeline）一个 tools/call 请求。

第三是 工具发现和 Schema 获取。tools/list 会返回服务器暴露的所有工具目录，以及每个工具完整的 JSON Schema。对于发布了四十个带有丰富 Schema 的工具的服务器，响应可能达到几十 KB，且服务器可能需要进行实际工作来组装它 —— 查询下游注册表、计算 Schema 片段、实例化示例。像 OpenAI Agents SDK 这样的框架默认会在每次 Agent 运行时调用 list_tools()，这意味着除非开发者显式选择 cache_tools_list，否则这项成本会反复发生。

将这三者相加，进入远程 MCP 服务器的新会话通常在得到第一个有用的工具结果之前，就已经消耗了 400–900 毫秒。一个通过在全新客户端运行单次工具调用来基准测试（benchmark）“工具延迟”的团队，实际上测量的是这整个堆栈，并将其归功于工具本身。而测量第二次调用的团队会得到一个快了十倍的数字，并得出 —— 错误地 —— 协议很快的结论。

为什么第 7 步才是最痛的地方

冷启动成本在每个连接（connection）中只支付一次，而不是每次调用，因此直觉认为在任何进行多次工具调用的会话中，它都会被摊销掉。但在真实的 Agent 工作负载中，这种直觉是错误的，原因有三点。

第一，Agent 会话触达的是多个服务器，而非一个。一个研究型 Agent 可能会在单个用户轮次中，分别从搜索 MCP、日历 MCP、向量库 MCP、代码执行 MCP 和文件系统 MCP 中提取信息。其中每一个都是独立的连接，都有自己的冷启动。会话在一个服务器内部摊销成本，但每次跨越到新服务器时都要支付全额费用，而现代 Agent 堆栈通常会联合（federate）五到十个服务器。

第二，框架会激进地拆除连接。许多客户端实现基于“会话是廉价的”这一假设，为每个 Agent 运行（run）而不是每个进程（process）开启一个 MCP 会话。一旦你支付了成本，它们确实很廉价 —— 但“拆除”连接的行为让它们变得昂贵。新的运行、新的工具调用、全新的握手。如果你的控制台为每个任务生成一个子进程（subprocess），那么每个子进程在与其通信的每个服务器进行首次调用时，都要支付全额税费。

第三，也是团队最容易低估的一点，就是 Token 预算驱动的 Schema 重新加载。随着 Agent 在长会话中积累上下文，框架会压缩或剔除消息，而工具 Schema（可能非常庞大）也会随之被剔除。下次调用时需要将 Schema 重新放回上下文中，这迫使在名义上已经预热的连接上重新进行获取。该连接在传输层是热的，但在协议层是冷的，而这种延迟差异对于仅关注传输层的健康检查是不可见的。

在多服务器 Agent 循环的第 7 步，你通常已经支付了两到四次冷启动税，而这在评估延迟预算时往往是预料之外的。模型在不到一秒内完成其轮次；用户却感到了五秒的延迟；追踪（trace）将其归咎于“工具执行时间”，因为截断发生在任何人看到协商开销之前。

大多数团队未追踪的延迟预算

加载中…