Thariq 那篇 Using Claude Code: Session Management & 1M Context 的价值，不只是把几个命令讲明白，而是把一个新问题讲明白了：当上下文窗口从“稀缺资源”变成“相对宽裕资源”之后，真正困难的事情不再是装不装得下，而是下一轮到底该带着什么继续往前走。

这件事表面上像使用技巧，实质上是 runtime 设计。因为每一次继续、清空、压缩、回滚、分叉、委托，都在重写 Agent 的“短期记忆边界”。谁拥有这层边界的定义权，谁就在定义编程 Agent 的实际行为。

Anthropic 在官方 best practices 里直接写得很明白：长会话里无关的对话、文件内容和命令会降低表现，因此应该在不同任务之间频繁使用 /clear，而不是默认一直往下续。
SECTION 01

为什么 1M context 没让 session management 过时

很多人第一次听到 1M context，会自然得出一个直觉：既然窗口更大了，那以后是不是少开新会话、少做摘要、少折腾上下文管理就行了？Thariq 的文章和 Anthropic 官方文档给出的答案都是否定的。

Anthropic 在 Claude Code Best Practices 里明确写道，长 session 会不断积累无关的对话、文件和命令，这些内容会降低模型表现，因此应该在不同任务之间频繁使用 /clear。同一页还建议，在接近上下文上限时主动 /compact，必要时用 /rewind 从某个节点开始 “Summarize from here”。

这其实说明了一件很关键的事：更大的上下文只是延后了爆炸点，没有消灭“状态污染”本身。窗口更宽，只意味着你有更长的操作时间去做主动整理，而不是你可以无限堆积历史。

Anthropic 在 Context Windows 文档里也把这个逻辑说得更系统：对于长对话和 agentic workflow，server-side compaction 是主要的上下文管理策略。这句话很重要，因为它代表 Anthropic 自己也不把“大窗口”视为终极答案，而是把压缩和编辑视为产品设计的一部分。

长上下文真正改变的，不是需求，而是时机

Thariq 的观察尤其有启发性。他提到，1M context 给了你更多“主动 compact”的时间窗口，因此你可以在模型还比较清醒的时候，先告诉它接下来要往哪个方向走，再做压缩。这和自动触发 compaction 的被动状态完全不同。

所以 1M 的真正价值不是“再也不用管理上下文”，而是“终于可以把上下文管理从应急行为变成前置行为”。

SECTION 02

Claude Code 把 session 做成了一级系统对象

如果你去看 How Claude Code works，会发现 Anthropic 对 session 的定义远比一般聊天产品重得多。官方文档写得很清楚：每条消息、每次 tool use、每个结果，都会被写入 ~/.claude/projects/ 下的明文 JSONL 文件，这使得 Claude Code 可以做 rewind、resume 和 fork；在 Claude 改文件前，还会先保存受影响文件的快照，用于后续回退。

这意味着 session 在 Claude Code 里不是一串 UI 里的对话气泡，而是一份可操作、可分叉、可恢复、可和文件状态绑定的运行时记录。Anthropic 不是把“聊天历史”附带存一下，而是在把“会话状态”做成产品对象。

对象普通聊天产品Claude Code 的做法
对话历史主要用于展示和继续聊天用于 rewind、resume、fork，直接参与运行时控制
代码改动通常依赖外部 git修改前先做文件快照，支持 checkpoint 式回滚
任务切换主要靠用户自己开新对话通过 /clear、/resume、/rewind 等命令显式管理
代理隔离大多仍在同一主线程里堆上下文subagent 使用独立上下文窗口和独立权限

一旦你接受“session 是一级对象”这个前提，很多 Claude Code 看上去零散的功能就会突然连起来。它们不是一堆方便命令，而是一整套 session lifecycle API。

SECTION 03

/clear、/compact、/rewind 到底在重写什么

这三个命令最容易被当成“差不多的上下文整理手段”，但它们实际重写的是三种完全不同的状态。

操作谁来裁剪状态保留什么损失什么最适合的场景
继续 continue没人裁剪完整历史继续叠加最容易引入无关噪音任务仍然连续、前文仍高度相关
/clear人你手写的 brief 和真正需要的边界条件需要重新读文件，成本更高切换到新任务，或已被失败路径污染
/compact模型模型认为重要的代码模式、文件状态、关键决策有损摘要，可能丢掉下一步真正需要的细节任务连续，但历史太重，且方向可预期
/rewind人选分叉点，模型重走后续分叉点之前的上下文分叉点之后的历史会被丢弃某条修复路径失败，想从更干净的位置重试

