AI 编码工具吃光代理流量？上传消耗排查与省流量实践

问题：先撑不住的往往是代理流量

AI 编码助手和 Agent 用得越来越多，不少人发现一个反直觉的现象：真正先见底的，往往不是模型额度，而是本地代理套餐的流量。有人一个月 100G 提前用完，有人半个月 150G 就见底，还有人同时开两台 Mac 跑任务，流量直接翻倍。

第一反应通常是“是不是下载了大文件”，但排查下来，下载只占小头。真正的大头是上传：截图、图片、文件快照、长上下文反复往返，都在悄悄消耗流量。再加上工具自动更新、拉取依赖、后台网页轮询，代理流量很快就被吃掉。

流量到底被什么吃掉了

上传流量常常比下载更大

AI 工具执行 computer use、截图、生成图片时，每次会话都可能把画面或文件上传给模型服务；如果任务拆出多个子 Agent，每个子 Agent 也可能各自上传。下载回来的多数是文字，体积很小，上传的图片和快照才是主要开销。有用户对比后发现，同类工具中偏向 computer use 的那个上传量明显更高。

上下文越长，往返流量越多

有经验估算：1 亿 Token 大约对应 0.4 到 0.7 GB 流量，而且上传和下载都算。上下文不断累积，每次请求都要携带历史内容，长会话的带宽成本会快速上升。任务越复杂、对话越长，流量越难控制。

自动更新和依赖下载

部分工具更新频繁，有用户遇到一天更新三次、每次几百 MB 的情况。另外，Agent 越来越倾向于使用 worktree，会反复拉取依赖，进一步放大下载量。这类流量单次不算夸张，但累积起来很可观。

容易被忽略的后台网页

有用户发现，某个文档页面大约每 30 秒发起一次约 400kB 的请求，页面挂了好几天，七天累计消耗了 8.6G。这类流量和 AI 工具无关，但会混在代理连接里，排查时容易误判成模型调用。

先定位，再省流量

用 Clash API 看连接

Clash 内核提供 connections 接口，可以按域名、进程、上传和下载排序。单机使用可以用 clash-traffic-monitor 这类小工具；需要多用户或长期观察，可以用 neko master。需要注意，基于连接记录的统计对短连接可能有偏差，不必追求绝对精确，看趋势和排名即可。

排查清单

• 按上传流量排序，确认是否集中在截图、图片类请求
• 按域名排序，找出高频轮询的网页或接口
• 查看进程字段，空的连接可能是后台页面或系统进程
• 对比开启、关闭某个工具前后的流量曲线
• 记录一天中流量突增的时间点，和当时的操作对应

省流量的具体做法

控制上下文与任务粒度

• 拆小步执行，避免把整个仓库一次性塞进上下文
• 长任务分段，及时开新会话
• 只把需要的文件加入上下文，无关目录排除
• 让 Agent 先给方案再动手，减少反复试错带来的往返

管理自动更新

• 关闭工具自身的自动更新，改为手动更新或用系统包管理器更新
• 把更新安排在不限流量的时段
• 更新前看说明，避免版本变化带来额外行为

减少图片与快照上传

• 非必要不让 Agent 截图
• 能用文字描述的地方不用图片
• 生成图片类任务集中处理，避免频繁触发

留意 worktree 与依赖

• 使用 worktree 时配置依赖缓存
• 避免每个任务都重新安装依赖
• 定期清理无用工作区

处理后台页面轮询

• 关掉不用的文档页面
• 用浏览器开发者工具查看 Network，找定时请求
• 对必要页面加请求拦截规则

网络方案怎么选

流量消耗大时，常见做法有几种：换更大流量套餐、自建服务器、使用专线。取舍如下：

无论选哪种，都要确保网络服务的使用符合当地法律法规和服务条款。不要购买或共享他人账号，也不要用来源不明的代理服务传输敏感代码。

如果本地网络本身不稳定，或者笔记本需要长时间跑 Agent，也可以考虑把任务放到远程 Mac 上：整台机器放在新加坡机房，按月租用，远程连接使用，可以长期在线运行 Claude Code 等工具，AI 工具产生的流量走机房网络，不占用本地代理套餐。这只是一种可选思路，是否合适取决于预算和对延迟的要求。

小结

AI 编码工具的流量消耗可以概括为：上传为主、长上下文放大、自动更新和依赖补刀、后台网页偶尔添乱。先监控定位，再控制上下文、关闭自动更新、减少图片上传，最后根据实际用量选择网络方案。定期查看流量账单，别等套餐见底才回头找原因。