004、AI 应用开发全景图:从模型、Prompt、RAG 到 Agent,前端开发者必须看懂的完整链路
这两年很多前端开发者学 AI 最大的痛苦不是不努力而是越学越碎。你可能已经听过很多词Prompt、RAG、LangChain、Agent、向量数据库、Function Calling、Workflow、知识库问答、多模态……每个词单独看都好像懂一点但一旦真要你做一个 AI 产品你又会立刻卡住这些东西到底是什么关系我到底该先做哪一层为什么我学了这么多概念最后还是只能做一个聊天框 Demo更现实一点说很多人现在的问题根本不是“没接触过 AI”而是知道很多名词却没有系统地图会调模型接口却不会组织完整链路能做局部功能却拼不出一个真正可交付的 AI 应用。所以这篇文章我不准备继续堆新概念而是带你把AI 应用开发的完整全景图真正梳理一遍。你看完后至少要建立一个非常清晰的认知一个 AI 应用到底由哪些层组成每一层分别解决什么问题它们之间是什么关系前端开发者应该从哪里切进去为什么很多人学了很多最后却还是做不出产品为什么很多人学了很多概念最后还是做不出产品这个问题非常典型而且几乎是所有 AI 初学者都会踩的坑。表面上看大家缺的是知识但更深层的问题其实是缺系统结构感。很多人学习 AI 应用开发时路径通常是这样的今天看 Prompt 技巧明天看 RAG 教程后天刷 LangChain 示例再过两天试一个 Agent Demo然后又去看大模型排行榜和各种新框架看起来学了很多实际上却很容易陷入两个问题1. 只知道局部不知道整体你知道 RAG 是检索增强知道 Agent 是任务执行知道 Prompt 会影响输出但你不知道它们在一个真实系统里是怎么接起来的。2. 只会“跑通”不会“落地”你能把某个 demo 跑起来但一旦进入真实业务场景比如企业知识库问答PDF 文档解析会议纪要生成周报自动整理工作流型 AI 助手你马上就会发现不是只有模型调用这一件事而是一整条工程链路。AI 应用最难的地方不是懂某一个概念而是知道这些概念在系统里各自站什么位置。真正决定你能不能做出产品的不是“知识点数量”而是“系统拼装能力”。先给你一张 AI 应用开发全景图如果把一个典型的 AI 应用拆开来看大致可以分成下面 6 层AI Application Stack │ ├─ 1. 模型层Model Layer │ ├─ 通义千问 / Qwen3-Plus │ ├─ embedding 模型 │ └─ 多模态模型 / 语音模型按场景扩展 │ ├─ 2. Prompt 层Prompt Layer │ ├─ system prompt │ ├─ prompt template │ ├─ output format constraint │ └─ few-shot examples │ ├─ 3. 知识层Knowledge Layer │ ├─ 文档清洗 │ ├─ chunk 切块 │ ├─ embedding │ ├─ 向量检索 │ └─ RAG 上下文拼接 │ ├─ 4. 编排层Orchestration Layer │ ├─ LangChain │ ├─ Workflow │ ├─ Agent │ ├─ Tool Calling │ └─ 多步骤任务链路 │ ├─ 5. 前后端应用层App Layer │ ├─ React TypeScript 前端 │ ├─ Python API 服务 │ ├─ 权限 / 状态 / 数据存储 │ └─ 结果展示与业务闭环 │ └─ 6. 部署与运营层Delivery Layer ├─ 日志与监控 ├─ 成本控制 ├─ 响应延迟优化 ├─ 配置管理 └─ 线上迭代与效果评估这张图为什么这样划分解决了什么问题它把“AI 应用开发”从零散概念变成了分层结构你能清楚看到模型不是全部Prompt 也不是全部RAG、Agent、LangChain 并不是彼此并列乱飞的热词而是处在不同职责层里前端和后端并没有被排除在 AI 之外恰恰是承接落地的关键一层部署、日志、成本、监控说明 AI 应用不是 demo而是要上线运行的系统这张图你只要真正吃透后面学很多内容就不会再碎。第一层模型层决定 AI 应用“能做什么”模型层是最底层的能力来源。这里最核心的不是“你一定要自己训练模型”而是你至少要知道你在调用什么模型这个模型擅长什么它的上下文长度、推理能力、结构化输出能力如何在你的业务场景里它是不是合适对大多数前端转 AI 应用工程的人来说默认最常见的是通义千问 Qwen3-Plus通用对话、摘要、问答、结构化输出embedding 模型知识库向量化特定场景模型例如 OCR、语音、图像理解下面是一个最基础的模型调用示例fromopenaiimportOpenAI clientOpenAI(api_keyYOUR_DASHSCOPE_API_KEY,base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1)defask_model(user_input:str):completionclient.chat.completions.create(modelqwen-plus,messages[{role:system,content:你是一名企业办公助手。},{role:user,content:user_input}],temperature0.3)returncompletion.choices[0].message.content这段代码为什么这样写解决了什么问题使用阿里云百炼兼容接口符合统一的模型接入方式system用来固定角色减少回答漂移temperature0.3更适合企业问答、总结、文档处理这类稳定性优先场景它说明模型层首先解决的是“让 AI 具备基础生成能力”但你也要记住模型层只负责“会回答”不负责“回答是否贴合你的业务知识和流程”。第二层Prompt 层决定输出“怎么更可控”很多人一学 AI 就先学 Prompt这没有错但问题在于很容易把 Prompt 学成万能钥匙。实际上Prompt 层的职责更准确地说是定义角色明确任务目标约束输出格式提高回答稳定性给模型提供必要示例比如做会议纪要、周报生成、制度问答时你通常不会直接把用户输入原封不动地扔给模型而是要先做一层 Prompt 组织。{task:meeting_summary,systemPrompt:你是一名企业会议助手请严格输出 JSON字段包括 title、summary、todos、risks。,temperature:0.3,outputSchema:{title:string,summary:string,todos:[string],risks:[string]}}这段配置为什么这样写解决了什么问题Prompt 被模板化配置而不是散落在业务代码里输出结构被提前定义方便前端和下游系统消费task概念能让不同业务场景共享统一调用方式它说明 Prompt 层真正的价值不是“写得花”而是“让输出更可控、更稳定、更工程化”Prompt 的作用不是代替系统设计而是为系统设计服务。第三层知识层解决“模型不知道你公司内部知识”这个问题如果你只是做通用聊天模型层和 Prompt 层可能已经够用。但一旦你进入真实企业场景很快就会遇到一个问题模型并不知道你的公司制度历史项目文档内部知识库产品手册客服知识会议记录这时候单靠 Prompt 往往不够你就需要知识层也就是大家常说的 RAG 基础链路。知识层通常包括文档采集文本清洗chunk 切块embedding 向量化向量检索检索结果和用户问题一起拼接进 Prompt它本质上解决的是让模型回答时不只是依赖参数记忆而是基于你的业务知识来回答。比如你做一个 AI 文档助手用户提问“我们公司报销流程里差旅发票最晚什么时候提交”如果没有知识层模型可能会按泛化经验回答而有了知识层它就能先从企业制度文档中检索相关段落再生成更贴近真实规则的回答。第四层编排层决定复杂任务能不能真正跑起来这是很多人第二个最容易混淆的部分LangChain、Workflow、Agent 到底是什么关系你可以这样理解LangChain帮助你组织模型调用、Prompt、检索、工具等组件Workflow强调多步骤任务流程和节点编排Agent强调让模型根据目标自主选择工具和下一步动作如果你的任务只是“输入一句话输出一句话”编排层可能不明显。但真实业务里往往是这样的用户上传一份 PDF系统先解析文本检索公司制度和历史案例让模型提炼摘要和风险点输出结构化数据前端展示结果并支持人工确认最终写入数据库或推给后续流程这种情况下你需要的就不只是一次 API 调用而是整条任务编排。下面看一段简化伪代码classDocumentAssistantWorkflow:defrun(self,file_path:str,question:str):contentself.parser.extract_text(file_path)chunksself.chunker.split(content)referencesself.retriever.search(question,chunks)promptself.prompt_builder.build(question,references)answerself.llm.generate(prompt)structuredself.output_parser.to_json(answer)self.repository.save(structured)returnstructured这段代码为什么这样写解决了什么问题extract_text负责先把 PDF 等文件变成可处理文本split说明知识层的数据往往需要切块不能整篇硬塞给模型search体现 RAG 检索逻辑而不是直接问模型prompt_builder把问题和检索结果组织成统一输入to_json说明结果需要结构化而不是只做一次性展示save表明这已经是业务链路而不是孤立 demo这就是编排层的核心意义把多个 AI 能力模块串成一条可执行、可维护、可复用的任务链。第五层前后端应用层决定用户到底能不能真正用起来很多人学 AI 时最大的问题是默认把前端当成“最外面那层壳”。其实恰恰相反。对于绝大多数 AI 产品来说前后端应用层才是用户真正感知价值的地方。因为用户最终接触到的是输入入口怎么设计历史记录怎么查看任务状态怎么反馈结果怎么展示是否支持二次编辑、确认、复制、导出AI 输出如何接入现有业务流程比如一个 AI 办公提效助手真实结构可能是这样的frontend/ ├─ pages/ │ ├─ meeting-summary/ │ ├─ knowledge-search/ │ └─ weekly-report/ ├─ components/ │ ├─ ResultCard.tsx │ ├─ SourceList.tsx │ └─ TaskStatus.tsx └─ services/ └─ ai.ts backend/ ├─ api/ ├─ llm/ ├─ rag/ ├─ workflows/ └─ repositories/这段结构为什么这样写解决了什么问题pages/表示 AI 能力通常会拆成不同任务页面而不只是一个聊天页ResultCard、SourceList、TaskStatus说明 AI 结果展示、引用来源和任务状态都是关键界面能力后端按llm、rag、workflows分层避免职责混乱它反映出 AI 应用不是“模型 页面”这么简单而是前后端协同的完整系统真正有价值的 AI 产品不是让模型说了什么而是让用户能基于结果完成什么。第六层部署与运营层决定它是不是能在线上活下来很多教程到这里就停了但这恰恰是从 demo 到产品最关键的一步。因为 AI 应用一旦上线很快就会出现这些现实问题调一次模型太贵怎么办用户一多就很慢怎么办输出偶尔不稳定怎么办Prompt 改了以后怎么回滚线上效果怎么监控哪类问题最容易失败所以部署与运营层通常要关注日志追踪调用成本控制缓存与限流配置管理响应时长监控Prompt / 模型版本管理线上效果评估这一层告诉你AI 应用开发的终点不是“能跑”而是“能持续稳定地跑”。用一个真实场景把 6 层串起来AI 文档助手现在我们用一个最典型的业务场景把前面的 6 层全部串起来。假设你要做一个AI 文档助手用户可以上传制度文件、项目方案或会议记录然后提问并拿到结构化答案。这个产品的目标是什么不是单纯聊天而是让用户快速找到文档重点基于上传文档进行问答给出引用来源输出摘要、待办、风险点支持结果复制、确认、导出它的 6 层分别是什么模型层使用 Qwen3-Plus 负责生成和结构化输出Prompt 层约束模型按摘要、重点、风险点格式回答知识层把上传文档切块、向量化、检索相关片段编排层组织“上传 → 解析 → 检索 → 生成 → 存储”链路前后端应用层提供上传入口、提问面板、引用来源、结果卡片部署与运营层记录调用日志、统计响应时延、控制模型成本这样一看你就会发现一个真实 AI 产品根本不可能只靠“会写 Prompt”就完成。前端开发者最应该先看懂哪几层如果你是 React 前端开发者不一定要一上来把 6 层同时吃透。更现实的顺序通常是第一阶段先理解模型层 Prompt 层你至少要知道模型怎么调用、Prompt 为什么影响输出质量。第二阶段重点补前后端应用层因为这是你最容易结合已有经验快速做出成果的一层。第三阶段补知识层和编排层当你开始做知识库问答、文档助手、工作流型产品时这两层会变成核心能力。第四阶段补部署与运营层意识当你开始考虑成本、稳定性、延迟、日志和迭代这说明你已经从 demo 思维进入产品思维。这也是为什么我一直说前端转 AI 应用工程不是先把自己逼成算法工程师而是先把自己升级成会组织 AI 系统的人。常见误区很多人为什么会把学习顺序搞反误区 1一上来就追最热概念今天学 Agent明天学 MCP后天又换另一个框架最后没有一条完整主线。误区 2把聊天框 Demo 当成 AI 产品聊天框只是最简单的交互形式不等于系统能力。误区 3忽略知识层和编排层很多人会调接口但一涉及企业文档、业务流程、多步骤任务就立刻断层。误区 4完全不关心前后端协同AI 应用不是单机脚本它最终要进入业务系统前后端设计非常关键。误区 5不考虑部署和线上问题如果只会本地跑 demo不考虑成本、时延、监控和配置那很难进入真正的工程落地阶段。本篇小结如果你想真正看懂 AI 应用开发最重要的不是记住更多新名词而是建立一张清晰的系统地图。这张地图至少应该包括 6 层模型层Prompt 层知识层编排层前后端应用层部署与运营层只要你把这 6 层的职责和关系看明白后面再去学 RAG、LangChain、Agent、Workflow就不会再觉得它们是一堆彼此割裂的热词。AI 应用开发的本质不是把若干热门概念堆在一起而是把不同层的能力组织成一套能交付的系统。前端开发者真正要补的不只是模型知识而是“用工程方式理解 AI 全链路”的能力。当你能从系统层看 AI而不是从单个技巧看 AI你才真正进入了 AI 应用工程的门槛。下一篇预告既然我们已经把 AI 应用开发的全景图梳理出来了下一步最关键的问题就是如果我是前端开发者应该按什么顺序学先学 Prompt还是先学 RAGLangChain、Agent、Transformer 分别该什么时候补所以下一篇我会继续写《前端转 AI 应用工程师完整学习路线怎么走从 Prompt 到 RAG、LangChain、Agent 一次规划清楚》下一篇我会把学习阶段、技能拆分、项目安排、踩坑顺序和时间投入建议全部按可执行路线拆开。