AI 智能体到底用多少流量？面向自主智能体的按 MB 成本指南

搜索"AI 智能体用多少流量"，几乎每一条结果讲的都是 token——那是大模型厂商用来给上下文和生成计费的单位。但一个会浏览网页、调用工具、跑在真实设备上的自主智能体，同时还在移动网络上搬运真实的字节。这是两个完全不同的计量表，把它们混为一谈，是你把智能体接到蜂窝网络上时最贵的一个错误。本文把两者拆开，并给出网络这一侧的数量级——恰好是没有人回答的那一侧。token 那半边的讨论已经被写烂了，这里不再重复。

token 不是兆字节

一个 token 是一小段文本（大约 4 个字符，约合 0.75 个英文单词），大模型厂商用它给一次请求定价。而兆字节衡量的是穿过网络的原始字节数。两者松散相关，但绝不是一回事，而且网络那一侧的数字，几乎总是比人们预期的小得多。一个直觉换算是：token 数量乘以每个 token 的字节数，才是线路上真正流动的数据量，而多数人在这一步之前就已经按"上下文很大"直接脑补成了 GB。

把账算一遍。英文文本在 UTF-8 下大约每个 token 4 字节。所以一个 200,000 token 的上下文窗口——这已经是非常大的提示词——在线路上也只有大约 800 KB 的文本。一次典型的 1,000 token 提示配 500 token 回答，来回各不过几 KB。大模型应用的瓶颈在 token 计量表（成本）和 GPU（延迟），不在带宽。即使是规模相当大的大模型应用，通常总带宽也远低于 100 Mbps；一个中等规模的多用户聊天应用，下行只需要其中的一小部分。中文在 UTF-8 下每个字占的字节比英文字母多，但结论不变：这仍然是很小的数字。

你发出去的 token 要花钱，也带来延迟。它们在网络上变成的那些字节，几乎只是个尾数——而这恰恰说明，按 GB 卖的流量套餐对一个文本智能体来说是错误的形状。

一张按任务拆分的带宽表

下面这些都是数量级估算，不是实测基准。真实数字高度依赖你的任务组合、响应是否流式返回、一个页面你到底下载了多少、以及是否抓取图片。请把它当成规划用的包络线，不要当成规格书。如果你要给一支智能体机群做容量规划，最好的做法是先用自己的日志跑一周实测，再拿这张表做交叉校验。

实例推演：一个研究型智能体的一天

假设你跑一个自主研究智能体，一天里发起 200 次大模型 API 调用，并以纯文本方式抓取 100 个网页。这种任务组合在做资料检索、竞品监控、每日简报的智能体身上非常常见。粗算如下：

• 200 次 API 调用 × 平均约 20 KB = 约 4 MB
• 100 次纯文本页面抓取 × 约 0.3 MB = 约 30 MB
• 合计：约 34 MB，这已经算是自主工作相当忙碌的一天

这要花多少钱？34 MB 的一天在 Roamzy 上，按法国费率约 $0.03，按美国费率约 $0.07——计量表只对真正搬运过的兆字节收费，并按各国当地费率结算。换句话说，一整天的自主工作，在网络这一侧的成本连一杯咖啡的零头都不到，真正贵的仍然是 token 和算力。

如果同一个智能体把每个页面连图片带脚本整个渲染一遍，那 100 次抓取会膨胀到约 250 MB。所以智能体流量账单上最大的杠杆根本不是大模型，而是它究竟下载了页面的静态资源，还是只取了它需要推理的那部分文本。同样一批目标网址，一个只取正文的抓取器和一个跑完整浏览器渲染的抓取器，账单能差出一个量级。

为什么 1GB 套餐对文本智能体会大部分都用不掉

现在把这个每天 34 MB 的智能体放到一张常规旅游 eSIM 上：1GB / 7 天套餐。一周下来它可能搬运约 34 MB × 7 = 约 240 MB——前提是它每天都全力运行。更现实的情况是，一个轻量智能体一天只用几 MB。无论哪一种，你付的都是 1,024 MB 的钱，而只用掉其中一小块。套餐还会在 7 天后到期，没烧掉的部分直接消失。这就是结构性的错配：固定容量包的容量和时限，是照着"度假时刷视频的人"设计的，不是照着一个啃 KB 的文本智能体设计的。携程、飞猪上那些出境流量包是同一个形状，问题也一样。还有更麻烦的一层：套餐跑满之后，智能体通常不会优雅地降级，它只是断网，然后你在日志里看到一长串超时，而真正的原因写在一张你没盯着的流量卡上。

