多智能体系统一旦进入真实业务，最先失控的往往不是模型能力，而是记忆边界。控制器需要知道任务目标、分支状态和人工兜底点；专家 Agent 只需要与自己职责直接相关的上下文；某一次局部会话则只该保留为当前动作服务的短期信息。如果这三层记忆被混成同一个上下文桶，系统就会在重试、并行和交接时不断把旧信息带进新决策。
因此，讨论“全局记忆和局部记忆应该如何分层”，本质上是在讨论多智能体编排里谁持有控制面、谁消费任务面、谁保留会话面。LangGraph 对多 Agent 编排强调 supervisor、network 和 handoff 等结构差异，AutoGen 与 CAMEL 也都说明角色化协作可以放大任务能力，但前提是角色边界与交互协议足够明确。对 TaskPilots 这类多 Agent 协作编排集群来说，真正要设计的不是“让所有角色都记住更多”，而是“让每一层只记住自己必须记住的东西”。
为什么这个问题重要
真实运行代价
当全局记忆和局部记忆没有分开时，控制器会被迫反复读取专家执行细节，专家又会继承不属于自己的历史噪声。这样做短期上像是“信息更完整”，长期却会直接抬高 token 成本、误路由概率和恢复复杂度。一个分支失败后，团队很难判断是全局目标错了、局部证据错了，还是某个 Agent 把上一轮讨论误当成了当前约束。
- 控制器难以稳定判断当前任务处在哪个阶段。
- 专家 Agent 容易被无关历史诱导，开始越权规划或重复调查。
- 人工接管时需要先清洗整段上下文，审计成本显著上升。
如果不处理会怎样
生产环境里最常见的后果有四类。第一类是角色漂移，研究员型 Agent 开始替控制器改计划，控制器又反过来替执行者补细节。第二类是状态失真，某个分支已完成，但旧上下文仍让系统把它当成待处理节点。第三类是并行分支失控，多个执行者共享同一份不断增长的历史，导致彼此污染。第四类是成本外溢，本该只在控制面存档的长期信息，被每次调用都重新搬运一遍。
适用场景
谁最需要这套方法
只要任务天然包含拆解、路由、并行调查、结果会合与人工兜底，这套分层方法就值得优先引入。典型场景包括多来源研究与归纳、跨系统排障、复杂工单编排，以及需要多角色协同生成并复核结果的内容或运营流程。它们的共同点不是“任务很难”，而是“同一份记忆不该被所有角色等量共享”。
- 控制器需要跨多轮持有任务目标、状态、权限与停止条件。
- 专家角色只需要窄职责输入、工具权限和回传契约。
- 局部执行会话需要可丢弃、可重建，而不是永久沉淀进主上下文。
什么时候先不要这么做
如果当前系统仍是单 Agent 加少量工具调用，或者流程固定、上下文很短、失败恢复也主要靠人工重新触发，那么先把记忆拆成多层未必会立刻带来收益。此时更重要的是先定义清楚工具输入输出、失败分类和权限边界，再决定是否需要独立的全局状态层与角色内存层。
推荐系统结构
核心角色与状态
一个更稳健的结构，是把记忆至少拆成三层。全局记忆由控制器持有，用来记录任务目标、任务图、分支状态、共享事实、审计事件和人工决策；局部记忆由专家 Agent 持有，只服务于某一类职责，比如检索、分析、生成、评审；会话记忆则只存在于当前一次执行中，随着子任务结束而归档或丢弃。AutoGen 强调会话式协作带来的灵活性，CAMEL 强调角色扮演带来的分工效率，但这些收益都依赖角色能在有限上下文里完成自己的工作，而不是共享一个无限膨胀的历史。
- 全局层记录任务级事实，必须结构化、可审计、可恢复。
- 局部层记录角色级工作记忆，只保留完成该职责所需的上下文。
- 会话层记录本轮推理与工具交互，结束后只提炼必要摘要回写。
与 TaskPilots 的映射
映射到 TaskPilots，多 Agent 协作编排集群的控制面应持有全局状态层，包括任务 ID、阶段、分支 join 条件、审批点和最终产出；状态层负责保存经过验证的共享事实和可回放事件；并行执行者只拿到最小必要任务包，而不是整个项目档案。这样做的好处是，控制器可以在 fan-out 时发放窄上下文，在 fan-in 时只接收结构化回传，再由控制面决定哪些内容升级为全局事实、哪些只留在局部日志里。
风险与失效点
常见失控方式
记忆分层最怕“名义上分层，实际仍然全量透传”。不少系统会给专家 Agent 单独名字，却继续把完整历史一股脑塞进去，这样角色虽然变多，边界并没有更清楚。另一类高频问题是回写过度，专家每完成一次子任务，就把整段推理过程写回全局层，最后全局记忆重新膨胀成未治理的聊天记录。
- 全局层写入标准不清，未经验证的假设也被当成共享事实。
- 局部层过宽，专家拿到过多权限和过多历史，边界再次失守。
- 会话层不做摘要提炼，导致归档内容不可搜索、不可复用。
需要人工兜底的地方
凡是涉及高成本操作、跨系统写入、权限升级、对外发送、或多个分支结论互相冲突的节点，都应保留人工兜底。人工看到的不该是冗长对话，而应是当前全局状态、关键证据、各分支结论和待确认动作。只有这样，人工接管才是真正接管控制面，而不是被迫重新阅读所有局部推理。
验证指标
上线前怎么验证
上线前要验证的核心，不是 Agent 是否“看起来更聪明”，而是分层之后是否更容易恢复、更少串味、更好解释。可以挑一组包含并行调查、失败重试和人工升级的样例，对比分层前后在同类任务上的表现。
- 检查相同任务重复运行时，控制器是否能稳定恢复到相近状态。
- 检查专家执行结果是否更聚焦，是否减少了越权规划与重复劳动。
- 检查 join 阶段的回收结果是否足够结构化，能否直接用于后续决策。
上线后怎么持续判断
生产阶段建议持续跟踪四类指标：任务完成率、分支回收率、人工接管率和单次任务成本。除此之外，还应补两项更贴近记忆分层本身的指标，一是“全局回写命中率”，看进入全局层的信息有多少会在后续步骤里真正复用；二是“局部上下文膨胀率”，看专家 Agent 的平均上下文是否正在失控。如果全局层越来越像日志仓库、局部层越来越像第二个全局层，就说明分层正在失效。
下一步 / FAQ
下一步建议
最实际的下一步，不是立刻重写全部角色，而是先画出一张记忆归属表。把你当前工作流里的信息分成三类：哪些是任务级长期状态，哪些是角色级工作记忆，哪些只是本轮会话的临时上下文。只要这张表画清楚，后续再去设计 handoff 契约、join 结构和人工审批点，系统就不容易继续把所有问题都塞进一个提示词里。
FAQ
全局记忆是不是越完整越好？ 不是。全局层应保存高价值、可验证、可复用的事实与状态，而不是保存所有中间推理。
局部记忆会不会让 Agent 丢上下文？ 会丢掉不该长期保留的噪声，但不应丢掉完成子任务所需的关键事实。关键在于 handoff 契约是否足够明确。
怎么判断某条信息该不该回写到全局层？ 看它是否会影响后续路由、审批、审计或最终结论。如果只服务于本轮局部推理，就应留在局部层或会话层。
组织协作上最容易卡在哪？ 通常卡在谁有权修改全局事实。平台团队需要先定义写入规则，否则任何角色都能改主状态，系统边界会很快重新模糊。