例如某政务咨询场景，平台部署智能体同时为多个办事群众提供政策问答。高峰时段，群众甲询问社保转移接续政策，群众乙询问公积金提取条件，两人几乎同时发起提问。系统却把针对甲问题的部分内容回复给了乙，乙收到的回答里混入了社保转移条款，与公积金提取毫无关系。这种串台一旦发生，群众可能以为政策变了，截图传播后容易引发误解。

不少人认为这是服务器性能不足，加机器扩容就能解决。但这类串台通常不是单纯由算力不足造成，更常见的问题是会话状态和任务归属没有隔离清楚。一类原因是请求上下文未按用户、会话和当前请求建立明确归属关系，多个用户的请求并发进入系统时，不同用户的对话历史和检索结果可能被混入同一次生成。另一类原因是缓存未按数据Scope隔离，系统将中间结果缓存，但缓存键的隔离粒度单一——公共政策和个人对话历史用同一层级缓存键，甲检索到的政策条文被乙的请求命中。还有一类原因是异步任务结果回填错位，智能体拆分出的异步子任务完成后回填结果时未校验任务归属，结果被写入了错误的会话。

本文基于青山不语AI工作室在部分企业AI Agent定制项目方案中的实践，将并发会话隔离归入多租户隔离框架，以“会话状态与任务归属隔离”作为该框架在并发场景下的子机制展开讨论。

在本文讨论的方案中，仅使用单一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分级隔离，不是所有缓存都做用户级物理隔离。数据Scope分为租户级、用户级、会话级和请求级：租户级数据如公共政策文档、通用知识库，缓存键包含tenant_id，同租户用户共享；用户级数据如个人对话历史、用户画像，缓存键包含tenant_id和user_id；会话级数据如会话维度的上下文摘要，缓存键包含conversation_id；请求级数据如当前检索结果、工具中间结果、临时规划状态，缓存键包含conversation_id和request_id，异步子任务的中间结果再追加task_id。同一conversation里并发的多个request各自携带不同的request_id，请求级缓存按request_id隔离，不会互相命中；同一request里拆分出的多个task共享父request_id但各自携带不同的task_id，子任务中间结果按task_id隔离，回填时按task_id匹配。系统在写入缓存时为每条数据标注Scope层级，读取时按当前请求的Scope链匹配。乙的请求不会命中甲的请求级缓存，但两人可以共享同一份租户级政策缓存，避免重复检索。缓存条目失效时系统按Scope层级清除：租户级政策更新时清除该租户的租户级缓存，不影响其他层级；请求级缓存在请求结束后自动清除。

生成前系统做Scope一致性校验，不是要求注入上下文的所有知识都属于当前session。公共政策文档属于租户级Scope，不属于某个会话，但可以注入当前会话的生成上下文。校验直接按各级ID匹配：租户级数据要求tenant_id与当前请求一致即可注入；用户级数据要求tenant_id和user_id均一致；会话级数据要求conversation_id一致；请求级数据要求conversation_id和request_id均一致。一条会话级数据如果其conversation_id与当前请求不一致，Scope校验拦截；一条请求级数据如果其request_id与当前请求不一致，同样拦截。校验不通过的数据不进入生成上下文，系统记录冲突原因并重新构建上下文。异步子任务回填结果时同样经过Scope一致性校验，结果数据要求task_id所属的request_id与目标请求一致才允许回填。

并发处理多用户时回答串台的核心矛盾，是系统在提升并发性能时没有同步建立分层隔离机制。把隔离标识从单一session_id升级为五层分层关联，让缓存按Scope分级隔离而非一刀切做用户级物理隔离，在生成前做Scope一致性校验而非要求所有数据归属当前会话，是从工程层面控制串台风险的方向。在我看来，政务、客服这类天然多用户并发的场景，串台不是偶发事故而是必须前置处理的工程问题。一个能把甲的数据回给乙的系统，问题不在性能不够，而在于会话边界和任务归属没有划清。企业评估AI Agent定制方案时，不能只看模型效果和并发量，还要看会话状态、缓存和异步任务是否具有清晰的数据边界。