3918 vs 1046：AI Agent成本控制实战深度分析

Level 0 的 Arc Ops 让重试工具调用变得可安全重复。Level 1 阻止了重试放大故障。但这两者都无法限制你自己累积的账单，而五美元的最高费用只是一个没有归属的数字——这个归属才决定最终结果。

参考工作负载是一个月末结账场景：6 步、8 次调用、72 个计费单元、741 美分——其中 400 美分集中在一个不可分割的单元里，一次批量重定价一旦开始就计费且无法中途停止。这个单一属性驱动了整个 Level 的设计逻辑。

python -m arc_ops.levels.l2_cost_caps.demo   # 以下所有数字均可重新计算
python -m pytest -q                          # 369 个测试，无网络，无模型

代码仓库：https://github.com/dev48v/arc-ops - 公开可用，MIT 协议，依赖项 = []，369 个 pytest，其中 119 个在新增的 5 个 L2 文件中，还有一个页面不抓取任何自身内容：https://dev48.infy.uk/arcops/level2-cost-caps.html

仪表盘不是上限。当上限设为 250 时，在末尾读一次表的那个观察者会收取完整的 741 美分；最好的观察者——每 tick 轮询一次、零聚合延迟、逐块发布——收取 521 美分，仍然超限，因为那笔 400 美分的调用早已启动。将延迟精确保持在一个 tick，然后在上限可能落到的所有 741 个位置上扫一遍：这个相同延迟的边际成本从 3 美分到 400 美分不等，在 tick_late == 1 的每一行中跨了 133 倍。秒是预算保证的错误单位。

细粒度本该是解决方案。

逐块计费在 741 个上限中的 445 个上与逐调用计费完全相同（字节级一致），且共享其最坏情况，因为那笔昂贵的调用本身就是不可中断的。

L1 的反转重演了，而我事先没有预料到

对照组完全不设上限：200 个任务交付，209,244 美分，每个 1,046.22。扫一遍所有上限，没有一个值能改善这个数字。有七个反而让情况更糟。

当上限为 400 时，fleet 支出的 90% 什么都没买到。上限并不降低成本。它只是将其重新分类——从已交付工作变为浪费——而承担这部分的人就是那个提出了在 90% 处中止的任务的人。

然后是废墟。在同一个上限下重启那 58 个中止的运行，最终完成了 0/58：696 次尝试，891,924 美分，每次尝试计费相同，所以更多尝试不等于缓慢推进。带检查点的恢复完成了 58/58，成本为无上限价格的 1.08 倍。而 L0 的门就在那里——无键重启复制了 662,900 美分的副作用，无键恢复 44,900 美分，两者任一加上键控都是 0。

并发击败了天真的计数器。8 个 worker 对抗 1,000 美分预算，提交了 1,600 美分而计数器只报告了 200——超支在它自己的仪表上完全看不见。

206 个页内断言。下一个是 L3，审批门控：上限决定了一个 Agent 可以花多少钱，而这里没有任何东西决定它被允许做什么。九个 Level，逐一展开：https://dev48.infy.uk/arcops.php