为什么你的 AI 编码代理成本呈指数增长（以及该如何应对）

Source: Dev.to

成本模式概览

如果你在使用 Claude Code、Cursor 或任何基于 LLM 的编码代理，需要了解一种成本模式：会话随着规模增长呈二次方成本上升。exe.dev 的详细分析对此进行了拆解。

量化细分

• 缓存读取在对话长度增加时主导成本。

  • 在 27,500 token 时，缓存读取占总成本的 ≈ 50 %。
  • 在 100,000 token 时，缓存读取跃升至总成本的 ≈ 87 %。

• 实现一个普通的 “ho‑hum” 功能可能花费 $12.93。

成本公式

total_cost = output_tokens * num_calls
           + cache_read_price * context_length * num_calls

第二项呈二次方增长，因为 context_length 与 num_calls 同时增加。

缓解策略

1. 经常刷新上下文

使用全新会话并提供清晰提示重新建立上下文，通常比继续一个膨胀的对话更便宜。新会话的费用往往只是继续膨胀会话的一小部分。

2. 使用限定任务

为每个任务定义明确的规格和验收标准。这样可以保持会话简短且聚焦，AI 能够在规格指示的完成点停止。

3. 利用子代理

在独立的上下文窗口中完成的工作不会计入主对话的缓存。如果你的代理框架支持子代理（例如 Claude Code），可以为孤立任务生成新上下文。其开销通常低于不断增长的主上下文成本。

4. 批量调用工具

将一次文件读取拆成多个小读取 更昂贵，因为每次读取都会再次读取完整历史的缓存。尽可能批量进行工具调用。

SpecWeave 示例

SpecWeave 实现了这些思路：

• 每个任务都有 明确的规格和验收标准。
• AI 在该受限上下文中工作，防止 token 无限累积。
• 短小、聚焦的会话取代了开放式的马拉松式对话，降低了每个功能的成本。

为什么重要

上下文管理、成本管理和代理编排是相互关联的问题。遵循这些约束构建工作流的团队能够更快、更低成本地交付。早期采用者能够获得 真实优势——在保持相同速度的同时，每个功能的支出降低 最高 3 倍。

延伸阅读

• 完整分析：Why AI Agents Are Expensively Quadratic（exe.dev）

---

在你的 AI 编码工作流中，你注意到了哪些成本模式？