harness技术手册-会话管理与百万级上下文实战启示¶

Ch01.1069 harness技术手册-会话管理与百万级上下文实战启示¶

📊 Level ⭐⭐ | 5.9KB | entities/harness技术手册-会话管理与百万级上下文实战启示.md

harness技术手册-会话管理与百万级上下文实战启示¶

来源: Unknown

发布日期: 2026-04-17

原文链接: https://mp.weixin.qq.com/s/y5ZfnqadTpDaG9cVQcU3Ig

百万上下文窗口的双面性¶

在与 Claude Code 用户的大量交流中，一个主题反复出现：百万级 token 上下文窗口是一把双刃剑。

一方面，它让 Claude Code 能够更长时间自主运行，更可靠地处理复杂任务。另一方面，如果对上下文管理不够刻意，也为上下文污染打开了大门。

会话管理的重要性前所未有，相关疑问也层出不穷：应该在终端保持一个还是两个会话？每次提示都开启新会话？何时应该使用压缩、回滚或子代理？什么会导致糟糕的压缩结果？

其中隐藏着大量细节，几乎都源自上下文窗口的管理方式，这些因素能够真正塑造使用 Claude Code 的体验。

上下文、压缩与上下文旋转基础¶

上下文窗口是模型在生成下一个响应时能够"看到"的全部内容。它包括系统提示、迄今为止的对话、所有工具调用及其输出，以及所有被读取的文件。Claude Code 的上下文窗口容量为一百万 token。

不幸的是，使用上下文存在轻微成本，通常被称为"上下文旋转"（context rot）。上下文旋转指的是随着上下文增长，模型性能逐渐下降的现象——注意力被分散到更多 token 上，旧的、不相关的内容开始干扰当前任务。对于百万级上下文模型，这种退化通常出现在约 30-40 万 token 区间，但具体阈值高度依赖任务类型，并非固定规则。

上下文窗口存在硬性上限，因此当接近窗口末端时，需要将已完成的任务总结为更精简的描述，然后在新上下文窗口中继续工作，这一过程被称为压缩（compaction）。用户也可以手动触发压缩操作。

从元认知的角度来看，上下文管理本质上是对认知资源的分配——有限的注意力需要在相关信息和历史信息之间进行权衡。这种权衡在 AI 协作中表现为对会话状态的持续评估：哪些信息仍需保留在工作记忆中，哪些可以编码为长期记忆（压缩后的摘要），哪些已经完全无关可以清除。

每个对话回合都是分支决策点¶

假设已经向 Claude Code 发出请求并获得了响应，此时上下文中已积累了一定信息（工具调用、工具输出、指令）。接下来存在多种选择：

• • 继续 （Continue）——在当前会话中发送另一条消息

• • 回滚 （/rewind，或按两次 Esc）——跳转到之前的某条消息，从那里重新开始

• • 清空 （/clear）——开启新会话，通常附带从已有学习提炼的简要说明

• • 压缩 （Compact）——总结当前会话，在摘要基础上继续

• • 子代理 （Subagents）——将下一个工作块委托给拥有独立干净上下文的子代理，仅将结果汇总回主会话

虽然"继续"是最自然的选择，但其他四种选项的存在正是为了帮助管理上下文。这个决策框架揭示了一个深层模式：与 AI 的协作不是线性的，而是在每个回合都面临着路径选择。这种分支结构要求使用者保持对工作状态的双重觉知——既关注任务本身的进展，也关注承载任务的上下文环境。

何时开启新会话¶

新的百万级上下文窗口意味着现在可以更可靠地执行长期任务，例如从零开始构建全栈应用。但这并不意味着不应该开启新会话——即使模型尚未耗尽上下文空间。

经验法则：开启新任务时，同时开启新会话。

灰

→ 原文存档

关联¶

• 相关概念: Harness Engineering