# **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 | **最后更�?*�?025-12-30 | **维护�?*：架构组