Anthropic 在 best practices 里甚至直接给出判断：如果你在同一个问题上已经纠正 Claude 超过两次，说明上下文里已经堆满失败尝试，这时往往应该 /clear，而不是继续往下纠偏。

这背后其实对应三种“状态主权”。/clear 是人类主导的状态重建，/compact 是模型主导的有损压缩，/rewind 则是对时间线的分叉回滚。

Anthropic 官方文档对 /rewind 的定义很关键：你可以从某个检查点恢复对话和代码，也可以只恢复对话而保留当前代码。这种设计说明它处理的不是单一文本上下文，而是“会话状态 + 工作区状态”的组合体。

为什么 bad compact 往往发生在最糟糕的时候

Thariq 提到一个很锋利的观察：当 auto-compact 在一段很长的 debugging session 尾部触发时，模型可能已经进入“上下文腐化”最严重的阶段，而你下一步却想转向另一个支线问题。此时模型会把刚才的主线总结得很好，却把接下来真正需要的旁支信息丢掉。

这正说明 /compact 本质上不是记忆术，而是预测术。它不是把全部东西无损打包，而是在猜“什么最重要”。当下一步方向难以预测时，它就会失手。

SECTION 04

Subagent 暴露的是 fresh context isolation

Anthropic 在 Sub-agents 文档里对 subagent 的定义非常直接：当某个旁路任务会用搜索结果、日志或大量文件内容淹没主会话，而且这些中间材料之后不再需要时，就应该把它丢给 subagent，在独立上下文里处理，只把结论带回来。

更重要的是，官方把 subagent 描述成拥有 自己的 context window、自定义 system prompt、特定工具权限和独立权限边界。这不是“同一个大脑开个线程”，而是一种上下文隔离原语。

Anthropic 官方博客 Enabling Claude Code to work more autonomously 也把这件事说得更彻底：checkpoints 和 subagents、hooks、background tasks 放在一起，构成了“更自主工作”的核心能力。其中对 subagents 的描述是，它们可以把某些任务委托出去，比如主 agent 做前端时，让 subagent 去搭后端 API，从而形成并行开发工作流。

这段官方表述非常关键。它说明 subagent 的意义不只是“并行”，而是“把会污染主线程的工作丢进隔离上下文里，再用摘要结果回接”。这本质上是 runtime 层的内存治理，而不是提示词技巧。

Resume subagent 进一步暴露了层级状态机

Anthropic 还在文档里写明：每次 subagent 调用都会创建一个 fresh context 的新实例，但也可以显式 resume 现有 subagent，恢复它完整的历史、工具调用结果和推理脉络。也就是说，subagent 不是一次性函数，而是可暂停、可继续的子会话。

当主会话和子会话都可以被保存、恢复、分叉和压缩时，Claude Code 实际上已经相当接近一个“会话树运行时”了。

SECTION 05

长上下文时代，护城河正在转向 runtime

如果只看营销口径，大家会觉得近一年的竞争是“谁上下文更长，谁工具更多，谁模型更会写代码”。但从官方文档的实际暴露来看，真正逐步显性的竞争点已经变成了 runtime 能力：状态持久化、压缩策略、分叉回滚、上下文隔离、并行代理、权限边界，以及这些能力如何共同构成长程任务的稳定性。

Anthropic 的 Long context tips 里甚至给出一个很反直觉但很工程化的建议：在 20k+ token 的长输入场景下，把长文档放在提示最上方、把 query 放在结尾，复杂多文档任务里这样做最高可带来约 30% 的响应质量改善。这个建议本身就说明，即便模型窗口已经很大，上下文结构化 依然强烈影响结果。

换句话说，大 context 不是免维护内存，它更像一块更大的 RAM。你依然需要调度、分页、压缩、回滚和隔离。Anthropic 只是把这些原本藏在系统里面的内存管理动作，变成了用户可控的显式接口。

为什么这也是行业共同方向

