如何减少 Claude Code 和 Codex 长会话中的 token 浪费

结论先说

如果你的 Claude Code 或 Codex 会话越聊越慢、越难驾驭，或者在 API 计费场景里越跑越贵，问题通常不在于“提示词还不够好”，而在于工作流形状本身。

2026-04-17，NVIDIA 的 Dynamo 团队发布了一篇关于 agentic inference 的详细文章，里面直接用了 Claude Code 和 Codex 风格的会话作为例子。它的核心观点很实用：长编码会话本质上更像 write-once, read-many 系统。真正昂贵的是那段稳定前缀：system instructions、tool definitions、repo rules，以及任务里跨多轮都不变的部分。你越频繁改写这段前缀，就越会触发额外重算；你越能保持它稳定，系统就越有机会复用它。

如果你走的是支持 prompt caching 的 API，这种复用还可能直接降低重复输入成本。但“措辞差不多稳定”还不够。Anthropic 的 prompt-caching 文档写得很清楚：你需要可缓存的内容块和明确的 cache breakpoint，而且 cache point 必须放在后续请求里会保持完全一致的内容之后。OpenAI 的 prompt-caching 指南也说明，复用依赖精确的前缀匹配，而且只有当 prompt 至少达到 1,024 tokens 后才开始生效。如果你用的是 Claude Code 或 Codex desktop 这类捆绑产品，更稳妥的理解方式仍然应该是：把它当成 latency 和 context hygiene 优化，而不是已经被官方证明的终端计费节省。

最稳妥的默认做法其实很简单：

• 一个会话只做一个目标，
• 把稳定指令收进一个小而可复用的前缀，
• 只有分支真正独立时才拆并行，
• 在线程变成一整段聊天流水账之前，把阶段性结论沉淀到文件里，
• 不要把当前轮次不需要的工具或文件继续挂在上下文里。

长会话会把问题放大

这个话题之所以值得现在讲，不是因为“agents 最近很火”，而是因为 2026-04-17 确实出现了新的明确信号。

NVIDIA 的官方文章指出，编码 agent 会话可能在携带一大段共享前缀的前提下连续发出数百次 API 调用。在他们公开的例子里，Claude Code 风格会话在首次写入缓存之后，后续轮次的 cache reuse 达到了 85% 到 97%；而四 agent 团队的 aggregate cache hit rate 达到了 97.2%，read-to-write ratio 为 11.7x。这些是基础设施层面的数字，不是对每个托管产品的体验承诺。但它足够说明一个模式：长会话的成本结构，往往被“反复复用同一段上下文”主导。

如果你走的是 API 计费工作流，价格层面也会放大这个差异。

截至 2026-04-20，Anthropic 的 prompt-caching 文档写明默认缓存生命周期是 5 minutes，Anthropic 的 pricing page列出的 Sonnet 4.6 价格是输入 $3 / MTok、5 分钟 cache write $3.75 / MTok、cache read $0.30 / MTok。OpenAI 的 API pricing page 列出的 GPT-5.4 价格是输入 $2.50 / 1M、cached input $0.25 / 1M，GPT-5.4 mini 则是输入 $0.75 / 1M、cached input $0.075 / 1M。如果你用的是产品捆绑套餐而不是原始 API 计费，更适合把这些数字理解为“复用经济性”和“延迟行为”的证据，而不是直接等同于产品侧账单会下降。

编码 agent 里的 token 浪费到底从哪来

大多数 token 浪费，并不是来自某一次回答答错了，而是来自你反复让模型重读太多易变上下文。

常见原因：

模式	会发生什么	更好的做法
一个聊天线程装很多无关任务	前缀越来越长，但和当前轮次真正相关的部分越来越少	目标一变就开新会话
每轮都重新解释 repo 规则	稳定指令在每轮里被重复改写、重复转述	把 repo 规则放进一个小文件，再让 agent 去读它
为了松散相关的工作乱开 subagent	每个分支都要冷启动，还可能重复携带 setup 上下文	只有输出可以独立审阅时才拆分
把整段文件和日志直接倒进聊天	线程会一直背着那些已经没用了的旧细节	把结果沉淀成 note、diff 或 issue comment
长时间保持很多工具都在作用域里	tool schema 和权限边界都会增加上下文长度和复杂度	只保留当前任务必需的工具

Tip 1：把稳定指令当成前缀，而不是聊天噪音

如果一条规则会在大多数轮次里长期成立，它就不该反复出现在来回对话里。

Anthropic 的 prompt-caching 文档在这里很有参考价值，因为它把缓存结构理解为“后续对话之前的一段稳定前缀”。Anthropic 的 Claude Code memory 文档则把同样的逻辑搬到了工作流层面：把持久的项目规则放进 CLAUDE.md，而不是每轮都重新说一遍。

