Document async optimization split

ai_knowledge_base_v2/development_records/2026-07-08-concurrency-optimization-plan.md

@@ -197,3 +197,31 @@
 1. 本阶段仍是同步 `httpx.stream`，一个请求生成期间仍会占用当前 worker 执行资源。
 2. 用户端能更快看到模型输出，但飞书检索阶段仍在首字之前完成；首字时间还会受飞书读取耗时影响。
 3. 多 worker 全局排队、共享飞书缓存、异步飞书读取仍需在阶段 3 和阶段 4 继续处理。
+
+## 阶段 3 拆分记录
+
+2026-07-08 进入第三阶段前评估当前代码边界。
+
+当前判断：
+
+1. 飞书检索、RAG 构建、聊天消息落库和模型调用仍串在同一条同步链路中。
+2. 当前工作区已有知识库检索相关未提交改动，包括按标题筛选文档、段落相关性截取、对话历史和摘要注入。
+3. 如果直接把飞书服务整体改成 async，容易把“检索准确性改动”和“并发性能改动”混在同一个提交里，后续回滚和排查都会变难。
+
+阶段 3 拆分为两步：
+
+1. 阶段 3A：先异步化模型长连接流式调用，让模型生成期间不长期占用同步 worker 线程。
+2. 阶段 3B：再异步化飞书读取和搜索接口，并同步梳理 RAG 构建的数据库会话边界。
+
+阶段 3A 设计约束：
+
+1. 不修改知识库检索排序和内容截取逻辑。
+2. 不调整数据库 schema。
+3. 不改变用户端 SSE 协议。
+4. 保留当前队列兜底，避免 async 改造期间请求无限进入外部服务。
+
+阶段 3B 预留事项：
+
+1. 飞书 token、wiki node、children、docx/file 文本缓存需要与阶段 4 Redis 缓存一起设计。
+2. async DB session 是否引入，需要结合 SQLAlchemy 连接池和迁移成本单独评估。
+3. 如果短期不引入 async DB session，飞书/RAG 可以先使用独立的异步外部请求层，DB 读写仍保持同步但缩短持有时间。