Flowness 工程进展：从需求到交付 · 阅读系列导读 →
10 月 11 日早上，我们看了一眼一台中转服务器的流量：948.68 GiB。
这台服务器只做转发，每月有 1000 GiB 的流量额度。它 10 月 4 日才上线，7 天，额度用掉了 95%。数据进来一次、出去一次都要算进额度，真正转发的量约为一半，7 天也有四百多 GiB。
按大多数人的印象，这事怪不到 AI 头上。AI 不就是来回发几句文字吗？一问一答，一次请求不过几 KB 到几十 KB。
可账拆开以后，大头确实是 AI。几句文字，怎么能在 7 天里用掉差不多一整个月的额度？
先看是谁在用
把转发的流量按来源拆开：网页、视频这些非 AI 流量，这几天上下行合计只有 71 GB。其余主要来自三处：本机的 AI Agent，桌面、浏览器和手机上的 AI 应用，还有另一台同样跑着 AI Agent 的远程工作机。
从 10 月 8 日起，日用量一路往上走：8 日 82 GiB，9 日 188 GiB，10 日 263 GiB。10 日的上涨，对得上当天的一件事：我们在同一分钟启动了一批后台 Agent，也就是在后台长期开着、持续接任务的 Claude Code。到了夜里，流量也没有降，每小时还在走 7 到 17 GiB。
流量这样涨，先要排除的是泄漏。本机 AI Agent 的上下行比例先露出了线索：约 6.8 天里，上传 168 GB，下载 18 GB。
上传是下载的 9 倍。
平常上网正好反过来。看视频、刷网页，几乎全是往下拿，往上送的只有几个请求。AI Agent 却在拼命往外发东西。它到底在发什么？
一轮 1.7 MB
我们截了约 10 分钟的请求级记录（10 月 11 日上午）：1050 个请求，上传 631 MB。
| 请求类型 | 次数 | 上传 | 占比 |
|---|---|---|---|
| 主 Agent 的正常轮次 | 334 | 567 MB | 90% |
| subagent | 81 | 23 MB | 4% |
| Claude Code 遥测 | 246 | 37 MB | 6% |
| 不带工具定义的小请求 | 329 | 3.3 MB | 0.5% |
| 其他（通知分类、读配置等） | 60 | 约 1 MB | — |
主 Agent 是直接接任务、向 subagent 派活的那一个；subagent 是它派出去、自己单独发请求的执行 Agent；遥测是客户端向服务商上报使用数据的请求。
看主 Agent 那一行和小请求那一行。次数几乎一样，334 对 329；上传量差了 170 多倍，567 MB 对 3.3 MB。主 Agent 平均每轮上传 1.7 MB，每 10 轮就有 1 轮超过 3.6 MB，最大的一轮是 11.5 MB。
1050 个请求都能归进上表这几类，上传的 90% 落在主 Agent 的正常轮次上。聊天的一次请求是 KB 级，这里一轮是 MB 级。往外发的不是泄漏出去的数据，是主 Agent 自己的上下文。
第 50 轮，前 49 轮都还在
编码 Agent 干活是一个循环：读文件，跑命令，看结果，决定下一步，再读，再跑。每决定一次下一步，就是一轮请求。
麻烦在于，Claude 的接口不保存对话。上一轮发生过什么，它不记得，必须随请求一起带上。于是每一轮的请求里都装着同样几样东西：系统提示、全部工具定义、到目前为止的所有对话，以及每一次工具返回的内容。
第 1 轮，请求里是系统提示、工具定义和你开头那句话。第 2 轮，是这些，再加上第 1 轮的回答和工具结果。到第 50 轮，前 49 轮的一切都还在里面，一字不少地再传一遍。
我们的主 Agent，上下文平时在 30 万 token 上下。自动压缩设在 60 万 token，也就是攒到 60 万才把历史压成摘要。这个数是我们有意设高的：长任务要做得好，Agent 得记得前面发生过什么。代价就是每一步都要把这 30 万 token 重新送出去。
有人会想到提示缓存（prompt caching）。它确实有用：服务商认出这一段前缀上一轮处理过，就按低价计费。但打折发生在接口那一头，这些字节照样要从你这边一个一个传过去。账单上的 token 便宜了，网线上的流量一点没少。
我们之前那篇《同一个任务，Claude 花了 10 元，GLM 花了 64 元》算的是 token 的钱，这一篇算的是网络的钱，两笔账要分开算。
11 万次请求从哪来
一轮 1.7 MB，单看不大。要堆出前面那 168 GB 的上传，另一半答案在次数上。
本机 AI Agent 每天的请求数，10 月 8 日约 1.06 万，9 日 1.97 万，10 日 5.02 万，11 日还没过完就超过了 10 日全天。10 日那天翻了一倍多，主要就是那批后台 Agent。24 小时里（10 日上午到 11 日上午），本机所有 AI Agent 一共发了约 11 万次请求。
主 Agent 的每一轮，大多是工具跑完，Agent 接着做下一步。剩下的是被别的事推了一下：其他 Agent 发来的消息，后台任务完成的通知，定时循环。不管哪一种，推一下，整段上下文就重传一遍。
所以这笔流量是几个数乘出来的：
每轮上传 × 每小时轮数 × 同时开着的 Agent 数 × 运行的小时数
拿那段记录来算，从第一个请求到最后一个是 9 分 24 秒，一共上传 631 MB，折合每小时约 4 GB。10 月 11 日早上另做过一次 5 分钟实时采样，本机 AI Agent 的上传折合每小时约 3.8 GB，相当于一刻不停地以 8 Mbit/s 多往外传，两次测量对得上。
上下文长，每轮上传就大；后台 Agent 多、通知多，后面几个数一起变大；而后台 Agent 是 24 小时不停的。
我们动了哪几处
查清楚以后，我们先改了两处。
一处是遥测。那段记录里它发了 246 次，占上传的约 6%。我们改成本地应答，由本机直接回复、不再把请求发出去，功能不受影响。这项改动在 10 月 11 日完成，上面的数都是改之前测的。
另一处是出口。我们让其中一台机器的出网流量不再经过这台中转服务器，它那一份就不再算进这台服务器的额度。
上下文长度我们没有动：90% 的上传来自主 Agent 在正常干活，这部分省下来，活就干得差了。当天我们又试了压缩请求体：接口照常收压缩过的请求，真实流量压完剩原来的一半到六成多。10 月 14 日起有个别压缩请求被拒，它按设计自动退回不压缩，先停一周。
为什么平时没人注意
跑 Agent 一直这么费流量：它每走一步，都要把攒下的整段上下文再传一遍，后台 Agent 又日夜不停地走。只是大多数时候没人看得见。
家里的宽带不按 GB 收钱，上传量也没人去看，个人用 Agent 很少碰到这件事。一旦流量要按量付费，它就成了账单上的一行：云服务器的出网流量，中转服务器，企业网关，手机热点。
如果你的团队要部署 Agent，成本表里除了 token 费，还应该有带宽和出网费。估算可以从那个乘式里前面三个数开始：主 Agent 每轮上传多少（我们 30 万 token 上下的上下文，每轮平均 1.7 MB），每小时跑多少轮，后台开着几个 Agent。我们的数放在这里供你对照：AI Agent 每小时上传约 3.8 GB（10 月 11 日早上 5 分钟采样折算）。
这些数来自我们自己的机器，时间是 10 月 11 日前后。服务器上的流量和额度用 GiB 计，其余用 GB，1 GiB 约等于 1.074 GB。
Flowness 是我们自己的多 Agent 框架，已经持续运行超过 6 个月，真实用在生产交付中，烧了粗略估计 1400 亿 Claude token。我们会继续分享用它干活时遇到的问题和做过的取舍。