Codex 用着用着就变“笨”了？聊聊 AI 编程工具的几个网络层坑

用 Codex、ChatGPT 这类 AI 编程工具的朋友，应该都经历过这种场景：昨天还能一口气生成几百行代码，今天突然开始答非所问，回答变短、推理变浅、甚至直接摆烂。网上有人管这叫“降智”，社区里已经有不少讨论。

但排查一圈之后，很多人发现问题并不全在模型本身。本文从两个真实踩过的坑出发，聊聊 AI 编程工具在网络层到底会遇到什么。

坑一：Codex 的“降智”可能是一个 prompt 机制 bug

社区里有人用自动化测试脚本量化了 Codex 在长推理任务上的表现，发现一个很奇怪的现象：失败的那几次，模型的思考 token 精确地停在 516 或 1034 就停了，问题还没解决；而成功的那次，推理链跑满了 4660 个 token 才给出答案。

这组数据说明一个问题：不是模型变弱了，是思考链被提前打断了。

根因在 Codex 的系统提示词里。提示词埋了一条指令，要求模型每隔 30 秒向 commentary 通道汇报一次进度——就是界面上“我正在做 X、接下来做 Y”那种提示。而模型的推理是按 512 个 token 一页往下翻的，翻不翻下一页由一个独立机制决定。这个每 30 秒插一嘴的汇报，正好卡在翻页的节骨眼上，推理刚到 516 准备往下走，就被汇报打断了。

社区给出的解法很直接——在 AGENTS.md 里加一句让它闭嘴：

# AGENTS.md
DO NOT send optional commentary
# 或者
Spend time on thinking; you do not need to use the commentary channel to report progress to me.

有用户测试过，加了这句之后，正确率从 10% 提升到了 60%，降智概率从 80% 压到了 20% 多。

坑二：流式响应频繁断开，问题可能出在网络的 NAT 超时

另一个高频问题是 Codex 或 ChatGPT 的流式响应跑到一半就断了，报错通常是 stream disconnected before completion。

很多人第一反应是“网络不行”，但换了几个网络环境问题依旧。排查到网络层之后，会发现一个容易被忽略的细节：住宅代理节点的 NAT 表通常有 50-60 秒的空闲超时。

AI 编程工具的流式响应在模型“思考”阶段可能长达 60-145 秒不输出任何数据。在这段时间里，代理节点的 NAT 表判定连接空闲，直接发 RST 把连接掐了。客户端等到模型终于开始输出 token 时，连接已经没了。

解决方案有两个方向：一是让请求走 SSE 流式传输，每个 event chunk 穿过代理时刷新 NAT 表，避免空闲超时；二是确保代理节点对长连接有足够的容忍度。

网络出口的影响：为什么同样的代码在不同环境下表现不同

以上两个问题排查完之后，如果 Codex 或 ChatGPT 仍然不稳定，第三个需要检查的就是网络出口的类型。

Codex 的请求走 HTTPS 长连接，出口 IP 的“身份”直接影响服务端的连接策略。数据中心 IP（云服务器 IP 段）在 OpenAI 的访问控制系统中信任等级偏低，可能被分配更短的超时阈值、更激进的限流。而住宅 IP 的 ASN 归属于当地运营商，不会被判定为数据中心流量，连接策略相对宽松。

以下是以 1024Proxy 长效静态住宅 IP 为例的配置方式，通过环境变量为 Codex CLI 指定出口：

# ============================================
# 使用住宅 IP 作为 Codex CLI 的网络出口
# 服务商：1024Proxy
# 官网：https://1024proxy.com/?kwd=hyj-txy
# ============================================

# 方式一：环境变量配置
export HTTPS_PROXY=http://用户名:密码@gateway.1024proxy.com:端口
export HTTP_PROXY=http://用户名:密码@gateway.1024proxy.com:端口

# 方式二：Codex 桌面端 config.toml 配置
# 在配置文件中指定出口地址
# [network]
# exit_address = "你的静态住宅IP地址"
# exit_port = 端口号
# exit_type = "static"

配置完成后，用 curl 验证出口 IP 是否生效：

# ============================================
# 验证住宅 IP 出口是否生效
# 服务商：1024Proxy
# 官网：https://1024proxy.com/?kwd=hyj-txy
# ============================================

curl -x http://用户名:密码@gateway.1024proxy.com:端口 https://ipinfo.io/json

返回的 IP 应该与 1024Proxy 后台分配的一致，ASN 归属于当地运营商而非云服务商。

几个排查顺序建议

1. 先查 prompt 机制：Codex 的降智问题，优先在 AGENTS.md 里加 DO NOT send optional commentary，看是否改善。
2. 再查网络链路：流式响应中断，用 mtr 跟踪路由，确认中间节点是否有丢包或 NAT 超时。
3. 最后查出口 IP：访问 IP 检测服务，确认出口 IP 的 ASN 归属。如果是云服务商网段，考虑切换到住宅 IP 出口。
4. 保持出口稳定：长期使用的账号，固定一个出口 IP，不要频繁切换。环境一致性比 IP 质量本身更重要。

AI 编程工具的稳定性，一半看模型，一半看网络。prompt 机制和网络层配置都排查清楚之后，大部分“降智”和断连问题都能找到对应的解法。

本文仅做技术交流，请遵守相关平台规则与法律法规。