Files

HaHafeng 96290d2f76 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

2026-01-24 17:29:24 +08:00

6.4 KiB

Raw Blame History

针对 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 耗尽连接)

实施步骤：

进入 RDS 控制台，新建数据库 ai_clinical_dev。
即使是同一个 RDS 实例，由于数据库名不同，数据文件在逻辑上是完全隔离的。
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” 方案：

数据库：
- 继续使用同一个 RDS 实例。
- 必须创建两个 DB：prod_db 和 dev_db。
- 必须使用两个数据库账号，防止权限越界。
SAE 环境：
- 生产环境：SAE 专业版（或标准版），常驻。
- 测试环境：SAE 标准版（无需专业版）。
- 关键动作：
  - 配置 SAE 测试环境的定时启停策略（阿里云 SAE 控制台支持定时启停）。
  - 例如：09:00 启动，20:00 停止。周末不启动。
  - 或者写一个脚本，只在部署新镜像时启动，闲置 1 小时无流量自动缩容到 0（需配合 ALB/CLB 流量监控，略复杂，建议手动或定时停止）。
本地开发增强：
- 完善 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），这就是云原生最大的红利。

6.4 KiB Raw Blame History Unescape Escape