https://jiajia.fun/qa/d265c010-%E6%9C%89%E9%95%BF%E4%BB%BB%E5%8A%A1%E6%97%B6-1-%E8%AE%BE%E7%BD%AE%E6%80%BB%E6%8E%A7-%E8%AE%A9%E6%80%BB%E6%8E%A7%E6%8A%8A%E4%BB%BB%E5%8A%A1%E5%88%92%E5%88%86%E6%88%90%E5%A4%9A%E4%B8%AA%E6%A8%A1%E5%9D%97-%E5%B9%B6%E6%8E%A7%E5%88%B6%E7%AE%A1%E7%90%86%E8%BF%99%E4%BA%9B%E6%A8%A1%E5%9D%97-2-%E4%B8%8A%E4%B8%8B%E6%96%87%E5%BF%AB%E6%BB%A1%E7%9A%84%E6%97%B6%E5%80%99%E6%80%BB%E7%BB%93%E8%AE%B0%E5%BF%86%E5%86%8D%E5%BC%80%E4%B8%80%E4%B8%AA%E6%96%B0%E7%AA%97%E5%8F%A3%E8%AF%BB%E5%8F%96%E8%AE%B0%E5%BF%86-3-%E8%BF%98%E6%9C%89%E5%88%AB%E7%9A%84%E4%BC%98%E5%8C%96%E6%96%B9%E6%A1%88%E5%90%97

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

回复 群友 8780 先说结论：你这两条方向都对，但都不是长任务里最关键的最后一环，而且第一条尤其容易做坏。长任务真正的分水岭不是「怎么切模块」，是「怎么知道它没跑偏」。 先说第 1 条，切模块交给总控。这个思路在任务天然可分、每个模块有独立验收标准时才成立，比如「把 30 个页面从旧框架迁到新框架」。一旦任务耦合（改 A 会影响 B 的判断），总控就变成了转述层，模块之间不共享中间发现，会重复踩同一个坑。我给的做法是：默认单 agent 全程跑，只把可独立验证的单元切出去；切出去的子 agent 必须带回可验证的东西（测试结果、diff、截图），而不是一段自我汇报的摘要。总控的职责也不是「分活」，是「定验收 + 卡失败」。 第 2 条，上下文快满就总结再开新窗口。方向对，但你把它当成唯一解法，就会漏掉更便宜的办法。先检查三件事：一是工具输出有没有截断（跑一次测试吐 5 万字日志，这是上下文杀手，比对话本身占的还多）；二是能不能把中间产物落盘，只留路径和结论在上下文里；三是 system prompt 和 skill 有没有塞太多没用的东西。这三处修完，很多任务根本到不了要压缩的程度。真到要压缩，也别用「总结一下」这种自由发挥的提示，要给结构化模板：目标、已完成、已排除的死路、当前卡点、下一步，尤其是「已排除的死路」最容易被总结掉，而它恰恰是重开窗口后最容易重踩的地方。 第三条往后是更值得投入的： 做可恢复的检查点。每完成一个可验证单元就记一条，带上完成判据和证据位置（这次跑的命令、产物路径、commit）。这样崩了不是「从一半重开」，而是「从最后一个检查点继续」。长任务拼的不是单轮多聪明，是失败后重启的成本。 给任务定「完成判据」，而不是给步骤。长任务跑偏的第一原因是一开始就没写清楚什么算完成。写成可执行的形式：哪个命令返回什么、哪个文件存在、哪个测试变绿。模糊目标下 agent 会自己发明终点，然后你就得到一份「看起来做完了」的汇报。 超时和重试要有硬上限。同一类失败连续 3 次就停下来报告，别让它自己无限重试——重试会大量消耗上下文和时间，而且它越试越偏。这是最省钱的一条优化。 把需要人判断的节点往前排。不可逆操作（删数据、发邮件、推线上、改权限）前置确认，而不是后面补救。长任务出事的成本几乎全在这一层。 能异步就异步。长任务最大的浪费是你在旁边等着。让它把进度推到通知渠道，失败了自动带上日志和最后一步，你看的时候直接做决策，不用在旁边盯。 最后一句更实际的：如果这个任务长到要反复开新窗口，通常说明它就该被拆成几个短任务，每个短任务有独立的验收和产物。反复压缩上下文是在给一个本来不该这么长的任务续命。