高效管理 Coding Agent 会话：用更少 Token，做更多事

在 Claude Code、Codex 这类 agentic 编码工具里，成本不再是固定月费，而是直接与 token 消耗挂钩。长会话中，第 40 轮请求仍在重读前 39 轮的全部历史——文件内容、命令输出、调试过程——这些都会被反复计费。真正的高效不在于「少用 token」，而在于让每一份 token 都花在当前要完成的任务上。

下文综合官方建议、社区实践与个人经验，整理成一套可落地方法；每条说明「怎么做」与「为什么有效」。

一、先理解成本从哪里来

Token 价格受三个主要因素影响：

1. 模型大小：大模型更贵，适合复杂/模糊问题；日常任务用小模型更划算。以 2026 年 8 月官方定价为例，Claude Opus 5 约是 Sonnet 5 的 2.5 倍；GPT-5.6 旗舰 Sol 约是中档 Terra 的 2.5 倍、约是轻量 Luna 的 25 倍。比例随定价调整，以官方定价页为准。
2. 输入 vs 输出：输出 token（生成内容）单价约是输入的 5 倍。
3. Prompt Caching：重复的「前缀」内容可缓存，读缓存约为原价的 10%——是打折而非免费，长会话即使全部命中也仍在计费。缓存失效的常见触发点：切换模型、切换 effort、开启 fast mode、连接或断开未延迟加载的 MCP 服务器、执行 /compact、升级 Claude Code 版本。只要前缀有任何变化，下一轮请求就整段按全价重新处理。

缓存有效期（TTL）分两种情况：用订阅账号（Pro/Max/Team/Enterprise）登录时默认为 1 小时；用 API Key 或第三方网关时默认只有 5 分钟，需设置 ENABLE_PROMPT_CACHING_1H=1 才能延长（需多付一次缓存写入费）。

会话本身也会不断膨胀：系统提示、CLAUDE.md、工具定义、你读过的文件、跑过的命令输出……都会一直留在上下文里，每轮都被重新发送。

核心原则：保持上下文「短而相关」。一个长会话往往比拆成几个短会话更贵。

为什么长会话更贵？

这一原则由请求机制决定，主要有五层原因：

1. 每轮重发全部历史，缓存只是打折。Claude 没有跨请求记忆，每轮请求都要把系统提示、CLAUDE.md、全部历史对话和本轮新增内容重新拼接发送。会话越长，前缀越大，一旦缓存失效，重算代价越大；即使全部命中，读缓存的费用也随历史线性增长。
2. 新增的「尾巴」永远全价，且越滚越大。每轮真正新处理的内容（新消息、新回复、新工具结果）都是全价 token。失败尝试、过时调试输出会留在历史里，成为之后每轮都要重读的固定负担。
3. 长上下文拉长输出、增加走弯路概率。无关历史越多，模型越容易做无谓探索（多余的文件读取和工具调用），而输出单价是输入的 5 倍，绕路成本被放大；噪声还会干扰判断质量。
4. 多任务上下文互相干扰，错误率上升。长会话往往同时处理多个任务，旧任务的文件路径、变量名、调试结论会污染新任务的判断。模型需要额外 token 去「区分哪些信息还有用」，这部分开销不直接可见，但会体现在更长的输出和更多的修正轮次上。
5. 长会话更容易触发自动 compact，时机不可控。上下文接近上限时，系统会在非理想时机强制压缩，总结质量差，且压缩本身也是一次全价请求。主动拆成短会话，可以把压缩时机掌握在自己手里。

一句话总结：短会话省钱，是因为同时避免了「缓存失效的重算成本」「无谓输出的放大效应」「上下文噪声对质量的拖累」「多任务干扰导致的修正轮次」和「不可控的自动 compact」五重叠加。

如何自己验证：选一个中等复杂度的真实任务，分两次完成。第一次在一个长会话里从头做到尾；第二次拆成 2-3 个短会话，每完成一个子任务就 /clear。两次结束后分别用 /usage 记录总输入、总输出和缓存读写量，对比总成本，同时观察第二次的输出质量是否更稳定。这个实验只需半小时，得到的数字比任何文章都有说服力。

