---
title: "harness技术手册-会话管理与百万级上下文实战启示"
source: wechat
url: https://mp.weixin.qq.com/s/y5ZfnqadTpDaG9cVQcU3Ig
ingest_date: 2026-07-04
vxc: 56
stars: 4
sha256: 21ee45084b3f7b2ef4ab3c677f0cc66898586492c2bc8079cd4a98e23658efcd
---

# 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 的协作不是线性的，而是在每个回合都面临着路径选择。这种分支结构要求使用者保持对工作状态的双重觉知——既关注任务本身的进展，也关注承载任务的上下文环境。

## 何时开启新会话

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

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

灰色地带在于执行相关任务时，部分上下文仍然必要，但并非全部。

例如，为刚实现的功能编写文档。虽然可以开启新会话，但 Claude 将不得不重新读取刚刚实现的文件，这会降低效率并增加成本。由于文档编写可能不是高智力敏感任务，额外的上下文开销或许值得换取无需重新读取相关文件的效率收益。

这里的权衡涉及到一个关键变量：上下文中信息的"复用价值"。如果后续任务高度依赖前序工作的认知成果，保持会话连续性是合理的；反之，如果任务切换意味着认知上下文的彻底转换，开启新会话能够避免旧信息对新任务的干扰。

## 回滚而非纠正

如果必须选择一个最能体现良好上下文管理的习惯，那就是回滚。

在 Claude Code 中，双击 Esc（或运行 /rewind）可以跳转回任意历史消息，并从该点重新提示。该点之后的消息将从上下文中移除。

回滚通常是比直接纠正更好的方法。例如，Claude 读取了五个文件，尝试某种方案，但未成功。直觉反应可能是输入"这不起作用，试试 X 方法"，但更优策略是回滚到文件读取之后，用已获得的认知重新提示："不要用方案 A，foo 模块没有暴露该接口——直接用方案 B。"

还可以使用"从此处总结"（summarize from here）功能，让 Claude 总结其学习成果并创建交接消息——就像来自已尝试某方案但未成功的"未来版本"的自己，给当前自己的一封交接信。

回滚机制的价值在于它允许"撤销"AI 的错误探索路径，而不仅仅是在错误路径上继续修补。这种能力反映了一个重要的设计原则：当 AI 的探索失败时，最优策略往往不是纠正错误，而是回到分叉点重新选择方向。

## 压缩与全新会话的对比

当会话变得冗长时，有两种减重方式：/compact 或 /clear（重新开始）。它们感觉相似，但行为截然不同。

压缩 让模型总结迄今为止的对话，然后用该摘要替换历史记录。这种方式存在信息丢失——需要信任 Claude 来判断什么是重要的，但优势在于无需亲自编写任何内容，且 Claude 可能更彻底地纳入重要学习成果或文件。可以通过传递指令来引导压缩方向（例如 /compact 关注 auth 重构，省略测试调试部分）。

清空 则由用户亲手写下什么重要（"我们正在重构 auth 中间件，约束条件是 X，关键文件是 A 和 B，已排除方案 Y"），然后从零开始。这需要更多工作，但生成的上下文完全由用户决定为相关内容。

两者的选择反映了一个更深层的张力：自动化与控制的权衡。压缩将判断权委托给 AI，节省了用户的认知精力，但可能丢失关键细节；清空保留完全控制，但需要用户投入时间进行总结。在长会话管理中，这种权衡会反复出现，没有普适的答案，只有基于具体情境的选择。

## 导致糟糕压缩的原因

如果经常运行长会话，可能遇到过压缩效果特别差的情况。糟糕的压缩通常发生在模型无法预测工作走向时。

例如，在一次漫长的调试会话后自动压缩触发，模型总结了调查过程，但用户的下一条消息是"现在修复我们在 bar.ts 中看到的另一个警告"。

由于会话焦点一直是调试，另一个警告可能已被从摘要中剔除。

这种情况尤为棘手，因为由于上下文旋转，模型在压缩时的智能程度处于最低点。借助百万级上下文，用户拥有更多时间主动使用 /compact，并附带对后续工作方向的描述。

这里的核心问题在于压缩是一个"向后看"的操作——它总结已经完成的工作，但无法预测未来的需求。解决这一困境的策略是"前瞻性压缩"：在压缩指令中明确说明后续工作方向，让模型在总结时有所侧重。这种主动引导能够在一定程度上弥补压缩的短视缺陷。

## 子代理与 Fresh 上下文窗口

子代理是上下文管理的一种形式，适用于预先知晓某个工作块将产生大量不再需要的中间输出的场景。

当 Claude 通过 Agent 工具调用生成子代理时，该子代理获得自己全新的上下文窗口。它可以执行任意复杂的工作，然后综合其结果，仅将最终报告返回给父会话。

判断标准可以是：是否需要再次使用该工具输出，还是只需要结论？

虽然 Claude Code 会自动调用子代理，但用户可能希望明确指示其执行此类操作。例如：

- • "启动一个子代理，根据以下规范文件验证此项工作结果"

- • "启动一个子代理，通读另一个代码库，总结其 auth 流程的实现方式，然后以相同方式自行实现"

- • "启动一个子代理，基于我的 git 变更为此功能编写文档"

子代理机制揭示了一个有趣的架构模式：通过创建临时的工作记忆空间，将复杂的中间过程与主上下文隔离，仅返回精炼的结论。这种模式在软件工程中有诸多对应——事务隔离、沙箱执行、函数作用域——都是通过边界来控制复杂性的经典策略。

## 延伸：上下文管理的元技能

上下文管理本质上是与 AI 协作的元技能——关于如何思考的思考。百万级上下文窗口改变了博弈规则，但并未消除对战略思维的需求。

关键洞察在于：上下文不是越大约好，而是越相关越好。

一个常见的误区是认为更大的上下文总是更优。实际上，当无关信息占据注意力空间时，模型的表现反而下降。这与人类认知有相似之处——工作记忆容量有限，需要不断将信息编码到长期记忆并释放认知空间。

策略建议包括：预防性压缩，不要等到上下文旋转让模型变"笨"才压缩，而是主动在关键节点进行有方向性的压缩；分层会话结构，将大型项目分解为多个主题明确的子会话，每个会话聚焦一个相对独立的工作单元；子代理边界，对于会产生大量中间状态但结论简洁的任务，优先使用子代理。

当模型变得更强大时，上下文管理的复杂性不会消失，而是会转移——从"如何让模型理解我的任务"转向"如何在庞大上下文中保持战略清晰度"。这种转移意味着使用者的角色从任务执行者逐渐演化为任务架构师，负责设计 AI 执行工作的环境和边界条件。

## 总结

当 Claude 完成一轮工作并准备接收新消息时，面临着一个决策点。

随着时间推移，Claude 自身可能会更好地协助处理这些决策，但目前，这些仍然是用户引导 Claude 输出的关键方式。

理解并掌握这些会话管理策略，将显著提升使用 Claude Code 的效率与工作质量。