新会话的注意力优势

Transformer 的注意力机制对 context 里的所有 token 同等收取计算开销，但不同位置的注意力质量并不均等。Liu et al.（2023）的实证研究表明，关键信息落在长 context 的中部时，模型的利用率显著低于放在头部或尾部——这就是广为人知的"Lost in the Middle"效应。

在一个持续运行的会话里，Phase A 的推理过程（试错、自我修正、文件读取结果、废弃分支）沉积在 context 中段。Phase B 的任务描述追加在末尾。Phase A 的推理噪声和 Phase B 的任务信号同时竞争注意力预算，前者在弱注意力区，但体积往往大得多。

切到新会话后结构反转：Phase B 的任务在 context 头部，Phase A 的蒸馏结果（handover 文档）也在头部，信号/噪声比接近最大值。

这说明在阶段边界开新会话、只传结果而不带推理过程，确实是有注意力机制支撑的优化——不只是节省 token。

切分点为什么难以找到

难以找到的根本原因是结构性的：切分不是"在哪里截断"的问题，而是"哪些内容保留"的问题。

一段对话里，不同内容的有效期是异构的：

工具调用结果（文件读取、搜索结果）：相关决策做出后立刻失效
已确立的约束条件：可能在整个工作流里永远有效
已物化的决策：实现完成并验证后失效
负空间（哪些方案被排除了，以及为什么）：失效时间不确定，往往最难捕获

这意味着 messages 数组里"仍然需要"的内容是散布的，不是连续的一段。不存在一个分隔线，使得线之前全部无用、线之后全部有用。在 messages 数组上找单点切分，本质上是用错误的数据结构操作这个问题——它需要的是选择（select），不是切片（slice）。

负空间是最难捕获的部分

有一类隐式依赖尤其容易被忽略。

Phase A 探索了 5 条路径，排除了 4 条，采纳了第 1 条。Phase B 的计划写了"采用方案 X"。如果只保留 Phase B 的计划、切掉 Phase A，Phase C 的某个时刻可能会"重新发现"一条 Phase A 已经排除的路径——因为排除的理由没有被显式记录，只是隐含在 Phase A 的推理过程里。

这就是负空间问题：早期内容的价值往往不在于它包含了什么，而在于它排除了什么。一份粗粒度的 handover 文档只写"决定用方案 X"，但抛弃了"方案 Y 为何不可行"这一同等重要的知识。后续阶段遇到具体实现时，会在 Phase A 已经踩过的坑里再踩一遍。

三类内容的失效速度

工具调用结果是失效最快的内容。文件读取、API 查询、搜索结果——一旦其中的发现被显式吸收进某个决策或计划，原始内容就可以丢弃。这类内容在长会话里体积最大、信息密度随时间递减最快，是切分时优先清理的对象。

决策的推理过程在决策物化后失效。"为什么选 Redis"的推理，在 Redis 的实现代码写完并通过测试后，对后续阶段不再有用。推理是中间产物，artifact 才是最终产物；artifact 存在后，推理的信息价值基本归零。

"最小充分上下文"测试是一个随时可用的判断工具：在任何关键节点问"如果把当前所有文件状态加上一段简短说明交给一个新 Agent，它能从这里继续吗？"。如果答案是肯定的，且那段说明远比当前 context 短，切分就是经济可行的。

制造切分点

在工作流设计阶段就应该规划好在哪里制造切分点，而不是在执行过程中试图发现它。

做法是在每个阶段边界主动外化状态。Phase A 结束时，写一份明确的 handover 文档，包含：

已做出的决策及其核心理由
被排除的方案及排除依据（负空间，不能省略）
当前所有 artifact 的状态摘要
进入下一阶段时的已知约束

这份文档把隐式的模糊边界变成显式的 handoff 契约。代价是在边界处做一次主动蒸馏；收益是后续所有阶段都在干净的 context 上运行，不携带前一阶段的推理噪声。

Claude Code 的 Agent tool 实现的正是这个模式：spawn 子 Agent 时，传给它的是精心构造的 prompt，而不是完整的 orchestrator 会话历史。那个 prompt 就是设计出来的切分点，不是在对话流里自然形成的。

三种切法的经济性比较

切法	信息保留	噪声清除	适合场景
Context compaction（压缩摘要）	高，摘要保留隐式细节	中	持续迭代，需要对话连续性
Subagent spawn（子 Agent 派发）	中，只传目标 context	高	明确的并行或专业化子任务
新会话 + Checkpoint Doc	取决于文档质量	最高	阶段边界清晰，artifact 完整

三种方式不互斥。在复杂工作流里，通常是：内部子任务用 subagent spawn，主流程阶段边界用 checkpoint doc，中间的对话连续性靠 compaction 兜底。可以把它们理解为渐进蒸馏架构：每个阶段产生"已定论的事实"，这些事实蒸馏进 checkpoint doc，下一阶段从 checkpoint 启动，不携带产生它的推理轨迹。

找不到切分点意味着什么

找不到切分点，有时候是一个诊断信号，而不只是技术困难。

如果一个阶段的输出无法用一份合理大小的文档描述，往往意味着这个阶段的边界本身不够清晰——两个阶段之间的耦合程度超过了一份 handover 文档所能承载的范围。在这种情况下，切分的困难是工作流设计问题的症状。解决思路不是找一个更好的切点，而是重新审视阶段的划分粒度，直到每个阶段都有清晰的输入规格和输出 artifact。

"何时新开 Agent"这个问题，最终是工作流设计问题，不是运行时判断问题。