# 空机器到一张兼容矩阵，MCP 探测机的搭建记录

机器是 2026-11-02 开的，2 核 4G，Ubuntu 24.04，系统盘 60 GB。当天晚上跑完全量，落库 2,737 格。下面按我敲命令的顺序写，每一步给一个验收点；验不过就别往下走，后面所有数都会歪。

## 第 0 步 · 先把口径落在纸面上

开机器之前先写七个值：非 fixture server 153 个（原始 161 个里剔掉 8 个 fixture）、宿主 17 个、总格 2,737、采集时间 2026-11-02T19:53:24.631Z、mode 为 full、collectorVersion 为 dev、Node 为 v22.23.2。

这七个数不是交代背景，是后面每一步的校验基准。少写一个，三天后回看数据就不知道它是在什么条件下采的。

验收点：README 里七个值齐全，并且「153 与 17 两两组合、最终落库 2,737 格」这句话自己能解释清楚——为什么不是整整齐齐的乘积，因为有些格子根本没有数据。这一句写不清，说明还没想明白自己在采什么。

## 第 1 步 · Node 钉在采集机那一版

```bash
. "$HOME/.nvm/nvm.sh"
nvm install 22.23.2
nvm alias default 22.23.2
node -v && npx --version
```

验收点三条：`node -v` 打出 v22.23.2；`npx --version` 有输出；`which node` 落在版本管理器目录下，而不是 `/usr/bin/node`。三条全过再继续。混用系统 Node 是后面一切怪现象的头号来源——宿主的引擎检查、原生模块的 ABI，都按当前 node 版本走。

装完先拿一个无害的包试一次 `npx -y`，确认 registry 通、cache 目录可写。这一步两分钟，能省掉后面「为什么所有 stdio server 都起不来」的半小时排查。

## 第 2 步 · 宿主 CLI 能装几个算几个

17 个宿主不是都能从命令行驱动。这次真正装成、并且能跑出真机数据的是 5 个：Claude Code、Gemini CLI、Qoder、CodeBuddy、OpenCode。装法各不相同，有的走全局 npm 包，有的下载二进制，有的首次运行还要过一遍登录。每装完一个立刻 `--version`，把输出抄进 hosts.json 的备注字段。

验收点：5 个命令都在 PATH 里；再逐个开一次空会话，确认不会卡在登录页。

配置目录也要各自隔离。每个宿主的配置、缓存、凭据默认写在不同的家目录路径下，共用同一个 `$HOME` 跑多宿主时，偶尔会出现一个宿主的设置被另一个读到。最省事的办法是给每个宿主一个独立的 HOME，采集脚本里显式传进去，出了问题也好定位是谁写的。

这一步会出现一个关键分叉：CodeBuddy 与 OpenCode 的命令在，但 `hostAvailability` 是 `available:false`，原因写「未知原因」。不要为了让脚本跑下去去改这个字段，直接让这两列各 153 格、合计 306 格落成 na。改一下确实能让采集看起来更完整，代价是整份数据失真。

## 第 3 步 · 十格小样本先试跑

别一上来就全量。挑 10 个 server，其中至少 2 个是 stdio 型，只对 2 个宿主跑。

```bash
node collect.js --servers sample10.json --hosts claude-code,gemini-cli --out out/sample.json
```

验收点：输出里必须能看到三个字段——启动是否成功、`tools/list` 返回条数、`startupMs`。三者缺一，说明采集脚本还没准备好。

若 10 个全 fail，先回第 1 步查出网与 npx，别急着怀疑 server。小样本里出现 `toolCount=0` 是正常的，全量里这样的 stdio 型 server 有 46 个；脚本要能把它记成结果，而不是抛异常退出。

异常还要单独记一份。每次启动失败、鉴权失败、超时，都往 traps.json 里追加一条，写清格子的坐标和当时的输出摘要。这份文件后来救了我很多次——矩阵上只显示一个 fail，翻 traps.json 才知道那格是 30 秒没起来，还是起来了但列表是空的。

## 第 4 步 · 全量落盘，先验算术

全量跑完，第一件事不是看通过率，是对账。

byUsable 四项：pass 1,438、limited 59、fail 873、na 367，相加正好 2,737。byEvidence 三项：文档 1,344、真机 796、协议实测 597，相加同样是 2,737。

验收点：两组数各自闭合，并且任意一格都能追到自己属于哪一档。对不上就别去做矩阵——多半是某类格子被写了两次，或者 na 被当成 fail 计了。

#### 落盘时这三个字段别省

`usable`、`evidence`、`startupMs`。前两个决定这一格怎么读，第三个决定它可不可信。少了 startupMs，以后想调超时阈值只能重跑一遍。

文件按一轮一个目录，目录名带采集时间戳，里面再按宿主分文件夹。这样重跑不会覆盖上一轮，对比两轮差异时直接 diff 目录就行，不用去翻日志猜哪次是哪次。

## 第 5 步 · 把 cells 摊成矩阵

