Back to Index
基础概念 /

AI 应用系统架构

从前端到模型层：AI 应用典型技术栈、各层职责、Orchestration 层详解，以及如何根据场景选架构

16 min read Part of AI Foundation · Ch. 10

AI 应用系统架构

flowchart LR
  A["AI 应用系统架构"]
  A --> B["分类：基础概念"]
  A --> C["关键词：AI"]
  A --> D["关键词：架构"]
  A --> E["关键词：RAG"]
  A --> F["关键词：LangChain"]

一个完整的 AI 应用，从来不是“调个模型 API 就完事”。真正上线的系统，至少要同时处理交互、状态、检索、工具、安全、监控和成本。理解每一层的职责，才能做对技术选型。

这篇文章会讲什么

前面几篇文章分别讲了 Prompt、RAG、Embedding、向量数据库、Tool Calling。每一篇单独看都成立，但一到真实开发，问题马上就会变成：

  • 前端怎么流式展示模型输出？
  • 多轮对话的 session 和状态存在哪里？
  • RAG 是放在后端里直接写，还是抽成单独编排层？
  • Tool Calling 是谁来执行、谁来校验、谁来回填？
  • 简单请求和复杂请求，是否应该走不同模型？
  • 向量库、关系数据库、业务 API、模型 API 之间，边界怎么划？

这说明一件事：

AI 应用不是一个模型问题，而是一个系统问题。

模型当然重要，但在生产环境里，很多真正决定成败的点都不在模型本身，而在模型之外：

  • 是否有合适的编排层
  • 检索层和工具层是否可控
  • 状态是否能被稳定维护
  • 输出是否能被系统消费
  • 整条链路是否可观测、可降级、可回滚

所以这篇文章的目标，不是再讲某一个技术点，而是把这些点拼成一张全景图。读完你应该能理解：

  • 一个典型 AI 应用从外到内都有哪些层
  • 各层分别负责什么、不该负责什么
  • 为什么 AI Orchestration 层是最容易被低估、但最关键的一层
  • RAG、Agent、Routing 在架构上有什么不同
  • 什么时候用现成框架，什么时候该自研
  • 怎样按场景做架构选择，而不是盲目“上最全、最复杂的栈”

延伸阅读：

  • Vercel AI SDK 提供面向全栈 AI 应用的流式生成、结构化输出和工具调用能力。:contentReference[oaicite:0]{index=0}
  • LangChain 官方文档将其定位为构建 LLM 应用和 agents 的框架，并强调模型集成、agent 架构和 retrieval 能力。:contentReference[oaicite:1]{index=1}
  • LlamaIndex 长期聚焦数据连接、检索、索引与 query engine，是偏 RAG / retrieval 方向的常见框架。:contentReference[oaicite:2]{index=2}
  • vLLM 官方文档将其定位为面向 LLM inference 和 serving 的高吞吐推理服务框架，并强调 PagedAttention、continuous batching 和 OpenAI-compatible API server。:contentReference[oaicite:3]{index=3}

先说结论：AI 应用的难点，不是“接上模型”，而是“把模型接进系统”

很多团队第一次做 AI 功能时，默认架构是这样的：

Frontend → Backend → LLM API

这个结构在 Demo 阶段经常够用。
比如：

  • 一个简单问答页
  • 一个翻译工具
  • 一个文案生成器
  • 一个总结按钮

但一旦需求升级，问题就会迅速冒出来：

  • 需要查私有知识库
  • 需要调用业务 API
  • 需要分租户隔离
  • 需要多轮对话记忆
  • 需要流式返回和中间状态
  • 需要输出 JSON 给下游系统
  • 需要成本控制和模型路由
  • 需要对失败请求进行回退和重试

这时你会发现，真正的挑战不是“怎么发一次模型请求”，而是：

怎么把模型变成系统中的一个可控组件。

