上下文与长任务管理
长任务的核心风险不是它某一次写错，而是上下文逐渐变满、目标漂移、失败尝试污染判断。研发人员要主动管理 clear、compact、fork、resume、worktree、子代理和进度记录。
本章目标
- 知道什么时候继续当前会话，什么时候清空或另开会话。
- 能用子代理和 worktree 隔离探索、评审和并行任务。
- 能让长任务停在可恢复、可解释、可验证的状态。
上下文是第一位约束
agent 的上下文会装下对话、文件内容、命令输出、截图和中间判断。它变满后，早期约束会被稀释，回答会变糙，甚至反复走失败路线。管理上下文不是任务收尾才做，而是从第一条 prompt 就开始。
我的经验是：长任务拆成几个可验收的小段。每段结束时，让工作区停在能解释、能回滚、能继续的位置；不要让一个会话同时背着多个不相关任务。
- 探索阶段限制范围：先给目录或文件范围，避免无边界扫全仓库。
- 实现阶段小步推进：每完成一块就验证一次，不等最后大爆炸。
- 评审阶段用新上下文：让 fresh reviewer 只看 diff 和验收标准。
- 收尾阶段写状态：改过哪些文件、跑过哪些命令、还剩哪些风险。
Clear、Compact、Fork 怎么用
- 继续当前会话：仍是同一个问题，前面的推理和决策对后续有价值。
- compact：会话很长但任务没变，先要求保留“目标、已改文件、关键决策、验证命令、未完成项”。
- clear / 新会话：任务换了、同一问题纠正两次还不对、或你想从干净上下文重新开始。
- fork：想从当前状态分出另一个方向尝试，但不想污染原会话。
- resume：跨天继续时先读项目规则、git status、当前 diff 和最近验证结果，不靠记忆硬接。
CASE
纠正两次还不对
场景
它连续两次修 UI 溢出都改错元素，第三次继续在同一上下文里争辩，大概率会更糟。
可以这样说
我们清空上下文重来。请基于这次教训写一条更精确的新任务说明：页面、视口、目标元素、不要改的范围、验证方式都写清楚。新会话只带这条任务说明和必要文件路径，不带前两次失败尝试。验收点
- 旧失败路线不继续污染。
- 新任务说明更精确。
- 只带必要上下文。
- 验证方式前置。
调研和评审交给子代理
子代理最重要的价值不是“多个 AI 更热闹”，而是隔离上下文。让它读几十个文件做探索时，主会话只需要结论和关键路径，不需要把探索过程全部塞进主上下文。
CASE
用子代理调研鉴权链路
场景
你要搞清楚现有鉴权如何处理 session 和 token refresh，会牵扯很多文件，但主会话只需要结论。
可以这样说
请用一个子代理调研鉴权系统怎么处理 session 和 token refresh，以及是否已有 OAuth 工具可以复用。只把结论、关键文件路径和不确定点带回主对话，不要贴大段原文。验收点
- 调研发生在独立上下文。
- 主会话只收到结论摘要。
- 关键文件路径被列出。
- 不确定点被明确标注。
CASE
用子代理做 fresh review
场景
实现会话已经有路径依赖。评审时最好让另一个上下文只看 diff 和验收标准。
可以这样说
请用一个全新上下文的 reviewer 审当前 diff。只读，不改代码。只报告影响正确性、需求或安全的问题，不报告风格偏好。验收点
- reviewer 不参与实现。
- 只读审查。
- 发现按影响排序。
- 不把偏好当必须修。
并行任务用 worktree 隔离
不要让多个 live session 同时改同一份工作区。并行执行时，用 git worktree 给每个任务单独目录，避免一个会话覆盖另一个会话的文件，也方便分别 review、测试和提交。
- 适合并行：互不依赖的 bug、不同模块的迁移、一个实现一个评审。
- 不适合并行：都要改同一个核心文件、需求还没拆清、验证环境只有一个。
- 每个 worktree 有自己的分支、会话和验证记录。
- 合并前先统一 review，避免两个任务各自通过但合在一起失败。
让状态可恢复
- 跨会话状态放在 issue、PR 描述、SPEC.md 或计划文档，不要只留在聊天里。
- 每轮结束要求汇报：目标、已改文件、命令结果、未验证项、下一步。
- 恢复任务先读：项目规则、git status、当前 diff、最近命令结果。
- 不要靠上一轮记忆继续改；记忆只能辅助，真实状态以仓库和命令输出为准。
请把当前会话压缩成可恢复状态：目标、已确认决策、已改文件、已运行命令、未验证项、下一步。内容要足够让一个新会话接手，不要贴大段原文。