cells 是一维的，矩阵是二维的。摊的时候宿主做列、server 做行，每格显示两个字符：一个表示可用性，一个表示证据档。

验收点：随机点 5 格，都能回答「这个结论来自哪一档」；点到 na 的格子，能看到 hostAvailability 的原值。这两点做不到，这张表就只能看个颜色，不能拿来引用。

## 全量跑到一半断了怎么办

2,737 格不是几分钟能跑完的，中途断掉很正常：SSH 掉线、宿主自己更新、某个 server 挂住不退。所以采集脚本从第一版就该支持续跑——每跑完一格就把结果追加进 JSON 行文件，重跑时先读已完成集合，跳过已有坐标。

验收点：手动 kill 一次，再启动，日志里应该显示「跳过 N 格、续跑 M 格」，且最终总数仍是 2,737。做不到续跑，一次断线就得从头再来，越跑越不敢开。

## 一张表分清「没测到」与「测失败」

na 367 格，其中 306 格是 CodeBuddy 与 OpenCode 两列整列（各 153）。fail 873 格，其中 552 格落在协议实测档、286 格落在真机档。这两堆数混在一列里看起来都是「不行」，实际一个是机器根本没跑，一个是跑了没通过。

协议实测那 597 格最容易被误读：pass 是 0。不是低，是零。这一档的 fail 也不是散开的，落点很集中，46 个 server 就把它占满了——所以它代表的是某一类 server 的处境，不是 153 个的整体水平。

验收点：矩阵里 na 与 fail 用不同颜色，图例写清楚，别用同一片灰。

## 第 6 步 · 留一份对外能解释的索引

最后给矩阵配一页索引，写清三档口径：文档档 1,344 格里 pass 1,250（93.0%），真机档 796 格里 pass 188（23.6%，剔除 322 个 na 后是 39.7%），协议实测档 597 格里 pass 0。三个百分比分母不一样，必须分行写，不能并成一个「兼容率」。

索引里再补两条：真机 pass 的 188 格只来自三个宿主（Claude Code 102、Gemini CLI 34、Qoder 33）；启动耗时中位 4,185 ms、最短 212 ms。有了这两条，才知道这份数据覆盖了什么。口径页在 [MCP 兼容手册](https://mcp.dpharness.com/?utm_source=txyun&utm_medium=article&utm_campaign=mcp-daily)，索引格式可以直接照抄。

## 总结

从空机器到一张矩阵，决定数据能不能用的不是脚本，是四道验收：Node 版本、宿主 CLI 能不能起来、两组算术闭不闭合、每格有没有 evidence 字段。四道过了，2,737 格才是能引用的东西。想按宿主看现成对照，从 [按平台找 MCP](https://mcp.dpharness.com/platform?utm_source=txyun&utm_medium=article&utm_campaign=mcp-daily) 进。

## 适合与不适合

**适合**：想在自己机器或内网复刻一份兼容性数据的人；需要给团队解释「这个 server 为什么不能用」的维护者；习惯按步骤验收、不追求一把梭的工程方式。

**不适合**：只想要一个查询结果、不打算维护采集流程的人；机器资源紧张到连 5 个宿主 CLI 都不想装的环境；希望跑一次就永久有效的团队。

另外，本文只讲采集与验收这条线；想找能直接装的 DSH 插件，[精选插件 Top 榜](https://dpharness.com/top?utm_source=txyun&utm_medium=article) 按站内综合分排了一份。

标签：MCP、腾讯云 CVM、部署记录、兼容矩阵

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


机器是 2026-11-02 开的，2 核 4G，Ubuntu 24.04，系统盘 60 GB。当天晚上跑完全量，落库 2,737 格。下面按我敲命令的顺序写，每一步给一个验收点；验不过就别往下走，后面所有数都会歪。

空机器到一张兼容矩阵，MCP 探测机的搭建记录

开发工具

测试

运维

本文记录了从空机器搭建MCP兼容矩阵探测机的完整流程，涵盖Node环境固定、宿主CLI安装、全量采集2,737格数据及验收标准。重点展示了通过usable、evidence、startupMs三字段实现数据可信验证，区分na与fail统计口径，并支持断点续跑。适合需要自建MCP兼容性测试、需明确证据分级标准的开发与运维人员参考。

代码解释

CodeBuddy

JSON

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


4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

本文记录了从空机器搭建MCP兼容矩阵探测机的完整流程，涵盖Node环境固定、宿主CLI安装、全量采集2,737格数据及验收标准。重点展示了通过usable、evidence、startupMs三字段实现数据可信验证，区分na与fail统计口径，并支持断点续跑。适合需要自建MCP兼容性测试、需明确证据分级标准的开发与运维...

空机器到一张兼容矩阵，MCP 探测机的搭建记录-腾讯云开发者社区-腾讯云

空机器到一张兼容矩阵，MCP 探测机的搭建记录

空机器到一张兼容矩阵，MCP 探测机的搭建记录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