一家政务咨询平台部署了智能体同时为多个办事群众提供政策问答。高峰时段群众甲询问社保转移接续政策群众乙询问公积金提取条件两人几乎同时发起提问。系统却把针对甲问题的部分内容回复给了乙乙收到的回答里混入了社保转移条款与公积金提取毫无关系。群众乙以为政策变了截图发到社区群引发误解。不少人认为这是服务器性能不足加机器扩容就能解决。但串台的根源不在算力不够而在于会话状态在不同用户之间没有隔离干净。一类原因是请求上下文未按用户绑定多个用户的请求并发进入系统时系统没有为每个用户维护独立会话上下文不同用户的对话历史和检索结果可能被混入同一次生成。另一类原因是缓存未按数据Scope隔离系统将中间结果缓存但缓存键的隔离粒度单一——公共政策和个人对话历史用同一层级缓存键甲检索到的政策条文被乙的请求命中。还有一类原因是异步任务结果回填错位智能体拆分出的异步子任务完成后回填结果时未校验任务归属结果被写入了错误的会话。本文基于青山不语AI工作室在部分项目方案中的实践将并发会话隔离归入多租户三层隔离框架以“会话状态与任务归属隔离”作为该框架在并发场景下的子机制展开讨论。隔离标识不是单一session_id而是tenant_id、user_id、conversation_id、request_id、task_id五层分层关联。tenant_id标识租户user_id标识用户conversation_id标识一次会话request_id标识一次请求task_id标识请求内拆分出的异步子任务。五层之间存在归属关系一个task_id属于一个request_id一个request_id属于一个conversation_id一个conversation_id属于一个user_id一个user_id属于一个tenant_id。同一会话内并发的多个任务靠request_id和task_id区分归属——甲的会话中同时发起两个子任务各自携带不同的task_id但共享同一个request_id回填结果时按task_id匹配目标请求不会串到乙的会话。归属链路中任何一层标识缺失或断裂时该数据项不进入生成上下文系统不猜测归属关系。缓存按数据Scope分级隔离不是所有缓存都做用户级物理隔离。数据Scope分为租户级、用户级和会话级租户级数据如公共政策文档、通用知识库缓存键包含tenant_id同租户用户共享用户级数据如个人对话历史、用户画像缓存键包含tenant_id和user_id会话级数据如当前对话的中间检索结果缓存键包含conversation_id。系统在写入缓存时为每条数据标注Scope层级读取时按当前请求的Scope链匹配——租户级缓存同租户可共享会话级缓存仅当前会话可命中。乙的请求不会命中甲的会话级缓存但两人可以共享同一份租户级政策缓存避免重复检索。缓存条目失效时系统按Scope层级清除租户级政策更新时清除该租户的租户级缓存不影响用户级和会话级缓存会话级缓存在会话结束后自动清除。生成前系统做Scope一致性校验不是要求注入上下文的所有知识都属于当前session。公共政策文档属于租户级Scope不属于某个会话但可以注入当前会话的生成上下文。校验检查的是每个待注入数据项的Scope是否与当前请求的Scope链兼容——数据的Scope层级必须等于或高于当前请求的Scope层级。一条会话级数据如果其conversation_id与当前请求不一致Scope校验拦截一条用户级数据只要tenant_id和user_id匹配即可注入一条租户级数据只要tenant_id匹配即可注入。校验不通过的数据不进入生成上下文系统记录冲突原因并重新构建上下文。异步子任务回填结果时同样经过Scope一致性校验结果数据的Scope链必须与目标请求的Scope链一致才允许回填。并发处理多用户时回答串台的核心矛盾是系统在提升并发性能时没有同步建立分层隔离机制。把隔离标识从单一session_id升级为五层分层关联让缓存按Scope分级隔离而非一刀切做用户级物理隔离在生成前做Scope一致性校验而非要求所有数据归属当前会话是从工程层面控制串台风险的方向。在我看来政务、客服这类天然多用户并发的场景串台不是偶发事故而是必须前置处理的工程问题。一个能把甲的数据回给乙的系统问题不在性能不够而在于会话边界和任务归属没有划清。