AI Coding Agent Token 成本优化指南（下）：工具层、代码图谱与多 Agent 协作

如果你把上篇的行动清单做完了，成本通常已经有明显下降。但如果你想继续往下压，就要开始处理系统层的问题：命令输出怎么压、检索怎么少走弯路、多个 Agent 怎么把上下文拆开。

本篇承接上篇的五层模型，继续往下走三层：

层级 主题 作用 特点
第三层 压缩工具 先把高频输入输出压下来 装完即用，立即见效
第四层 代码图谱 让检索不再盲搜 先知道该读哪里，再读文件
第五层 多 Agent 用法 把大任务拆成多个小上下文 边界清晰时更省

第四章 上下文压缩：先把高频上下文压下来

如果说上篇解决的是“少带无关上下文”，这一层解决的就是另一件事：把那些一定会进上下文的内容，尽量压短。

这四个工具方向不同，但可以叠加。你不一定要一次装全，但只要装上一个，通常就能立刻看到收益。

4.1 RTK：终端输出才是真正的 Token 大杀手

很多人把 Token 浪费归因于“聊太多轮”，但忽略了一个隐性大户：终端命令的冗余输出。

CodeBuddy 执行 cargo test，成千上万行测试日志、警告、进度条、ANSI 颜色码全部涌进上下文。

实测：30 分钟开发会话对比（来自 2900+ 真实命令测量）：

场景 Token 消耗
不用 RTK ~150,000
用 RTK ~16,850
节省 88.9%

按命令类别的典型压缩率：

命令类别 原始 tokens RTK 后 节省
cargo test / npm test 25,000 2,500 -90%
pytest 8,000 800 -90%
vitest run 102,199 字符 377 字符 -99.6%
ls / tree 2,000 400 -80%
grep / rg 16,000 3,200 -80%
git status 3,000 600 -80%
git diff 10,000 2,500 -75%
cat / read 40,000 12,000 -70%

说明：这张表混合了 token 和字符两种统计口径。前几行是 token，vitest run 这一行是字符长度，用来说明压缩幅度，不能和 token 行直接横向比较。

RTK 的四层过滤策略

  1. 智能过滤：剔除注释、空行、ANSI 颜色码、进度条、无关警告
  2. 分组聚合：同类输出合并展示（搜索结果按文件分组、错误按类型归类）
  3. 智能截断：按信息密度取样，保留关键片段，砍掉重复长尾
  4. 去重合并：「连接超时」重复 10 次 → 「连接超时（×10）」

5 分钟安装

# macOS（推荐）
brew install rtk

# Linux / WSL
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh

注意：安装后用 rtk gain 验证。如果命令不存在，可能装了同名的 Rust Type Kit，需卸载重装。

# 全局启用 CodeBuddy（推荐）
rtk init -g

# 仅启用 Hook，不修改 CODEBUDDY.md
rtk init -g --hook-only

# 其他 AI 工具
rtk init -g --agent cursor   # Cursor
rtk init -g --gemini         # Gemini CLI
rtk init -g --codex          # Codex

重启 CodeBuddy 后自动生效，所有命令透明经过 RTK 过滤，开发者无感知。

# 常用命令
rtk gain                 # 查看节省统计
rtk gain --history       # 带命令历史
rtk discover             # 扫描哪些命令还没用 RTK

# Git（压缩率 60-80%）
rtk git status
rtk git diff

# 测试（压缩率 90-99.6%）
rtk test cargo test
rtk vitest run

4.2 Caveman：压缩输出端的废话

RTK 压缩的是命令输出（输入 Token），Caveman 压缩的是 AI 回复（输出 Token）。两者方向不同，可以叠加。

核心数据（来自 arXiv:2604.00025）：

任务类型 正常输出 Caveman 节省
解释 React bug 118 tokens 15 tokens 87%
配置 PostgreSQL 234 tokens 38 tokens 84%
Docker 多阶段构建 104 tokens 29 tokens 72%
Code Review PR 67 tokens 39 tokens 41%
平均 — — 65-75%

Caveman 有四种模式，按压缩程度递增：

  • /caveman lite：删填充词，保留冠词，专业风格（适合正式输出）
  • /caveman（full 默认）：删冠词，碎片句，平衡压缩
  • /caveman ultra：极度压缩，用 A→B→C 箭头因果链
  • /caveman wenyan：文言文模式（理论上 token 效率最高的书面语）

