feat(ssa): Agent channel UX optimization (Solution B) + Plan-and-Execute architecture design
SSA Agent channel improvements (12 code files, +931/-203 lines): - Solution B: left/right separation of concerns (gaze guiding + state mutex + time-travel) - JWT token refresh mechanism (ensureFreshToken) to fix HTTP 401 during pipeline - Code truncation fix: LLM maxTokens 4000->8000 + CSS max-height 60vh - Retry streaming code generation with generateCodeStream() - R Docker structured errors: 20+ pattern matching + format_agent_error + line extraction - Prompt iron rules: strict output format in CoderAgent System Prompt - parseCode robustness: XML/Markdown/inference 3-tier matching + length validation - consoleOutput type defense: handle both array and scalar from R Docker unboxedJSON - Agent progress bar sync: derive phase from agentExecution.status - Export report / view code buttons restored for Agent mode - ExecutingProgress component: real-time timer + dynamic tips + step pulse animation Architecture design (3 review reports): - Plan-and-Execute step-by-step execution architecture approved - Code accumulation strategy (R Docker stays stateless) - 5 engineering guardrails: XML tags, AST pre-check, defensive prompts, high-fidelity schema, error classification circuit breaker Docs: update SSA module status v4.1, system status v6.7, deployment changelist Made-with: Cursor
This commit is contained in:
@@ -1,10 +1,12 @@
|
||||
# AIclinicalresearch 系统当前状态与开发指南
|
||||
|
||||
> **文档版本:** v6.6
|
||||
> **文档版本:** v6.7
|
||||
> **创建日期:** 2025-11-28
|
||||
> **维护者:** 开发团队
|
||||
> **最后更新:** 2026-03-01
|
||||
> **最后更新:** 2026-03-07
|
||||
> **🎉 重大里程碑:**
|
||||
> - **🆕 2026-03-07:SSA Agent 通道体验优化 + Plan-and-Execute 架构设计完成!** 方案 B 左右职责分离 + 10 项 Bug 修复(JWT 刷新/代码截断/重试流式/R Docker 结构化错误/进度同步/导出按钮)+ 分步执行架构评审通过(代码累加策略 + 5 项工程护栏)
|
||||
> - **🆕 2026-03-05:RVW V3.0 智能审稿 + ASL Deep Research 历史 + 系统稳定性增强!** RVW LLM 数据核查 + 临床评估维度 + 并行 Skill 故障隔离 + ASL 研究历史/删除 + DeepSearch S3 升级
|
||||
> - **🆕 2026-03-01:IIT 业务端 GCP 报表 + AI 时间线增强 + 多项 Bug 修复!** 4 张 GCP 标准报表(筛选入选/完整性/质疑跟踪/方案偏离)+ AI 工作流水详情展开 + 一键全量质控 + dimension_code/时区/通过率/D1 数据源修复
|
||||
> - **🆕 2026-02-27:旧版系统集成完成!** Token 注入自动登录 + Wrapper Bridge 架构 + Storage Access API + iframe 嵌入(研究管理 + 统计分析工具 126 个) + CSS 注入样式定制 + 本地 E2E 验证通过
|
||||
> - **🆕 2026-02-27:数据库文档体系 + 部署文档体系 + Prisma Schema 对齐完成!** 6 篇数据库核心文档 + 部署文档归档整理 + 统一操作手册 + 数据库开发规范 v3.0 + Cursor Rule 自动提醒 + Schema 类型漂移修正
|
||||
@@ -33,7 +35,11 @@
|
||||
> - **2026-01-24:Protocol Agent 框架完成!** 可复用Agent框架+5阶段对话流程
|
||||
> - **2026-01-22:OSS 存储集成完成!** 阿里云 OSS 正式接入平台基础层
|
||||
>
|
||||
> **🆕 最新进展(旧版系统集成 + 数据库文档体系 2026-02-27):**
|
||||
> **🆕 最新进展(SSA Agent 体验优化 + RVW V3.0 2026-03-07):**
|
||||
> - ✅ **🆕 SSA Agent 通道体验优化(12 文件, +931/-203 行)** — 方案 B 左右职责分离 + JWT 刷新 + 代码截断修复 + 重试流式生成 + R Docker 结构化错误(20+ 模式)+ Prompt 铁律 + 进度同步 + 导出按钮恢复 + ExecutingProgress 动态 UI
|
||||
> - ✅ **🆕 Plan-and-Execute 分步执行架构设计完成** — 代码累加策略 + 5 项工程护栏(XML 标签/AST 预检/防御性 Prompt/高保真 Schema/错误分类短路)+ 3 份架构评审报告
|
||||
> - ✅ **🆕 RVW V3.0 智能审稿** — LLM 数据核查 + 临床专业评估维度 + 并行 Skill 故障隔离(partial_completed)+ error_details JSONB
|
||||
> - ✅ **🆕 ASL Deep Research 历史 + DeepSearch S3** — 研究历史列表/删除 + getTask 鉴权修复 + Unifuncs S3 升级(中文数据源)
|
||||
> - ✅ **🆕 IIT 业务端 GCP 报表 + Bug 修复** — 4 张 GCP 标准报表(D1/D2/D3D4/D6)+ AI Timeline 详情展开 + 一键全量质控 + 6 项关键 Bug 修复
|
||||
> - ✅ **🆕 旧版系统集成** — Token 注入自动登录 + Wrapper Bridge(Cookie 设置 + CSS 注入)+ Storage Access API + 本地 E2E 全部通过
|
||||
> - ✅ **🆕 数据库文档体系建立** — 6 篇核心文档(架构总览/迁移历史/环境对照/技术债务/种子数据/PG扩展),位于 `docs/01-平台基础层/07-数据库/`
|
||||
@@ -84,7 +90,7 @@
|
||||
| **ASL** | AI智能文献 | 文献筛选、Deep Research、全文智能提取、SR图表、Meta分析 | ⭐⭐⭐⭐⭐ | 🎉 **V2.0 核心完成(90%)+ 🆕工具4+5完成** - SSE流式+瀑布流UI+HITL+Word导出+散装派发+PRISMA流程图+Meta分析引擎(R Docker) | **P0** |
|
||||
| **DC** | 数据清洗整理 | ETL + 医学NER(百万行级数据) | ⭐⭐⭐⭐⭐ | ✅ **Tool B完成 + Tool C 99%(异步架构+性能优化-99%+多指标转换+7大功能)** | **P0** |
|
||||
| **IIT** | IIT Manager Agent | CRA Agent - LLM Tool Use + 自驱动质控 + 统一驾驶舱 | ⭐⭐⭐⭐⭐ | 🎉 **V3.1完成 + GCP报表 + Bug修复!** 质控引擎升级 + 4张GCP业务报表 + AI时间线增强 + 一键全量质控 | **P1-2** |
|
||||
| **SSA** | 智能统计分析 | **QPER架构** + 四层七工具 + 对话层LLM + 意图路由器 | ⭐⭐⭐⭐⭐ | 🎉 **Phase I-IV 开发完成** — QPER闭环 + Session黑板 + 意图路由 + 对话LLM + 方法咨询 + 对话驱动分析,E2E 107/107 | **P1** |
|
||||
| **SSA** | 智能统计分析 | **QPER架构 + 双通道(QPER + LLM Agent)** + 四层七工具 + 对话层LLM | ⭐⭐⭐⭐⭐ | 🎉 **双通道架构 + Agent 体验优化完成** — QPER闭环 + Agent代码生成通道 + 方案B左右职责分离 + 10项Bug修复 + Plan-and-Execute架构设计,E2E全通过 | **P1** |
|
||||
| **ST** | 统计分析工具 | 126 个轻量化统计工具(旧系统 iframe 嵌入) | ⭐⭐⭐⭐ | ✅ **旧系统集成完成** — Token 注入 + Wrapper Bridge + E2E 验证通过 | P2 |
|
||||
| **RVW** | 稿件审查系统 | 方法学评估 + 🆕数据侦探(L1/L2/L2.5验证)+ Skills架构 + Word导出 | ⭐⭐⭐⭐ | 🚀 **V2.0 Week3完成(85%)** - 统计验证扩展+负号归一化+文件格式提示+用户体验优化 | P1 |
|
||||
| **ADMIN** | 运营管理端 | Prompt管理、租户管理、用户管理、运营监控、系统知识库 | ⭐⭐⭐⭐⭐ | 🎉 **Phase 4.6完成(88%)** - Prompt知识库集成+动态注入 | **P0** |
|
||||
@@ -254,12 +260,32 @@
|
||||
- ✅ **QPER 集成**:对话层直接调用 plan → execute → report,analysis_plan SSE 事件传输
|
||||
- ✅ **团队审查 12 条反馈全部落地**:Phase II H1-H4、Phase III H1-H3+P1、Phase IV H1-H3+B1-B2
|
||||
|
||||
**下一步**:Phase VI(集成测试 + 可观测性 10h)→ 交付试用 → 按需补做 Phase V
|
||||
**下一步**:Phase 5A-5C(Plan-and-Execute 分步执行)→ Phase V-B(反思编排)→ Phase VI(集成测试 + 可观测性)
|
||||
|
||||
**相关文档**:
|
||||
- 开发计划:`docs/03-业务模块/SSA-智能统计分析/04-开发计划/11-智能对话与工具体系开发计划.md`
|
||||
- 模块状态:`docs/03-业务模块/SSA-智能统计分析/00-模块当前状态与开发指南.md`
|
||||
- 系统设计:`docs/03-业务模块/SSA-智能统计分析/00-系统设计/SSA-Pro 四层七工具实现机制详解.md`
|
||||
- 架构评审:`docs/03-业务模块/SSA-智能统计分析/07-统计专家配置/架构委员会审查报告:分步执行架构.md`
|
||||
|
||||
#### ✅ SSA Agent 通道体验优化 + Plan-and-Execute 架构设计(2026-03-07)
|
||||
|
||||
**Agent 通道体验优化完成(12 文件, +931/-203 行):**
|
||||
|
||||
| 修复项 | 问题 | 解决方案 |
|
||||
|--------|------|---------|
|
||||
| 方案 B 左右职责分离 | 左侧对话与右侧工作区信息打架 | 左侧仅输出视线牵引提示,右侧承载全部交互;双屏状态互斥同步 + 历史穿梭 |
|
||||
| JWT Token 刷新 | Agent 管线执行期间 Token 过期导致 401 | 前端 `ensureFreshToken()` 在 API 调用前检查并刷新 |
|
||||
| 代码截断 | R 代码展示不完整 | LLM maxTokens 4000→8000 + CSS 优化 |
|
||||
| 重试流式生成 | 重试时无代码展示 | 后端改用 `generateCodeStream()` + 前端状态管理优化 |
|
||||
| R Docker 结构化错误 | 错误信息 LLM 无法理解 | 20+ 模式匹配 + 行号提取 + 错误分类 + 修复建议(`format_agent_error`) |
|
||||
| Prompt 铁律 | LLM 在代码块内输出自然语言 | CoderAgent System Prompt 严格输出格式规则 + `parseCode()` 三级匹配 |
|
||||
| 进度条/按钮缺失 | Agent 模式下进度/导出按钮不工作 | 从 `agentExecution.status` 派生 phase + `reportBlocks` 判断 hasResults |
|
||||
|
||||
**Plan-and-Execute 分步执行架构设计完成:**
|
||||
- ✅ 三份架构评估报告审查通过
|
||||
- ✅ 策略:代码累加(R Docker 保持无状态,每步累加前序成功代码)
|
||||
- ✅ 5 项工程护栏:XML 标签提取 + AST 预检 + 防御性 Prompt + 高保真 Schema + 错误分类短路
|
||||
|
||||
#### ✅ SSA QPER 四层架构全部完成(2026-02-21)
|
||||
|
||||
|
||||
@@ -1,13 +1,27 @@
|
||||
# SSA智能统计分析模块 - 当前状态与开发指南
|
||||
|
||||
> **文档版本:** v4.0
|
||||
> **文档版本:** v4.1
|
||||
> **创建日期:** 2026-02-18
|
||||
> **最后更新:** 2026-03-02
|
||||
> **最后更新:** 2026-03-07
|
||||
> **维护者:** 开发团队
|
||||
> **当前状态:** 🎉 **QPER 主线闭环 + Phase I-IV + Phase V-A + 双通道架构(Agent 通道 Phase 1-3)开发完成**
|
||||
> **当前状态:** 🎉 **QPER 主线闭环 + Phase I-IV + Phase V-A + 双通道架构 Phase 1-3 + Agent 通道体验优化完成**
|
||||
> **文档目的:** 快速了解SSA模块状态,为新AI助手提供上下文
|
||||
>
|
||||
> **最新进展(2026-03-02 双通道架构 Phase 1-3 完成):**
|
||||
> **最新进展(2026-03-07 Agent 通道体验优化 — 方案 B 左右职责分离 + 10 项 Bug 修复):**
|
||||
> - ✅ **方案 B — 左右职责分离** — 左侧对话区仅输出简洁视线牵引提示,右侧工作区承载计划/代码/结果全部交互;双屏状态互斥同步(右侧操作→左侧追加审计消息);历史穿梭(点击左侧卡片→右侧切换对应任务)
|
||||
> - ✅ **JWT Token 刷新机制** — 前端 `ensureFreshToken()` 在 API 调用前检查并刷新过期 Token,解决 HTTP 401 问题
|
||||
> - ✅ **代码截断修复** — LLM maxTokens 4000→8000 + CSS max-height 60vh + word-break 优化
|
||||
> - ✅ **重试流式代码生成** — 后端重试改用 `generateCodeStream()` 流式生成,前端实时展示重试代码
|
||||
> - ✅ **错误信息增强** — R Docker 结构化错误(20+ 模式匹配 + 行号提取 + 错误分类 + 修复建议);前端展示上次失败原因
|
||||
> - ✅ **Prompt 铁律强化** — CoderAgent System Prompt 增加严格输出格式规则,禁止代码块内混入自然语言
|
||||
> - ✅ **代码解析器健壮化** — `parseCode()` 支持 XML/Markdown/推断三级匹配,过短代码抛错
|
||||
> - ✅ **consoleOutput 类型防御** — 兼容 R Docker unboxedJSON 标量/数组两种返回格式
|
||||
> - ✅ **Agent 进度条同步** — `SSAWorkspacePane` 从 `agentExecution.status` 派生 phase,步骤高亮正确
|
||||
> - ✅ **导出报告/查看代码按钮恢复** — Agent 模式下 `hasResults` 基于 `reportBlocks` 长度判断;`SSACodeModal` 支持 Agent 代码展示
|
||||
> - ✅ **执行中动态 UI** — `ExecutingProgress` 组件(实时计时器 + 动态提示 + 步骤脉冲动画)
|
||||
> - ✅ **Plan-and-Execute 分步执行架构设计完成** — 代码累加策略 + 工程护栏(XML 标签/AST 预检/防御性 Prompt/高保真 Schema/错误分类短路)
|
||||
>
|
||||
> **此前进展(2026-03-02 双通道架构 Phase 1-3 完成):**
|
||||
> - ✅ **SSA 双通道架构** — QPER 管线 + LLM Agent 代码生成两条通道并行,前端一键切换
|
||||
> - ✅ **Phase 1 基础设施** — DB schema(execution_mode + ssa_agent_executions)、前端 ModeToggle 组件、Session PATCH API
|
||||
> - ✅ **Phase 2 Agent 服务** — PlannerAgent + CoderAgent(含流式生成)+ CodeRunnerService,ReviewerAgent 暂缓
|
||||
@@ -72,7 +86,7 @@
|
||||
| **前端状态模型** | **Unified Record Architecture — 一次分析 = 一个 Record = N 个 Steps** |
|
||||
| **商业价值** | ⭐⭐⭐⭐⭐ 极高 |
|
||||
| **目标用户** | 临床研究人员、生物统计师 |
|
||||
| **开发状态** | 🎉 **QPER 主线闭环 + Phase I-IV + Phase V-A + 双通道架构 Phase 1-3 完成** |
|
||||
| **开发状态** | 🎉 **QPER 主线闭环 + Phase I-IV + Phase V-A + 双通道架构 Phase 1-3 + Agent 体验优化完成** |
|
||||
|
||||
### 核心目标
|
||||
|
||||
@@ -178,7 +192,11 @@ AnalysisRecord {
|
||||
| **双通道 Phase 1** | **基础设施(DB + 前端切换 + API)** | **~4h** | ✅ **已完成(DB schema + ModeToggle + PATCH API)** | 2026-03-02 |
|
||||
| **双通道 Phase 2** | **Agent 服务层(Planner + Coder + Runner)** | **~6h** | ✅ **已完成(3 Agent 服务 + R execute-code 端点)** | 2026-03-02 |
|
||||
| **双通道 Phase 3** | **前端集成(SSE + AgentCodePanel + 确认流程)** | **~6h** | ✅ **已完成(三步确认 + 流式代码 + 7 种 SSE 事件)** | 2026-03-02 |
|
||||
| **双通道 Phase 4** | **Prompt 工程 + 全面测试** | **~8h** | ⏳ 待用户体验测试确认后推进 | - |
|
||||
| **Agent 体验优化** | **方案 B 左右职责分离 + 10 项 Bug 修复** | **~8h** | ✅ **已完成(12 文件, +931/-203 行)** | 2026-03-07 |
|
||||
| **Plan-and-Execute 设计** | **分步执行架构设计(代码累加 + 工程护栏)** | **~4h** | ✅ **已完成(架构评审 + 三份评估报告)** | 2026-03-07 |
|
||||
| **Phase 5A** | **CoderAgent 防错护栏(XML 标签 + AST 预检 + 防御性 Prompt + 高保真 Schema)** | **~6h** | 📋 待开始 | - |
|
||||
| **Phase 5B** | **后端分步执行引擎(DB schema + 代码累加循环 + 错误分类短路 + 新 SSE 事件)** | **~10h** | 📋 待开始 | - |
|
||||
| **Phase 5C** | **前端分步展示(类型扩展 + AgentCodePanel 多步骤 UI + SSE 处理器)** | **~6h** | 📋 待开始 | - |
|
||||
| **Phase V-B** | **反思编排 + 高级特性** | **18h** | 📋 待开始 | - |
|
||||
| **Phase VI** | **集成测试 + 可观测性** | **10h** | 📋 待开始 | - |
|
||||
|
||||
@@ -204,7 +222,8 @@ AnalysisRecord {
|
||||
| **Phase V-A 后端** | PATCH /workflow/:id/params(Zod 结构校验防火墙)+ tool_param_constraints.json(12 工具参数约束)+ inferGroupingVar 恢复(默认填充分组变量) | ✅ |
|
||||
| **Phase V-A 前端** | WorkflowTimeline 可编辑化(SingleVarSelect + MultiVarTags + 三层柔性拦截)+ ssaStore updateStepParams + SSAWorkspacePane 同步阻塞执行 + DynamicReport 对象 rows 兼容 + Word 导出修复 | ✅ |
|
||||
| **双通道 Agent 通道** | PlannerAgent(意图→分析计划)+ CoderAgent(计划→R 代码,含流式生成)+ CodeRunnerService(沙箱执行)+ AgentCodePanel(三步确认 UI)+ ModeToggle(通道切换)+ R Docker /execute-code 端点 | ✅ |
|
||||
| **测试** | QPER 端到端 40/40 + 集成测试 7 Bug 修复 + Phase I E2E 31/31 + Phase II E2E 38/38 + Phase III E2E 13/13+4skip + Phase IV E2E 25/25 + Phase V-A 前后端集成测试通过 + 双通道 E2E 8/8 通过 | ✅ |
|
||||
| **Agent 体验优化** | 方案 B 左右职责分离(视线牵引+状态互斥+历史穿梭)+ JWT 刷新 + 代码截断修复 + 重试流式生成 + R Docker 结构化错误(20+ 模式)+ Prompt 铁律 + parseCode 健壮化 + consoleOutput 类型防御 + 进度条同步 + 导出/查看代码恢复 + ExecutingProgress 动态 UI | ✅ |
|
||||
| **测试** | QPER 端到端 40/40 + 集成测试 7 Bug 修复 + Phase I E2E 31/31 + Phase II E2E 38/38 + Phase III E2E 13/13+4skip + Phase IV E2E 25/25 + Phase V-A 前后端集成测试通过 + 双通道 E2E 8/8 通过 + Agent 体验测试通过(统计分析结果+图表正常) | ✅ |
|
||||
|
||||
---
|
||||
|
||||
@@ -270,7 +289,9 @@ frontend-v2/src/modules/ssa/
|
||||
└── index.ts # 前端类型定义
|
||||
|
||||
r-statistics-service/
|
||||
├── plumber.R # API 入口(含参数日志)
|
||||
├── plumber.R # API 入口(含参数日志 + Agent 结构化错误处理)
|
||||
├── utils/
|
||||
│ └── error_codes.R # Agent 通道:20+ 错误模式匹配 + format_agent_error
|
||||
└── tools/
|
||||
└── descriptive.R # 描述性统计(NA 安全防御)
|
||||
```
|
||||
@@ -354,24 +375,30 @@ npx tsx scripts/seed-ssa-phase4-prompts.ts # Phase IV: SSA_ANALYZE_PLAN
|
||||
|
||||
### 近期(优先级高)
|
||||
|
||||
1. **双通道 Phase 4 — Prompt 工程 + 全面测试**
|
||||
- 用户体验测试确认双通道 Agent 管线
|
||||
- Prompt 优化(PlannerAgent / CoderAgent 系统提示词精调)
|
||||
- 错误处理增强(R 执行失败→LLM 自动修复重试,MAX 2 次)
|
||||
- ReviewerAgent 按需启用(代码质量/安全审核)
|
||||
1. **Phase 5A — CoderAgent 防错护栏**
|
||||
- XML 标签提取:强制 `<r_code>...</r_code>` 标签 + `parseCode()` 严格正则
|
||||
- 防御性 Prompt:NA 处理 / 类型转换 / 因子水平检查 / tryCatch 规则注入
|
||||
- 高保真 Schema 注入:`buildDataContext()` 增加列类型 + 前 3 条样本值
|
||||
- R Docker AST 预检:`parse()` 语法检查在 `eval()` 之前
|
||||
|
||||
2. **Phase V-B — 反思编排 + 高级特性(18h / 3 天)**
|
||||
- 错误分类器实现(可自愈 vs 不可自愈)
|
||||
- 自动反思(静默重试,MAX 2 次)+ 手动反思(用户驱动,feedback 意图)
|
||||
- write_report interpret 模式 + discuss 意图处理(深度解读已有结果)
|
||||
2. **Phase 5B — 后端分步执行引擎**
|
||||
- DB: `SsaAgentExecution` 新增 `stepResults: Json[]` + `currentStep: Int?`
|
||||
- 代码累加执行循环(R Docker 保持无状态,每步累加前序成功代码)
|
||||
- 错误分类短路(Fatal→硬停 / Retriable→重试 MAX 2 / Soft→跳过)
|
||||
- 新 SSE 事件:`step_coding / step_code_ready / step_executing / step_result / step_error / step_skipped / pipeline_aborted`
|
||||
|
||||
3. **Phase Deploy 收尾** — 前端三线表增强、决策表/流程模板补齐、ACR/SAE 部署
|
||||
3. **Phase 5C — 前端分步展示**
|
||||
- 类型扩展:`AgentExecutionRecord` 增加 `stepResults[]` + `currentStep`
|
||||
- AgentCodePanel 多步骤 UI(可折叠步骤卡片 + 状态/代码/结果/错误)
|
||||
- SSE 处理器适配新步骤级事件
|
||||
|
||||
### 中期
|
||||
|
||||
4. **Phase VI(10h)** — 集成测试 + 可观测性(含 QPER 透明化)
|
||||
4. **Phase V-B — 反思编排 + 高级特性(18h)**
|
||||
5. **Phase VI(10h)** — 集成测试 + 可观测性(含 QPER 透明化)
|
||||
6. **Phase Deploy 收尾** — 前端三线表增强、决策表/流程模板补齐、ACR/SAE 部署
|
||||
|
||||
**详细计划:** `04-开发计划/11-智能对话与工具体系开发计划.md`(v1.8,Phase I-IV + Phase V-A 完成)+ 双通道架构计划详见 `06-开发记录/` 相关文档
|
||||
**详细计划:** `04-开发计划/11-智能对话与工具体系开发计划.md` + 架构评审报告详见 `07-统计专家配置/` 目录
|
||||
|
||||
---
|
||||
|
||||
@@ -416,7 +443,7 @@ npx tsx scripts/seed-ssa-phase4-prompts.ts # Phase IV: SSA_ANALYZE_PLAN
|
||||
|
||||
---
|
||||
|
||||
**文档版本:** v4.0
|
||||
**最后更新:** 2026-03-02
|
||||
**当前状态:** 🎉 QPER 主线闭环 + Phase I-IV + Phase V-A + 双通道架构 Phase 1-3 已完成
|
||||
**下一步:** 双通道 Phase 4(Prompt 工程 + 全面测试)→ Phase V-B(反思编排)
|
||||
**文档版本:** v4.1
|
||||
**最后更新:** 2026-03-07
|
||||
**当前状态:** 🎉 QPER 主线闭环 + Phase I-IV + Phase V-A + 双通道架构 Phase 1-3 + Agent 体验优化已完成
|
||||
**下一步:** Phase 5A(CoderAgent 防错护栏)→ Phase 5B(分步执行引擎)→ Phase 5C(前端分步展示)
|
||||
|
||||
129
docs/03-业务模块/SSA-智能统计分析/07-统计专家配置/复杂分析分步执行架构评估报告.md
Normal file
129
docs/03-业务模块/SSA-智能统计分析/07-统计专家配置/复杂分析分步执行架构评估报告.md
Normal file
@@ -0,0 +1,129 @@
|
||||
# **架构委员会评估报告:复杂多步统计分析的 Agentic 分步执行方案**
|
||||
|
||||
**评估议题:** 针对“描述 \-\> 单因素 \-\> 多因素 \-\> 敏感性”复杂流,大模型是否可以且应该“分步写代码、分步执行、分步展示”?
|
||||
|
||||
**评估结论:** 🌟 **极度赞同!** 这是经典的 **"Plan-and-Solve (规划并逐步解决)"** 智能体设计模式。它不仅解决了大模型的上下文窗口限制,更是解决“步骤间因果依赖”的唯一工程解法。
|
||||
|
||||
## **一、 为什么“一次性生成全部代码”注定失败?(The One-Shot Trap)**
|
||||
|
||||
在你提供的这个 4 步分析法中,存在一个极其关键的\*\*“因果悖论 (Causality Paradox)”\*\*:
|
||||
|
||||
**步骤 3 (多因素分析) 明确要求:** “将**单因素分析中 P 值小于 0.1** 的变量... 纳入多因素逻辑回归模型。”
|
||||
|
||||
* **如果让大模型一次性写完所有代码:**
|
||||
大模型在写代码的那一刻,根本不知道哪些变量的 P 值会小于 0.1!
|
||||
为了实现这个需求,大模型必须在 R 代码里写出极度复杂的“动态提参和动态公式拼接”代码(例如:用 R 提取所有卡方和秩和检验的 P 值,动态过滤,然后 as.formula(paste("Yqol \~", paste(selected\_vars, collapse="+"))))。
|
||||
在真实工程中,这种由大模型动态生成的元编程 R 代码,因为各种检验结果的数据结构不同,**运行崩溃率高达 95% 以上**。
|
||||
* **如果采用“分步执行 (Agentic Step-by-Step)”:**
|
||||
大模型先写步骤 1 和 2。R Docker 跑完后,大模型**真真切切地看到了 P 值的输出结果**。然后大模型做一个人脑决策:“哦,我看到 age (P=0.03) 和 smoke (P=0.08) 小于 0.1,所以我现在的步骤 3 代码可以直接写死:glm(Yqol \~ age \+ smoke \+ bmi \+ sex, ...)”。
|
||||
**这让代码生成变得极其简单、傻瓜、0 报错!**
|
||||
|
||||
## **二、 架构实现方案:如何在无状态的 Docker 中实现“分步”?**
|
||||
|
||||
R Docker 的 /execute-code 接口是无状态的 HTTP 请求(跑完就销毁内存)。要实现分步执行,我们在 Node.js 编排层有两套落地模式:
|
||||
|
||||
### **方案 A:代码累加法 (Code Accumulation) —— 🌟 推荐 MVP 阶段使用**
|
||||
|
||||
这种方式最简单,不需要改动基础设施。
|
||||
|
||||
1. **Turn 1 (描述与单因素)**:
|
||||
* LLM 生成 Code\_A(加载数据、Table 1、卡方、秩和检验)。
|
||||
* Node.js 发送 Code\_A 给 R Docker,拿到结果展示给用户。
|
||||
2. **Turn 2 (多因素)**:
|
||||
* LLM 根据上一步结果,决定了纳入变量,生成 Code\_B(Logistic 回归)。
|
||||
* Node.js 在后台将代码拼接:Final\_Code \= Code\_A \+ "\\n" \+ Code\_B。
|
||||
* Node.js 把 Final\_Code 发给 R Docker 重新跑一遍。虽然前两步被重复跑了,但在小数据集下(如1000行以内),R 跑一次只需零点几秒,用户完全无感知。
|
||||
|
||||
### **方案 B:环境快照法 (Workspace Snapshot) —— 适合大数据/耗时计算**
|
||||
|
||||
如果单因素分析非常耗时(如海量基因数据),不能重复跑。
|
||||
|
||||
1. **执行引擎改造**:
|
||||
在每次 R 脚本执行的最后,强制加上一句 save.image("/tmp/session\_xxx.RData"),把当前处理好的清洗后数据、中间变量全部序列化存入本地或 OSS。
|
||||
2. **分步调起**:
|
||||
执行步骤 3 时,LLM 生成的 R 代码第一句就是 load("/tmp/session\_xxx.RData"),直接继承上一步的内存状态继续跑。
|
||||
|
||||
## **三、 对产品体验 (UX) 的降维打击**
|
||||
|
||||
这种分步执行模式,在前端交互上能带来无与伦比的体验(参考我们在 V12/V13 原型图中的设计):
|
||||
|
||||
1. **进度条变“真”了 (Progressive Rendering)**:
|
||||
原来用户要看一个转圈看 30 秒。现在,系统可以在 5 秒时弹出 Table 1(描述统计),10 秒时弹出单因素 P 值表格,20 秒时弹出 Logistic 回归森林图。用户像看瀑布流一样看着报告生成,极大地降低了等待焦虑。
|
||||
2. **极简自愈 (Micro-Healing)**:
|
||||
如果到了第 4 步(多重插补敏感性分析)时 R 引擎因为缺包报错了,系统**只需要让大模型重写第 4 步的代码**,前面的 3 步成果依然安然无恙地展示在界面上。
|
||||
3. **人类干预节点 (Human-in-the-loop)**:
|
||||
在步骤 2 跑完后,可以挂起流程。系统问医生:“基于 P\<0.1 的规则,AI 拟将 age, smoke 纳入回归模型。您是否需要强制纳入其他具有临床意义的变量?”医生勾选后,再执行步骤 3。**这是顶级医疗软件的灵魂。**
|
||||
|
||||
## **四、 针对 R 代码执行错误的诊断与防御机制补充 (R Docker Error Prevention)**
|
||||
|
||||
针对日志中出现的 \<text\>:14:9: unexpected input 错误(通常由于大模型在 R 代码块中输出了非法的中文注释或未闭合的字符串/标签导致),在架构上需要增加以下防御机制:
|
||||
|
||||
### **1\. Coder Agent 输出的预处理清洗 (Pre-Execution Sanitization)**
|
||||
|
||||
大模型有时会在代码块中混入解释性文字(如“根据您的分析计划,”),如果这些文字没有被加上 \# 注释符,R 引擎就会报语法错误。
|
||||
|
||||
**Node.js 侧 (CodeRunnerService) 的强制修正:**
|
||||
|
||||
在将代码发给 R Docker 之前,执行一层纯正则或 AST 级别的清洗:
|
||||
|
||||
* **提取有效块**:只提取 r\` 和 \` \` 之间的代码。
|
||||
* **过滤孤儿中文**:如果存在不在引号内且不以 \# 开头的中文字符,这极可能是大模型的解释文字泄漏到了代码块中。可以尝试用正则检测并自动给这些行加上 \# ,或者直接截断。
|
||||
* **(推荐)最简单暴力的方法**:在 Coder Agent 的 System Prompt 中加入最严厉的指令:**“除了代码块,你绝对不能输出任何解释性文字。必须直接输出纯 R 代码,第一行就是 library(),不要使用 Markdown 代码块标签。”**
|
||||
|
||||
### **2\. R Docker 端的语法预检 (Syntax Dry-Run)**
|
||||
|
||||
R Docker 在真正执行计算(尤其是耗时计算)前,应该快速进行一次语法检查,这样能立即抛出友好的错误,而不是等跑了一半才崩溃。
|
||||
|
||||
**R 端 (execute-code API) 的防御:**
|
||||
|
||||
可以在 R 侧接收到代码字符串后,先用 parse() 函数尝试解析,如果解析失败,直接返回“语法错误”,不再交给 eval()。
|
||||
|
||||
\# 在 R API 内部增加预检
|
||||
tryCatch({
|
||||
parsed\_code \<- parse(text \= input\_code)
|
||||
}, error \= function(e) {
|
||||
\# 这里捕获的就是 unexpected input 这种纯语法错误
|
||||
stop(paste("R代码语法错误,无法解析:", e$message))
|
||||
})
|
||||
\# 解析通过后,再执行 eval(parsed\_code)
|
||||
|
||||
### **3\. 错误捕获的鲁棒性 (Robust Error Handling)**
|
||||
|
||||
日志中显示的 (execResult.consoleOutput || \[\]).slice is not a function 说明 Node.js 在尝试处理 R 的报错信息时,因为 execResult.consoleOutput 不是一个数组而导致了二次报错。这会让后续的自愈机制(Self-Healing)拿不到真实的错误信息。
|
||||
|
||||
**后端侧的修正:**
|
||||
|
||||
确保 CodeRunnerService 在捕获 R 的 HTTP 错误响应时,返回的数据结构永远符合约定,避免抛出 JS 层的 Type Error,保证错误能够平稳地传给 Reviewer/Fixer Agent 让其重试。
|
||||
|
||||
### **4\. Agent 职责的精细化拆分:引入独立的 Fixer Agent (专门改代码) 🌟**
|
||||
|
||||
这是彻底解决 AI 陷入“修 Bug 死循环”的最优架构策略(Actor-Critic 模式)。不要让原来的 Coder Agent 兼职改代码,必须将其拆分:
|
||||
|
||||
* **📝 Coder Agent(纯写代码)**:
|
||||
它的职责是“从 0 到 1”,专注于把统计学计划翻译成 R 代码。上下文中包含大量的分析需求和数据字典。
|
||||
* **🔧 Fixer Agent(专门修 Bug)**:
|
||||
当 CodeRunnerService 捕获到 R 报错时,**唤醒专门的 Fixer Agent**。
|
||||
它拥有完全不同的 System Prompt,内部**被注入了丰富的“R 语言常见报错及修复指南 (Knowledge Base)”**。
|
||||
**Fixer Agent 的 Prompt 示例:**"你是一个顶尖的 R 语言 Debug 专家。
|
||||
刚才系统执行了这段代码:\[原始代码\]
|
||||
遇到了这个错误:\[R 原始报错,如 unexpected input 或 computationally singular\]**排错指南:**
|
||||
1. 如果是 unexpected input,通常是因为代码块中混入了未注释的中文解释,请剔除它们。
|
||||
2. 如果是 object not found,请核对原始列名大小写是否拼错,或者是否漏了引包(如 library(dplyr))。
|
||||
3. 如果是 computationally singular,说明存在严重的共线性或某列方差为0,请在代码中添加自动剔除方差为0的变量的逻辑。
|
||||
|
||||
请分析错误原因,并输出修复后的纯 R 代码。"
|
||||
|
||||
**优势:** 这种职能拆分让修复动作更具**靶向性**,大幅降低了大模型面对冰冷的 R 错误日志时产生幻觉的概率,自愈成功率可提升 60% 以上。
|
||||
|
||||
## **五、 最终结论**
|
||||
|
||||
你提出的分步思路不仅靠谱,更是通往高级数据科学智能体(Data Science Agent)的核心秘籍。
|
||||
|
||||
**行动建议:**
|
||||
|
||||
请后端和 Agent 研发团队在接下来的开发中,将这个长流程拆解为一个 **“多轮对话状态机 (Multi-turn State Machine)”**:
|
||||
|
||||
* 设定一个管线数组:\[Task1\_Desc, Task2\_Uni, Task3\_Multi, Task4\_Sens\]。
|
||||
* 让 Node.js 控制 LLM 逐个 Task 生成代码 \-\> 跑 Docker \-\> 读取结果 \-\> 喂给下一个 Task 的 Context。
|
||||
|
||||
同时,针对本次 R 执行报错,请优先修复错误处理代码中的 slice is not a function Bug,并**引入独立的 Fixer Agent 机制**,以确保自愈循环能高效、精准地运转!
|
||||
97
docs/03-业务模块/SSA-智能统计分析/07-统计专家配置/提升代码生成与修复成功率的高级策略.md
Normal file
97
docs/03-业务模块/SSA-智能统计分析/07-统计专家配置/提升代码生成与修复成功率的高级策略.md
Normal file
@@ -0,0 +1,97 @@
|
||||
# **架构进阶指南:提升 LLM 代码生成与修复成功率的 10 大高级策略**
|
||||
|
||||
**文档目的:** 针对 Agentic Workflow 中大模型写 R 代码容易报错、陷入死循环的问题,提供系统性的解决方案。
|
||||
|
||||
**核心逻辑:** 不要指望大模型“不犯错”,而是要建立一套“让它极难犯错,且一旦犯错能立刻定位”的工程护栏。
|
||||
|
||||
## **🎯 第一部分:提升“首次生成”成功率 (Getting It Right The First Time)**
|
||||
|
||||
防范于未然永远是成本最低的。为了防止类似 unexpected input(中文泄露到代码区)这种低级语法错误,我们需要在 Prompt 和约束上下狠手:
|
||||
|
||||
### **1\. 采用 XML 标签强制物理隔离 (XML Tagging)**
|
||||
|
||||
* **痛点**:传统的 Markdown 代码块 (r ... ) 很容易被大模型破坏,它经常会在反引号外面或者里面夹杂诸如“好的,根据您的要求...”之类的闲聊。
|
||||
* **策略**:在 Coder Agent 的 Prompt 中,强制要求它将纯代码包裹在自定义的 XML 标签中。
|
||||
* **Prompt 示例**:“你只能输出纯 R 代码。绝对不要输出任何 Markdown 标记、问候语或解释。**你必须且只能将代码放在 \<r\_code\> 和 \</r\_code\> 标签之间。**”
|
||||
* **后端解析**:Node.js 提取时直接用正则表达式提取 \<r\_code\> 内部的内容,彻底屏蔽外围的所有文字幻觉。
|
||||
|
||||
### **2\. 注入“防御性编程”黄金法则 (Defensive Prompting)**
|
||||
|
||||
* **痛点**:LLM 假设数据是完美的,但实际数据常有 NA、类型错误或极端值,导致 t.test 等函数直接崩溃。
|
||||
* **策略**:在 System Prompt 中硬编码医学统计的“防御性 R 编程规范”。
|
||||
* **Prompt 示例**:
|
||||
“写 R 代码时必须遵守以下防御规则:
|
||||
1. 模型计算前,强制剔除涉及变量的 NA 值:df \<- na.omit(df\[, c('X', 'Y')\])
|
||||
2. 强制类型转换:把分组变量明确转为因子 as.factor(),把数值变量明确转为数值 as.numeric()。
|
||||
3. 如果要做回归,先检查是否只有1个水平,如果只有1个水平直接停止执行。”
|
||||
|
||||
### **3\. 强制思维链注释化 (Chain of Thought in Comments)**
|
||||
|
||||
* **痛点**:如果不让大模型“说话”,直接写代码,它的逻辑往往会混乱(缺乏思维链的推演)。
|
||||
* **策略**:允许它思考,但**强制它把思考过程写在 R 代码的注释里**。
|
||||
* **Prompt 示例**:“在写具体代码前,请先使用 R 语言的注释符号 \# 逐行写下你的分析步骤和推演过程。确保每一行中文的前面都有 \#。”
|
||||
|
||||
### **4\. 数据字典的高保真注入 (High-Fidelity Schema Injection)**
|
||||
|
||||
* **痛点**:LLM 写错列名(大小写错误、多加了下划线)。
|
||||
* **策略**:不仅仅给 LLM 传入列名数组,最好把每一列的 Class (如 numeric, character) 和**前 3 行的具体数值**(Head)作为 Context 传给 Coder Agent。看到真实的数值长相,LLM 选错变量类型和拼错列名的概率会断崖式下降。
|
||||
|
||||
## **🛠️ 第二部分:提升“代码修复”成功率 (Making Self-Healing Work)**
|
||||
|
||||
一旦出错,如何让 Fixer Agent 一次性改对,而不是陷入“修了A错误,引发B错误”的死循环?
|
||||
|
||||
### **5\. R 端报错的“降维翻译” (Enhancing Error Traceback)**
|
||||
|
||||
* **痛点**:R 的默认报错极度晦涩(如 Error in eval(expr, envir) : object 'X' not found),不告诉你是哪一行代码报的错。Fixer Agent 拿到这种错误就像盲人摸象。
|
||||
* **策略**:在 R Docker 的 plumber.R 外壳中,使用 rlang 包捕获异常,将完整的调用栈和具体的出错行号抛给 Node.js。
|
||||
* **R 代码改造**:
|
||||
tryCatch({
|
||||
eval(parse(text \= input\_code))
|
||||
}, error \= function(e) {
|
||||
\# 提取具体的报错信息和可能的行号
|
||||
error\_msg \<- conditionMessage(e)
|
||||
\# 将此结构化错误返回给 Node.js
|
||||
stop(paste("\[R\_EXEC\_ERROR\]", error\_msg))
|
||||
})
|
||||
|
||||
### **6\. Fixer Agent 的“上下文重置” (Context Reset)**
|
||||
|
||||
* **痛点**:如果把错误信息直接 Append 到之前的长对话记录里让模型修改,模型会受之前历史信息的干扰,产生“注意力偏移”。
|
||||
* **策略**:Fixer Agent 必须是一个**拥有全新 Context 的独立会话**。
|
||||
* **输入构造**:它只需要接收 3 个东西:
|
||||
1. \<original\_code\>...原始代码...\</original\_code\>
|
||||
2. \<error\_log\>...R引擎的精确报错...\</error\_log\>
|
||||
3. \<data\_schema\>...列名和类型...\</data\_schema\>
|
||||
* 干净的上下文能让大模型将 100% 的注意力集中在“找 Bug”上。
|
||||
|
||||
### **7\. 引入 AST (抽象语法树) 静态检查 (Fail Fast)**
|
||||
|
||||
* **策略**:在 Node.js 把修复后的代码发给 R 之前(或者在 R 引擎运行 eval 之前),先执行纯粹的语法检查。
|
||||
* **R 端实现**:使用 parse(text \= code)。如果代码连括号都没闭合、引号没闭合,parse 会立刻报错,根本不需要进入漫长的数据加载和计算环节。这能将修复反馈循环(Feedback Loop)的延迟从几秒缩短到几毫秒。
|
||||
|
||||
### **8\. 强制输出“诊断报告”再输出代码**
|
||||
|
||||
* **痛点**:大模型拿到错误后,急于输出代码,往往只是“瞎蒙”一个改法。
|
||||
* **策略**:强制要求 Fixer Agent 遵循 Diagnosis \-\> Fix Plan \-\> Code 的标准格式输出。
|
||||
* **Prompt 示例**:
|
||||
“收到报错后,你必须按以下格式作答:
|
||||
1. **错误诊断**:分析 R 报错的根本原因。
|
||||
2. **修复方案**:说明你打算修改哪几行代码。
|
||||
3. **修正代码**:将修改后的完整代码放在 \<r\_code\> 标签中。”
|
||||
|
||||
## **🏗️ 第三部分:架构级防线 (Architectural Safeguards)**
|
||||
|
||||
### **9\. 异常分类与短路机制 (Error Classification & Circuit Breaker)**
|
||||
|
||||
有些错大模型能修,有些错大模型**绝对修不好**,千万不要浪费 Token 循环重试。
|
||||
|
||||
在 Node.js 中建立错误拦截字典:
|
||||
|
||||
* **可重试 (Retriable)**:object not found, unexpected input, could not find function(通常是少加了 library 或拼错变量)。
|
||||
* **直接短路 (Hard Abort)**:system is computationally singular (多重共线性,数据数学性质导致,大模型改代码没用), cannot allocate vector of size (内存超限,直接中断并提示用户)。
|
||||
|
||||
### **10\. 建立“错题本”机制 (Error Memory / RAG for Fixes)**
|
||||
|
||||
* **终极杀招**:在数据库建一张 ssa\_fixed\_errors 表。
|
||||
* **流程**:当某次 R报错 \-\> LLM修复 \-\> 再次执行成功 时,将这个组合 (报错信息 \+ 修复前代码 \-\> 修复后代码) 存入向量数据库。
|
||||
* **使用**:下次 Fixer Agent 遇到类似报错时,先从向量库检索历史成功修复案例喂给它。随着系统运行的时间越长,它修 Bug 的能力就越强,最终无限逼近资深 R 程序员。
|
||||
94
docs/03-业务模块/SSA-智能统计分析/07-统计专家配置/架构委员会审查报告:分步执行架构.md
Normal file
94
docs/03-业务模块/SSA-智能统计分析/07-统计专家配置/架构委员会审查报告:分步执行架构.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# **架构委员会独立审查报告:Plan-and-Execute 分步执行架构**
|
||||
|
||||
**审查对象:** plan-and-execute\_architecture\_0895bce2.plan.md
|
||||
|
||||
**审查时间:** 2026-03-07
|
||||
|
||||
**总体评级:** 🌟 **A 级 (方向极度正确,但底层状态管理存在重大设计缺陷)**
|
||||
|
||||
**核心裁决:** 强烈支持分步执行理念!但在 R 容器的“状态持久化 (Phase 5A)”和“步骤跳过逻辑”上,必须进行架构级修正,否则系统在并发环境下必然崩溃。
|
||||
|
||||
## **一、 极度赞赏的架构闪光点 (Highlights)**
|
||||
|
||||
1. **降维打击大模型幻觉**:让大模型一次写 50 行代码的成功率是 95%,一次写 300 行的成功率只有 30%。按步骤生成代码,彻底规避了 LLM 容易遗忘上下文和乱编变量名的通病。
|
||||
2. **极佳的渐进式 UX**:不再让用户盯着一个大大的“转圈”看一分钟。每个步骤独立出结果,进度条有了真实的物理意义。
|
||||
3. **精准的局部重试 (Micro-Healing)**:Step 3 报错了,只需把 Step 3 的代码重写,不需要把 Step 1(耗时的清洗)和 Step 2 再跑一遍,极大地节省了算力和时间。
|
||||
|
||||
## **二、 致命工程盲区与强制修正指令 (Critical Blind Spots & Fixes)**
|
||||
|
||||
### **🚨 盲区 1:Phase 5A 的“内存环境池”是分布式系统的灾难**
|
||||
|
||||
* **原计划设计**:在 R 进程内维护一个全局 SESSION\_POOL \<- new.env() 来保存上下文。
|
||||
* **致命隐患 (The Trap)**:
|
||||
1. **OOM 内存溢出**:如果 20 个用户同时在做分析,每个人的 df 有 50MB。这些环境全部堆积在 R 的内存中,Docker 容器会迅速耗尽内存并被宿主机 Kill 掉。
|
||||
2. **多进程/多实例负载均衡失效**:生产环境中的 R Plumber 通常会启动多个 Worker 进程,或者我们在 SAE 上部署了多个 Docker 实例。**用户的 Step 1 请求打到了容器 A(变量存在 A 的内存里),Step 2 请求如果被负载均衡打到了容器 B,容器 B 里根本没有这个 session!** 流程直接断裂。
|
||||
* **架构强制修正 (File-based Session State)**:
|
||||
坚决放弃内存池!改用硬盘(或共享存储)序列化工作空间。
|
||||
在 CodeRunnerService.ts 每次调用 R 时,告诉 R 去哪里加载/保存状态:
|
||||
\# R Docker 端的标准做法:基于磁盘序列化的 Jupyter 模式
|
||||
session\_file \<- paste0("/tmp/ssa\_session\_", input$session\_id, ".RData")
|
||||
|
||||
\# 1\. 恢复上一步的现场
|
||||
if (file.exists(session\_file) && input$step\_index \> 1\) {
|
||||
load(session\_file, envir \= .GlobalEnv)
|
||||
} else {
|
||||
\# 首次加载数据
|
||||
df \<- load\_data(input$data\_source)
|
||||
}
|
||||
|
||||
\# 2\. 执行当前步骤代码...
|
||||
eval(parse(text \= input$code), envir \= .GlobalEnv)
|
||||
|
||||
\# 3\. 保存现场给下一步用
|
||||
save.image(file \= session\_file)
|
||||
|
||||
*(注:如果采用多 Docker 实例部署,/tmp 需要挂载为阿里云 NAS 共享网盘,或将 .RData 文件上传/下载至 OSS。在 MVP 单实例阶段,本地 /tmp 配合定期清理脚本即可。)*
|
||||
|
||||
### **🚨 盲区 2:LLM 上下文失明 (Variable Namespace Blindness)**
|
||||
|
||||
* 如果是核心数据处理、模型拟合步骤失败 \-\> **必须强行阻断整个 Pipeline (Hard Abort)**,通知用户分析终止。
|
||||
* 如果是边缘步骤(如:Step 4 敏感性分析,或者最后画一张漂亮的散点图)失败 \-\> 允许跳过 (Soft Skip),并在最终总结中提示“图表生成失败”。
|
||||
|
||||
## **三、 融合《10 大高级策略》的防错与自愈增强 (Advanced Integration)**
|
||||
|
||||
结合之前制定的《提升 LLM 代码生成与修复成功率的 10 大高级策略》,分步执行(Plan-and-Execute)不仅需要宏观的状态调度,更需要微观的防错。建议将以下三条策略直接“镶嵌”到分步执行架构中:
|
||||
|
||||
### **🛡️ 借鉴 1:AST 语法树预检 (保护 Session 现场)**
|
||||
|
||||
* **结合点**:在 Phase 5B (CodeRunner 执行单步代码) 时。
|
||||
* **落地价值**:在调用 eval() 运行代码并将 R 环境保存为 .RData 现场之前,**必须先执行 parse(text \= input$code)**。如果大模型犯了低级语法错误(如未闭合括号、非法中文字符),预检会直接报错阻断。**绝对不能让脏代码污染当前的 Session 内存现场**。
|
||||
|
||||
### **🛡️ 借鉴 2:XML 标签提取 (保障代码纯净度)**
|
||||
|
||||
* **结合点**:在 Phase 5B (CoderAgent 按步骤生成代码) 时。
|
||||
* **落地价值**:不要信任 LLM 会乖乖只输出代码。由于分步生成的聊天属性,大模型极易在代码前后加上“Step 1 的分析代码如下:”等解释性文字。强制 CoderAgent 使用 \<r\_code\>...\</r\_code\> 标签包裹单步代码,并在 Node.js 端用正则严格提取,从根源消灭 unexpected input 错误。
|
||||
|
||||
### **🛡️ 借鉴 3:结合错误分类的“智能短路” (增强软/硬阻断)**
|
||||
|
||||
* **结合点**:与本报告“盲区 3”的跳过逻辑结合。
|
||||
* **落地价值**:某一步骤失败后是“重试、跳过还是终止”,不仅取决于 isCritical,还要看错误分类:
|
||||
* **Fatal Error (硬阻断)**:如果 R 抛出 computationally singular(共线性),说明数据数学性质存在冲突,即使重试 LLM 也修不好,直接中断。
|
||||
* **Fixable Error (可修复重试)**:如果是 object 'age\_years' not found,则启动独立的 **Fixer Agent**。利用**上下文重置 (Context Reset)**,只给它看当前步骤的代码、报错信息和 Data Schema,让其专注修复后再重试。
|
||||
|
||||
## **四、 对 Phase 5B 状态机 (DB Schema) 的优化建议**
|
||||
|
||||
您在 SsaAgentExecution 中新增了 stepResults: Json\[\]。为了配合前端渲染“等待中、生成中、执行中、已完成、错误”的复杂状态,建议定义如下精确的状态流转模型:
|
||||
|
||||
// 建议的 AgentStepResult 状态流转字典:
|
||||
type StepStatus \=
|
||||
| 'pending' // 还没轮到它
|
||||
| 'coding' // LLM 正在吐代码 (前端渲染骨架屏 \+ 打字机)
|
||||
| 'executing' // R 引擎正在跑 (前端渲染转圈)
|
||||
| 'completed' // 成功拿到 ReportBlocks (前端渲染图表)
|
||||
| 'error' // R 报错 (前端展示红色错误框,准备重试)
|
||||
| 'skipped'; // 非致命错误被跳过
|
||||
|
||||
这种精确的状态切分,能让前端 AgentCodePanel 的进度条和状态图标完美契合用户的心理预期。
|
||||
|
||||
## **五、 最终审核结论**
|
||||
|
||||
这是一次**将系统体验从“玩具”跃升为“生产力工具”的重构**。
|
||||
|
||||
只要把 **R 环境变量的磁盘序列化(解决内存爆炸和状态丢失)**、**严格的错误阻断机制** 以及 **XML/AST 防错策略** 落实到位,这个 Plan-and-Execute 架构将使你们的 SSA-Pro 在交互体验和容错率上直接对标顶级的 Agent 平台。
|
||||
|
||||
**准予通过,请优先攻坚 Phase 5A 的文件持久化沙箱!**
|
||||
@@ -30,6 +30,7 @@
|
||||
| BE-5 | RVW 新增临床专业评估维度(ClinicalAssessmentSkill) | `clinicalService.ts`(新), `ClinicalAssessmentSkill.ts`(新), `library/index.ts`, `profile.ts`, `utils.ts`, `reviewWorker.ts`, `reviewService.ts` | 重新构建镜像 | 新增 clinical Agent + Skill,存储在 contextData.clinicalReview |
|
||||
| BE-6 | RVW 稳定性增强:SkillExecutor Promise.allSettled + partial_completed 状态 + errorDetails | `executor.ts`, `reviewWorker.ts`, `reviewService.ts`, `reviewController.ts`, `types/index.ts` | 重新构建镜像 | 并行 Skill 故障隔离,部分模块失败时仍返回成功模块结果,新增 `partial_completed` 任务状态 |
|
||||
| BE-7 | DataForensicsSkill LLM 核查增加独立 60s 超时 | `DataForensicsSkill.ts` | 重新构建镜像 | LLM 核查超时不阻塞整体 Skill,graceful 降级为纯规则验证 |
|
||||
| BE-8 | SSA Agent 通道体验优化(方案 B 左右职责分离 + 10 项 Bug 修复) | `ChatHandlerService.ts`, `AgentCoderService.ts`, `chat.routes.ts` | 重新构建镜像 | 视线牵引 Prompt + maxTokens 8000 + 重试流式生成 + consoleOutput 类型防御 + Prompt 铁律 + parseCode 健壮化 |
|
||||
|
||||
### 前端变更
|
||||
|
||||
@@ -41,6 +42,7 @@
|
||||
| FE-4 | RVW 数据验证报告增加 LLM 核查结果展示 | `ForensicsReport.tsx`, `rvw/types/index.ts` | 重新构建镜像 | 总览展示完整 LLM 报告,每个表格卡片展开后显示对应 AI 核查结果(Markdown) |
|
||||
| FE-5 | RVW 新增临床专业评估 Tab + Agent 选择项 | `ClinicalReport.tsx`(新), `AgentModal.tsx`, `TaskDetail.tsx`, `rvw/types/index.ts` | 重新构建镜像 | 共 4 个 Tab:稿约规范性/方法学/数据验证/临床评估;Word 导出包含临床评估章节 |
|
||||
| FE-6 | RVW 前端支持 partial_completed 状态(部分完成) | `TaskDetail.tsx`, `TaskTable.tsx`, `rvw/types/index.ts` | 重新构建镜像 | 琥珀色警告横幅展示失败模块详情,列表页显示"部分完成"标签,支持查看已完成模块的报告 |
|
||||
| FE-7 | SSA Agent 通道体验优化(方案 B + 动态 UI) | `AgentCodePanel.tsx`, `SSAChatPane.tsx`, `SSAWorkspacePane.tsx`, `SSACodeModal.tsx`, `useSSAChat.ts`, `ssaStore.ts`, `ssa.css` | 重新构建镜像 | 左右职责分离 + JWT 刷新 + 重试代码展示 + 错误信息展示 + 进度条同步 + 导出/查看代码按钮恢复 + ExecutingProgress 组件 |
|
||||
|
||||
### Python 微服务变更
|
||||
|
||||
@@ -53,6 +55,7 @@
|
||||
| # | 变更内容 | 涉及文件 | 需要操作 | 备注 |
|
||||
|---|---------|---------|---------|------|
|
||||
| R-1 | 新增 POST /api/v1/execute-code 端点(Agent 通道任意 R 代码执行) | `plumber.R` | 重新构建镜像 | 含超时 + 沙箱限制 |
|
||||
| R-2 | Agent 结构化错误处理增强(20+ 模式匹配 + format_agent_error) | `plumber.R`, `utils/error_codes.R` | 重新构建镜像 | withCallingHandlers 捕获 warnings/messages + 行号提取 + 错误分类 + 修复建议 |
|
||||
|
||||
### 环境变量 / 配置变更
|
||||
|
||||
|
||||
Reference in New Issue
Block a user