# **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 | **维护者**：架构组