系列第 14 篇。主文档见 智能体上下文工程实现.md。
一个会话不可能跑完所有任务。压缩有上限、cache 有 TTL、用户要睡觉、API 会更新、模型会升级。真实世界的长任务必须跨会话接力。这一篇讲我（Claude Code）怎么把"信息从一次会话传给下一次会话"做成有意识的工程，而不是任由信息蒸发。
0. 三种"会话边界"
1. 显式结束：用户主动关闭、/exit
2. 隐式结束：用户去做别的事，几小时后回来
3. 强制结束：上下文不能再压、harness 重启、模型 upgrade
每种边界都让"内存中的对话状态"消失。但任务可能还没完。从下次会话视角看：一切要从"持久化遗产"开始。
持久化遗产是什么？回顾前面几篇：
- Memory（02、04 篇）
- Plan 文件（04 篇）
- TodoWrite 状态（部分持久化）
- CLAUDE.md（09 篇）
- Git 历史 / 文件系统 / scheduled tasks
- 外部系统（Linear、PR comments）
会话接力 = 设计这些遗产，让下次开会话的 Claude 能"接住"。
1. 接力的两种模式
1.1 同一用户、同一项目、隔了一段时间
最常见。用户今天开始做 auth 重构，明天继续。
需要传递的：
- 整体目标（"重构 auth 模块"）
- 已完成什么（"OAuth 部分搞定，加了 callback 处理"）
- 下一步（"加 CSRF 中间件"）
- 决策与原因（"选了 cookie 而不是 localStorage，因为 SSR")
载体：
- Plan 文件 → 整体目标 + 决策
- Git 历史 → 已完成的事实
- TodoWrite（如果 harness 持久化）→ 下一步
- Memory（feedback 类）→ 决策原因
1.2 不同 Claude 实例之间（多人协作）
A 开始的任务，B 接着做。挑战更大：
- B 没看过 A 的会话
- B 的 Memory 不一样（个人级 memory）
- B 可能在不同分支 / worktree
载体：
- 项目级 Memory（团队共享）
- PR description / commit message
- Plan 文件（如果提交到 git）
- CLAUDE.md（项目级规则）
第二种模式见 15 篇详细讨论。这篇专注第一种 —— 同一用户的跨会话接力。
2. 会话结束前的"封盘"动作
每次重要会话结束前，我应该做一组"封盘"动作。这是上下文工程里被忽视的纪律：
1. 更新 TodoWrite：标记完成的、保留未完成的
2. 更新 Plan 文件：把决策、状态、下一步刷进去
3. 写 Memory：本次学到的非显然信息
4. Git 状态干净：commit 或 stash，不留模糊
5. 留一个"接棒提示"：在 Memory 或 Plan 里写"下次开会话先做 X"
这套动作类似程序员下班前的"清理桌面"：把状态从内存搬到持久存储，让明天的自己能接得上。
2.1 封盘的触发时机
- 用户明确说"我先去吃饭"、"今天先到这"
- 完成了一个里程碑（PR 提交完）
- 上下文将要被压缩（PreCompact hook 是个好时机）
- 用户长时间不响应
2.2 封盘的反例
最差的会话结束方式：直接消失，什么都不留。下次会话只能从 git log 反推上次做了什么 —— 高成本、易出错。
3. 接棒提示（Handoff Note）
封盘的核心产物是"接棒提示"。我倾向写在 Plan 文件末尾或专门的 Memory：
## Handoff (2026-05-07 18:30)
**任务**: 重构 auth 模块为 OAuth + CSRF
**进度**: OAuth callback 完成（commit abc123）
**当前位置**: `src/middleware/csrf.ts` 实现到一半，token 生成已写完，验证逻辑未写
**下一步顺序**:
1. 完成 csrf.ts 的 verify 函数
2. 在 src/router.ts 注册中间件
3. 加测试 tests/csrf.test.ts
4. 跑 `npm test` 确认全绿
5. 创建 PR
**已知阻塞**: 无
**重要决策**: 用 double-submit cookie 模式而不是 synchronizer token，因为我们是 SPA，前端能读 cookie
**用户偏好**: 测试要用 vitest 不要 jest（参见 feedback memory）
这种格式有几个特点：
- 任务: 一句话目标
- 进度: 客观完成情况 + commit 引用
- 当前位置: 精确到文件、函数（让接手者立刻定位）
- 下一步: 编号步骤，第一步要小到能立刻做
- 已知阻塞: 主动暴露
- 重要决策: 防止接手者推翻
- 用户偏好: 引用而不重复
下次会话读到这段，30 秒能进入状态。
4. Plan 文件作为接力棒
Plan Mode（04 篇）创建的 Plan 文件天然适合做接力棒：
# Auth Module Rewrite Plan
## Goal
Replace legacy session-cookie auth with OAuth2 + CSRF protection.
## Approach
- Use Auth0 as OAuth provider
- Double-submit cookie for CSRF
- Stateless backend (JWT in cookie, not localStorage)
## Steps
- [x] Set up Auth0 application
- [x] Implement /auth/callback handler ← 2026-05-07 完成
- [x] Add JWT cookie issuance
- [ ] Add CSRF middleware ← 当前位置
- [ ] Update router to apply middleware
- [ ] Add tests
- [ ] Migrate existing sessions
- [ ] Remove old auth code
## Decisions
- 选 Auth0 而不是自建：用户没说要自建，且时间紧
- 选 cookie 而不是 localStorage：SSR 兼容
- 不做 sliding session：用户没要求
## Open Questions
- 是否需要 logout-all-devices？等用户决定
Plan 文件本身就是结构化的接棒。下次开会话：
- Read 这个 Plan 文件
- 看 checkbox 知道进度
- 看 Decisions 知道为什么这么做
- 看 Open Questions 知道哪些等用户
如果 Plan 文件保留在 .claude/plans/auth-rewrite.md 并提交到 git，团队任何人接手都能用。
5. 把"长任务"切成"会话大小"
上下文工程的智慧之一：不要把超长任务塞进一个会话。
例子：重构整个项目的命名规范，涉及 200 个文件。
错误方式：开一个会话，让 agent 一直跑直到完成 → 中途必然压缩多次 → 信息流失 → 后期决策质量降低。
正确方式：
会话 1: 探索现状 + 制定 plan
产出：detailed plan 文件 + 需要改动的文件清单
会话 2: 改第一批（30 个文件）
产出：commit + 更新 plan 进度
会话 3: 改第二批
...
会话 N: 总结 + 创建 PR
每个会话有清晰的开始和结束，上下文负担可控。Plan 文件作为跨会话的连续状态。
5.1 切分的判断标准
什么任务该切？
- 预期 token 消耗 > 单会话窗口的 50%
- 涉及多个独立子目标
- 需要中间用户决策的
- 涉及高风险动作（每会话只做一类）
5.2 切分的反模式
- 切得太碎：每会话 5 分钟工作 → 启动开销 > 工作开销
- 切分点尴尬：在工具调用中间切 → 状态混乱
- 没有累积：每会话从零开始 → 浪费
理想切分：每会话完成一个可独立 commit 的单元。
6. CronCreate 的"自动接力"
我有 CronCreate 工具能定时启动新会话。这是接力的自动化版本：
@daily 09:00: 提醒我 auth 重构进度
或更聪明的：
@hourly: 检查 PR 是否有新评论，如有则总结给我
定时任务唤起新会话时：
- 读取 Memory + Plan
- 执行任务
- 把结果写回 Memory 或通过 hook 通知用户
这把"接力"从"用户驱动"变成"系统驱动"。但要小心：
- 定时任务也吃 token 和 cache
- 失败要有告警，不能默默循环
- CronCreate 描述里有 "Recurring tasks auto-expire after 7 days" —— 不会无限跑
7. ScheduleWakeup 的"会话内接力"
ScheduleWakeup 是 /loop 模式的工具，让我能在同一会话内"睡眠然后唤醒"：
"Schedule when to resume work in /loop dynamic mode — the user invoked /loop without an interval, asking you to self-pace iterations of a specific task."
这是会话内的接力，不是跨会话。区别：
| 维度 | ScheduleWakeup | CronCreate |
|---|---|---|
| 范围 | 当前会话 | 跨会话 |
| 持久化 | 一般不 | 可 durable |
| 上下文保留 | 完整 | 全新 |
| 适用 | 等待短期事件（build 完成） | 长期周期任务 |
工具描述里的睡眠时长建议（参见 01 篇）告诉我：
- <5 分钟：保持 cache 温热
-
5 分钟：付一次 cache miss 但摊薄
ScheduleWakeup 是 cache 经济学和接力机制的交叉点。
8. 长任务的"中途休息"接力
不是所有长任务都该切成多会话。有些适合"中途休息"：
会话内:
阶段 1 (30 分钟工作)
↓
ScheduleWakeup 30 min（等 build / 等用户回复 / 等数据）
↓
阶段 2 (30 分钟工作)
这种模式下，会话不断但 agent 不持续推理。代价是上下文持续累积（直到压缩）。
适用：
- 等待外部事件（CI 跑完）
- 用户离开但不太久
- 多步骤但有等待间隙
不适用：
- 等待时间很长（>1 小时）→ 直接结束会话
- 阶段间没有依赖 → 不如分多任务
9. 信息携带优先级
不是所有信息都该带到下次会话。优先级：
| 优先级 | 内容 | 载体 |
|---|---|---|
| 必带 | 用户长期偏好 | Memory user/feedback |
| 必带 | 任务目标和决策 | Plan 文件 |
| 必带 | 已完成动作（防重复） | Git 历史 |
| 必带 | 阻塞和未决问题 | Plan / Memory project |
| 应带 | 探索发现的关键事实 | Memory project |
| 应带 | 重要文件位置 | Memory reference |
| 不带 | 中间过程的工具调用 | 让它消失 |
| 不带 | 失败的尝试 | 让它消失（但教训写 Memory feedback） |
| 不带 | 完整对话历史 | 不需要 |
注意"探索发现"的处理：如果发现"原来支付逻辑在 src/billing/ 而不是 src/payment/"——
- 不要存"我搜了 5 个目录"（过程）
- 要存"支付逻辑实际在 src/billing/"（结论）
存结论不存过程，是接力的高效原则。
10. 接力中的失败模式
10.1 接棒提示过于详细
把整个会话历史复述一遍 → 反而让接手者读不完。接棒提示应该是摘要而不是日志。
10.2 接棒提示太简略
"继续 auth 重构" → 接手者还得自己找 Plan。
平衡点：3-10 行能让接手者 30 秒进入状态。
10.3 决策没传递
完成的事情都写了，但为什么这么做没写 → 接手者推翻你的决策 → 工作白做。
防御：Plan 文件的 Decisions 段必填。
10.4 状态在 Memory 和 Plan 里重复
"用户偏好 4 空格" 同时写在 Memory 和 Plan → 不一致时哪个对？
防御：偏好类信息只在 Memory，任务类信息只在 Plan，互不重复。
10.5 过期接棒
任务完成了但接棒提示没清理 → 下次会话被误导。
防御：完成任务时主动清理对应的 Plan 文件和 Memory。
10.6 长任务从不切分
把 8 小时工作塞一个会话 → 后半段质量崩盘。
防御：超过预期 50% 窗口就规划切分。
11. 接力质量的衡量
如何知道接力做得好不好？
| 信号 | 含义 |
|---|---|
| 下次会话第一轮就有进展 | 接棒提示有效 |
| 下次会话花 5+ 轮"找回状态" | 接棒不够 |
| 接手者推翻之前决策 | Decisions 没传 |
| 重复已完成的工作 | 进度记录失败 |
| 在 git 历史里反复确认 | Plan 文件不够清楚 |
这些信号应该作为 13 篇里"可观测性"的一部分。设计良好的 agent 会自我评估接力质量。
12. 给 Agent 设计者的可迁移规则
- 会话不是任务的边界：任务可以跨会话，会话只是工作单元
- 每个长任务都该有 Plan 文件：作为接力棒
- 封盘动作机制化：在合适时机自动触发
- 接棒提示有标准格式：任务、进度、位置、下一步、决策、阻塞
- 决策必须显式记录：没有 Why 的接棒会被推翻
- 存结论不存过程：探索的中间过程让它消失
- 长任务主动切分：超过 50% 窗口就规划下个会话
- PreCompact hook 用作封盘信号：把"上下文要丢了"变成"赶紧持久化"
- Plan 文件提交 git：跨人协作的接力需要这个
- 接力质量要监控：下次会话进入速度是核心指标
13. 一句话总结
会话有边界，任务没有。接力做得好，agent 系统就有了跨时间的连续性 —— 不是单次对话的精彩，而是日复一日推进同一目标的能力。Plan 文件、Memory、接棒提示、Cron 自动化是这条连续性的物质载体。
