62 分钟交卷，Token 用了预算的 192 倍：一次多 Agent 实测复盘

给 Agent 的预算是 100 万 token，或者 2 小时，哪个先到就停。

它带着三个子 Agent，62 分钟交卷。事后追问日志才发现，累计用量已经到了 1.92 亿 token，接近预算的 192 倍。

时间还剩一半，另一项预算早就超了。

这次复盘让我重新看待多 Agent 的效率：把实现、审计、测试分给不同角色以后，主 Agent 仍然要协调、读报告、检查版本、纠正工具结论。这些工作都在消耗上下文，而完成报告很容易把它们略过去。

交卷报告看起来挺顺

任务是用 Three.js 做一部程序化叙事影片《远岬夜航》：战机在航母上准备，弹射升空，冲出云层，穿过夜间峡湾里的塔架，打靶，再返航降落。

要求交付一个 HTML 文件和一份说明文档，时长 90–240 秒，除了 Three.js，不能使用外部资产。飞机、航母、地形和特效都得自己生成。

这次运行由一个主 Agent 加三个子 Agent 完成。主 Agent 负责统筹和验收；三个子 Agent 分别负责演出实现与文档、飞机资产与运动审计、测试与像素回读。除启动和一次「继续」之外，用户没有逐步指挥。

最后交付的是一部 180 秒、六幕的片子。34 条自动检查通过，0 条失败，另有 1 条人工检查项和 1 条信息项。整场播放没有页面错误，也没有控制台报错。

如果复盘到这里结束，很容易留下一句「多 Agent 配合得不错」。但这些结果只回答了任务完成了什么，没有回答用了多少资源。

7.73 倍，究竟比的是什么

同一道题还有一次 Codex 运行，可以作为观察参照。先交代来源：本文沿用实验笔记中的统计，Harness 一侧由代理读取本地会话日志汇总；Codex 一侧来自运行者的自查报告，没有独立复核原始日志。两边都统计到交卷为止，不包含后续讨论用量的消耗。

这里的 Harness，指组织模型调用、工具和多 Agent 协作的运行系统。

对齐口径后，Harness 主 Agent 的总量是 3859.88 万 token，Codex 那次是 499.19 万，相差约 7.73 倍。

但主 Agent 的输出只有 4.62 万 token，Codex 则是 7.86 万。输出更少，总量却高出这么多，差距主要出在输入。两边总量差额中，缓存输入这一项占了约 98.8%。

这些数不能直接从字段名相加。Codex 的 input_tokens 已经包含缓存输入，另一边的 input 只记未缓存输入。比较时要统一拆成未缓存输入、缓存输入、输出三部分；推理 token 已包含在输出里，也不能重复计算。

再把三个子 Agent 算上，情况是这样的：

• 主 Agent：约 3860 万 token。
• 三个子 Agent 合计：约 1.53 亿 token。
• 整次运行合计：约 1.92 亿 token。

图中展示本次运行内部的用量构成，缓存输入占全体总 token 的 99.01%；下文的 98.48% 则指主 Agent 缓存输入占其全部输入的比例。

全体总量约为 Codex 那次的 38.43 倍。但它比较的是一整组 Agent 和另一次运行，不能拿来替换前面的 7.73 倍，更不能据此宣布某个框架效率差了几十倍。

两次虽然题目相同，模型、实际工作量、验证强度和产物质量却没有控制一致。Codex 那次约 44 分 43 秒，这边约 62 分钟；这次没有显示出时间优势，也没有同一 Harness 下的单 Agent 对照组，所以无法测出并行本身到底节省了多少时间。

这组数据能支持一次成本复盘，支撑不了框架排名。

缓存命中率很高，累计输入仍然很大

主 Agent 的缓存输入占全部输入的 98.48%。缓存确实大量命中了，但全部输入仍累计到约 3855 万 token。

缓存命中率和累计用量回答的是两件事。前者说明本次读入的内容有多少可以复用缓存；后者把每轮调用的输入都记了进去。同一段上下文被反复带入后续调用，就会反复出现在累计统计里。

