阿里面试官追问："你的Agent协作系统，谁该知道什么、谁不该知道什么？ 我说：各记各的就行好，共享的放一个公共区域。面试官没说话了。

单Agent系统的记忆设计，核心问题是"记不记得"。而多Agent协作的记忆设计呢，核心问题就变成了"谁该记、记在哪、给谁看"。

上周有个伙伴找我复盘阿里的面试，面试官问了一个很有意思的问题：你们那个Agent协作系统，记忆是怎么设计的？

他想了想，说我们用的是短期记忆加长期记忆，短期的放当前任务上下文，长期的存经验积累。面试官点了点头，追问了一句：那多个Agent之间呢？谁该知道什么、谁不该知道什么，你考虑清楚了吗？

他愣了一下，说大家各记各的就行了，共享的东西放一个公共区域。面试官没说话，停顿了一会儿，又问：那你告诉我，一个Agent写了一条数据，写进共享记忆还是写进它自己的长期记忆？触发条件一样吗？他说应该差不多吧。面试官笑了笑，没再追问，但他知道问题出在哪了——他只考虑了"一个Agent怎么记东西"，从来没想过"多个Agent之间，记忆的归属权和可见性怎么划分"。

这个细节在大部分Agent教程里不会提，因为单Agent场景压根不存在这个问题。今天就把多Agent协作的记忆架构讲清楚。

一、单Agent记忆 vs 多Agent记忆：本质区别在哪

单个Agent的记忆呢，不管你是短期的还是长期的，它服务的对象都挺单一的，就是它自己嘛。但是在多Agent协作里面，记忆就多出来了一个全新的维度，那就是归属权和可见性。

打个比方好了，一个团队里面，每个人都有自己的工作笔记，这就是个人记忆嘛。但是团队也需要一个共享的项目文档，这就是共享记忆。如果所有人的笔记都混在一起了，谁都看谁的，那肯定会乱套的。但是如果完全不共享呢，团队协作也就无从谈起了。

所以说在多Agent场景下，记忆通常要分成三个层次才行，而不是简单的"短期/长期"那么二分：

二、个体短期记忆：每个Agent只关心自己手头的活

在多Agent系统里面，每个Agent通常只会拿到和自己任务直接相关的上下文。它不会把整个协作过程的所有信息一股脑地塞给它。

举个例子好了，一个内容生产团队里面有三个Agent：选题Agent、写作Agent、审核Agent。任务是产出一篇关于新品发布的推文。

【选题Agent的短期记忆】- 当前任务:根据品牌调性生成3个候选选题- 输入:产品资料、历史爆款标题- 输出:选题A"这个夏天最该换的居家好物"【写作Agent的短期记忆】- 当前任务:基于选题A撰写正文- 输入:选题A的具体描述、字数要求、语气要求- 输出:一篇800字草稿【审核Agent的短期记忆】- 当前任务:检查写作Agent的草稿是否合规- 输入:草稿全文、品牌敏感词库- 输出:通过 / 需要修改的具体位置

你看啊，写作Agent它根本就不需要知道选题Agent当初否决了另外两个候选选题。它也不需要知道审核Agent用的是哪套敏感词规则。它只需要拿到"选题A"这一个结果就够了。这种"按需传递"的设计呢，本质上就是在给每个Agent的短期记忆做隔离和裁剪。这样做的目的就是为了避免不相关的信息互相干扰嘛，也避免上下文爆炸。

三、个体长期记忆：每个Agent攒自己的"专业经验"

和任务型Agent类似，多Agent系统里面的每个Agent也会积累自己专属的长期记忆。但是因为分工明确嘛，这些经验往往具有很强的专业针对性。

// 写作Agent的长期记忆{ "agent": "写作Agent", "type": "写作偏好", "content": "该品牌历史爆款标题偏好'反问句+场景化'风格， 例如'你家的沙发,是不是已经三年没换过了?'"}

// 审核Agent的长期记忆{ "agent": "审核Agent", "type": "违规经验", "content": "过去曾因'全网最低价'这类绝对化用词被判定违规， 需要重点标记此类表述"}

你看这两条记忆，它们分别只属于写作Agent和审核Agent，彼此之间是不会共享的。写作Agent不需要知道审核规则的细节嘛，它只需要产出内容就行了。审核Agent也不需要知道写作风格偏好是什么，它只负责挑毛病。各司其职、各记各的，这就是多Agent系统长期记忆设计的第一原则。

四、共享记忆：整个协作系统的"公共看板"

除了每个Agent自己的记忆之外，多Agent系统还需要一层所有相关Agent都能读写的共享记忆。业内常把它叫做"黑板系统"（Blackboard），或者"全局状态"（Global State/Shared Scratchpad）。

它记录的通常是这些内容：

◆当前整体任务进展到哪一步了、谁负责哪一步◆每个Agent已经产出的中间结果是什么◆需要跨Agent同步的关键决策和约束条件有哪些

继续用内容生产团队的例子来说好了：

// 共享黑板{ "task_id": "content_20260723", "current_stage": "审核中", "history": [ {"agent": "选题Agent", "output": "选定选题A：反问句风格新品推文"}, {"agent": "写作Agent", "output": "800字草稿已生成，见draft_v1.docx"}, {"agent": "审核Agent", "output": "发现1处违规表述，退回写作Agent"} ], "constraints": ["禁止使用绝对化用词", "字数控制在750-850字"]}

