这两个月我把团队的 Coding Agent 全切到“超长上下文”模式。广告牌写着 1M token，像是突然拥有了一间巨大的资料仓库：整仓的代码、冗长的日志、几轮失败的尝试，全都塞进去，模型一眼看尽。兴奋劲儿过后，我被现实狠踹了一脚——额度往下掉得飞快，Agent 的判断却越来越钝。不是模型不行，而是我把它当“全记忆的同伴”，忽略了“会话是工作记忆”的本质。

很多厂商都在宣传 1M 上下文的新纪元，确实能承载更长的任务链，但两个老问题没有消失：噪音会吞掉注意力，Token 会吞掉钱包。省钱的路子，最后都指向同一件事：管理好你的会话，让模型只记住“该记住的”。

1M 是仓库，不是外接硬盘：上下文到底在装什么

在 Coding Agent（我常用 Claude Code、以及若干 IDE 插件型 Agent）里，上下文并不是两三句对话那么简单。系统提示词、长期记忆、工具调用历史、工具输出、读过的代码文件、终端日志、你给过的每一条指令，统统挤在这一扇“工作记忆”里。

窗口变大意味着可以在同一会话里跑通更长的任务链——从脚手架搭建到灰度发布，甚至完成一次跨模块重构。但模型每次回答，仍要在这一大坨里分配注意力。无关信息越多，路径就越容易被旧日志和失败尝试带偏。你看到的是“它开始瞎说”；模型经历的是“我见过太多互相矛盾的线索”。

把会话当“冲刺看板”：每步结束都有分岔

实操里，我把每一轮对话的结束都当作一次小分岔。按回车前，先问四个问题：

• 下一步真的还需要这堆上下文吗？
• 如果只要结论，能不能先压缩一遍再继续？
• 这算不算“新任务”？是的话，开新会话更干净。
• 中间过程会很脏吗？脏就丢给子 Agent，最后只带回摘要。

围绕这四个问题，我常用的会话策略像这样分层：

• 延续当前会话：同一任务连续推进，之前读过的文件、调试路径都还有效。
• 压缩后继续：调试产出了海量日志和搜索结果，保留要点，扔掉中间过程。
• 开启新会话：进入真正的新任务，只把“我确认过的关键信息”带过去。
• 启动子 Agent：搜索、读库、跑脚本这类高噪声过程在子会话完成，主会话只接收结论。
• 回退到干净节点：走错路了，回到“刚读完关键文件但尚未实现”的状态，重新指挥。

什么叫“新任务”？不是换项目才算

很多人把“新会话”留给“新项目”。我的经验是，只要目标切换，就算是新任务。比方你刚修完登录模块的 bug，下一秒想让它优化阅读列表的交互，哪怕还在同一仓库，也建议开一条干净的会话。给它一段你的摘要，成本更低，目标也更清晰：

“订阅源和 feed 已落库；本迭代只做 XXX；系统启动时加载数据到缓存以加速读取。”

这种“人写的任务脚注”，往往比把几十万 token 的历史硬塞进来更准。例外也存在：如果你刚完成功能实现，准备让 Agent 写文档或补测试，旧上下文依然有价值，延续会话就好。

Rewind 比 PUA 有用：删掉错误的“记忆链”

Claude Code 的 rewind 是我最喜欢的一个小功能。Agent 一旦在当前轨道上连续犯错，靠“语气更严厉的提示”并不能把它拉回来，因为那条错误实现和推理的链条已经写进上下文了。退回到“读完关键文件、但尚未开始实现”的时间点，再发出新指令，等于保留了知识，丢掉了污染物。复杂调试尤其需要这种“时间旅行”。

别等系统自动压缩，主动给方向

长会话快顶满时，系统通常会自动总结一遍，再继续干活。问题在于，这个时机往往已经是信息最嘈杂的时刻，丢的也许正是你后续要用的关键信息。更稳妥的做法是自己触发压缩，并明确告诉模型“摘要服务于什么目标”。例如：

/compact 聚焦阅读模块重构，保留数据同步逻辑。UI 交互与调试日志无需保留。

方向一明确，压缩就不再是“随缘删减”，而是为下一阶段铺路。

子 Agent 是省钱的大杀器：把“高噪声阶段”外包

像“通读代码库找用户认证链路”这类任务，如果在主会话里做，搜索结果、文件片段、命令输出会迅速把 1M 吃空。我的做法是开子 Agent：它拥有一段干净上下文，在里面尽情读文件、试错、跑命令，最后带着一页“压缩后的结论”回到主会话。你要的是路线图，不是旅途所有尘土。

我在团队落地的一些实操细节

• 只传差异：提交大文件时，不要反复贴整文件。用“补丁式提示”传递改动片段，再给模型留一句“其余部分与上轮一致”。
• 日志门禁：管住终端输出。只贴出发生变化的段落，或用 tail -n 200、关键字过滤，把“可复现的噪声”关在门外。
• 摘要有模板：我常用三段式摘要——目标、边界、当前状态。长度控制在 300～600 token，足够让模型建立正确的“世界坐标”。
• 把检索放到上下文之外：建立嵌入索引，让检索发生在工具层，进上下文的是“命中的片段+短注释”，而不是整章整节的文件。
• 设置会话 TTL：给长会话一个“生命期”。超时必须 compact 或重开，避免老问题的残影继续影响新目标。
• 利用供应商的缓存机制：支持提示缓存的服务里，把“稳定不变的系统提示和项目常识”拆成独立消息，少改动，触发缓存命中就省下大头开销。
• 预算护栏：为每个任务设定“预期 Token 区间”和“硬性上限”。到阈值自动提醒你 compact、分叉或中止，别等额度页变红才想起来。

什么时候坚持 1M，什么时候刻意变“短记忆”

有时确实该用满 1M。比如连续重构、需要回看多轮失败路径、或者跨越多模块的协议约束，这些都依赖“长记忆的连续性”。但像写一份接口文档、修一个局部 UI、验证一条 SQL 的边界行为，短会话配上好摘要就够了。我的经验数据是：把“高噪声阶段”外包给子 Agent、把“稳定知识”放进缓存、把“阶段目标”写成 300～600 token 的人工摘要后，同等产出下 Token 消耗能降到原本的 40%～65%，而误判率也更低，因为注意力不再被旧日志牵着走。

写在最后

1M 上下文像是给了我们一个巨大的仓库，但仓库越大，越需要管理员。省钱并不是抠字数，而是尊重“工作记忆”的规律：减少无效记忆，清理污染信息，让每一步都有清晰的目标和边界。把会话当成一条条“工程化的冲刺”，该延续就延续，该压缩就压缩，该分叉就分叉。做到这一点，不止钱包更轻松，你和你的 AI 也会更聪明。