AI Agent 的钱花在哪：99% 是输入 token，而不是它写出来的代码
原作者：Paula Hingel 原文链接：https://www.augmentcode.com/guides/ai-coding-cost-analysis-agent-token-spend
结论先行
AI 编码 Agent 的成本结构和一个直觉相反：钱不是花在模型写出来的代码上，而是花在它每一轮重新读回去的上下文上。Anthropic 自己的成本示例里，一个 Sonnet 会话的 996,500 个 token 中，输出只有 5,300 个（0.5%），缓存读取占 94.5%。OpenRouter 的数据更极端：Claude 4 Sonnet 在 2025 年 9 月的日用量达到 1000 亿 token，其中 99% 是输入 token。
由此得出三条可操作的结论：一是循环设计（上下文增长、重试、扇出）比模型选择更能左右成本；二是同一任务不同运行的 token 消耗可以差 30 倍，而准确性往往在中等成本处达到峰值，说明超支多半来自低效探索而非更深推理；三是「便宜执行者 + 昂贵审查者」的分层路由能把基准成本压到 1/14。
原文出处
作者：Paula Hingel 原文：AI Coding Cost Analysis: Where Token Spend Really Goes in an Agent Loop（Augment Code Guides） 发布：2026-07-24 链接：https://www.augmentcode.com/guides/ai-coding-cost-analysis-agent-token-spend
文章引用了 Anthropic 的 Claude Code 成本文档、arXiv 上关于 Agent 花费的研究、OpenRouter 的用量数据，以及 Bun 迁移项目的公开复盘。
要点解读
1. 一次真实会话的成本构成
Anthropic 文档里 claude-sonnet-4-6 的一个会话是这样分布的：
| Token 类别 | 数量 | 占总量比例 |
|---|---|---|
| 缓存读取（cache reads） | 940,000 | ~94.5% |
| 缓存写入（cache writes） | 50,000 | ~5.0% |
| 输出（output） | 5,300 | ~0.5% |
| 未缓存输入（uncached input） | 1,200 | ~0.1% |
| 合计 | 996,500 | 100% |
这个会话的总成本是 $0.55。也就是说，你为「模型写代码」付的那部分，几乎可以忽略。
另有研究指出，Agent 编码消耗的 token 比单轮推理多 1,000 倍以上，输入与输出的比例超过 150:1。
本站判断：这条对 Web3D 项目尤其致命。三维项目的文件普遍更大——一个 Three.js 场景文件动辄上千行，着色器、模型加载、后处理都堆在一起。如果 Agent 每次都要把这些文件完整读回上下文，成本不是线性增长，而是随轮次滚雪球。
2. 循环里的四类消耗
| 类别 | 说明 |
|---|---|
| 上下文重读 | 工具结果一旦进入轨迹，后续每一轮都会保留。打开一个大文件或跑一条冗长命令，代价会在之后每一步重复支付 |
| 系统提示与指令重注入 | 系统提示、CLAUDE.md、仓库级指引每一轮都要重新注入 |
| 文件读取与工具定义 | 缺乏相关性索引的 Agent 会读更广的项目上下文；Anthropic 的 computer use 工具定义每个请求就要消耗 735 个输入 token |
| 压缩与扇出乘数 | 压缩、摘要、并行子 Agent 会成倍放大开销，因为每个分支都要携带足够的先前状态 |
3. 循环设计比模型选择更重要
同一任务不同运行之间的 token 消耗可以产生 30 倍波动。文章给出的量化节省如下：
| 技术 | 记录在案的节省 |
|---|---|
| 提示词缓存（prompt caching） | 长提示词的成本最多降低 90% |
| 上下文编辑（清除过期工具结果） | 100 轮评估中， token 减少 84% |
| 主动上下文压缩 | SWE-bench 任务节省 57%（4.0M → 1.7M token） |
| 隔离子 Agent + 记忆工具 | 相比基线性能提升 39% |
| 编码化提示（codified prompting） | 输入 token 减少 55–87% |
两个必须注意的反面：缓存的正确性和缓存存在与否同样重要（未命中会让同一长提示重新变贵）；压缩可能适得其反，当摘要隐藏了后续轮次需要的状态时，Agent 会重新去查一遍。文章建议摘要在清晰的阶段边界使用，而不是持续压缩。 还有一条容易被忽略的前提：没有硬性停止标准，上面所有优化都保不住——Agent 会靠不断重试和重新生成代码一直跑下去。
4. 便宜执行者 + 昂贵审查者
分层路由是文章里回报最直接的一节：
| 模式 | 配置 | 结果 |
|---|---|---|
| Aider architect | DeepSeek R1 规划 + claude-3-5-sonnet 编辑 | 64.0% 通过率，成本 $13.29；对比 o1 单机 61.7%、$186.50，便宜 14 倍 |
| Anthropic Advisor | Opus 建议 + Haiku 执行 | SWE-bench 41.2%，是 Haiku 单机 19.7% 的两倍多 |
| Anthropic Advisor | Opus 建议 + Sonnet 执行 | SWE-bench +2.7pp，每任务成本降低约 12% |
| BudgetMLAgent cascade | 免费基础模型 + 专家调用走 GPT-4 | 每次运行 $0.054 vs $0.931，便宜 94.2% |
| RouteLLM 路由 | GPT-4 / Mixtral-8x7B | 成本降低超过 85%，同时保持 GPT-4 95% 的性能 |
代价是延迟：R1 + Sonnet 的组合在 Aider 中每个案例耗时 251.6 秒，而单机模型只要 12.4 秒。
本站判断：这个「规划很贵、执行却很便宜」的分工，和三维开发的实际形态很契合——因为真正的难点在架构决策（比如场景怎么切分、哪些走实例化、LOD 策略怎么定），而写一个加载器、一个材质配置，就属于机械劳动。把后者交给便宜的模型，是当前最划算的做法。
5. Bun 的 16.5 万美元重写：数字和限定条件
Bun 公开的 Zig → Rust 迁移是文章里最大的一个案例：
| 指标 | 数值 |
|---|---|
| 迁移规模 | 535,000 行 Zig 转 Rust |
| 日历时间 | 11 天 |
| 提交量 | 6,778 次 |
| 并行度 | 约 64 个并行 Claude Agent |
| Token 形态 | 59 亿未缓存输入、6.9 亿输出、720 亿缓存读取 |
| 成本 | 约 $165,000 |
缓存读取量约为输出 token 的 100 倍。团队的对照估算：3 名工程师掌握完整代码库上下文，手工做约需 1 年。
三个限定条件必须一起读：Bun 于 2025 年 12 月被 Anthropic 收购，重写用的是预发布版模型而非通用可用版本，所以成本与能力都不是标准情形；$165K 应视为高度并行迁移的 API 费率成本。此外 Zig 作者 Andrew Kelley 公开批评其中一部分是「未经审查的垃圾」——质量和 token 支出是两个独立维度。
6. 别把「2000 万美元」当规划基准
文章专门澄清了一个流传很广的说法：没有任何一手来源支持「公司在实现 ROI 前花费 2000 万美元 token」，不建议拿它当规划基准。
取而代之的是把支出和工程信号连起来审计：
| ROI 信号 | 测量层 |
|---|---|
| Token 支出 | 发票与 API 用量，按模型和循环拆分 |
| 被接受的工作 | 已合并的变更 |
| 返工 | 被回滚的变更 |
| 审查负担 | 代码审查耗时 |
| 质量影响 | 缺陷逃逸与维护负担 |
这里还有一个很值得记住的对照实验：METR 的随机对照试验发现，经验丰富的开源开发者使用 AI 工具后慢了 19%，但他们自己估计是快了 20%——感知与实测之间有 39 个百分点的差距。
7. 给 Agent 设 token 预算的五个步骤
背景数据：FinOps Foundation 报告显示，98% 的 FinOps 团队已经把 AI 支出管理纳入工作（两年前只有 31%），Token 成本管理被列为首要挑战。
- 从自己的遥测数据设定额度：按团队区分缓存读取、未缓存输入和输出，而不是拍一个数字。
- 先归因再控制：按团队或成本中心拆分 API Key，通过 OpenTelemetry 导出每用户 token 指标。
- 用供应商的硬停止，并知道它的局限：GitHub Copilot 提供预算开关，在 75%、90%、100% 处告警；OpenAI 的项目级预算是软阈值，超出后仍会继续处理请求。
- 在循环内部运行时强制预算：月度上限只能拦住下个月的账单，运行时控制才能在任务中途决定继续、收窄、要审批还是停。
- 按被接受的结果衡量：把所有支出（含失败尝试和升级）相加，除以达到质量标准的变更数。
代码与验证
文章没有给可直接运行的代码，但给了一个可以立刻执行的自查动作：
拉取一个团队一周的会话级 token 数据，拆成缓存读取 / 未缓存输入 / 输出三类，再对照路由层级为每一轮定价。
判断标准也很明确：如果大部分支出是在前沿模型上为机械轮次重读上下文，那么架构变更能挽回合同变更触及不到的预算。
适用场景与坑
该用：任何跑 Agent 编码的团队，尤其是长时间自主运行、多轮工具调用、大文件仓库的场景——三维项目基本都符合。
别用：不要把这套结论套到单轮补全或简单问答上，那里输入输出比例完全不同，优化重点也不一样。
已知的坑：
- 缓存没命中的时候，同一个长提示会变得很贵，执行缓存的纪律比缓存开关要重要；
- 如果持续压缩会隐藏后续需要的状态，摘要比较适合放在阶段边界；
- 没有硬性停止的标准，Agent 就会一直重试，那么所有优化都白做；
- 分层路由会显著增加延迟（251.6 秒 vs 12.4 秒），如果做交互式场景就要权衡了；
- 「便宜模型执行」不等于「结果可接受」，质量和成本是两个维度的，必须分开度量。
