docs(iit): Add IIT Manager Agent V2.9 development plan with multi-agent architecture

Features:
- Add V2.9 enhancements: Cron Skill, User Profiling, Feedback Loop, Multi-Intent Handling
- Create modular development plan documents (database, engines, services, memory, tasks)
- Add V2.5/V2.6/V2.8/V2.9 design documents for architecture evolution
- Add system design white papers and implementation guides

Architecture:
- Dual-Brain Architecture (SOP + ReAct engines)
- Three-layer memory system (Flow Log, Hot Memory, History Book)
- ProfilerService for personalized responses
- SchedulerService with Cron Skill support

Also includes:
- Frontend nginx config updates
- Backend test scripts for WeChat signature
- Database backup files

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/03-业务模块/IIT Manager Agent/05-测试文档/潜在的具体风险与问题.md

@@ -0,0 +1,64 @@
+# **潜在的具体风险与问题**
+
+即使架构完美，细节仍可能翻车。以下是代码落地时可能遇到的“暗礁”以及针对性的应对策略。
+
+## **🔴 风险一：意图路由的“延迟感”**
+
+* **位置**：IntentService (Day 20-21)  
+* **问题**：用户发一句话，系统先调一次 LLM (路由)，再调一次 SOP/ReAct (执行)。  
+* **后果**：响应延迟 \= LLM(路由) \+ LLM(执行) \+ 网络开销。可能导致用户发完消息后 **5-8 秒** 才有反应。在微信的即时通讯场景下，这个体感很差，用户容易认为系统卡死。  
+* **对策**：  
+  1. **流式欺骗 (UX Trick)**：收到消息立刻回一个“正在思考...”或“正在查询...”的状态（企业微信 API 支持中间态更新或 typing 状态）。  
+  2. **快速通道 (Fast Path)**：对于极短的、特征明显的指令（如“质控”、“报表”、“帮助”），先用 **正则 (Regex) / 关键词 (Keywords)** 进行拦截。只有正则拦截不住的复杂长句，再走 LLM 意图路由。  
+     * *原则*：**混合路由 \> 纯 LLM 路由**。
+
+## **🔴 风险二：ReAct 的“多嘴”风险**
+
+* **位置**：ReActEngine (Day 22-23)  
+* **问题**：ReAct 的核心机制是“思考-行动-观察”循环。模型倾向于在思考过程中输出大量中间步骤，例如：  
+  * *AI Thought*: "用户想查 P001，我需要先调用 search 工具，然后..."  
+  * *AI Thought*: "哎呀，没查到数据，可能需要换个参数..."  
+* **后果**：如果将这些中间思考过程（Internal Monologue）全部实时推送给用户，用户会觉得“这个机器人话痨”、“不够干练”甚至“不自信”。  
+* **对策**：  
+  1. **UI 静默处理**：只把 Final Answer 发送给用户。  
+  2. **调试可见**：中间的 Trace (思考轨迹) 只存入后台日志，或者仅在 Admin 管理端的 Debug 模式下显示，用于排查问题。
+
+## **🔴 风险三：SOP 状态机的“死锁”**
+
+* **位置**：SopEngine (Day 8-9)  
+* **问题**：SOP 流程中经常包含“人工介入”环节。例如，如果 SOP 走到了 review\_required（等待人工复核）节点，流程会暂停。如果 CRC 一直不点击确认，或者忘记处理，这个任务就会一直挂在内存或队列中。  
+* **后果**：pg-boss 可能会认为任务超时（Timeout），触发反复重试机制，最终判定失败（Failed），导致流程异常终止。  
+* **对策**：  
+  1. **区分状态**：在系统设计中严格区分 **“系统阻塞 (System Blocking)”** 和 **“业务等待 (Business Waiting)”**。  
+  2. **挂起机制**：如果是“等人”，任务状态应设为 SUSPENDED（挂起）。此时应从活动队列中移除，不再占用 Worker 资源。  
+  3. **唤醒机制**：当 CRC 在前端点击“确认”后，触发一个回调，创建一个新的 Job 来唤醒流程，继续执行后续步骤。
+
+## **3\. 给 2 人团队的“瘦身版”执行建议**
+
+基于 V2.6 计划，为了确保在有限人力下 100% 交付核心价值，建议执行以下 **“瘦身”** 策略：
+
+### **✂️ 裁剪清单 (不做或延后)**
+
+1. **\[延后\] Phase 6 全阶段 (视觉能力)**：放到 V3.0 再说。目前的文本交互和结构化数据处理已经足够复杂，且 OCR 准确率调优是个无底洞。  
+2. **\[裁剪\] Phase 5 的语义记忆 (pgvector)**：暂时只做简单的文本记录（如 JSON 或 Markdown）。跨度极大的语义召回在初期并非刚需。  
+3. **\[简化\] 伦理合规检测 (T11.3)**：伦理规则极度复杂且非结构化。建议先写死几条最核心的规则（如“知情同意日期必须早于入组日期”），暂不做通用的伦理引擎。
+
+### **✨ 聚焦清单 (必须做好)**
+
+1. **P0: ToolsService 的健壮性**：这是整个系统的地基。一定要加上 V2.3 文档中提到的 **“字段模糊映射”**，否则 LLM 根本调不通工具，体验会崩塌。  
+2. **P0: 每日早报 (Morning Brief)**：这是用户（PI）感知最强的功能。一定要做得漂亮、准时，这是体现 Agent “主动性”的关键。  
+3. **P0: 意图路由的混合模式**：正则 \+ LLM 双保险，这是保证响应速度和降低 Token 成本的关键。
+
+## **4\. 最终评价**
+
+这份 **V2.6 计划** 是一个经过深思熟虑的、高水平的架构设计。
+
+* **它懂业务**：SOP 状态机完美解决了医疗合规与流程锁定的痛点。  
+* **它懂用户**：双脑架构（ReAct \+ SOP）解决了“机器人太死板”的交互体验痛点。  
+* **它懂工程**：极简架构（Postgres-Only \+ Service Class）解决了小团队维护复杂微服务的痛点。
+
+**结论**：只要你们能忍住不去做“视觉识别”和“复杂语义记忆”这些锦上添花的功能，按部就班地把前 5 个 Phase 做完，这将是一个在医疗垂直领域极具竞争力的产品。
+
+**最后一步建议：**
+
+把这份文档发给团队，然后开一个 **Kick-off Meeting**，明确告诉大家：“我们要造的是**双脑 Agent**，但我们从\*\*左脑（SOP）\*\*开始造，视觉能力先放进冰箱。”