第 14 章 — 基准测试、测试与性能
LLM Primer IV: Designing AI Cognition with MCP 章节走读第十五篇,也是最后一篇。这一章里架构终于要回答那个不带感情的问题 — 系统真的能跑吗? — 答案通过真 benchmark、两种系统性故障、还有多数团队在上线那一天发现的十倍吞吐悬崖到来。
这一章为什么存在
一个被细心设计、被安全加固、被干净地包在框架里的协议,最后还是要回答那个不带感情的问题:这个系统真的能跑吗?Agent 解决了它该解决的任务吗?负载翻倍它还扛得住吗?把优雅退化变成宕机的那些性能悬崖在哪里?前面几章讲的是把架构搭对;这一章讲的是测一旦搭好了之后它有没有兑现。这一章走 MCP-Universe Benchmark — 第一份让真 LLM 在真 MCP server 上对练的公开测试 harness — benchmark 暴露的两种系统性故障和开始起作用的缓解,以及吞吐这一面,精心设计的会话池跟天真的每请求一会话之间差一个数量级。
14.1 MCP-Universe:在真 server 上测 agent
2024 年大半年到 2025 年初,公开 agent 评估住在一个奇怪的地方。工具使用 benchmark 测模型对合成 API 是否生成了语法正确的调用。Agent benchmark 测沙箱环境里的任务完成度。缺的是一份在 真 MCP server 上对模型练手的 benchmark,有真认证、真限流、真会漂的 schema、偶尔返回空结果的真工具。2025 年由 Salesforce AI Research 发布的 MCP-Universe 是第一次认真尝试。六个评估域跨十一个真生产 MCP server — Google Maps、GitHub、Yahoo Finance、Blender、Playwright、真搜索引擎 — 共 231 个任务,每个都配自动评估器,检查最终状态是否匹配预期结果,而不是检查模型在路上有没有发出 "对的" 工具调用。
头条结果跨模型刷新版都站得住。在合成 benchmark 上得分八十多的 Claude 3.5 Sonnet,在 MCP-Universe 整体只到四十到四十中。GPT-4o、Gemini 1.5 Pro、Llama-3 70B 各变体聚在类似区间。合成工具使用表现跟真 MCP 表现的差距大约绝对 40 分,光靠规模缩不掉。故障聚在几个能识别的类别里:工具输出填窗口时的长上下文退化;模型误读陌生 schema 时的未知工具探索;跨 server 协调时输出格式不匹配、没有语义桥;还有任务特定推理 — 模型挑对工具、调对、拿到对的答案,却没把工具输出整合进更大推理而到了错的最终结论。让 MCP-Universe 成为一份严肃工具的几个结构性决定是 基于执行的评估(对真 server 跑调用,不跟参考 trace 比),实时数据(活的市场数据,评估器追踪那次跑时正确答案是什么),多轮评估(评最终状态,不评每一步)。一个有用的副作用是 benchmark 间接成了 server 设计的质量信号,在乎 agent 表现的 server 作者现在有了公开靶子。
14.2 两个系统性挑战和起作用的方法
长上下文退化和未知工具探索是大到值得仔细处理的两种故障模式,因为缓解不显然。MCP agent 里的长上下文退化有特定形状:上下文被工具输出填满,这些输出在某种意义上 都 相关 — 每条都是模型选择去调的结果 — 但每条都很庞大,真正承重的那个事实很小。缓解作用在信息呈现这一层。工具结果摘要在原始工具输出落进 agent 上下文之前,用一个便宜模型(Haiku、GPT-4o-mini、Gemini Flash)过一遍;生产部署报告长上下文完成率提升 2 到 3 倍,单次调用成本由便宜模型主导。结构化工具输出在 JSON 载荷旁边带一个 summary 字段 — 2025 年协议修订里正式化 — 不用额外模型调用做类似的事。Agent 循环上的 上下文压缩配上一个能挺过压缩的 agent 管理 scratchpad,处理对话本身长到不行的情况;生产部署每 20 到 40 步触发一次压缩,保留约原上下文的三分之一。
未知工具探索有另一种形状。一个 agent 连上一个它没训练过的 server 时,模型最初几次调用常常失败 — 类型错、顺序错、有时候完全选错工具。缓解是在主循环之前加一个 探索阶段:框架让模型读每个工具的描述、总结它是干嘛的、生成一个示例调用、标出它不确定的参数。产出的笔记前置到 agent 上下文里。代价是会话开始时几次便宜调用;收益是 MCP-Universe 这类 benchmark 上 20 到 30 个百分点的完成率提升,加一份可审计的 "agent 自陈理解" 记录帮助归因后续故障。这个模式扩展到 变了 的工具:连接时哈希工具表面,哈希一变就跑预热,silent-drift 故障模式(server 更新了,agent 失效几周才有人察觉)就消失了。第三个相关问题值得起名:工具描述质量。很多 server 出货的描述是写给人开发者看的 — 简短、术语扎堆、假设上下文。把描述重写成 "面向一个从没见过这个系统的实习生",同样模型不改 agent 代码就能拿到可测的提升。模型对工具的唯一窗口就是描述,一段没法独立站住的描述产出一个用不了那个工具的模型。
14.3 会话池的吞吐悬崖
正确性只是故事的一半;生产现实是,让 agent 更快的设计选择常常对正确性有影响,反过来也一样。2025 到 2026 年 MCP 部署里最大的单项吞吐问题,是管 Streamable HTTP 会话的两种方式之间的差距,这差距大约是十比一。每请求一会话每次 agent 请求开一个新会话,里面跑工具调用,完成时关。共享会话池维持一个长寿会话池,每个请求从池里分一个。在标准 server 上以代表性工作负载跑,吞吐差距稳定落在大约十倍 — 每请求一会话每秒大约 30 个,池每秒大约 290 到 300 个,商用硬件。不知道这道差距的团队在上线那天踩硬:staging 跑得没事,生产上线撞上了会话创建开销主导请求速率的那堵墙。
机制很直接。会话创建很贵 — 状态分配、能力协商、凭据校验、清理注册、结构化日志 — 还有 MCP 级握手,传输绕不过的协议往返。每请求一会话每次请求都付这份费用;池一次会话付一次然后摊销。决定池在实践里能不能跑通的实现细节:隔离(每请求状态是会话内的子上下文,按请求建毁;每会话状态共享)、池大小(p95 并发数,加突发自动扩)、健康检查(空闲会话后台检查,分配时快速检查)、还有 请求亲和性,对状态跨多次调用的工具用粘性会话。叠在上面的,HTTP/2 或 HTTP/3 连接复用 — 一根底层连接载多个并发流 — 才产出引用的吞吐数;单独池一层只产出小得多的提升。长尾延迟那一面也重要:每请求一会话 server 因为创建时的不走运时刻有长尾延迟,池的尾很紧因为创建成本异步在请求热路径之外。P99 通常改善 3 到 4 倍 — 比吞吐改善更大,也是实际塑造用户体验的那个。
14.4 这一系列搭出了什么
四卷走过一条有意的弧线。第 I 卷讲模型内部。第 II 卷讲 prompt 和推理。第 III 卷讲检索增强生成。这一卷讲 agent 和工具,围绕 MCP 组织,因为 MCP 是让 agent 架构变连贯的技术衬底。三条线贯穿:第一是 认知与运维的分离 — 模型是认知层,框架和 MCP server 是运维层,大多数生产故障来自把两者塌成一团。第二是 有限的上下文预算 — 上下文是稀缺资源,产出可靠 agent 的架构选择是尊重这种稀缺的那些。第三是 协议即边界 — MCP 不只是一种线协议,还是一条能力流动、信任要被协商、未来演化要继续发生的边界。一个扛得住工程压力的协议会变成基础设施;MCP 看起来正在这么做。
第 IV 卷接下去会怎么走
这是本卷的最后一章,所以它铺垫的不是下一章,而是下一卷。LLM Primer V — 构建真实世界的 LLM 应用把第一到第四卷铺好的根基拿过去,装成具体的应用原型:软件工程助手、业务自动化 agent、垂直应用里的 copilot、自主研究工具。处理的重点会从底层机制(前面四卷覆盖了)转向应用级工程选择 — 怎么给一个 LLM 应用定范围让它可靠交付价值、怎么在生产里评估、怎么随着应用演化管 prompt、工具、记忆的生命周期。读完第 V 卷的读者,会走过从一个单注意力头到一个在真基础设施上的真 MCP server 栈上跑 agent 的部署应用的路径,带着 "为什么每一层是这么搭的" 的工程判断力。
系列继续:LLM Primer V — 构建真实世界的 LLM 应用。
