1M 上下文不是终点：Anthropic 正在把 Claude Code 变成"上下文操作系统"

Claude Code 团队的 Thariq 写了一篇《Using Claude Code: Session Management & 1M Context》，从一个很具体的功能更新——/usage 命令——讲起，展开讨论了 1M 上下文窗口下的会话管理策略。

说实话，一开始我是当操作手册来翻的。什么时候 compact，什么时候 clear，什么时候交给 subAgent——用了这么久 Claude Code，或多或少有点自己的习惯。

但读到后面，有个地方让我多想了一会儿。

不是某个命令用法，而是文章整体说的比较有意思的一个点：

长任务跑到后面，卡住它的往往不是窗口不够大，而是留在窗口里的东西开始帮倒忙。

过去两年聊长上下文，好像都在比数字

过去两年，长上下文几乎成了 AI 产品的标配卖点。200k、1M、2M、4M……大家聊起来，第一反应也是先比数字。

默认的叙事逻辑也很自然：窗口越大，能塞进去的信息越多，长任务就能跑得更稳。

这当然不算错。Anthropic 自己也在博客里确认：1M 窗口让 Claude Code 确实能更可靠地处理更长的任务，比如从零搭一个全栈应用。

但同一篇文章里，紧跟着就说了另一件事：

随着上下文增长，模型性能会下降——注意力被更多 token 摊薄，旧的无关内容开始干扰当前任务。他们管这个叫 context rot。

Thariq 后来在推特帖串里还补了一个更具体的经验范围：对于 1M 上下文模型，context rot 往往在大约 300k–400k tokens 左右开始变得明显。不过他也强调，这高度依赖具体任务，不能当成硬阈值。

这两层信息放在一起看，我理解 Anthropic 想说的大概是这么一件事：

如果把这段变化压成一张图，大概会更清楚：

窗口变大先解决“能不能装下”，然后把问题推向“留下来的内容还在不在帮忙”。

窗口变大是好事，但不会自动解决状态管理问题。"能装进去"和"装进去之后还好使"，是两件事。

上下文里装的，不只是聊天记录

在聊具体策略之前，可能有个前提值得先对齐一下。

Claude Code 的上下文窗口里到底装了什么？

很多人的直觉是"对话记录"。但官方定义得很清楚：它包含 system prompt、CLAUDE.md 配置文件、到当前为止的整个对话历史、每一次工具调用及其返回结果，以及读过的每一个文件。

官方的这张结构图把这件事画得很直观：

上下文窗口里不只有你说了什么，还有整段任务执行过程留下来的状态。右边的 "free" 是剩余可用空间，最右侧橙色线是 1M 硬上限。

图里有个细节值得注意：tool calls + outputs 和 files read 各自占了一大块。也就是说，模型消耗掉的上下文容量，很大程度并不来自你打的那些字，而来自任务执行本身不断产生的中间态。

所以，把上下文理解成一个装文本的静态容器，会有点失真。

更贴切的理解是：它是一段正在运行的工作记忆——会随着任务推进不断变重，也会随着路径分叉不断变杂。

这个视角其实不新。之前写《深入解析 OpenClaw 上下文窗口压缩：三层治理、配对修复与溢出恢复》的时候就聊过，会话里塞进来的不只是聊天记录，还有工具调用结果、文件读取内容、失败日志……你真把这些东西一股脑丢给模型做摘要，最容易丢的往往正是不能丢的部分。再往前追，《2026 AI Memory 最新综述》里也说得很直接：memory is a cornerstone of cognitive capability——没有记忆，Agent 就只是一个更贵的一次性工具。

而且上下文窗口是 hard cutoff。快到边界时，系统会把当前任务自动总结成一段更短的描述，再在新的窗口里继续推进。这就是 compaction（压缩）。

窗口越用越满，注意力越用越散。到达上限时，系统会自动做一次 compact：把历史压缩成摘要，在新窗口里继续。

之前在《Claude Code 长任务为什么不容易跑偏：从压缩、记忆到续写的 Runtime 设计》里，我顺着源码看过 Claude Code 的压缩机制是怎么一层层搭起来的——microcompact、autocompact、reactiveCompact 那一套。当时更多是从代码层面去拆它怎么做的。

今天 Anthropic 自己发这篇博客，等于从产品层面把"为什么要做这些"说了出来，对上了，都对上了。

但是， 如果，把这两层放一起看，问题的性质就变了：

窗口变大，当然意味着能装下更长的任务链路。但与此同时，旧的工具输出、失败的尝试、早就不再相关的文件内容——这些东西也会跟着一起堆在工作记忆里，越来越重。

问题不只是"装不装得下"，而是"留下来的东西，还在帮忙吗"。

每一轮结束后，都是一个五路决策点

官方文章里有一句话我印象很深：

