开启长任务，如何判断自己需要终止当前对话开新对话，然后上一轮对话怎么跟下一轮的衔接

这事本质是两件事：什么时候该切，切的时候怎么把状态交出去。 一、什么时候该开新会话 不是轮次多就该切，而是出现下面这些信号才切： 1. 上下文污染。最典型的是你反复纠正同一个问题，它绕两圈又回去了。比如你说了三次「不要动 utils 目录」，它还是改；或者它开始拿一个已经被否掉的方案重新提。这时候再讲道理已经没用，因为旧上下文里那个错误结论权重太高。 2. 早期约束被遗忘。开头定的规则（不许加依赖、保持 CommonJS、只改这一个文件），到第 40 轮它开始违反。这说明关键信息已经被后面的长内容稀释掉了，对应「Lost in the Middle」那类注意力问题。 3. 事实开始错乱。它把没跑过的测试说成通过，或者引用一段其实没发生的对话。这个信号很危险，别继续用。 4. 话题真正切换了。上一个任务是修 bug，下一个是问部署方案。这两件事之间没有共享的因果链，硬放在一个会话里只会互相干扰。 5. 上下文用量接近阈值，或者响应明显变慢、开始重复自己。 反过来，如果任务还在同一条因果链上，只是轮数多，别急着开新的。先做压缩和摘要，比换会话划算——多 Agent 那套拆分反而更容易丢信息。 二、上一轮怎么衔接 核心动作只有一个：在切之前，让即将被丢弃上下文的那个 Agent 自己写一份交接文档。它知道自己踩过哪些坑，这是你事后补写不出来的。 不要贴对话记录，要写结论和约束。区别就是交接工作给对方一页 brief，还是甩过去一百页档案。 交接文档该有这些字段： 目标，一句话说清这次到底要交付什么。 当前状态，哪些已完成、验证到什么程度（跑过什么命令，通过还是没过）。 关键决策和约束，为什么这么选，哪些地方不许动。 失败的尝试，这条最容易被忽略，也最值钱——避免新会话把坑再踩一遍。 待办和下一步，按优先级排，第一步要具体到文件。 未验证的部分，别让新会话以为都验过了。 举个实际的。你让 Claude Code 把项目从 JS 迁到 TS，跑到第 40 轮你发现它又开始改你已经确认不动的 utils 目录。这时候别继续吵，先让它写 PROGRESS.md： 目标：把 src 迁到 TS，运行时行为不变。 已完成：src/api、src/hooks 迁完，tsc --noEmit 通过。 未完成：src/components 还剩 12 个文件，X.tsx 里有一处用 any 临时绕过。 约束：不要动 utils，不要升级依赖，保持 CommonJS。 失败尝试：批量 rename 引入 3 个循环依赖，已回滚。 下一步：先迁无依赖的叶子组件，从 Button.tsx 开始。 然后新会话第一句话就一句：「读 PROGRESS.md，然后继续下一步。」别的都不用说。 最后补一个习惯：别等到要切会话才总结。让状态一直外部化在文件里，每完成一个阶段就更新一次。这样会话中途崩了、超限了、你临时有事明天接着干，都能直接接上。真正的衔接不发生在切的那一刻，而发生在你一直在写的那份文件里。