在阿里云上跑 MCP 采集，可信度从哪来
把 MCP 兼容性当成一张静态表格是危险的：表格里有多少格是真测的，取决于采集机装了什么。这次我在一台 ECS 上复跑了整套采集（2026-11-02 19:53 UTC 产出，161 个 server × 17 个宿主 = 2,737 格，模式 full），有两个结论只在这台机器上成立——因为它们由「采集机上有什么」决定，不由 server 决定。
一、先看这台机器决定了什么
| 依赖项 | 有 | 后果 |
|---|---|---|
| claude-code CLI 2.1.311 | 有 | 161 格里有真机数据 |
| gemini-cli 0.66.0 | 有 | 真机通过 40 格（24.8%） |
| qoder 1.1.80 | 有 | 真机通过 39 格（24.2%） |
| codebuddy CLI | 无 | 161 格全部 na |
| opencode CLI | 无 | 161 格全部 na |
na 总数 367 格，其中 322 格来自「采集机没装对应命令行工具」。换句话说，矩阵里 13.4% 的格子在这台机器上根本测不出来。这不是 server 的兼容性问题，是采集端的环境缺失。
二、出网策略直接影响失败归因
597 个协议实测格里 45 格记的是「本机网络连不上这个服务，未取得结论」。要在 ECS 上跑这类采集，出网要按下面三条配：
- 安全组只放行必要的出站端口，不要为了图省事全放；采集本身只需要访问 server 声明的端点；
- 对需要拉取远端包的 server，把 npm registry 与 GitHub 放进可达集合，否则失败会被记成「平台不支持」；
- 采集前先跑一次连通性自检，把不可达的目标列出来，避免它们污染结论。
三、常驻进程与实例规格
采集是短时高频进程：161 个 server 逐个启动、握手、读工具列表。启动耗时分布决定了资源需求——112 个有耗时数据的 server 中位数 3,866 ms，最长 55,285 ms（b1-mcp-server），最短 212 ms。最慢那个单个就占近一分钟，用 2 核 4 GiB 的按量实例跑完全程足够，但要注意 stdio 型 server 会真的起子进程：本次 147 个是 stdio、14 个是 http，并发度开太高容易把自己 OOM。
建议两件事：并发限制在 8 以内；把每个 server 的超时设成中位数的两倍（约 8 秒），超过 20 秒的单独标记、不参与批量结论。
四、跑完怎么校验结果
采集产物是一份 JSON，至少要核四个字段：
# 1) 模式必须 full，finalChunk 必须 true，否则是残缺快照
jq -r '.mode, .finalChunk' mcp-data.json
# 2) summary.cells 必须等于 servers × hosts 的实际格子数
jq '.summary.cells, ([.servers[].checks[]] | length)' mcp-data.json
# 3) 证据分级要能对上：文档 + 真机 + 协议实测 = 总格数
jq '.summary.byEvidence' mcp-data.json
本次快照三项都自洽：2,737 格，byEvidence 为文档 1,344 + 真机 796 + 协议实测 597。
五、云上最容易误读的两个数字
第一，真机通过率。796 格真机里 pass 188 格（23.6%），这个数字低不是因为 server 质量差，而是因为真机判定包含启动、握手、工具注册三段，任何一段失败都记 fail。
第二，工具数为 0 的 server。51 个里 8 个是测试夹具，其余 43 个是真实 server。它们在任何宿主上都不可能「可用」，但在文档判定下仍可能显示配置通过——这就是云上采集最值得注意的口径差异。
总结
在 ECS 上跑 MCP 采集，结论的可信度取决于三件事：采集机装了哪些宿主 CLI、出网是否可达、超时与并发怎么设；矩阵本身的字段定义与宿主口径见 MCP 兼容矩阵，按现象归档的排查条目见 装不上的原因，插件类目可以对照 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：要在自己云上复跑兼容性采集的人；需要向团队解释「为什么矩阵里有 367 格是 na」的人；做 MCP 选型要做二次统计的人。
不适合：只想直接抄结论的人，采集结论强依赖采集机环境；期望采集器自动适配所有宿主的人，缺 CLI 就是缺；把 na 当「不支持」的人。
标签：MCP、DeepSeek Harness、阿里云 ECS、兼容矩阵
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
