技术栈选型
定义 Deep Thought 系统的技术栈选型及理由。
核心原则：以 Python 为核心，架构契约驱动，运行形态无关。 每个模块只要遵守接口契约，可以跑在任何地方——本地脚本、Docker、Lambda、Cloud Worker。
决策总览
层级 技术选择 说明
──────────────────────────────────────────────────────
语言 Python 3.11+ AI/金融数据生态最强
异步框架 FastAPI 异步原生、自动文档、可作 API 层
数据库 embedded-postgres 嵌入式 PG，开发零配置，迁移零风险
ORM SQLAlchemy 屏蔽数据库差异
向量检索 pgvector (PG 扩展) 前期即可用，无需额外服务
缓存/队列 diskcache + queue.Queue 前期无需 Redis
任务调度 APScheduler 纯 Python，轻量
LLM 调用 LiteLLM 统一接口，支持多模型切换1. 语言：Python 3.11+
决定：纯 Python。
理由：
- OpenBB、pandas、ccxt、IBKR API 客户端、Longbridge SDK 均为 Python 原生
- LangGraph / CrewAI / LiteLLM 均为 Python 框架
- 系统核心价值在数据处理和 AI 推理，不在前端交互
- 异步能力通过 FastAPI + asyncio 覆盖
否决方案：
- 纯 TypeScript：金融数据生态弱，部分 LLM 框架支持差
- Python + TS 混合：两套代码库，维护成本高于收益
2. 异步框架：FastAPI
决定：FastAPI 作为统一的异步框架和 API 层。
理由：
- 异步原生（async/await），适合 I/O 密集的数据采集和 LLM 调用
- 自动生成 OpenAPI 文档，接口契约可视化
- Pydantic 模型同时服务于数据校验、API 文档、序列化
- 未来需要 web 界面时，FastAPI 直接提供后端 API
3. 数据库：embedded-postgres
决定：开发阶段使用 embedded-postgres，生产环境迁移至完整 PostgreSQL。
理由：
- embedded-postgres 就是 PostgreSQL，只是以子进程方式运行
- 同一引擎、同一 SQL、同一数据格式，迁移等同于"搬家"而非"翻译"
- 前期即可使用 PG 全部能力：JSONB、pgvector、全文搜索、ARRAY 类型
- pip 安装，Python 代码控制启停，无需手动管理服务
- 迁移至完整 PG 只需
pg_dump | psql，零兼容性风险
升级路径：
Phase 1-5: embedded-postgres (开发/本地运行)
Phase 6+: Docker PostgreSQL 或云 RDS (生产部署)否决方案：
- SQLite：类型系统弱、无原生 JSONB、迁移到 PG 有兼容性风险
- 直接装完整 PG：前期配置重，不符合渐进式原则
pgvector 扩展：
- embedded-postgres 支持安装扩展，前期即可用 pgvector 做向量检索
- 用于叙事的语义匹配搜索（新旧叙事对比）
4. ORM：SQLAlchemy
决定：SQLAlchemy 2.0+（使用 async 模式）。
理由：
- 屏蔽数据库差异，切换数据库只需改连接字符串
- 声明式模型定义与 Pydantic 可互转
- 支持异步（asyncpg 驱动），与 FastAPI 配合
5. 缓存与队列
决定：前期 diskcache + Python queue.Queue，后期可升级 Redis。
| 需求 | 前期方案 | 后期方案 |
|---|---|---|
| 缓存 | diskcache（磁盘持久化字典） | Redis |
| 任务队列 | queue.Queue + threading | Celery / Redis Queue |
| Pub/Sub | 自定义事件总线（进程内） | Redis Pub/Sub |
理由：
- 前期零外部依赖，
pip install diskcache即可 - diskcache 支持过期、持久化，覆盖大部分缓存场景
- 数据量增长或需要分布式时，平滑迁移至 Redis
6. 任务调度：APScheduler
决定：APScheduler。
理由：
- 纯 Python，无需外部服务（对比：Celery 需要 broker）
- 支持 Cron 式调度、间隔调度、一次性任务
- 可持久化任务状态（配合 SQLAlchemy jobstore）
- 后期可升级为 Celery 或 Airflow，接口层隔离
7. LLM 调用：LiteLLM
决定：LiteLLM 作为统一 LLM 调用层。
理由：
- 统一接口调用 Claude / GPT / DeepSeek / 开源模型
- 一个参数切换提供商，不改业务代码
- 内置重试、限流、fallback 逻辑
- 成本追踪
模型策略（详见 LLM 选型）：
- 核心分析（Persona 辩论、合成推理）：Claude Opus / Sonnet
- 叙事提取（高频、低成本）：Claude Haiku / GPT-4o-mini
- 情绪打分（结构化输出）：小模型或本地模型
8. 前端与可视化
决定：前期 Streamlit，后期可升级 FastAPI + React。
Phase 1-5: Streamlit Dashboard
- 快速搭建，Python 原生
- 适合内部使用、数据展示
- 无需前端知识
Phase 6+: FastAPI 后端 + React/TailwindCSS/Vite 前端（如需要）
- 更丰富的交互
- 可打包为 Electron 桌面应用原则：前端不是系统核心，不值得前期投入。Streamlit 能覆盖 80% 的需求。
9. 模块运行形态
系统设计为契约驱动的异构架构，每个模块可独立部署：
模块 推荐形态 可迁移形态
──────────────────────────────────────────────────────────
数据采集 本地 Cron + APScheduler → Lambda
叙事发现 本地 Worker → Lambda (事件触发)
指标计算 本地 Cron → Cloud Worker
Persona 分析 本地 Worker → Lambda
合成分析 本地 Worker → Lambda
记忆系统 embedded-postgres → 云 RDS
情绪采集 本地 Cron → Lambda
前端 Dashboard Streamlit → FastAPI + React模块间通信：
- 事件驱动（实时）：进程内事件总线 → 可升级为 Redis Pub/Sub
- 请求驱动（按需）：Python 函数调用 → 可升级为 FastAPI HTTP API
10. 外部服务集成
| 服务 | 接入方式 | 说明 |
|---|---|---|
| OpenBB | Python SDK | 统一数据层 |
| IBKR | ib_insync / REST API | 实时补丁 |
| Longbridge | Longbridge SDK | 中国市场 |
| Binance | ccxt / REST API | 加密永续合约 |
| FRED | OpenBB 覆盖 | 宏观指标 |
已讨论决定
- [x] 语言：Python 3.11+
- [x] 框架：FastAPI
- [x] 数据库：embedded-postgres → PostgreSQL
- [x] ORM：SQLAlchemy 2.0+
- [x] 向量检索：pgvector
- [x] 缓存/队列：diskcache → Redis
- [x] 任务调度：APScheduler
- [x] LLM：LiteLLM
- [x] 前端：Streamlit → FastAPI + React
已确认但暂不定细节
- [x] LLM：通过 LiteLLM 支持多模型 + 多 Provider，具体选型根据任务类型和成本动态调整，不锁定任何单一供应商
- [x] 云部署：技术栈已支持云端实现（契约驱动 + 异构架构），具体云方案待实际需求时确定
- [x] 监控与告警：根据实际运行需求确定选型，前期可用 Python logging + 简单通知