多会话交接 — 会话结束,工作继续
构建七字段交接包,从工作台工件自动生成,使下一个会话在第一分钟就高效
多会话交接 — 会话结束,工作继续
会话即将结束。工作还没有。交接包是将”Agent工作了一小时”变成”下一个会话在第一分钟就高效”的工件。有目的地构建它,不是事后补充。
类型: 构建 语言: Python(标准库) 前置条件: Phase 14 · 34(仓库记忆),Phase 14 · 38(验证),Phase 14 · 39(审查者) 时间: ~50分钟
学习目标
- 识别每个交接包需要的七个字段。
- 从工作台工件生成交接,无需手写散文。
- 将大型反馈日志修剪为交接大小的摘要。
- 使下一个会话的第一个动作确定性。
问题所在
会话结束。Agent说”很好,我们取得了进展。“下一个会话打开。下一个Agent问”我们从哪里继续?“上一个Agent的答案消失了。下一个Agent重新发现、重新运行相同命令、重新询问人类相同问题,并浪费三十分钟恢复上一个会话最后三十秒。
糟糕交接的成本在任务生命周期内每个会话都要支付。修复是在会话结束时自动生成的包:变更了什么、为什么、尝试了什么、失败了什么、剩下什么、下次首先做什么。
核心概念
七个字段
| 字段 | 它回答的问题 |
|---|---|
summary | 做了什么的一段话 |
changed_files | 一目了然的diff |
commands_run | 实际执行了什么 |
failed_attempts | 尝试了什么以及为什么不起作用 |
open_risks | 下一个会话可能遇到什么,带严重性 |
next_action | 下一个会话采取的第一个具体步骤 |
verdict_pointer | 验证+审查报告的路径 |
next_action 字段是承重的。一个有除了 next_action 之外一切的交接是状态报告,不是交接。
交接是生成的,不是写的
手写交接是在困难日子被跳过的交接。生成器读取工作台工件并发出包。Agent的工作是使工作台处于生成器可以总结的状态,不是写总结。
两种形式:人类可读和机器可读
handoff.md 是人类读取的。handoff.json 是下一个Agent加载的。两者来自相同的源工件。如果它们分歧,JSON胜出。
反馈日志修剪
完整的 feedback_record.jsonl 可能有数百条目。交接仅携带最后K条加上每个非零退出的条目。下一个会话如果需要可以加载完整日志,但包保持小型。
留下干净状态
交接描述工作。干净状态使工作可恢复。它们不是同一件事。一个完美的 handoff.md 如果下一个会话打开时面对半应用的diff、Agent忘记的临时文件、游离的分支和运行前就出错的测试,那就是毫无价值的。
所以会话不在功能工作时结束。它在工作台处于生成器可以总结且下一个会话可以信任的状态时结束。清理是自己的阶段,在交接之前运行,它是一个检查,不是一个习惯,因为习惯是在困难日子被跳过的东西。
| 检查 | 干净意味着 | 脏阻止因为 |
|---|---|---|
| 工作树 | 每个变更已提交或显式暂存并带注释 | 半应用的diff对下一个Agent看起来像有意工作 |
| 临时工件 | 无 *.tmp、scratch目录、调试打印或注释块留下 | 游离文件污染diff和下一个Agent的心智模型 |
| 测试 | 绿色,或红色且失败在 open_risks 中命名 | 静默红色测试是下一个会话踩入的陷阱 |
| 功能板 | feature_list.json 状态反映现实 | 过时板发送下一个会话去做已完成的工作 |
| 分支 | 在预期分支上,无分离HEAD,无孤立分支 | 错误分支意味着下一个会话的第一次提交落在错误位置 |
生产模式
- 压缩策略各不相同;包Schema不变。 Codex CLI的POST /v1/responses/compact是服务器端不透明AES blob;回退是本地”交接摘要”。Claude Code在95%上下文时运行五阶段渐进压缩。三种不同机制,相同需求:将压缩后存活的内容序列化为可移植工件。包就是那个工件。
- 新会话交接不是压缩。 压缩延长会话;交接干净地关闭一个并开始下一个。当原地压缩开始降级时,Agent应该写紧凑交接、结束会话、并在新鲜上下文中恢复。
- 50-75%上下文时收尾,不是在墙边。 最佳结果报告在50-75%上下文预算时结束会话而不是95%。包生成器在压缩伪影污染源状态之前干净运行。
- 每个分支和主题一个活跃交接。 多Agent协调在过时交接上比在坏模型输出上更容易崩溃。始终包含
branch、last_known_good_commit和active | superseded | archived的status。
实践
code/main.py实现:将状态、裁决、审查和反馈收集到 WorkbenchSnapshot 的加载器、generate_handoff(snapshot) -> (markdown, payload) 函数、选择最后K条反馈条目加所有非零退出的过滤器,以及写入 handoff.md 和 handoff.json 的演示。
交付
outputs/skill-handoff-generator.md产生调整到项目工件路径的生成器、运行它的会话结束钩子,以及下一个Agent在启动时读取的 handoff.json schema。
练习
- 添加
assumptions_to_validate字段,显示构建者记录但审查者评分不高于1的每个假设。 - 对失败运行和通过运行不同地修剪反馈摘要。辩护不对称。
- 包含”给人类的问题”列表。问题进入包vs聊天消息的阈值是什么?
- 使生成器幂等:运行两次产生相同的包。需要什么稳定才能成立?
- 添加”下一个会话先决条件”部分,列出下一个会话在行动前必须加载的确切工件。
关键术语
| 术语 | 人们怎么说 | 实际含义 |
|---|---|---|
| 交接包 | ”会话摘要” | 携带七个字段的生成工件,markdown和JSON都有 |
| 下一步行动 | ”首先做什么” | 开始下一个会话的一个具体步骤 |
| 反馈修剪 | ”日志摘要” | 最后K条记录加每个非零退出 |
| 状态报告 | ”我们做了什么” | 缺少 next_action 的文档;有用,但不是交接 |
| 裁决指针 | ”收据” | 验证+审查报告的路径用于可追溯性 |