本文迁移自 mindcarver/91ai · 原始位置 docs/agent/ai-app-tutorials/ai-basics/ai-app-dev-landscape.md · 由 @阿新聊ai 整理。

AI 应用开发全景地图

理解 AI 应用开发，第一步不是急着写 Prompt，也不是先选框架，而是先建立一张足够完整的认知地图。只有先看清系统由哪些部分组成、不同架构各自解决什么问题，后面的建模、调用、编排、检索、评估和交付才不会变成零散拼凑。

本文回答四个核心问题：AI 应用开发和”使用 AI”有什么本质区别？一个完整的 AI 应用系统通常包含哪些模块？Chatbot、RAG、Workflow、Agent、Multi-Agent 分别处在什么位置？为什么企业级 AI 方案不能只停留在 Prompt 层？

核心概念

一、AI、机器学习、深度学习、大模型、Agent 的层级关系

理解这五个概念的最简单方式是把它们想象成一套俄罗斯套娃，每一层都包含在前一层之内，但每一层都比前一层更加具体。

人工智能（AI）是最外层的套娃，也是最宽泛的概念。它指的是让机器表现出智能行为的任何技术。早在 1950 年代，计算机科学家就在研究怎么让机器下棋、证明数学定理。那时候的 AI 和今天的大模型没有任何关系，但它们都属于 AI 这个大类。

机器学习（ML）是 AI 的一个子集。它的核心思想是：不让人类手写所有规则，而是让机器从数据中自动学习规律。举个例子，如果你想做一个垃圾邮件过滤器，传统做法是人工编写规则——如果邮件包含"中奖"就标记为垃圾邮件，如果包含"免费领取"也标记。但规则永远写不完，垃圾邮件发送者也在不断进化。机器学习的做法不同，你给模型看一万封垃圾邮件和一万封正常邮件，让它自己发现区分两者的模式。

深度学习（DL）是机器学习的一个子集，它使用多层神经网络来学习数据中的复杂模式。深度学习在 2012 年左右开始爆发，主要原因是两个：算力（GPU）变得足够便宜，数据量变得足够大。图像识别、语音识别这些任务，深度学习的效果远远超越了传统机器学习方法。

大语言模型（LLM）是深度学习的一个特定应用方向。它用海量文本数据训练超大规模的神经网络，让模型学会理解和生成人类语言。GPT 系列、Claude、Gemini、LLaMA 都是大语言模型。它们的共同特点是：参数量巨大（几十亿到几千亿），训练数据海量（互联网上的大量文本），能力通用（一个模型能做翻译、写作、编程、推理等多种任务）。

Agent（智能体）是在大模型基础上构建的应用形态。如果说大模型是一个超级大脑，那 Agent 就是给这个大脑装上了手和脚——它能感知环境、制定计划、使用工具、执行动作、根据反馈调整策略。Agent 不只是回答问题，它能完成任务。

用一个比喻来总结：AI 是整个宇宙，机器学习是太阳系，深度学习是地球，大模型是地球上的人类文明，Agent 是一个能干活的工人。每一层都是前一层的特殊化。

为什么要搞清这个层级关系？因为在实际工作中，你遇到的很多问题需要回到正确的层级去找答案。比如客户说"我要一个 AI 系统"，你脑子里应该马上反应过来：他要的是什么层级的 AI？是一个简单的基于规则的自动化流程？还是一个需要机器学习的预测系统？还是一个基于大语言模型的文本处理应用？还是一个能自主执行任务的 Agent？不同层级的方案，技术栈、成本、周期完全不同。

二、AI 应用开发的真实含义

很多人理解的"AI 应用开发"就是在 ChatGPT 网页上输入一段文字，然后复制结果。这不叫 AI 应用开发，这叫使用 AI。

AI 应用开发是把大模型的能力封装到一个系统里，让这个系统能够稳定地、可重复地、规模化地解决特定的业务问题。

打个比方。你会用 Excel 的求和公式，这不叫开发财务系统。真正的财务系统是：把求和公式嵌到一套完整的工作流里，配合数据校验、权限控制、报表生成、异常提醒，让非技术人员也能准确高效地完成财务工作。

