AI Coding Agent 的 Token 成本优化：从小模型路由到上下文复用

当 AI coding agent 从研究工具变成日常开发环境，Token 消耗就开始变成一个必须正视的工程问题。本文从消耗建模出发，给出可操作的成本优化策略，适合已经在日常工作中使用 AI 编程工具、但还没有系统管理 token 消耗的团队。

目录

• 一、为什么现在要关注 Token 成本
• 二、Token 消耗的真实分布
• 三、小模型路由：不同任务用不同脑子
• 四、上下文复用：从「每次重读」到「一次记住」
• 五、工具输出的成本意识设计
• 六、建立团队的 Token 预算感知
• 七、实战：一个月降低 40% token 消耗的操作清单

一、为什么现在要关注 Token 成本

AI coding agent 刚出现时，”按 token 计费”几乎不是问题——月费订阅制让大多数人没有感知。但到了 2026 年，情况已经变了：

成本开始分层：

• Claude Code Pro 的 token 上限虽高，但超量后按量计费
• 企业部署中，API 调用成本直接进入基础设施账单
• 多 Agent 并行执行时，成本是线性增长的
• 长任务（codebase 重构、大型 code review）消耗巨大，一不小心就跑出几十美元的账单

更重要的是：大部分团队的 token 消耗是”漏的”，而不是”必要的”。

一次典型的效率损失场景：

工程师 A：让 Agent 修复一个 bug
Agent 行为：
1. 全量读取项目文件（200K tokens）← 大量与 bug 无关的文件
2. 读取 git history（80K tokens）  ← 绝大部分与 bug 无关
3. 工具输出（60K tokens）          ← 每次工具调用都有输出回传
4. 推理过程（30K tokens）           ← 对话历史累积
5. 最终答案（3K tokens）           ← 真正有价值的只有这 3K

373K tokens 的总消耗里，真正服务于解决 bug 的可能只有 30K。这个比例在很多团队的真实使用场景里是常态，而不是极端情况。

所以这篇文章的核心问题不是”要不要用 AI coding agent”，而是：

如何在不降低任务质量的前提下，把 token 消耗从 370K 降到 80K？

二、Token 消耗的真实分布

要优化，先测量。我在多个团队的 Claude Code 使用数据里看到了相对一致的分布模式：

关键发现：

1. 工具输出是最主要的消耗来源——不是系统提示，不是你写的 prompt，是每次调用工具后传回给模型的输出。这些输出包含文件内容、Bash 命令结果、工具响应等，通常比实际需要的长得多。

2. 上下文读取是最容易被滥用的——”帮我理解这个项目”这类请求很容易触发全量读取。模型没有精确的”哪些文件相关”的直觉，需要人主动引导。

3. 对话历史的消耗是累积的——每轮对话的 token 都会进入下一轮，越长的 session，累积效应越明显。很多团队意识不到一个用了两小时的 session 已经有几十万 token 了。

理解了这个分布，我们就知道该在哪里用力了。

三、小模型路由：不同任务用不同脑子

3.1 什么时候应该用小模型

不是所有任务都需要 Sonnet 3.7 的能力。以下场景用小模型（Haiku、o3-mini、GPT-4o-mini）不仅足够，而且更划算：

3.2 Claude Code 中的模型切换策略

Claude Code 支持在会话中动态切换模型。在 .clauderc 中可以配置任务级别的模型偏好：

{
  "completion": {
    "model": "claude-opus-4-5",
    "thinkingBudget": 16000
  },
  "preferences": {
    "modelSelect": "allowUser"
  }
}

但更实用的做法是在会话内用指令切换：

// 当前会话切到快速模式（适合简单任务）
/gpt --model o3-mini --reasoning-level concise

// 切到深度推理模式（适合复杂问题）
/claude --model opus-4 --thinking on

3.3 多模型协作架构

高级用法是多模型 pipeline：

简单任务入口（Haiku）
    ↓ 判断任务复杂度
    ├── 简单 → Haiku 直接处理 → 完成
    └── 复杂 → 升级到 Sonnet
                  ├── 生成方案
                  ├── 低风险 → 自动执行
                  └── 高风险 → 暂停 + human review

这种架构下，简单任务用小模型（成本 $0.001/次），只有真正复杂的才调用大模型（成本 $0.015/次），可以将总体成本降低 60-80%。

四、上下文复用：从「每次重读」到「一次记住」

4.1 上下文窗口的复用困境

Claude Code 的每次会话开始时，如果你是”新建一个 session”，模型通常需要重新理解代码库。这在每个新任务开始时是必要的——但问题是，很多团队的实际情况是：

• 同一个代码库，连续多天都在开发
• 同一个模块，连续多个任务都在改
• 同一个技术栈，模型每次都被迫重新学一遍

这里的关键问题是：上下文没有持久化，每次 session 都从零开始。

4.2 Repo Memory 的正确用法

Claude Code 支持 repo memory 功能，核心是一个 .claude/projects/<project>/context.json 文件，记录项目的结构化记忆：

{
  "projectName": "my-api-service",
  "primaryLanguage": "TypeScript",
  "framework": "Express",
  "keyFiles": {
    "auth": "src/middleware/auth.ts",
    "database": "src/db/connection.ts",
    "routes": "src/routes/"
  },
  "architecture": "Layered architecture with routes/services/repositories",
  "recentChanges": [
    "2026-03 migrated from REST to GraphQL",
    "2026-02 added rate limiting middleware"
  ]
}

正确的用法是：每次完成一个较大的任务后，更新这个文件，记录项目的最新状态。这样下次新 session 开始时，模型读取这个文件就能快速恢复上下文，而不需要重新扫描整个代码库。

4.3 增量 context：只读变化的部分

对于还在进行中的任务，另一个策略是基于 git diff 的增量 context：

