第31期 | AI应用架构全景

🎯 今天你将学会

• 理解前端与 LLM 交互的四种主流架构模式
• 知道 AI 应用的技术栈怎么选、怎么搭
• 理解 AI 应用与传统 Web 应用的核心差异
• 画出你的第一个 AI 应用的架构图

📖 核心知识

AI 应用 vs 传统 Web 应用：核心差异

你可能觉得「AI 应用就是普通 Web 应用 + 一个 API 调用」。不是的——AI 应用有根本性的不同：

维度	传统 Web 应用	AI 应用
数据流	请求 → 响应，一次性完成	请求 → 流式响应，数据逐步到达
响应时间	< 200ms（数据库查询）	1-30s（LLM 生成），需要 UX 处理慢响应
结果确定性	相同请求 = 相同响应	相同请求 ≈ 相似响应（LLM 有随机性）
错误类型	网络错误、权限错误	内容错误（幻觉/偏离预期）、格式错误（不是期望的 JSON）
交互模式	点击 → 刷新页面	对话 → 流式打字效果 → 可中断 → 可追问
成本模型	服务器成本固定	API 调用按 token 计费，成本跟使用量相关

这些差异决定了 AI 应用需要全新的架构模式。

四种主流架构模式

模式1：直接调用（Direct API Call）

最简单的模式——前端直接调用 LLM API。

前端 → HTTPS 请求 → LLM API (OpenAI/Claude) → 返回结果 → 前端渲染

适用场景： 简单的文本生成、翻译、摘要

优点： 实现最简单，几行代码就能搞定
缺点： API Key 暴露在前端（安全风险）、CORS 跨域问题、无法做缓存和限流

