笔记
加速的成本
最近，在一个持续推进的图像处理项目里，我让多个 Agent 同时处理不同开发任务。
不到两天，一项按流量计费的网络资源产生了超过 200GB 的流量。
这显然不是我对个人项目的预期。
从安全事件开始
一开始，我把它当成安全事件：运行环境是否被攻击，是否有未知进程上传数据，是否发生了异常下载或外泄。
先查这些，很正常。
排除明显的外部攻击后，我才开始怀疑刚刚放开的多 Agent 协作。它们会不会重复同步资源、搬运测试数据，或者为了“保持环境完整”，做了局部合理、经济上却非常不划算的事？
一个不知道哪些状态已经共享、哪些数据可以重建、哪些资源正在计费的执行者，很容易把眼前的任务做对，同时把整体成本做错。
继续拆分流量、对照任务以后，问题显出了另一层性质。它不像入侵，也不该简单归咎于某个 Agent。
真正出错的，是我对 AI 成本的理解太窄。
事后，我写了一个流量分析工具，按进程抽样。活跃 Agent 十分钟产生几十 MB 往返流量并不罕见；有些高频任务里，单个 Codex Agent 四十分钟接近 1GB。
为了估算这次协作，我用了更保守的十分钟 50MB。前后共创建 7 个主 Agent，其中一些又拉起 10 个以上的子 Agent。即使只按主 Agent 同时带 4 到 5 个子任务、累计工作几段四小时来算，活跃执行者也很容易来到几十个。百 GB 到 200GB，已经不需要一个失控进程才能解释。
这不是对每一 GB 的完整归因。任务会空闲、重试，上下文大小和同步路径也不同。
但数量级已经足够刺眼。
任务会自己拆开
并发不是唯一的乘数。任务还会在执行中不断拆分。
一个涉及 GPU 管线的复杂任务，单个主 Agent 前后启动过多达 80 个子 Agent。我无法确认它们有多少真正重叠，也不能把这个数字直接换成八十倍流量。它至少说明，成本不只取决于某一刻有多少 Agent 在线，也取决于任务被拆开、重新理解和交接了多少次。
协作会进一步放大这件事。不同主 Agent 为了判断同一片复杂代码，可能各自派生子任务补齐背景。以 RAW 管线为例，算法、处理流程和既有实现，会被几组 Agent 分别分析。
人受时间和注意力限制，常会跳过与当前修改关系不大的逻辑。Agent 没有同样的默认收缩动力。只要一项分析看起来能降低不确定性，它就可能继续展开。
缺少共享结论、范围声明和成本反馈时，局部合理的拆分会累积成重复的上下文装载、工具调用、数据传输和计算。
于是，安全疑点变成了一个更日常的问题：
一套持续并发、不断拆分、反复重新理解的 AI 协作，到底在消耗什么？
Token 只是账本一页
谈 AI 成本，人们最先想到模型价格和 Token。这没有错。对一次问答或代码补全，推理往往就是主要成本。
但多个 Agent 持续协作，不是把一次回答复制几遍。
它们会读取、修改、验证、同步、等待和恢复。任务并发以后，状态复制、远程环境、构建产物、测试数据和任务交接，都进入运行过程。
更接近现实的，是一份账本：
AI 的运行成本 =
模型推理
+ 状态与数据移动
+ 构建、测试与计算
+ 网络、存储与副本
+ 运行时间
+ 人的检查、恢复与决策
+ 外部服务的额度、信誉与可用性不同任务占比不同。纯文本工作里，Token 可能仍占大头；持续运行、带远程状态和大文件的工程协作里，网络和同步很快就会追上来。
关键也不一定是某个特别昂贵的动作，而是各项消耗随并发、持续时间、副本数量和任务拆分一起上升。跨过某个阈值以后，面对的已经不是“多开几个聊天窗口”，而是一套持续消耗现实资源的执行系统。
速度让一个人可以调度过去需要一个团队才能提供的执行力。
账单也会很快长成团队的样子。
访问权也会被消耗
账单不是唯一代价。
此前，我让 Agent 高频调用 GitHub CLI，结果触发了 GitHub 的风控标记。每次调用都是正常维护。唯一显著的变化，是 AI 把人原本低频完成的操作，提高到了更持续的频率。到现在，申诉仍然没有结果。
平台看不到这些请求背后的完整协作关系。它只能根据频率、访问模式、来源和历史行为判断风险。即使每次调用都有理由，合在一起也会进入另一套风险模型。
家庭宽带和其他共享基础设施也一样。持续高流量不只意味着多花钱，也可能触发异常使用管制，直接影响网络可用性。
AI 持续运行时，消耗的是 CPU、磁盘和带宽，也是外部服务的额度、账号信誉和访问权。
技术上还能继续，不等于继续执行没有代价。
一句 prompt 很难承担这种判断。
加速会放大一切
Agent 可以常驻一整天，也会为了消除不确定性继续派生分析和执行。按照聊天形成的成本直觉，很难估计它怎样放大读取、同步、验证、重试和外部调用。
模型和工具越快，同一段时间里就会塞进更多动作。快的代价，最终落在远比推理更广的地方。
如果这种方式普及，影响也不会只停在个人账单上。更多常驻任务、更多副本、更多上行流量，以及更多撞上第三方限流和风控的自动化行为，会形成一种不同于网页访问和少量后台任务的负载。
互联网会不会因此被压垮，尚未可知。数据本地性、增量同步、共享缓存、任务归因、限流和配额，都能改变结果。
但这些东西必须进入 Agent 基础设施，不能等事故替我们写需求。
AI 的规模化，不只是推理规模化，也是网络、存储、身份、信誉和服务可用性的规模化。
让 AI 看见代价
这件事没有让我放弃 Agent 协作。它只是给“让 AI 根据环境自主协作”补上一个条件：系统必须让成本和后果可见。
只告诉 AI“完成 RAW pipeline”不够。它还应该知道：哪些数据不能离开本地；网络、存储和计算预算还剩多少；哪些资源和结论已经共享；哪些副本可以重建；外部服务的额度和账号状态是否接近风险边界；超过什么阈值应该降级、暂停或请求确认。
这些信息不必变成一套规定每一步动作的行为协议。更重要的是，把价格、余量和后果交给执行者，让它们进入规划。
资源预算和外部访问权，与权限、证据和高风险操作一样，属于稳定边界。它们不要求把路径写死，却不能被默认忽略。
为了弥补模型短板建立的流程，可能随着能力提升被删掉；可观测性、归因、硬额度、人工确认和恢复记录，连接的却是现实后果。它们不是脚手架。
理想情况下，AI 看见真实成本以后，可以减少状态复制，改用增量同步，把计算留在数据附近，或者在接近预算和风控边界时主动换路。
当然，显示“网络还剩 30GB”不会自动产生理想决策。资源反馈还需要可靠测量、按任务归因和真正不可绕过的限制。
环境契约不是取消约束。是让约束不只活在 prompt 里。
这笔账还没算完
这次事件仍有很多细节需要验证：流量分布在哪些路径、任务和副本上；哪些同步有价值，哪些只是重复搬运；哪些预算可以交给 AI 权衡，哪些必须直接停止；多个 Agent 完成同一任务时，真实单位成本又是多少。
暂时没有完整答案。
但它把一个模糊常识变成了具体数字。我当然知道规模会放大成本，却没有认真算过这道乘法。直到把单个 Agent 的开销、并发层级、任务拆分和运行时间放进一笔账，才知道它会多快抵达这样的量级。
当 AI 只是一次回答，Token 是很好的近似。
当它开始持续工作、彼此协作并接触真实基础设施，成本会沿着网络、磁盘、计算、外部服务和人的注意力扩散。
一个任务即使完成得很漂亮，也可能留下一笔没人准备承担的消耗。
AI 不只需要理解目标，也需要看见完成目标正在付出什么。
否则，加速只是更快地消耗资源。