Files

HaHafeng 66255368b7 feat(admin): Add user management and upgrade to module permission system

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

2026-01-16 13:42:10 +08:00

5.0 KiB

Raw Blame History

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)

交互层 (Interaction Layer)：
- 微信/企微终端：PI 接收周报、患者 AI 咨询及任务提醒。
- Agent Workbench (基于 Ant Design X)：CRC 处理 AI 建议、执行质控确认的“驾驶舱”。
逻辑与智能体层 (Logic & Agent Layer)：
- Agent Orchestrator：基于 Node.js 的中央编排器，驱动 pg-boss 任务流。
- Shadow State 机制：AI 建议在被人类确认前，仅以“影子数据”形式存在。
连接适配层 (Connectivity Layer)：
- EDC Adapter：非侵入式对接 REDCap (REST API / Webhooks)。
- Dify RAG Adapter：封装多知识库检索 API，执行向量检索。
- Python Execution Service：执行 OCR、医学 NER 及复杂统计算法（如 MICE）。
基础设施层 (Infrastructure)：
- Postgres-Only 中枢：统一管理任务队列、应用缓存及业务数据（iit_schema）。

2.2 三大中心 (System Centers)

真理中心 (REDCap)：临床数据的唯一合法来源。
状态中心 (RDS Postgres)：管理 Agent 状态、审计日志、用户映射。
知识中心 (Dify / PGVector)：存储数字化方案及医学知识库。

3. 核心技术机制深度解析

3.1 影子状态 (Shadow State) 与人机闭环

为规避 AI 幻觉带来的数据错误，引入“影子状态”：

AI 生成建议：Agent 产生的结果存入 iit_schema.pending_actions。
证据链溯源：在 Workbench 中，AI 建议必须与 Dify 返回的原文片段（页码/坐标）强绑定。
人类确权：CRC/PI 确认后，触发事务。
正式写入：调用 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)

Phase 1: 连接与感知：打通 REDCap 读写适配器，上线微信端智能周报。
Phase 2: 工作站与协同：完成 Agent Workbench 开发，实现“质控建议-人类确认”的影子闭环。
Phase 3: 全自动采集：开启多模态 OCR 提取，结合 RAG 知识库实现数据的一键同步。
Phase 4: 智能化演进：探索基于多智能体对抗（Critic Loop）的深度质控，并预研 SmartEDC 原型。

文档版本：V3.0 | 最后更新：2025-12-30 | 维护者：架构组

5.0 KiB Raw Blame History Unescape Escape