# **IIT Manager Agent V4 完整产品需求文档 (全量集成版)** ## **1\. 引言** ### **1.1 项目背景** 在研究者发起的临床试验(IIT)中,数据质量的核心痛点在于“过程失控”。传统的 EDC 系统(如 REDCap)是静态的记录工具。IIT Manager Agent V4 旨在通过“自研逻辑编排 \+ Dify 知识库赋能”,构建一个具有主动意识、实时质控、多端协同的数字科研团队。 ### **1.2 核心目标** * **主动任务化**:将 Protocol(方案)转化为主动驱动的任务流,而非被动的数据填报。 * **医疗级合规**:通过“影子状态”机制,确保 AI 建议在进入真理源(REDCap)前经过人类确权。 * **规模化品牌**:通过“企微中枢 \+ 小程序落地”解决 100+ 项目同时运行时的品牌归属感与触达效率。 ## **2\. 产品总体架构:原生编排 \+ 外部认知** 系统放弃了黑盒 Agent 框架,采用\*\*“大脑与图书馆”\*\*分离的架构: * **逻辑大脑 (Node.js \+ pg-boss)**:位于后端,负责状态机流转、影子数据处理、权限校验及异构系统调度。 * **知识图书馆 (Dify RAG)**:负责非结构化文档(方案、指南、手册)的解析与向量检索,作为 AI 的认知增强。 ## **3\. 终端与角色矩阵 (Endpoint & Role Matrix)** 系统通过“基础角色 \+ 扩展权限”模式,实现跨终端的紧密协作。 | 角色 | 核心诉求 | 推荐终端 | 核心交互逻辑 | | :---- | :---- | :---- | :---- | | **项目负责人 (PI)** | 宏观进度、合规审批、学术报表 | **企业微信 (通知) \+ 微信小程序 (查看)** | 接收企微通知,在小程序查看品牌化报表并审批 | | **协调员 (CRC)** | 录入数据、复核建议、管理随访 | **REDCap (录入) \+ PC Workbench (复核)** | 尊重 REDCap 录入习惯,在工作站处理 AI 质疑 | | **患者 (受试者)** | 访视提醒、依从性引导、医学咨询 | **个人微信 (H5/小程序)** | 接收由 Agent 以 CRC 名义发送的企微消息 | | **系统管理员** | 项目初始化、规则配置、RAG 维护 | **PC 端 (Admin Portal)** | 数字化方案、配置字段映射、管理多租户 | ## **4\. 核心功能模块与 Agent 矩阵** ### **4.1 数据质控 Agent (严谨的监察员)** * **逻辑**:通过 Webhook 监听 REDCap 录入 \-\> 调用 Dify 检索方案规则 \-\> 发现逻辑冲突 \-\> 生成影子质疑 (Pending Action)。 * **参数**:Temperature \= 0,追求极致确定性。 ### **4.2 任务驱动引擎 (数字指挥官)** * **逻辑**:根据项目初始化定义的 Visit Schedule 计算访视窗 \-\> 触发 pg-boss 延时任务 \-\> 自动发送微信提醒。 ### **4.3 患者随访 Agent (温暖的协调员)** * **逻辑**:基于 RAG 知识库回复患者咨询 \-\> 识别 SAE 风险 \-\> 自动提醒 CRC 介入接管。 * **参数**:Temperature \= 0.7,保持医学严谨的同时具有亲和力。 ### **4.4 汇报 Agent (智能汇报者)** * **逻辑**:自动汇总 REDCap 进度数据 \-\> 生成智能报表草稿 \-\> 推送至 PI 微信确认。 ## **5\. 操作边界:双轨并行原则** 为了降低推广阻力,系统明确划分了 REDCap 与 Workbench 的操作边界: * **REDCap 原生录入**: * **场景**:手动、少量、常规的临床数据录入。 * **AI 表现**:后台静默质控,仅通过 EM 插件在页面顶端显示微提醒。 * **AI Workbench**: * **场景**:化验单 OCR 批量采集、AI 建议的深度复核(同屏对比证据链)、多中心映射配置。 * **AI 表现**:作为主要处理界面,展示推理过程与原文引用。 ## **6\. 核心机制:影子状态机 (Shadow State)** 所有 AI 建议必须经过以下生命周期,严禁 AI 直接修改 REDCap 数据: 1. **PROPOSED (影子建议)**:Agent 发现问题,记录于 pending\_actions 表,包含引用页码及推理逻辑。 2. **APPROVED (人类确权)**:CRC 在 Workbench 点击“确认”或 PI 在小程序点击“审批”。 3. **EXECUTED (正式执行)**:系统通过 EDC Adapter 调用 API 回写至 REDCap,并生成审计日志。 ## **7\. 规模化部署与微信集成方案** 针对“100 个项目、47 家医院”的规模化场景: ### **7.1 通知中枢 (企业微信)** * 使用壹证循统一认证的企微主体作为“推送管道”。 * 针对每个研究项目创建“自建应用”,应用名可设置为“XX 项目研究组”,降低商业感。 ### **7.2 品牌落地 (小程序)** * PI/CRC 从企微卡片跳转至微信小程序。 * **动态渲染**:小程序根据 project\_id 自动加载对应医院的 Logo、主题色和项目名称,给足 PI“学术归属感”。 ## **8\. 技术底座与安全合规** ### **8.1 基础设施** * **数据库**:Postgres-Only 架构,利用 iit\_schema 实现物理隔离。 * **集成层**:REDCap External Module (EM) 侧挂插件 \+ Node.js REST API 适配器。 ### **8.2 安全与 GxP** * **Token 安全**:所有 REDCap API Token 使用 AES-256-GCM 高强度加密存储。 * **脱敏引擎**:上下文进入 LLM 前,本地网关执行 PII(个人身份信息)自动脱敏。 * **审计链**:记录从 AI 推理原文到人类点击确权的全链路 TraceID。 ## **9\. 实施阶段计划** * **Phase 1 (连接)**:打通 REDCap Webhook 与 Node.js,上线微信周报确认功能。 * **Phase 2 (协同)**:上线 PC Workbench 核心组件,实现质控影子建议的闭环。 * **Phase 3 (增强)**:集成 Python 微服务的 OCR/DC 模块,开启智能化数据采集。 * **Phase 4 (生态)**:完成 100+ 项目规模化配置方案,预研 AI 原生 SmartEDC。 **文档版本**:V4.0 Final | **更新日期**:2025-12-30 | **作者**:产品架构团队