AI 应用开发也是同样的道理。你需要把大模型的能力嵌到一套工程系统里。这个系统至少要处理以下问题：

输入管理——用户怎么把需求告诉系统？是文字输入、文件上传、还是数据库对接？输入的内容需要做什么预处理？要不要做格式校验、敏感信息过滤、长度限制？

模型调用——什么时候调用模型？调哪个模型？传什么参数？要不要多轮对话？流式输出还是一次性返回？调用失败了怎么办？超时了怎么处理？

结果处理——模型返回的结果怎么解析？怎么保证格式正确？怎么校验内容的准确性？结果要存到哪里？要不要做后处理？

业务流程——一个任务可能需要多次模型调用，中间的流程怎么编排？每一步的输出怎么传给下一步？出错后怎么回滚？用户中途怎么介入？

评估反馈——系统输出好不好？用什么标准衡量？怎么自动评估？怎么收集用户反馈？怎么基于反馈持续优化？

安全控制——用户输入了恶意内容怎么办？模型输出了不当内容怎么办？数据隐私怎么保护？调用权限怎么管理？

这些问题加在一起，构成了 AI 应用开发的完整含义。它的本质是系统工程，不是写 Prompt。

三、Chatbot / RAG / Workflow / Agent / Multi-Agent 区别

这五个概念是 AI 应用开发中最核心的架构模式，理解它们的区别是入门的第一步。

Chatbot（聊天机器人）是最基础的 AI 应用形态。用户发消息，模型回复消息，就这么简单。ChatGPT 网页版就是一个 Chatbot。它的特点是单轮或简单的多轮对话，没有外部知识，没有工具调用，完全依赖模型自身的知识。适合做通用问答、闲聊、简单咨询。

RAG（检索增强生成）在 Chatbot 基础上加了一个知识库。模型不再只依赖自身训练时的知识，而是先从你的文档库里检索相关内容，再基于这些内容来生成回答。RAG 解决的核心问题是：大模型不知道你公司的内部信息。比如你问"我们公司的年假政策是什么"，模型本身不知道答案，但如果它能从公司员工手册里找到相关内容，就能准确回答。

Workflow（工作流）是一种固定流程的自动化方式。你预先定义好一系列步骤，每个步骤可能调用模型，也可能执行其他操作（查询数据库、调用 API、发送邮件等），步骤之间有明确的输入输出关系。Workflow 的特点是流程是预先设计好的，不会根据中间结果动态调整。就像工厂流水线，产品按固定路线经过每个工位。

Agent（智能体）是一种更灵活的架构。你给它一个目标，它自己决定要做什么、调用什么工具、按什么顺序执行。Agent 有规划能力、工具使用能力、反思能力。它像是一个能自主思考的员工，你告诉他目标，他自己想办法完成。

Multi-Agent（多智能体）是多个 Agent 协作完成复杂任务。每个 Agent 有自己的专业领域和职责，它们通过某种机制协调、通信、整合结果。Multi-Agent 适合特别复杂的任务，单个 Agent 难以胜任的场景。

为了更直观地理解它们的区别，可以这样想：Chatbot 是一个只能说话的客服，RAG 是一个带资料库的客服，Workflow 是一个按流程手册办事的专员，Agent 是一个能灵活应变的项目经理，Multi-Agent 是一个专业团队。

在实际项目中，这些架构不是互斥的，而是可以组合使用的。一个 RAG 系统内部可能包含 Workflow 来编排检索流程。一个 Agent 系统内部可能使用 RAG 来获取知识。一个 Multi-Agent 系统中，每个 Agent 可能都是一个包含 RAG 能力的智能体。

选择哪种架构取决于三个因素：任务的复杂度、流程的确定性、对可控性的要求。任务简单就用 Chatbot，需要外部知识就用 RAG，流程固定就用 Workflow，需要灵活决策就用 Agent，任务特别复杂就用 Multi-Agent。

