慢，往往是「上下文」的问题
Claude Code 变慢、变笨、返工多，多数时候不是「模型不行」，而是上下文管理出了问题。这一节教你先定位瓶颈，再对症下药。
别一慢就怪工具，先找到真正的瓶颈。
性能慢的三种典型「病因」
1. 上下文过载
对话越来越长，塞满了无关内容。模型在巨大上下文里「找不着北」，反应慢、判断差。
症状：越到后面越慢、越容易忘前面的事。
对 mcp-hub：工具列表本身就是上下文的一部分。mcp-hub 挂了 20 个 Server、上百个工具，Claude Code 每次都要先「看一遍」所有工具才能决定用哪个——这就是 mcp-hub 特有的「上下文过载」。
2. 模型选型不当
用了一个又贵又慢的强模型，去干一件简单的小事。
症状：简单任务也等很久，成本还高。
3. 任务拆得太粗
一个大任务一把梭，上下文和步骤都乱成一团，反复返工。
症状：改来改去，总在绕圈。
先定位，再动手
遇到慢，先别急着换模型或重做。按这个顺序排查：
1. 是不是上下文太长？ → 清理/压缩（下一节）
2. 是不是模型选太大了？ → 换更合适的
3. 是不是任务没拆开？ → 拆小
4. 都不是？ → 看是不是网络/服务端问题
大部分性能问题，指向的是「上下文管理」，而不是工具本身。
对 mcp-hub，定位时还要多问一句：「是不是 mcp-hub 暴露的工具/服务太多，把上下文撑大了？」——这是 mcp-hub 特有的第一个要排查的病因。
一个诊断练习
你的 Claude Code 处理一个文件改得越来越慢。你这样诊断：
现状：改一个文件越来越慢，还开始答非所问。
排查：
1. 这个会话已经聊了很久？→ 是，上下文可能过载
2. 模型是不是最强的那个？→ 是，简单改动用大了
3. 我是不是让它一次性改太多？→ 是，没拆
对策：先压缩上下文 + 换更省的模型 + 拆成小任务
套到 mcp-hub 场景：
现状：让 Claude 通过 mcp-hub 查订单，越来越慢、还总用错工具。
排查：
1. mcp-hub 里挂了多少 Server？→ 20 个，工具上百个
2. 这些工具这次任务都用得上吗？→ 用不上，大部分是干扰
3. 会话是不是很长？→ 是
对策：给 mcp-hub 精简暴露的工具 + 压缩上下文
什么时候是「真·性能问题」
排除了上下文、选型、拆分后，如果还慢，才考虑：
- 网络/网关：国内网络到网关的延迟
- 服务端负载：模型服务本身慢
这些是外部因素，你只能「换更快端点」或「错峰」。
对 mcp-hub 还要补一条外部因素：你接入的外部 MCP 服务本身慢。如果订单库的服务端慢，Claude Code 等的是「查订单」这个调用，和模型性能无关。
一个可复制的定位记录表
给团队一个统一的定位表格，mcp-hub 遇到慢时照着填：
| 项目 | 你的答案 |
| 会话长度 | 聊了 N 轮 |
| 模型 | 用的是哪个模型 |
| 任务粒度 | 一把梭 / 已拆分 |
| mcp-hub 工具数 | 当前暴露了多少工具 |
| 外部服务响应 | 快 / 慢（测一下） |
填完，病因基本浮出水面，再对症下药。
落地练习：给 mcp-hub 做一次性能体检
这一节，给你的 mcp-hub 做一次性能定位。
跟着这三步走：
- 用上面的「定位记录表」，记录你当前 mcp-hub 的会话长度、模型、任务粒度、暴露的工具数
- 逐条按「上下文 → 选型 → 拆分 → 外部」四个方向排查，标出最可能的病因
- 把结论记下来，下一节按这个结论去优化
你会怎么判断做对了？——你能明确说出「mcp-hub 现在最可能的性能瓶颈是哪一类」以及依据，而不是笼统地说「反正就是慢」，就算过关。
卡住了怎么办？ 判断不出病因？就先用「上下文过载」这个最常见的方向入手，看 mcp-hub 暴露的工具数是不是很多。没有真实会话可测？造一个场景：挂上多个 Server，故意问一个简单问题，观察是不是变慢。
常见坑：一慢就换模型，从不看上下文
新手最常见的坑：觉得慢就是模型不够强，一上来就换更贵更快的模型，结果又慢又贵还没解决。多数慢，根子在上下文，不在模型——模型再强，塞满垃圾上下文一样犯迷糊。
mcp-hub 团队尤其容易踩：觉得「是不是该上更贵的模型了」，却忘了先看「是不是 mcp-hub 的工具列表把上下文撑爆了」。先按四步定位，确认是模型问题再换，别把换模型当万能药。
小结
- 慢，多数是上下文管理问题，不是工具问题
- 三病因：上下文过载、模型选型不当、任务拆太粗
- 先定位再动手，别一慢就换模型
- 真·性能问题才考虑网络/服务端
- mcp-hub 特有的病因：暴露的工具/服务太多撑大上下文
下一节，讲上下文与 Token 的具体优化技巧。