Claude Code 省 token 的四板斧，治不了你那份 13 MB 的接口文档
AI CODING DEEP DIVE。 这是一篇工程实测复盘，不是工具安利——讲我按一个百万阅读的「省 90% token」视频把四个工具全上了一遍，然后打开 Claude Code 自己的归因面板，发现账单根本不在我以为的地方。所有数字来自我自己的机器，没有一个是转述的。English version: The Token-Saving Playbook Has a Blind Spot: Your 13 MB API Spec.
一条 SSE 链路，19 个文件，8,716 行
我手上有个企业级客服 Agent 平台。Python 后端 + React 工作台，610 个 .py、101 个 .tsx，git 跟踪的源码 12.3 万行。
上个月我让 Claude Code 追一个问题：流式回复偶尔在中途断掉，前端转圈不收。 这是一条 SSE 链路——从后端 handler 吐 text/event-stream，穿过网关、穿过重试逻辑，到前端的 EventSource 消费、渲染、异常兜底。
我量了一下这条链路真正涉及多少代码：
grep -rlE "EventSource|text/event-stream|StreamingResponse|\bSSE\b" \
--include="*.py" --include="*.ts" --include="*.tsx" . \
| grep -vE "node_modules|tests?/" | xargs wc -l | tail -1
# 8716 total （19 个文件）
19 个文件，8,716 行。 要判断「到底是哪一段把流掐断了」，这 19 个文件基本都得进上下文——你不能只读 handler，因为断点可能在网关的超时、在前端的 onerror 没重连、在中间某个 buffer。
一条链路，就能吃掉 context window 的一小半。
那次追完，MAX 订阅的 5 小时窗口，我两个多小时就撞到上限。
7 月初我刷到 @kirillk_web3 转的一条推，110 万阅读：
Cut Your Claude Code Token Usage by 90% He leaked the exact methods. Most people will scroll past it.
推里挂着一个 18 分 30 秒的视频。作者是 John Kim（做 Claude Code / AI coding 内容，最近和 ByteByteGo 开了付费课）。我把视频转录了一遍——**他讲得比这个标题党的推诚实得多：**四个策略，每一个都跟着讲了 trade-off，不是「一键起飞」那种营销。
我照做了。工具装上，索引建好。撞限确实变松了。
然后我把自己账单里的大户逐个量了一遍，发现了两件事：一，四板斧只覆盖其中两个；二，省下来的额度，被我自己重新花掉了。
四板斧：他讲的是什么
先把视频摆清楚，不然后面的复盘没有参照系。
① 代码库 index。 用 codegraph 把 repo 预先索引成可查询的图谱。Claude Code 默认是 grep → read → scan，为了找一个 auth.ts 会把路上不相关的文件全读进上下文；索引之后变成「查图谱，返回一个节点，而不是整个 repo」。
他讲的 trade-off 有三条，第一条最关键：索引让你多了一个 source of truth。 代码是一个，图谱是另一个，忘了同步，Claude 就会「自信地错」。第二条：走 query 路径会绕过模块级的 CLAUDE.md。第三条他一句带过，但对我来说是致命的——找到文件之后你还是得读文件。省的是检索的 token，不是阅读的 token。
② 压缩工具输出。 rtk（Rust 写的 CLI proxy）。npm run、git log、测试输出这类噪音日志，在进入上下文之前先压掉。他 slide 上的例子是 8,400 tokens 压到 1,010，也就是 −88% 的压缩比。trade-off 是有损。
③ 让模型少说话。 caveman，一个 skill，light / full / ultra 三档，让 Claude 像原始人一样说话，同样的信息量砍掉一半输出。trade-off 讲得很到位：**上一轮的输出会作为下一轮的 context 回灌，**你把输出压烂了，等于把自己的 context history 压烂了，agentic loop 会变笨。
④ 老老实实管 session。 /context 看谁在吃 token、/clear、/model 换模型、先 plan mode 再动手。他点名了一个例子：一个 50k 的 CLAUDE.md，每次开 session 白烧 4%。
四条都对。问题不在这四条对不对。
我的五个 token 大户，四板斧只覆盖两个
先把账单摊开。 我把这个客服 Agent 平台上真正吃 token 的东西逐个量了一遍——不是猜，是 wc 和 du 量的：
| 我的 token 大户 | 实测体量 | 什么形态 |
|---|---|---|
| 追一条 SSE 全链路 | 19 个文件 · 8,716 行 | 代码，跨后端+前端 |
| 读一份企业接口文档 PDF | 13.0 MB 单份 | 外部文档灌入 |
| 知识治理 / 标注语料处理 | 5.3 MB · 24 份文档 | 外部文档灌入 |
| 翻单日业务日志 | 52.4 MB / 天 | 命令输出 |
臃肿的 CLAUDE.md | 49,480 字符 | 常驻上下文 |
现在把四板斧套上去：
| 大户 | codegraph 索引 | rtk 压输出 | caveman 压模型话 | session 管理 |
|---|---|---|---|---|
| SSE 全链路（8,716 行） | ⚠️ 只帮定位，链路还是得整条读 | ❌ | ❌ | ⚠️ 只能靠 /clear 断尾 |
| 接口文档 PDF（13 MB） | ❌ | ❌ | ❌ | ❌ |
| 知识库语料（5.3 MB） | ❌ | ❌ | ❌ | ❌ |
| 业务日志（52 MB/天） | ❌ | ✅ 它的主场 | ❌ | ❌ |
| CLAUDE.md（49,480 字符） | ❌ | ❌ | ❌ | ✅ |
五个大户，四板斧真正治得了两个。
看清楚这个矩阵在说什么：四板斧瞄准的是「代码检索 / 命令输出 / 模型输出 / 会话管理」这四个面。而我账单里最肥的两块——13 MB 的接口文档 PDF 和 5.3 MB 的知识库语料——是纯粹的「外部文档灌入」，它根本不在这四个面里。
那份 13 MB 的 PDF 是一份接口文档——企业里的文档就是这个体量，几百页，正文之外全是入参出参表、状态码表、错误码附录。Agent 要对接业务系统，就得知道每个接口怎么调、状态机怎么流转。
这份文档没有 grep 的余地。 你不能「查图谱找到它」，因为它本来就是一整份要读的东西。codegraph 索引不了它（不是代码），rtk 压不了它（不是命令输出），caveman 更管不着（不是模型输出）。它就是纯 input，硬灌。
企业落地的人对这个体量不会陌生：接口手册、业务规则汇编、标注规范、知识库语料——每一份都是几 MB 起步，而且都是「必须读懂」而不是「搜一下就行」的东西。
知识治理那 24 份语料同理——而知识库本身该怎么治理，是另一个更大的话题。
这不是 John Kim 讲漏了。是他的负载里没有这一类东西。 他做的是 coding 内容——写 web 应用、跑测试、看 build log。而任何一个真正在企业里落地 Agent 的人，token 账单里都会有一大块是「读别人给的文档」：接口手册、业务规则、标注规范、知识库语料。
这就是为什么我 82% 的用量卡在超过 150k 的 context 上。不是因为 grep 读多了文件，是因为我在往里灌 PDF。
（Agent 上线之后要喂多少语料、标多少数据，我在另一篇里算过账——那笔账和这笔是同一个池子。）
打开归因面板：省下来的，被我自己重新花掉了
Claude Code 现在会告诉你，额度是被什么样的使用形态吃掉的。原始面板长这样——这是我更早的那次快照：
95% of your usage was at >150k context
Longer sessions are more expensive even when cached.
/compact mid-task, /clear when switching to new tasks.
64% of your usage came from sessions active for 8+ hours
These are often background/loop sessions.
39% of your usage was while 4+ sessions ran in parallel
All sessions share one limit.
27% of your usage came from subagent-heavy sessions
Each subagent runs its own requests.
然后是最近 24 小时的：
82% of your usage was at >150k context
73% of your usage came from subagent-heavy sessions ← 27% → 73%
39% of your usage was while 4+ sessions ran in parallel
23% of your usage came from sessions active for 8+ hours ← 64% → 23%
Skills % of usage
/superpowers:subagent-driven-dev… 13%
/hotfix 6%
/superpowers:writing-plans 3%
Subagents % of usage
superpowers:subagent-driven-dev… 11%
general-purpose 8%
Plugins % of usage
superpowers 33%
并排放：
| 归因维度 | 更早那次 | 最近 24h | 变化 |
|---|---|---|---|
| 用量发生在 超过 150k 的 context 时 | 95% | 82% | ↓ 13 |
| 来自 8 小时以上的会话 | 64% | 23% | ↓ 41 |
| 4 个以上会话并行时产生 | 39% | 39% | 持平 |
| 来自 subagent 密集的会话 | 27% | 73% | ↑ 46 |
马拉松会话我确实治好了（64% → 23%）。/clear、/compact、索引，都在起作用。
但省出来的额度立刻被 subagent 扇出吃光了（27% → 73%）。同一份面板的技能榜印证了这件事：superpowers 一个插件占 33% 的用量，subagent-driven-development 一个技能占 13%，general-purpose subagent 占 8%。
而 39% 的并行会话纹丝不动——四个窗口同时开着写四篇文章、改四个 repo，共享同一个额度池。
先声明口径，这很重要：面板自己写了 "independent characteristics, not a breakdown"——这四个百分比不相加，不能当饼图看。它只统计本机的 local session。两次快照是不同时间窗，是观察，不是对照实验。所以我不会说「某个工具导致了 X 下降」，只会说：我的使用形态变了，而变化的方向不是我以为的那个。
省电灯泡换了一屋子，空调还开着四台。
第一刀：我的 CLAUDE.md 有 49,480 字符
视频里那个「50k 的 CLAUDE.md 每次开局白烧」的例子，字面意义上就是我。
wc -m ~/.claude/CLAUDE.md ~/.claude/rules/*.md ./CLAUDE.md
# 9994 ~/.claude/CLAUDE.md
# 6128 ~/.claude/rules/doc-verification.md
# 49480 ./CLAUDE.md ← 这个 blog repo 的
我在一个开局就吃掉 5 万字符的仓库里，写一篇关于省 token 的文章。
问题不在于内容错——那 49,480 字符里没有一句废话，全是踩过的坑：distDir 会静默炸掉 Vercel、dev server 开着别跑 build、双语配图的高度要分语言、公众号的孤儿冒号……问题在于加载时机。
写作风格规范（10 条 voice 规则 + hands-on 硬闸 + 去 AI 味 scrub）、系列生产流程（双语 frontmatter、公众号导出、CTA 关键词表）、手绘视觉规范（色板、字体、布局尺寸）——这三块加起来占了整个文件的三分之二，**而它们只在「写文章」和「做图」时才用得上。**改一行 lib/db.ts 的时候，它们一个字都用不到，却全量灌进上下文。
修法不是删，是按加载时机重新分配：
CLAUDE.md → 每个 session 常驻（架构 + 那些沉默且昂贵的坑）
.claude/skills/ → 任务匹配时才加载（写作 / 翻译 / SEO 三条流水线）
notes/ → 只在需要溯源时读（why、how discovered、repro）
我把写作风格、生产流程、视觉规范整体搬进一个 write-post skill，CLAUDE.md 里只留一行硬指针：「起草原创文章 → 必须先 invoke write-post」。规则一条没丢——我写了个脚本逐条核对 distDir / ensurePostInDB / 避头 / Songti SC 全部还在，18 篇 notes 的引用也全在。
结果：
| memory files | 之前 | 之后 |
|---|---|---|
| 4 个文件合计 | 67,987 字符 | 30,311 字符 |
| 折算 token（实测 2.23 字符/token） | ≈ 30.5k | 13.6k |
每个 session 开局白省 17k tokens。零成本，无损，没有需要同步的第二份真相。
这是全清单里投入产出比最高的一条，而它连一个工具都不用装。如果你只做一件事，做这件。
顺手扒出另外两个隐形大户
瘦身之后跑 /context，开局 46.8k tokens。拆开看：
System prompt: 5.5k
System tools: 8.8k
Custom agents: 6.0k · 20 agents ← 我自己只写了 4 个
Memory files: 13.6k · 4 files ← 刚瘦完的
Skills: 9.8k · 193 skills ← 193 个
Messages: 3.1k
MCP tools: 0 tokens · 33 tools (loaded on-demand) ← 注意这行
193 个 skill、20 个 agent，加起来 15.8k tokens，占开局的 34%。 我自己写了 4 个 agent，剩下 16 个是插件塞的。数了一下：huggingface-skills 一家 92 个 skill、plugin-dev 77 个 skill + 33 个 agent、pr-review-toolkit 66 个 agent、vercel 44 个 skill。我一个都没用过。 每个 skill 的 name + description 都常驻上下文，只为了让模型「知道它存在」。
而 MCP tools · 33 tools · 0 tokens (loaded on-demand) 那一行是对的架构——MCP 工具按需加载，用到才拉 schema，不用不占开局。 Skills 和 agents 反而是全量常驻。
检测信号：/context 里 skills + agents 超过 10k tokens，去看看那些插件你是不是真在用。
第二刀：rtk 装了，但一行 token 都没省
这一条是全篇我最想让你记住的。
rtk 我早就装了。which rtk 有输出，rtk --version 报 0.43.0。我一直以为它在替我省 token——尤其是面对那 52 MB 的单日业务日志，我觉得「有 rtk 顶着呢」。
直到我去查它到底有没有接进来：
grep -rn "rtk" ~/.claude/settings.json ~/.claude/CLAUDE.md # 空
grep -rn "rtk" ~/.zshrc ~/.zshenv ~/.zprofile # 空
全空。
rtk 是显式调用型的 CLI proxy——你得写 rtk git log、rtk test、rtk read 它才生效，它不劫持任何命令。而我的机器上，**没有任何地方告诉 Claude Code「该用 rtk」。**所以它从来没被调用过一次。
我把一个二进制下载到了硬盘上，然后以为自己省了 token。
这不是我笨。这是一整类失败：装了 ≠ 接了。 工具的安装是可见的（which 有输出，版本号打得出来），工具的接线是不可见的——没有任何东西会报错，没有任何指标会掉，你只是在一个「我已经优化过了」的幻觉里继续烧钱。
30 秒的自查，你现在就能跑：
# 这个工具到底有没有被接进来？空 = 它是个装饰品
grep -rn "rtk" ~/.claude/settings.json ~/.claude/CLAUDE.md ~/.zshrc 2>/dev/null
真正的接法不是往 CLAUDE.md 里写一条「记得用 rtk」的规则——那是概率性的，模型会忘，而且规则本身还占常驻上下文（省 token 的规则不该费 token）。rtk 自己就喊出来了：
[rtk] /!\ No hook installed — run `rtk init -g` for automatic token savings
跑完 rtk init -g，它装的是一个确定性的 hook：
事件: PreToolUse
matcher: Bash
command: rtk hook claude
每一条 Bash 命令在执行之前被拦截、重写成 rtk 版本。 不靠模型记性。常驻成本是一个 958 字符的 RTK.md（≈430 token），可以忽略。
真实压缩比是 32.2%，不是 88%
接上 hook 之后，rtk 自带的统计：
$ rtk gain
Total commands: 5
Tokens saved: 1.1K (32.2%)
单条命令的实测：
git log -20 | wc -c # 7,955 字符
rtk git log -20 | wc -c # 3,825 字符 ↓ 52%
视频里是 −88%（8,400 → 1,010）。rtk 官方 README 写的是 60–90%。我机器上的真实聚合是 32.2%。
这不是谁在撒谎。−88% 是拿一个精心挑选的 noisy build 输出算的——那种输出确实全是垃圾，压掉九成不心疼。而我的日常命令里有大量 git log、git diff、ls 这种本来就不太冗余的东西，压不出那么多水。
样本只有 5 条命令，跑几天会更准。但方向不会变：你能省的百分比，取决于你的命令里有多少是噪音，不取决于工具标榜了多少。
**这是本周你能带到会上的第一个问题：**任何人跟你说「我们的方案省了 X%」，问他 分母是什么、样本怎么选的、你的负载跟他的像不像。
一个必须写进 checklist 的失效模式
hook 在 PreToolUse 拦截，意思是：它会静默压缩你以为是原始输出的东西。
追那条 SSE 断流的时候，我要的就是原始日志——哪一秒的 heartbeat 没发出去、哪个 connection 提前 close 了。rtk 完全可能把那一行折叠成「(842 more lines omitted)」，而我不知道。 那会变成一个「日志里明明没有这行」的幽灵 bug，能烧掉一下午。
逃生舱：
rtk proxy <cmd> # 绕过压缩，拿原始输出
讽刺的是，这正是我在生产环境上花过 9 天的同一个失效类——你以为你在看源，其实你在看派生物。 那次是知识库的源文件和搜索索引静默失同步了 9 天，业务方在前台看到的是 9 天前的话术，而所有看板都是绿的。
同一个洞，这是第三次遇见：第一次在知识库的索引里，第二次在下面要讲的代码图谱里，第三次在我自己的终端输出里。
第三刀：codegraph 的 stale 窗口，精确到 300 秒
视频里说索引「会 stale，记得 sync」。这个说法太粗了。我去翻了 daemon 的日志：
[CodeGraph MCP] Auto-synced 18 file(s) in 261ms
[CodeGraph MCP] Auto-synced 1 file(s) in 131ms
[CodeGraph MCP] File watcher active — graph will auto-sync on changes
[CodeGraph daemon] Shutting down (idle timeout; clients=0).
[CodeGraph daemon] Listening on ... (pid 47135, v1.3.0). Idle timeout 300000ms.
读出三件事：
- daemon 醒着的时候有 file watcher，改动自动同步（131ms 一个文件）。视频里担心的「忘了 sync」，这一版已经治了。
Idle timeout 300000ms—— 空闲 5 分钟，daemon 自己关掉。 关掉期间你改的代码，没有任何人在监听。- 但它醒来会补扫（那个
Auto-synced 18 file(s)就是补扫的形状）。
准确的描述是：stale 不是永久失同步，是「有延迟的最终一致」，延迟窗口 = daemon 睡着的时间 + 下次唤醒补扫的时间。
这个区别很要紧。「会 stale」听起来像一个你要时刻警惕的雷；「300 秒空闲后进入延迟一致」是一个你可以推理的系统属性——它告诉你：刚改完代码立刻问 Claude「这个函数在哪」，答案可能来自 5 分钟前的世界；而你连续编码时它是准的。
检测信号：
tail -20 <repo>/.codegraph/daemon.log
# 看 "Auto-synced" 和 "Shutting down (idle timeout)" 的交替节奏
# 只有 Shutting down 没有 Auto-synced —— watcher 没工作，那才是真的雷
还有一件我没预料到的：我全机器只索引了一个 repo。 那个 12.3 万行的客服 Agent 建了 .codegraph，而这个 blog 仓库——我 82% 的长上下文会话实际发生的地方——什么都没有。
工具装在了最像「需要索引」的那个仓库，而不是最烧钱的那个。这两件事不是一回事，而我从来没检查过。
caveman 我故意没装
四板斧我只上了三个。
caveman 省的是 output token。但按它自己 README 的说法，这个 skill 每轮还要倒贴 1–1.5k input token（skill 本身要进上下文）。
对我这种 82% 用量发生在超过 150k context 的会话形态，这笔账算不过来：我的瓶颈根本不在模型话多，而在我往里灌了一份 13 MB 的 PDF。 为了省输出的一半、每轮多付 1.5k 输入——净收益存疑，代价是 context history 变糙、agentic loop 变笨。
视频作者自己常年开 ultra 档。那说明他的负载跟我不一样——这恰恰是「别照抄别人配置」最好的例证。
不装是个决定，不是遗漏。
真凶：73% 的额度，被一队没写 model: 的 subagent 吃掉
回到那个 27% → 73%。
我自己写的 4 个 agent 都老老实实声明了模型：
$ grep -H "^model:" ~/.claude/agents/*.md
codegen-boilerplate.md:model: sonnet
coordinator.md:model: sonnet
debugger.md:model: sonnet
ui-helper.md:model: sonnet
然后我去翻那个占了 13% 用量的技能：
$ find ~/.claude/plugins -path "*subagent-driven-development*" -name "*.md"
.../subagent-driven-development/SKILL.md
.../subagent-driven-development/implementer-prompt.md
.../subagent-driven-development/task-reviewer-prompt.md
.../dispatching-parallel-agents/SKILL.md
这几个文件里，没有一个声明了 model:。
没声明 = 继承主模型。而我的主模型是 Opus。
我的 4 个自定义 agent 规规矩矩跑 Sonnet，而这个技能一次拉起来的一队 implementer + reviewer，全跑在 Opus 上。
27% → 73% 的答案就在这里，不用猜了。
而视频 18 分 30 秒，subagent 和并行会话，一个字都没提。
不是他写漏了。是因为这四板斧治的根本不是这个层级的问题。
零售端和批发端
四板斧治的是「单次读取」的单价；真正吃掉额度的是「灌进去多少 × 并发几个 × 活了多久 × 扇出多宽」。
这是整篇的论点，也是我花了一整晚才看清的东西：
- 零售端（视频教的）：一次 grep 读多少文件、一条日志多少 token、一轮输出多少字。工具能治，收益是百分比——省 30%、省 50%。
- 批发端（账单实际在的地方）：你往里灌了一份 13 MB 的 PDF、一条 8,716 行的链路；你同时开了四个 session；你拉起一队 Opus subagent。工具治不了，因为这些是你的工作内容和工作方式，不是你的命令输出。
一个 Opus subagent 队列跑十分钟，能烧掉你用 rtk 省一整天的量。
而且省下来的会被自动重新花掉——这是最反直觉的部分。我把马拉松会话砍掉了（64% → 23%），额度松了，于是我更放心地去拉 subagent 队列（27% → 73%）。没有人在中间设闸。省出来的空间，会被下一个昂贵的习惯填满。
这就是为什么归因面板比任何一个省 token 工具都值钱：它是唯一一个告诉你「省下来的钱去哪了」的东西。
盲区怎么治：大文档不能灌，只能架
四板斧对那 13 MB 的 PDF 和 5.3 MB 的语料完全失效。但「工具治不了」不等于「没救」——只是解药不在工具层，在架构层。
核心思路就一句：把 MCP 那个「按需加载」的架构，搬到文档上。
还记得 /context 里那行吗——MCP tools · 33 tools · 0 tokens (loaded on-demand)。33 个工具，开局零成本，因为它只在被调用时才拉 schema。而 skills 和 agents 全量常驻，193 个就吃掉 9.8k。
同一个道理：文档不该「灌进 context」，该「挂在外面等着被取」。
三步，从「硬灌」到「按需取」
第一步：一次性转换，别每次重读。 PDF 是最糟的输入格式——排版噪音、页眉页脚、跨页断行，全都是 token。转成结构化 markdown，转一次，之后永远读转换后的：
# 转换 + 切片：按接口/章节切，不按页切
python3 -c "
import pymupdf4llm, pathlib
md = pymupdf4llm.to_markdown('api-manual.pdf')
pathlib.Path('api-manual.md').write_text(md)
"
wc -c api-manual.pdf api-manual.md # 看看瘦了多少
第二步：建一份「目录 + 索引」，让它只读需要的那一节。 Agent 要的从来不是整本手册，是「退款接口的入参是什么」。所以给它一个薄薄的接口清单（几 KB），和一个按接口名取详情的方法：
docs/api/
INDEX.md ← 只有接口名 + 一行说明 + 所属文件（几 KB，可以常驻）
refund.md ← 按需读
logistics.md
price-protect.md
INDEX.md 进 CLAUDE.md 或 skill；详情文件让它自己按需 Read。这就是把 13 MB 的常驻成本，换成几 KB 的常驻 + 按需的几十 KB。
第三步：让便宜模型去啃文档，主 agent 只拿摘要。 这是 subagent 唯一真正省钱的用法——它省的不是算力，是主会话的 context：
---
name: doc-scout
description: 只读文档侦查——从大文档里找出问题的答案，返回结论 + 出处，不返回原文
model: haiku
tools: Read, Grep, Glob
---
你是文档侦查兵。任务：在指定文档里找到答案，返回结论 + 章节出处。
不要贴大段原文——主 agent 的 context 很贵，你的不贵。
主会话问「退款接口怎么判断可退」，doc-scout 用 Haiku 去啃那几百页，只把结论带回来。主会话的 context 里进的是 200 字，不是 13 MB。
注意这里的反转： subagent 是我账单里 73% 的元凶，但那是因为它跑在 Opus 上、被用来干「实现 + review」这种本来就贵的活。同一个机制，换成 Haiku 去干「读文档、找答案」，它从最大的成本项变成最有效的省钱项。
贵的不是 subagent，是没声明模型的 subagent。
73% 那个口子：给每个 agent 声明 model
# 找出所有没声明 model 的 agent —— 它们全在跑你的主模型
grep -L "^model:" ~/.claude/agents/*.md
grep -rL "^model:" ~/.claude/plugins/*/*/agents/*.md 2>/dev/null
自己写的 agent 一律显式声明。搜索/定位/读日志/啃文档这类只读侦查的活，model: haiku 足够；实现和 review 才值得上大模型。
至于插件里那些没声明 model 的（比如我那个占 13% 用量的 subagent-driven-development），你改不了它的源文件——能改的是调用习惯：重武器只用在真正独立的多任务上。写文章、改配置、单文件重构，一个 agent 就够。
诚实交代： 上面这三步里，doc-scout 我建好了，PDF 转换和索引拆分还在做——下一篇会带实测数字回来。 这一篇里已经量完的（CLAUDE.md 瘦身 30.5k→13.6k、rtk hook 32.2%），都是跑完的。
判断表：什么时候开，什么时候必须关
| 场景 | codegraph | rtk | caveman | subagent 扇出 |
|---|---|---|---|---|
| 熟悉一个陌生的大代码库 | ✅ 它的主场 | ✅ 开 | ⬜ 随意 | ❌ 别拉队 |
| 日常写功能 / 改一个模块 | ✅ 开 | ✅ 开 | ⚠️ 看 context 长度 | ❌ 单 agent 够了 |
| 追全链路 bug / 翻原始日志 | ✅ 开 | ❌ 关（rtk proxy）——有损压缩会吃掉你要找的那一行 | ❌ 关 | ❌ 关 |
| 刚改完代码立刻问「这函数在哪」 | ⚠️ 索引可能还是 5 分钟前的世界 | ✅ 开 | ⬜ | ⬜ |
| 灌大 PDF / 知识库语料 | ❌ 四板斧全部失效 —— 老老实实拆分、抽取、只喂需要的章节 | ❌ | ❌ | ⬜ |
| 真正独立的多任务并行 | ✅ 开 | ✅ 开 | ⬜ | ✅ 值得——但给每个 agent 声明便宜的 model |
| 写文章 / 改配置 / 单文件重构 | ⬜ | ✅ 开 | ⬜ | ❌ 绝对别用重武器 |
本周你能做的 10 件事
- 量你的大户，别猜。
wc -l你最常追的那条链路涉及的文件，du -sh你要喂给 Agent 的文档目录。先知道钱花在哪，再谈省。 - 跑
/context。 看 memory files / skills / custom agents 各占多少。这是你的开局包袱。 - 跑用量归因面板。 看「超过 150k context / 8h+ 会话 / 并行会话 / subagent 密集」四个维度。这四个数不相加，别当饼图看。
- 量你的 CLAUDE.md：
wc -m ~/.claude/CLAUDE.md ./CLAUDE.md。超过 3 万字符就该拆。 - 按加载时机重新分配：常驻规则留 CLAUDE.md，任务流水线搬 skill，溯源上下文进 notes。别删内容，改加载时机。
- 查你装的工具是不是装饰品：
grep -rn "<tool>" ~/.claude/settings.json ~/.claude/CLAUDE.md ~/.zshrc。空 = 它从没被调用过。 - 给压缩工具找逃生舱，并写进 checklist。用 rtk 就记住
rtk proxy <cmd>——不然你会在幽灵 bug 上烧掉一下午。 grep -L "^model:" <插件>/agents/*.md。没声明 model 的，全在跑你的主模型。- 看 daemon 日志，而不是相信「索引会自动同步」这句话：
tail -20 .codegraph/daemon.log，找Auto-synced和idle timeout的节奏。 - 大文档不要整份喂。 13 MB 的接口 PDF 先按接口拆成片段、抽成结构化摘要，让 Agent 按需取——这一块四板斧帮不了你，只能靠架构。
反方：这套东西的复杂度成本是真的
视频作者自己在结尾讲了句很诚实的话：四个东西全上，最大的代价是复杂度。 索引会 stale、压缩有损、caveman 过度精简——你多了三个失效点要 juggle。
我要再加一条他没说的：这三个失效点的共同形状是「你以为你在看源，其实你在看派生物」。 代码 vs 图谱、原始输出 vs 压缩输出、完整历史 vs 精简历史。每一层都在你和真相之间加了一道，而每一道都会在你最需要真相的那一刻（追 bug）静默地骗你。
网上也有反方的声音，比如 Token Inflation Nightmare: Are Your Claude "Hacks" Actually Burning Your Cash?，打的就是重索引的 CPU/RAM 开销和有损压缩导致的返工。别只听一面。
我的立场：① ④ 无条件做（CLAUDE.md 瘦身 + 会话管理，零失效模式）；② rtk 做，但记住逃生舱；③ caveman 看你的 context 形态，我不装；而最大的两个口子——大文档灌入和 subagent 扇出——工具治不了，只能靠架构和你自己盯着归因面板。
我的账还没结清
诚实交代现状：
| 口子 | 状态 |
|---|---|
| CLAUDE.md 常驻 | ✅ 30.5k → 13.6k tokens/session |
| rtk 输出压缩 | ✅ 已接 hook，实测 32.2% |
| codegraph 检索 | ✅ 在跑，stale 窗口 = 300s idle |
| caveman | ⬜ 故意不装 |
| 大文档灌入（13 MB PDF + 5.3 MB 语料） | ❌ 四板斧的盲区，还没治 |
| subagent 扇出 = 73% | ❌ 还在流血 |
| 插件常驻（193 skills / 20 agents） | ⬜ 待砍，预计再省 ~10k/session |
| 4+ 并行会话 = 39% | ❌ 习惯问题，工具治不了 |
我把灯泡全换成 LED 了，四台空调还开着。
上面那套「按需取」的架构我已经开始搭了。下一篇带实测数字回来：13 MB 的 PDF 拆成索引 + 片段之后，一次接口对接实际进 context 的是多少 token；以及把只读侦查全部降到 Haiku 之后，那个 73% 掉到了几。
回复关键词「账单归因」，我把这次实测用的东西发你：/context + 归因面板的逐项拆解模板、「工具是不是装饰品」的 5 条自查命令、CLAUDE.md → skill → notes 的三层拆分清单、以及上面那张覆盖矩阵和开关判断表。
回复渠道见页脚（公众号 / X）。不方便回复的，评论区留邮箱也行。
Subscribe for updates
Get the latest AI engineering posts delivered to your inbox.