当任务只有一个时，人和 Agent 很容易保持一致：读一份材料，写一个结果，检查一次输出。问题从多任务开始出现。多个子任务并行或连续推进时，如果没有一个中央状态，前后很快会变得不连贯。素材里的核心证据是“终端大脑 / jp009 / 多任务指挥官为什么需要中央状态”，这句话很准确。
“终端大脑”这个说法有意思。它不是指某个神秘系统，而是指多任务协作里需要一个持续保存判断的位置。没有它，Agent 每次都像从局部重新开始；有了它，所有子任务才能围绕同一组目标、边界和决策继续工作。
用户看到的是碎片化结果
多任务失控通常不是以报错形式出现，而是以“不像同一个人做的”形式出现。某个段落重复，某个判断前后冲突，某个任务忘了前一轮已经决定的标准。单看每个子任务，都似乎完成了；合起来，却缺少统一意图。
用户如果只要求“把这些内容改顺”，Agent 会继续在结果层修补。更有效的问法是：“为什么这些任务之间没有共享同一个状态？”这句话会把 Agent 从文本整理拉回协作架构。
中央状态的价值就在这里。它不是多写一个总结，而是让每个子任务都知道当前目标是什么、已经做过什么、哪些判断已经确定、哪些地方不能再改。没有这层状态，多任务指挥官就只是在分发任务，不是在指挥任务。
状态不是记录越多越好
很多人听到中央状态，会以为要把所有信息都塞进去。其实那样反而会失效。真正有用的中央状态，应该保存会影响后续判断的内容：目标、范围、风格、已确认决策、未解决问题、禁止触碰的边界。
对于写作任务，它可能包括文章定位、读者预期、素材来源、已经选定的角度。对于代码任务，它可能包括读写边界、测试策略、风险点。内容不一定多，但必须能让后续 Agent 或后续步骤快速接上。
用户在这里的引导很关键。他需要不断问 Agent：“这个判断会影响后面吗？如果会，就放进状态；如果只是一次性细节，就不要污染状态。”中央状态不是垃圾箱，而是多任务协作的短期记忆。
判断链怎样形成
多任务协作的判断链可以分成三步。第一步，确认所有任务共享的目标。第二步，确认每个任务的局部责任。第三步，把局部结果回写到中央状态，让后续任务知道已经发生了什么。
问题常常出在第三步。Agent 完成一个子任务后，如果没有回写，下一步就只能依赖当前上下文的残留。上下文一长，残留就会变得不可靠。中央状态相当于一个经过筛选的“共同记忆”，让任务之间有交接，而不是靠感觉延续。
这也是“指挥官”这个比喻有用的地方。指挥官不是每个细节都亲自做，而是知道整体战局、资源位置和下一步重点。多任务 Agent 如果没有中央状态，就像每个执行者都在努力，但没人知道全局正在变成什么。
下次复用中央状态
我会在多任务开始前，要求 Agent 建一个很小的状态块。不要长篇大论，只写当前目标、输入来源、输出路径、关键决策和风险边界。每完成一个阶段，就更新一次。更新时也要克制，只记录会影响后续的内容。
这样做的好处，是用户可以随时检查任务有没有偏航。Agent 也能在切换上下文时快速恢复，不必反复读取大量历史。尤其在批量写作、批量审查、跨文件修改里，这个习惯会显著减少风格漂移和逻辑断裂。
中央状态不是为了让流程显得高级，而是为了让多任务协作有连续性。用户怎么问，决定 Agent 是各做各的，还是围绕统一目标推进。Agent 怎么维护状态，决定结果是拼接，还是整合。
所以，多任务指挥官需要中央状态，不是因为任务复杂才要加一层形式，而是因为复杂任务必须有共同记忆。没有共同记忆，就没有稳定协作；没有稳定协作，再多子任务也只是碎片。
中央状态也要能被用户读懂
中央状态不能只服务 Agent，也要服务用户。如果状态写得像内部日志，用户看不懂，就无法及时纠偏。好的状态应该短、清楚、可检查。用户看完能立刻知道当前目标是什么，哪些决定已经定了，下一步会影响哪里。
这点在人机协作里很关键。Agent 可能觉得自己“记得”，但用户并不知道它记住了什么。把中央状态外显出来，等于给双方一个共同桌面。用户可以指出遗漏，Agent 可以据此调整后续任务。状态不是为了保存历史，而是为了让下一步不误解历史。多任务越多，这个共同桌面越重要。
中央状态还应该允许被修正。一次任务推进中，用户可能改变判断，也可能发现前面的假设不成立。如果状态只追加不修订，就会把旧误解带到后面。更好的做法是让 Agent 在更新状态时说明：哪些是新决定，哪些替换了旧判断，哪些仍然待确认。这样状态不只是记事本，而是协作中的活文档。
这个活文档越清楚，任务交接越轻。哪怕换一个 Agent 接手，也能从状态里看见当前方向，而不是重新翻完整段对话。对用户来说，这就是中央状态最实际的价值：它把复杂协作压缩成可继续的现场。