采集机没装 CLI 这件事，在云上会放大成 306 格空结论
本地跑采集，缺一个命令行工具最多是少一列，你自己知道是没装。搬进云上，缺的那一列会变成 153 格 na；两个宿主就是 306 格，占掉 2,601 的 11.8%。数字不算吓人，吓人的是它在报表里长得像结论。
306 格的形状：2 × 153
351 格 na 里，306 格的原因只有一句采集 note：采集机没装这个平台的命令行工具。codebuddy、opencode 各 153 格全 na，hostAvailability 里 available:false，reason 写「未知原因」。
在云上，「未知原因」几乎没有悬念：镜像里没有那个二进制。公共镜像只保证通用运行时，宿主 CLI 属于应用层，要自己装。本地机器是你日积月累装出来的一堆全局包，云主机是干净的，这个差异会一比一写进结论表。
45 格：DNS 通了不等于握手成功
另一类 na 是 45 格「本机网络连不上这个服务」。云上的成因比本地多得多：安全组只管入方向，出方向默认放通但被策略收紧后照样不通；NAT 网关有并发与带宽上限，长连接容易被回收；VPC 里没配 DNS 就解析不了外部域名；企业代理常要求 SNI 白名单。
注意这 45 格记的是 na 不是 fail。采集器在连不上时不下「不可用」的判断，这个设计在云上是救命的——否则一次网络抖动会被写成 45 个 server 坏了，而这批结论再也没法用。
| 出网形态 | 典型断点 | 表里会变成 | 怎么区分 |
|---|---|---|---|
| 直连 + 收紧的安全组 | 出方向只放通部分端口或网段 | na，note 写网络连不上 | 换一台同子网机器复跑仍不通 |
| NAT 网关 | 并发打满、长连接被回收 | 间歇性 na | 同一格重跑结果不稳定 |
| 企业代理 | 只认 CONNECT、要求白名单 | na 或 fail | curl 通，server 启动报握手错 |
| 无 DNS | 解析失败 | na | getent hosts 直接空 |
| 容器网络 | 宿主在宿主机、CLI 在容器内 | 整列 153 格 na | 容器里 which 为空 |
代理只在子进程里生效
这是云上最容易被忽略的一层。export http_proxy 只影响你在 shell 里起的子进程；用 systemd 或 nohup 拉起的采集器不会继承你登录会话的变量，得在 unit 里写 Environment=。反过来，GUI 形态的宿主更麻烦，它压根不读 shell 环境。
判断顺序别搞反：先在采集进程所处的那个环境里跑一次 curl -I，通不了就别怀疑 server。不少用 Node 写的 server 不主动读代理变量，需要显式传参或挂代理 agent；这一步不做，你会看到「本地好好的，云上全 na」。
容器里的两套 PATH
镜像化部署最常见的翻车点是 CLI 装错了层：宿主机 root 下 npm i -g 装好，采集跑在容器里，which 出来是空的，于是一整列 na，而你在宿主机上验证时一切正常。
四条经验：CLI 装进镜像而不是宿主机；采集进程与 CLI 用同一个 UID 和同一份 PATH；nvm 装的 node 落在 /root/.nvm，换个用户就找不到；别把可执行文件放进 /tmp 这类会被清理的目录。
验收就一句：在采集进程内部执行 which 与 --version，两者都有输出才算装上。在宿主机上验证不算。
出网不通与 server 不通，别混着修
云上排查最常见的浪费，是把两件事一起改：既收安全组又换 server 版本，最后不知道哪一步起了作用。分层验证更省时间——先证明机器能到目标域名（curl 拿到状态码），再证明 MCP 客户端能完成一次握手（本机 Inspector 或最小 server 都行），最后才跑批量。
任何一层没通，就不要动下一层。同理，镜像制作时把 CLI 和 node 一起固化，机器重建后不会退回成片的 na；只装运行时不装 CLI 的镜像，重装一次就复现一次 306 格空结论。
上云验收：四行命令
# 全部在「采集进程所处的环境」里执行，不是你的登录 shell
which claude gemini codex # 有路径
node -v && npm -v # 运行时在位
curl -sS -o /dev/null -w '%{http_code}\n' https://registry.npmjs.org # 出网
getent hosts registry.npmjs.org # DNS
四行都过，仍然可能出现 na，那就只剩一种可能：这个宿主没有可执行入口，属于设计内的 na，不是故障。
把 na 记成账，别记成 0
306 格 na 一旦进了分母，两个宿主的通过率就是 0.0%，看上去像「这两个宿主什么都不支持」。正确写法是单列 na，并在标题里写明「未测」。有效通过率 pass/(总−na) 对这两个宿主没有定义，让它们退出排名比强行给个 0 更诚实。
同理，45 格网络类 na 应该在报表里单独标注。补好出网后重跑，这 45 格要么变成 pass，要么变成 fail——两种都比 na 有信息量。
总结
云上采集的结论质量，先取决于那台机器能不能把该跑的东西跑起来，其次才取决于 server 本身；出网策略与 CLI 安装这两件事没做对，表里就会出现成片的空结论。
适合与不适合
适合：在 ECS 或 CVM 上跑多宿主采集；要给出网策略写审批材料；容器化之后工具突然「消失」；需要向同事解释 0% 是环境问题。
不适合：单机本地开发，这些网络问题大多不存在；想找「云上推荐的 MCP server」；需要认证类结论，本批 authRequired 只有 1 个 server 且 17 格全 na。
标签：MCP、DeepSeek Harness、云上采集、出网策略
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
