Tricoder/doc/平台设计/后端技术栈方案.md

后端技术栈方案

版本号：v0.1.0 最后更新：2026-04-04

1. 目的

本文档用于定义本项目第一阶段的后端技术栈选择，并说明每一层技术的职责边界与选择理由。

2. 设计目标

后端技术栈应满足以下要求：

• 能支撑 AI 编排工作流
• 能支撑算法链执行
• 能支撑结构化实验记录
• 能与 Flutter 终端稳定通信
• 能支持后续扩展到更多模态和更多实验类型

3. 总体建议

第一阶段建议采用混合后端架构：

• API 层：Python + FastAPI
• AI 编排层：Python
• 算法执行层：Rust
• 模型服务层：vLLM + Gemma 4
• 数据存储层：PostgreSQL

4. 为什么不建议单语言统一

如果后端全部使用单一语言，会在某一侧明显吃亏：

• 全 Dart：模型编排与算法生态不占优
• 全 Rust：第一阶段开发速度较慢，模型编排迭代成本高
• 全 Python：算法执行层和本地可复用核心不够理想

因此第一阶段更合理的做法是：

• 用 Python 负责“快迭代、强表达”的编排层
• 用 Rust 负责“高性能、可复用”的算法执行层

5. API 层选型：FastAPI

5.1 职责

API 层负责：

• Flutter 终端访问入口
• 音频样本上传
• 分析任务发起
• 实验过程查询
• 结论查询
• WebSocket 实时状态推送

5.2 选择理由

FastAPI 适合第一阶段，原因包括：

• 开发效率高
• 类型与 schema 表达清晰
• 适合结构化 API
• 适合快速构建内部平台接口
• 和 Python 编排层天然协同

6. AI 编排层选型：Python 服务

6.1 职责

AI 编排层负责：

• 读取 Observation、Evidence、ExperimentSummary
• 构造 AI 输入
• 调用 Gemma 4
• 生成结构化 OrchestratorPlan
• 输出阶段性结论和最终结论

6.2 选择理由

Python 适合这一层，原因包括：

• LLM 适配生态成熟
• JSON schema 和结构化输出处理方便
• prompt 与编排策略迭代速度快
• 更适合快速试错与优化

7. 算法执行层选型：Rust

7.1 职责

算法执行层负责：

• 执行本地和远端算法链
• 跑基础探针和验证模块
• 生成结构化证据
• 生成评分与失败原因

7.2 选择理由

Rust 适合这一层，原因包括：

• 性能稳定
• 便于控制资源消耗
• 适合做可复用核心库
• 可与 Flutter 终端本地核心共享部分实现

8. 模型服务层选型：vLLM + Gemma 4

8.1 职责

模型服务层负责：

• 承载 Gemma 4
• 为 AI 编排层提供稳定推理接口

8.2 选择理由

第一阶段建议把 Gemma 4 放在后端，而不是手机本地，原因包括：

• 编排任务比终端展示更适合后端集中运行
• 便于统一模型版本和行为
• 便于控制成本与日志
• 便于后续扩展到更复杂实验循环

9. 数据存储层选型：PostgreSQL

9.1 职责

数据存储层负责保存：

• Observation 元数据
• Evidence
• Experiment
• ScoreCard
• Conclusion
• 会话状态

9.2 选择理由

PostgreSQL 适合本项目第一阶段，原因包括：

• 结构化数据支持成熟
• 事务与查询能力稳定
• 适合实验树和状态流转管理
• jsonb 适合保存部分灵活证据结构

10. 第一阶段暂不引入的基础设施

第一阶段建议暂不引入：

• 复杂微服务网格
• 大规模消息中间件
• 分布式工作流平台
• 多数据库混搭

原因：

• 当前阶段重点是跑通最小实验闭环
• 过早引入复杂基础设施会拖慢主线

11. 第一阶段推荐后端结构

Flutter App
  -> FastAPI API
      -> Python Orchestrator
      -> Rust Experiment Runner
      -> PostgreSQL
      -> vLLM (Gemma 4)

12. 结论

第一阶段后端建议采用：

• FastAPI 作为 API 与会话入口
• Python 作为 AI 编排层
• Rust 作为算法执行层
• vLLM + Gemma 4 作为模型服务层
• PostgreSQL 作为实验数据存储层

该方案在开发效率、性能、结构清晰度和后续扩展性之间较为平衡。