AI 应用基础架构
这个主题从单个功能进入应用架构。真实 AI 产品需要把模型、上下文、工具、存储、日志、成本和权限组织成系统。
当 AI 功能从 Demo 进入产品,最大的问题通常不再是“能不能调通模型”,而是“能不能稳定、可控、可替换、可观测地运行”。这个阶段会把模型调用放回完整应用系统里,理解 AI Gateway、模型路由、会话数据模型和运行生命周期如何一起工作。
学习目标
完成这个主题后,你应该能够:
- 描述一个真实 AI 应用从前端到模型 Provider 的完整链路。
- 设计 AI Gateway,用统一接口管理多模型、多 Provider、重试、超时和 fallback。
- 为 conversation、message、run、step、tool call 建立清晰的数据模型。
- 根据任务、成本、延迟和质量做模型路由。
- 记录 token、cost、latency、first token time、error rate 等核心指标。
关键概念
AI Gateway 是应用和模型 Provider 之间的工程边界。它不只是转发请求,还负责鉴权、模型抽象、密钥管理、限流、fallback、日志和成本统计。
Model Routing 是根据任务选择模型的策略。高风险任务可能选择更强模型,实时补全可能选择低延迟模型,批处理可能选择低成本模型。
Session 数据模型 决定你能不能追踪一次 AI 交互。用户看到的是一条 assistant message,系统内部可能包含一次 run、多次 step、若干 tool call 和最终输出。
AI Run 生命周期 描述一次生成任务从创建到结束的状态变化。它是前端状态、后端任务和可观测日志之间的共同语言。
AI 应用架构
这张图把 AI 应用拆成可替换的层:前端不直接理解模型差异,业务后端不直接散落 Provider 细节,Gateway 负责把 Prompt、Context、Tool、Routing 和日志组织起来。
核心主题
- AI 应用基本架构:frontend、backend、model provider、prompt layer、context layer、tool layer、storage layer、observability layer。
- AI Gateway:provider abstraction、model abstraction、API key management、retry、timeout、fallback、rate limit。
- Model Provider:OpenAI、Anthropic、Gemini、DeepSeek、Qwen、local model。
- Model Routing:按任务、成本、速度、质量和 fallback 路由。
- Session 设计:user、conversation、message、run、step、tool call。
- AI Run 生命周期:created、queued、running、requires_action、completed、failed、cancelled。
- AI 可观测性:latency、first token time、token usage、error rate、model distribution、user satisfaction。
阶段实践拆解
- 设计数据表:从 user、conversation、message 开始,再增加 run、step、tool call。
- 抽象 Provider 接口:统一输入 messages、tools、stream,统一输出 delta、usage、finish reason。
- 实现 AI Gateway:集中处理 API key、timeout、retry、fallback 和错误映射。
- 增加模型路由:根据任务类型或配置选择不同模型,并保留路由日志。
- 接入可观测性:记录每次请求的 token、cost、latency、first token time、model 和错误原因。
- 回到前端验证:让 Chat UI 能显示运行中、工具调用中、失败和重试状态。
阶段实践
- 设计一套 AI Chat 数据表。
- 实现一个 AI Gateway。
- 记录每次请求 token、cost、latency。
计划文章
- AI 应用为什么需要 Gateway 层
- 如何设计 AI Chat 的数据库模型
- AI 应用应该记录哪些日志