核心要点
先看产品语义：是否共享没有唯一答案，取决于"用户期望跨渠道续上对话还是各渠道独立"
区分两层：短期上下文（对话历史）通常按渠道+会话隔离；长期记忆（用户偏好、画像）是否跨渠道共享看需求
隔离维度：用户 × 渠道 × 会话/群组/线程，常见以 (channel, conversationId) 作为隔离边界
群聊 vs 私聊：私聊一般按用户隔离，群聊按群隔离且需区分@对象与多人发言，不能共用一个上下文
并发与一致性：同一会话的消息要串行化处理，配合会话 key 设计与 TTL 过期清理，避免上下文交叉污染与无限膨胀
标准回答
先问"为什么"：共享与隔离取决于产品语义
这道题没有标准答案，关键是先界定产品想要的体验。如果用户期望"在手机端聊到一半，换电脑 Web 端能接着聊"，那就要跨渠道共享；如果是工作群里的任务机器人，群与群、私聊与群聊就必须各自独立。所以我会先把"共享"拆成两个层次分别决策。
两层记忆，分开决策
- 短期上下文（当前对话历史）：决定模型这一轮看到什么。默认按"渠道 + 会话"隔离——飞书私聊和钉钉群聊本就是两段独立对话，混在一起会让模型答非所问。
- 长期记忆（用户偏好、画像、历史结论）：可以跨渠道共享。把它绑定到全局用户身份，无论从哪个渠道进来都能召回"这个人是谁、喜欢什么"。
一句话：上下文倾向隔离，长期记忆按需共享。
隔离维度与会话 key
隔离边界由几个维度组合：用户、渠道、会话/群组/线程。最常用的会话 key 是 (channel, conversationId)，必要时再叠加 threadId（话题/回复线程）或 userId（群里按人分流）。会话 key 唯一确定一段上下文的存储桶，设计时要保证稳定、可推导、且能覆盖群聊分线程这类场景。
群聊与私聊的差异
私聊里一个会话就是一个人，按用户隔离即可。群聊复杂得多：多人发言共享一个群上下文，但 Agent 通常只在被@或命中触发词时响应；要记录是谁说的、回应谁，避免把别人的话当成当前用户的诉求。是否给群里每个人单独建上下文，取决于机器人是"群助理"还是"对群内每个人的私人助手"。
并发与一致性
同一会话可能短时间收到多条消息（用户连发、平台重试）。必须对同一 session key 做串行化处理（队列或锁），否则两条消息并发读写同一段上下文会互相覆盖、产生错乱回复。配合幂等去重防重复。
生命周期与清理
会话上下文要设 TTL 过期或按轮数/长度滚动裁剪，长期不活跃的会话归档或清理，否则存储与上下文会无限膨胀，也带来隐私合规风险。
何时共享、何时隔离（判断）
- 该隔离：不同渠道的对话语义独立、群聊与私聊、不同任务话题、以及涉及敏感/权限不同的场景；
- 可共享：用户级长期偏好与画像、明确做了"多端续聊"承诺的同一用户跨设备场景。
判断准则就一句：上下文混了会不会让用户困惑或泄露？会，就隔离。
常见误区
⚠️ 常见踩坑
最常见的误区是"一刀切"——要么所有渠道全共享一个上下文，导致群里的话串进私聊、答非所问；要么全隔离，连用户的长期偏好都不复用，体验割裂。第二个坑是只用 userId 当会话 key，忽略渠道和群组维度，群聊场景直接错乱。第三个坑是不做并发串行化，用户连发两条消息时上下文相互覆盖。还有人忘了设过期清理，会话无限堆积既费存储又有隐私风险。
追问
追问 1：想做到"换个渠道还能接着上一段对话"，技术上怎么实现？
关键是把短期上下文从渠道解耦，绑定到全局用户身份而非会话 key。先做跨渠道身份打通（显式绑定或共同标识），再把对话上下文以 userId 维度存储，新渠道进来时按 userId 召回最近上下文。但要谨慎：默认仍按渠道隔离，只有用户明确发起"继续上次对话"或产品承诺多端同步时才合并，避免无意中把不相关对话串起来。
追问 2：群聊里 Agent 要不要给每个人单独维护上下文？
看定位。如果是"群助理"，整个群共享一段上下文更自然，Agent 理解群里多人的讨论脉络，但需标注发言人、只在被@时回应。如果是"群里每个人的私人助手"，则按 (群, 用户) 双维度隔离，各自独立。多数任务机器人取折中：群级共享可见历史，但回应聚焦当前@它的人的诉求。
追问 3：同一会话短时间来了多条消息，怎么保证不乱？
对同一 session key 做串行化：用 per-session 队列或分布式锁，保证同一会话的消息按序、互斥地处理，前一条处理完再处理下一条。配合幂等键去重，防止平台重试导致重复。若需要"打断/合并连发消息"，可在入队时做去抖动（debounce），把短时间内多条合并成一次推理，既正确又省成本。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习