一篇搞懂 AI Coding Agent 的 Token 成本控制（上）

本文为《一篇搞懂 AI Coding Agent 的 Token 成本控制》系列第 1 篇（共 3 篇），建议连续阅读。

适用：CodeBuddy、Cursor、Codex、Gemini CLI 等这类 AI Coding Agent。

读完你会得到三样东西：一个正确的心智模型、一份今天就能做的行动清单、几套继续往下压成本的工程方法。

月初看账单，吓一跳。

也没问多少问题，Token 怎么烧成这样？

后来认真拆了一轮，才发现一个反直觉的事实：

你问的那句话，在每次请求里可能连 1% 都不到。

真正的成本大头藏在别的地方。这篇文章，就是把这个"别的地方"讲清楚，然后给一套从日常使用习惯、模型路由，到工具层、代码图谱、多 Agent 协作的完整优化方法。

第一章 账单都花在哪了

很多人一上来先优化提问方式：把句子写短一点，把形容词删掉一点，把问题问得更"像 Prompt Engineer 一点"。

方向不算错，但经常抓错重点。

因为在 AI Coding Agent 里，真正决定账单的，通常不是你手里敲进去那几十个字，而是系统为了让模型"看起来懂上下文"，自动帮你带上的那一大坨东西。

先把一轮请求拆开看清楚，再谈优化。否则你会一直在省零钱，漏掉大头。

1.1 你问的那句话，其实最便宜

先看一个典型的请求结构：

System Prompt        5K
项目说明文档          10K
Skill 定义            20K
Tool / MCP 定义       30K
历史会话             100K
代码文件              50K
用户问题               0.1K

这不是所有产品都一样的精确账单，而是一种很常见的分布。

它传递的信息很明确：

贵的是系统塞进去的东西，不是你写的那句话。

很多人本能地把优化方向定为"怎么把问题写短点"。这当然不是坏事，但它抓不到主要矛盾。因为模型真正收到的，不是"你的问题"，而是"带着整包上下文的问题"。

可以把一轮请求近似理解成这个公式：

总成本 ≈ 固定前缀 + 会话历史 + 运行时检索 + 工具往返 + 模型输出

这里面有三层东西：

• 固定前缀：System Prompt、Skill 定义、Tool / MCP 定义、稳定背景文档
• 半固定上下文：项目说明、Repo Map、Memory、长期约束
• 动态上下文：聊天历史、代码片段、检索结果、工具返回、你这轮新问题

你那句提问，往往只是最后一撮"点火器"。它负责触发任务，但通常不是成本主体。

这个结构可以画成一张很直观的图：

[图片：请求成本结构示意图]

这也是为什么很多人会产生错觉：

我明明只问了一句话，怎么这么贵？

答案是：你只问了一句话，但系统替你背了一整车背景。

当你理解这一点，后面很多优化动作就会突然变得合理：为什么要开新会话，为什么要压缩历史，为什么要少装 Skill，为什么要做代码图谱。这些动作看上去分散，本质都在做同一件事：

减少重复上下文。

1.2 "它明明记得"只是一种幻觉

AI Coding Agent 用久了，很容易产生一种感觉：

它好像一直记得我们聊过什么

但实际上，大模型本身通常是无状态的。

真正"记得"的，不是模型，而是包在模型外面的 Agent / CLI / 平台层。它在每一轮请求前，把历史、规则、工具、代码、文档重新拼起来，再发给模型。所谓"记忆"，很多时候只是"再次传入"。

这个过程可以简化成：

[图片：Agent 记忆/重传机制示意图]

这件事为什么重要？因为它直接决定了成本结构。

第一，会话越长，后续每一轮越贵。因为历史不是"存在那里等模型自己想起来"，而是很可能在每轮都要重新带过去。

第二，工具越多，常驻定义越重。一个 Tool / MCP 不只是"多一个按钮"，而是多一段要让模型理解的说明、参数模式和调用约束。

第三，工具调用会形成回路。模型先读一大包上下文，再调用工具；工具返回一段结果；结果又被塞回上下文，再进入下一轮。于是一次任务，不是一次计费，而是一连串"请求—返回—再请求"的链条。

所以 AI Agent 最怕的不是问题复杂，而是：

• 会话越滚越长
• 工具越堆越多
• 背景越塞越满
• 每次都从零找信息
• 输出不合格反复重试

很多人说"它明明记得"。更准确的说法其实是：

不是它记得，而是系统在一遍遍提醒它。

1.3 五种成本，不止是"输入字数"

做成本优化，先别把 Token 理解成"字数"。

Agent 场景里至少有五类开销，要分开来看：

这里最容易被低估的，往往是后两项。

工具往返成本的问题在于：你以为自己只是"让它查个文件"，但模型其实经历的是：理解工具定义 → 生成参数 → 接收返回值 → 再结合返回值继续思考。对人来说只是一个动作，对系统来说可能是多段上下文交换。

重试成本更隐蔽。真正烧钱的，常常不是第一次调用太长，而是第一次不合格——格式不对、结构错、找错文件、推理过度——于是又来一轮。

