LLM Agent 的隐藏成本陷阱：为什么你的 AI 编程助手越用越贵

一个不太直觉的事实

你有没有注意到，用 AI 编程助手（Cursor、Copilot Agent、Claude Code 等）做一个稍复杂的功能时，前几轮对话飞快又便宜，但越到后面越慢、越贵？

这不是错觉。最近 exe.dev 团队发表了一篇很有意思的分析文章 Expensively Quadratic，用数据揭示了一个 LLM Agent 架构中的固有问题：成本增长是二次方的。

Agent Loop 的工作原理

几乎所有编程 Agent 都遵循同一个模式：

1. 把完整对话历史发给 LLM
2. LLM 返回回复 + 工具调用
3. 执行工具，把结果追加到对话历史
4. 重复步骤 1

关键在于每次调用都要发送完整的对话历史。第 1 轮发 1000 tokens，第 2 轮发 2000，第 10 轮发 10000……这是一个典型的等差数列求和问题，总输入量是 O(n²)。

Cache 救不了你

“但是有 prompt cache 啊！” 你可能会说。

确实，现在主流 LLM 提供商都支持 prompt caching——之前发过的内容不用重新计算，从缓存读取就行，价格大约是正常输入的 1/10。听起来很美好，但问题是：

• Cache read 虽然便宜，但不是免费的
• 随着对话增长，cache read 的 token 数量也在二次方增长
• exe.dev 的实际数据显示：一个普通功能开发对话总计花费 $12.93，到对话末尾，87% 的成本来自 cache reads
• 在对话达到约 27,500 tokens 时，cache reads 就已经占了一半的成本

换句话说，cache 只是把二次方成本打了个折，但二次方本身还在那里。

这对开发者意味着什么

1. 长对话是成本杀手

一个持续 50 轮的 Agent 对话，后半段每一轮的边际成本都远高于前半段。如果你发现月底账单惊人，大概率不是因为用的次数多，而是单次对话太长。

2. “帮我重构整个项目” 是最贵的请求

让 Agent 在一个长会话里完成大规模重构，意味着海量的上下文在反复传输。拆成多个小任务反而更经济。

3. 上下文窗口越大 ≠ 越好

厂商们在卷上下文窗口长度（128K、200K、1M），但更长的窗口意味着更大的二次方成本空间。能用的上下文和该用的上下文是两回事。

可能的解决方向

这个问题有根本解吗？几个思路：

• 对话压缩/摘要：定期把历史对话压缩成摘要，控制上下文长度。一些 Agent 框架已经在做这件事。
• 分层记忆：短期对话 + 长期记忆存储，避免把所有信息都塞进 prompt。
• 任务拆分：把大任务拆成独立的小对话，每个对话保持短小精悍。
• 更好的定价模型：提供商可以对 cache reads 进一步降价，或者提供 session 级别的计费方式。

我的看法

这篇文章揭示了一个被忽视的架构问题。我们总在讨论 LLM 的能力边界，却很少关注成本边界。实际上，对于日常开发场景，成本上限比能力上限更早到来。

作为开发者，最实际的建议是：保持对话简短，任务拆细，不要让一个 Agent 会话无限膨胀。 这不仅省钱，也能让 Agent 的输出质量更稳定——毕竟超长上下文中的注意力衰减也是个已知问题。

AI 编程助手确实在改变我们的工作方式，但理解它的成本模型，才能真正用好它。

---

参考：Expensively Quadratic: the LLM Agent Cost Curve