# 在一台机器上复现 17 宿主 × 153 server 的兼容矩阵

这篇不讨论结论，只记录怎么把矩阵跑出来。想验证「同一个 MCP server，换个宿主结论就反了」这句话，光看别人的截图没用，得自己在一台机器上把 2,601 个格子填一遍。

下面是 2026-11-02 那次全量采集的实施顺序：准备宿主、定样本、定判定、逐格跑、读表、验收。所有命令都在采集机上执行，单机单环境。

## 第 1 步 · 先把 17 个宿主的命令行入口凑齐

矩阵的行是宿主，行数不够，结论就不成立。这一步的产出不是「装好 17 个」，而是「明确哪几个装不上」。采集机最终在 15 个宿主上跑通了判定，codebuddy 与 opencode 两个宿主各自 153 格全部记为 na。

`na` = 没测到，原因是采集机没装这两个平台的命令行工具，不是「这两个宿主不可用」，也不能读成「一个都装不上」。这是整张表可信度的地基：na 若被当成 fail 统计，最下面两行就会从「没测到」变成 0%，结论全错。

准备阶段的验收：`--version` 能打印版本号，才算这个宿主可用；打印不出来的，直接在采集配置里标 na，不要试图用相近的宿主顶替。

## 第 2 步 · 定样本：161 条记录，剔掉 8 条

server 侧来自目录里可枚举、可安装的记录，共 161 条。其中 8 条标记为 `isFixture`，是自建测试桩，用来调试采集脚本的，不是真实条目，必须剔除。

161 - 8 = 153，这是矩阵的列数。测试桩响应写死，在任何宿主上都「能用」，算进 pass 会直接抹平要观察的差异。

判定格数随之确定：153 × 17 = 2,601，后面所有百分比都以它为分母。中途不要再改样本，加一个 server 就要重算全部格子。

## 第 3 步 · 定判定：四个值的边界

每一格只填一个值，四个值的定义要在跑之前写死：

- `pass`：这个 server 在这个宿主上装得上，并且能调起来
- `limited`：装上了，但有一块能力不可用（资源类能力不支持、工具数超过宿主上限、远程支持情况资料不足）
- `fail`：这次采集没跑通
- `na`：没测到，采集环境不具备测试条件

最容易混的是 `fail` 与 `na`，判据只有一条：测试动作有没有真的执行过。执行了没成功记 `fail`；根本没执行（工具不在、无凭据）记 `na`。需要 OAuth 的远程 server 在无凭据环境里应记 `na`，不是 `fail`。

另一条纪律：`fail` 只代表这一次没跑通，不代表该 server 永久不可用。版本、网络、宿主版本都会影响结果，所以结果表里要带采集时间。

## 第 4 步 · 逐格跑，得到 2,601 格

按「宿主 × server」两重循环跑，每格记录 usable 值、证据来源、失败原因。证据分文档推断、真机验证、协议实测三类，含测试桩口径下分别是 1,344 格、796 格、597 格；证据强度不同，读表时要能分辨。

汇总出来是这样：

| 判定 | 格数 | 占比 |
|---|---|---|
| pass | 1,339 | 51.5% |
| fail | 856 | 32.9% |
| limited | 55 | 2.1% |
| na | 351 | 13.5% |
| 合计 | 2,601 | 100% |

跑完先做一次对账：四类相加必须等于 2,601，占比相加必须是 100%。对不上就是有格子被重复计数或被漏掉，别急着解读。

## 第 5 步 · 怎么读这张表

顺序比结论重要，按 na → limited → fail 的次序看：

先看 na。351 格 na 里，codebuddy 与 opencode 各 153 格，其余 45 格是 15 个宿主每家 3 格。第一件事是把这两整行摘出去，它们不参与横向比较。

再看 limited。55 格不多，但信息密度最高：资源类能力不支持 30 格、工具数超过宿主上限 14 格、远程 MCP 支持情况资料不足 11 格。三类原因对应三种不同的处置方式，混在一起看会得出「兼容性差」这种没用的结论。

最后看 fail。856 格最大，也最容易被过度解读。看之前先确认分母：通过率的分母含 na，67.3% 那一档其实是 103/153；只算测到的 150 格则会整体上移。两种算法都能用，同一份材料里只能用一种。

## 第 6 步 · 验收点

跑完之后，按这六条自查，全过才算这张表可用：

1. 行数对得上：17 个宿主都有归属，装不上的记为 na 而不是删除整行
2. 列数对得上：153 列，且能追溯到 161 - 8 的剔除过程
3. 格数对得上：2,601，四类相加等于总数
4. na 有原因：每一格 na 都能说出「为什么没测到」，而不是笼统标注
5. limited 有分类：能拆到资源、工具数、远程资料三类，而不是一个笼统的「部分可用」
6. 结论带时间：所有百分比都绑定 2026-11-02 这个采集时间点

第 4 条最常被跳过。na 一旦变成「不知道为什么没测」，整行数据就失去了可解释性，后面谁都不敢用。

## 这次没覆盖的

单机单环境意味着企业代理、内网镜像、ARM 与 Windows 差异都没有覆盖；153 个 server 是目录里可枚举、可安装的那一批，不是 MCP 生态全集；需要 OAuth 的远程 server 在无凭据环境下只能记 na。要把这张表用于生产选型，还得在目标环境里补测一轮。

## 总结

矩阵的可信度不取决于 pass 有多少，而取决于 na 有没有被如实记录、fail 有没有被过度解读；宿主侧兼容性与配置差异见。

## 适合与不适合

**适合**：想在自己环境里复现一套兼容性矩阵的人；要给内部工具做横向评测、需要一套可验收流程的人；已经在用多宿主、想搞清楚 na 与 fail 该怎么区分的人。
**不适合**：只用同一个宿主、不需要横向对比的人；需要覆盖企业代理或内网镜像的人，这次的采集口径不覆盖；要求「装了就一定可用」的人，测出来的是概率分布，不是保证。

标签：MCP、DeepSeek Harness、宿主兼容、协议适配

本文由 DeepSeek Harness Hub 自动整理，数据来源于 MCP 采集快照（2026-11-02）。



这篇不讨论结论，只记录怎么把矩阵跑出来。想验证「同一个 MCP server，换个宿主结论就反了」这句话，光看别人的截图没用，得自己在一台机器上把 2,601 个格子填一遍。

在一台机器上复现 17 宿主 × 153 server 的兼容矩阵

测试

开发工具

架构设计

本文记录在一台机器上复现17宿主×153server的兼容性矩阵（共2,601格）的实施全流程，涵盖宿主准备、样本剔除（161条剔8条测试桩）、四值判定标准（pass/limited/fail/na）、逐格采集对账及验收六条自查。数据快照显示pass占51.5%、fail占32.9%，na占13.5%且需区分未测与失败，适合需自建兼容评测流程的团队参考。

命令行工具

CodeBuddy

Windows

OAuth

快速部署LLM、AI绘画等应用,助你玩转AIGC！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

本文记录在一台机器上复现17宿主×153server的兼容性矩阵（共2,601格）的实施全流程，涵盖宿主准备、样本剔除（161条剔8条测试桩）、四值判定标准（pass/limited/fail/na）、逐格采集对账及验收六条自查。数据快照显示pass占51.5%、fail占32.9%，na占13.5%且需区分未测与失败...

在一台机器上复现 17 宿主 × 153 server 的兼容矩阵-腾讯云开发者社区-腾讯云

在一台机器上复现 17 宿主 × 153 server 的兼容矩阵

在一台机器上复现 17 宿主 × 153 server 的兼容矩阵

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