当 Claude 完成一轮输出、你准备发送下一条消息时，你面前其实有非常多的选择。

乍看好像没什么特别的，但仔细想想还挺有意思——同一个“下一步”，系统默认其实给了五种不同的处理方式。

看下面这个图，会比较清晰：

同一个“下一步”，其实有五种默认动作：继续保留、切掉错误尾巴、带 brief 重开、让模型压缩，或者把支线隔离出去。

简单对照一下：

翻过来看，这五种动作本质上在处理同一件事：保留信息、丢弃信息、还是隔离信息。

大多数人（包括之前的我）95% 的时间只会做一个动作：Continue。

这当然没有大问题——如果你的任务本来就短，或者上下文还很干净的话。但一旦任务变长，不加选择地一路 Continue 下去，那些旧路径、旧工具输出、旧的半成品想法，就会悄悄把工作记忆填满。

官方还给了一个朴素但实用的经验法则：

当你开始一个新任务时，通常也该开始一个新会话。

当然也有灰区。比如刚写完一个功能紧接着要写文档——这种高度关联且对"智力敏感度"要求不那么高的任务，沿用已有上下文反而更划算，省去重新读文件的时间和费用。

所以也不是说一定要清，更多是想一下：这一步到底还需要多少历史。

容易被忽略的 /rewind

五个动作里面，我个人觉得最容易被忽略的是 /rewind。

它就是那个很多人知道但未必真当回事的快捷键：双击 Esc。

为什么这么说呢？因为它背后藏着一个平时不太容易注意到的问题：

错误路径不只是"答错了一次"那么简单——它会沉淀成状态，持续影响后续推理。

正如文章提到的：Claude 读了五个文件，尝试了方案 A，没走通。你的本能反应大概是继续在对话里补一句："那条路不行，换 X 试试。"

但更好的做法是：rewind 到"文件刚读完、错误尝试还没发生"的那个节点，再带着新认知重新下指令——"别用 A，foo 模块没暴露那个接口，直接走 B"。

上面是纠正（correcting）：失败尝试还留在上下文里。下面是回溯（rewinding）：失败尝试被整段移出，上下文只保留读文件 + 一条更精准的指令 + 正确结果。

这两种做法看起来只差一步操作，但对上下文的影响完全不同。

继续纠正，相当于在一个已经被错误路径污染过的状态上打补丁。而 rewind，是把那段错误路径从工作记忆里整个移走。

如果用传统工程的语言来说，这就是 rollback to checkpoint。

而且，长任务里之所以容易越跑越偏，很多时候并不是模型"变笨了"，而是那些中间态——废弃的尝试、没走通的分支、中途读到但后来没用上的文件内容——一直留在上下文里，悄悄地把注意力拽向错误方向。

所以 /rewind 的价值，不只是"撤回一句话"。

它更像是在必要的时候，让系统退回到一个更干净的起跑点。

顺便提一个容易被忽略的小功能："summarize from here"。

rewind 之后，你可以让 Claude 把刚才那轮试错学到的东西总结成一段交接信息。这就像"未来的 Claude"给"过去的 Claude"留了张便条：这条路我走过了，行不通，原因是……

Compact 和 /clear 很像，但它们不是一回事

这篇文章还有一个地方我觉得特别值得单独拎出来说：compact 和 /clear 的区别。

因为在日常讨论里，很多人会把这两个动作混着用。觉得都是"减负嘛，差不多"。

但它们背后其实是两种完全不同的决策逻辑。

左边是一段已经很长的会话。/compact 让模型写摘要后继续推进；/clear 则是你自己写一份关键信息的 brief，在全新会话里重开。

Compact：让模型总结当前会话，用摘要替换掉冗长的历史记录。好处是省事，而且你可以通过指令引导方向（比如 /compact 重点保留 auth 重构，丢掉 test debugging 那段）。

但它有个绕不过去的问题——这是有损压缩，决定"什么该留什么该扔"的是模型。

而且官方自己还说了一句挺扎心的话：

受 context rot 的影响，模型在做 compact 的那一刻，往往恰好处于它最不聪明的时候。

也就是说，模型被长历史拖了这么久、注意力已经在发散了，这时候让它来判断“什么最重要”——多少有点让人不放心。之前写《如何让单个 Agent 做长任务不失真》时，Anthropic 自己就把这个问题叫做 context anxiety——模型越担心丢东西，压缩时就越倾向于什么都留，结果反而稀释了真正重要的信息。

官方举的 bad autocompact 例子也很典型：调了半天 Bug，自动压缩之后，另一个顺手发现但还没来得及处理的 warning，可能就被当成无关信息一起丢掉了。等你下一轮想回头修那个 warning——抱歉，系统已经接不上了。

/clear 的逻辑正好反过来。

你自己写下关键事实、当前约束、已排除的方案、需要关注的文件，带着这份 hand-written brief 重开一个干净会话。