实际效果示例（full 模式）：

问：为什么 React 组件不断重渲染？

普通输出（69 tokens）：
"The reason your React component is re-rendering is likely because you're
creating a new object reference on each render cycle..."

Caveman 输出（19 tokens）：
"New object ref each render. Inline object prop = new ref = re-render.
Wrap in useMemo."

安装

# CodeBuddy 插件方式（推荐）
codebuddy plugin marketplace add JuliusBrussee/caveman
codebuddy plugin install caveman@caveman

安装后在 CodeBuddy 里输入 /caveman 即可激活。模式在会话内持续生效，输入 stop caveman 关闭。

4.3 headroom：压“进上下文的所有内容”

RTK 压的是命令输出，Caveman 压的是 AI 回复。headroom 压的是第三个方向：所有读进上下文的内容——文件内容、工具调用返回值、会话历史。

核心机制：可逆压缩（CCR）。原始数据本地保留，压缩版本送给 LLM，LLM 需要细节时再按需取回。不是丢数据，是推迟加载。

实测：47–92% token 减少（取决于内容类型）。

安装

pip install "headroom-ai[all]"

接入 CodeBuddy

# 基础接入
headroom wrap claude

# 推荐：同时开启跨 session 记忆 + 代码图谱集成
headroom wrap claude --memory --code-graph

之后正常用 CodeBuddy，headroom 在后台透明处理压缩，无感知。

也支持 MCP Server 模式

如果不想用 wrap 方式，可以走 MCP：

headroom mcp install

安装后在 CodeBuddy 里自动注册三个工具：headroom_compress、headroom_retrieve、headroom_stats。

与 RTK 的区别

RTK headroom
压缩对象 终端命令的输出 所有进上下文的内容
工作方式 过滤 + 截断 可逆压缩，按需还原
安装方式 brew / curl pip + wrap 命令
典型节省 89% 47–92%

两者方向不同，可以叠加使用。

4.4 context-mode：工具输出不再撑爆上下文

context-mode 解决的是一个具体痛点：MCP 工具调用的返回值太大。

一次 Playwright 快照 56 KB，二十条 GitHub issue 59 KB，一份访问日志 45 KB。用 30 分钟，40% 上下文就没了。然后 /compact 一压缩，CodeBuddy 忘了在改哪些文件、任务进行到哪了。

context-mode 是一个 MCP server 插件，四层能力一起上：

能力一：Sandbox 工具输出（98% 压缩）
工具调用结果先沙箱化，不直接进上下文。315 KB → 5.4 KB。LLM 按需取回原始数据，不是真的删掉。

能力二：跨 compact 会话连续性
所有文件编辑、git 操作、任务进度、错误信息全部记录到本地 SQLite。/compact 之后不丢失现场——context-mode 用 FTS5 全文索引按相关性取回，而不是把所有历史重新塞回去。

能力三：用代码代替读文件
ctx_execute() 工具让 CodeBuddy 写脚本处理数据，而不是读 50 个文件进上下文：

// Before: 47 次 Read() = 700 KB
// After: 1 次 ctx_execute() = 3.6 KB
ctx_execute("javascript", `
  const files = fs.readdirSync('src').filter(f => f.endsWith('.ts'));
  files.forEach(f => {
    const lines = fs.readFileSync('src/' + f, 'utf8').split('\\n').length;
    console.log(f + ': ' + lines + ' lines');
  });
`);

CodeBuddy 生成并运行脚本，只把结果（几行文字）放进上下文，而不是把 47 个文件的内容全部读进来。

能力四：不干预输出格式
context-mode 只管数据往哪走，不管 CodeBuddy 怎么回答。如果你同时装了 Caveman，两者各管各的，不冲突。

安装（CodeBuddy 插件市场直装）

codebuddy plugin marketplace add mksglu/context-mode
codebuddy plugin install context-mode@context-mode

重启 CodeBuddy（或 /reload-plugins）后生效。

验证

/context-mode:ctx-doctor

所有项显示 [x] 即正常。

常用命令

/context-mode:ctx-stats    # 查看节省统计，按工具分类
/context-mode:ctx-insight  # 打开本地分析看板（90 个指标）

