# 加速的成本 当 AI 从一次回答变成持续运行、并发协作的执行者，成本会从 Token 扩展到网络、存储、访问权与基础设施本身。 ## Metadata - HTML: https://glenzli.com/notes/cost-of-acceleration/ - Markdown: https://glenzli.com/notes/cost-of-acceleration.md - Collection: Notes - Language: zh-CN - Published: 2026-07-27 - Updated: 2026-07-27 - Tags: ai, agents, software-engineering, infrastructure, costs, judgment ## Content 最近，在一个持续推进的图像处理项目里，我让多个 Agent 同时处理不同的开发任务。不到两天，一项按流量计费的网络资源已产生超过 200GB 的流量。这显然超出了我对一个个人项目的预期。 ## 从安全事件开始 一开始，我把它当作安全事件处理：运行环境是否被攻击，是否有未知进程在上传数据，是否发生了不该出现的下载或外泄。出现这样的流量，先做这些排查本来就是正常顺序。 排除明显的外部攻击迹象后，我才回头怀疑起一个刚刚认真讨论过的变化：多 Agent 协作。 这次协作没有预先设计一套很重的 A2A 协议。我只给出了共同目标、基本边界和一份可以随着实践修订的最小契约。Agent 知道彼此存在，需要处理共享文件和冲突，也可以根据实际工作形成交接方式。 我开始怀疑，自己是不是把协作放得太开了。它们会不会在重复同步资源、搬运测试数据，或者为了“保持环境完整”而做了经济上不划算的事？这个猜测并不牵强。一个不知道哪些状态已经共享、哪些数据可以重建、哪些资源有价格的执行者，很容易在局部逻辑上做对事，却在整体成本上出错。 继续拆分流量、对照任务以后，问题显出了另一层性质。它既不像一次入侵，也不该简单归咎于某个 Agent。真正需要修正的，是我原先对 AI 成本过于狭窄的理解。 事后，我写了一个流量分析工具，按进程抽样看了看量级。一个活跃 Agent 十分钟产生几十 MB 往返流量并不奇怪；有些高频任务里，单个 Codex Agent 四十分钟就会接近 1GB。为了估算这次协作，我仍用更保守、也更好理解的十分钟 50MB。前后共创建了 7 个主 Agent，其中一些又拉起 10 个以上的子 Agent。即使只按主 Agent 同时带 4 到 5 个子任务、几段四小时的累计工作来算，活跃执行者也很容易来到几十个，流量落在百 GB 到 200GB 左右就不值得惊讶了。 ## 任务拆分，也会放大成本 数字背后还有一个容易被忽略的因素：任务会在执行中不断被拆分。在一个涉及 GPU 管线的复杂任务中，单个主 Agent 在整个执行过程中前后启动过多达 80 个子 Agent。我无法追踪它们有多少真正重叠，也不能把这个数字直接换算成八十倍流量；它至少说明，复杂任务的成本不只取决于某一刻有多少 Agent 在线，还取决于任务在过程中被拆开、重新理解和交接了多少次。 协作会把这种拆分进一步放大。不同主 Agent 为了修改或判断同一片复杂代码，也会各自派生子任务补齐背景。以 RAW 管线为例，算法、处理流程和既有实现，可能被几组 Agent 分别分析。人受时间和注意力限制，常会略过与当前修改关系不大的逻辑；Agent 没有同样的默认收缩动力。只要一项分析看起来有助于降低不确定性，它就可能继续展开。缺少共享结论、范围声明和成本反馈时，局部合理的拆分会累积成上下文装载、工具调用、数据传输和计算上的重复开销。 这不是对每一 GB 的完整归因。实际任务会有空闲、重试、不同大小的上下文和不同的同步路径，单个 Agent 的流量也不会恒定。但它足以说明，200GB 不需要由某一个失控进程制造。安全疑点由此变成了一个更朴素的问题：一套持续并发、不断拆分任务、又反复重新理解的 AI 协作，到底会带来哪些日常运行成本？ ## Token 只是账本的一页 谈 AI 成本时，最先想到的往往是模型价格和 Token 数量。这没有错。对一次问答或一次代码补全，推理通常就是主要成本；压缩上下文、控制输出、选择合适模型，依然有效。 但多个 Agent 持续协作，并不是把一次回答复制几遍。它们会读取、修改、验证、同步、等待和恢复。多个任务并发以后，状态复制、远程环境准备、构建产物、测试数据和任务交接也会进入运行过程。 更接近现实的是一份需要逐项核对的账本，而不是一条精确公式： ```text AI 的运行成本 = 模型推理 + 状态与数据移动 + 构建、测试与计算 + 网络、存储与副本 + 运行时间 + 人的检查、恢复与决策 + 外部服务的额度、信誉与可用性 ``` 不同任务的占比当然不同。纯文本工作流里，Token 可能仍然占大头；持续运行、带远程状态和大文件的工程协作里，网络和同步很快就不能忽略。 对这类协作而言，关键不在某一个特别昂贵的动作，而在各项消耗会随并发、持续时间、副本数量和任务不断拆分一起上升。跨过某个阈值后，面对的已经不是“多开了几个聊天窗口”，而是一套持续消耗现实资源的执行系统。 《当速度开始改变探索》讨论过，执行速度提高以后，个人可以在更短时间里把判断带到现实中。这次经历补上了另一面：速度也让一个人能调度比过去多得多的并发执行者，资源消耗随之从个人习惯变成需要专门处理的运行问题。 ## 访问权也会被消耗 账单并不是唯一的代价。 此前，我曾让 Agent 高频调用 GitHub CLI，结果触发了 GitHub 的风控标记。调用本身是正常维护，唯一显著的变化，是 AI 把原本由人低频完成的操作提升到了更高、更持续的频率。到现在，申诉仍然没有结果。 平台没有理由知道这些请求背后的完整协作关系。它只能依据请求频率、访问模式、来源和历史行为判断风险。当 AI 把一项操作放大到团队规模时，即使每一次调用都有理由，合在一起也会进入另一套风险模型。对平台而言，这正是风控该处理的情形。 家庭宽带和其他共享基础设施也有相似风险。持续的高流量如果没有及时发现，未必只意味着多花一点钱；它也可能触发运营商的异常使用管制，影响网络本身的可用性。 因此，AI 持续运行时，消耗的不只是 CPU、磁盘和带宽，也包括外部服务的额度、账号信誉和可用性。运行时需要区分“技术上还可以继续执行”和“继续执行是否会耗尽额度、触发风控或影响服务可用性”。一句 prompt 很难处理这类后果。 ## 加速会放大一切 并发只是其中一个乘数。任务会持续运行，也会为了消除不确定性不断派生新的分析和执行。按照聊天使用方式形成的直觉，很难估计这种工作会如何放大读取、同步、验证、重试和外部服务调用。 Agent 不一定只跑几个小时，也可以常驻一整天。模型和工具执行越来越快以后，同一段时间里会塞进更多分析、同步、验证和外部调用；快的代价会落在远比推理更广的地方。 如果这种工作方式被广泛采用，影响不会只停留在个人账单上。更多常驻任务、更多副本、更多上行流量，以及更多落在第三方服务限流和风控系统里的自动化行为，会形成一种不同于传统网页访问或少量后台任务的负载形态。 互联网是否会因此被压垮，尚未可知。数据本地性、增量同步、共享缓存、按任务归因、限流和配额，都可以显著改变结果。但这些东西需要成为 Agent 基础设施的一部分，不能等到事故发生以后才补上。 模型能力越强、执行速度越快，这些问题越不能被当成附属品。AI 的规模化不仅是推理的规模化，也是网络、存储、身份、信誉和服务可用性的规模化。 ## 让 AI 看见运行成本 这件事没有推翻我对 Agent 协作的判断。问题不在于是否应该写一套细密的协议，把每一次同步和交接都预先规定下来。 它让此前的判断多了一个条件：如果希望 AI 根据环境自主协作，系统就必须让与任务有关的成本和后果变得可见。 只告诉 AI“完成 RAW pipeline”并不够。运行环境至少需要让它能够获得这些信息： - 哪些数据可以离开本地，哪些必须留在原处； - 网络、存储和计算预算还剩多少； - 哪些资源和结论已经共享，哪些范围正在被其他 Agent 分析，哪些副本可以重建； - 某项外部服务的请求频率、额度和账号状态是否接近风险边界； - 超过什么阈值后应该降级、暂停，还是请求人工确认。 这些信息不必再写成一套规定每一步动作的行为协议。更重要的是把价格、余量和后果交给执行者，让它们成为判断的一部分。 《奥卡姆很忙》讨论过，局部协作规则可以在实践中形成，权限、证据和高风险操作的边界则需要更稳定。资源预算和外部访问权大概也属于后者。它们不要求把路径写死，却不能被默认忽略。 这也和《AI 脚手架的半衰期》里的取舍不同。为了弥补模型短板而建立的流程，可能随着能力提升被删掉；但可观测性、归因、硬额度、人工确认和恢复记录连接的是现实后果，不应被当成可以随手撤掉的脚手架。 这里更值得期待的，不是继续预设一长串节流规则，而是让 AI 在运行中看到真实成本，并据此重新规划。它也许会选择不再复制已有状态、改用增量同步、把计算留在数据附近，或者在接近预算和风控边界时主动换一条路径。这样的取舍本来就是动态问题；在不可绕过的边界之内，让 AI 根据实时情况规划，通常比人工事先写死阈值和流程更灵活，也更贴近任务。 当然，显示“网络还剩 30GB”并不会自动得到理想结果。资源反馈仍需要可靠的测量、按任务归因和真正不可绕过的限制。环境契约不是取消约束，而是让约束不只停留在 prompt 里，并让 AI 有机会在边界之内自己作出更合适的取舍。 ## 还没有结束的复盘 这次事件还留下几件需要继续验证的事：流量具体分布在哪些路径、任务和副本上；哪些同步确实有价值，哪些只是重复移动；哪些预算适合交给 AI 权衡，哪些必须直接停止；以及怎样衡量多个 Agent 协作完成同一任务时的真实单位成本。 暂时没有完整答案。但它把一个原本模糊的常识变成了具体数字：我当然知道规模会放大成本，却从来没有认真算过这道乘法。直到把单个 Agent 的开销、并发层级、任务不断拆分和运行时间放进同一笔账里，才知道它会这么快抵达怎样的量级。 当 AI 只是一次回答时，Token 是很好的近似。当它开始持续工作、彼此协作并接触真实基础设施时，成本会沿着网络、磁盘、计算、外部服务和人的注意力扩散。 一个任务即使完成得很漂亮，也可能带来一笔没有人准备承担的消耗。AI 不只需要理解目标，也需要看见完成目标正在付出什么代价。这样，速度才有机会转化为更好的判断，而不只是更快地消耗资源。 ## 相关笔记 - [奥卡姆很忙](https://glenzli.com/notes/occam-is-busy) - [当速度开始改变探索](https://glenzli.com/notes/speed-matters) - [AI 脚手架的半衰期](https://glenzli.com/notes/half-life-of-ai-scaffolding) - [说明书之外](https://glenzli.com/notes/software-beyond-the-manual)