# **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 补充实现 (作为即时性增�?