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

docs/07-运维文档/架构优化建议：2人团队SAE降本增效方案.md

@@ -0,0 +1,124 @@
+# **针对 2 人初创团队的 SAE \+ RDS 架构降本增效方案**
+
+**现状诊断：**
+
+* **团队规模：** 2人（极简团队）  
+* **当前痛点：** 成本压力（双 SAE 环境费用） vs 运维安全（需要隔离测试）  
+* **关键约束：** 必须防止类似 prisma db push 的生产事故再次发生。
+
+## **策略一：数据库层面 —— “同居不同室”**
+
+你们现在的做法是共享同一个 RDS PostgreSQL 15 实例。这在创业初期是**非常明智**的选择，不需要改变。购买两个 RDS 实例对于目前的业务量来说太浪费了。
+
+但是，**“共享”的方式决定了生死**。
+
+### **1\. 绝对禁止的做法**
+
+❌ **Dev 和 Prod 使用同一个数据库名（Database Name），试图靠 Schema 区分。**
+
+* **风险**：你们的代码中（特别是 Prisma 和 pg-boss）可能硬编码了 Schema 名称（如 platform\_schema）。  
+* **后果**：Dev 环境启动后，pg-boss Worker 会连接到数据库，开始抓取 Prod 环境的任务队列进行处理。这会导致生产任务丢失或被错误处理。
+
+### **2\. 推荐做法：Database 级别的隔离**
+
+✅ **在同一个 RDS 实例中，创建两个完全独立的数据库。**
+
+| 环境变量 | 生产环境 (Prod) | 开发/测试环境 (Dev) |
+| :---- | :---- | :---- |
+| **DATABASE\_URL** | .../ai\_clinical\_prod | .../ai\_clinical\_dev |
+| **用户名** | aiclinical\_prod\_user | aiclinical\_dev\_user |
+| **资源限制** | 无限制 | 限制连接数 (避免 Dev 耗尽连接) |
+
+**实施步骤：**
+
+1. 进入 RDS 控制台，新建数据库 ai\_clinical\_dev。  
+2. 即使是同一个 RDS 实例，由于数据库名不同，数据文件在逻辑上是完全隔离的。  
+3. Dev 环境即使执行 prisma db push \--force-reset，也只会清空 ai\_clinical\_dev，**生产环境绝对安全**。
+
+## **策略二：计算层面 (SAE) —— “分时租赁与按需启停”**
+
+对于 SAE，你们最大的优势是**Serverless 的弹性**。如果测试环境 24 小时开着，那就是把 SAE 当 ECS 用，非常亏。
+
+### **1\. 生产环境 (Production)**
+
+* **策略**：保持常驻，配置最小实例数为 1（或 2 保证高可用）。  
+* **配置**：开启弹性伸缩，根据 CPU/内存自动扩容。
+
+### **2\. 开发/测试环境 (Dev/Test)**
+
+**核心建议：不要让它 24 小时运行！**
+
+#### **方案 A：一键启停 (手动省钱法)**
+
+* **操作**：  
+  * 平时开发：在本地 localhost 使用 Docker Compose \+ 本地 Postgres 开发（完全免费）。  
+  * 提交代码后：如果需要验证，去 SAE 控制台点击“启动”。  
+  * 验证完/下班后：去 SAE 控制台点击\*\*“停止”\*\*（由 1 实例缩容为 0）。  
+* **成本影响**：SAE 停止的应用**不收取计算费用**（只收取极少的快照存储费）。如果每天只开 2 小时测试，成本降低 90%。
+
+#### **方案 B：CI/CD 触发式环境 (自动化法)**
+
+* **原理**：利用 GitHub Actions 或 阿里云云效。  
+* **流程**：  
+  1. 代码 Push 到 dev 分支。  
+  2. CI 流水线构建镜像。  
+  3. CI 调用阿里云 API，**更新并启动** SAE Dev 应用。  
+  4. 设置一个定时任务（如每晚 22:00），自动调用 API **停止** Dev 应用。
+
+## **策略三：极致省钱的替代架构 (如果不使用 SAE 测试环境)**
+
+如果连 SAE 测试环境的“按需启动”成本都想省，可以考虑以下架构：
+
+### **1\. "Localhost is King" 模式**
+
+既然只有 2 个人，且都在内网或可以通过 VPN 协作：
+
+* **放弃 SAE 测试环境**。  
+* **开发验证**：每人本地运行全套 Docker Compose（包含前端、后端、Postgres、MinIO 模拟 OSS）。  
+* **集成测试**：其中一人的电脑作为“临时服务器”，通过 ngrok 或 frp 暴露端口给另一人测试。  
+* **上线**：直接部署到 SAE 生产环境。  
+* **缺点**：缺乏一个稳定的“预发环境”，上线风险略高。
+
+### **2\. ECS "脏"环境模式 (Dirty Dev Box)**
+
+* **做法**：买一台最便宜的 **ECS (突发性能实例 t6/t5)**，或者利用闲置的旧笔记本/工控机放在公司/家里。  
+* **部署**：上面装一个 Docker，把所有 Dev 服务（前端、后端、Python、DB）全扔进去。  
+* **成本**：一台 2核4G 的 t6 实例，一个月可能只要几十块钱（或者抢占式实例，更便宜）。  
+* **优势**：固定 IP，成本极低，随便折腾。  
+* **劣势**：需要自己维护 Linux、Docker 环境。
+
+## **综合建议：给你们团队的最佳实践**
+
+考虑到你们已经熟悉了 SAE 且希望减少运维，我推荐 **“改良版 SAE \+ 共享 RDS”** 方案：
+
+1. **数据库**：  
+   * 继续使用**同一个 RDS 实例**。  
+   * **必须**创建两个 DB：prod\_db 和 dev\_db。  
+   * **必须**使用两个数据库账号，防止权限越界。  
+2. **SAE 环境**：  
+   * **生产环境**：SAE 专业版（或标准版），常驻。  
+   * **测试环境**：**SAE 标准版（无需专业版）**。  
+   * **关键动作**：  
+     * 配置 SAE 测试环境的**定时启停**策略（阿里云 SAE 控制台支持定时启停）。  
+     * 例如：09:00 启动，20:00 停止。周末不启动。  
+     * 或者写一个脚本，只在部署新镜像时启动，闲置 1 小时无流量自动缩容到 0（需配合 ALB/CLB 流量监控，略复杂，建议手动或定时停止）。  
+3. **本地开发增强**：  
+   * 完善 docker-compose.yml。确保本地开发体验和云端 99% 一致。  
+   * 这样你们 90% 的测试工作（包括 Python 微服务、数据清洗逻辑）都可以在本地完成，只有最后 10% 需要用到 SAE 测试环境。
+
+### **成本对比预估 (月)**
+
+| 方案 | 生产环境成本 | 测试环境成本 | 运维复杂度 | 推荐度 |
+| :---- | :---- | :---- | :---- | :---- |
+| **现状 (双 SAE 常驻)** | ¥600+ | ¥300+ | 低 | ⭐⭐ |
+| **推荐 (Dev 定时启停)** | ¥600+ | **¥50 (按量付费)** | 中 (需配置一次) | ⭐⭐⭐⭐⭐ |
+| **ECS 廉价测试机** | ¥600+ | ¥40-80 | 高 (需维护服务器) | ⭐⭐⭐ |
+| **Localhost 只有生产** | ¥600+ | ¥0 | 低 (但在上线时风险极高) | ⭐ |
+
+### **总结**
+
+对于 2 人团队，**时间比计算资源更贵**。
+
+不要为了省几百块钱去维护一套复杂的自建 ECS 环境。
+
+**继续用 SAE，但是要学会“关机”。** 就像你离开房间会关灯一样，没人测试的时候，把 SAE Dev 环境关掉（缩容到 0），这就是云原生最大的红利。