先说结论，怎么省钱呢，其实就是做好会话管理。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。

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

        11M 上下文并不是无限记忆。拿 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 写对应文档或补测试，旧的上下文可能仍然是有价值，继续会话就挺好的。

        4Claude Code 里有个 rewind 功能我还挺喜欢的，你可以随时退回到之前的某个状态：当 Coding Agent 犯了错你去 PUA 它是没用的，失败路径已经进入上下文了，Agent 后面每一步都要背着这些旧内容继续走。

        更好的做法是 rewind。回到它刚读完关键文件、但还没开始错误实现的位置，然后重新给命令。

        这样保留了有价值的上下文，删除了错误实现和推理，效果更好，也更省 token。

        这条尤其适合复杂调试。调试的中间过程经常产生大量命令输出、错误日志和假设。

        如果你确定某条路径废了，就不要让它继续留在当前会话里。

        5主动压缩也是个好办法，不要总是等着自动触发。当上下文快满时，系统会自动压缩，把长会话总结成短摘要，然后继续工作。

        但是，自动压缩发生的时候，往往已经到了上下文最混乱的时候。

        更好的方式是主动 compact，并给出明确的方向，比如：/compact 聚焦阅读模块的重构，保留数据同步的逻辑，不用保留之前的 UI 交互和调试信息。

        这就等于是在压缩上下文的时候，告诉模型，下一阶段要服务什么目标。

        否则压缩的时候可能把你后面需要的信息丢掉。6Sub Agent 是省 Token 的大杀器，很多任务会产生大量中间输出，但你最终只需要一个结论。

        比如：读代码库，找一下用户认证是怎么实现的。这样的任务如果在主会话里做，主会话的上下文会被搜索结果、文件内容、日志输出填满。

        更好的方式是让子 Agent 去做，你要个结果就行。

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

        我经常这么干。写了这么多，其实提高效率节省 Token 的本质就是减少无效记忆，给明确的指令，避免重复，减少无效记忆，清除污染信息。

        1M 上下文让 Coding Agent 能做更长、更复杂的事，但依然需要工程判断。管理好你的会话，不仅省钱，你和你的 AI 也会很聪明。