AI 编程工具的一次任务是一个「智能体循环」：模型思考 → 调用工具 → 读取结果 → 继续思考，循环几十上百次，全程走流式长连接。网页聊天失败重发一条消息即可，编程任务失败则几十分钟工作作废——失败成本相差两个数量级，对网络的要求自然高一个量级。具体门槛：晚高峰丢包低于 1%、任务期间出口 IP 不变、终端与编辑器正确走代理。
目录
一次「修 bug」在网络上发生了什么
给 AI 编程工具下达一个任务，网络层面展开的是这样一串事件：
上传上下文（代码、目录树）
→ 模型流式返回分析 ← 长连接 #1
→ 工具调用：读取 3 个文件 ← 请求 × 3
→ 模型流式返回修改方案 ← 长连接 #2
→ 工具调用：写入、跑测试 ← 请求 × N
→ 测试失败，模型继续迭代 ← 长连接 #3…
→ （循环，直到完成）几十分钟内可能有上百次网络交互，且它们不是独立的——共享同一个会话状态。任何一环断掉，不是「重试这一步」，而是整个循环崩溃。
三个机制放大了网络要求
流式响应 × 丢包
模型输出逐 token 流回本机。丢包引起 TCP 重传，重传时间超过客户端超时阈值（通常几十秒）连接即断。晚高峰中转线路 3–10% 的丢包率意味着长连接几乎必断，这就是「白天好好的、晚上跑不完」的原因。指标解读见 什么是丢包。
会话 × IP 绑定
OpenAI 与 Anthropic 的风控把会话与出口 IP 关联。代理客户端的「自动测速切换」在任务中途换了节点，风控视角就是「会话被劫持」——轻则重新验证，重则临时限制。所以 AI 编程的铁律是：固定节点，关闭自动切换。
进程 × 代理
这些工具运行在浏览器之外，不继承浏览器代理。终端要环境变量或 TUN，编辑器要各自设置——配置缺一角，表现就是「浏览器正常、工具连不上」。
由机制推导线路标准
| 机制 | 推导出的要求 |
|---|---|
| 流式 × 丢包 | IEPL / IPLC 专线，晚高峰丢包 < 1%（专线原理） |
| 会话 × IP | 低共享 IP + 域名固定到单一节点 |
| 进程 × 代理 | TUN 模式或环境变量，浏览器与终端同出口 |
三大工具在这套标准下的差异排序见 Codex、Claude Code、Cursor 哪个更依赖稳定网络；已经在掉线的用户直接看 AI 编程工具经常断线怎么办；符合标准的线路怎么挑，见 Codex 机场推荐。
常见问题
智能体循环是什么意思？
AI 编程工具不是一次性生成答案，而是反复「思考→执行→观察」：改一个 bug 可能包含读 10 个文件、改 3 处代码、跑 2 次测试，每一步都是一次模型请求，串联在同一条会话里。
为什么流式响应特别怕丢包？
流式输出依赖一条持续的连接，丢包触发重传，重传延迟超过超时窗口连接即被断开；而普通请求丢包只是慢一点。
用 API Key 调模型和用订阅工具，网络要求一样吗？
机制相同，都怕丢包与 IP 漂移；差别是 API 报错更直白（超时/断流异常），而且部署在服务器上时需要确保服务器自己的出口在支持地区。
提升带宽能减少断线吗？
基本没用。AI 编程的流量极小，断线由丢包和 IP 变化引起，与带宽无关；钱应该花在专线上而不是更大带宽上。