OpenAI 的 Codex CLI 最近也在官方文档里强化了 session 概念。根据 Codex CLI Features，你可以从 ~/.codex/sessions/ 找到历史 session，并通过 codex resume 或 codex exec resume 恢复；恢复后的 run 会保留原 transcript、plan history 和 approvals。它说明另一家头部玩家也在把“session 持久化与恢复”做成一等能力。

但 Anthropic 更激进的一点在于，它不只提供 resume，还把 /clear、/compact、/rewind、checkpoint 和 subagent 全部暴露给用户，等于直接把 session surgery 变成了交互主面板的一部分。

因此下一阶段更值得追踪的问题，不是“谁先到 2M context”，而是“谁能提供更可靠的 session runtime，让 Agent 在长程开发里持续保持方向感”。

SECTION 06

产品信号，Anthropic 正在把 session runtime 工程化

如果说前面几节更多还是从功能表面来推断 runtime 方向，那么 Anthropic 自己的 changelog 和 hooks 文档，其实已经把这个方向说得更明了。它不是把 session 管理当成“高级用户技巧”，而是在持续把这层能力做成显式可编排的工程接口。

第一类信号，修复项本身已经围绕 session 生命周期展开

Anthropic 的官方 changelog 里，已经连续出现和长会话治理直接相关的修复。比如它专门修过 autocompact thrash loop，也就是刚压缩完马上又被塞爆、连续触发 compaction 的死循环，后来改成三次后停止并给出可执行错误提示。这个修复很说明问题，因为它处理的不是模型回答质量，而是 runtime 的状态管理失稳。

同一份 changelog 里还出现过两类非常有代表性的修复：一类是 “Fork conversation from here” 和 rewind 在 session cache 失效后静默失败，另一类是 /clear 会错误杀死后台 agent/bash tasks，后来改成只清前台。把这些修复放在一起看，会发现 Anthropic 其实在修一整台“会话机器”的状态边界，而不是只修聊天框。

第二类信号，官方开始教你在 compaction 之后重新注入状态

更硬的一点来自 hooks 文档。Anthropic 现在已经明确提供一种工作流：当上下文被压缩后，可以通过 SessionStart hook 匹配 compact 场景，把关键项目约定、最近工作摘要或长期规则重新注入 Claude 的新上下文。官方甚至明确说明，hook 输出到 stdout 的文本会重新进入 Claude 的上下文。

这很关键，因为它意味着 Anthropic 已经默认承认 compaction 会丢细节，而“压缩后怎么恢复关键状态”不再是用户自己的野路子 hack，而是官方文档认可的 runtime 设计模式。

一旦连“compact 之后如何回填关键记忆”都成为官方推荐动作，Claude Code 的本质就更像一个可扩展的会话操作系统，而不是一次性问答工具。

第三类信号，session management 正在从 UI 操作变成可组合接口

社区已经开始要求 Anthropic 把 session rename、list、resume 进一步开放成工具接口，背后的原因也很直白：有了 1M context 之后，会话本身越来越像长期工作单元，用户希望按名称回到它、自动化管理它、把它作为工作流节点编排它。

也就是说，session 不再只是“正在聊天的地方”，而是在变成“正在运行的任务容器”。这也是 runtime 化最重要的产品信号之一。

SECTION 07

现实摩擦，1M context 仍然不是稳定真相

如果只读官方叙事，你可能会以为 1M context 已经把长程工作的大部分问题解决了。但 GitHub issues 里正在持续冒出来的高信号反馈，恰好说明另一面：“宣称支持 1M” 和 “稳定跑出 1M 工作流” 之间，还有一段不小的工程距离。

第一类摩擦，名义 1M，实际工作流仍可能卡在 200K 级别

在 issue #34158 里，用户报告 /context 明明显示的是 1M 模型，但实际在大约 197K token 时就触发了 “Context limit reached”。另一条 issue #46372 则描述了一个更微妙的问题：用户在 1M 会话中切到 Haiku、中途取消 compaction 后，effective window 卡死在 200K，重启之后仍未恢复。

这些问题未必代表产品整体不可用，但它们足以说明一件事：长上下文能力不是一条静态模型参数，而是一整套会话、模型切换、压缩逻辑、状态同步共同维持的系统行为。

第二类摩擦，auto-compaction 的时机仍远未被完全驯服

