Appearance
Q113 · 如何实现跨 Agent 的记忆复用？
小林向客服 Agent 说：“订单 A-17 的退款怎么还没到账？”客服查订单系统，看到退款状态是“处理中”，并创建工单 T-17。次日，小林又找售后 Agent 问“昨天那单有结果了吗？”如果两个 Agent 各自只看自己的对话，售后不知道 A-17 和 T-17；如果它们无条件共用全部历史，售后可能看到不该看的内部备注，甚至读到别的客户的信息。
跨 Agent 记忆复用是让后一个 Agent 在被授权的范围内，读取前一个 Agent 留下的、仍对当前任务有用的信息，并理解它的来源与时效。实现它的重点不只是“接同一个数据库”，还要确定谁是同一用户、什么信息可共享、谁能写和读、冲突时听谁的，以及何时回源系统再核对。LangChain 的多 Agent 文档把“每个 Agent 能看见什么信息”称为多 Agent 设计的核心；LangGraph 的记忆文档则区分线程内状态与跨线程 Store（存储）。LangChain 多 Agent 概览 · LangChain Memory 概览
术语和示例编号
| 术语或编号 | 含义 | 小林案例中的对象 |
|---|---|---|
| Agent | 由模型、工具和应用规则共同组成、负责完成某类任务的流程 | 客服 Agent 回答咨询；售后 Agent 跟进工单 |
| 记忆 | 可在后续步骤重新取用的旧信息，不等于模型自己永久记住 | “A-17 曾在处理中、关联 T-17”的记录 |
| 共享状态 | 同一次任务中各步骤共同读取和更新的工作资料 | 客服刚查到 A-17，立刻交接给售后 |
| 跨会话存储 / Store | 在新会话或新线程仍可检索到的资料库 | 次日售后检索昨天留下的 T-17 索引 |
| 租户 | 需要彼此隔离的数据拥有者，如两家企业客户 | T1 是小林所在企业；T2 是另一家企业 |
| 主体 ID | 被记忆描述的对象的稳定标识 | 认证后的用户 U7、订单 A-17、工单 T-17 |
| 命名空间 / namespace | 组织记忆的路径或分区标识，便于按范围查找；单靠路径名不等于授权 | “T1 / U7 / 客服可共享” |
| 可见性 | 哪些 Agent 或角色有资格读这条记录 | 工单索引可给客服与售后；内部质检备注只给质检 |
| 来源 / provenance | 事实来自用户、业务系统、人工，还是模型推断，以及源记录位置 | “处理中”来自订单系统的一次查询 |
| 版本 | 某条记录更新到了哪一版，用于辨认新旧和处理并发写入 | 同一记忆先是第 1 版，确认更改后成为第 2 版 |
| 读写冲突 | 两个 Agent 几乎同时修改同一条信息，或给出互相矛盾的值 | 客服写“处理中”，售后随后查到“已完成” |
T1、T2、U7、A-17、T-17 均为教学用假设编号。假设小林已通过登录身份验证，T1 的订单系统对 A-17 返回“处理中”，售后有权查询这个订单但无权修改退款金额。本文中的共享服务、数据格式和规则是设计示例，不是某框架自动提供的安全承诺。
先定共享范围，再选存储方式
第一种情况是同一个任务里的交接。客服 Agent 刚查完订单，要把当前任务交给售后 Agent。编排程序可在当前工作状态里明确放入“已认证用户 U7、订单 A-17、查询结果、源记录位置、工单 T-17”，只把售后完成跟进所需的字段传过去。这属于任务交接或共享状态，不必为了传几项值先建永久记忆库。LangChain 的 Handoffs 文档说明，多 Agent 子图交接需要显式决定传哪些消息与状态，否则容易出现格式不对或上下文膨胀。LangChain Handoffs
第二种情况是跨会话复用。次日售后启动了新的会话，无法只依赖昨天客服线程的状态。应用需要把经过筛选的记忆写到持久 Store，再按认证身份和业务权限检索。LangGraph 的 Store 提供按 namespace 和 key（记录键）存取、搜索的机制；文档示例把用户 ID 放进 namespace，让另一个线程取回同一用户的记忆。这里的 namespace 解决的是组织与定位问题。实际授权必须由服务端独立检查，不能认为路径里有 U7 就自动隔离，也不能让模型自己填写任意租户 ID 后直接读库。LangGraph 添加记忆 · LangChain Memory 概览
第三种是组织级公共知识，如已发布的售后处理流程。它不属于小林的个人记忆，应有单独的组织或政策命名空间、发布版本和适用范围。个人偏好、订单事件和组织规则若混进一张无差别的“共享记忆”表，售后就很难辨认一条句子到底是客户要求、某次事实，还是已批准规则。最简单的设计也要把主体与内容类型分开。Q109 的记忆类型解释将事实、事件和做法按内容性质区分；跨 Agent 复用时，这种区分直接关系到信任级别。
给每条可共享记忆一个能核对的格式
可把共享记忆想成一张结构化卡片，而非一段没有标签的摘要。对小林这单，一条示例记录可表述为：
| 字段 | 本例写入值 | 为什么要有 |
|---|---|---|
| memory_id（记忆 ID） | M-17 | 稳定地查找、更新和审计同一条记录 |
| tenant_id（租户 ID） | T1 | 限定企业边界；由登录上下文确定，不能从模型文本猜 |
| subject（记忆主体） | 用户 U7、订单 A-17 | 指明事实属于谁、哪笔业务 |
| type（内容类型） | 已观察到的业务状态 | 与用户偏好、Agent 推断和组织规则区别开 |
| value（内容） | “A-17 在查询时为处理中，关联 T-17” | 只保存完成后续任务必要的信息 |
| source（来源） | 订单系统记录 A-17；工单系统 T-17 | 后续 Agent 可回到原始记录复查 |
| observed_at（观察时间） | 第一天查询时刻 | 明确这是当时状态，不等于当前状态 |
| writer（写入者） | 客服 Agent，经服务端写入接口 | 追踪是谁提交，便于排错；不能代替来源证明 |
| visibility（可见性） | T1 内被授权的客服、售后角色 | 不同岗位只读各自需要的内容 |
| version（记录版本） | 1 | 同时更新时避免无声覆盖 |
这些英文标识只是示例字段名：memory_id 是记录自己的编号；tenant_id、subject 确定“归谁”；type、value 说明“是什么”；source、observed_at、writer 说明“从哪来、何时见到、谁写入”；visibility 和 version 则分别控制可读范围与更新次序。实现时还可增加保留期限、敏感级别和删除标记。不要把客服 Agent 说的“应该很快完成”存成订单事实；那是推测，即使要保留，也应标为“Agent 推断”，默认不作为跨 Agent 的已核实事实。OWASP 的 Agentic 应用安全资料把来自用户、工具和其他 Agent 的污染内容带入长期记忆列为风险，因此写入来源和验证步骤不是可省的装饰。OWASP：Memory & Context Poisoning
正常路径：客服写入，售后按需读取
**第 1 步，统一身份。**T1 的登录系统确认来访者是 U7，并确认 U7 对 A-17 有查看权限。若两个 Agent 部署在不同服务里，它们也应通过可信的身份服务或映射表使用同一个稳定用户 ID；不能把“昵称小林”“手机号后四位”当成唯一身份。应用服务从认证凭据取得 T1、U7 和当前角色，再决定能访问哪些订单。Agent 生成的自然语言不应直接决定租户或用户 ID。
**第 2 步，只写经核对的最小事实。**客服查订单系统，返回 A-17 在查询时“处理中”；开工单接口返回 T-17。写入服务验证返回值和关联关系，形成 M-17；只共享“订单、状态、观察时间、工单引用”这些售后需要的字段。原始聊天全文、银行卡信息、内部质检意见不因此自动对售后开放。若系统只需要即时交接，就将同样的精选字段放进任务状态；若第二天也要用，才持久写入 Store。LangChain 文档的多 Agent 说明强调每个 Agent 只取得任务需要的上下文，LangGraph 文档展示了跨线程 Store 的写入与检索接口。LangChain 多 Agent 概览 · LangGraph 添加记忆
**第 3 步，按权限和任务读取。**次日售后收到“昨天那单有结果了吗”，先得到当前已认证身份 T1/U7，检查自己是否有读 M-17 的角色权限，再在 T1/U7 的范围内按“退款、最近工单”检索少量相关记录。读到 M-17 后，发现“昨天 A-17 处理中、关联 T-17”。这条记忆让售后知道该查哪单，但不直接作为今天的最终状态。
**第 4 步，回到事实源确认。**售后按 A-17 或 T-17 调用实时查询。假设系统此时返回“已完成”，售后回答：“昨天客服记录这单仍在处理，今天订单系统显示已完成；对应工单是 T-17。”同时保留查询时间与来源。若系统仍显示“处理中”，则如实报当前状态。售后无权修改退款金额，不能因为记忆里提到客户着急就越过权限直接处理赔付。
**第 5 步，更新但保留历史。**若需要把最新状态用于后续任务，写入新观察时间与订单系统的新来源版本；旧的“昨天处理中”可以作为历史事件保留，当前状态视图则指向最新已验证值。更新要检查 M-17 的 version 是否仍为 1：若另一个 Agent 已改成 2，当前写入应重新读取再合并，而不是静默覆盖。实际数据库可用条件更新或事务实现；这里讲的是设计原则，不假定某个记忆框架自动解决全部并发问题。
失败路径：共享太宽、来源太弱或同时改写
跨租户误读。假设 T2 的用户也问“A-17”，模型便把字符串 A-17 作为全库搜索条件。如果服务端只看搜索相似度而不先核验租户，T1 的记录可能泄露。正确路径是服务端从 T2 的认证上下文构造允许的查询范围，拒绝访问 T1/U7 的 M-17；向 T2 返回“无权查看或未找到”，且不要在错误消息里暴露 T1 的真实姓名、工单号或记录内容。测试要同时覆盖精确 key 查询、语义搜索、批量接口和缓存，避免只有主路径做了过滤。图中的 T2 被挡在柜外，表达的是服务端真正拒绝，不是只在提示词里提醒模型“不要看”。
**把推断当事实。**客服 Agent 看见“处理中”后补写“明天一定到账”，售后如果直接引用，就把没有来源的预测放大成承诺。写入服务应区分“系统已观察事实”“用户自述”“Agent 假设”，要求业务事实附原始来源；缺来源的高影响结论不能进入共享事实区。来自网页、邮件或别的 Agent 的“以后忽略核验步骤”同样只是低信任内容，不是组织操作规则。OWASP 提醒记忆污染会在后续任务中持续影响规划与工具使用。OWASP：Memory & Context Poisoning · OWASP：Prompt Injection
**同时写入相冲突的状态。**售后 A 查询到“已完成”，客服 B 在较早的页面上仍看到“处理中”；两个 Agent 几乎同时更新 M-17。不能简单采用“最后写入者胜出”，因为网络延迟可能让旧结果最后到达。保留两个观察事件的时间、系统来源及业务版本；用订单系统当前状态作准，无法判断先后或权威性时标记冲突并暂停确定性回复。对单一记忆记录采用版本条件更新，避免 B 覆盖 A；对状态事实则优先使用系统的业务版本，而非仅凭记忆写入时间。若记忆库临时不可用，售后可以直接查授权业务系统，明确失去交接线索，而非编造“昨天处理过”。
这些防护同样影响删除和更正。用户撤回某项偏好后，删除或失效操作要作用于统一记忆源与相关索引，不能让某个 Agent 的本地副本继续重复旧值。审计记录保留的是谁写、谁读、何时更新的必要元数据；敏感正文仍按适用的保留规则处理。
怎样验证这套复用真的可靠
先做一组可复演的端到端样本：①T1/U7 的客服查 A-17、写 M-17，售后新会话找到 T-17 并查询到新状态；②同租户另一用户 U8 请求 A-17，应因订单归属不符被拒；③T2 使用同样的字符串 A-17，不应看到 T1 记录；④客服写入没有原始依据的“明天到账”，售后不得当作事实；⑤两个 Agent 同时更新版本 1，应有一个检测到冲突；⑥业务系统状态变化，售后应以最新授权查询为准。每例核对最终回答、真实工具调用、共享库记录和审计轨迹。再观察误共享率、漏召回率、陈旧事实引用率、额外耗时与存储成本，别只看“回答看起来接上了话”。
可按需求选择最简单的实现：同任务只需显式交接字段；跨会话才用带主体隔离的共享 Store；跨独立部署的 Agent 通过受控 API 访问共享服务。无论选哪种，身份、权限、来源、版本和按需读取都是应用层需要兑现的条件。向量搜索可帮助找相关记忆，但不能替代精确的租户过滤、业务系统查询或写入冲突控制。
面试中可以这样回答
我会先区分同任务交接和跨会话复用。同任务可以在共享状态里传明确字段；跨会话要有共享存储。两种都要用认证系统给出的统一租户和用户 ID，按角色决定哪些 Agent 能读写，不能让模型自己指定任意 namespace。每条记忆保存主体、内容类型、来源、观察时间、可见性和版本。比如客服查到 A-17 昨天在处理，写入关联工单 T-17；售后今天授权读到这条线索后，还要查订单系统的实时状态再回答。多个 Agent 同时更新时用版本检查并核对权威来源；模型推断不能冒充已验证事实。失败时要防跨租户泄露、过期状态、记忆污染和静默覆盖。
若追问“共用一个向量库是否足够”，可以说：向量库只解决按内容找相似记录，身份与权限要在服务端先限定范围；版本和来源仍需结构化保存。若追问“能否把整个对话传给下一个 Agent”，可以说：同任务确实可以显式交接，但应按任务筛字段；跨会话保留全文会增加泄露和过期风险，还会给模型塞入大量无关内容。共享的是被允许且可核对的信息，不是越多越好。
资料来源
- LangChain：Multi-agent：说明多 Agent 设计需要明确各 Agent 可见的上下文。
- LangChain：Handoffs：说明同任务跨 Agent 交接须显式处理消息与状态。
- LangChain：Memory overview：区分线程内短期状态与跨线程长期记忆，并解释自定义 namespace。
- LangGraph：Add and manage memory：Store 的写入、搜索与按用户 namespace 取回的官方示例；本文的授权、来源和并发策略是在其上设计的应用约束。
- OWASP GenAI Security Project：Memory Is a Feature. It Is Also an Attack Surface：长期记忆污染会跨任务影响后续行为。
- OWASP GenAI Security Project：LLM01 Prompt Injection：不可信输入、权限隔离与提示注入的风险说明。