第一次没答对 → 重新描述问题 → 重新附带历史 → 重新拉代码或工具结果 → 再跑一轮模型

所以很多"看起来只补了一句话"的修正，实际含义是：

错误的第一次调用 + 第二、第三次修正调用 = 整包上下文被反复付款

这也是为什么"减少重试"本身就是一种非常硬的成本优化手段。格式约束更清楚、任务边界更明确、上下文给得更准，省下来的不只是一次输出，而是整条失败链路。

1.4 Prompt Cache：为什么它是所有优化的基础

理解了成本结构，就能理解为什么 Prompt Cache 这么重要。

很多人第一次听到缓存，会以为它缓存的是"答案"。其实更接近的理解是：缓存的是稳定前缀的处理结果。也就是——如果两次请求前半段几乎一样，服务端就不必每次都从头处理那一大段相同内容。[1]、[2]

原理可以先粗略理解成：

固定前缀 → 缓存命中 → 不用每次都从头处理

最容易被缓存的内容，通常是这些：

• System Prompt
• Tool / MCP 定义
• Skill 定义
• 长文档背景
• 稳定的 few-shot 前缀

为什么官方文档总在强调"静态内容放前面，动态内容放后面"？因为缓存命中的对象通常是前缀，不是整段任意位置的拼图。

看这张图就很容易懂：

[图片：Prompt Cache 前缀缓存示意图]

这里有三个很关键的推论。

第一，Prompt Cache 省的不是首次成本，而是重复成本。 第一次发送长前缀时，通常还是要正常付费；价值在第二次、第三次、后续很多次复用时才会体现出来。

第二，缓存不是"写短"，而是"写稳"。 你天天改系统提示词、天天调 Skill Prompt，那缓存理论上存在，实践里也很难命中。

第三，缓存优化和上下文治理是一回事。 减少前缀抖动、把稳定内容前置、把变化内容后置，本质都在提升"可复用比例"。

所以 Prompt Cache 本质上不是让模型更聪明，而是让你别为同一段前缀反复买单。官方数据也说明了这一点：OpenAI 与 Anthropic 都提到，长前缀命中缓存后，输入成本和延迟都可能显著下降。[1]、[2]

Token 优化重点，不是把提示词写短，而是把前缀写稳。

（缓存的具体配置方法，会在后文工具层详细展开。）

1.5 一张全图：五层模型

梳理完成本来源后，再看优化路径就会清楚很多。

这篇文章核心框架分五层：

[图片：五层优化模型示意图]

它们不是并列的小技巧，而是一条从便宜到贵、从易到难的升级路径。

• 使用习惯解决的是"无意义的历史和废 Token"
• 模型路由解决的是"贵模型干便宜活"
• Context 工程解决的是"同样前缀重复发送"
• 代码图谱解决的是"每次都从零找代码"
• Agent 架构解决的是"所有任务都塞给同一个大上下文"

这五层背后其实只有一个总目标：

• 让模型少看无关内容
• 让便宜模型多干标准活
• 让贵模型只做高价值推理

还有一条贯穿全文的线：观测与预算治理。

没有数据，优化就会变成体感。你觉得自己"省了"，但不知道省在哪，也不知道是不是用质量换的。这个话题会在后文继续展开。

到这里，第一章真正想建立的心智模型可以浓缩成一句话：

AI Coding Agent 的成本，本质上不是"你问了什么"，而是"系统为了回答你，重复搬运了多少上下文"。

一旦你脑子里有了这张图，第二章那些"看起来很琐碎"的使用习惯，就不再是经验技巧，而会变成非常自然的工程动作。

第二章 使用习惯：最便宜也是最被低估的优化

如果你现在就想开始省 Token，最先动的不是架构，不是知识图谱，而是使用习惯。

这层几乎零工程投入，却经常拿到第一波最大收益。接下来的九个习惯，都是今天就能改的。

2.1 一个 Session，一件事

很多人把 AI Agent 当成永不关闭的长会话：上午修 Bug，下午写文档，晚上聊架构，第二天接着来。

体验很顺，成本是灾难。

原因很简单：Session 越长 → 继承的历史越多 → 每一轮越贵。

一个 Session 只服务一个目标。

修 Bug 开一个，做重构开一个，写文章开一个，查线上问题开一个。别混着来。

Topic 切分就是最便宜的 Context 管理。

2.2 长会话不压缩，就是负债

很多人舍不得清历史，觉得"越完整越稳"。

模型不需要你的完整试错过程。它需要的是：

• 现在要干什么
• 做完了什么
• 哪条路不通
• 卡在哪了
• 下一步怎么做

/compact 做的，本质上是这一件事：

1 把完整历史
2 压成可继续工作的状态

对话记录不是资产，未压缩的长对话是负债。它让后续每一轮都背着越来越重的历史包袱。

2.3 聊天记录不是数据库

很多团队把背景、决策、约束、待办全挂在会话里，指望 Agent 一路记到底。

后果：会话越来越长，状态越来越难提炼，成本越来越高。

真正该长期保留的信息，外置出去：

• 项目文档
• Summary 文件
• Memory 文件
• Repo Map / Knowledge Graph
• 任务清单