四、AI 应用系统九大模块

一个完整的 AI 应用系统可以拆解为九个模块。这九个模块不是每个 AI 应用都必须全部实现，但你需要知道它们的存在，因为随着应用复杂度的增加，你会逐一遇到它们。

输入层：用户与系统交互的入口。它负责接收用户的各种输入——文字消息、文件上传、语音输入、图片输入等。输入层不只是简单地传递数据，它还需要做预处理：格式校验（用户上传的是不是支持的文件类型？）、长度限制（输入文本太长怎么截断？）、敏感信息过滤（输入里有没有密码、身份证号之类的隐私数据？）、意图识别（用户想做什么？是提问、下指令、还是闲聊？）。输入层是系统的门面，它的设计直接决定了用户体验。

模型层：系统的核心计算引擎。它负责与大语言模型交互——选择合适的模型、构造请求参数、发送请求、处理响应。模型层需要考虑很多工程问题：多个模型之间怎么切换？用 GPT-4 还是 Claude？什么时候用便宜的小模型，什么时候用贵的大模型？怎么处理模型的速率限制？怎么应对模型服务不可用的情况？怎么统计 Token 用量和成本？一个好的模型层应该把这些复杂性全部封装起来，让上层业务代码不需要关心底层细节。

知识层：系统获取外部知识的通道。大模型的知识来自训练数据，有截止日期，也不知道企业内部信息。知识层就是弥补这个缺陷的。它通常包含文档解析（把 PDF、Word、Excel 转成可处理文本）、文本切块（把长文档切成小段）、向量化（把文本变成数学向量）、向量存储和检索（根据用户问题找到最相关的文本片段）。知识层是 RAG 架构的核心，也是企业级 AI 应用的必备模块。

工具层：系统执行动作的能力。大模型只能生成文字，不能发邮件、查数据库、调用 API。工具层就是给系统装上"手脚"。一个工具通常包含：工具定义（这个工具能做什么，需要什么参数）、工具选择（根据当前任务决定用哪个工具）、工具执行（实际调用工具并获取结果）、结果处理（把工具返回的结果转成模型能理解的格式）。常见的工具包括：网络搜索、数据库查询、文件读写、邮件发送、API 调用等。

流程层：系统的任务编排引擎。一个复杂任务通常需要多个步骤，流程层负责决定步骤的执行顺序、条件分支、循环逻辑、错误处理。流程层有两种风格：固定流程（Workflow）和动态流程（Agent）。固定流程是预先设计好的，每一步做什么都确定了；动态流程由 Agent 根据实际情况实时决策。实际项目中往往是两种风格的混合——大流程是固定的，某些节点由 Agent 灵活处理。

记忆层：系统的状态管理机制。它负责存储和管理对话历史、用户偏好、任务进度等上下文信息。记忆层的设计直接影响系统的连贯性和个性化能力。记忆分为短期记忆（当前对话的上下文）和长期记忆（跨对话的用户信息、历史交互记录）。短期记忆通常用对话历史列表实现，长期记忆通常用数据库或向量存储实现。记忆层还需要考虑上下文长度限制——当对话历史太长超过模型能处理的范围时，需要做截断或压缩。

评估层：系统的质量保证机制。它负责评估系统输出的质量，包括：准确性（输出的内容是否正确？）、完整性（是否遗漏了重要信息？）、格式合规（输出格式是否符合要求？）、安全性（有没有输出不当内容？）。评估可以自动化（用另一个模型来评估输出质量），也可以人工审核（人在循环中检查关键输出）。评估层是持续优化系统的基础——没有评估，你根本不知道系统好不好，更不知道往哪个方向优化。

安全层：系统的防护机制。它负责应对两类威胁：外部攻击和内部风险。外部攻击包括 Prompt 注入（用户精心构造输入来绕过系统限制）、数据投毒（在知识库中植入误导信息）。内部风险包括模型幻觉（模型编造虚假信息）、数据泄露（模型输出了不应该公开的信息）、工具越权（Agent 调用了不应该调用的工具）。安全层需要在输入端做过滤、在输出端做审查、在工具调用时做权限检查。

