# **IIT Manager Agent 技术方案审查与补丁 (V1.1)**

## **1\. 架构修正：解决医院内网连通性**

针对 **风险一 (网络连通性)**，建议在 3.1 REDCap 集成 中增加 **"混合同步模式"**。

### **新增模块：SyncManager (同步管理器)**

// backend/src/modules/iit-manager/services/SyncManager.ts

export class SyncManager {  
  /\*\*  
   \* 混合同步策略  
   \* 1\. 优先监听 Webhook (实时)  
   \* 2\. 定时轮询 (兜底，解决内网不通或Webhook丢失问题)  
   \*/  
  async schedulePolling(projectId: string, intervalMinutes: number \= 10\) {  
    await jobQueue.schedule('iit:redcap:poll', { projectId }, {  
      every: \`${intervalMinutes} minutes\`  
    });  
  }

  /\*\*  
   \* 轮询任务处理器  
   \*/  
  async handlePoll(projectId: string) {  
    // 1\. 获取上次同步时间  
    const lastSync \= await this.getLastSyncTime(projectId);  
      
    // 2\. 调用 REDCap API 获取在此之后修改的记录  
    // API: 'export', content: 'record', dateRangeBegin: lastSync  
    const records \= await this.redcapAdapter.fetchModifiedRecords(projectId, lastSync);  
      
    // 3\. 触发质控 (复用 Webhook 的逻辑)  
    for (const record of records) {  
      await jobQueue.push('iit:quality-check', {  
        projectId,  
        recordId: record.record\_id,  
        data: record  
      });  
    }  
  }  
}

**修改建议**：

* 在 MVP 阶段，**务必实现轮询 (Polling)**。不要赌医院的网络环境。

## **2\. 功能补充：历史数据全量扫描**

针对 **风险二 (存量数据)**，建议利用现有的 CheckpointService 实现全量扫描。

### **新增 API：全量质控触发**

**Endpoint**: POST /api/v1/iit/projects/:id/scan-all

**逻辑实现 (复用现有 ASL/DC 模块的批处理经验)**：

1. 调用 REDCap API 仅下载所有 record\_id (轻量级)。  
2. 将 ID 列表分片 (Chunk)，每片 50 个 ID。  
3. 利用 pg-boss 推送 iit:quality-check:batch 任务。  
4. Worker 逐个拉取完整数据并运行 Agent。

## **3\. 前端技术栈明确**

方案中提到了 "微信小程序"，但未明确技术栈。考虑到你们现有的 React 基因：

* **推荐方案**：使用 **Taro** (React 语法) 开发小程序。  
* **理由**：  
  1. 可以让前端团队复用 React 知识（Hooks, Components）。  
  2. 可以复用 shared/components 中的部分逻辑（如数据格式化）。  
  3. Taro 支持一键编译为 微信小程序 \+ H5 (用于企微侧边栏)，**一鱼两吃**。

## **4\. 数据库 Schema 微调**

在 IitUserMapping 表中，建议增加 Token 字段，用于小程序 Session 维护。

model IitUserMapping {  
  // ... 现有字段  
    
  // 新增：小程序会话密钥 (用于校验 wx.login)  
  miniProgramOpenId  String?  @unique  
  sessionKey         String?  // 微信 session\_key  
    
  @@index(\[miniProgramOpenId\])  
}

## **5\. Dify RAG 性能优化 (预加载)**

PRD 提到 "Protocol 往往很长"。

* **风险**：每次质控都让 Dify 重新检索整个 PDF，速度慢且 Token 消耗大。  
* **优化**：在 ProtocolService 中增加 **"关键规则缓存"**。  
  * 在上传 Protocol 后，让 Agent 预先提取出 "入排标准" (Inclusion/Exclusion Criteria) 并存入 PostgreSQL JSONB 字段。  
  * 在做基础质控时，优先匹配 DB 里的规则，匹配不到再由 Agent 去 RAG 检索。

## **结论**

**此方案 V1.0 可以通过评审，但必须补充上述 "Plan B" (轮询机制)**。

**开发优先级调整建议**：

1. **Day 1**: 数据库 & 基础架构 (不变)  
2. **Day 2**: **优先实现 REDCap API Adapter (拉取能力)**，而不是 Webhook (推送能力)。因为 API 拉取更可控，且能解决历史数据问题。  
3. **Day 3**: Webhook 补充实现 (作为即时性增强)。