所以一个成熟的 AI 应用架构，本质上是在解决三件事：

  1. 把用户意图转成模型可执行的输入
  2. 把外部知识、工具和状态组织进模型推理过程
  3. 把模型输出重新纳入业务系统的控制流

这就是为什么 AI 应用一定会长出多层架构，而不是永远停留在“前端调一个 API”。

1. 典型 AI 应用技术栈

先看定义：一个典型 AI 应用通常至少包含五层：前端交互层、后端网关层、AI 编排层、模型服务层，以及数据与工具层。

一张足够实用的总图

可以先把一个典型 AI 应用抽象成下面这五层：

┌──────────────────────────────────────────────┐
│ Frontend（Chat UI / Dashboard / Workspace） │
│ 输入、流式展示、引用展示、工具状态、交互反馈   │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────────────────────────────────┐
│ Backend（API Gateway / App Server）         │
│ 鉴权、限流、会话、日志、路由、权限、租户隔离   │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────────────────────────────────┐
│ AI Orchestration（Workflow / Agent Layer）  │
│ Prompt 组装、RAG、Tool 调度、状态机、回填逻辑 │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────────────────────────────────┐
│ Model Layer（Hosted API / Self-hosted）     │
│ OpenAI / Anthropic / Gemini / vLLM / TGI    │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────────────────────────────────┐
│ Data & Tools Layer                          │
│ Vector DB、业务 DB、对象存储、外部 API、工具   │
└──────────────────────────────────────────────┘

这个图不是唯一标准，但足够说明一个核心事实：

模型通常只是整套系统中的一层，而不是整套系统本身。

为什么要分层

分层最大的价值不是“看起来整齐”，而是降低耦合。

如果你把：

  • Prompt 逻辑
  • RAG 检索
  • Tool Calling
  • 用户鉴权
  • 业务状态
  • 模型调用
  • 日志监控

全部写进一个后端 handler 里，很快就会出现经典问题：

  • 逻辑越来越像“上帝函数”
  • 很难定位问题出在哪
  • 很难替换模型或向量库
  • 很难做 A/B 测试和灰度发布
  • 很难复用已有能力到新场景

所以，AI 应用架构分层的真正目标是：

让每一层只对某一类复杂性负责。

2. 各层职责详解：每层做什么，不做什么

先看定义：真正稳定的 AI 系统，不是每层都很强，而是每层边界清楚。前端负责体验，后端负责管控，编排层负责智能流程，模型层负责推理，数据与工具层负责事实与动作。

2.1 Frontend：负责交互体验，不负责“智能逻辑”

前端通常是用户直接接触的那一层。
它的职责很明确：

  • 收集输入
  • 展示输出
  • 展示中间状态
  • 展示引用来源和工具调用过程
  • 让用户对结果进行反馈或继续追问

Vercel AI SDK 的官方定位之一，就是帮助你在前端或全栈应用中做 streamText、streamObject、结构化输出和工具调用集成。:contentReference[oaicite:4]{index=4}

这一层常见的能力

能力典型表现
聊天 UI类似 ChatGPT 的多轮对话界面
流式输出token 边生成边展示
中间状态“正在检索知识库”“正在调用天气工具”
结果引用展示回答来源片段
多模态输入文件上传、图片上传、语音输入
用户反馈👍 / 👎、重试、继续追问

前端最容易犯的错

很多团队会把太多 AI 逻辑塞进前端，比如：

  • 直接拼很复杂的 prompt
  • 在浏览器里维护大量业务状态
  • 让前端直接决定工具调用流程

这样做短期看省事，长期通常会失控。
更稳妥的原则是：

前端负责呈现和交互，后端或编排层负责智能决策。

2.2 Backend：负责网关、管控和系统边界

后端不是“写 AI 逻辑的地方”，而更像整个系统的控制面。

它最核心的职责通常包括：

  • 用户鉴权
  • API Key 管理
  • 租户隔离
  • 会话管理
  • 请求日志和审计
  • 限流和预算控制
  • 路由到不同编排流或模型服务