四个压缩工具一览

工具互补，不互斥。从左到右压缩复杂度递增：

工具 压缩什么 典型节省 装法
RTK 终端命令输出 → 上下文 89% brew install rtk + rtk init -g
Caveman AI 回复输出 65–75% CodeBuddy 插件市场
headroom 所有进上下文的内容 47–92% pip install headroom-ai[all]
context-mode MCP 工具结果 + 会话连续性 98%（工具输出） CodeBuddy 插件市场

最低成本起点：先装 RTK + Caveman，五分钟，立即见效。有时间再评估 headroom 和 context-mode。

第五章 代码图谱：让 AI 不再盲搜

前一层压的是“已经进来的东西”。这一层解决的是另一类浪费：本来就不该读进来的东西。

5.1 真正贵的是“找代码”，不是“读代码”

上下文窗口够大，不代表不需要图谱。

项目越大，AI 越容易陷入一个循环：

grep 一圈找入口
→ 读几个文件找关系
→ 发现漏了一个
→ 再 grep 一圈
→ 反复几轮才定位到

这个过程消耗大量 Tool Call 和上下文，而且结果还不一定准确。

代码图谱解决的是：让 AI 在动手读文件之前，就知道该读哪里。

5.2 Graphify：把代码库变成可查询的知识地图

Graphify 在 2026 年 4 月发布，10 天内 GitHub stars 超过 22k，如今已经来到 50.8k。

核心机制：用 Tree-sitter 解析代码构建知识图谱，AI 查图而不是反复读文件。

官方数据：比直接读文件减少 71.5 倍 Token 消耗。

安装和使用

# 安装
uv tool install graphifyy
# 或
pipx install graphifyy

# 注册到 CodeBuddy
graphify install --platform codebuddy
# 或
graphify codebuddy install

在 CodeBuddy 里执行 /graphify，自动扫描项目并生成三份产物：

> /graphify

Building knowledge graph...
  Parsed 247 files (TS/Prisma)
  Found 1,832 symbols, 4,217 edges
  Detected 14 communities (clusters)
  Generated:
    - graphify-out/graph.html          ← 交互式可视化
    - graphify-out/GRAPH_REPORT.md     ← 自然语言报告
    - graphify-out/graph.json          ← AI 查询用的数据

后续问跨文件问题时，AI 读 graphify-out/graph.json，而不是反复 grep 源码：

> 我想在 /api/v1/comments 加一个 PATCH 接口。
> 列出会受到影响的所有中间件、Prisma model、和测试文件。

影响分析（基于知识图谱）：

中间件链：
  - middleware/auth.ts → optionalAuth → requireAuth
  - middleware/rate-limit.ts（commenting 路径 30/min 限制）

Prisma model：
  - Comment（直接修改）
  - User（通过 authorId 关联）
  - Mention（通过 commentId 关联，PATCH 后需要重算）

测试：
  - tests/comments.test.ts
  - tests/integration/registration.test.ts（间接依赖）

不用图谱时，同样问题经常要靠多轮 grep 和补读文件来兜底，遗漏关键路径并不少见。用图谱后，定位和影响分析会稳定得多，尤其适合跨文件问题。

支持范围

  • 30+ 种语言：Python、TypeScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin 等
  • 多模态：SQL schema、Markdown 文档、PDF、图片（通过 LLM 提取语义）
  • 增量更新：git hook 触发，每次 commit 自动重建

与 CodeGraph 的区别

CodeGraph 是另一个方向的工具，基于 MCP Server + 持久化图数据库（Neo4j/KuzuDB），对 7 个真实开源仓库做了完整 benchmark（v0.9.4，2026-05-24 复验）：

平均数据：57% 更少 Token、71% 更少 Tool Call、35% 更低成本、46% 更快。

分仓库明细：

代码库 语言 成本 Tokens 工具调用
VS Code TypeScript -26% -78% -85%
Excalidraw TypeScript -52% -90% -96%
Tokio Rust -82% -86% -92%
Django Python -12% -36% -53%
Gin Go -21% -34% -40%
OkHttp Java -2% -13% -45%
Alamofire Swift -47% -64% -83%

注意：收益和项目规模、语言强相关。Rust/TypeScript 大型项目收益最显著，Java/Go 较小项目收益相对有限。