如果你直接走 API，把这条原则再具体一点。Anthropic 文档里，cache hit 取决于你把 breakpoint 放在哪里，以及可复用前缀是否足够长，达到模型要求的最小可缓存长度。OpenAI 文档里，可复用部分必须从 prompt 开头开始精确匹配，不是“意思差不多”就行。“大体相同”和“真正可缓存”不是一回事。

如果你就在这些产品里工作，还应该直接用它们原生的会话控制手段。截至 2026-04-20，Anthropic 的 Claude Code commands 文档列出了 /compact，用于压缩当前对话；也列出了 /clear，用于清空历史后重新开始。OpenAI 的 Introducing the Codex app 则说明，Codex agents 运行在按 project 组织的独立 threads 里，而且 app 内置了 worktrees。落到实操上，意思就是：

• 在 Claude Code 里，如果目标没有变，但 transcript 已经膨胀到很难带着继续走，就用 /compact；如果旧历史已经变成死上下文，就用 /clear，
• 在 Codex 里，更应该优先开一个新 thread；如果代码路径也已经分叉，再配一个新的 worktree，而不是强行把无关工作塞进同一个长会话里。

适合收进稳定前缀的内容包括：

• repo conventions
• coding style rules
• test commands
• review checklist
• approval boundaries
• 整个任务期内都有效的产品文档或 API 文档链接

对 Claude Code 来说，这通常意味着一个足够紧凑的项目说明文件，例如 CLAUDE.md，或者其他 repo 文档。对 Codex 来说，这意味着一个尽量短、尽量稳定的 task brief，再加上放在文件里的项目说明，而不是每条消息都把相同约束再粘贴一遍。

反例：

Use TypeScript. Also keep accessibility in mind. Also do not change analytics. Also prefer server components. Also keep changes small. Also run the same test command as before.

更好的写法：

Use the repo rules in AGENTS.md.
Task: fix the mobile checkout validation error without changing analytics or auth flows.
Stop after code changes plus the exact verification commands.

这个变化看起来很小，其实不是。它把稳定指令从一堆越积越多的转述，变成了可复用前缀的一部分。

Tip 2：一个会话只做一个目标

一个编码线程应该只有一条明确的终点线。

好的会话边界：

• 一个 bug
• 同一子系统内的一次重构
• 一轮 PR review
• 一次 setup 或 migration 任务
• 一篇有明确验证路径的文档改动

不好的会话边界：

• “顺手把 repo 也清理一下”
• “顺便把文档更新、CI 修了、价格对比也查了、这个 PR 也看了”
• “把这条聊天当成我整周的通用编码工作区”

一个很好用的重置判断规则是：

• 如果 acceptance test 变了，开新会话；
• 如果主工作目录变了，大概率也该开新会话；
• 如果你在问新任务之前，不得不先花一段话解释旧上下文，那就一定该开新会话。

这也是 worktree 真正有用的地方。新的 worktree 会给你新的分支、更小的 diff，以及一个天然适合开启新 agent 会话的环境。

git worktree add ../repo-fix-checkout -b fix-checkout-validation
cd ../repo-fix-checkout

Tip 3：并行 agent 只用在真正独立的分支上

NVIDIA 的2026-04-17 文章有个很重要的价值：它把 lead agent 和 subagents 区分开了，而不是假装所有并行都没有成本。

当每个分支都能回答一个很窄的问题时，并行是有帮助的，比如：

• trace 一个 failing test，
• inspect 一次 dependency upgrade，
• review 一个文件夹里的 dead code，
• compare 两种 implementation option。

当每个分支都需要整套 repo 背景和完整聊天历史时，并行就会开始伤害效率。

对 API 用户来说，这里还有一个 cache timing caveat。Anthropic 的 prompt-caching 文档说明，cache entry 要等到第一个响应开始之后才会对其他请求可用。OpenAI 的 prompt-caching 指南则说明，当很多请求同时带着相同前缀到达时，cache routing 可能会降低实际效果。所以，如果你想让共享前缀真的产生帮助，更稳妥的做法是：先让一个 lead request 把前缀“热起来”，再向外拆分成更窄的分支。

在你决定要不要再开一个 agent 之前，可以先用这个判断：

• If the subtask can end with a small memo, diff, or yes/no recommendation, spawn it.
• If the subtask needs the full evolving plan, keep it in the main thread.

一个紧凑的 delegation prompt，通常比把整个聊天历史都转发过去更有效：

Check only `src/payments/` for why the checkout form sends duplicate validation events.
Do not edit files.
Return:
1. likely root cause,
2. exact files involved,
3. whether the fix is low, medium, or high risk.

这样做既保留了独立性，也限制了每个分支必须携带的上下文长度。

Tip 4：在线程变成日志档案之前先做里程碑摘要

长编码聊天会变差，往往不是因为旧探索错了，而是因为旧探索一直留在活跃上下文里。