为什么这一层不能省

因为模型层本身通常不懂：

  • 谁是当前用户
  • 这个用户有没有权限查某数据
  • 这个租户配额还有多少
  • 哪些操作需要人工确认
  • 哪些请求应该走便宜模型，哪些必须走强模型

这些边界控制都属于应用后端，而不属于语言模型。

一个很重要的工程原则

Backend 负责“系统安全和资源控制”，而不是“替模型思考”。

这意味着，后端不应该自己去写大量 if-else 模拟 AI 推理；
但它必须负责把风险、权限和成本都框起来。

2.3 AI Orchestration：真正把“调模型”变成“完成任务”的地方

这是整套架构里最关键、也最容易被低估的一层。

如果没有这一层，你的系统通常只能做到：

  • 单轮问答
  • 简单改写
  • 固定提示词生成

但一旦进入真实业务，你几乎一定会需要：

  • Prompt 组装
  • 多轮消息管理
  • RAG 检索
  • Tool Calling 循环
  • 状态机推进
  • 多模型路由
  • 错误重试和降级策略

这些都属于 AI Orchestration，也就是 AI 编排层。

后面会单独展开讲，因为这层几乎决定了你的 AI 应用到底是“一个模型壳子”，还是“一个可工作的智能系统”。

2.4 Model Layer：负责推理，不负责业务真相

模型层的职责很纯粹：

  • 接收输入
  • 做推理
  • 返回 token 或结构化结果

这层可以是：

  • OpenAI / Anthropic / Google 这类托管 API
  • vLLM、TGI、Ollama 等自托管推理服务

LangChain 和 LlamaIndex 之所以能接不同模型，本质上也是因为它们把模型层抽象成了统一接口。LangChain 官方文档明确强调它支持 OpenAI、Anthropic、Google 等模型连接；vLLM 官方文档则强调其 OpenAI-compatible API server。:contentReference[oaicite:5]{index=5}

这一层最容易被误解的点

很多人会把“模型能力”误当成“系统能力”。
但实际上：

  • 模型不等于权限系统
  • 模型不等于知识系统
  • 模型不等于业务流程引擎
  • 模型不等于审计系统
  • 模型不等于数据库

模型只负责推理。
所有业务可靠性，仍然要靠系统设计补上。

2.5 Data & Tools Layer：负责事实、状态和动作

这一层通常包含：

  • 关系型数据库
  • 文档数据库
  • 对象存储
  • 向量数据库
  • 搜索引擎
  • 外部 SaaS API
  • 内部服务和工具

这层的职责非常明确：

1. 提供事实

例如用户数据、订单信息、企业知识、工单状态。

2. 提供长期状态

例如用户偏好、任务进度、对话摘要、Agent 中间结果。

3. 提供真实动作能力

例如发邮件、建日程、调用支付接口。

这意味着，这一层代表的是：

模型之外的真实世界。

3. AI Orchestration 层深挖：为什么它是 AI 应用的“大脑”

先看定义：AI Orchestration 的作用，是把用户请求、模型能力、外部知识、工具调用和业务状态组织成一个可执行流程。没有这一层，复杂 AI 应用很快就会退化成一堆互相缠绕的 prompt 和 handler。

为什么不能直接在后端里“顺手写掉”

很多项目一开始会这样写：

def chat_handler(request):
    # 1. 读历史
    # 2. 查知识库
    # 3. 拼 prompt
    # 4. 调模型
    # 5. 如果工具调用就执行
    # 6. 再调模型
    # 7. 记录日志

一开始看着非常顺。
但功能一多，这个 handler 很快就会承担：

  • 状态推进
  • 消息拼接
  • 检索召回
  • rerank
  • 工具执行
  • 多模型选择
  • 错误重试
  • 回答后处理

最后它就变成一个非常难维护的“上帝函数”。

