367 格 na 只有两种成因，没有一格是认证失败

367 格 na 只有两种成因，没有一格是认证失败

打开 MCP 兼容矩阵，第一眼看到的通常是绿色和红色，很少有人先数灰色。但 2,737 格里那 367 格灰色恰恰是最容易被误读的部分——它既不是失败，也不是成功，而是「没有结论」。

「没有结论」在运维语境里经常被下意识翻译成「大概是不行」，于是 na 被并进 fail 一起算，通过率被压到 52.5%。反向的错法也存在：把 na 当「没报错就是没问题」，通过率虚高到 65.9%。两个数相差 13.4 个百分点，而它们描述的是同一份数据。

把 367 格逐格查一遍备注，只有两种成因，没有第三种。矩阵本身的逐格分布可以对照 MCP 兼容矩阵，宿主侧的规则表在 宿主能力表。

322 格：两列整列没有测

第一种成因占了绝大部分。codebuddy 和 opencode 两列各有 161 格，全部是未测，备注统一是「本次没测到：采集机没装这个平台的命令行工具」。

161 乘 2 等于 322。这两列不是抽查漏了几格，是整列没开始——采集机上没有装那两家的 CLI，连版本号字段都是空的。所以这两列的信息量为零，任何以它们为分母的比率都没有意义。

一个具体的错法：把这两列的 na 并进失败一起算，真机层的通过率会从 188 / 474 = 39.7% 变成 188 / 796 = 23.6%，凭空掉 16.1 个百分点。这 322 格不代表「这两家兼容性差」，只代表采集机缺两个工具。补装之后整列是能重跑的，这也是它和真失败最本质的区别：na 可复测，fail 需要改东西。

45 格：三个远程服务连不上

第二种成因只有 45 格，分布很规律：3 个 server × 15 列。17 列减去 codebuddy、opencode 那两列全空的，正好 15 列——也就是说，凡是真正参与判定的列，这 3 个条目全是 na，无一例外。

这 3 个条目是 free-agent-tools、huggingface、sentry，全部是远程 HTTP 服务，工具数都是 0，启动耗时都是 0。它们的格子备注写得很直白：「本机网络连不上这个服务，未取得结论」。

这句话必须原样理解。它不是「服务拒绝了我」，不是「token 无效」，也不是「协议版本不匹配」——是采集机所在的网络到不了那个地址。换一台能出网的机器，这 45 格大概率会变成有结论的格子，可能绿也可能红，但现在两者都无从判断。

顺带一个反直觉的观察：161 个 server 里，声明需要认证的只有 1 个（sentry），而它恰好就在这 45 格 na 里。也就是说，本期数据里「认证失败」这张牌一次都没被打出过——1,299 格非 pass 的格子里，没有一格的备注提到认证、授权或凭据。

归零的第三种可能

理论上 na 还有第三种来源：能连上但需要授权、采集时没带凭据。这在本期数据里出现 0 次，原因是 authRequired 为真的条目只有 sentry 一个，而它卡在网络层，压根没走到鉴权。

这个 0 值得记住，因为它推翻了一种常见的排错惯性：看到灰格先怀疑 token。在这批数据里，灰格要么是工具没装，要么是网不通，跟鉴权无关。把灰格当鉴权问题排查，方向从一开始就是错的。

同一个矩阵的三个通过率

na 怎么处置，直接决定结论。三种算法都能自圆其说，但只有一个适合对外引用。

实测三种算法的差值是 8.2 与 5.2 个百分点，合计 13.4。这个量级足以让同一批数据得出「一半能用」和「三分之二能用」两种相反的印象。

我的取法是第二种：367 格 na 从分母里剔除，只用 2,370 格有结论的格子算比率，同时在正文里把剔除量写清楚。理由是 na 的成因是两个可修复的采集条件，它既不证明条目差，也不证明条目好，让它参与分母等于给结论掺噪声。

需要注意的是，分层之后 na 的分布并不均匀。实测 796 格真机格里 322 格是 na（40.5%），因为两列全空都在真机层；而 1,344 格文档格里 0 格 na，597 格协议格里 45 格 na（7.5%）。所以「真机层通过率 39.7%」这个数，分母已经是剔过 na 的 474 格，不是 796 格——引用时若把 796 当分母，会算成 23.6%，那是另一个问题的答案。

三条读 na 的规则

第一，先看 na 是整列还是零散。整列 na 说明采集条件缺失，这条轴直接不参与横向比较；零散 na 才是条目级问题。

第二，看备注原文，不要看颜色。灰格背后可能是「没装工具」「网不通」「跳过」，三者的处置完全不同，而它们在图上长得一模一样。

第三，任何对外引用的通过率都要带分母和 na 处置方式。只报 52.5% 或只报 60.7% 都是不完整的，读者无法判断你排除了什么。

如果你正卡在某一条目上，先区分它是 na 还是 fail——不确定的话从 排查方法 的症状对照表入手；条目级的坑点按现象归在 坑点清单。像 server-memory 这种本地进程类条目，通常不会落在 na 里，出问题就是真 fail，可以直接进真机层排查。

数据口径

全部数字取自 2026-11-02T19:53:24Z 生成的全量快照，mode=full、finalChunk=true、collectorVersion=dev，161 个 server × 17 个宿主 = 2,737 格。真机列对应的命令行版本为 claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80；codebuddy 与 opencode 版本为空，即未安装。

「本机网络连不上」是采集侧的原话，属单机网络条件下的观测，不构成对那 3 个远程服务可用性的判断，也不代表国内网络普遍不通。凡涉及宿主能力边界的结论，来自 宿主能力表，证据档位最高为「规则推导」，与真机实测不可混用。字段与状态值的定义见 名词表。