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

潜在的具体风险与问题

即使架构完美，细节仍可能翻车。以下是代码落地时可能遇到的“暗礁”以及针对性的应对策略。

🔴 风险一：意图路由的“延迟感”

• 位置：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）**开始造，视觉能力先放进冰箱。”