我们在 RAG 对话中，增加了一个快速上传文档的问答环节，但是设计上要求每个session_id只能上传一个文档

为什么呢？我们团队认为，RAG系统增加功能要考虑「易用性、稳定性、资源管控、业务逻辑」四个维度

先抛结论：核心原因：会话（Session）= 单次独立的文档处理场景 session_id 代表你当前一次临时对话/操作会话，系统给它定「只能传1个文档」，本质是为了轻量化、无混乱、不崩溃，具体分6个关键理由：

1. 简化核心业务逻辑（最根本原因）

绝大多数带文档上传的会话（比如AI文档问答、文档解析、单文件处理），设计初衷就是「一次会话只处理一份文档」：

如果允许一个会话传多个文档，系统必须额外解决一堆复杂问题：多文档优先级？用哪个文档回答？多文档内容冲突？多文档解析失败怎么回滚？ → 直接限制「单会话单文档」，业务逻辑瞬间极简，几乎不会出bug。

2. 严格管控服务器资源，防止崩溃

文档上传/解析/存储非常消耗资源（内存、CPU、磁盘）：

这是最基础的服务器安全防护逻辑。

从你的使用角度看：

系统直接限制，帮你规避操作混乱，不用做复杂的文档切换/选择。

session（会话）的特性：临时、短暂、关闭浏览器就失效

多文档管理是文件库/网盘的功能，不是临时会话的功能。

前端不用做多文件上传、预览、切换界面后端不用开发多文档关联、合并、清理逻辑 → 小功能快速实现，不用过度开发。

限制单会话单文档，能有效防止：

「每个session_id只能上传一个文档」 = 用最简单的规则，保证系统不崩溃、操作不混乱、处理不出错 这是轻量化文档交互功能（如AI文档问答、临时解析）的标准设计，不是限制，而是最优解。