CodeGraph 安装：

# npm 安装
npm i -g @colbymchenry/codegraph

# 初始化项目
cd your-project
codegraph init -i

手动配置 CodeBuddy：

// ~/.codebuddy/.mcp.json
{
  "mcpServers": {
    "codegraph": {
      "type": "stdio",
      "command": "codegraph",
      "args": ["serve", "--mcp"]
    }
  }
}

核心工具：

  • codegraph_context：找入口点和关键符号（第一跳）
  • codegraph_trace：追调用路径（含动态派发）
  • codegraph_impact：重构前影响分析

选哪个：个人项目、快速上手 → Graphify（Skill 形态，零配置）。团队、大型仓库、需要持久化查询 → CodeGraph（MCP 服务器，功能更完整）。

第六章 多 Agent 协作：边界清晰时，CodeBuddy 会更省 Token

前两层解决的是“单个上下文怎么更省”。这一层继续往前走：别让所有任务都挤进同一个上下文。

换句话说，前面讲的是“单个会话怎么省”，这里讲的是：多个 Agent 怎么分工协作，才能在任务边界清晰时更省。

CodeBuddy 本身就支持 subagent 调度、worktree 隔离、Skill 绑模型——不需要自己写 Orchestrator，用好内置能力就够了。

6.1 单 Agent 为什么越用越贵

复杂项目里，单 session 很容易演变成这样：

  • 规划、写代码、跑测试、Code Review 全在一个会话
  • 上下文越积越长（所有历史都往一个 session 里塞）
  • 所有任务用同一个模型配置，便宜活也用最贵模型

职责越混，上下文越胖，成本越高。

6.2 subagent：任务隔离的最低成本方式

CodeBuddy 的 Skill 里可以直接调用 Agent tool，把子任务分发出去：

使用 Agent tool 分析这个 PR 的影响范围，
然后把结果返回给我，不需要读具体实现文件。

每个 subagent 都应该有独立的上下文边界——它只看到自己需要的内容，主 session 只看到结果。前提是子任务真的能拆开；如果每个 Agent 都要重复读同一批背景，拆得越多，反而越贵。

典型分工：

主 session（规划 + 决策）
  ├── subagent A：影响分析（只看图谱，不读源码）
  ├── subagent B：写实现（只看相关文件）
  └── subagent C：跑测试 + 生成报告

与上篇 3.5 的连接：subagent 可以单独绑定便宜模型（见下节）。规划用强模型，执行用便宜模型，两者在不同 session 里，互不干扰。

6.3 /new、/compact、subagent、worktree：四种手段别混用

这四个动作都和“上下文变轻”有关，但解决的问题完全不同：

手段 解决什么 历史怎么处理 代码改动怎么处理 适用场景
/new 切断无关任务 直接开新会话 仍在同一仓库 换话题、换需求
/compact 压长会话历史 保留摘要，不保留完整过程 仍在当前工作区 长任务续做
subagent 拆子任务 只给子任务需要的上下文 默认不做代码隔离 搜索、分析、验证
worktree 隔离并发改动 历史不是重点 独立 git worktree 多任务并行开发

一句话：

/new 解决换任务
/compact 解决历史过长
subagent 解决职责拆分
worktree 解决代码并发

6.4 worktree 并发：多任务同时跑不冲突

有一批互相独立的任务要处理（比如修 5 个不相关的 Bug），可以用 worktree 模式并发：

主分支
  ├── worktree-1：修 Bug A（独立 git worktree）
  ├── worktree-2：修 Bug B（独立 git worktree）
  └── worktree-3：修 Bug C（独立 git worktree）

每个 Agent 在隔离的 worktree 里工作，改的是不同文件，互不冲突。

怎么开：在 CodeBuddy 里启动新任务时，指定 worktree 隔离：

开一个新的 worktree 分支修这个 Bug，
修完后告诉我分支名，我来 review 再合并。

怎么合：worktree 没改动自动清理；有改动返回路径和分支名，自己决定 review 后合并。

适用场景：互相独立的 Bug 修复、并行跑不同重构方案对比效果、同时生成多个文档。

6.5 Skill 绑定模型：系统默认更省

上篇 3.5 说过“Skill 可以绑定模型”，这里给具体配置。

CodeBuddy 的 Skill 支持在 frontmatter 里指定模型，不靠人记得手动切：

