1M 上下文时代太费Token，告诉你我的Coding Agent 省钱方法

本文来自微信公众号： MacTalk ，作者：池建强，原文标题：《1M 上下文时代太费 Token，告诉你我的 Coding Agent 省钱方法》

先说结论，怎么省钱呢，其实就是做好会话管理。

1M上下文是什么意思？就是在一次会话（session）里，模型能看见的大概100万个token。最近发布的GPT-5.5、Claude 4.6/4.7、Qwen 3.6-Plus、DeepSeek V4等等都是原生支持1M上下文，这里面有几个关键的概念：

1、在Claude Code这类Coding Agent里，上下文不是一句两句对话，而是一个大杂烩：系统提示词、长期记忆、调用过的工具、工具的输出、读过的代码文件、终端日志、以及你给它的各种指令，统统都会塞进去。模型每回答一次，都是在这一大坨信息里“分配注意力”，决定该看什么、不看什么。

2、1百万意味着什么？以前咱们都用8K、32K、200K这种上下文窗口，现在是1M token，就像什么呢？原来你桌上摊几份文件几本书就满了，现在你有了一个很大的仓库，全部代码库、长日志、好几轮调试过程，都可以同时装进去，模型一眼看穿，这就是所谓“1M上下文时代”。

但仓库再大，有两个本质没变：1、大模型会被噪音干扰了；2、你的钱随着大量Token流失，达到一种花Token如流水的感脚。

很多人用硅谷的顶级模型，没跟人家寒暄几句呢，5小时的额度已经用得干干净净，这真是人生最大的悲剧：任务没做完，Token花完liao。

所以，老百姓必须要理性而自制，把上下文和会话好好管理起来：一方面给模型提效，一方面给自己省钱。

1

1M上下文并不是无限记忆。拿Claude Code举例，上下文包括系统提示词、对话历史、工具调用历史、工具的输出、读文件、终端日志，以及用户给过的所有指令。

1M token的窗口虽大，能支撑长任务——比如从零搭一个全栈应用，或者连续完成一次复杂重构——但是，模型每次生成回答时，都要在这些内容里分配注意力。

上下文越长，里面的无关信息越多，模型就越容易被旧路径、失败尝试、过期日志干扰。因为AI大哥见的太多了，不知道该参考谁。

所有任务都在一个会话里完成，你的Agent会越来越笨，这并不是AI变笨了，而是用法出了问题。1M context的正确打开方式也不是一直聊，得学会在不同阶段选择不同的会话策略。

2

我最常用的就是Coding Agent，比如CC，Codex，SOLO等等。每一轮对话结束，其实我们都有多个选择：

1）可以继续当前会话，适合做同一个任务，之前读取的文件、命令输出、分析路径恰恰是非常有效的。

2）压缩会话，当前任务还没完，但上下文里已经堆了太多调试过程、搜索结果和无用输出，可以选择压缩会话，继续做任务。

3）清空当前会话开启新任务，适合进入一个真正的新任务，只保留自己判断过的关键信息。

4）启动子Agent，让另一个干净上下文去做搜索、验证、读代码、写文档，最后只把结论带回来。

5）回退，适合Agent走错路了，但前面的文件读取和分析仍然有价值的场景。

这些选择，对应的是这些问题：

下一步还需要这些上下文吗？

如果需要，就留下。

如果只需要结论，就压缩。

如果要做新任务，就开新会话。

如果中间过程繁杂冗长又没啥用，我就想要个结果，那就丢给子Agent。

3

什么时候该新开会话？一个简单原则就是：新任务，新会话。

比如你刚让Agent修完登录模块的bug，现在想让它优化阅读列表的交互，虽然都在同一个项目里，依然是两个任务。继续使用旧会话，Agent会带着登录模块的背景、调试日志和失败路径进入新任务，这些内容大概率没帮助，还会污染Agent的判断。

新会话的好处是干净。我一般会这么写：订阅源和feed介绍现在已经持久化到数据库里了，后续我们的第一个迭代只做XXX这些内容，同时，系统启动时把这些数据加载到缓存，方便快速读取。

这比把几十万token的历史都塞给模型要便宜，也更准确。

当然也有例外，如果你刚做完一个功能，准备让Agent写对应文档或补测试，旧的上下文可能仍然是有价值，继续会话就挺好的。

4

Claude Code里有个rewind功能我还挺喜欢的，你可以随时退回到之前的某个状态：

当Coding Agent犯了错你去PUA它是没用的，失败路径已经进入上下文了，Agent后面每一步都要背着这些旧内容继续走。

更好的做法是rewind。回到它刚读完关键文件、但还没开始错误实现的位置，然后重新给命令。这样保留了有价值的上下文，删除了错误实现和推理，效果更好，也更省token。

这条尤其适合复杂调试。调试的中间过程经常产生大量命令输出、错误日志和假设。如果你确定某条路径废了，就不要让它继续留在当前会话里。

5

主动压缩也是个好办法，不要总是等着自动触发。

当上下文快满时，系统会自动压缩，把长会话总结成短摘要，然后继续工作。但是，自动压缩发生的时候，往往已经到了上下文最混乱的时候。更好的方式是主动compact，并给出明确的方向，比如：

/compact聚焦阅读模块的重构，保留数据同步的逻辑，不用保留之前的UI交互和调试信息。

这就等于是在压缩上下文的时候，告诉模型，下一阶段要服务什么目标。否则压缩的时候可能把你后面需要的信息丢掉。

6

Sub Agent是省Token的大杀器，很多任务会产生大量中间输出，但你最终只需要一个结论。比如：读代码库，找一下用户认证是怎么实现的。

这样的任务如果在主会话里做，主会话的上下文会被搜索结果、文件内容、日志输出填满。更好的方式是让子Agent去做，你要个结果就行。

Sub Agent有自己干净的上下文。可以读很多文件、跑很多命令、试错，最后把压缩后的结论返回给主会话。我经常这么干。

写了这么多，其实提高效率节省Token的本质就是减少无效记忆，给明确的指令，避免重复，减少无效记忆，清除污染信息。1M上下文让Coding Agent能做更长、更复杂的事，但依然需要工程判断。

管理好你的会话，不仅省钱，你和你的AI也会很聪明。