二、核心习惯（官方推荐）

1. 任务切换时果断 /clear

怎么做：完成一个相对独立的任务后，直接运行 /clear（可先 /rename 方便以后 resume）。
为什么有效：旧任务的文件读取、失败尝试、调试输出全部清空，新任务不再背负无关历史。每轮请求的 token 量立刻下降，缓存也更容易从干净状态建立。
注意：/usage 显示的会话总成本在 v2.1.211 之前会跨 /clear 持续累加，之后的版本在 /clear 后清零。这只影响统计数字，不影响实际计费。

2. 用 @ 直接提及文件，而不是让 Claude 自己找

怎么做：写「修复 @utils.test.ts 里的失败测试」。
为什么有效：Claude Code 会在发送第一轮请求前就把文件内容附加进去，省掉「搜索 + Read 工具调用」整轮。文件只需 @ 一次。
注意：超大文件会快速填满上下文；再次 @ 同一文件通常会再附加一份副本。

3. 开始前就定好模型和 effort 级别

怎么做：会话一开始就设置好，中途尽量不改。
为什么有效：模型和 effort 等级各自都是独立的缓存键。即使对话内容完全相同，换一个模型或 effort 等级，下一轮请求都会 0 命中、按全价重新处理完整历史。这也是切换时 Claude Code 会弹出确认提示的原因。

4. 对嘈杂命令加 quiet 参数，或放到 Subagent

怎么做：在 CLAUDE.md（或 AGENTS.md） 里写好常用命令并带上 quiet 标志；或让子代理去跑会产生大量输出的任务（如测试、日志分析）。
为什么有效：命令输出会像文件一样永久留在主会话上下文里。Subagent 有独立的系统提示和上下文窗口，只把摘要结果返回主会话，噪声被完全隔离。
注意：Subagent 的缓存始终是 5 分钟 TTL，订阅账号的 1 小时延长只对主会话生效。让 Subagent 长时间空闲后再继续，更容易冷启动重算。

5. 新会话开始时跑一次 /context

怎么做：开新会话后立刻执行，查看当前加载了哪些东西，关掉不需要的。
为什么有效：提前发现并剔除不必要的固定开销，从源头减少每轮的基础 token。

6. 休息前主动 /compact

怎么做：准备离开键盘时运行 /compact focus on 当前任务关键决策、文件和 next steps。
为什么有效：/compact 本身是一次完整请求，要把当前对话全部发送一遍生成摘要。趁缓存还热，这次请求大部分走缓存价，主要花费在生成摘要部分；一旦超过缓存窗口（订阅约 1 小时，API Key 默认 5 分钟）再执行，就要按全价重新处理整段历史。「趁热压缩」比「过期后再压缩」便宜得多。

三、进阶与社区补充技巧（高杠杆，强烈推荐）

7. 精简 CLAUDE.md，把工作流移到 Skills

怎么做：把 CLAUDE.md 控制在 200 行以内，只放「每会话都需要」的稳定规则。详细工作流、检查清单等移到 Skills（按需加载）。也可用 path-scoped rules（.claude/rules/）。
为什么有效：CLAUDE.md 在会话启动时加载并常驻，构成每轮请求的固定开销。Skills 只在被调用时才把内容注入对话，既不占启动开销，也不破坏已有缓存前缀。
注意：CLAUDE.md 在会话中途被编辑不会让缓存失效，但也不会立刻生效——Claude 仍使用会话开始时加载的内容，新内容要等下次 /clear、/compact 或重启会话才生效。
优先级：.claude/rules/ 中的 path-scoped rules 优先于 CLAUDE.md，适合存放项目特定规则；CLAUDE.md 存放通用稳定规则。两者冲突时，path-scoped rules 生效。

8. 主动在 60% 左右手动 /compact，并始终加 focus 指令

怎么做：看到上下文到 60% 左右就运行 /compact focus on ...，不要等自动或警告。
为什么有效：自动 compact 往往在上下文已接近满、时机不可控时才触发，总结质量差。提前手动 + 指令能保留真正有用的信息，并利用还热的缓存把压缩本身的成本降到最低。

