AI Coding Agent Token成本优化指南（上）：成本结构、使用习惯与模型路由

月初看账单，吓一跳。

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

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

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

真正的成本大头藏在别的地方。这篇文章，就是把这个"别的地方"讲清楚，然后给一套不用装任何工具、今天就能用的省钱方法。

---

第一章 账单都花在哪了

很多人一上来先优化提问方式：把句子写短一点，把形容词删掉一点，把问题问得更“像 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、长期约束
• 动态上下文：聊天历史、代码片段、检索结果、工具返回、你这轮新问题

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

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

flowchart TB Q["你主动输入<br/>用户问题：0.1K"] subgraph S["系统自动补齐"] direction TB SP["System Prompt：5K"] PD["项目说明文档：10K"] SK["Skill 定义：20K"] TL["Tool / MCP 定义：30K"] HS["历史会话：100K"] CF["代码文件：50K"] end

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

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

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

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

减少重复上下文。

1.2 “它明明记得”只是一种幻觉

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

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

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

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

这个过程可以简化成：

flowchart TD U["用户提问"] --> A subgraph A["Agent / CLI"] direction TB S1["取系统提示词"] --> S2["拼历史消息或摘要"] --> S3["附 Skill / Tool 定义"] --> S4["读取代码、文档、检索结果"] --> S5["组装完整请求"] end A --> L["LLM API"] --> O["输出答案 / 发起工具调用"] --> N["结果再被塞回下一轮上下文"]

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

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

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

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

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

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

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

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

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

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

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

成本类型	它是什么	为什么会放大
输入 Token	系统提示词、历史消息、代码片段、检索结果、工具定义	每轮都可能重复携带，是最大头
输出 Token	模型最终回答的文字	回答越长、越啰嗦、越容易失控
推理 Token / thinking budget	模型内部用于思考和规划的预算	简单任务如果走高推理档位，会明显溢价
工具往返成本	工具描述、调用参数、返回结果进入上下文	一次工具调用，常常比原问题还长
重试成本	第一次做错后重新来一轮	每修一次，都可能把整包上下文再付一遍

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

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

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

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

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

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

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

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

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

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

原理可以先粗略理解成：

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

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

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

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

看这张图就很容易懂：

flowchart TB subgraph R1["请求 1"] P1["系统提示词 / Tool 定义 / 项目背景"] --> A["本轮问题 A"] end subgraph R2["请求 2"] P2["系统提示词 / Tool 定义 / 项目背景"] --> B["本轮问题 B"] end P1 -. "相同前缀，可复用" .-> P2

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

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

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

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

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

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

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

1.5 一张全图：五层模型

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

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

层级	主题	作用	特点	覆盖
第一层	使用习惯	先减少无意义上下文	零成本，立刻可做	本篇覆盖
第二层	模型路由	让不同任务匹配不同模型	ROI 最高	本篇覆盖
第三层	Context 工程	稳定前缀，减少重复传输	系统级优化	下篇覆盖
第四层	代码图谱	减少盲搜，缩短检索链路	收割检索成本	下篇覆盖
第五层	Agent 架构	把任务分给对的单元	提升长期可维护性	下篇覆盖

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

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

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

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

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

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

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

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

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

---

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

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

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

2.1 一个 Session，一件事

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

体验很顺，成本是灾难。

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

一个 Session 只服务一个目标。

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

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

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

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

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

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

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

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

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

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

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

能 CLI 解决 → 尽量 CLI
能脚本解决 → 尽量脚本
最后才考虑 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 实实在在。

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

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

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

更直接的做法：

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

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

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

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

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

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

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

sequenceDiagram participant U as 用户 participant A as AI U->>A: 帮我看一下这个函数 A->>U: 你想让我做什么？ U->>A: 找一下有没有 bug A->>U: 找到一个问题，要修吗？ U->>A: 修一下 A->>U: 修好了，还要写测试吗？ U->>A: 写一下

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

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

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

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

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

---

第三章 模型路由：别让贵模型干便宜活

习惯层做好之后，下一步收益最高的，是模型路由。

很多人一上来就犯一个错：所有环节默认最强模型。看起来稳，实际上最烧钱。

3.1 匹配优先，不是便宜优先

模型路由不是“一律用便宜的”，而是先把任务类型分对：

• 复杂任务 → 强模型
• 简单任务 → 便宜模型
• 重复任务 → 稳定模型

架构设计需要长链路推理，该用贵的就用。写单测、补注释、生成提交信息的，便宜模型完全够用。大规模批量分类和摘要，适合低单价模型或离线批处理。

3.2 一张表说清楚

任务	推荐模型档位	理由
写 UT	便宜模型	模式稳定、模板化
写 commit	便宜模型	输出短、风险低
Code Review	中高档模型	需要语义理解
架构设计	强模型	长链路推理
复杂 Bug 分析	强模型	多步假设和验证
批量分类/摘要	低价或 Batch	规模大、成本敏感