让会话只承载"当前工作状态"，而不是全部项目历史。

2.4 少说废话，也是省 Token

很多人优化只盯输入，忘了输出一样贵。

编码场景最浪费的回答不是"错"，是"废"：先复述一遍问题，再讲一段众所周知的背景，然后一堆礼貌性铺垫，最后才给结论。

如果你只需要 diff、步骤、结论、表格、JSON——直接要求它这么给。

这类约束值钱，因为它同时省两类：

1. 输出更短
2. 结果更可用 → 重试更少

在很多日常任务里，一句指令就够了：

直接给结论，不要复述问题，必要时再展开

Caveman 这类思路受欢迎，不是"简陋"，而是直接打掉高频废 Token。

2.5 Skill ≠ 免费能力

Skill 有价值，但也背成本。

每个 Skill 都带着 Description、Instructions、Examples、触发逻辑。这些信息如果常驻，就会进上下文。

问题不是"装不装"，而是：

哪些常驻，哪些按需加载。

高频、稳定、通用的 Skill 常驻。低频、长说明、低复用的按需触发。

和后端服务治理同理：常驻能力要尽量少而精。

2.6 MCP 越多，不一定越强

MCP 的最大诱惑是让 Agent "什么都能接"。

但从成本看，每多一个 MCP，就多一份 Tool Definition、多一层选择成本。

很多人装了 GitHub、Notion、Jira、Slack、Browser、Filesystem、Kubernetes、Docker 和各种内部系统。看起来很强，实际高频用的就两三个。

工具太多不只是"文档长"的问题：

• 选择空间变大 → 决策变慢
• 错误调用概率变高
• 每轮携带定义更重

所以工具治理和依赖治理一样：关键不是能不能装，是有没有必要常驻。

2.7 CLI 优先于 MCP

这是一个有点尖锐但很实用的原则：

1 能 CLI 解决 → 尽量 CLI
2 能脚本解决 → 尽量脚本
3 最后才考虑 MCP

很多操作已经有非常成熟的 CLI：gh pr create、kubectl get pods、docker ps、git diff。

AI 直接走命令更轻，不需要额外拉一整套工具说明。

对于国内常见的研发平台，也有专门为 AI Agent 优化的 CLI 工具可以直接用：

• tapd-ai-cli：腾讯 TAPD 的 AI Agent 专用 CLI，支持需求、缺陷、任务的查询和更新。直接用 tapd story list、tapd bug create 之类的命令操作 TAPD，比拉一套 MCP 轻得多，还能用 tapd skill init 一键生成 SKILL.md 配置。
• gongfeng-cli：腾讯工蜂代码托管的 AI Agent 专用 CLI，专门针对 Agent 的认知模式优化了输出格式（Markdown + JSON 混合），支持 PR 创建、代码评审、项目管理等完整工作流，Token 消耗显著低于同等 MCP 方案。

这两个工具的共同思路值得借鉴：专为 Agent 设计，而不是给人看的 UI 套了个 CLI 壳。输出格式、信息密度、命令发现机制，都针对 AI 的调用模式做了优化。

MCP 的价值在：跨系统编排、结构化返回、权限统一收敛、内部业务能力包装。

所以不是"CLI 永远优于 MCP"，而是：

已有成熟命令链路时，不要为了看起来高级而过度工具化。

2.8 引用文件时带完整路径

这是一个极其容易忽视的小习惯，但省的 Token 实实在在。

很多人引用文件时习惯只写文件名：

1 看一下 config.go 的问题
2 帮我修改 utils.py

AI 收到这类请求，往往要先搜索整个项目找这个文件在哪，有时候还会搜到同名文件或路径不确定，再次搜索确认。这些搜索调用和返回结果，全部计入 Token。

更直接的做法：

1 看一下 src/config/config.go 的问题
2 帮我修改 @/Users/yourname/project/utils.py

用 @ 符号加上相对路径或绝对路径，Agent 直接定位读取，不需要搜索任何中间步骤。

这个习惯对大型项目更显著——项目越大，搜索代价越高，目录层级越深，搜索越容易绕弯。

1 只写文件名 → 搜索 → 可能多次确认 → 读取
2 完整路径   → 直接读取

一个 @路径 节省的，是一整条搜索链路。

2.9 把意图一次说完，别聊天式拆碎

AI Agent 的使用场景里，有一种很常见的低效模式：

[图片：聊天式拆分意图示意图]

表面上看，这是"正常沟通"。实际上，每一轮来回都在消耗 Token：重新组装上下文、重新带入历史、重新确认状态。四轮对话的成本，往往是一次完整表达的好几倍。

更省的做法是一次把意图说清楚：

1 看 @src/order/service.go 的 CreateOrder 函数，
2 找出潜在的 bug，修复，并为修复后的函数写单测。

这不是要求你写得长，而是要求你把目标说完整。一次对话，Agent 一次性跑完整个任务，省去了所有中间确认的来回成本。

越具体、越完整的指令，浪费的轮次越少。这和程序员提 Issue 的逻辑是一样的：把背景、期望、验收条件都写清楚，沟通成本才不会比写代码还贵。