如何隔离不同用户与不同会话的上下文和记忆？

核心回答

隔离要同时覆盖身份、会话、项目范围、存储查询和运行上下文。请求先从认证结果取得tenant_id、user_id，再确认该用户有权访问指定session；消息历史按会话读写，长期记忆按授权的用户或项目范围检索。不能只生成不同session_id，就认为所有数据已经隔离。

身份与范围由服务端传入工具和存储层，不能让模型参数覆盖。缓存、向量检索、附件、后台任务和日志也要携带同样的范围，避免主数据库分开了，其他路径仍串用户。

短期与长期分别隔离

短期状态可以按租户、用户、会话或thread标识组织，记录消息与当前任务；服务端每次读取前检查归属。长期记忆可以在用户范围跨会话复用，但项目约定应绑定project_id，团队共享知识则需要显式授权。

例如同一个用户维护两个项目：A项目使用PostgreSQL，B项目使用MySQL。召回项目记忆时先限定当前项目，再在允许范围内读通用偏好，不能仅凭“数据库配置”语义相近把A规则带进B。用户偏好与项目规则最好保留来源和适用范围，避免被压成一段无边界摘要。

存储和执行怎么落实

关系库查询统一加范围条件；向量检索把授权范围作为硬过滤或采用独立集合，不能先把其他租户内容交给模型再要求忽略。缓存键、对象路径和下载接口都校验归属；高隔离要求可以进一步采用独立数据库、存储或执行环境。

避免模块级可变消息列表被所有请求复用。异步任务显式携带身份、session、run和版本，回调提交前确认任务仍有效。取消或重新回答后，旧回调不应写进新回答。进程内ContextVar可以帮助传播上下文，但本身不构成认证、访问控制或跨进程传输协议。

LangGraph的thread_id用于定位检查点，Store的namespace用于组织跨thread数据；两者都需要应用层绑定用户与权限，标识本身不是访问令牌。

怎样验证隔离

用两个用户、多个会话与项目交错请求，覆盖相同问题、重复ID、缓存命中、后台迟到、文件下载和记忆删除。检查检索候选、工具参数与最终回复均没有越界，不能只观察答案“看起来没串”。

常见追问

同一用户跨会话共享是否违反隔离？ 不一定。共享范围可以按业务明确配置；关键是将允许共享的长期偏好与仅属于某次任务的数据分开管理。

对应教程

参考资料