issue #42590 直接把问题说得很尖锐：在 1M 窗口下，自动 compaction 仍可能过早触发，而且压缩过猛，导致“关键时刻丢掉约 90% 信息”。这和 Thariq 文里关于 bad compact 的观察高度对齐，区别只是这里变成了真实线上用户的损伤报告。

另一条 issue #39149 则进一步提出，既然 Claude 最清楚当前上下文噪音和阶段转换，为什么不能让 Claude 自己程序化触发 /compact？这个提议本身就说明，用户已经不满足于手工上下文治理，而是在要求 runtime 具备更强的自我调度能力。

第三类摩擦，用户感知与产品解释之间还有断层

还有一类高信号反馈并不是单点 bug，而是“为什么我感知不到 context quality 正在恶化”。有人在 issue 里明确提出，应该暴露实时 context quality 指标和更早的预警，因为在当前产品形态下，模型即便已经开始检索漂移或压缩过度，用户看到的表面自信度可能并不会同步下降。

从系统设计角度看，这其实很像操作系统里“内存压力可视化”的缺失。不是用户不想管理，而是他缺少一个足够好的状态面板来判断什么时候该 clear、该 compact、该 rewind、该换子代理。

所以真正的研究结论不是“Claude Code 没做到 1M”。
更准确的说法是：Claude Code 已经把 session runtime 这层产品形态做出来了，但 1M context 这件事越往真实工作流里走，就越暴露出 runtime 设计还有很多要继续打磨的细部。
SECTION 08

边界、反例与工程启示

第一，不能把 bad compact 全部归咎给模型笨

很多 bad compact 并不是模型真的不会总结，而是用户自己在错误的时间点切换了任务目标。压缩永远是有损的，当你的下一步方向没有提前被明确写入摘要目标时，模型很难猜对你真正要保留什么。

第二，/clear 也不是越频繁越好

官方虽然建议在不同任务之间频繁清空，但在“实现完功能马上写文档”“刚读过一批文件接着做相邻的小修复”这类场景里，重新读文件的成本可能大于污染成本。真正重要的不是教条地勤开新会话，而是判断“旧上下文里有多少仍然高价值”。

第三，subagent 不适合所有任务

如果你后续还要频繁引用 subagent 过程中的原始工具输出、排障过程、精确文件路径和中间判断，那么把它压成摘要带回来，反而可能让主会话丢失关键证据。subagent 最适合“我只需要结论，不需要过程噪音”的工作。

第四，checkpoint 不是版本控制的替代品

Anthropic 官方博客明确提醒，checkpoints 主要覆盖 Claude 自己的编辑，不覆盖用户编辑或 bash 命令，因此它们应该和版本控制一起用，而不是替代版本控制。

第五，Codex 与 Claude Code 的差异，开始不在“有没有 session”而在“session 暴露得有多深”

Codex CLI 也已经把 session resume 做成一等能力，这说明行业共识正在形成。但 Anthropic 更进一步的地方，是把 clear、compact、rewind、checkpoint、subagent、hooks 这整组和 session surgery 相关的动作都暴露给用户，让你直接管理生命周期，而不是只在历史记录上做恢复。

对工程团队的实际启示是：
1. 给 Agent 设计工作流时，不要只设计 prompt，也要设计 session lifecycle。
2. 把“什么时候 clear、什么时候 compact、什么时候 rewind、什么时候 spawn subagent”写进团队操作规范。
3. 如果是高价值长程任务，最好再加一层 hook / memory reinjection 机制，不要把 compaction 之后的状态恢复完全赌给模型自己。
4. 长程 Agent 的核心可靠性，不再只来自更强模型，而来自更好的状态治理。

结论

Thariq 这篇文章最值得深挖的地方，并不是它教你几个 Claude Code 命令，而是它无意中把一个行业趋势讲漏了出来：编程智能体的真正竞争，正在从“谁更像会聊天的模型”转向“谁更像有状态管理能力的运行时系统”。

而当你把 changelog、hooks、issue 和竞品 session 设计放在一起看，这个结论会更清楚：1M context 只是入口，session runtime 才是核心产品层。

Sources

参考来源

Appendix

参考与延伸

文章信息

2026-04-16 · 22 分钟阅读

研究 · AI 编程智能体

主题标签

Claude Code · Anthropic · Context Engineering · Session Runtime · Subagent · Checkpointing · Codex