feat(aia): Implement Protocol Agent MVP with reusable Agent framework
Sprint 1-3 Completed (Backend + Frontend): Backend (Sprint 1-2): - Implement 5-layer Agent framework (Query->Planner->Executor->Tools->Reflection) - Create agent_schema with 6 tables (agent_definitions, stages, prompts, sessions, traces, reflexion_rules) - Create protocol_schema with 2 tables (protocol_contexts, protocol_generations) - Implement Protocol Agent core services (Orchestrator, ContextService, PromptBuilder) - Integrate LLM service adapter (DeepSeek/Qwen/GPT-5/Claude) - 6 API endpoints with full authentication - 10/10 API tests passed Frontend (Sprint 3): - Add Protocol Agent entry in AgentHub (indigo theme card) - Implement ProtocolAgentPage with 3-column layout - Collapsible sidebar (Gemini style, 48px <-> 280px) - StatePanel with 5 stage cards (scientific_question, pico, study_design, sample_size, endpoints) - ChatArea with sync button and action cards integration - 100% prototype design restoration (608 lines CSS) - Detailed endpoints structure: baseline, exposure, outcomes, confounders Features: - 5-stage dialogue flow for research protocol design - Conversation-driven interaction with sync-to-protocol button - Real-time context state management - One-click protocol generation button (UI ready, backend pending) Database: - agent_schema: 6 tables for reusable Agent framework - protocol_schema: 2 tables for Protocol Agent - Seed data: 1 agent + 5 stages + 9 prompts + 4 reflexion rules Code Stats: - Backend: 13 files, 4338 lines - Frontend: 14 files, 2071 lines - Total: 27 files, 6409 lines Status: MVP core functionality completed, pending frontend-backend integration testing Next: Sprint 4 - One-click protocol generation + Word export
This commit is contained in:
@@ -0,0 +1,163 @@
|
||||
# **研究方案制定 Agent (Protocol Agent) 统一架构方案 V3.0**
|
||||
|
||||
版本： v3.0 (SOP编排与后端配置版)
|
||||
日期： 2026-01-20
|
||||
适用范围： 壹证循科技 (AIclinicalresearch)
|
||||
核心进化： 引入 "Code-as-Skeleton, Data-as-Brain" 理念。将思维链 (CoT) 下沉为后端可配置的 SOP 数据，实现逻辑与代码解耦。
|
||||
|
||||
## **1\. 核心设计理念**
|
||||
|
||||
我们摒弃传统的“无状态问答”模式，构建一个维护长程记忆、具备反思能力的 **Protocol Agent**。
|
||||
|
||||
### **1.1 四大核心组件 (The 4 Pillars)**
|
||||
|
||||
* 🧠 **大脑 (Brain): Orchestrator 服务**
|
||||
* 负责 **规划 (Plan)**：决定当前处于哪个阶段，下一步该做什么。
|
||||
* 负责 **反思 (Reflexion)**：对用户的操作结果进行质量校验（如样本量是否合理）。
|
||||
* **升级点**：V3 版本中，大脑的思考逻辑（思维链）不再写死在代码里，而是从数据库加载配置。
|
||||
* 💾 **记忆 (Memory): ProtocolContext 表**
|
||||
* 利用 Postgres 的 JSONB 存储“活的”方案数据。
|
||||
* **长程记忆**：不仅记住聊天记录，更记住结构化的 PICO、样本量 N 值、观察指标等关键状态，突破 LLM Token 限制。
|
||||
* 📚 **知识 (Knowledge): 自建 EKB (Postgres-Only)**
|
||||
* 提供 **混合检索 (Hybrid Search)** 能力。
|
||||
* **结构化检索**：利用 SQL 精准筛选（如“找样本量\>500的RCT研究”）。
|
||||
* **语义检索**：利用 pgvector 进行向量相似度匹配。
|
||||
* 🛠️ **手脚 (Hands): Deep Link Action**
|
||||
* 通过 **Action Card** 调用的现有 Web 工具（如样本量计算器、数据清洗工具）。
|
||||
* 实现“对话无法完成的复杂操作，跳转到专业工具完成，再把结果同步回来”的闭环。
|
||||
|
||||
### **1.2 总体架构拓扑 (V3)**
|
||||
|
||||
引入了全新的 **LLM Ops 控制层**，支持运营人员在后台动态调整 Agent 的思考逻辑。
|
||||
|
||||
graph TD
|
||||
User\[用户 (React UI)\] \<--\> Entry\[单一入口: Protocol Agent\]
|
||||
|
||||
subgraph "前端交互 (Interaction)"
|
||||
Chat\[流式对话\]
|
||||
StatePanel\[实时状态看板\]
|
||||
DeepLink\[Action Card\]
|
||||
end
|
||||
Entry \--\> Chat & StatePanel
|
||||
|
||||
subgraph "后端引擎 (Orchestrator Engine)"
|
||||
Loader\[配置加载器\]
|
||||
Executor\[SOP 执行引擎\]
|
||||
Reflector\[Reflexion 卫士\]
|
||||
Tracer\[全链路追踪\]
|
||||
end
|
||||
|
||||
Chat \<--\> Executor
|
||||
|
||||
subgraph "大脑配置中心 (LLM Ops)"
|
||||
DB\_Prompt\[(Prompt & CoT 表)\]
|
||||
DB\_Trace\[(Trace 日志表)\]
|
||||
AdminUI\[运营管理后台\]
|
||||
end
|
||||
|
||||
AdminUI \--配置 SOP--\> DB\_Prompt
|
||||
DB\_Prompt \--加载--\> Loader
|
||||
Loader \--注入--\> Executor
|
||||
Executor \--写入日志--\> Tracer
|
||||
Tracer \--可视化--\> AdminUI
|
||||
|
||||
subgraph "记忆与知识 (Memory & Knowledge)"
|
||||
DB\_Ctx\[(Protocol Context)\]
|
||||
DB\_EKB\[(Self-built RAG)\]
|
||||
end
|
||||
|
||||
Executor \<--\> DB\_Ctx & DB\_EKB
|
||||
|
||||
## **2\. 核心机制：后端配置化思维链 (Backend CoT)**
|
||||
|
||||
### **2.1 什么是“配置化 CoT”？**
|
||||
|
||||
我们将 AI 的思考过程拆解为标准作业程序 (SOP)，存储为 JSON 数组。这意味着您可以在后台增加一个检查步骤，而无需修改代码。
|
||||
|
||||
**数据库配置示例 (JSON):**
|
||||
|
||||
\[
|
||||
{
|
||||
"step": 1,
|
||||
"key": "completeness\_check",
|
||||
"desc": "检查 PICO 完整性",
|
||||
"instruction": "检查用户输入是否包含 P, I, C, O 四个要素。如果缺失，标记为 MISSING。"
|
||||
},
|
||||
{
|
||||
"step": 2,
|
||||
"key": "methodology\_match",
|
||||
"desc": "方法学匹配",
|
||||
"instruction": "根据研究目的推荐设计类型（RCT/队列）。"
|
||||
},
|
||||
{
|
||||
"step": 3,
|
||||
"key": "response\_generation",
|
||||
"desc": "生成回复",
|
||||
"instruction": "综合以上分析，给出建议。如果 PICO 缺失，请追问。"
|
||||
}
|
||||
\]
|
||||
|
||||
### **2.2 运行时表现 (Runtime Behavior)**
|
||||
|
||||
Orchestrator 会将上述 JSON 动态编译为 System Prompt。AI 的输出将包含显式的 **XML 思考标签**：
|
||||
|
||||
\<completeness\_check\>
|
||||
用户提供了 P 和 I，但缺失 C (对照组) 和 O (结局)。
|
||||
\</completeness\_check\>
|
||||
|
||||
\<methodology\_match\>
|
||||
因缺失关键信息，暂无法确定设计类型，倾向于 RCT。
|
||||
\</methodology\_match\>
|
||||
|
||||
\<response\_generation\>
|
||||
您好，为了帮您设计方案，我还需要了解：您的对照组是什么？主要结局指标是什么？
|
||||
\</response\_generation\>
|
||||
|
||||
**前端展示：** 前端解析 \<completeness\_check\> 标签，将其放入可折叠的 **"深度思考"** 组件中，让用户看到 AI 的逻辑。
|
||||
|
||||
## **3\. 业务流程编排**
|
||||
|
||||
### **3.1 完整交互闭环**
|
||||
|
||||
1. **User**: 输入 "我要做阿司匹林的研究"。
|
||||
2. **Orchestrator**:
|
||||
* 加载当前阶段 (SCIENTIFIC\_QUESTION) 的 Prompt 和 CoT 配置。
|
||||
* 执行 LLM 生成。
|
||||
3. **Reflexion (隐式)**:
|
||||
* Orchestrator 后台运行微型 LLM 任务，尝试从对话中提取 PICO。
|
||||
* 如果提取成功，更新 ProtocolContext。
|
||||
4. **State Panel**: 前端通过 SSE 收到更新，右侧面板自动点亮 "P" 和 "I" 字段。
|
||||
5. **Plan**:
|
||||
* Orchestrator 判断当前阶段已完成 (PICO 齐全)。
|
||||
* **主动推送**：生成 Action Card "建议进入下一步：选题评价"。
|
||||
|
||||
### **3.2 深度链接与反思 (Deep Link & Reflexion Loop)**
|
||||
|
||||
当涉及到工具调用（如样本量计算）时：
|
||||
|
||||
1. **Action**: AI 生成 Action Card (Deep Link)。
|
||||
2. **Execute**: 用户点击跳转 \-\> 工具页计算 \-\> 点击“同步”。
|
||||
3. **Reflexion Guard (后端强制校验)**:
|
||||
* 数据回写到 DB 时，触发后端校验函数 reflexionGuard()。
|
||||
* **规则配置化**：(N \< 10 OR N \> 10000\) \-\> 报警。
|
||||
* **反馈**：如果校验失败，AI 主动发送消息：“⚠️ 样本量异常，请检查参数。”
|
||||
|
||||
## **4\. 可观测性与调试 (Observability)**
|
||||
|
||||
为了解决 "Prompt 难调" 的问题，V3 引入了 **Trace 机制**。
|
||||
|
||||
* **Trace ID**: 每次对话生成一个唯一 ID。
|
||||
* **Step Recording**: 记录 Router 决策、Prompt 组装结果、CoT 输出、工具返回。
|
||||
* **Replay**: 在 Admin 后台，可以一键重放某个 Trace，修改 Prompt 后重新运行，对比效果。
|
||||
|
||||
## **5\. 实施路线图 (Roadmap)**
|
||||
|
||||
1. **Week 1: 数据层升级**
|
||||
* 修改 prompt\_templates 表结构，增加 chain\_config。
|
||||
* 建立 agent\_traces 表。
|
||||
2. **Week 2: 引擎升级**
|
||||
* 重构 Orchestrator，实现动态 CoT 组装逻辑。
|
||||
* 实现 XML 标签解析器。
|
||||
3. **Week 3: 前端适配**
|
||||
* 升级 Chat 组件，支持渲染 XML 思考过程。
|
||||
* 完善右侧 State Panel 的实时同步。
|
||||
Reference in New Issue
Block a user