多 Agent 协作最容易被误解的一点，是大家以为“记得越多越安全”。于是控制器、研究 Agent、执行 Agent、评审 Agent 乃至人工接管者都被喂同一段不断增长的历史。短期看像是在降低信息损失，长期却会把角色边界、状态边界和决策边界一起抹平，让每个角色都在消费自己并不真正需要的背景。
更稳的做法，是给不同角色划清记忆边界。谁需要共享事实，谁只需要当前任务包，谁只该拿到本轮会话的临时上下文，都应该在系统层明确，而不是交给提示词临时猜。OpenAI Agents SDK 对 sessions 的设计、Anthropic 对 prompt caching 的说明，以及 LangGraph 对 memory 的分层思路，其实都指向同一个结论：协作系统真正需要的不是全量继承，而是按角色作用域发放可恢复、可回写、可审计的最小记忆面。
为什么这个问题重要
真实运行代价
如果每个角色都继承全部背景，最先上涨的通常不是正确率，而是噪声、成本和误判概率。控制器本来只需要目标、阶段、分支状态和升级条件，却被迫读取专家层面的搜索细节；执行 Agent 本来只需要当前步骤的输入与约束，却继承了上游关于策略和权衡的大段讨论。结果就是每个角色都开始在不属于自己的信息面里做判断。
OpenAI Agents SDK 的 sessions 文档强调，会话状态应该服务于可恢复执行，而不是无边界堆积历史。Anthropic 的 prompt caching 也说明，稳定、可复用的前缀才值得缓存，频繁变化且只对局部有效的内容不该成为所有请求的共同负担。放到生产环境里，这意味着如果角色边界不清，每次委派都会重复携带大量短期噪声，系统既更贵，也更难恢复。
如果不处理会怎样
不做角色级记忆边界，常见后果有四类。第一，角色漂移，专家开始替控制器改计划，控制器又去重写专家结论。第二，状态失真，某个旧轮次的中间判断被下游误认成当前硬约束。第三，并行污染，多个角色共享同一桶历史，彼此把无关上下文带进本轮决策。第四，人工升级失焦，因为人接到的不是最小状态包，而是一整段需要重新清洗的聊天记录。
LangGraph 对 memory 的区分给了一个很实用的提醒：应把长期有效的事实和当前工作会话分开。若这一步不做，系统就会把“能拿到的上下文”误当成“应该继续参与决策的上下文”，最后每次交接都越来越重。
适用场景
谁最需要这套方法
最适合引入角色级记忆边界的，是那些会跨角色、跨步骤、跨时间片持续流转的任务。比如控制器把问题分派给研究、执行和审查三个角色；比如一个长流程会先自动处理，再在高风险节点升级给人工；再比如多个专家 Agent 并行处理不同来源，最后由汇总角色做 join。它们的共同点不是“流程长”，而是“不同角色需要消费不同密度的信息”。
还有一类高匹配场景，是角色权限不同的流程。拥有写库权限的执行角色不该天然拿到所有历史策略讨论；只负责审核的角色也不需要继承执行阶段的全部工具日志。只要角色权限和职责不同，就值得把记忆面也分开，否则上下文和权限很容易一起失控。
什么时候先不要这么做
如果你的流程本质上还是单 Agent 加少量工具调用，任务同步完成、很少暂停恢复，也没有明确的角色分工，那么先做复杂的记忆边界收益未必明显。此时更优先的是先把输入输出、停止条件和失败分类定义清楚。
另一个不适用边界，是完整历史本身就是工作对象的一部分。例如某些深度协作写作、咨询或陪伴场景，角色需要持续理解前文语气和演进过程。在这类任务里，不应机械压缩成窄上下文，而应先确认哪些角色真的需要完整历史，哪些角色仍可用最小任务包工作。
推荐系统结构
核心角色与状态
更稳妥的做法，是至少把协作记忆拆成四层。第一层是共享状态层，由控制器或状态服务持有，记录任务目标、当前阶段、共享事实、审批点和会话身份。第二层是角色级工作记忆，每个角色只保留完成本职责所需的规则、历史和未完成线索。第三层是本轮会话层，只保存当前一次执行中的临时推理和工具输出。第四层是交接包，用于跨角色传递最小必要信息，而不是转发整段历史。
在字段设计上，角色级边界至少应明确三件事：这个角色能读哪些共享事实，这个角色能写回哪些字段，这个角色的局部会话何时归档或丢弃。比如研究角色可以读任务目标与已有证据摘要，但不能改全局完成状态；执行角色可以回写 outputs 和 status，但不应直接重写共享规则；评审角色可以读取候选结果与证据，却不需要继承执行期的全部中间日志。
与 TaskPilots 的映射
映射到 TaskPilots，可以把上下文包理解为“按角色裁剪后的任务记忆投递物”，把消息流转理解为“会话身份与状态迁移的编排层”，把回传契约理解为“角色写回共享状态的唯一入口”。这样控制器发给下游的不是整个项目背景，而是当前角色需要知道的目标、约束、证据和回传格式；下游回来的也不是自由叙述，而是结构化结果、未决问题和证据引用。
如果要再加一个判断标准，可以问一句：这条信息是否真的会帮助下一个角色完成自己的职责？如果不会，就不该进入那个角色的记忆面。和 全局记忆和局部记忆应该如何分层、回传契约不是摘要，而是结构化结果 配合来看，角色级边界其实就是把“谁该看到什么、谁能写什么”进一步落到具体协作节点上。
风险与失效点
常见失控方式
第一类失效，是名义上做了角色隔离，实际上仍在全量透传。角色名字虽然不同，每个节点拿到的却还是同一份长历史。第二类失效，是边界过窄，导致下游缺少完成任务所需的必要事实，只能反复回问。第三类失效，是角色回写权限太宽，任何角色都能把未经验证的猜测写进共享状态。第四类失效，是局部会话不做清理，临时推理越积越多，最后重新膨胀成第二个全局上下文。
还有一个常被忽略的风险，是敏感信息越权扩散。只要系统默认把全部背景交给每个 Agent，权限控制就很容易失守。某些角色也许只该看到脱敏摘要，却因为上下文复用拿到了原始客户数据、内部规则或审批讨论。这不是单纯的成本问题，而是治理问题。
需要人工兜底的地方
凡是涉及共享事实升级、权限放大、对外发送、不可逆写操作或跨角色冲突裁决的节点，都应该保留人工或控制器层的最终确认。原因很简单：角色级边界的价值，在于限制谁能看什么、谁能改什么。一旦允许任意角色直接修改核心状态，边界就会很快失效。
当某个角色请求扩大自己的上下文面，或者要求读取额外敏感信息时，也应有显式审批与审计记录。否则“临时放开一次”会很快演变成默认全量继承。
验证指标
上线前怎么验证
上线前建议做三类验证。第一，最小上下文实验：为同一角色准备“全量历史版”和“角色裁剪版”两个输入，比较完成率、误判率和回问次数。第二，恢复演练：在中断、重试和换人接手时，验证系统是否能仅凭共享状态与角色包继续执行，而不必重放全部历史。第三，权限检查：确认每个角色实际拿到的上下文与预期读取范围一致，没有无意透出敏感字段。
如果条件允许，还可以做一次“交叉角色错投”测试。把研究角色包误投给执行角色，或把评审角色包投给研究角色，观察系统是否能明显暴露输入不匹配问题。若换错包后仍能继续运行，通常说明各角色边界设计得还不够清楚。
上线后怎么持续判断
上线后值得持续跟踪至少五项指标。第一，交接成功率，衡量角色是否能直接基于自己的上下文包继续工作。第二，返工率，检查是否因上下文过宽或过窄导致重复劳动。第三，恢复时间，衡量异步续跑是否真正摆脱了整段历史依赖。第四，角色回问率，观察哪些角色经常说“还缺信息”。第五，局部上下文膨胀率，检查角色包和会话长度是否又开始持续增长。
再加一个治理性指标会很有帮助：越权读取事件数。只要某个角色经常请求额外背景，或被人工发现看到了不该看的信息，说明记忆边界要么设计过宽，要么投递机制没有真正按角色裁剪。
下一步 / FAQ
下一步建议
最实际的第一步，不是上更复杂的 memory 框架，而是先为现有工作流画一张“角色记忆矩阵”。按角色列出三列：必须读取的共享事实、允许回写的字段、只在本轮会话存在的临时信息。只要这张表一清楚，后面的 handoff、回传契约和人工升级点就更容易稳定下来。
第二步再选一条返工最多的链路做试点，把它从“共享整段历史”改成“共享状态加角色包”。通常只改这一条，就能很快看出误判、成本和恢复时间是否下降。
FAQ
是不是所有角色都要有独立 memory store？ 不一定。关键不是存储实例分多少个，而是读取范围、写回权限和会话生命周期是否按角色隔离。
角色包做小了会不会丢上下文？ 会丢掉噪声，但不应丢掉完成当前职责所需的必要事实。是否“做小过头”，要靠回问率和完成率一起看。
共享状态和角色记忆谁更重要？ 两者缺一不可。共享状态负责一致性和恢复，角色记忆负责聚焦和低噪声执行。
组织协作最容易卡在哪？ 最容易卡在谁有权把局部判断升级成共享事实。这个写入门槛如果不清楚，角色边界很快又会重新混回去。