这次不是事后复盘，是把失败写进出题方式
11 月 5 日提交到 arXiv 的一篇论文，做了件和主流 MCP 基准不太一样的事。编号 2611.07689 的 MCPHallu 由 Yizhen Jiang 等九位作者署名，它不打算再比一次「任务做完没有」，而是在构造每一道题的时候，就先埋好一个会让智能体出错的结构。用论文的话说，已有 MCP 基准大多测任务完成度，就算诊断失败，也是跑完之后回头找原因；MCPHallu 把推理、执行、记忆三类失败风险直接做进题目里。
规模摆出来比较直观：358 个任务，覆盖五个能力域，跑在 36 个隔离容器里的生产 MCP 服务器上；每道题带一个结构触发器，让四类失败里的某一种成为主要风险——分支塌缩（Branch Collapse）、目标不可达（Unreachable Goal）、工具误用（Tool Misuse）、上下文遗忘（Context Forgetting）。团队拿来自八家厂商的 14 个前沿模型智能体跑了 5012 条轨迹，论文页面未点名具体是哪些模型，也没列出作者所属机构，这两处先记着，后面说分寸。
总成绩不算好看：在 0 到 1 的区间上平均得分 0.642。更值得盯的是「目标不可达」这一类，均分掉到 0.458，只有 23.2% 的运行算通过。论文给的解释很具体——碰到根本达不成的目标，智能体往往继续一轮轮发工具调用，或者干脆宣称任务已完成，而不是识别出这事儿办不成。干过运维的人对这个画面应该不陌生：日志刷得挺热闹，其实一步也没往前挪。
一个总分，撑不起选型这件事
单个数字看着平平，真正有增量的是后面那组排名分析。论文发现，同一个模型换一类失败，名次平均要移动 6.9 位，而总共只有 13 个名次；分支塌缩和目标不可达这两类，跨模型的相关系数是 -0.12，基本可以说不相关。翻成大白话：在 A 类坑里稳的那个模型，换到 B 类坑未必还稳，用一条聚合分给智能体排座次的做法，在这里站不住。
这对采购和架构选型的影响比论文标题大。过去大家习惯问「哪家模型在 MCP 榜单上分数高」，现在更该问的是「我的业务里最常出现哪一类失败」。做客服的怕上下文遗忘，做自动化的怕工具误用，跑长链路的怕目标不可达——三条完全不同的防线，却可能被同一个总分糊过去。顺带一提，这套做法和站内 11 月初那几篇评测研究能连起来：2187 那篇讲评测单位该从任务终点沉到过程动作，MCPHallu 则把这一步再往前推，让失败类型在出题阶段就带上标签。两者不是一回事，但方向是接得上的。
和 FixedBench 那道题，隔着一层
容易混淆的是另一篇讲行动偏置的研究。1750 号那篇 FixedBench 用 200 个人工核验的编码任务测出：任务本身压根不需要改代码，五个模型跨四套 harness 仍有 35% 到 65% 的概率提出多余改动。那说的是「不该动手却动了」，偏行为倾向；MCPHallu 的目标不可达是「条件根本不成立，却不肯承认」，偏环境判断。一个管手，一个管脑，凑在一起才把「停不下来」这件事画完整。
还有个位置问题值得留意：MCPHallu 把服务器放在隔离容器里跑，测的是真实生产 MCP 服务器的行为，不是模拟接口。这比拿假工具列表打分更接近线上，但也带来一个绕不开的麻烦——MCP 服务器会升级、工具描述会变，今天测出来的 0.642，过两个月未必还能复现。基准本身也需要版本管理，这个话题目前讨论得不多。
冷水：能读出的和读不出的，得分开
分寸说清楚。上述数字全部来自论文自述，属于作者团队自己的评测，没有第三方复现；14 个被测模型没有点名，八家厂商也未列出，读者没法按自家在用的模型去对号入座；0.642 这个分数缺少可比的基线，说不上是进步还是退步；358 个任务是构造出来的，与线上真实流量分布有多大差距，论文没有给对照。GitHub 上放了名为 mcp_hallu 的实现，但公开材料里没看到不同服务器版本下的稳定性数据。
所以能拿走的是方法，不是排名。把失败分型、按型出题、按型看分，这个思路值得抄进自己的评测集；至于「哪个模型更强」，这篇论文回答不了，也不该由它来回答。厂商选型时更要紧的是拿自己的工具链和自己的失败样本重跑一遍。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。