HaHafeng
0c590854b5
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>
64 lines
5.1 KiB
Markdown
64 lines
5.1 KiB
Markdown
# **潜在的具体风险与问题**
|
||
|
||
即使架构完美，细节仍可能翻车。以下是代码落地时可能遇到的“暗礁”以及针对性的应对策略。
|
||
|
||
## **🔴 风险一：意图路由的“延迟感”**
|
||
|
||
* **位置**：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）\*\*开始造，视觉能力先放进冰箱。” |