交付层：系统的用户界面和部署架构。它决定了用户怎么使用这个系统——是一个网页应用、一个微信机器人、一个 API 接口、还是一个嵌入到现有系统中的功能模块？交付层还需要考虑：用户认证和权限管理、多租户隔离（不同客户的数据互不可见）、计费和用量统计、监控和告警、高可用和容灾。

这九个模块不是独立工作的，它们之间有紧密的协作关系。一次典型的用户交互可能是这样的：用户通过输入层提交问题，系统在记忆层找到相关上下文，通过知识层检索相关文档，在流程层编排处理步骤，由模型层调用大模型生成回答，经过评估层检查质量，通过安全层过滤风险内容，最终由交付层把结果呈现给用户。如果任务需要执行动作，还会调用工具层的工具。

五、为什么 Prompt 不是 AI 应用的全部

这是初学者最容易犯的错误。很多人以为做一个 AI 应用就是写好一个 Prompt，然后在 ChatGPT 里跑就行。

Prompt 确实重要。它是你与大模型沟通的方式，好的 Prompt 能显著提升输出质量。但 Prompt 只是 AI 应用系统的一个组件，就像菜谱只是开餐厅的一个要素。

为什么 Prompt 不够？

第一，Prompt 不能保证输出稳定。同样的 Prompt，模型可能给出截然不同的回答。在企业应用中，这种不确定性是不可接受的。你需要结构化输出、格式校验、重试机制来保证稳定性。

第二，Prompt 不能获取实时信息。模型的知识停留在训练数据的截止日期。你问它今天的新闻、最新的股价、公司内部的政策，它要么说不知道，要么编一个答案。你需要 RAG、工具调用来获取实时信息。

第三，Prompt 不能执行动作。模型只能生成文字。你要让它发邮件、改数据库、调接口，光靠 Prompt 做不到。你需要工具层、流程层来实现真正的自动化。

第四，Prompt 不能保证安全。用户可以通过精心构造的输入绕过 Prompt 的限制，让模型做不该做的事。你需要安全层来防护。

第五，Prompt 不能规模化。一个 Prompt 也许能在一个人使用时表现良好，但当一千个人同时使用，当输入格式千奇百怪，当并发请求压上来，光靠 Prompt 就撑不住了。你需要完整的工程系统来支撑规模化。

一个极端但形象的比喻：Prompt 就像是对一个新员工说的第一句话。你告诉他"帮我分析一下半导体行业的 AI 机会"，他也许能给出一个还不错的答案。但如果你要建立一个真正高效的团队，你需要工作流程、知识库、工具系统、质量检查、安全规范、培训体系。AI 应用开发就是建立这套完整体系。

六、为什么 AI 应用开发是系统工程

把前面的内容串起来，你应该能看出：AI 应用开发不是某一项技术的应用，而是多种技术的系统整合。

系统工程的本质是处理复杂性。AI 应用的复杂性来自几个方面：

模型的不确定性。传统软件的行为是确定性的——相同的输入永远产生相同的输出。但大模型不是这样。同样的输入可能产生不同的输出，而且你无法完全预测它会输出什么。这种不确定性要求你在系统设计中加入大量的校验、重试、降级机制。

数据的多样性。企业数据不是干净的、标准化的文本。你会遇到 PDF 里的表格、扫描件的图片、Excel 里的数据、Word 里的嵌套格式。每一种数据格式都需要专门的处理逻辑。

用户需求的模糊性。用户往往说不清楚自己要什么。"我想要一个 AI 帮我分析业务"——分析什么业务？分析的维度是什么？输出什么格式的结果？需要多久？需要多准？系统设计者需要把这些模糊需求翻译成明确的技术方案。

成本与效果的平衡。大模型的调用是有成本的。GPT-4 每次调用可能花费几毛钱到几块钱。如果一个任务需要调用十次模型，每天有一千个用户使用，一个月的成本就是几万到几十万。你需要在效果和成本之间找到平衡点——不是所有任务都需要最贵的模型。

