Claude Code MCP reliability routing：v2.1.191 修复不稳定的 Agent 控制平面

Claude Code MCP reliability routing 在 6 月 24 日发布的 v2.1.191 中变成了更具体的 operator 问题。重点不是新模型，也不是醒目的 IDE 功能，而是一组小型控制平面修复：MCP discovery 现在会重试瞬时网络错误，MCP OAuth 对 headless 环境更友好，managed settings 可以强制无缓存刷新，sandbox 网络批准也能在会话内持续生效。对通过 AI gateway 运行 coding agent 的团队来说，这些细节决定了长任务是 fail closed、卡在认证循环里，还是把预算浪费在可恢复的基础设施抖动上。

发生了什么

Anthropic 官方 Claude Code v2.1.191 release 列出了一批容易被忽略的修复。最值得 operator 关注的是：

• MCP capability discovery 针对 tools/list、prompts/list、resources/list 的瞬时网络错误增加了短 backoff 重试。
• MCP OAuth discovery 和 token 请求会在瞬时网络错误后重试一次；headless 环境会跳过 browser popup，直接进入 paste-the-URL 提示。
• Managed settings 的 forceRemoteSettingsRefresh 在通过 MDM 或 file policy 设置时可以生效，并且刷新请求会发送 Cache-Control: no-cache，避免代理返回陈旧策略。
• Sandbox network permission dialog 会记住本会话内用 “Yes” 批准的 host，不再每次连接都重复提示。
• 从 tasks panel 停止的 background agent 不会在之后“复活”。
• Streaming 文本更新合并到 100ms，响应期间 CPU 使用下降约 37%，长会话 terminal output cache 的内存增长也被降低。

这些变化没有重写 Claude Code 产品，但它们共同收紧了 agent 控制平面：tool discovery、credential flow、policy propagation、sandbox egress 和长会话资源开销，正是 operator 通常需要负责的接口。

为什么对 AI 工程团队重要

Coding agent 的可靠性取决于它周围的控制平面。如果 MCP server 在 tools/list 时短暂掉线，agent 可能会把缺失工具误判成应用能力不足。如果 OAuth discovery 在 SSH 或 CI 环境中失败，operator 看到的可能是认证错误，而不是瞬时网络问题。如果 remote settings 被代理缓存，团队以为新策略已经下发，实际 fleet 仍在运行旧的 model restriction 或 permission policy。

因此，Claude Code MCP reliability routing 应该被看作 policy 议题，而不是 patch note 的脚注。通过共享基础设施路由 agent session 的团队，需要区分三类失败：

1. 可恢复的控制平面噪声：在切换 model route 或判定任务失败之前，先对 MCP discovery 和 OAuth 做一到两次重试。
2. 策略新鲜度失败：managed settings 无法刷新时应 fail closed，尤其是 model restriction、sandbox policy 和 tool permission。
3. 运行时资源漂移：对长会话监控 CPU、memory 和 terminal output 增长，避免 agent 成本隐藏在 host overhead 里。

TheRouter 用户可以在 TheRouter docs 的通用 gateway 实践中映射这些类别：把 agent session 当作带有 tool inventory、identity、policy version 和 cost attribution 的有状态 workload，而不是孤立的 chat completion。

路由与运维视角

这次 release 改变了 router 或 gateway 应如何观测 coding-agent session。单纯的 model fallback 不能修复缺失的 MCP tool list、陈旧的 remote policy，或每隔几秒重复出现的 sandbox egress prompt。这些都是控制平面条件，所以 routing layer 需要一份控制平面 checklist。

第一，把 MCP discovery 与 model request 分开记录。失败的 tools/list 不应该混进通用 model latency；它应被标记为 MCP availability、server URL、retry count 和最终 tool inventory。这样 operator 才能判断任务失败来自 model reasoning，还是缺失 tool context。

第二，把 policy version 和 refresh status 放进 session metadata。forceRemoteSettingsRefresh 修复很重要，因为陈旧策略是 enterprise agent fleet 最容易漂移的方式之一。如果 gateway 按 team、project 或 risk tier 路由 session，也应记录 session 开始时实际生效的 managed-settings version。

第三，把 sandbox network approval 当作 egress state。会话内记住已批准 host 可以减少 prompt fatigue，但也意味着 session 的网络许可会不断演化。Operator 应把它与 deny-by-default egress rules，以及围绕 repo、package registry、internal API 的 compliance boundary 对齐。

TheRouter 用户应关注或尝试什么

先建立受控升级 lane，而不是一次性全 fleet 更新。用一个代表性的长任务，把 v2.1.191 与当前 Claude Code 版本对比；任务应同时使用 MCP、sandboxed commands 和 background agents。

使用这份快速 operator checklist：

• 确认 MCP discovery failure 会记录 retry count 和最终状态。
• 在 headless 或 SSH 环境中测试 MCP OAuth，并记录 paste-the-URL 路径。
• 验证 managed settings refresh 能绕过 proxy cache，且 operator 能看到 active policy version。
• 把 sandbox network approval 审视为 session-scoped egress state，而不只是 UX 便利。
• 对比升级前后长 streaming session 的 CPU 与 memory。
• 重新阅读 TheRouter 之前关于 Claude Code 2.1.186 bash auto-respond and subagent permission routing 的分析，因为 v2.1.191 延续了同一个 operator 主题：agent 控制平面正在成为一等可靠性界面。

实际结论是：Claude Code MCP reliability routing 与其说是在改变哪个模型回答 prompt，不如说是在证明 tools、credentials、policy 和 sandbox egress 都健康之后，再让 coding agent 继续投入下一个小时。