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

关于 Agent 回合（turn）的标准延迟说法是：模型推理占主导，工具执行是不确定的，其他一切都是舍入误差。这个说法对于聊天补全（chat completions）是正确的，但对于使用工具的 Agent 则是错误的。发布的预算细分显示，LLM 推理占 Agent 回合的 45–60%，而工具执行占 5–70% —— 这个巨大的范围就是破绽所在。这种差异几乎完全存在于工具层的单次调用开销（per-call overhead）中。

团队需要追踪的应该是一个双轴预算：单次调用延迟（per-call latency）和单次循环延迟（per-loop latency），并对两者进行清晰的分离。

单次调用延迟是传统视角：从发送 tools/call 到接收结果耗时多久。这是大多数可观测性平台默认显示的指标，它很必要但并不充分。单次循环延迟是 Agent 从用户输入到用户可见响应的实际耗时（wall-clock），包括每一次工具调用的开销、每一轮模型交互，以及框架在它们之间强加的每一个停顿。单次循环延迟与单次调用延迟总和的比率，就是框架所强加的乘数 —— 在冷启动密集的会话中，这个乘数可能是 3 倍或 4 倍。

在单次调用内部，你需要进一步拆分，而几乎没有任何现成的插桩库能直接提供这些：冷连接设置、MCP 协商、Schema 获取、载荷传输、服务端执行和响应解析。如果你看不见这些阶段，你就无法判断你的工具调用慢是因为下游 API 慢，还是因为你重新进行了握手。将它们视为一个数字会确保你在错误的层级进行优化。

必然的结论是：在工具密集型的 Agent 中，更快的模型并不能带来团队预期的收益。在一个包含 7 次工具调用和 2 次冷启动的回合中，将模型时间从 800ms 减少到 400ms，在总共 4500ms 中仅节省了 400ms —— 不到 10%。团队经常升级到更小、更快的模型，然后报告说 Agent “感觉没变化”，进而得出结论认为模型不是瓶颈。他们是对的，但原因错了。模型不是瓶颈，是因为瓶颈一直存在于工具 RPC 层，任何模型更换都无法解决它。

温池架构的具体实现​

修复方法并不复杂，但需要大多数 Agent 框架（harnesses）都会略过的纪律。该模式有四个组成部分，跳过其中任何一个都会留下一个大洞，让冷启动再次钻进来。

预连接会话池，作用域限定在框架生命周期内。 在进程启动时开启 MCP 会话，在 Agent 运行器的整个生命周期内保持开启，并将所有 Agent 运行路由到共享池中。成本是每个池化连接占用几十 KB 的驻留内存，以及一个用于在服务端空闲超时后保持活跃的 Pinger。收益是没有任何 Agent 运行需要支付传输层握手的代价。对于长驻守护进程，这很直接；对于无服务器（serverless）部署，这需要预置并发，或者接受扩容后的第一次调用需要支付这笔“税”。

基于版本锁定的 Schema 缓存失效。 缓存 tools/list 的响应，以服务端标识和版本为键，并且仅在服务端宣布版本更新时才失效（通过 notifications/tools/list_changed 通知，该通知在规范中正是为此目的而存在的）。不要仅根据 TTL 进行缓存 —— TTL 要么过期太频繁导致不必要的重新获取，要么过期太慢导致在服务端工具更改后仍提供旧的 Schema。版本锁定是在部分和全部服务端升级情况下唯一安全的纪律。

具备截止日期感知能力的身份验证令牌复用。 OAuth 令牌有有效期；最糟糕的模式是在过期后的第一次调用时进行延迟刷新，因为那次调用除了自身工作外，还必须支付 IdP 的往返时间。正确的模式是在令牌寿命的 80% 左右（例如）通过后台任务主动刷新，这样任何面向用户的调用都不会等待 IdP。这是一个五行的代码改动，却能为刚好落在刷新窗口内的调用稳定节省数十到数百毫秒。

针对已知服务端的预先 DNS 解析和连接预热。 如果你的 Agent 工具目录在启动时是固定的，请在启动时解析每个已知服务端主机名的 DNS 并预热连接池。在缓存已热的工作站上，DNS 解析看起来是免费的，但在没有解析器状态的新容器上，它需要 30–80ms。对于水平扩展且频繁出现新容器的 Agent 来说，这是真金白银的成本。

结合这些措施，单次循环延迟将不再取决于循环中发生了多少次新的握手，而是取决于实际的服务端工作 —— 这才是用户真正关心的唯一事情。

生产环境中“快速工具调用”的真正含义​

当 Agent 感觉慢时，诱惑在于升级模型或并行化工具调用。两者有时都是正确的。但两者都无法解决冷启动税，也无法在温池失效的栈中消除症状。

真正起作用的诊断方法是监测单次调用的各个阶段 —— 握手、协商、Schema 获取、主体（body） —— 并查看过去一小时生产流量中每个工具服务端的冷启动命中率。如果任何你频繁调用的服务端冷启动命中率超过 10%，说明你的温池架构已损坏或缺失。如果冷启动命中率是个位数，但单次循环延迟仍然很高，那么问题出在 MCP 之下，模型才是一个更合理的目标。如果没有这种拆分，每个团队都会先优化模型，然后在第二个性能项目中重新发现协议层。

更深层的架构点在于，Agent 的工具层是一个分布式系统，其访问模式不同于任何单次触发的 API 客户端。它是高频、多服务器、对长尾延迟敏感的，且在一轮交互中是串行的。为任意客户端设计的协议默认不会针对这种模式进行优化 —— 优化必须由框架在顶层添加。跳过这一层的团队是在用一个本质上“话痨型”的客户端去对接一个本质上“面向会话”的协议，冷启动税就是每七步就要结一次的账单。

好消息是，这种纪律是一劳永逸的工作。一旦构建了温池、连接了 Schema 缓存并存在各阶段的指标，Agent 的感知速度就会变成模型质量和服务端执行的函数 —— 这两点是团队真正可以推理的。在此之前，模型并不慢，慢的是协议，而你只是在每一次循环中为此买单。