feat(iit): Initialize IIT Manager Agent MVP - Day 1 complete
- Add iit_schema with 5 tables - Create module structure and types (223 lines) - WeChat integration verified (Access Token success) - Update system docs to v2.4 - Add REDCap source folders to .gitignore - Day 1/14 complete (11/11 tasks)
This commit is contained in:
@@ -0,0 +1,83 @@
|
||||
# **IIT Manager Agent 技术架构白皮书 (V3.0 生产级架构版)**
|
||||
|
||||
## **1\. 架构愿景：逻辑回归中心，知识驱动未来**
|
||||
|
||||
本架构旨在解决临床研究中 AI 落地最核心的三个矛盾：**“AI 的不可控性”与“医疗的严谨性”**、**“异构系统的碎片化”与“管理的一体化”**、**“数据隐私”与“模型效能”**。
|
||||
|
||||
* **原生编排 (Native Orchestration)**：将核心逻辑与状态机（State Machine）保留在 **Node.js (Fastify) \+ pg-boss** 中。不迷信外部 Agent 框架，确保 SOP 流程在代码级可定义、可测试、可审计。
|
||||
* **薄认知、厚逻辑**：将 **Dify** 定位于高性能的 **RAG Service**。利用其成熟的文档解析与召回管线，而将决策权、权限控制和事务一致性收回到自研后端。
|
||||
|
||||
## **2\. “四层三中心”架构设计**
|
||||
|
||||
### **2.1 架构分层 (Layered Architecture)**
|
||||
|
||||
1. **交互层 (Interaction Layer)**：
|
||||
* **微信/企微终端**：PI 接收周报、患者 AI 咨询及任务提醒。
|
||||
* **Agent Workbench (基于 Ant Design X)**：CRC 处理 AI 建议、执行质控确认的“驾驶舱”。
|
||||
2. **逻辑与智能体层 (Logic & Agent Layer)**：
|
||||
* **Agent Orchestrator**：基于 Node.js 的中央编排器，驱动 pg-boss 任务流。
|
||||
* **Shadow State 机制**：AI 建议在被人类确认前，仅以“影子数据”形式存在。
|
||||
3. **连接适配层 (Connectivity Layer)**：
|
||||
* **EDC Adapter**：非侵入式对接 REDCap (REST API / Webhooks)。
|
||||
* **Dify RAG Adapter**：封装多知识库检索 API，执行向量检索。
|
||||
* **Python Execution Service**：执行 OCR、医学 NER 及复杂统计算法（如 MICE）。
|
||||
4. **基础设施层 (Infrastructure)**：
|
||||
* **Postgres-Only 中枢**：统一管理任务队列、应用缓存及业务数据（iit\_schema）。
|
||||
|
||||
### **2.2 三大中心 (System Centers)**
|
||||
|
||||
* **真理中心 (REDCap)**：临床数据的唯一合法来源。
|
||||
* **状态中心 (RDS Postgres)**：管理 Agent 状态、审计日志、用户映射。
|
||||
* **知识中心 (Dify / PGVector)**：存储数字化方案及医学知识库。
|
||||
|
||||
## **3\. 核心技术机制深度解析**
|
||||
|
||||
### **3.1 影子状态 (Shadow State) 与人机闭环**
|
||||
|
||||
为规避 AI 幻觉带来的数据错误，引入“影子状态”：
|
||||
|
||||
1. **AI 生成建议**：Agent 产生的结果存入 iit\_schema.pending\_actions。
|
||||
2. **证据链溯源**：在 Workbench 中，AI 建议必须与 Dify 返回的原文片段（页码/坐标）强绑定。
|
||||
3. **人类确权**：CRC/PI 确认后，触发事务。
|
||||
4. **正式写入**：调用 EDC Adapter 将数据写入 REDCap，并记录“AI-ID \+ Human-ID”的双重签名。
|
||||
|
||||
### **3.2 基于 Dify 的多知识库 RAG 管线**
|
||||
|
||||
* **多源检索**：针对同一决策，Agent 同时检索“研究方案”、“临床指南”和“历史质控记录”。
|
||||
* **混合召回**：利用 Dify 的向量检索 \+ 全文检索 \+ Rerank 机制，确保上下文（Context）的极端准确。
|
||||
* **脱敏安全**：在 Node.js 调用 Dify 接口前，利用 LLM Gateway 执行 PII (个人身份信息) 的本地化扫描与屏蔽。
|
||||
|
||||
### **3.3 跨体系身份映射 (Identity Mapping)**
|
||||
|
||||
* 建立加密存储的 User-EDC-Credential 体系。
|
||||
* Agent 的每一个动作都通过 API 代理模拟真实用户的 REDCap 权限，确保数据访问的合规性（Audit Trail 符合 21 CFR Part 11）。
|
||||
|
||||
## **4\. 部署与性能优化策略**
|
||||
|
||||
### **4.1 混合云部署蓝图**
|
||||
|
||||
* **AI 控制平面 (SAE)**：Node.js 后端与 Python 微服务运行在 Serverless 环境，根据任务负载弹性伸缩。
|
||||
* **数据底座 (ECS \+ RDS)**：REDCap 运行在 ECS，通过阿里云 VPC 内网与 SAE 通信，降低延迟且数据不出内网。
|
||||
* **Dify 节点**：独立容器部署，仅作为 RAG 接口对内提供服务。
|
||||
|
||||
### **4.2 任务可靠性**
|
||||
|
||||
* 利用 pg-boss 的指数退避重试机制处理 Webhook 丢失或 REDCap 接口超时。
|
||||
* 支持长达 24 小时的长任务监控（如患者体征趋势分析）。
|
||||
|
||||
## **5\. 风险评估与对冲**
|
||||
|
||||
| 潜在风险 | 应对策略 |
|
||||
| :---- | :---- |
|
||||
| **逻辑代码膨胀** | 采用“微引擎化”设计，将质控规则参数化并存储在 JSONB 字段中。 |
|
||||
| **Dify 接口延迟** | 对常用 RAG 背景信息在 app\_cache 中进行短时缓存。 |
|
||||
| **未来扩展性需求** | 预留状态机接口，逻辑同构设计支持未来向 LangGraph 的平滑迁移。 |
|
||||
|
||||
## **6\. 实施路线图 (Milestones)**
|
||||
|
||||
1. **Phase 1: 连接与感知**：打通 REDCap 读写适配器，上线微信端智能周报。
|
||||
2. **Phase 2: 工作站与协同**：完成 Agent Workbench 开发，实现“质控建议-人类确认”的影子闭环。
|
||||
3. **Phase 3: 全自动采集**：开启多模态 OCR 提取，结合 RAG 知识库实现数据的一键同步。
|
||||
4. **Phase 4: 智能化演进**：探索基于多智能体对抗（Critic Loop）的深度质控，并预研 SmartEDC 原型。
|
||||
|
||||
**文档版本**：V3.0 | **最后更新**：2025-12-30 | **维护者**：架构组
|
||||
Reference in New Issue
Block a user