# 后端技术栈方案 版本号：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. 第一阶段推荐后端结构 ```text Flutter App -> FastAPI API -> Python Orchestrator -> Rust Experiment Runner -> PostgreSQL -> vLLM (Gemma 4) ``` ## 12. 结论 第一阶段后端建议采用： - `FastAPI` 作为 API 与会话入口 - `Python` 作为 AI 编排层 - `Rust` 作为算法执行层 - `vLLM + Gemma 4` 作为模型服务层 - `PostgreSQL` 作为实验数据存储层 该方案在开发效率、性能、结构清晰度和后续扩展性之间较为平衡。