AI Coding Token 与成本分析：一次任务到底消耗了什么
先看一个很普通的任务
你对 Agent 说：
GET /reports/:id偶尔返回 500。请找到原因，修好它，补一个回归测试。
最后可能只改了两三个文件。可是在改文件之前，Agent 也许已经做了这些事：
- 读了项目里的
AGENTS.md和测试命令； - 搜索路由、数据库调用和重试逻辑；
- 打开了几份相关代码和一段错误日志；
- 跑了一次测试，发现自己的 Fixture 写错了；
- 改完后再跑一遍测试，并写出修改说明。
所以，任务的花费和 diff 大小没有直接关系。真正消耗资源的，往往是“为了找到答案，Agent 来回看了多少东西、试了多少次”。
这篇文章就围绕这个排错任务展开。我们先弄清 Agent 每一轮在做什么，再把 Token、缓存、工具调用、重试和人工审查拆开，最后给出一份团队可以真正落地的记录清单。
一、Agent 不是只补全代码，它会反复做四件事
现在主流的 AI Coding Agent——例如 Codex、Claude Code、GitHub Copilot coding agent——虽然产品形态不同，但工作方式很像：它们会读取上下文，决定下一步动作，调用工具，然后根据结果继续判断。官方文档可以参考 Claude Code、GitHub Copilot Agent 和 Codex。
把它说得直白一点，就是四步循环：
- 先看：读需求、规则、代码片段和上一步工具输出；
- 想下一步：决定继续搜索、打开文件、修改代码，还是先跑测试；
- 动手：调用 Shell、搜索、浏览器或其他工具；
- 检查：看命令结果、看 diff、跑测试，决定是否继续。
每循环一次，都可能多出一笔输入、多一段输出，或者一次工具运行。最后用户看到的“已完成”，只是这一串循环的最后一句话。
同一个产品名，不代表同一种账单
有的 Agent 是 API 按量计费，有的是订阅里包含额度，有的还会额外计算云端容器、浏览器或搜索服务。比较成本时，别只问“这个模型一百万 Token 多少钱”，还要问：
- 一次任务实际调用了几次模型？
- 工具是在本地跑，还是在云端跑？
- 失败后会不会自动重试？
- 最后花了多少人工时间审查？
只看月度席位或消息数量，很难回答“修好一个 Bug 到底花了多少钱”。
二、Token 到底是什么钱
可以把一次模型调用想象成把一叠材料交给模型：
- 输入 Token：你交给它的材料，包括 Prompt、项目规则、代码、历史对话和工具结果；
- 输出 Token：模型生成的计划、解释、代码修改建议和最终回复；
- 缓存输入：前面已经交过、这次可以复用的一部分材料；
- 工具结果：Shell、搜索、浏览器等工具返回的新材料。
OpenAI 和 Anthropic 都把输入、输出以及缓存相关用量作为独立计费维度，具体字段和价格会随产品变化。实际账单应以供应商当前的 OpenAI 定价、OpenAI Prompt Caching、Anthropic 定价 和 Anthropic Prompt Caching 为准。
先记住一个简单版本：
任务成本 ≈ 输入成本 + 输出成本 + 工具/运行时成本 + 人工审查成本为什么输入经常比你想象的多
你只输入了一句话，不代表模型只看了一句话。它可能还收到：
- 系统指令和项目规则；
- 当前对话历史；
- Agent 刚刚搜索出来的文件片段；
- 测试命令的输出；
- 你上一轮补充的限制条件。
如果 Agent 连续跑四五轮，后面的请求往往会带着前面的历史一起走。于是，一次“再搜索一下”，可能不只增加一次搜索结果，还会让后续每轮的输入都变长。
缓存不是免费，也不是魔法
如果一段稳定的规则和工具定义被反复使用，供应商可能把它放进 Prompt Cache。缓存命中通常比普通输入便宜，但创建缓存、缓存失效和缓存没被再次使用，都可能产生代价。
因此不要为了“命中缓存”把整个仓库永久塞进固定前缀。更实用的做法是：把稳定的规则放前面，把易变化的日志和临时内容放后面；然后看真实命中率，而不是凭感觉加缓存。
三、把一次排错任务摊开看
下面的数字是演示用的假设值，不是任何供应商的报价。
| 轮次 | Agent 做了什么 | 这轮新增了什么 | 假设用量 |
|---|---|---|---|
| 1 | 读规则、路由和测试 | 任务上下文 | 6,000 输入；1,200 输出 |
| 2 | 搜索重试逻辑 | 搜索结果 | 3,500 输入；700 输出 |
| 3 | 查看数据库适配器 | 代码片段和日志 | 8,000 输入；900 输出 |
| 4 | 修改代码和测试 | 补丁上下文 | 2,000 输入；1,100 输出 |
| 5 | 第一次跑测试失败 | 错误输出 | 4,000 输入；600 输出 |
| 6 | 修正 Fixture，再跑一次 | 修正后的上下文 | 2,000 输入；500 输出 |
| 7 | 汇报结果 | 最终摘要 | 1,000 输入；700 输出 |
表面上看，这是一个“小改动”。但它已经包含了 7 轮模型判断、多个工具调用和一次失败重试。
如果其中 18,000 个 Token 来自重复上下文，并且命中了缓存，台账至少要记成这样：
{
"task_id": "BUG-1842",
"input_tokens": 26500,
"cached_input_tokens": 18000,
"output_tokens": 5700,
"tool_calls": 9,
"retries": 1,
"human_review_minutes": 14,
"outcome": "merged"
}假设未缓存输入 $2 / 1M、缓存输入 $0.20 / 1M、输出 $8 / 1M，模型部分大约是：
(26,500 - 18,000) × $2 / 1M
+ 18,000 × $0.20 / 1M
+ 5,700 × $8 / 1M
= $0.0986这几分钱不是重点。重点是：输出 Token 虽然少，却可能更贵；缓存能降低重复上下文的价格；一次失败测试会同时增加模型调用和人的审查时间。
四、最容易浪费钱的地方，通常不是“写代码”
1. 读了太多无关代码
改一个服务，却让 Agent 先读完整个 Monorepo。它可能因此更“有背景”，但也更容易把真正的问题淹没。
2. 工具输出太吵
完整构建日志、依赖树、生成文件列表都塞进上下文，既贵又不容易读。让工具只返回失败附近的几十行，通常更好。
3. 需求在中途不断变化
如果已经改了一半，才补充“权限也要处理”“接口不能改名”，Agent 往往需要重新检查前面的决定。不是它故意绕路，而是任务边界变了。
4. 没有先写清楚验收条件
“修好它”很容易变成多轮猜测。更好的说法是：“修复 500，增加一个能复现旧问题的测试，运行命令 X，最后汇报通过的测试。”
一个实用的判断方法
每次复盘只问三个问题：
- 这一轮新读的内容，真的改变了下一步吗？
- 失败是因为模型能力不够，还是因为输入不清楚？
- 如果重来一次，最先删掉哪一段上下文或哪一次工具调用？
这样比盯着“平均每人用了多少 Token”更容易找到改进点。
五、别把“会话成本”当成“任务成本”
会话只是聊天窗口。一个窗口里可能混着三个问题；一个 Bug 却可能跨过本地 Agent、云端 Agent、CI 和人工 Review。
所以最好给每个任务一个稳定的编号，例如 BUG-1842，然后把下面这些东西都挂到它下面：
- 模型调用；
- 工具调用和运行时间；
- 测试结果；
- PR 或提交；
- 审查时间；
- 最终结果：合并、回滚、放弃或阻塞。
最小可用的调用记录可以很简单：
task_id
repository
model
input_tokens
cached_input_tokens
output_tokens
tool_calls
retries
runtime_seconds
review_minutes
outcome
evidence_uri注意：这里不是让团队给每个人打分。记录这些字段的目的，是找出“为什么这类任务总要重试”“哪个工具输出特别吵”“哪个模型路线合并率更高”。
六、便宜的模型，不一定带来便宜的结果
选择模型时，不要只看每百万 Token 的价格。真正应该比较的是：
- 第一次修改就通过审查的比例；
- 需要重试几次；
- 测试和回滚情况；
- 人工需要看多久；
- 从开始到合并用了多久。
一个常见而稳妥的分工是：
| 阶段 | 可以先尝试的模型 | 什么时候升级 |
|---|---|---|
| 找文件、做摘要 | 小模型 | 找不到关键路径或摘要不可靠 |
| 设计修改方案 | 中等或强模型 | 跨权限、数据或并发边界 |
| 改代码 | 能稳定通过项目测试的模型 | 出现反复返工 |
| 独立审查 | 与编码不同的模型或人工 | 任务风险较高 |
这是一个起点，不是规则。要用自己团队的任务记录验证，而不是照搬公开 Benchmark。
七、成本优化不能靠跳过验证
下面几种“省钱”方式，通常会把成本转移到更贵的地方：
- 不跑测试，省下几轮调用，却把问题留给线上；
- 关掉权限确认，让 Agent 更快执行危险命令；
- 把密钥和生产日志完整放进上下文，减少几次搜索；
- 只统计模型 Token，不统计云容器和人工审查。
尤其要注意缓存数据和日志。缓存并不意味着可以把秘密长期放进 Prompt；日志也不应该因为“模型能读”就不做脱敏。
真正可取的优化通常是：缩小无关上下文、减少工具噪声、让验收条件更早明确、把简单步骤交给便宜模型，同时保留测试和权限边界。
八、团队看板先记录事实，再谈优化
第一版看板不需要几十个图表。能回答下面这些问题就够了：
- 这个任务用了哪几个模型、工具和运行环境？
- 输入、缓存输入和输出分别是多少？
- 重试了几次，测试通过了吗？
- 最后合并了吗，还是回滚了？
- 人工审查花了多久？
可以先按四个视角看数据：
- 按任务结果：合并、回滚、放弃、阻塞；
- 按阶段：探索、实现、验证；
- 按模型路线：价格旁边同时看通过率和审查时间；
- 按浪费来源：过大上下文、重复工具调用、失败重试、空转运行时。
平均值不够。最好同时看中位数和 P90，因为少数复杂任务往往消耗大部分预算。
验收清单：你真的看懂一次任务的成本了吗？
拿一条真实任务记录，尝试回答：
- 哪些模型调用属于这项任务？
- Agent 读了哪些上下文，哪部分命中了缓存？
- 调用了哪些工具，重试了几次？
- 测试和人工审查给出了什么证据？
- 任务最终是合并、回滚、放弃还是阻塞？
- 下一步准备优化哪一处？用什么质量指标防止优化过头？
如果只能回答“这个月订阅花了多少钱”，你看到的是预算，不是任务成本。
结语：别只数 Token，要看它完成了什么
一次 AI Coding 任务的成本，不只是模型吐出了多少字。它还包括模型为了找到答案读了多少上下文、调用了多少工具、失败后重试了几次，以及最后有没有人花时间确认结果。
把这些信息挂到同一个任务编号下，成本才会从一个模糊的月度数字，变成可以解释、可以比较、也可以改进的工程记录。
下一篇文章再继续讨论：有了这些记录之后，怎样通过 AI Gateway 控制模型路由、权限和配额。