第 4 章 · 长任务连续性管理
本章目标：理解为什么智能体会在长任务中"丢失线索"，掌握状态持久化技术和 context anxiety 的应对策略。
4.1 跨会话困境
你让 Claude Code 实现一个完整功能。它运行 30 分钟，完成大部分工作，但上下文快满了。你开启新会话继续——却发现它不记得上次做了什么决定、为什么选 A 不选 B、哪些文件已修改、测试状态如何。它花 15 分钟重新探索项目，可能采用与上次不一致的方法。
这就是 AI 编码智能体在跨会话任务中面临的真实困境。
4.2 上下文窗口不是无限的
上下文窗口是有限的。这不是模型升级能解决的问题——即使窗口扩大到 1M token，复杂任务仍会耗尽它们。智能体不只是生成代码；它们理解代码库、跟踪自己的决策历史、处理工具输出、维持对话上下文。所有这些信息的增长速度快于窗口扩展速度。
更深层的问题：智能体产生的信息重要性不均匀。中间推理步骤包含决策的"为什么"——为什么选 A 不选 B、为什么用这个库而不是那个、为什么跳过某个优化。最终输出只包含"是什么"——代码本身。压缩策略通常保留后者但丢失前者。下次会话看到代码，但不知道为何这样写，可能会"优化"掉一个刻意的设计决策。
Anthropic 在长运行智能体研究中观察到有趣现象：当智能体感知上下文快满时，会表现出"仓促收尾"行为——匆忙结束当前工作、跳过验证步骤、选择简单方案而非最优方案。他们称之为 context anxiety（上下文焦虑）。
4.3 没有状态持久化 vs 有状态持久化
没有状态持久化，每次新会话从零开始：
会话 1（功能完成一半）→ 上下文快满 → 会话结束
↓
会话 2 重新开始 → 重读文件夹、重跑测试、猜代码为何这样写 → 工作重复、恢复缓慢有状态持久化，新会话快速接续：
会话 1 工作 → PROGRESS.md（完成/进行中/下一步）
→ DECISIONS.md（为何选此方案）
→ 验证记录（哪些测试通过/失败）
→ Git checkpoint（精确仓库状态）
↓
会话 2 重建 → 快速接续4.4 核心概念
| 术语 | 含义 |
|---|---|
| 状态持久化文件 | 让新会话能明确接续上次工作的持久化文件。最基本形式包括进度日志、验证记录、下一步行动 |
| 重建成本 (Rebuild Cost) | 新会话达到可执行状态所需时间。好的 harness 可将重建成本从 15 分钟压缩到 3 分钟 |
| 漂移 (Drift) | 智能体理解与实际仓库状态之间的差距。每次会话边界都引入漂移；不受控制时逐会话累积 |
| 上下文焦虑 | Anthropic 观察到的现象——智能体在接近上下文限制时表现出仓促收尾行为 |
| 压缩 vs 重置 | 压缩在同会话内总结上下文（保留"是什么"，可能丢失"为什么"）；重置开启新会话从持久化状态重建（干净但依赖工件完整性） |
4.5 连续性断裂的后果
上次会话花费大量上下文预算分析了三种方案并选择了 B。本次会话的智能体不知道那次分析，可能基于不完整信息重新决策——甚至可能选 A。相同信息，不同结论，因为决策上下文消失了。
更糟的是重复工作。智能体不确定某些工作是否已完成，于是再做一遍。或者更糟——做了一半，发现与现有实现冲突，必须重做。没有进度记录，新会话不知道什么已完成。
多次会话后，实现方向可能已悄然偏离原始需求。每个新会话对项目目标的理解略有不同。每次偏差逐次累积，最终结果可能远离原始意图。
还有验证差距。上次会话的验证结果（哪些测试通过、哪些失败、为何失败）未记录。新会话必须重跑所有验证才能了解当前状态。每次会话从头诊断，每次浪费宝贵上下文。
4.6 状态持久化实践
核心思路：把智能体当作每次会话短期记忆被擦除的工程师。 在它"下班"前，必须写下关键信息，让下一个"值班"智能体能快速接手。
工具 1：进度文件 (PROGRESS.md)
最基本的状态持久化文件：
# 项目进度
## 当前状态
- 最新提交：abc1234 (feat: 添加用户偏好端点)
- 测试状态：42/43 通过 (test_pagination_edge_case 失败)
- Lint：通过
## 已完成
- [x] 用户模型和数据库迁移
- [x] 基础 CRUD 端点
- [x] Auth 中间件集成
## 进行中
- [ ] 分页功能（90% - edge case 测试失败）
## 已知问题
- test_pagination_edge_case 在空结果集时返回 500
- 需确认被删除用户是否应出现在列表
## 下一步
1. 修复分页 edge case bug
2. 添加 "include deleted users" 查询参数
3. 更新 API 文档工具 2：决策日志 (DECISIONS.md)
记录重要设计决策和原因。不需要详细设计文档——只要"什么决策、为何、何时"：
# 设计决策
## 2024-01-15: 使用 Redis 缓存用户偏好
- 原因：高频读取（每次 API 调用）、数据量小
- 被否决方案：PostgreSQL 物化视图（高频变更使维护成本不划算）
- 约束：缓存 TTL 5 分钟，写时主动失效工具 3：Git 提交作为检查点
完成每个原子工作单元后提交。提交信息应说明做了什么和为何这样做。这是免费的、自动版本化的状态快照。
工具 4：init.sh 或 harness 初始化流程
在 AGENTS.md 中指定"打卡"和"下班"流程：
## 会话开始（打卡）
1. 读取 PROGRESS.md 了解当前状态
2. 读取 DECISIONS.md 了解重要决策
3. 运行 make check 确认仓库状态一致
4. 从 PROGRESS.md "下一步"部分接续
## 会话结束（下班）
1. 更新 PROGRESS.md
2. 运行 make check 确认状态一致
3. 提交所有完成的工作混合策略
不是每个任务都需要上下文重置。短任务（30 分钟内）可在一个会话内完成。长任务（跨会话）必须用进度文件和决策日志保持连续。判断标准：如果任务需要超过 60% 的窗口，开始准备交接。
4.7 深入理解上下文焦虑
Anthropic 2026 年 3 月研究进一步揭示了上下文焦虑的具体表现：在 Sonnet 4.5 上，当上下文接近窗口限制时，智能体表现出强烈的"仓促收尾"行为。
两种应对策略：
压缩：在同一会话内总结上下文。保留"是什么"，可能丢失"为什么"。适合短暂停。 重置：开启新会话从持久化状态重建。干净但依赖工件完整性。适合长暂停或上下文极度紧张时。
选择标准：如果任务明显跨越会话边界，用重置；如果只是短暂中断，用压缩。
4.8 本章小结
- 上下文窗口有限，复杂任务终将耗尽
- 状态持久化文件让新会话能明确接续
- 重建成本是衡量 harness 质量的关键指标
- 漂移逐会话累积，必须主动控制
- 上下文焦虑导致仓促收尾，需用持久化缓解
- PROGRESS.md + DECISIONS.md + git 提交 + init.sh 是四大工具
🧪 随堂测验
点击你认为正确的选项。答错时会展示正确答案与原因解析。
1. "context anxiety" (上下文焦虑) 是指什么现象？
2. 以下哪种方法不能有效减少跨会话 drift（漂移）？
3. rebuild cost（重建成本）衡量的是什么？
4. 压缩 (compaction) 和重置 (reset) 的主要区别是？
🛠️ 动手实践
- 为一个长任务（>30 分钟）创建 PROGRESS.md 模板，包含当前状态、已完成、进行中、已知问题、下一步。
- 运行一次跨会话实验：会话 1 做一半停掉，会话 2 仅读 PROGRESS.md 接续，记录重建成本。
- 实现 init.sh 的打卡/下班流程，让智能体每次会话自动读写状态文件。