AI Orchestration 层的意义，就是把这些与“智能流程”有关的逻辑抽出来，形成一个单独层级。

这一层通常负责什么

1. Prompt 组装

把 system prompt、用户输入、few-shot、对话历史、RAG 结果、工具结果组织成最终上下文。

2. RAG 流程

决定什么时候做检索、检索什么、取多少、怎么拼回上下文。

LangChain 官方文档把 retrieval 作为核心能力之一，明确展示了基于 embeddings 和 vector stores 的 searchable knowledge base 与 minimal RAG workflow。:contentReference[oaicite:6]{index=6}

LlamaIndex 也长期围绕 retriever、query engine 和 structured retrieval 构建能力。:contentReference[oaicite:7]{index=7}

3. Tool 调度

解析模型的工具调用意图、执行工具、回填结果、必要时进入多轮循环。

4. 多轮对话管理

决定保留哪些历史、何时做摘要、哪些状态要显式注入。

5. 路由和策略

例如：

  • 简单任务走便宜模型
  • 高风险任务转人工
  • 长文档问答必须经过检索
  • 某些意图先分类再进入专门流程

所以，编排层真正解决的是：

如何把“模型能力”转成“业务行为”。

Orchestration 层为什么是系统分水岭

一个 AI 应用从“玩具”到“系统”，通常不是因为模型更强了，而是因为编排层开始成熟了。

你可以把它理解成：

  • 模型层 = 推理引擎
  • 数据层 = 事实来源
  • 工具层 = 外部动作
  • 编排层 = 决策中枢

没有编排层，其他层都只是孤立能力。
有了编排层，它们才能真正协同起来。

4. 编排框架怎么选：LangChain、LlamaIndex、Vercel AI SDK、自研分别适合什么

先看定义：框架的价值在于帮你快速搭出“流程骨架”，但抽象越强，黑盒也越多。小项目可以先借框架起步，核心链路稳定后再考虑下沉到自研。

LangChain：更像通用编排框架

LangChain 官方把自己定位成构建 LLM 应用和 agents 的框架，并强调快速连接不同模型、使用预构建 agent 架构。:contentReference[oaicite:8]{index=8}

这意味着它更适合：

  • 想快速把模型、工具、检索、状态拼起来
  • 需要丰富生态和组件
  • 希望有较多现成抽象

但也要看到它的代价：

  • 抽象层较厚
  • 调试路径可能较长
  • 随着系统复杂化，团队可能需要自己重新掌控关键环节

LlamaIndex：更偏 retrieval / data-centric

LlamaIndex 长期围绕：

  • 数据接入
  • 文档切分
  • 索引构建
  • retriever
  • query engine
  • structured retrieval

展开，因此在知识库问答、文档助手、RAG 场景里通常更顺手。:contentReference[oaicite:9]{index=9}

如果你的系统核心问题是：

“怎样把企业数据更好地变成模型可检索上下文？”

那么 LlamaIndex 往往比纯 agent 框架更对路。

Vercel AI SDK：更适合前后端一体的流式应用

Vercel AI SDK 的优势不在“复杂工作流编排”，而在于：

  • 与 Web 应用集成顺滑
  • 文本流式输出体验好
  • 结构化输出和工具调用方便
  • 对前端产品开发友好

官方文档中直接展示了 streamText、generateObject、streamObject 等能力。:contentReference[oaicite:10]{index=10}

所以它特别适合：

  • 聊天产品
  • 内容生成产品
  • 前后端一体开发
  • 以交互体验为中心的 AI 界面

自研：不是为了“炫技”，而是为了掌控关键路径

当你的系统开始出现这些特点时，自研的价值会越来越高：

  • 核心链路已经稳定
  • 团队知道自己真正需要什么
  • 框架抽象反而成了束缚
  • 你需要更精细的日志、缓存、路由、回退策略
  • 你不想把可观测性和调试交给黑盒

所以一个很实用的策略是：