9. 自定义 Status Line，实时盯住上下文百分比和成本

怎么做：运行 /statusline show model, context percentage with progress bar, session cost，并加颜色编码（绿 <50%、黄 50-75%、红 >75%）。
为什么有效：上下文膨胀是隐性最大成本。实时可见后，你会在「质量下降前」就主动清理，而不是事后补救。关注两个指标的比值：cache_read_input_tokens（走缓存的量，约 10% 单价）和 cache_creation_input_tokens（新写缓存的量，全价）。读写比越高说明前缀越稳定；若每轮 creation 都很高，说明有东西在持续打断缓存前缀，比如反复切模型、反复启停某个 MCP 服务器。

10. 精确指定文件 + 行范围

怎么做：写「对比 @src/auth/session.ts 的 30-90 行」或「只读 lines 40-90」。先用 plan mode（Shift+Tab）出计划再执行。
为什么有效：整文件读取动辄几千到上万 token，且永久留在上下文。精确范围能把单次读取从 5k+ 降到几百 token。

11. 并行多会话 + git worktree

怎么做：用 claude --worktree <名字>（简写 -w）同时跑 3–5 个隔离会话（不同功能/分支）。每个 worktree 有独立目录和分支，共享同一个 .git。
为什么有效：每个会话独立上下文，互不污染。总有效工作量大幅提升，单个会话也不会因为「同时干太多事」而膨胀。
成本权衡：worktree 解决的是文件冲突，不是省 token。每个并行会话是独立对话，彼此不共享缓存——开 3 个会话的 token 消耗约为单会话的 3 倍。官方文档给出的参考数字：Agent Teams 在 plan mode 下约为单会话的 7 倍。并行的价值是「用可控成本换吞吐」，预算按会话数线性估算。

12. 按任务复杂度动态选模型 + effort（只在正确时机切换）

怎么做：简单任务用 Sonnet/Haiku + low/medium effort；复杂架构用 Opus + high/max。只在会话开始或 /clear 后切换。
为什么有效：正确路由能在质量几乎无损的前提下省钱，且避免中途切换造成的一次性缓存失效。以当前定价 Opus 约是 Sonnet 的 2.5 倍，「能用 Sonnet 就不用 Opus」依然值得坚持，但更值得优先做好的是避免中途切换、减少不必要的重复轮次。

13. 关闭不需要的 MCP 服务器

怎么做：新会话跑 /context 后，用 /mcp 关掉本会话用不到的服务器。
为什么有效：当前版本默认对 MCP 工具定义采用「延迟加载」——只有工具名称进入上下文，完整定义等真正调用时才加载。因此连接或断开延迟加载的服务器通常不会让整段缓存失效，这条建议的收益已从「每个工具定义都在烧 token」降为「减少工具名称列表、避免意外调用产生的输出噪声」。

CLI 优先原则：能用 CLI 工具（如 gh、aws、gcloud）就优先用 CLI。CLI 不需要在上下文里维护工具清单，比 MCP 更省。例如用 gh pr list 代替 GitHub MCP 的 list_pull_requests，输出更简洁，也不占用工具定义槽位。

14. 给 Claude 内置验证闭环

怎么做：在 CLAUDE.md 或提示里明确「改完后必须跑测试 /build，直到通过才停」。
为什么有效：没有验证时 Claude 会「看起来完成」就停，你得反复纠正（每轮都付上下文税）。有闭环后它自己迭代到正确，总 token 反而更少。

四、上下文已经很大、任务还没完成时怎么办？

按成本从低到高排序：

HANDOFF.md 推荐结构（让 Claude 生成）：

请把当前会话整理成 HANDOFF.md，结构如下（精炼、可执行）：

- Goal
- Status（已完成 / 进行中 / 未开始）
- Key decisions & rationale
- Files touched
- Open issues / blockers
- Next steps
- Don’t do / Lessons learned

保存后 /clear，新会话第一句：@HANDOFF.md 继续任务，先确认理解，再执行 Next steps 第一步。