// 在新 session 开始时，先生成增量变化
git diff --stat HEAD~10

// 将增量文件作为 context 重点喂给模型
/claude --context-from-diff

这样模型只需要关注最近哪些文件变了，而不是每次都读取全部历史。

4.4 外部知识库的拉取

对于大型项目，可以将项目文档、设计决策记录放在外部（Notion、Confluence），然后在需要时通过 MCP 工具拉取。这样模型能访问到文字记录，但不会把整个知识库塞进 context。

五、工具输出的成本意识设计

5.1 工具输出为什么贵

每次调用 Bash、Read、Write 工具后，工具的输出会完整回传给模型用于下一步推理。这个设计在大多数情况下是合理的，但它的成本容易被忽视：

Read 一个 5000 行的文件 → 返回 5000 tokens
↓
这些 tokens 全部进入 context
↓
下一轮推理时全部重新处理

5.2 截断策略（Output Truncation）

Claude Code 支持对工具输出进行截断，避免大文件占满 context：

在 .claude/settings.json 中：

{
  "tools": {
    "limits": {
      "Read": { "maxLines": 500 },
      "Grep": { "maxResults": 50 },
      "Bash": { "maxOutput": 2000 }
    }
  }
}

这样即使模型读取大文件，也只有前 500 行被传入 context，足以让模型理解文件结构，但不会消耗过多 token。

5.3 专用工具 vs Bash 的选择

很多操作可以用专用工具完成，也可以用 Bash 完成，但消耗差异巨大：

原则：能用专用工具就用专用工具——专用工具的输出是结构化的，通常比 Bash 的原始输出短得多。

5.4 并行 vs 串行的权衡

工具并行执行（多个工具同时调用）通常更快，但有一个隐藏成本：多个并行工具的输出会同时涌入 context，如果输出量大，context 会被迅速占满。

策略：

• 简单、独立的工具 → 并行调用（节省时间）
• 可能产生大量输出的工具 → 串行调用，并设置截断
• 复杂任务的早期阶段 → 串行调用，充分理解每步输出后再并行

六、建立团队的 Token 预算感知

6.1 个人层面的实践

每日起身检查：每天工作结束时看一眼当天的 token 消耗。Claude Code Pro 用户可以在设置里开启用量通知：

{
  "notifications": {
    "tokenUsageWarning": true,
    "dailyBudgetThreshold": 100000
  }
}

单任务上限：在开始一个任务前，花 30 秒估计任务复杂度。超过自己预估的大任务，及时拆分或切换策略。

6.2 团队层面的实践

对于团队来说，关键是建立共享的感知和基准线：

1. 建立 token 消耗日志：每次重要任务完成后记录消耗量。积累一个月后，团队会对”简单任务 vs. 复杂任务”的消耗区间有直觉。

2. 设定团队基准线：

   简单任务（small bug fix）：20-50K tokens
   中等任务（单文件实现）：50-150K tokens
   复杂任务（跨文件重构）：150-400K tokens
   极复杂任务（架构调整）：400K+ tokens（需要 human review）
   

3. 月度回顾：每月抽 5 个代表性任务，分析 token 消耗分布，找出浪费最大的环节，针对性优化。

6.3 不建议的做法

• 为了省 token 限制模型能力：如果省了 50 块钱的 token，但导致工程师多花了两小时，这就是错误的节约。
• 设置过低的单任务上限：模型在复杂推理时需要足够的 context 空间，强行截断会降低任务质量。
• 让模型在不清楚上下文的情况下工作：省了读取代码的时间，但模型给出的方案质量差，最终需要返工——这是最贵的优化。

七、实战：一个月降低 40% token 消耗的操作清单

以下是我在一个 8 人后端团队实际验证过的操作，按实施难度排序：

第一周：零成本立即生效（预计节省 15-20%）

• 开启工具输出截断：Read 工具 maxLines=500，Bash maxOutput=2000
• 建立 repo memory：为每个项目创建 context.json，记录关键文件和架构
• 清理无用的系统提示词：检查 .clauderc 中的 system prompt，删除冗余的说明文字

第二周：轻度调整（预计额外节省 10-15%）

• 强制使用专用工具：在团队规范中明确 Grep/Glob > Bash 的使用场景
• 任务拆分规范：超过 200K tokens 预估的任务必须拆分
• 每日用量通知：开启 token 警告通知，培养个人感知

第三周：架构优化（预计额外节省 10-15%）

• 模型路由规则：明确哪些任务类型必须用 Sonnet，哪些可以用 Haiku/o3-mini
• Git diff 增量 context：大型项目的任务开始前先用 diff 聚焦变化范围
• 建立团队 token 日志：用 Notion 或简单表格记录每个 sprint 的 token 消耗

第四周：持续优化（预计额外节省 5-10%）

• 月度分析会议：Review 高消耗任务的共同特征
• 知识库外置：将项目设计文档从 context 移到外部知识库，用时拉取
• 自动化工具：用 MCP 协议接入团队知识库，模型在需要时主动查询

总结

Token 成本优化不是一个”找最便宜的模型”的问题，而是一个系统性工程——涉及工具使用习惯、任务拆分方式、上下文管理策略，以及团队对消耗的感知。

核心原则只有三条：

1. 只给模型它真正需要的 context，而不是全部
2. 用正确的模型做正确的事，简单任务不要浪费大模型
3. 让 token 消耗可见，不可见就没有优化空间

这三条做好了，40% 的节省是保守估计。更重要的是，这个过程不会牺牲任务质量——因为高质量的 context 管理，本身就是提高 Agent 输出质量的最好方式。

*本文是「AI Coding Agent 工程化」系列的第三篇。前两篇分别是《Context 管理策略》和《AI Coding Agent 评估体系》。