第31期 | AI应用架构全景 今天你将学会理解前端与 LLM 交互的四种主流架构模式知道 AI 应用的技术栈怎么选、怎么搭理解 AI 应用与传统 Web 应用的核心差异画出你的第一个 AI 应用的架构图 核心知识AI 应用 vs 传统 Web 应用核心差异你可能觉得「AI 应用就是普通 Web 应用 一个 API 调用」。不是的——AI 应用有根本性的不同维度传统 Web 应用AI 应用数据流请求 → 响应一次性完成请求 → 流式响应数据逐步到达响应时间 200ms数据库查询1-30sLLM 生成需要 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;constresultawaitopenai.chat.completions.create({model:gpt-4,messages:[{role:user,content:总结这段文字${text}}],});res.json({summary:result.choices[0].message.content});});模式3流式响应StreamingLLM 的生成是逐 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 SSEapp.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);conststreamawaitopenai.chat.completions.create({model:gpt-4,messages:[{role:user,content:req.body.message}],stream:true,// ← 开启流式});forawait(constchunkofstream){constcontentchunk.choices[0]?.delta?.content||;if(content){res.write(data:${JSON.stringify({content})}\n\n);}}res.write(data: [DONE]\n\n);res.end();});模式4RAG 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 / SvelteReact生态最丰富AI UI 组件库最多流式处理SSE / WebSocket / fetch streamSSE最简单、兼容性好、ChatGPT 也用 SSELLM SDKopenai / anthropic / langchainopenai anthropic直接用官方 SDKlangchain 太重向量数据库Pinecone / Weaviate / Supabase pgvectorSupabase pgvector免费、SQL 兼容、够用后端框架Express / Fastify / Next.js API RoutesNext.js API Routes前端 后端一体减少运维状态管理Zustand / React Query / SWRZustand React QueryZustand 管 UI 状态React Query 管 API 状态UI 组件shadcn/ui / Ant Design / MUIshadcn/ui轻量、可定制、跟 Tailwind 无缝配合Markdown 渲染react-markdown / marked / MDXreact-markdown remark-gfm轻量、支持 GFM代码块、表格代码高亮Prism / Shiki / highlight.jsShikiVS 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 以外的内容。常见误区误区1AI 应用就是 Web 应用 API 调用AI 应用有根本差异流式响应、不确定性、内容错误、成本模型。不做针对性设计就会出问题。误区2前端直接调用 LLM APIAPI 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 渲染 引用标注 - StreamingHandlerSSE 流式接收 - ChatStoreZustand对话历史 当前状态 后端层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 promptsystem 检索到的文档 用户问题 3. 调用 GPT-4stream: true → SSE 逐 token 推送 → StreamingHandler 接收 → ChatStore 更新 → MessageList 渲染我的审查和调整✅ 架构清晰——三层前端/后端/数据职责明确❌ 缺少限流——加上了 rate limit middleware❌ 缺少缓存——相似问题的回答应该缓存避免重复调用 LLM✅ 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 接收 逐步渲染打字效果测试能在浏览器中看到逐字出现的效果 本期要点四种架构模式直接调用仅学习用→ 后端代理推荐→ 流式响应聊天必备→ RAGAgent高级AI 应用核心差异流式响应、不确定性、内容错误、成本模型——必须针对性设计API Key 安全绝不暴露在前端——后端代理是生产环境的唯一正确方式流式响应是必备LLM 生成可能 30 秒用户需要几秒内看到内容AI 应用错误处理更复杂除了网络错误还有幻觉、格式错误、内容安全、超限 下期预告下一期我们进入 OpenAI API 接入实战——手把手教你调用 API、处理流式响应、做错误处理。你将封装一个可复用的 API 调用层。如果你没有苹果电脑需要上传ios到APPStore可以访问以下网站iPA上传工具 - IPA解析与AppStore提交