当审核Agent发现问题了，需要退回给写作Agent修改的时候，写作Agent它不需要重新去问一遍"选题是什么、字数要求是多少"。它直接从共享黑板里面读取这些信息就行了。然后再加上审核Agent刚刚写入的"具体违规位置"，就能开始第二版修改了。这就是共享记忆存在的意义。让多个Agent之间的协作有一个共同的、实时更新的"事实来源"，避免信息在传递过程中失真或者遗漏。

五、数据什么时候写入，写进哪一层？

在多Agent场景下，"写入时机"这个问题要拆成两层来看。一个是写进共享记忆，另一个是写进个体长期记忆。它们的触发条件不完全一样。

1. 每个Agent完成自己的子任务后，立即写入共享记忆

这是最高频的写入动作了。只要某个Agent完成了自己负责的那一步，它的产出结果就要立刻同步到共享黑板上，供下一个环节的Agent去读取。

写作Agent完成草稿 → 立即写入共享记忆： "写作Agent已产出draft_v1.docx，等待审核"

这一步几乎不需要去判断"值不值得记"。只要是协作链条上的关键产出，就必须写入。否则下游Agent根本就无从获知上游发生了什么。

2. 任务整体结束后，各Agent复盘并写入各自的长期记忆

和任务型Agent的逻辑类似，当整个协作任务完成后，比如说这篇推文最终审核通过了、发布成功了，每个Agent会分别对自己负责的那部分去做复盘。然后把有价值的经验写入各自的长期记忆里，而不是写进共享区域。

写作Agent复盘："反问句+场景化"风格这次通过率高, 写入自己的长期记忆，作为下次选词参考审核Agent复盘："绝对化用词"这类问题出现频率较高, 写入自己的长期记忆，作为下次重点审查项

3. 出现跨Agent冲突或反复退回时，触发协调层的记忆写入

在多Agent协作中，经常会出现"来回拉扯"的情况。比如说写作Agent和审核Agent的标准打架了，草稿被退回了三次都没通过。这种情况下呢，通常会有一个协调或管理层Agent（Orchestrator）来介入。它会把这类冲突记录下来，写入一个更高层级的记忆里：

{ "type": "协作冲突记录", "content": "写作Agent与审核Agent在'营销话术边界'上 连续3次意见不一致，建议后续在选题阶段 提前引入审核规则作为约束条件", "resolution": "已在共享黑板的constraints中新增预置规则"}

这类记忆的价值在于优化协作流程本身。它不是让某个Agent变聪明，而是让整个系统下次少走弯路。这也是多Agent场景独有的一种记忆。单Agent系统根本就不会产生"协作冲突"这种问题。

4. 用户/人工介入纠正时，同时更新共享记忆和相关Agent的长期记忆

如果人工在协作过程中介入并做了修改，比如说运营同学直接把审核Agent判定"违规"的表述改成了"合规"的，这个修正信号就需要双向写入。既要更新共享黑板里面的当前状态，也要写入审核Agent的长期记忆，提醒它"这类表述其实是被允许的"。

六、一个完整例子：三个Agent协作发一篇推文

我们把整个流程串起来看一遍哈。

【任务启动】共享黑板初始化→ 写入任务目标、初始约束条件【选题Agent工作】→ 读取长期记忆:历史爆款风格偏好→ 产出选题A→ 写入共享黑板:"选题已确定为A"【写作Agent工作】→ 从共享黑板读取选题A(不关心其他候选选题)→ 读取自己的长期记忆:偏好反问句风格→ 产出草稿v1→ 写入共享黑板:"草稿v1已完成"【审核Agent工作】→ 从共享黑板读取草稿v1→ 读取自己的长期记忆:警惕绝对化用词→ 发现违规表述,判定不通过→ 写入共享黑板:"草稿v1未通过,违规位置在第二段"【写作Agent二次工作】→ 从共享黑板读取审核反馈(具体到第二段)→ 修改后产出草稿v2→ 写入共享黑板:"草稿v2已提交"【审核Agent二次工作】→ 通过,任务完成【任务结束,各自复盘】→ 写作Agent:将"反问句风格审核通过率高"写入自己的长期记忆→ 审核Agent:将"这类违规高频出现"写入自己的长期记忆→ 协调层(如有):记录"两轮修改后通过", 评估是否需要优化选题阶段的预置约束

整个过程中，共享记忆就像一条流水线上的传送带。每个Agent把自己的产出放上去，下一个Agent接着处理。而个体长期记忆呢，就像是每个工位工人自己的经验笔记，跟别的工位无关，只影响自己下次怎么干得更好。

写在最后

单Agent系统的记忆设计，核心问题是"记不记得"。而多Agent协作的记忆设计呢，核心问题就变成了"谁该记、记在哪、给谁看"。

设计这类系统的时候，有三条经验值得记住：

1.该隔离的要隔离。不是所有信息都要塞给每个Agent，按需分发才能避免上下文膨胀和信息干扰。2.该共享的要及时共享。协作链条上的关键产出必须实时同步，否则下游Agent看不见上游发生了什么。3.协作本身也值得被记住。多个Agent之间反复出现的冲突和摩擦，本身就是一种值得沉淀的经验，能帮系统在下一次协作时更顺畅。

说到底啊，多Agent记忆设计考验的不是单个模型有多聪明。而是这套"团队"有没有把该说的话说到位、该记的事记对地方。

你设计Agent协作系统的时候，有没有遇到过类似的记忆归属问题？评论区聊聊，看看大家都是怎么处理的。