选模型不是凭喜好，是按任务需要的能力。

3.3 先过便宜模型，再升级

很多任务不需要一上来就最贵模型。

更省的模式可以简化成一条升级链路：

便宜模型先跑
↓
判断复杂度
↓
需要才升级

例如：先让便宜模型分类（重构？Bug？文档？），先做初筛（PR 有没有高风险？），先做摘要（20 页 → 1 页），再交给强模型做推理。

这种级联工作流，既省钱，又让贵模型花在刀刃上。

3.4 不只换模型，也要调预算旋钮

现在很多模型提供成本旋钮：

• reasoning effort
• thinking budget
• verbosity
• max output tokens

它们影响的，其实是同一组东西：

想多深、答多长、花多少钱

Google Gemini 的 thinkingBudget 允许按任务控制思考 Token，简单任务甚至可以压到 0（关闭思考）。OpenAI 也建议很多工作负载从 low 的 reasoning effort 起步。

不是所有任务都要深度思考，也不是所有任务都要长答案。 让一个模型用高推理档位做分类、摘要、提交说明，本质上是在拿推土机扫地。

3.5 Skill / Agent / Command 都应该绑定模型

模型路由不该只存在于“主对话框”的心智里，要落实到执行单元。

Skill 绑定模型：写 UT、commit、格式修复、样板代码，明确绑定便宜模型。

以 CodeBuddy 为例，SKILL.md 文件头部可以直接声明模型和上下文策略：

---
context: fork
model: deepseek-v4-pro
---

model 字段指定该 Skill 使用的模型，context: fork 表示把这类固定流程放到独立执行上下文里，适合任务边界清晰、可单独完成的 Skill。这样一来，低复杂度的 Skill 就能自动走便宜模型，也不必把主会话的全部历史都带进去。

斜杠命令（Slash Command）和 Agent 同样支持 model 参数绑定，在定义时就固化好模型选择。这样团队里每个人用 /commit、/gen-ut 这类命令时，都默认走便宜模型，不需要依赖个人记得切换。

Agent 绑定模型：

Planner  → 中高档
Coder    → 中档 / 便宜
Reviewer → 强

Command 绑定模型：很多命令本身就是固定模板，适合预设便宜模型。

这类设计一旦固化，成本治理就从“靠人记得切”变成“系统默认更省”。

---

本篇小结

本篇讲了三件事：

第一，搞清楚钱花在哪。 不是你问的那句话，是历史、工具定义、代码文件反复被带上去。减少重复上下文，是所有优化的根本逻辑。

第二，习惯层的收益被低估。 一个 Session 一件事、及时 /compact、控制输出格式、少装 Skill 和 MCP、CLI 优先、引用文件带完整路径、意图一次说完——这些不需要任何工具配置，今天就能开始用。

第三，模型路由的 ROI 非常高。 不是所有任务都值得用最贵的模型。按任务匹配模型，加上 reasoning effort 控制，通常是改动最小、收益最快的工程化手段。

好的习惯加上合理的路由，是在不动任何架构的前提下，能拿到的最大一块收益。这也是为什么这篇文章放在最前面——工具可以慢慢配，但习惯越早建立越好。

---

今天就能做的行动清单

• /new 切断无关历史，一个 Session 一件事
• 长会话及时 /compact，别让历史变包袱
• 指定输出格式，减少废话和重试
• 清点 Skill 和 MCP，低频的卸掉或按需加载
• 简单任务手动切便宜模型
• 能 CLI 就先 CLI，别过度工具化
• 引用文件时用 @路径，不要只写文件名让 AI 去搜索
• 意图一次说完，避免聊天式拆碎指令

---

下篇预告：

习惯和路由做完，下一步进入工具层和架构层。

下篇会讲：

• RTK / Caveman / headroom / context-mode：终端输出、模型回复、工具返回值分别怎么压
• Graphify / CodeGraph：代码图谱怎么建，怎么让 Agent 不再盲搜
• 多 Agent 边界：/new、/compact、subagent、worktree 分别解决什么问题

---

参考资料

[1] OpenAI，《提示词缓存 | OpenAI API》
https://developers.openai.ac.cn/api/docs/guides/prompt-caching

[2] Anthropic，《Token-saving updates on the Anthropic API》
https://claude.com/blog/token-saving-updates

[3] OpenAI，《使用 GPT-5.5 | OpenAI API》
https://developers.openai.ac.cn/api/docs/guides/latest-model

[4] Google AI for Developers，《Thinking》
https://ai.google.dev/gemini-api/docs/thinking

[5] Anthropic，《Prompt caching》
https://platform.claude.com/docs/en/build-with-claude/prompt-caching