实验设置：三因子 × 300 任务 × 10,800 次
作者来自巴西互联网络信息中心 NIC.br（其中一位同时任职于 PUC-SP）。他们构建了一个名为 MASTIF（Multi-Agent System TestIng Framework）的评测系统，用来回答一个工程味很重的问题：对一个大模型智能体来说，决定结果的到底是模型、协议还是框架？
实验设计是标准的多因子对照。任务侧从 Mind2Web 基准的 2,350 个任务中做分层抽样，取 300 个，每个条件都跑这同一批任务，因此规模是 3 × 3 × 4 × 300 = 10,800 次执行，与论文自述一致。判分使用 GPT-4o-mini——刻意选择了与所有被测系统都不同模型家族的裁判，以抑制自偏好偏差。代码、实验配置与日志在 github.com/cewebbr/mastif 全部公开。
| 因子 | 取值 |
|---|---|
| 模型（3） | Mistral-7B-Instruct、Qwen2.5-7B、Llama-4-Scout-17B-16E |
| 通信方式（3） | 标准调用（standard）、MCP、A2A |
| 实现框架（4） | LangChain、LangGraph、CrewAI、Semantic Kernel |
| 任务（300） | Mind2Web 分层抽样，取自 2,350 个任务 |
| 裁判 | GPT-4o-mini（与被测系统不同模型家族） |
| 总执行次数 | 10,800 |
这里要提醒一句：三个模型都是 7B 到 17B 量级的开源权重模型，没有前沿闭源模型参与。这个选择让实验成本可控、可复现，但也意味着结论不能直接外推到旗舰模型上——协议的固定开销相对于强模型的长上下文与高纠错能力，占比可能完全不同。
三个因素都显著，但量级差了一个数量级
作者用 Kruskal-Wallis 检验（并报告 Shapiro-Wilk 与 Dunn 事后检验）分别检验三个因子对任务完成率（TCR）的影响，结果如下：
| 因子 | Kruskal-Wallis H | p 值 | 相对量级（以协议为 1） |
|---|---|---|---|
| 框架 | 6039.3 | < 0.001 | 约 14.1 倍 |
| 模型 | 1203.3 | < 0.001 | 约 2.8 倍 |
| 协议 | 428.8 | < 0.001 | 1 |
这是本次横评中含金量最高的一张表。过去两年行业讨论的焦点大量集中在协议层——MCP 还是 A2A、要不要上协议、协议会不会成为标准。但在这个受控实验里，协议确实显著，却只有框架因素的约十四分之一。用一句更直白的话讲：换框架比换协议更值得先做实验。
三个因子的 p 值都小于 0.001，统计上都是显著效应。但 H 统计量相差一个数量级，说明它们解释的方差份额完全不同。工程排期时真正该问的不是「协议有没有影响」（有），而是「在同样一天的工程时间里，调哪一层收益更大」（按本实验是框架，其次模型）。
MCP 悖论：工具用得更多，任务做得更少
把论文 Table 2 的 36 个格子按模型求平均（该平均由二次分析方计算，并非论文直接给出的数字），得到一个清晰的规律：MCP 条件下，三款模型的任务完成率都低于标准调用。
| 模型 | 标准调用 | MCP | A2A | 标准→MCP 差值 |
|---|---|---|---|---|
| Mistral-7B-Instruct | 66.3% | 62.8% | 65.0% | −3.5 分 |
| Qwen2.5-7B | 75.8% | 53.4% | 68.2% | −22.4 分 |
| Llama-4-Scout-17B-16E | 48.1% | 39.4% | 52.2% | −8.7 分 |
与之形成对照的是工具使用成功率：在 Table 4 中，MCP + Semantic Kernel 组合达到 68.1%，是全部组合里工具使用成功率最高的一个。也就是说，加了一层协议之后，模型确实更频繁、更规范地调用了工具，但把这些调用串成一条能走到终点的路径的能力反而下降了。
论文在 6.3 节提到了这个现象，但二次分析方认为作者低估了它：把「选对了工具」和「做完了任务」分开测，正是这份基线评估真正的价值所在。对工程团队而言，这个分离直接对应两类不同的失败——工具选择错误要去改描述与模式，而任务中断要去改编排与上下文预算，二者不该混为一谈。
协议效应随模型而变：−3.5 到 −22.4 分
上表最后一列还藏着一条容易被忽略的信息：同一个协议改动，在三款模型上造成的完成率变化相差六倍以上（−3.5 分、−8.7 分、−22.4 分）。这说明协议开销不是一笔固定税，而是与模型的行为特征耦合在一起。
Qwen2.5-7B 受影响最重，一个合理的解释方向是：它本来在标准调用下完成率最高（75.8%），意味着它更依赖多轮工具调用来完成任务，因此协议层带来的额外轮次、格式与上下文占用，正好打在它最敏感的地方。需要强调的是，这是本文基于公开数据提出的解释性推测，论文本身并未给出因果归因。
框架因素：79.5% 与 53.7% 之间只差一个协议
把观察粒度下移到单个组合，能看到本次实验中最陡的一处落差：Qwen2.5-7B 在标准调用 + LangChain 下取得 79.5% 的完成率（标准差 0.157），是 Table 2 中分数最高的单个格子；换成 MCP + LangChain 后掉到 53.7%（标准差 0.278）。
| 组合 | 任务完成率 | 标准差 |
|---|---|---|
| Qwen2.5-7B + 标准调用 + LangChain | 79.5% | 0.157 |
| Qwen2.5-7B + 标准调用 + Semantic Kernel（按平均秩最优） | 论文 Table 6 列为完成率维度的最佳因子组合 | 论文未在同表给出对应单元格值 |
| Qwen2.5-7B + MCP + LangChain | 53.7% | 0.278 |
| Qwen2.5-7B + MCP + Semantic Kernel | 工具使用成功率 68.1%（全表最高） | 论文未在同表给出完成率 |
标准差的变化同样值得记下来：从 0.157 升到 0.278。协议层不只在平均意义上降低了完成率，还让结果更不稳定。对线上系统来说，方差变大往往比均值下降更麻烦——它意味着尾部的坏体验会增多，而你无法用平均值把它掩盖掉。
工具使用率：只有一个模型愿意把调用外显
Table 4 有一个必须说明的前提：三款模型里，只有 Qwen2.5-7B 真正把工具调用外显出来了，另外两款没有产生可供统计的外部化工具调用。因此工具使用率这一组结果，实际上把模型效应与协议/框架效应混在了一起，不能当作独立的协议结论来读。
这一条也提醒我们：所谓「MCP 提高了工具使用率」这个结论，证据基础只有一款模型、一张表。它可以作为方向性提示，但不足以支撑「上 MCP 就能提升工具使用」这样的工程决策。
「最佳组合表」的两种赢法不要混读
论文 Table 6 给出了「按指标的最佳技术栈」，在完成率维度上以平均秩为标准选出 Qwen2.5-7B + 标准调用 + Semantic Kernel。但在 Table 2 里，单个格子的最高分是 Qwen2.5-7B + 标准调用 + LangChain 的 79.5%。
这是两个不同的问题：前者问的是「哪个因子水平在整体上最稳」，后者问的是「哪一次实测分数最高」。一支只看 Table 6 就选框架的团队，最终拿到的是按平均秩的胜出者，而不是那个 79.5% 的实测最高分。在自己的基准里做同样的表时，两种口径应该都列出并标明。
生态层面的旁证：8,060 个 MCP 服务器
为什么加一层协议反而拖慢完成率？论文没有给因果解释，但同期研究提供了一个生态层面的旁证：Guo 等人 2025 年对 MCP 生态的实测研究（arXiv:2509.25292）测量了 8,060 个 MCP 服务器，发现其中超过一半属于低质量或已弃用。两份研究测量的对象不同，不能直接互证，但如果智能体在真实生态里要面对大量描述含糊、模式不一致甚至已经失效的工具，那么「协议层引入的开销无法被工具质量红利抵消」就是一个说得通的假设。
另一条同期旁证来自对工具元数据的大规模实验（arXiv:2610.14334，经 Ramsay Research Agent 于 10 月 14 日汇总转述）：在 367,174 个 MCP 工具上逐项改变元数据，参数模式（schema）造成的模型选择偏移最大且最一致，模型偏好分离的顶层参数而非分组或复合参数，而工具名称的影响很弱。若该结论成立，团队优化 MCP 服务器时的优先级应当是「压平参数、在描述里解释清楚」，而不是反复改名。需说明的是，这两条旁证均来自单一汇总源的转述，本文未能逐篇核验原文表格。
方法学边界与口径红线
- 协议对比只模拟消息格式。作者在 7.4 节明确说明，协议条件模拟的是「消息如何交换」，并没有运行真实的 MCP/A2A 服务器，因此实际部署中的模式注入开销与握手成本可能未被计入。这意味着 MCP 的真实代价可能比本实验测到的更高，而不是更低。
- 预印本，未经同行评审。arXiv:2610.13703v1 于 2026 年 10 月 9 日提交，发表venue 字段为空，采用 CC BY 4.0 许可。
- 资助方与作者机构重叠。NIC.br 是巴西的非营利互联网治理机构，本项目由其资助，且全部作者均受雇于资助方。没有外部赞助方，但存在机构利益关联。反过来，完整公开代码、配置与日志是可复现性上的加分项。
- 工具使用结论的模型混淆。如前所述，仅一款模型外显了工具调用。
- 模型量级偏小。被测模型为 7B–17B 开源权重模型，结论不宜直接外推到旗舰闭源模型。
四条读榜检查与工程建议
- 把协议当作可选项而非默认项。不要因为 MCP 或 A2A 「是标准」就接入；先在自己的任务集上同时测完成率与工具使用率。
- 模型与协议必须联合评测。本实验中协议效应随模型在 −3.5 到 −22.4 分之间摆动，换模型就要重测。
- 看方差，不只看到均值。MCP 条件下标准差从 0.157 升到 0.278，尾部风险上升是线上系统更难承受的部分。
- 用真实服务器复核协议开销。本实验只模拟消息格式，模式注入与握手成本需单独测量；同时把 Token 消耗与收敛时间作为与准确率并列的指标，这也是 Kapoor 等人 2024 年在《AI Agents That Matter》中提出的成本控制主张。
综合判断
这份基线评估的贡献不是提出新技术，而是提出一种立场：把智能体网络技术栈当成需要测量的东西，而不是需要默认接受的东西。在 10,800 次执行里，模型、协议、框架三个因素都统计显著，但框架的影响量级压倒性领先；MCP 在提高工具使用的同时压低了任务完成率，且这个效应随模型而异。
考虑到协议仅被模拟、资助方与作者机构重叠、以及只有中低量级开源模型参与，这些数字最合适的用法是：作为「上协议之前先自己测一遍」的方向性依据，而不是作为选型结论。对多数团队而言，立刻可做的一件事是把手上那套栈按同样的三因子方式跑一轮小规模对照——300 个任务、几十美元成本，就能知道自己那一层的真实排序。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。