安全与可控。AI 系统不像传统软件那样完全可控。模型可能产生幻觉，Agent 可能做出意料之外的行为。你需要在系统中设计足够的控制机制，同时不牺牲太多灵活性。

正因为这些复杂性，AI 应用开发需要系统思维。你不能只关注某一个环节（比如 Prompt），而要从整体架构出发，考虑各个模块如何协作，如何处理异常情况，如何持续优化。

概念关系图

AI 应用开发全景图

+------------------------------------------------------------------+
|                        AI 应用系统                                |
|                                                                  |
|  用户交互                                                         |
|  +-----------+     +-----------+     +-----------+               |
|  | 输入层    | --> | 流程层    | --> | 交付层    |               |
|  | (接收请求)|     | (编排步骤)|     | (返回结果)|               |
|  +-----------+     +-----+-----+     +-----------+               |
|                          |                                       |
|              +-----------+-----------+                           |
|              |                       |                           |
|         +----+----+            +-----+-----+                    |
|         | 模型层  |            | 工具层    |                    |
|         | (调LLM) |            | (执行动作)|                    |
|         +----+----+            +-----+-----+                    |
|              |                       |                           |
|  +-----------+-----------+-----------+-----------+               |
|  |           |           |           |           |               |
|  | 知识层    | 记忆层     | 评估层    | 安全层    |               |
|  | (RAG)    | (上下文)   | (质量)    | (防护)    |               |
|  +----------+-----------+-----------+-----------+               |
|                                                                  |
+------------------------------------------------------------------+

AI 应用架构层级

Chatbot < RAG < Workflow < Agent < Multi-Agent
(简单)                                  (复杂)

+----------+   +----------+   +-----------+   +----------+   +------------+
| Chatbot  |   |   RAG    |   | Workflow  |   |  Agent   |   | Multi-Agent|
|          |   |          |   |           |   |          |   |            |
| 问 -> 答 |   | 问 -> 检 |   | 触发 ->   |   | 目标 ->  |   | 目标 ->    |
|          |   | 索 -> 答 |   | 固定流程  |   | 灵活决策 |   | 团队协作   |
|          |   |          |   | -> 结果   |   | -> 结果  |   | -> 结果    |
+----------+   +----------+   +-----------+   +----------+   +------------+

常见误区与避坑

误区一：认为 AI 应用开发就是写 Prompt

Prompt 只是 AI 应用系统的一个组件。把它等同于整个应用开发，就像把写 SQL 等同于做数据库系统一样荒谬。Prompt 决定了模型输出的上限，但工程系统决定了输出的下限。在企业应用中，下限比上限更重要。

误区二：认为 Agent 万能，什么都想用 Agent

Agent 是强大的架构，但不是所有场景都需要。简单的问答用 Chatbot 就够了，固定流程用 Workflow 更可控。Agent 的灵活性意味着不确定性增加、成本增加、调试难度增加。选择架构应该从简单到复杂，不要一上来就上最复杂的方案。

误区三：把九大模块当成必须全部实现的清单

九大模块是一个参考框架，帮助理解和规划。实际项目中，简单的应用可能只需要输入层、模型层、交付层就够了。随着需求增长，再逐步加入知识层、工具层等其他模块。不要追求一步到位，而是根据实际需要逐步构建。

误区四：混淆"使用 AI"和"开发 AI 应用"

使用 AI 是个人行为——在 ChatGPT 里写 Prompt，得到回答，满意了就行。开发 AI 应用是工程行为——要让系统能稳定地、可重复地、规模化地解决问题。两者的思维模式完全不同。前者关注"能不能得到好结果"，后者关注"系统能不能持续产出合格的结果"。

误区五：忽视评估和安全

做 AI 应用只关注"能跑起来"，完全不考虑输出质量和安全风险是危险的。在企业场景中，一次幻觉（模型编造错误信息）或者一次数据泄露，就可能造成严重后果。评估层和安全层应该从一开始就纳入设计，而不是事后补充。