HaHafeng
66255368b7
Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
83 lines
5.0 KiB
Markdown
83 lines
5.0 KiB
Markdown
# **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 | **维护者**：架构组 |