// 直接调用示例（⚠️ 仅用于学习，生产环境不要这样做）
async function generateSummary(text: string) {
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${API_KEY}`, // ❌ Key 暴露在前端！
    },
    body: JSON.stringify({
      model: 'gpt-4',
      messages: [{ role: 'user', content: `总结这段文字：${text}` }],
    }),
  });
  return response.json();
}

⚠️ 安全警告： 直接从前端调用 LLM API 会暴露 API Key。任何用户打开 DevTools 就能看到你的 Key，然后盗用。生产环境必须用模式2或模式3。

---

模式2：后端代理（Backend Proxy）

前端请求你的后端，后端转发到 LLM API。

前端 → HTTPS 请求 → 你的后端 → 转发 → LLM API → 返回 → 后端 → 前端

适用场景： 大多数 AI 应用（聊天、生成、分析）

优点： API Key 安全（存在后端）、可以做限流/缓存/日志、可以加业务逻辑
缺点： 要后端服务，增加了一层延迟

// 后端代理示例（推荐方式）
async function generateSummary(text: string) {
  const response = await fetch('/api/ai/summary', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text }),
  });
  return response.json();
}

// 后端代理实现（Express 示例）
app.post('/api/ai/summary', async (req, res) => {
  const { text } = req.body;
  const result = await openai.chat.completions.create({
    model: 'gpt-4',
    messages: [{ role: 'user', content: `总结这段文字：${text}` }],
  });
  res.json({ summary: result.choices[0].message.content });
});

---

模式3：流式响应（Streaming）

LLM 的生成是逐 token 的——不是一口气吐出完整文本。流式模式让前端实时显示每个 token，就像 ChatGPT 的打字效果。

前端 → HTTPS 请求 → 后端 → SSE/WebSocket → 逐 token 推送 → 前端逐步渲染

适用场景： 聊天界面、长文本生成、代码生成

优点： 用户不需要等 30 秒看到完整响应——几秒内就能看到开头内容
缺点： 实现复杂，需要处理 SSE/WebSocket、连接中断、并发管理

// 前端流式接收（SSE 方式）
async function streamChat(message: string) {
  const response = await fetch('/api/ai/chat', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ message }),
  });

  const reader = response.body!.getReader();
  const decoder = new TextDecoder();
  let buffer = '';

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;

    buffer += decoder.decode(value, { stream: true });
    // 解析 SSE 格式的数据
    const lines = buffer.split('\n');
    buffer = lines.pop() || '';

    for (const line of lines) {
      if (line.startsWith('data: ')) {
        const data = JSON.parse(line.slice(6));
        if (data.content) {
          // 逐步追加到 UI
          setMessages(prev => {
            const last = prev[prev.length - 1];
            if (last.role === 'assistant') {
              return [...prev.slice(0, -1), { ...last, content: last.content + data.content }];
            }
            return [...prev, { role: 'assistant', content: data.content }];
          });
        }
      }
    }
  }
}

// 后端流式转发（Express + SSE）
app.post('/api/ai/chat', async (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const stream = await openai.chat.completions.create({
    model: 'gpt-4',
    messages: [{ role: 'user', content: req.body.message }],
    stream: true,  // ← 开启流式
  });

  for await (const chunk of stream) {
    const content = chunk.choices[0]?.delta?.content || '';
    if (content) {
      res.write(`data: ${JSON.stringify({ content })}\n\n`);
    }
  }

  res.write('data: [DONE]\n\n');
  res.end();
});

---

模式4：RAG + Agent（检索增强生成 + 智能代理）

最复杂的模式——前端不只跟 LLM 对话，还跟知识库（向量搜索）和工具（Agent）交互。

前端 → 请求 → 后端 → 查询知识库(向量搜索) + 调用工具(Agent) + 调用LLM → 组合响应 → 前端渲染

适用场景： AI 知识库、AI 助手（能查数据库/调用API/执行操作）

优点： LLM 有真实数据支撑（减少幻觉）、能执行实际操作（不只是说话）
缺点： 架构最复杂、需要向量数据库、需要 Agent 工具定义

RAG 流程详解：

1. 用户提问：「如何部署 React 应用到 Vercel？」
2. 向量搜索：从知识库中找到与「部署 React Vercel」最相关的文档片段
3. 构建 Prompt：
   System: 你是一个技术助手，以下参考资料可供引用：
   Reference 1: [从知识库检索的部署文档片段]
   Reference 2: [从知识库检索的 Vercel 配置文档片段]
   User: 如何部署 React 应用到 Vercel？
4. LLM 生成：基于真实文档片段回答，而不是凭记忆编造
5. 前端展示：回答 + 引用的文档来源链接

AI 应用技术栈选择

完整技术栈全景：

层级	选项	推荐	原因
前端框架	React / Vue / Svelte	React	生态最丰富，AI UI 组件库最多
流式处理	SSE / WebSocket / fetch stream	SSE	最简单、兼容性好、ChatGPT 也用 SSE
LLM SDK	openai / anthropic / langchain	openai + anthropic	直接用官方 SDK，langchain 太重
向量数据库	Pinecone / Weaviate / Supabase pgvector	Supabase pgvector	免费、SQL 兼容、够用
后端框架	Express / Fastify / Next.js API Routes	Next.js API Routes	前端 + 后端一体，减少运维
状态管理	Zustand / React Query / SWR	Zustand + React Query	Zustand 管 UI 状态，React Query 管 API 状态
UI 组件	shadcn/ui / Ant Design / MUI	shadcn/ui	轻量、可定制、跟 Tailwind 无缝配合
Markdown 渲染	react-markdown / marked / MDX	react-markdown + remark-gfm	轻量、支持 GFM（代码块、表格）
代码高亮	Prism / Shiki / highlight.js	Shiki	VS Code 同款高亮引擎，效果好

核心架构图：

┌─────────────────────────────────────────────────┐
│                    前端                           │
│  ┌───────┐  ┌──────────┐  ┌──────────────┐      │
│  │Chat UI│  │Stream处理 │  │Markdown渲染  │      │
│  └───────┘  └──────────┘  └──────────────┘      │
│  ┌───────┐  ┌──────────┐  ┌──────────────┐      │
│  │Zustand│  │React Query│  │shadcn/ui     │      │
│  └───────┘  └──────────┘  └──────────────┘      │
└─────────────────────────────────────────────────┘
          │ SSE / fetch stream
          ↓
┌─────────────────────────────────────────────────┐
│                    后端                           │
│  ┌────────────┐  ┌──────┐  ┌────────────┐       │
│  │API Routes  │  │限流  │  │缓存/日志    │       │
│  └────────────┘  ┌──────┘  ┌────────────┘       │
│  ┌────────────┐  ┌──────┐                        │
│  │LLM SDK     │  │RAG   │                        │
│  └────────────┘  └──────┘                        │
└─────────────────────────────────────────────────┘
          │ API calls
          ↓
┌─────────────────────────────────────────────────┐
│              LLM / 向量数据库                     │
│  ┌──────┐  ┌──────────┐  ┌──────────────┐      │
│  │OpenAI│  │Anthropic  │  │Supabase      │      │
│  │      │  │           │  │pgvector      │      │
│  └──────┘  └──────────┘  └──────────────┘      │
└─────────────────────────────────────────────────┘

AI 应用的错误处理：比传统应用复杂得多

传统应用的错误是明确的：404、500、权限不足。AI 应用有额外的「内容错误」：

错误类型	表现	处理方式
网络错误	API 请求失败	retry + 错误提示
内容幻觉	LLM 编造不存在的事实	RAG 检索真实数据 + 人工审核
格式错误	LLM 输出不是期望的 JSON 格式	prompt 严格约束格式 + 输出解析 + fallback
内容安全	LLM 生成有害/不当内容	content moderation API + 内容过滤
超限错误	token 超限或 rate limit	降级到更小模型 + 用户提示
中断错误	流式连接中途断开	自动重连 + 已接收内容保留

格式约束 Prompt 示例：

你必须严格按以下 JSON 格式输出，不要有任何额外文字：

{
  "summary": "一句话总结",
  "keyPoints": ["要点1", "要点2", "要点3"],
  "confidence": 0.8
}

如果无法确定某个字段，填 null。不要输出任何 JSON 以外的内容。

常见误区

误区1：AI 应用就是 Web 应用 + API 调用
AI 应用有根本差异：流式响应、不确定性、内容错误、成本模型。不做针对性设计就会出问题。

误区2：前端直接调用 LLM API
API Key 暴露在前端 = 任何人都能盗用。必须用后端代理。

误区3：不用流式响应，等完整结果再显示
LLM 生成可能需要 30 秒。用户等 30 秒看到空屏幕会以为系统挂了。流式响应让用户几秒内看到内容。

🤖 AI协作实战

实战场景：设计你的第一个 AI 应用架构

任务：设计一个「AI 技术文档助手」

功能：用户输入技术问题 → AI 从知识库检索相关文档 → 基于真实文档回答 → 展示回答和引用来源

我给 AI 的 prompt：

设计一个 AI 技术文档助手的完整架构。

功能需求：
- 用户输入技术问题（如「React useEffect 的 cleanup 什么时候执行」）
- AI 从知识库检索相关文档片段
- 基于真实文档回答，附带引用来源
- 流式输出，打字效果
- 支持追问（多轮对话）

请用以下方式输出：
1. 架构图（用文字描述各层和连接）
2. 技术栈选择及原因
3. 数据流描述（从用户输入到最终展示的完整路径）
4. 需要处理的关键问题（错误处理、成本控制、安全）
5. 目录结构建议

AI 输出架构图：

前端层：
  - ChatInterface（对话界面）
  - MessageList（消息列表，含 Markdown 渲染 + 引用标注）
  - StreamingHandler（SSE 流式接收）
  - ChatStore（Zustand：对话历史 + 当前状态）

后端层（Next.js API Routes）：
  - /api/chat（流式转发到 LLM）
  - /api/search（向量搜索知识库）
  - /api/embed（上传文档 → 生成 embedding → 存入向量库）

数据层：
  - Supabase pgvector（向量存储 + 文档元数据）
  - OpenAI embeddings API（生成 embedding）

LLM 层：
  - OpenAI GPT-4（生成回答）
  - OpenAI text-embedding-3-small（生成 embedding）

数据流路径：

用户输入 → ChatInterface → POST /api/chat
  → 后端并行执行：
    1. POST /api/search（向量搜索相关文档）
    2. 构建 RAG prompt（system + 检索到的文档 + 用户问题）
    3. 调用 GPT-4（stream: true）
  → SSE 逐 token 推送 → StreamingHandler 接收
  → ChatStore 更新 → MessageList 渲染

我的审查和调整：

1. ✅ 架构清晰——三层（前端/后端/数据）职责明确
2. ❌ 缺少限流——加上了 rate limit middleware
3. ❌ 缺少缓存——相似问题的回答应该缓存，避免重复调用 LLM
4. ✅ SSE 方式正确——兼容性好，比 WebSocket 简单

学到了什么： AI 能帮你快速画出架构图和选择技术栈，但关键问题（限流、缓存、安全）需要你补充——因为这些是业务决策，不是技术选择。

💻 动手练习

练习1（简单）：画出你的 AI 应用架构图

选一个你想做的 AI 应用（比如 AI 聊天助手、AI 文档搜索），用四种架构模式中的哪种？画出简化的架构图。

练习2（中等）：搭建 AI 应用后端代理

用 Express 或 Next.js API Routes 实现一个简单的 LLM 代理接口：

• 接收前端的 POST 请求
• 转发到 OpenAI API
• 返回结果给前端
• API Key 存在后端环境变量中

练习3（挑战）：实现一个完整的流式聊天接口

在前端 + 后端实现完整的流式聊天：

• 后端：Express SSE 流式转发
• 前端：fetch stream 接收 + 逐步渲染打字效果
• 测试：能在浏览器中看到逐字出现的效果

📌 本期要点

1. 四种架构模式： 直接调用（仅学习用）→ 后端代理（推荐）→ 流式响应（聊天必备）→ RAG+Agent（高级）
2. AI 应用核心差异： 流式响应、不确定性、内容错误、成本模型——必须针对性设计
3. API Key 安全： 绝不暴露在前端——后端代理是生产环境的唯一正确方式
4. 流式响应是必备： LLM 生成可能 30 秒，用户需要几秒内看到内容
5. AI 应用错误处理更复杂： 除了网络错误，还有幻觉、格式错误、内容安全、超限

🔗 下期预告

下一期我们进入 OpenAI API 接入实战——手把手教你调用 API、处理流式响应、做错误处理。你将封装一个可复用的 API 调用层。
如果你没有苹果电脑，需要上传ios到APPStore可以访问以下网站
iPA上传工具 - IPA解析与AppStore提交