有长任务时 1.设置总控，让总控把任务划分成多个模块，并控制管理这些模块 2.上下文快满的时候总结记忆再开一个新窗口读取记忆 3.还有别的优化方案吗

提问

有长任务时

1. 设置总控，让总控把任务划分成多个模块，并控制管理这些模块
2. 上下文快满的时候总结记忆再开一个新窗口读取记忆
3. 还有别的优化方案吗

回答

回复 群友 8780

先说结论：你这两条方向都对，但都不是长任务里最关键的最后一环，而且第一条尤其容易做坏。长任务真正的分水岭不是「怎么切模块」，是「怎么知道它没跑偏」。

先说第 1 条，切模块交给总控。这个思路在任务天然可分、每个模块有独立验收标准时才成立，比如「把 30 个页面从旧框架迁到新框架」。一旦任务耦合（改 A 会影响 B 的判断），总控就变成了转述层，模块之间不共享中间发现，会重复踩同一个坑。我给的做法是：默认单 agent 全程跑，只把可独立验证的单元切出去；切出去的子 agent 必须带回可验证的东西（测试结果、diff、截图），而不是一段自我汇报的摘要。总控的职责也不是「分活」，是「定验收 + 卡失败」。

第 2 条，上下文快满就总结再开新窗口。方向对，但你把它当成唯一解法，就会漏掉更便宜的办法。先检查三件事：一是工具输出有没有截断（跑一次测试吐 5 万字日志，这是上下文杀手，比对话本身占的还多）；二是能不能把中间产物落盘，只留路径和结论在上下文里；三是 system prompt 和 skill 有没有塞太多没用的东西。这三处修完，很多任务根本到不了要压缩的程度。真到要压缩，也别用「总结一下」这种自由发挥的提示，要给结构化模板：目标、已完成、已排除的死路、当前卡点、下一步，尤其是「已排除的死路」最容易被总结掉，而它恰恰是重开窗口后最容易重踩的地方。

第三条往后是更值得投入的：

做可恢复的检查点。每完成一个可验证单元就记一条，带上完成判据和证据位置（这次跑的命令、产物路径、commit）。这样崩了不是「从一半重开」，而是「从最后一个检查点继续」。长任务拼的不是单轮多聪明，是失败后重启的成本。

给任务定「完成判据」，而不是给步骤。长任务跑偏的第一原因是一开始就没写清楚什么算完成。写成可执行的形式：哪个命令返回什么、哪个文件存在、哪个测试变绿。模糊目标下 agent 会自己发明终点，然后你就得到一份「看起来做完了」的汇报。

超时和重试要有硬上限。同一类失败连续 3 次就停下来报告，别让它自己无限重试——重试会大量消耗上下文和时间，而且它越试越偏。这是最省钱的一条优化。

把需要人判断的节点往前排。不可逆操作（删数据、发邮件、推线上、改权限）前置确认，而不是后面补救。长任务出事的成本几乎全在这一层。

能异步就异步。长任务最大的浪费是你在旁边等着。让它把进度推到通知渠道，失败了自动带上日志和最后一步，你看的时候直接做决策，不用在旁边盯。

最后一句更实际的：如果这个任务长到要反复开新窗口，通常说明它就该被拆成几个短任务，每个短任务有独立的验收和产物。反复压缩上下文是在给一个本来不该这么长的任务续命。