AI API 接入后会话记忆串号怎么办？
聊天助手、客服助手和 AI 自动化办公流程一旦接入历史上下文，最怕的不是模型答错，而是把 A 用户的上一轮内容带给 B 用户。这个问题通常不是模型本身造成的，而是 session、缓存和日志链路没有隔离清楚。
适用场景：会话变长后才暴露的串号问题
最常见的现场是：用户先问了合同条款，换到另一个客户工单后，模型仍然引用上一份合同；或者客服主管测试时看到正式用户的称呼、订单号和历史偏好。很多新手会把这类能力笼统叫作 GPT 中转，但更规范的说法是 AI 模型接口接入与调用管理。只要接口层保存历史，就必须把 user_id、session_id、tenant_id、业务来源和权限边界作为同一组上下文键处理。
永沃云枢建议先判断串号发生在哪一层：前端是否复用了 conversation_id，后端是否用用户昵称做缓存键，队列是否把上一条 payload 合并进新请求，CCSwitch 配置是否把测试 profile 指到同一个共享上下文服务。不要一开始就调模型参数，先把一次请求从页面按钮追到模型调用记录。
操作步骤：从请求编号追到历史窗口
第一步，在每次开发者 AI 调用里写入不可复用的 request_id，并同时记录 user_id、session_id、tenant_id、model、profile 和 history_count。第二步，用两组测试账号交替提问，问题内容故意写成容易识别的短句，例如“只在 A 账号出现的蓝色发票”。如果 B 账号回答里出现这句话，就说明历史窗口或缓存键已经串了。
第三步，检查缓存和摘要服务。命令可以从本地仓库开始：rg "session_id|conversation_id|cache_key|history" server pages，看是否存在只按路径、IP 或模型名缓存的代码。第四步，检查截断逻辑。有些服务为了省 token，会把最近 N 条消息拼成 summary；如果 summary 没有绑定用户和会话，AI API 接入越稳定，错误传播越隐蔽。
排错路径：不要只看最终回答
排查时至少保存四段证据：前端提交的 JSON、后端组装后的 messages、发送到 AI 模型接口的最终 payload，以及模型返回后的落库记录。若使用 Codex 接入维护代码，让 Codex 先只读扫描调用链，再生成差异说明，不要直接改权限和全局配置。若使用 CCSwitch 配置多模型，确认每个 profile 的 base URL、模型名和日志标签能回指到同一条业务请求。
还要检查“自动续聊”和“相似问题缓存”。AI 自动化办公里常把邮件摘要、工单摘要和知识库答案缓存起来，如果缓存 key 没有包含租户、用户和任务类型，模型调用管理看起来成本下降了，实际却可能把别人的上下文当作命中结果返回。
常见问题/避坑
一个坑是把 session_id 放在前端 localStorage 里长期复用，用户切换账号后旧值没有清理。另一个坑是只在日志里打 user_id，不在实际缓存键里使用。还有团队会把测试账号和正式账号接到同一个“演示会话”，上线后忘记关闭。遇到这些情况，不要用“清空全部历史”作为长期方案，而要修正键设计、权限校验和历史窗口构造。
检查清单：验收到不会串号再上线
验收时确认这些项目：两组账号交替提问不会互相看到私有短句；退出登录后前端 conversation_id 被清理；缓存 key 至少包含 tenant_id、user_id、session_id 和任务类型；日志能按 request_id 还原最终 payload；敏感字段已脱敏但不影响排错；CCSwitch profile 与业务环境一致；Codex 生成的修改只落在会话、缓存和日志相关文件；栏目页、帮助页和 AI API 接入专题、CCSwitch 配置专题、Codex 安装专题、AI 自动化办公专题的说明没有互相矛盾。
完成这些检查后，再看模型效果才有意义。会话隔离是地基，地基不稳时，任何提示词优化都会把问题掩盖得更深。
二次验收样本：把串号做成可复现问题
建议另外准备三类样本：同一用户不同浏览器、同一租户不同用户、不同租户相同问题。每组都写入专属短句，再分别触发普通聊天、客服工单和 AI 自动化办公任务。若只有浏览器切换会串号，多半是前端存储问题；若不同租户也串号，就要优先查服务端缓存和摘要表；若只有定时任务串号，通常是队列消费者复用了上一批参数。
修复后不要只跑一次通过样本，至少连续执行十轮交替请求，并记录每轮的 request_id、history_count 和缓存命中状态。这样下一次更换 AI 模型接口、调整 CCSwitch 配置或让 Codex 修改调用链时，团队能用同一组样本确认模型调用管理没有倒退。
还有一个容易忽略的验收点是客服后台代登录。管理员代用户查看问题时，系统应明确使用被代看的用户会话，还是管理员自己的调试会话，不能两者混在一起。建议在日志里增加 actor_id 和 subject_user_id，避免权限排查时只看到一个 user_id。