Codex 疯狂请求 MCP 服务？排查思路与优化建议

最近圈子里有不少朋友在反馈一个问题：自家的 Codex 开始疯狂请求 MCP 服务，搞得系统负载飙升，甚至影响了正常的业务运行。这种“无限套娃”式的请求确实让人头疼，别慌，今天咱们就扒一扒这背后的坑，顺便把解决思路捋清楚。

简单回顾一下，MCP（Model Context Protocol，模型上下文协议）最近挺火的，它主要用来让大模型能更方便地连接外部数据源和工具。理想状态下，模型通过 MCP 调用 API 获取实时数据或执行操作，是为了增强智能表现。

但如果 Codex（无论是指某个 AI 编码工具还是集成了 MCP 的客户端）开始“疯狂请求”，那通常意味着调用逻辑出了岔子，陷入了某种死循环或错误重试机制。

很多时候，问题的根源在于“容错机制反噬”。如果 MCP 服务端偶尔报错（比如超时或 500），而客户端的重试间隔设置得太短，或者没有设置最大重试次数，请求就会像洪水一样涌过去。

这听起来有点玄学，但确实存在。Codex 在生成代码或回答时，可能因为某个上下文误解，反复认为需要调用 MCP 才能完成任务。比如它总是试图读取一个不存在的资源，读不到就重试，读不到就再试。

解决办法：查看具体的请求日志。如果发现每次请求的参数都一模一样，那十有八九是卡住了。这时候需要重置会话，或者调整系统提示词，明确告知模型“失败即停止”。

如果是服务端本身就慢，客户端积压了大量请求排队，看起来就像是在“疯狂请求”。这种情况不一定是客户端的 BUG，纯粹是性能瓶颈。

如果你是用 Codex 生成的代码，而这段代码本身触发了某个 MCP 调用，那就很容易造成无限递归。比如 A 调用 B，B 调用 A，永无止境。

如果你现在正面临这个紧急情况，按下面这个顺序操作，通常能把火先灭下来：

紧急熔断：直接暂停 MCP 服务，或者在客户端暂时禁用 MCP 插件。先别让请求继续发了，保住服务器资源。
抓包看日志：打开日志系统，过滤掉正常的请求，专门看那堆报错或高频请求的 Payload。重点看 status_code、response_time 和 request_body。
定位坏点：根据日志判断是模型“想不通”去卡死，还是网络环境不好导致的重试风暴。
修改配置：针对性调整。如果是重试问题，修重试策略；如果是逻辑问题，修 Prompt 或代码。
灰度开启：修复后别急着全量放行，先开小流量测试，观察一段时间没问题了再全面恢复。

MCP 的出现确实给 AI 交互带来了不少新玩法，但新技术的落地往往伴随着各种奇奇怪怪的坑。遇到 Codex 疯狂请求别硬抗，从日志入手，排查重试逻辑和调用链路，基本都能找到病灶。

希望这篇分析能帮到正在踩坑的你，如果还有其他疑难杂症，欢迎在评论区留言，咱们一起交流应对方案。