启动耗时这道坎只对两个宿主成立，第三个几乎不罚

启动耗时这道坎只对两个宿主成立，第三个几乎不罚

遇到「工具列表空着」或「连上了但没反应」，最常见的建议是「你的 server 启动太慢，宿主等不及超时了」。这个解释有一半是对的：同一批 server 里，启动超过 5 秒的那 39 个，在一个宿主上通过率 94.9%，在另外两个上只有 15.4%。差别不在 server，在宿主等多久。

口径交代。数据取自子站采集机的全量汇总，generatedAt 为 2026-11-02T19:53:24Z（北京时间 11 月 3 日凌晨），mode=full、finalChunk=true，161 个 server 乘 17 个宿主共 2737 格；剔掉 8 个 isFixture 测试样本后是 153 个 server、2601 格。真有命令行工具、能跑真机的宿主只有三个：claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80，各 153 格（150 格真机加 3 格协议实测）。其余 14 列是文档推断，codebuddy 与 opencode 两列整列未测。字段定义与取数口径见取数方法，逐宿主的配置与超时约束见宿主能力对照。

一、153 个 server 按启动耗时切三刀

startupMs 是采集机拉起进程到握手完成的时间。为 0 有两种含义——进程没起来，或者根本没测到；这批数据里 49 个为 0 的样本全部属于前者，理由在下一节。

实测 104 个能起来的 server 里，启动耗时中位数是 4155ms，已经贴着 5 秒线。也就是说「5 秒」不是一条只在极端案例里才被碰到的线，而是一条过半样本都快要碰到的线。

慢的那批具体长什么样，抽几个最慢的看：

这些耗时的成因大多是首次 npx 拉包、装依赖、或远程建连。它们不是「坏 server」，只是第一句问候来得晚。

二、零启动那 49 个，三列全灭

先把最干净的一档说清楚。49 个启动耗时为 0 的 server，在三个真机宿主上的判定完全一致：46 格失败、3 格未测、0 格通过。三列同形，没有任何一个宿主例外。

失败说明写的是「这个平台用不了它」，但真实原因是它自己没起来——同一批格子在文档列的说明是「它没有对外提供任何工具，装上也没东西可调」。

实测 49 个零启动样本的工具数全部为 0，因为进程没起来，工具列表自然是空的。这两个字段在这批数据里互为镜像：工具数为 0 的 server 一共 50 个，其中 49 个启动耗时也是 0。

唯一的例外值得单独记一笔：structured-world__gitlab-mcp 启动耗时 22675ms、工具数 0，它起来了，但确实没提供任何工具。这也说明「零工具」不等于「没启动」——判断前者要看工具数，判断后者要看启动耗时，两个字段不能互相替代。

三、5 秒内的 65 个：一个全过，两个四成

这一档最能说明问题：65 个 server 全部在 5 秒内起来了，工具也都拿得到，但 claude-code 一格没丢，gemini-cli 与 qoder 各丢了三成半以上。此时原因已经和启动无关，全在宿主侧的适配。

实测 65 个快速启动样本里，claude-code 65 格全通过，gemini-cli 只通过 28 格、qoder 只通过 27 格，两者相差不到 1 格，属于同一档表现。

四、超 5 秒的 39 个：惩罚只落在两个宿主上

实测这 39 个慢样本在 claude-code 上通过 37 格、在 gemini-cli 与 qoder 上各只通过 6 格，同一批 server 同一次采集，差距 31 格。

这张表是全文的核心：启动慢的代价不是均匀分布的。claude-code 几乎不罚（降 5.1 个点），另两个宿主罚掉四分之一以上（降 27.7 与 26.1 个点）。

拿 server-time 这个具体样本对一遍，它启动 6948ms、提供 2 个工具，刚过 5 秒线一点点：claude-code 判通过（真机安装、连接成功），gemini-cli 与 qoder 都判失败。同一个 server、同一份配置，差别只在宿主等多久。

五、那条「5 秒超时」的规则，这批数据验不了

坑点清单里有一条关于 OpenCode 的记录：拉取工具列表默认只等 5000ms，启动慢的 server 会被判超时，出处是 OpenCode 官方文档的 Options 表。这条属于文档级证据，可靠性取决于文档是否与当前版本一致。

但在这批数据里它无法被验证——opencode 这一列 153 格全部是未测，说明是「采集机没装这个平台的命令行工具」，一格真机结论都没有。所以「OpenCode 5 秒超时」这件事，在本文口径下只能标到规则推导，不能标成实测。

真正被实测支持的是另外两个宿主上的惩罚。这也顺带说明一件事：文档写了超时是多少，不等于这个宿主在你这台机器上就一定按这个数字执行；能验证的只有跑过的那几个。

逐条宿主的约束出处与证据强度在坑点清单里都有标注，引用前先看它标的是「文档」还是「真机」。这也是这份数据里最容易忽略的一层——同样是失败，证据等级不同，可信度差一个档次。

六、这三档怎么用

第一，判定顺序放在启动之前。启动耗时为 0 就不必再调配置，先去解决拉包与依赖；工具数为 0 但启动有值，才是「这个 server 本来就不提供工具」。

第二，5 秒线只在特定宿主上有意义。如果你用的是 claude-code 这一档的宿主，慢 10 倍的 server 也大概率能过，不必为启动耗时改配置；换成 gemini-cli 或 qoder 这一档，同一批 server 的通过率从四成掉到一成半，这时候「换一个更快的 server」比「调超时参数」更有效。

第三，别把「通过率低」当成 server 质量差。这批数据里 39 个慢 server 在 claude-code 上通过率 94.9%，说明它们本身是能用的，只是对宿主超时窗口敏感。

想找一个慢一点但确实能用的样本对照，可以看 server-time 的兼容页：6948ms 启动、2 个工具，在两个宿主失败、在一个宿主通过。术语不清楚的查术语表。

七、局限

三条：一是快照停在 11 月 2 日，全量数据此后没有新采集，启动耗时尤其容易随网络与缓存状况漂移，跨天比较不可靠；二是 14 列文档推断没有真机复核，本文所有宿主因果只能标到规则推导；三是慢样本只有 39 个，按分类再细分就只剩个位数，不足以支撑分类级结论。

另外提醒一句：启动耗时是单次测量值，同一 server 连测两次可能差出一倍。判断「慢不慢」用它够用，判断「快多少」不够。