验证阶段优先借框架提速，核心流程成熟后逐步把关键链路下沉到自研。

这样比“一开始全自研”或“永远不脱框架”都更稳。

5. 模型服务选型：云 API、自托管、混合架构

先看定义：云 API 的优势是省心和能力强，自托管的优势是控制权和数据边界；真正的选择，不是理念问题，而是规模、成本、隐私和团队能力的平衡。

云 API：最快上手的默认选项

云 API 的优势很直接：

  • 零运维
  • 能力通常最强
  • 升级和模型切换简单
  • 很适合原型和中小流量上线

但代价也很明确：

  • 按 token 或调用计费
  • 成本随流量增长明显
  • 数据出域问题需要评估
  • 供应商依赖明显

所以云 API 很适合：

  • MVP
  • 快速验证
  • 高价值低频请求
  • 团队没有 GPU / 推理运维能力

自托管：把模型层变成你自己的基础设施

vLLM 官方定位自己为 “fast and easy-to-use library for LLM inference and serving”，并强调 PagedAttention、continuous batching、OpenAI-compatible API server。:contentReference[oaicite:11]{index=11}

这类框架的价值在于：

  • 数据不出域
  • 推理吞吐可控
  • 可根据请求量优化单位成本
  • 能部署特定开源模型和 LoRA

但代价也很实在：

  • 需要 GPU 资源
  • 需要模型运维
  • 需要监控和容量规划
  • 开源模型能力未必总能追平最强闭源模型

混合架构：现实里经常最实用

真实系统很少永远只用一种模式。
常见做法包括：

  • 普通请求走自托管便宜模型
  • 高难推理请求走闭源强模型
  • 涉及敏感数据的请求走内网模型
  • 创意写作走外部 API，结构化抽取走内部模型

这就是典型的 multi-model / hybrid 架构。

所以模型层选型的正确问题通常不是：

API 还是自托管，二选一？

而是：

哪类任务适合哪类模型，怎样让整个成本和能力曲线最优？

6. 四种典型架构模式：从简单链到 Agent 系统

先看定义：AI 应用可以按复杂度大致分成四种常见模式：Simple Chain、RAG Pipeline、Agent Loop、Multi-Model Routing。多数真实系统最终会在其中两三种模式之间组合。

模式 1：Simple Chain

User Input → Prompt → Model → Response

这是最简单的形式，适合：

  • 翻译
  • 改写
  • 总结
  • 格式转换
  • 简单 FAQ

它的优点是：

  • 架构简单
  • 延迟低
  • 调试容易

局限也明显：

  • 没有外部知识
  • 没有工具能力
  • 没有复杂状态控制

模式 2：RAG Pipeline

User Input → Retrieve → Context Assembly → Model → Response

这类架构的重点不是模型更复杂，而是：

  • 如何检索
  • 如何选 Top-K
  • 如何组织上下文
  • 是否需要 rerank
  • 是否需要引用来源

LangChain 官方 retrieval 教程和 LlamaIndex 的 retriever / query engine 能力，本质上都在支持这类模式。:contentReference[oaicite:12]{index=12}

适用场景包括：

  • 企业知识库问答
  • 文档助手
  • 内部 SOP / FAQ 系统
  • 合同、政策、手册检索问答

模式 3：Agent Loop

User Input
→ Model decides tool call
→ Tool execution
→ Result appended
→ Model continues
→ ...
→ Final answer / action

这类架构适合：

  • 需要查实时数据
  • 需要操作外部系统
  • 需要多步骤工具组合
  • 任务路径不固定

也就是前一篇讲的 Tool Calling / Agent loop 场景。

它的关键挑战不在“调不调工具”，而在：

  • 循环控制
  • 错误恢复
  • 权限校验
  • 成本管理
  • 何时停止

模式 4：Multi-Model Routing

Input
→ Router / Classifier / Policy
→ Choose Model / Workflow
→ Execute