---
name: write-unit-tests
description: 为指定函数生成单元测试
model: deepseek-v4-pro
---

为以下函数写完整的单元测试，覆盖正常路径和边界情况：
...

推荐配置原则：

Skill 类型 推荐模型 理由
写 UT、补注释、生成 commit DeepSeek 模式固定，不需要强推理
Code Review、影响分析 中高档模型 需要语义理解
架构设计、复杂 Bug 分析 不绑定（用默认最强） 需要长链路推理

一旦固化到 Skill 配置，成本治理就从“靠人记得切”变成“系统默认更省”。

6.6 记忆外置：别让 session 承载全部历史

用“永不清空的超长会话”模拟记忆，是最贵也最脆弱的做法。

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

CODEBUDDY.md 系统：项目约定、关键决策、架构边界。保持 < 50 行，是索引不是文档。详细内容放 docs/，让 CodeBuddy 按需读取。

Graphify graph.json：代码结构的外置记忆。建一次，跨 session 共享，新 session 不需要重新扫描整个仓库。

headroom --memory：如果你装了 headroom，--memory 模式会把重要信息持久化到本地，跨 session 恢复。

好处不只是省 Token：

  • 可更新（旧信息能被替换）
  • 可检索（按需读入，不是全量注入）
  • 不依赖 session 存活

原则：会话只承载“当前工作状态”，背景信息按需读入。

到这里，下篇真正想建立的心智模型其实也可以浓缩成一句话：不要只想着把单次回答压短，更要想办法让系统少把同一批背景反复搬进来。

第七章 误区：很多“优化”其实在加成本

误区一：上下文越多越好。
上下文越多不一定越准，但通常越贵。噪音越多，模型越容易分神。该读哪个文件，比读多少文件更重要。

误区二：MCP 越多越强。
工具堆得越多，选择空间越大、决策越慢、错误调用概率越高。低频工具长期挂载，贡献的更多是成本。

误区三：所有 Agent 都上最强模型。
这不叫优化质量，叫放弃路由。每个环节默认最贵模型，系统里就没有“资源分配”，只有“直接烧钱”。

误区四：聊天记录当长期记忆。
长会话方便，但不是记忆系统。长期依赖会话承载全部背景，最终成本越来越高，关键信息越来越难提取。

误区五：只看单价不看总成本。
便宜模型如果导致更多重试、更多搜索、更多上下文回填，总成本未必更低。真正该看的是完成一次任务的总成本。

误区六：Prompt 越短越好。
压缩时丢掉了必要的 few-shot 或格式说明，导致第一次输出不合格，反复重试。压缩要精准，不是一味缩短。

第八章 结语

两篇文章的核心只有一句话：

AI Agent 成本优化
本质不是让你少问一句话
而是让系统少重复做无效工作

压成公式：

更低成本
=
更少重复上下文（RTK、Caveman、headroom、context-mode、会话管理）
+ 更合理模型路由（任务匹配、Skill 绑模型）
+ 更精准代码检索（Graphify、CodeGraph）
+ 更清晰 Agent 分工（subagent 隔离、worktree 并发、记忆外置）

参考资料

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

[2] Claude Code Prompt Cache 实战指南
https://cloud.tencent.com/developer/article/2662618

[3] RTK（Rust Token Killer）GitHub
https://github.com/rtk-ai/rtk

[4] RTK 实战指南
https://juejin.cn/post/7628503584259211316

[5] Caveman GitHub
https://github.com/JuliusBrussee/caveman

[6] Caveman 论文：Brevity Constraints Reverse Performance Hierarchies
https://arxiv.org/abs/2604.00025

[7] Graphify GitHub
https://github.com/safishamsi/graphify

[8] CodeGraph GitHub
https://github.com/colbymchenry/codegraph

[9] LLM 推理成本工程：五层防御体系
https://jishuzhan.net/article/2062415217950273537

[10] Google AI，《Context caching - Gemini API》
https://ai.google.dev/gemini-api/docs/caching

[11] headroom GitHub
https://github.com/chopratejas/headroom

[12] context-mode GitHub
https://github.com/mksglu/context-mode

posted @ 2026-06-08 17:41  深蓝  阅读(26)  评论(0)    收藏  举报

我要啦免费统计