多阶段 Agent 工作流常遇到一个问题：前一阶段已经结束，消息历史仍然带着大量搜索结果、失败命令和废弃路径；下一阶段需要其中的约束，却不需要完整过程。此时应该继续同一会话、做一次 compact、派发子 Agent，还是从 checkpoint 启动新会话？

这个问题不能靠在 messages 数组里寻找某个神奇下标解决。需要设计的是工作状态怎样越过边界，以及边界后的 Agent 怎样证明自己已经恢复到可执行状态。

四种边界经常被混在一起

“会话”在不同产品和讨论里可能指四件事：

边界 它分隔什么 典型操作 主要风险
Context Window 边界 当前一次模型调用可见的工作集 prune、compact、重新装配 关键信息遗漏、摘要失真
Durable Session 边界 可恢复的事件日志或产品会话 resume、fork、clear、新建 session 把持久日志误当成模型当前输入
Work Phase 边界 规划、实现、验证等工作阶段 checkpoint、handoff、验收门 阶段输出没有形成可验证契约
Agent / Role 边界 不同执行者、上下文和权限域 delegate、subagent、独立 evaluator 委托信息不足、结果难以验证

这四种边界可以重合，也可以完全不重合。一次 compact 会改写当前工作集，却仍可能属于同一个产品会话和同一个工作阶段；一个新 Agent 可以接手下一阶段，也可以在同一阶段并行调查；同一会话还可能连续完成多个阶段。

因此，“切不切会话”只是表层操作。真正需要回答的是：

  1. 当前阶段以什么条件结束？
  2. 哪些状态必须保留，哪些内容可以重新获取？
  3. 下一执行者从哪里恢复事实、约束和证据？
  4. 恢复成功由什么检查证明？

Session 不是 Context Window

Anthropic 在 2026 年的 Managed Agents 文章里给出了一组很有用的区分：session 可以是一份追加式、可持久化的事件日志；Harness 决定从中选择和变换哪些事件，装配为模型当前看到的 context；文件、代码和进程则存在 sandbox 中。原文明确提醒，session 并不等于 Claude 的 context window。

把组件拆开后，结构如下：

Session、Context Window 与工作状态

这张图解释了两个容易误判的现象。

第一，创建新 context 不必删除旧 session。持久日志可以继续保留，用于恢复、审计和追溯；Harness 只是不再把全部历史送入当前工作集。Claude Code 的 /clear、/compact 和 session resume 也分别对应不同的状态操作。

第二，单会话并不意味着完整 transcript 永远驻留在窗口里。自动 compaction 可以在同一 durable session 内反复重写 active context。相反，新开 session 也不保证干净：如果恢复包把过期结论和大段日志重新灌入，新窗口仍然会被旧状态污染。

切分需要 Select，不是 Slice

一段 Coding Agent 历史里的信息有效期并不一致：

  • 文件读取结果可能在文件被修改后过期，也可能仍是复现某个判断所需的原始证据。
  • 项目约束可能贯穿整个任务，也可能只适用于某个目录或阶段。
  • 实现决策已经落入代码，但被拒方案及其约束仍可能影响后续修改。
  • 测试日志可以重跑，测试命令、环境和失败样例却需要保留。
  • 临时推理通常不值得长期携带，其中的来源、反例和未决风险仍可能重要。

仍然需要的信息散布在历史各处，无法由一个连续区间表示。会话边界处理的是一项选择问题：

1
2
3
4
5
6
7
下一阶段状态
= 当前仍有效的约束
+ 可定位的 artifact
+ 决策与重审条件
+ 已验证的证据
+ 未完成风险
+ 下一步动作

这也是旧稿里“工具结果用完即失效”和“artifact 完成后推理价值归零”两个判断需要订正的地方。

工具输出能否丢弃，取决于它是否可重复获取、来源是否稳定、关键结论是否已经带着出处写入 durable state。生产故障现场、一次性 API 响应和外部页面快照不能一概清除。