这类模式的典型目标是：

  • 降低成本
  • 提升速度
  • 按任务选择最合适的模型或流程

例如：

  • 简单分类走小模型
  • 高难逻辑走强模型
  • 检索问答走 RAG 流程
  • 涉及动作执行走 Agent 流程

从系统设计上看，它的关键不是“模型多”，而是：

你开始承认不同任务应该走不同路径。

7. 根据场景选架构：不要从技术栈出发，要从问题形态出发

先看定义：先问你的应用到底要解决什么问题，再决定需要哪些层和模式。不是所有项目都需要 Agent，不是所有系统都要 RAG，也不是所有场景都值得多模型路由。

场景 1：纯文本生成或轻问答

例如：

  • 写邮件
  • 总结会议
  • 改写文案
  • 轻量 FAQ

通常一个 Simple Chain 就够。
重点在 Prompt 和交互体验，不一定要引入复杂检索或工具层。

场景 2：企业知识库 / 文档助手

核心问题通常是：

模型怎么获得企业内部、最新、可引用的知识？

这类场景几乎天然指向 RAG Pipeline。

重点关注的是：

  • 文档清洗
  • chunking
  • embedding
  • 向量检索
  • rerank
  • 上下文组织

场景 3：个人助理 / 工作助手 / 自动化助手

如果系统需要：

  • 查天气
  • 查日程
  • 发消息
  • 建任务
  • 调内部工具

那你通常需要 Agent Loop 或至少 Tool Calling。

这时关键问题变成：

  • 工具怎么暴露
  • 调用如何校验
  • 高风险动作怎么确认
  • 状态和中间结果怎么维护

场景 4：多租户 SaaS 或复杂平台型产品

这类系统通常同时具有：

  • 知识检索
  • 工具调用
  • 多租户隔离
  • 成本控制
  • 不同套餐能力差异
  • 可观测性要求

所以经常会进入混合架构：

  • RAG + Agent
  • Routing + 多模型
  • 强后端控制 + 编排层抽象

这类场景里，架构设计的重要性会明显超过“单模型能力差一点还是强一点”。

8. 一个最好记住的原则：AI 架构的核心不是“层数多”，而是“职责清”

如果你只想记住一句话，那就是：

一个好的 AI 应用架构，不是每层都很复杂，而是每层都知道自己该负责什么。

更具体一点：

  • 前端负责交互体验
  • 后端负责安全与边界
  • 编排层负责智能流程
  • 模型层负责推理
  • 数据与工具层负责事实和动作

一旦这几个职责混在一起，系统就会迅速变脆：

  • 出错时难定位
  • 改动时容易牵一发而动全身
  • 新功能难复用
  • 调优只能靠猜
  • 成本和安全都难控制

所以真正成熟的 AI 架构，不是“用了多少酷技术”，而是：

能否把模型当成系统里的一个组件，而不是整个系统本身。

核心概念速查

概念一句话
Frontend负责输入、流式展示、状态反馈和用户交互
Backend负责鉴权、限流、会话、日志、租户与权限边界
AI Orchestration负责编排 prompt、RAG、工具调用、状态流转和路由策略
Model Layer负责具体推理，可是托管 API，也可以是自托管服务
Data & Tools Layer提供知识、业务事实、长期状态和真实动作能力
RAG Pipeline检索相关知识后再生成回答的固定流程
Agent Loop模型与工具之间不断循环，直到完成任务或结束
Multi-Model Routing按任务或成本策略，把请求分发到不同模型或不同链路
vLLM面向高吞吐推理和 serving 的自托管框架，支持 OpenAI-compatible API server。:contentReference[oaicite:13]{index=13}

下一篇

架构讲清楚了，接下来最好的方式就是把前面这些能力真正串起来：
Prompt、RAG、Tool Calling、多轮状态、模型调用、日志埋点，如何从 0 到 1 搭一个可运行的 AI 助手？