更好的模式是：在关键里程碑，把临时推理转成可持久引用的简短记录，例如：

• repo exploration 之后，
• root cause 找到之后，
• fix path 选定之后，
• verification 完成之后，
• 交接给其他 agent 或其他人之前。

这个摘要应该短，而且最好有文件承载。

里程碑 note 示例：

## Checkout validation checkpoint
- Root cause: `useCheckoutValidation` fires both on blur and on submit for the same empty state.
- Files: `src/features/checkout/useCheckoutValidation.ts`, `src/features/checkout/CheckoutForm.tsx`
- Safe fix path: dedupe submit-time emission when blur already marked the same field invalid.
- Verify with: `bun test src/features/checkout` and manual mobile checkout flow.

它能给下一轮一个干净锚点，比拖着 60 轮探索历史继续前进要好得多。

Tip 5：长会话里把工具作用域收紧

每多一个工具、连接器或权限面，都会带来更多无关上下文、更长的 tool definitions，以及暂停后更慢的恢复成本。

截至 2026-04-16，OpenAI 的 Codex update post 已经把产品面扩展得很大：browser actions、plugins、memory、multiple terminals、review-comment handling、automations 都在里面。这当然有用，但它也更容易让你把一个会话做成“活跃表面太多”的状态。

最安全也最有效的默认做法其实很朴素：

• 只启用当前任务需要的工具，
• 只有真的必须时才打开 browser 或 desktop control，
• 不要因为“以防万一”就把额外 docs、logs、screenshots 一起挂进去，
• 把长期 memory 留给稳定偏好，而不是临时项目状态。

对 Claude 一侧的工作流也是一样。缓存那些会长期稳定的部分，不要让 live thread 一直堆满临时碎片。

一个通常能减少浪费的会话模板

启动一个非 trivial 编码任务时，可以先用这个模板：

You are helping with one bounded coding task.
Goal: fix [specific problem].
Scope: only [files, folders, or subsystem].
Constraints: follow repo rules in [file]; do not change [out-of-scope areas].
Tools: use only what is needed for this task.
Process:
1. inspect,
2. propose the smallest fix,
3. apply it,
4. run the exact verification commands,
5. stop.
Return a short checkpoint summary before any optional follow-up work.

它之所以有效，是因为它把前缀稳定下来，也给了会话一条明确的停线。

什么时候别再优化这条线程，而是直接重开

遇到下面这些情况时，直接重开一个新会话，通常比继续挽救旧线程更划算：

• agent 已经在错误理解上跑了很多轮，
• 你接受的计划已经变了，
• 真正相关的 repo 区域已经完全换了，
• 线程里已经堆满了大量死上下文，
• 你现在需要的是一条比现有线程更干净的 review 记录。

很多时候，重开一条干净会话，比硬救一条臃肿线程更省事。

常见问题

只有按 token 计费时，这些建议才有意义吗？

不是。账单信号在 API 定价里最清楚，但同样的复用逻辑，在捆绑产品里也可能表现为更好的延迟和会话质量。

有了 prompt caching，是不是就能无限拉长同一个大线程？

不能。Anthropic 的文档把 prompt caching 定义为前缀复用，不是给你一张“无论上下文多乱都能继续加”的许可证。相关性仍然重要。

我是不是应该总是用 subagents 来提速？

不是。只有当分支能保持很窄，而且能返回一个边界清楚的结果时，subagents 才真的值。否则你只是制造了多个冷启动，再加上一轮新的 review 成本。

summary file 真的比聊天历史更好吗？

通常是。一个有文件承载的短摘要，会把下一轮重新锚定在你仍然关心的事实之上；而完整聊天记录会继续把所有东西都背在上下文里。

核验说明

核验时间：2026-04-20。

核验官方来源：

• NVIDIA: Full-Stack Optimizations for Agentic Inference with NVIDIA Dynamo：用于核对 2026-04-17 的发布时间、cache reuse 示例，以及 multi-agent read-to-write ratio。
• Anthropic Prompt Caching、Anthropic Claude Code Memory、Anthropic Claude Code Commands 和 Anthropic Pricing：用于核对默认缓存生命周期、cache breakpoints、并发行为、CLAUDE.md memory 用法、/compact、/clear 以及 Sonnet 4.6 缓存定价。
• OpenAI Prompt Caching 和 OpenAI API Pricing：用于核对 exact-prefix matching、minimum cacheable length、cache-routing caveat，以及 GPT-5.4 / GPT-5.4 mini 的 cached-input 定价。
• OpenAI: Introducing the Codex app：用于核对 Codex threads 按 project 组织、built-in worktrees，以及 session-history continuity。
• OpenAI: Codex for almost everything：用于核对 Tip 5 里引用的 2026-04-16 Codex desktop 功能面。