决策落入代码之后，长篇探索轨迹通常可以退出工作集；决策依据却未必失效。架构决策记录之所以保留背景、备选项与后果，是为了让后续维护者知道结论成立的条件，以及何时应当重审。需要压缩的是推理轨迹，不是可追溯的理由。

越过边界的最小状态

一份可恢复的 handoff 至少要覆盖六类内容。

目标和边界

写清本阶段目标、完成状态、下一阶段目标，以及明确不在范围内的事项。只有目标而没有 scope，接手者容易顺手扩张任务。

Artifact 和版本

记录代码、Spec、计划、数据、进度文件的路径与版本。Git 任务应带分支、HEAD、工作区状态和相关提交，而不是只写“代码已经完成”。

决策和负空间

保留当前方案、关键理由、被拒方案和拒绝条件。负空间不需要复制所有讨论，但要足以阻止后续阶段在相同约束下重复走入死路。

证据和验证入口

记录已运行的检查、结果、环境和可重跑命令。长日志可以外置，handoff 保存结论与指针。没有验证入口的“已完成”不能作为可靠状态。

未决风险和权限

写出阻塞项、已知缺口、待确认假设、外部依赖以及新执行者是否拥有继续操作所需的权限。权限变化本身也可能构成必须切换 Agent 的边界。

下一步动作

下一步应当具体到可执行动作和停止条件。模糊的“继续优化”会迫使新 Agent 重新解释整个任务。

Anthropic 的能力演变：Reset 为何先必要，后来又被删除

Anthropic 2025—2026 年两代长程 Agent Harness 实验，为会话边界提供了一个很有价值的反例：reset 的效果不是固定属性，它取决于模型行为、上下文策略和外部状态协议的组合。

早期 Harness：用新 context 约束长任务

Anthropic 早期的长程 Coding Agent 方案把工作拆成 initializer agent 与后续 coding agent。每轮 coding agent 从新 context 开始，读取 feature list、progress 文件、Git 历史和当前代码，只完成一个功能，再写回进度并提交。

官方 quickstart 的循环也确实在每次迭代创建新的 client。其 coding prompt 明确要求 Agent 在 context 填满之前留下干净状态，供下一轮继续。

这个 Harness 同时做了多件事：

  • 缩短单轮可见历史；
  • 用固定启动指令重新强调小步交付；
  • 通过新 Agent 降低旧路径依赖；
  • 强迫进度、Git 和测试结果外化；
  • 用下一轮冷启动检验 checkpoint 是否足够。

因此，早期实验可以证明“这套 reset + durable state 组合有效”，却不能把收益全部归因于新窗口的注意力位置。

Sonnet 4.5：Context Anxiety 使 Reset 成为补丁

Anthropic 2026 年复盘称，Sonnet 4.5 在接近它认为的上下文限制时会表现出 “context anxiety”：过早收尾、缩小目标，甚至把未完成工作包装成完成。该团队当时发现，仅靠 compaction 不足以获得强的长任务表现，周期性 reset 仍然关键。

关键变量是当时的模型会根据剩余 context 形成错误的完成压力，并非旧 token 本身“有毒”。Reset 改变了模型对任务时间和剩余预算的判断，也重新施加了每轮交付协议。

旧 prompt 中“在 context 填满之前结束”的要求，既能促使 Agent 留下可恢复状态，也可能放大这种提前收尾倾向。这一解释与公开材料一致，但属于机制推断，不是 Anthropic 发布的独立消融结论。

Opus 4.5：Reset 变成 Dead Weight

换成 Opus 4.5 后，同一团队观察到 context anxiety 基本消失，周期性 reset 反而成为额外负担。新 Harness 取消 reset，让 Agent 维持连续 session，并交给 Agent SDK 自动 compaction。

这项变化不能简化成“Opus 4.5 的长上下文更强，所以不需要阶段边界”。Anthropic 保留了大量边界机制：

  • planner、generator、evaluator 仍然分工；
  • 工作仍按 sprint 和 contract 组织；
  • Agent 继续通过文件交换状态；
  • Git 仍承担版本和恢复职责；
  • 独立 evaluator 仍从外部验证结果。