这也不意味着某一刻的上下文窗口里塞了几千万 token。那是多轮相加的结果。总 token 倍率同样不能当作费用倍率，本文没有按两边实际定价计算账单。

从过程记录里，可以看到几种值得检查的开销。

主 Agent 的交互比较碎，一件事拆成多条消息交代；子 Agent 交回长报告和代码片段，主 Agent 继续读取；实现反复更新，中间版本和检查记录不断进入上下文；验收时，主 Agent 还要核对版本和工具结论。

这些动作可能增加调用轮数，或拉长每轮携带的上下文。不过，消息发送不一定立即触发一次独立模型调用，消息也可能排队。笔记没有统计调用次数和上下文长度分布，因此不能给每种开销分配比例，更不能据此判断哪一边的压缩策略更差。

能确定的是：子 Agent 的调用用量单独统计，它们交回的报告又会进入主 Agent 的上下文。委派出去的工作，仍然会产生后续阅读和复核成本。

有些检查抓到了真问题，有些检查制造了返工

这次过程里，有个很具体的错误：像素检查工具把清屏操作改成了不执行，上一帧残留的彩色火球被当成了飞机的像素区域。

那一轮检测结论是错的，需要先修测试工具，再重新验证。另一次扫描也误报过确定性问题，修正工具后才撤回。

还有一轮测试读到了实现尚在修改的中间产物，结果只能作废重跑。实现和测试虽然并行了，测试对象却没有固定下来。

这些返工增加了工具调用、解释、核对和重新读取上下文的次数。它们很适合成为下一次优化的对象。

但验证也确实抓出了 NaN、撞山、机头瞬间转向等问题。只盯着 token 降幅，把检查全部删掉，交付质量很可能跟着变差。

而且，34 条检查通过也不能替代视觉评价。这次所用模型无法直接看图，依靠的是 ASCII、像素和几何检查。它能验证部分可计算的约束，却不能直接判断镜头好不好看。

记录中仍有局部低对比、轻微裁切、轮子短暂压入甲板、航路加速度偏大和位置硬切等问题，两边产物也没有做盲评。因此，不能假设这次额外的消耗都换成了更好的成片。

预算要能让运行停下来

这次最明确的问题，是预算只写在题面里，没有变成覆盖整个运行过程的停止条件。

过程主要跟踪了墙钟时间。62 分钟交卷，满足了两小时这一项，却没有满足「累计输入加输出 100 万 token，先到者为准」。

按包含缓存输入的口径，Codex 那次用了预算的约 4.99 倍，Harness 全体用了约 191.86 倍。即使把缓存输入完全扣掉，Harness 的未缓存输入加输出仍有约 190.68 万，也超过了 100 万。

这里不能靠「每个 Agent 自己注意节省」解决。主 Agent 和子 Agent 都可能只看到自己的一部分，整体预算需要运行系统统一汇总，并在达到条件时停止后续调用。

如果再做一次，我会先改三个地方。

首先，把预算落实到整棵会话树。开工前为实现、审计、测试预留份额，运行时持续累计主子 Agent 的用量。时间和 token 两项都检查，不能等交卷后才查账。

其次，让测试对应一个固定版本。实现交出可测版本后记录文件哈希，测试结论绑定这个版本。后续修改发生了，再根据改动决定需要重测什么，避免拿中间产物的失败结论来回讨论。

最后，减少默认进入上下文的信息。子 Agent 先回结论、关键证据和待处理事项，详细日志落文件，主 Agent 有疑问再读。可以一起交代的任务合并发送，已经有证据支持的结论也不必让多个角色无差别重验。

这些调整保留了独立检查，也让每次往返有明确用途。

这次实测还不能回答「多智能体协作值不值得」。我缺少同条件对照，也缺少产物质量评估。但它已经暴露了一个具体问题：任务分出去以后，协调、验收和纠错的消耗仍在累积，而预算没有把这些工作管起来。

下一次实验，我希望交卷时就能同时拿到完成时间、全体累计用量和质量记录。至少，不用再靠事后追问，才发现预算早已失效。

原文信息

作者：cxjwin（@cxjwin），AI 编程与 Agent 实践博主

原文地址：