多端 AI 会话如何隔离用户？把登录、会话归属与工具权限分开

网页和移动端共用 AI 后端时，需要把三件事分开：请求者是谁、他能否访问这条会话、他能否操作会话中提到的业务记录。只知道一个会话编号，不能完成其中任何一项判断。

下面以售后工单助手说明一个假设架构。用户 A 在手机上查询工单，再在网页继续同一段讨论；用户 B 即使拿到 A 的会话编号，也不能读取这段讨论。与此同时，A 能读取自己的会话，也不代表他能查询所有客户的工单。本文只说明接入时要验证的边界，不构成产品推广或购买建议。

先把业务登录态映射为可信用户

客户端先使用产品原有的登录方式。自有 Node.js 服务验证登录态，得到稳定用户标识，再处理会话请求。请求体中的用户编号只能作为输入数据，不能直接充当身份；会话编号也不是访问凭据。

在自有 Node.js 进程装配 Tansr 的多用户会话服务时，authenticate 把经过验证的业务登录态映射为 endUserId。验证返回空或抛错时，认证失败；带会话编号的端点还要独立检查归属，跨用户访问应拒绝。这样不同客户端可以沿用同一套业务登录体系，而不必把平台调用凭据交给浏览器。

凭据应按所在链路分开：

这里讨论的是嵌入式多用户服务的鉴权路径。命令行共享 Bearer 等部署形态有自己的信任前提，不能直接套成公网用户隔离；Electron 主进程直接接 SDK 的凭据路径，也不能与上述客户端到服务路径混用。正式接入前应按对应官方文档核对字段和部署范围。

会话归属检查之后，工单工具还要授权

假设 A 的手机已创建会话 S，网页端随后以 A 的有效登录态访问 S。应用需要保存用户、产品任务与会话编号的对应关系，才能让网页发现正确的讨论。不能让模型生成的会话标题决定归属，也不能用浏览器缓存代替服务端归属检查。

B 用自己的有效登录态访问 S 时，即使知道编号，也应在会话边界被拒绝。这个结果只说明会话隔离成立，不能据此认定业务数据授权也已完成。

例如 A 在自己的会话中提出“查一下工单 T”，工单工具仍要按可信用户上下文检查 T 的访问权。模型提供的工单编号是待校验参数，不能把模型自称的用户身份当成授权依据；A 的权限若已被撤销，后续工具调用也要遵守业务系统的实际权限。

Serve 接手多会话 REST、SSE 与会话归属等运行接入机制，智能体运行层组织工具调用；工单数据、工具实现和逐条业务授权仍由应用负责。两层检查各自完成，才能让“继续我的讨论”与“访问我有权查看的记录”同时成立。

连接断开、任务结束与历史恢复要分别判断

SSE 传递服务端事件，网络中断首先是连接状态变化。页面不能因为没有新文字就显示“查询成功”，也不能直接认定服务端任务失败；应结合会话状态与实际结果判断，再恢复事件接收和页面显示。

跨进程重启继续讨论还需要显式接会话存储与恢复逻辑。持有会话编号不等于历史已经保存；恢复对话也不会撤销已经执行的业务操作。多副本部署还需把会话请求送回所属副本，文件存储方案不能让多个副本共写同一目录。

自托管会话服务也不等于模型本地运行。采用平台调用路径时，应按实际数据流安排日志、存储和数据去向，不能仅凭服务部署在自己的云里，就承诺全链离线。

选择 SDK 还是 Serve，看现有后端已经承担了什么

如果团队已经有完整的用户会话、事件转发和恢复后端，可以把 Tansr SDK 接入原后端，继续使用现有接入层。若多个客户端需要统一的会话接口，而这些协议与运行接入还没有实现，Tansr Serve 可以提供这部分机制，使团队把接入工作集中到业务登录映射、工具权限、界面和部署接线。两者的取舍取决于实际缺口，不取决于客户端数量本身。

可以用两名测试用户核对四个结果：A 在两个客户端继续自己的会话；B 读取 A 的会话被拒绝；A 在自己会话中查询无权访问的工单被业务工具拒绝；断网或重启后，页面准确呈现连接、执行与保存状态。这些是建议验收项目，不能由接口存在推断为产品已经通过。