AI 辅助工程团队的成本结构分析

没有人掌握你的实际开销数据，任何所谓"典型"数字都只是别人的数字。可以迁移的是账单的构成逻辑——它由循环结构决定，而非工具决定。下面的每个数字都是你可以替换的输入。

三种请求形态，三种账单

为什么一次 Agent 会话值这个价

对话是无状态的。每一次交互都会把之前的所有内容重新发送，因此如果上下文以 b 个 token 开头，每轮增长 g 个 token——一次文件读取、一次测试输出、模型自己的上一条消息——那么第 i 轮发送的是 b + g·i，跨越 n 轮：

input_tokens(n) = SUM over i=0..n-1 of (b + g*i)
                = n*b + g * n*(n-1)/2          <- the quadratic term

ASSUMPTIONS (replace all four):
  b = 20,000    starting context: repo map, instruction file, task, 2 files
  g =  3,000    growth per turn: a file read plus truncated test output
  n =     25    turns before it stops
  out=    800   output tokens per turn

input  = 25*20,000 + 3,000 * 25*24/2 = 500,000 + 900,000 = 1,400,000
output = 25*800                                          =    20,000

二次项是 1,400,000 中的 900,000——几乎占会话的三分之二，而它不过是重复发送产生的。假设输入每百万 token $3，输出每百万 token $15，那么一次会话是 $4.20 + $0.30 = $4.50。

现在加上缓存。前缀在每一轮新内容开始之前都是稳定的，所以大部分重发内容都可以命中缓存。假设 90% 的输入读取来自缓存，缓存价格是未缓存价格的 10%：140,000 token 按 $3/M 计（$0.42）加上 1,260,000 token 按 $0.30/M 计（$0.378），输入降到约 $0.80，整个会话降到 $1.10。仅仅因为上下文布局的一个特性，就产生了四倍的差异。缓存在 Agent 循环中的临界价值比任何地方都重要，正是因为这个二次项。

二次项的另一个后果：轮次成本不是线性的。从 25 轮增加到 50 轮，会话成本不是翻倍，而是增加约两倍。轮次预算不只是安全阀，更是成本控制手段。

一个开发者的一天

同样处理，所有输入都标注了。换成你自己的；重点是总账的构成形态，不是总数。

AGENT       4 sessions x $1.10 (from above, cached)          = $4.40
CHAT        30 turns x 8,000 in  = 240,000 in  -> $0.72
            30 turns x 600 out   =  18,000 out -> $0.27      = $0.99
AUTOCOMPLETE 400 requests x 2,000 in = 800,000 in -> $0.12
             400 requests x   30 out =  12,000 out-> $0.01    = $0.13
                                                        day  = $5.52
                                    x 21 working days  month  = $116

在你质疑这些数字之前，有两点值得注意。Agent 工作在这份账单中占约 80%，而它只用了 434 次请求中的 4 次——那个每次交互成本最低的计数器主导了总量。而那个不断触发的自动补全，反而是占比最小的项目，因为小模型配小价格再乘以小输出，无论触发多少次总量都很小。

这张表里缺失的那一行是失败。没有产出任何成果的会话，成本和成功会话一样——甚至可能更高，因为它们往往是跑到轮次上限的那种长会话。如果三分之一的会话最终没有任何可用的 diff，每个落地变更的真实成本是会话成本的 1.5 倍，而解决方案不是用更便宜的模型，而是不进步停止规则——把 25 轮失败转换成 6 轮失败。追踪每个合并变更的成本，而非每个会话的成本，否则这个指标会把最值得改进的东西藏起来。

真正会让你惊讶的数字是人员之间的差异。一个在大仓库上跑长 Agent 会话的开发者，成本可能是中位数的十倍，而原因永远是 b、g 或 n 之一。按开发者归因是值得在讨论总额之前先做好的。

控制手段

限制 n。轮次预算加上 Agent 页面中的不进步停止条件。二次项使其成为杠杆最高的单一控制点，而且停滞的轮次本来就不产生任何价值。

缩小 b。起始上下文要被支付 n 次。一份 3,000 token 的指令文件跨 25 轮是 75,000 token；一份 12,000 token 的是 300,000 token。带着这个乘数来修剪仓库地图和指令文件。

缩小 g。截断的测试输出和行范围文件读取。每轮都反馈一次完整的冗长测试运行，是会话成本达到应有的四倍的最常见原因。

让前缀可缓存。稳定的内容放前面，易变的内容放后面。任何在提示词前端变化的内容——时间戳、打乱的文件列表——每一轮都会使整个缓存失效。

按轮次类型分流。不是每一轮都需要强模型。总结一次测试失败、决定下一步打开哪个文件、格式化一次编辑，这些都是小模型的工作；而规划和困难的补丁则不是。

关注推理 token。对于边思考边回答的模型，隐藏的 token 按输出费率计费，而且在转录中不可见——这是账单高于可见输出所暗示的数字时的常见解释。

你真正想做的对比

放在工资对比下，这些数字很小，这是实话。如果一次会话成本是 C，节省了时薪全成本 R 的工程师 t 分钟，那么：

C < R * t / 60

At C = $1.10 and an ASSUMED R = $100/hour:   t > 0.66 minutes
Whole-day spend of $5.52 pays for itself if it saves 3.3 minutes a day.

这就重新框定了整个预算对话。在这个比例下，token 账单不是决策变量；相对于工资单而言只是四舍五入的误差。决策变量是 t 是否为正——而在某些类型的工作上，已发表的证据表明它可能是负的，这是生产力页面的主题。花时间优化 $116 的月账单，不如花时间弄清楚哪些任务属于工具能够发挥作用的区间。

例外是规模相关的：一百名工程师乘以 $116 是每月 $11,600，而一个没有轮次上限的 Agent 循环，一个糟糕的下午就能产生一个完全不同的数字。预算控制是为尾部设计的，不是为中位数设计的——控制 Agent 支出覆盖的是机制本身。

按开发者追踪差异是让这个话题可操作的数字，它需要在请求级别进行归因：每个开发者每个工具一个 key 或 tag，用量在每次调用时记录。用量和成本如何按 key 报告，值得在第一张账单到来之前就设置好，而不是之后。

Building a Coding Agent That Can Run Tests

Giving a Coding Model the Right Context

Does AI Actually Make Developers Faster?