补充：第 8 条提到的自动 compact 触发时机不完全可控，配合第六节的 /autocompact 或 CLAUDE_CODE_AUTO_COMPACT_WINDOW 可以显式控制阈值。

五、什么情况下可以放宽标准

省钱不是唯一目标。以下场景不必严格遵循短会话原则：

• 原型探索期：需求模糊、需要大量试错时，长会话保持上下文连贯更重要，成本是次要的。
• 一次性脚本：用完即弃的代码，不需要优化 token 消耗。
• 深度调试：复杂 bug 需要保留完整调试历史，频繁 /clear 会丢失关键线索。
• 教学/演示：向他人展示完整思考过程时，长会话更有价值。

判断标准：当「节省的 token 成本」低于「上下文断裂带来的认知负担」时，放宽限制。

六、长期养成的好习惯

1. 把稳定规则写进精简版 CLAUDE.md，工作流放 Skills。
2. 把「Compact instructions」和 HANDOFF 模板写进 CLAUDE.md。
3. 大文件或探索性工作尽量用 Subagent（可指定便宜模型，如在 frontmatter 里写 model: haiku）。
4. 定期用 /context + Status Line 自查，关注缓存读写比。
5. 一个逻辑完成点（有意义的 commit）就考虑清理上下文。
6. 任务分块：完成一个组件后新会话做集成。
7. 提前触发 compact 的稳妥做法：/autocompact 500k（交互式命令，写入用户设置）或环境变量 CLAUDE_CODE_AUTO_COMPACT_WINDOW（接受具体 token 数，脚本化场景优先级最高）。社区流传的 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 不是官方文档记录的配置项，存在阈值被静默封顶、从 settings.json 设置被忽略等已知问题，不建议依赖。

七、5 分钟自查清单

每周或每个大任务结束后，快速检查：

• [ ] CLAUDE.md 是否超过 200 行？是否有可移到 Skills 的内容？
• [ ] 本周是否因忘记 /clear 导致会话膨胀？
• [ ] Status Line 是否显示上下文百分比和成本？
• [ ] 缓存读写比是否健康（read:creation 大于 5:1）？
• [ ] 是否有未使用的 MCP 服务器在后台运行？
• [ ] 是否在用 CLI 工具替代 MCP（如 gh 代替 GitHub MCP）？
• [ ] 最近一次 /compact 是否加了 focus 指令？

发现 3 项以上未达标，说明当前工作流有优化空间。

八、版本适配说明

• 本文基于 Claude Code v2.1.232（2026 年 8 月）撰写。
• 价格数据来自 2026 年 8 月官方定价页，实际以官方页面为准。
• 命令和功能可能随版本更新变化，建议定期查看官方更新日志。
• 社区技巧（如 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE）未经官方文档确认，使用前请验证。

写在最后

Claude Code 等 Agent 的真正价值，不在于一次塞进多少上下文，而在于让模型始终聚焦在当前最相关的信息上。
短而干净的会话，不仅更便宜，模型表现也往往更好——这一点已由第一节的机制拆解说明，不只是经验规律。

从今天开始，试着在任务切换时 /clear、用 @ 提及文件、60% 左右主动 /compact、精简 CLAUDE.md、开启 Status Line。
几周后你会明显感觉到：同样预算下，能完成的工作量显著增加，而且对话质量更稳定。

把这些小习惯变成肌肉记忆，你就已经在「用更少 token 做更多事」的路上了。

保持探索和学习同样重要。模型能力和 Agent 设计仍在快速迭代，今天的最优实践半年后可能就有更高效的替代方案。关注官方更新日志、社区讨论和实际成本数据，定期重新审视自己的工作流，才能持续站在效率前沿。

附一：快速路径

• 新手：先掌握第 1-6 条（/clear、@ 提及、模型选择、quiet 参数、/context、/compact），覆盖 80% 日常场景。
• 老手：直接看第 7-14 条（Skills、Status Line、精确读取、worktree、MCP 优化），追求极致效率。
• 团队负责人：关注 CLAUDE.md 精简、HANDOFF 模板统一、团队成本监控。

附二：关键命令速查