消失的是周期性 transcript reset，保留下来的是工作阶段、职责边界、外部状态与验收门。

公开材料能够确认 合理但尚未独立证明 不能据此推出
Sonnet 4.5 阶段 reset 对该 Harness 很重要 reset 同时缓解了路径依赖和剩余预算焦虑 所有模型、所有任务都应周期性 reset
Opus 4.5 阶段取消 reset 后表现更好 更强的连续规划能力降低了冷启动收益 自动 compaction 永远优于 checkpoint
新 Harness 仍保留 contract、文件、Git 和 evaluator durable state 让连续会话更容易恢复 阶段边界已经不再需要
Anthropic 把变化归因于模型行为改善 多项 Harness 改动共同影响了结果 已存在 reset 对照实验量化每个因素

截至 2026 年 7 月，公开文章提供的是工程观察和系统演变，没有发布严格的 reset / no-reset 定量消融。最稳妥的结论是：模型能力提升会改变最佳上下文策略，但没有消除状态外化与可验证恢复。

Lost in the Middle 不能直接证明新会话更优

《Lost in the Middle》在多文档问答和键值检索等任务上发现，模型使用长上下文信息时会受到位置影响，关键信息放在中部时常弱于头部或尾部。它提醒工程师不能把“放进窗口”当成“模型能稳定使用”。

这项结果不能直接证明：

  • Coding Agent 的历史中段必然是低价值噪声；
  • 把 handoff 放在新会话开头就能无条件提高信噪比；
  • 任意模型、任意窗口占用率都有相同的首因和近因偏置；
  • reset 的收益主要来自注意力位置变化。

后续研究还显示，位置偏差会随相对上下文占用和模型变化，Lost in the Middle 并非所有设置下都稳定出现。对 Coding Agent 更可靠的工程原则仍是 Anthropic 所说的“最小高信号上下文”：根据当前任务选择内容，测量恢复质量，而不是把某个位置偏差当成通用切分定律。

四种策略没有固定强弱顺序

Compact、连续会话、子 Agent 和 checkpoint reset 改变的是不同变量，不能只用“信息保留高、中、低”排序。

策略 保留局部连续性 隔离旧噪声 状态转移成本 适合场景 主要失败模式
连续会话 最完整 弱 低 同一目标下高耦合迭代 历史膨胀、旧路径锚定
Compact 依赖摘要策略 中 中 同一任务受窗口压力 细节丢失、摘要错误固化
Subagent / Fork 由委托方式决定 强 中到高 独立调查、专业化、并行验证 prompt 漏项、返回结果不可验
新会话 + Checkpoint 只保留显式状态 强 高 阶段完成、所有权变化、权限变化 checkpoint 不完整、冷启动重复探索

普通 Claude Code subagent 从独立 context 开始，不继承父会话的对话历史、已读文件和已调用 Skill；它会得到委托 prompt、自身 system prompt、适用的项目规则、Git 状态和配置中预加载的 Skill。fork 是例外，会继承父会话历史。

Claude Code 还支持恢复 custom / general-purpose subagent 的已有会话；Explore 与 Plan subagent 则是一次性执行。把子 Agent 一概写成“每次调用都无状态”已经不准确。当前 Claude Code 也允许嵌套 subagent，最大深度为 5；这是版本化产品能力，不是 Subagent 的稳定本质。

边界由设计给出，触发由运行时证据决定

“切分点是设计的”不等于执行前必须锁死一个 turn 数或 token 百分比。设计阶段应定义退出条件和恢复契约，运行时再根据证据选择连续、compact、delegate 或 reset。

可观测的触发信号包括：

  • 当前阶段的 artifact 已形成，并通过约定验证；
  • 下一阶段的目标、权限或责任人发生变化；
  • 窗口压力开始影响工具结果、Skill 或关键约束的保留；
  • Agent 反复回到被否决方案，旧路径依赖明显；
  • 任务已经漂移，当前历史与新目标的相关性很低；
  • checkpoint 已经足以让冷启动执行者恢复；
  • 安全边界要求把不同权限域隔开。

