会话分段与阶段总结：超长任务下，Agent 为什么必须学会“分段生存”
当一个 Agent 任务持续数十分钟、跨越多个工具和状态阶段时，真正先崩的往往不是模型能力，而是上下文组织能力。本文系统拆解会话分段、阶段总结、重入恢复与验证闭环，帮助团队把“长任务偶尔成功”升级成“长任务稳定完成”。
📷 Photo by Walls.io via Pexels
一、长任务失败，很多时候不是模型不够强，而是上下文已经失控
团队做 Agent 时，最容易被短任务 demo 误导。一个三轮内完成的问答、一次数据库查询、一次简单工具调用，看起来都很顺。但一旦任务变成下面这种形式，系统就开始出现不稳定：
- 持续 20 分钟以上
- 需要调用多个工具和外部系统
- 中间存在人工确认、等待和重试
- 任务目标会被拆成若干阶段推进
这时最常见的问题并不是模型不会推理，而是：
- 历史上下文越来越长，关键约束被埋没
- 早期错误假设没有被及时淘汰
- 模型忘记当前处于哪个阶段，重复做已完成动作
- 中断后无法从“正确位置”恢复，只能重新扫整段对话
所以，长任务 Agent 的核心不是“把窗口做大”，而是“把过程组织好”。会话分段与阶段总结，本质上是在给 Agent 建一个更可靠的任务运行时。
二、什么叫“会话分段”：不是按长度切，而是按任务边界切
很多系统的第一反应是：对话太长了，那就每隔 $N$ 条消息做一次摘要。这种做法能缓解 token 压力，但不一定能提升稳定性，因为它只是按文本长度切片，不是按任务结构切片。
更有效的分段方式，应该围绕阶段边界：
- 目标切换：从“理解需求”进入“执行计划”
- 工具切换：从“信息搜集”进入“外部系统写入”
- 责任切换：从“模型决策”进入“等待用户确认”
- 状态切换：从“探索”进入“收敛”或“交付”
也就是说，分段不是为了省 token，而是为了让系统知道：
- 当前阶段的目标是什么
- 这一段里哪些信息仍然有效
- 到了下一段，什么应该沉淀，什么应该丢弃
这和 记忆写入策略：什么时候写、写什么、写到哪，才不会把记忆库写脏 是一体两面：前者解决“阶段内怎么组织”，后者解决“阶段外怎么沉淀”。
三、阶段总结不是“复述聊天记录”，而是产出可执行状态
一个无效的阶段总结通常长这样：
- 我们讨论了 A、B、C
- 然后尝试了 X、Y、Z
- 最后觉得可能需要继续优化
它看似完整，实际上没有任何系统价值，因为无法支持下一轮执行。
真正有用的阶段总结，至少应回答七个问题：
1）当前阶段的目标是什么？
例如：确认用户真实意图、完成工具数据拉取、输出候选方案、等待审批。
2）已经完成了哪些动作？
不是“聊了什么”，而是“做成了什么”。例如：
- 已读取 4 个数据源
- 已调用支付 API 失败 2 次
- 已生成 3 个方案候选
3）产生了哪些可复用产物？
包括：
- 结构化参数
- 已确认约束
- 工具返回结果摘要
- 已验证结论
4）还有哪些未决问题？
未决问题会直接决定后续是否该追问、等待还是回退。
5）当前风险是什么？
例如：数据源未验证、权限不足、用户口径矛盾、外部系统可能超时。
6）下一步应该做什么？
要落到可执行动作，而不是“继续推进”。
7）下一步判断成功的证据是什么？
这是很多摘要最缺失的一项。没有证据定义，后续 Agent 即使完成动作，也不知道是否达成阶段目标。
因此，阶段总结更接近一个“阶段 checkpoint”，而不是会议纪要。
四、一个实用的阶段状态模型
如果你希望分段与摘要真正进入工程系统，建议至少维护这样一份结构化状态：
phaseId
phaseGoal
inputs
completedActions
artifacts
openQuestions
risks
nextAction
successCriteria
resumePointer
这套状态有三个价值：
- 可注入模型：让模型在下一轮基于结构化事实继续推理
- 可供前端展示：把长任务变成用户可见的阶段面板
- 可供系统恢复：在崩溃、中断、切模型后快速恢复执行
其中 resumePointer 很关键。它表示系统应从哪里重新开始，例如：
- 从某个工具调用继续轮询
- 从用户确认节点重新等待
- 从“重新规划下一步”节点重新生成计划
没有这个字段，所谓“恢复”往往只是“再读一遍旧上下文”。
五、分段规则怎么定：建议同时使用事件驱动和预算驱动
成熟系统通常不会只靠单一规则切段，而是同时考虑两类触发器。
1）事件驱动切段
适用于任务语义明显变化的场景：
- 用户目标改变
- 进入新工具或新子任务
- 等待外部审批
- 输出阶段性交付物
2）预算驱动切段
适用于上下文成本持续膨胀的场景：
- token 使用接近预算阈值
- tool traces 过长
- 重复观察数过高
- 历史消息中有效信息占比下降
经验上，预算驱动负责“防溢出”，事件驱动负责“保语义完整”。两者结合，才能既不太早切碎，也不拖到上下文已经被污染。
六、为什么长任务需要“阶段摘要 + 原始证据”双轨并存
有些团队走到另一个极端：既然要压缩上下文，那就把原始细节都丢掉，只保留摘要。结果是系统虽然更短了，但一旦摘要有偏差，后续所有步骤都会建立在错误抽象上。
正确做法通常是双轨：
- 执行轨：注入阶段摘要，保证模型在小上下文里快速对齐
- 证据轨：保留原始日志、工具回执、关键消息引用，供需要时回看
这和 幻觉治理框架：拒答、追问、证据引用三件套 的原则一致：不要让模型只依赖“被转述过的世界”。重要决策仍应有原始证据可回溯。
七、重入机制：没有恢复能力的长任务系统，最终都依赖人工兜底
长任务系统一定会遇到：
- 模型超时
- 服务重启
- 外部接口失败
- 用户离开后再回来
- 任务被人工接管后再交回 Agent
如果系统没有重入机制，最常见后果是：
- 从头读取整段对话，成本高且不稳定
- 重复调用已成功的外部动作
- 错过本应等待的条件，导致误执行
一个可用的重入机制通常至少包含：
- 阶段快照：最近一次稳定状态
- 幂等标识：避免恢复后重复写入或重复触发
- 恢复策略：失败后是重试、回滚还是转人工
- 状态验真：恢复前先检查外部世界是否已经变化
尤其第四点非常重要。因为系统中断时，世界不会暂停。恢复逻辑如果只看本地快照，不看外部当前状态，反而可能把旧状态重新写成新错误。
八、如何判断你的 Agent 已经需要会话分段
以下任意现象持续出现，就说明你不能再靠“把更多聊天历史塞给模型”来解决：
- 同一任务中反复重做已完成动作
- 用户明明确认过的约束，后续阶段又被违背
- tool traces 很长，但模型仍然频繁问回已经得到答案的问题
- 中断恢复后，系统从错误阶段继续
- 长任务成功率随着轮数明显下降
这类现象本质上不是单点 prompt 问题，而是任务状态管理问题。
九、落地建议：从“自动摘要”升级为“阶段运行时”
如果团队现在还处于第一版，可以按下面顺序升级：
阶段一：先做显式阶段字段
哪怕手工定义，也比完全没有状态强。至少区分：理解、规划、执行、等待、交付。
阶段二：给每个阶段固定摘要模板
避免摘要风格飘忽不定，导致恢复质量波动。
阶段三：建立 resume pointer 和 success criteria
让系统知道从哪继续，以及继续到什么算成功。
阶段四：让前端可视化阶段状态
一旦用户也能看到任务处于哪个阶段、卡在哪个问题上，长任务的信任感和协作效率都会明显提升。
阶段五：把阶段摘要纳入评测
不要只测最终答案，也要测：
- 摘要是否漏掉关键约束
- 恢复后是否重复动作
- 切段后成功率是否提升
十、结论：会话分段不是优化项，而是长任务 Agent 的基础设施
只要任务足够长、步骤足够多、状态足够复杂，系统就迟早会从“提示词工程”问题，演化成“运行时管理”问题。
会话分段解决的是阶段边界，阶段总结解决的是状态压缩，重入机制解决的是中断恢复。三者合起来，才让 Agent 从“偶尔做完长任务”变成“可重复地做完长任务”。
联动阅读：