更费劲，但新上下文里的每一个字都是你确认过的。

一句话总结它们的区别：

• • Compact = 委托模型做一次有损的状态蒸馏
• • /clear = 由你来做一次精确的边界重建

选哪个？看场景。

如果接下来的任务风险不高、你只是想保持推进节奏，compact 省力好用。

如果下一步是高风险改动，或者你在大量探索中只抓到了一两条关键结论需要带走——那 /clear 更稳。

因为这时候更重要的，是让新的工作记忆里只剩下真正承重的信息。

Subagent 最值得关注的，不是并行，而是隔离

很多人看到 subagent，第一反应是"可以多线程干活了"。

这没错，但如果只停在并行这一层，会错过它更有价值的那一面。

官方对 subagent 的核心描述是这样的：当你预知某段工作会产生大量以后不再需要的中间输出，就应该考虑把它交给一个独立上下文去处理，最后只把结论带回主线程。

主线程（左边）只收到一份精炼的 final report；子线程里的 20 次文件读取、12 次搜索、3 条死胡同——全部随着子上下文退出而丢弃。

这里面最关键的不是"多开了一个 Claude"，而是 "独立上下文" 这四个字。

它意味着：子任务执行过程中产生的所有中间噪音——文件读取、工具调用、失败尝试——都不会回灌到主线程的工作记忆里。

原文给了几个我觉得特别实用的场景：

• • "派个 subagent 去，根据 spec 文件验证刚才的工作对不对"
• • "派个 subagent 去读另一个代码库，总结它的 auth flow 是怎么做的，然后你自己照着实现"
• • "派个 subagent 根据 git 改动写文档"

这些任务有个共同点：主线程要的不是全部过程，只是结论。

判断要不要用 subagent，官方给了一个很朴素的标准：

以后我还需要这些工具的原始输出吗，还是只要结论？

如果答案是后者，那就很适合交给 subagent。

从这个角度看，subagent 其实解决的不是"算力不够"的问题，而是"支线噪音如何不污染主线" 的问题。

这让我想起之前写《Anthropic 的 Harness，已经进入新阶段：只用三招，开始从“补”转向“删”》时聊的那个问题：Harness 不只是往上加东西，也得知道什么时候该做减法。

今天这篇博客刚好把同一件事落到了会话层——哪些上下文还在承重，哪些其实已经是 dead weight，该用什么动作清理掉。

多想了几步

写到这里，跳出具体命令，聊聊读完之后我自己的一点感受，不一定对。

第一，长上下文这件事，可能正在从“比谁大”慢慢变成“比谁管得好”。

Anthropic 没有否定 1M 窗口的价值，但这篇文章从头到尾都在说另一面：光有容量不够，还得有配套的管理手段。

第二，越看越觉得，这些问题好像都不新鲜。

我读的时候忍不住做了个类比，不知道大家会不会有同感：

看完这张表我的感觉是，Agent 系统好像没有跳出软件工程的老问题，反而又绕回来了。之前在《模型差距在缩小，Harness 差距在放大》里拆 Coding Agent 的 6 个关键模块时，"上下文管理"就已经单独占了一层；再到《你的AI-First对了吗? 让我们一起看看你的软件工程成熟度》里聊到的那条工程闭环，核心问题其实一直都是同一个：模型外面那层系统怎么搭。今天这篇，只不过是把镜头推到了会话内部。再往前追，《别把 Prompt Cache 只当优化技巧：它背后其实是 Agent 的架构纪律》里聊的就是同一件事——Agent 真正贵的，是反复重算上下文，而不是模型调用本身。

第三，AI 编程工具接下来比什么？也许不只是写代码了。

这次 Anthropic 给出的五个分支动作——继续、回滚、压缩、清空、隔离——说是聊天命令，但用起来越来越像一组围绕上下文状态的操作系统动作。

我自己有个不太成熟的猜测：以后 AI IDE 之间拉开差距的地方，可能不只在“谁能生成更好的代码”，也会在谁能把 session branching、rewind、compaction、subagent isolation 这些东西做得更顺手——说白了，就是谁能让开发者更省心地维护一份干净的工作记忆。

一张可以直接用的小抄

最后，如果想把这篇文章的操作建议浓缩成一张日常速查表，我会这么记：

当然，这不是一张死表。真正要看的，还是当前这段历史到底还在不在承重。

说到底，这篇博客让我印象最深的，不是哪个命令怎么用，而是 Anthropic 把一个很多人用久了多少会有体感、但平时不太会认真想的问题，正式拿出来聊了：

长任务跑不好，瓶颈可能不在模型多强、窗口多大，而在于这份工作记忆有没有被好好打理。

也不知道这个判断对不对，但至少从我自己的使用体验来说，挺有共鸣的。