Claude Code长任务如何压缩交接和续跑
长任务难点经常出现在“接着做”。前半段已经调查清楚调用链，也做了几处修改，窗口开始变长。此时直接压缩，可能丢掉失败测试和临时约束；直接换会话，新 Agent 又不知道前面排除了哪些方案。
我处理长任务时会先把信息分成三类：可以重新获取的原始材料、需要继续使用的任务状态、必须由工程系统保存的真实结果。分类完成后，再决定清理、压缩还是换会话。
三类信息要分开放
三类信息的保存位置不同，混在聊天记录里会让后续交接很难判断哪个结果仍然有效。
可以重新获取的材料
这些内容丢掉后可以再次读取或执行：
- 某次 Read 返回的完整源文件；
- 大段 Grep 命中；
- 完整构建日志；
- 已经提交到仓库的文档正文；
- Git 能查到的历史记录。
它们对当前判断有用，却不需要永久留在会话里。真正要保存的是从材料中得出的结论和再次获取它们的线索。
需要接续的任务状态
这些内容在压缩和交接时必须保留：
- 用户最终要交付什么；
- 不能修改什么；
- 已经确认的调用链和业务规则；
- 当前采用的方案及理由；
- 已修改文件和关键方法；
- 当前失败用例与错误摘要；
- 已排除的方案及排除原因；
- 接下来第一条可执行动作。
由外部系统保存的真实结果
文件系统、Git、测试报告和任务系统保存的是工程事实。压缩摘要写着“已经修改库存服务”，仍要回到 diff 确认；摘要写着“测试通过”，仍应保留实际命令和结果。
压缩前先找阶段边界
随时执行 /compact 虽然可以释放空间，但压缩发生在方案尚未稳定时，摘要器很难判断哪些细节马上会用到。
更适合压缩的时机包括：
- 仓库探索完成，调用链已经确认；
- 方案评审结束，修改范围和风险已经确定；
- 一个独立功能已经实现并验证；
- 大量日志分析结束，只剩根因和证据；
- 准备从实现阶段进入全面验收。
阶段中间也可以压缩，但要明确告诉 /compact 保留什么。例如：
/compact 保留库存预占状态机、超时释放幂等条件、
当前失败的三条测试、已修改文件和下一步验证命令
这种指令比“帮我压缩一下”更容易得到可接续的摘要。
/compact完成了什么
从使用层面看，/compact 会把较长的历史整理成一份更短的接续状态，让会话继续运行。它的目标通常包括用户意图、关键决策、已完成工作、当前断点和待办。
压缩后的摘要无法保留每一段文件内容和每一行日志。需要精确代码、行号和测试输出时，要重新读取或重新运行。
Claude Code 当前官方文档还明确了规则恢复边界：
- 项目根目录的
CLAUDE.md会在压缩后从磁盘重新注入； - 子目录中的嵌套
CLAUDE.md不会立刻全部恢复，重新读取相应目录文件时才会加载； - 带
paths的 Rules 也要等再次命中匹配文件后加载； - 只在对话里说过、没有进入摘要或文件的限制可能丢失。
压缩完成后，继续处理某个子目录前，可以先读一遍相关文件，让局部规则重新进入上下文。
自动压缩与手动压缩怎么配合
Claude Code 会在接近上下文限制时进行自动处理。当前版本还提供 /autocompact 用于查看或设置自动压缩窗口，具体可用性与参数要以本机 /help 和官方命令文档为准。
自动压缩是一道兜底，无法替代阶段管理。它触发时，任务可能正处于复杂排查中间；手动压缩可以选在信息已经稳定的节点，并明确保留重点。
我的习惯是：
- 日常小任务交给默认自动机制；
- 跨模块任务在阶段结束时主动压缩；
- 压缩前更新计划或状态文件；
- 压缩后立即核对目标、约束、改动和下一步。
为什么任务状态要写到窗口外
对话历史会增长、压缩和清空，文件可以重新读取、审查和版本化。长任务只靠聊天记录，很难稳定跨越多次压缩。
状态文件不用写成流水账。下面这些内容就够用：
# 库存超时释放任务状态
## 目标与验收
- 待支付订单超过 15 分钟释放库存。
- 已支付订单不释放。
- 重复超时消息只生效一次。
## 已确认事实
- 超时信号由 order-job 产生。
- 库存预占流水以 reservationId 唯一定位。
- releaseIfReserved 已有条件更新，可以作为幂等入口。
## 已完成
- 新增重复消息测试，旧实现可稳定复现失败。
- 消费者已改为调用 releaseIfReserved。
## 当前故障
- InventoryTimeoutConsumerIT 在 Testcontainers 启动阶段失败。
- 错误摘要：本机 3307 端口被旧容器占用。
## 下一步
1. 清理测试容器占用并重新运行该集成测试。
2. 运行 order-service 与 inventory-service 相关测试。
3. 检查 diff 中是否出现超范围配置修改。
这份状态能让新会话直接从错误恢复开始，不必重新阅读几十轮对话。
Handoff至少要写清七件事
需要新开会话时，我会写一份 handoff。它可以是 Markdown、Issue 评论或任务系统记录，格式不重要，接手者能马上执行更重要。
- 目标与完成标准：最终交付物和验收条件。
- 修改边界：禁止目录、兼容要求、用户特别强调的限制。
- 已完成工作：文件、方法和验证结果。
- 当前断点：正在处理哪一个测试、错误或分支。
- 关键决策：选了什么方案，为什么这样选。
- 排除记录：尝试过什么，为什么放弃。
- 启动动作：新会话接手后的第一条命令或第一个文件。
一份可直接使用的Handoff模板
# Handoff：库存预占超时释放
## 最终目标
待支付订单超过 15 分钟后释放库存。重复触发保持幂等，
已支付订单不受影响。
## 修改边界
- 不改数据库表结构；
- 不改公开下单接口；
- 不提交、不推送、不部署。
## 当前工作区
- `InventoryTimeoutConsumer.java`：已接入条件释放方法；
- `InventoryReservationRepository.java`：未修改；
- `InventoryTimeoutConsumerIT.java`：新增三条场景测试。
## 已确认决策
复用现有 order-job 发送的超时事件，不引入新的消息组件。
库存幂等以 reservationId 和 RESERVED 状态的条件更新保证。
## 已验证
- 单元测试：`mvn -pl inventory-service -Dtest=InventoryReleaseServiceTest test` 通过；
- 集成测试尚未完成。
## 当前阻塞
Testcontainers 启动 MySQL 时提示本机端口冲突。业务断言还没有执行到。
## 已排除
- 不使用 Redis 锁：项目没有统一锁组件，条件更新已能保证单次状态迁移；
- 不新增 reservation 表字段：现有状态和更新时间足够判断。
## 接手后的第一步
运行 `docker ps` 确认测试容器占用，再重新执行
`InventoryTimeoutConsumerIT`。测试通过后检查完整 diff。
模板里保留了精确路径、命令和失败原因。接手者不需要猜“继续处理测试”具体指什么。
什么时候该压缩，什么时候该换会话
| 状态 | 建议动作 |
|---|---|
| 只是工具输出很多，目标和方案仍清楚 | 控制输出，必要时压缩 |
| 一个阶段刚结束，后面仍是同一任务 | 更新状态后手动压缩 |
| 会话多次重复搜索，旧判断持续干扰 | 写handoff并开新会话 |
| 用户开始了无关的新任务 | /clear或新会话 |
| 想保留当前对话并尝试另一方向 | 使用当前版本提供的分支或Fork能力 |
| 独立支线会产生大量一次性材料 | 交给Subagent |
不要把“窗口还能装多少”当成唯一判断。当前会话已经形成错误惯性时，继续压缩可能只会保留一份更短的错误摘要。
压缩后如何做恢复检查
压缩完成后，我会让 Claude 用几句话回答下面的问题：
请根据压缩后的状态回答：
1. 当前最终目标和不能修改的内容是什么；
2. 已经改了哪些文件；
3. 当前失败用例是什么；
4. 已排除哪些方案；
5. 下一条要执行的命令是什么。
如果摘要里没有证据，请回到工作区和状态文件核对，不要猜。
这一步相当于一次恢复演练。回答缺少关键约束，就先重新读取 handoff、计划或相关文件，别直接继续改代码。
后台任务和Subagent状态也要交代
压缩或换会话时，仍在运行的测试、审查和子任务不能只写“后台还有任务”。至少记录：
- 任务名称和目的；
- 由谁执行；
- 当前状态；
- 结果到哪里查看；
- 完成后会影响哪一步决策。
新会话无法自动继承所有外部进程和旧支线。把后台任务当作显式依赖管理，能避免重复启动或在结果回来前做出错误判断。
面试里容易说错的地方
这几个说法听起来顺口，放到真实任务里却会直接影响状态保存和恢复判断。
把压缩说成无损
摘要一定会舍弃细节。保住目标和状态，不等于保住所有文件、搜索结果和日志。
把Auto Memory当成当前任务检查点
Auto Memory适合跨会话经验，当前任务的修改断点、失败测试和临时决策更适合放Plan或Handoff。把大量临时状态写进长期记忆，会让后续会话一直携带过期内容。
只保存结论，不保存证据入口
“消息幂等已经处理”缺少实现文件、条件和测试。交接记录要让接手者知道到哪里核对。
交接写成流水账
逐轮复制聊天记录会把上下文污染一起带过去。Handoff只保留目标、边界、决策、断点、证据和下一步。
Claude Code长任务要区分可重新获取的材料和必须接续的状态。源文件、搜索结果和完整日志可以按需重取；目标、约束、决策、失败用例、已改文件和下一步必须进入压缩摘要或外部状态文件。阶段结束时可以用/compact释放空间，压缩后重新核对任务状态。多次压缩仍然出现重复探索或错误惯性时，写一份带文件、命令和失败原因的handoff，再让新会话从明确断点接手。