“无法用合理大小的文档描述阶段输出”只能作为诊断信号，不能直接证明阶段设计错误。有些高耦合任务确实依赖大量局部状态，更适合连续会话或 fork。边界质量最终要由恢复测试判断。

运行时状态机

边界操作应当冻结当前状态、验证、发出 checkpoint，再决定如何切换；不能先清空上下文，再回忆刚才做过什么。

会话运行时状态机

这套顺序也解释了为什么“自动 compaction”与“checkpoint”不冲突。前者重写 active context，后者定义工作状态的事实源和恢复协议。可靠的 Harness 往往同时需要两者。

一份可执行的 Handoff Contract

Handoff 不必采用统一文件名，但字段应足以让新执行者恢复并自证。下面是一份可以直接裁剪的模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
schema_version: handoff/v1

goal:
  current_phase: "实现会话恢复"
  next_phase: "独立验证"
  exit_criteria:
    - "目标测试通过"
    - "工作区只包含声明过的变更"

scope:
  in:
    - "src/session/**"
  out:
    - "部署与生产配置"

status:
  phase: verified
  branch: "feature/session-recovery"
  head: "0123456789abcdef"
  worktree: clean

artifacts:
  - path: "docs/session-contract.md"
    role: "接口事实源"
  - path: "src/session/recover.ts"
    role: "实现"

decisions:
  - choice: "事件日志与 active context 分离"
    rationale: "支持恢复与审计，同时限制模型工作集"
    revisit_when: "日志重放成本超过当前预算"

rejected_options:
  - option: "把完整 transcript 重新注入"
    reason: "窗口成本过高，且包含过期工具输出"

evidence:
  - claim: "恢复后可继续执行"
    source: "tests/session-recovery.test.ts"
    result: "passed"

verification:
  commands:
    - "npm test -- session-recovery"
  environment: "Node 24 / macOS"

open_risks:
  - "尚未覆盖损坏 checkpoint"

permissions:
  allowed:
    - "本地文件修改"
  forbidden:
    - "部署"

next_step:
  action: "由独立执行者重跑恢复测试并检查失败路径"
  stop_when: "验收报告已生成，或发现契约缺字段"

YAML 只是载体，可定位性才是重点。每个结论都要能回到 artifact、版本或验证结果；每个未决问题都要有下一动作；每项权限都要清楚说明。

用冷启动恢复测试验收边界

边界是否设计成功，不应由 handoff 的字数或格式判断。最有效的检查是让一个没有旧 transcript 的执行者完成恢复：

  1. 只读取项目规则、checkpoint 和其中指向的事实源。
  2. 核对分支、HEAD、工作区和 artifact 状态。
  3. 重跑最小基线，确认 checkpoint 没有把失败状态写成成功。
  4. 复述当前目标、已完成事项、被拒方案、未决风险和下一步。
  5. 在不猜测隐含历史的前提下开始下一动作。

如果第 2 或第 3 步失败，问题在 checkpoint 的真实性；如果第 4 步需要猜测，问题在状态选择；如果恢复材料接近完整 transcript，阶段可能过度耦合，或者外部 artifact 还不够成熟。

这种冷启动检查还有一个额外价值：它把“上下文是否充分”从主观感觉变成可重复的 Harness 测试。早期 Anthropic Coding Agent 每轮从 Git、feature list 和 progress 文件恢复，本质上就在做这种检查。新 Harness 取消周期性 reset 后，仍通过文件、contract 和 evaluator 维持同一类可验证边界。

在上下文文章矩阵中的位置

本文承担的是“工作状态怎样跨越会话、阶段和 Agent 边界”这一层。相邻文章分别回答：

Messages 文章讲“历史能做哪些变换”，Context Paging 讲“工作集怎样管理”，Subagent 文章讲“执行者怎样隔离”。本文位于三者之间，定义何时进入下一工作状态，以及必须带走什么。

参考资料