按兆字节计费把这件事翻了过来。智能体只为它真正搬运的字节付几分钱，剩下的余额永远不会作废，而且——这才是对自主性真正重要的部分——智能体可以读取自己的用量、给自己设开销上限。这三件事——查余额、估成本、到点停手——是把"无人值守"从一句口号变成可运维状态的最小集合。完整机制见按兆字节计费的 eSIM 详解。

用程序计量并封顶开销

人会注意到流量套餐快用完了，智能体需要的则是一个接口。Roamzy 提供 MCP 服务器（12 个工具）以及 REST API，智能体可以自己查余额、在动手之前先估算成本、到达上限就停下——不需要控制台，也不需要人守在回路里。由于计费是按兆字节、用 USDT/USDC 稳定币结算、无需账号、无需 KYC，智能体可以端到端地自行开通连接——不存在一张会在结账时被拒付的银行卡——它直接用稳定币为连接付费。它甚至可以对自己带来的下游用量赚取 20% 返佣。关于这种形态为什么适合机器买家，可以读AI 究竟能买哪一种 eSIM 和智能体商务与连接。

一张 eSIM，智能体跑到哪都算数

自主智能体不会一直待在一个国家。在日本执行任务的智能体、部署在德国附近的一批爬虫、在新加坡的监控机器人、在美国的现场设备，要的是同一件事：一条到哪里都能用、计费方式完全一致的连接。Roamzy 是覆盖 193 个国家的单一全球 eSIM——在巴西、印度或阿联酋都是同一套按 MB 计量表——你不必为每个地区各配一份套餐、各记一个到期日。上手流程见给你的 AI 智能体配一张全球 eSIM，候选方案的横向比较见最适合 AI 智能体的 eSIM。对跨境部署的团队来说，这还顺带省掉一件杂事：不必为每个地区各留一套采购、续费和到期提醒的流程。

实用结论

• 给蜂窝连接做预算时，量字节，别量 token——它们是两个不同的计量表。
• 文本智能体在带宽上很便宜——每天个位数到几十 MB，是现实的包络线。
• 渲染完整页面才是真正的成本推手。除非确实需要，就只取文本，别取静态资源。
• 固定 GB 套餐对文本智能体会大部分都用不掉，然后过期；按 MB 计费让支出与用量对齐，而且永不过期。
• 给智能体一个能看见自己开销的接口，它才可能自我封顶——这正是 MCP 和按 MB 定价解锁的能力。

常见问题

AI 智能体的数据用量，是按 token 算还是按兆字节算？

两者都算，但它们衡量的是不同的东西。token 是你的大模型厂商为模型读写的文本计费的单位；兆字节是穿过网络的原始字节。给移动或蜂窝连接做预算时，你关心的是兆字节；而对一个文本智能体来说，这个数字通常远小于 token 数给人的印象——线路上大约每个 token 4 字节。两张账单要分开看：一张交给大模型厂商，一张交给网络。

一个纯文本智能体每天实际用掉多少移动流量？

按数量级估算，一个繁忙的纯文本智能体，一天发起几百次 API 调用、以文本方式抓取网页，可能搬运几十兆字节；轻一点的只有几兆。这些是规划用的估算，不是基准测试——你的真实用量完全取决于它打开多少页面、以及是否下载图片和脚本。想拿到确定答案，最快的办法是在设备上记一周的实际流量。

为什么 1GB 的 eSIM 套餐对 AI 智能体是浪费钱？

因为一个文本智能体可能只用掉 20–50 MB，而套餐卖给你的是 1,024 MB，你为从未搬运过的数据付了钱——而且没用完的余额会在套餐有效期（通常 7 天）结束时清零。按兆字节计费只对真正流动过的字节收费，在 Roamzy 上余额永不过期，一台闲置几周的设备也不会因为"套餐到期"而丢掉已付的钱。

AI 智能体能自己控制连接开销吗？

能，前提是服务商提供机器接口。Roamzy 提供 MCP 服务器和 REST API，智能体可以查余额、在行动前估算成本、到达上限就停下——全部以编程方式完成，不需要任何人类控制台。以 USDT/USDC 稳定币结算、无需账号也无需 KYC，让智能体能够端到端地自行开通连接，从下单到充值到用量监控都不必转交给人。

什么情况会让智能体的流量账单暴涨？

渲染带全部静态资源的完整网页。网页中位数约 2.2 MB，其中仅图片一项就接近 1 MB，所以下载完整页面而不是只取文本，可能把智能体的带宽放大 10× 甚至更多。如果你的智能体只需要对文本进行推理，那就抓 HTML，跳过静态资源；确实需要渲染时，把渲染限定在少数几个必须的页面上。