夜雨聆风
AI 系统学习笔记 01｜面向初学者、产品经理与工程师
资料校准日期：2026-08-14
最近我在系统整理 AI 应用工程时，遇到的第一个困难不是代码，而是名词。
AI、机器学习、基础模型、LLM、RAG、Tool Calling、Workflow、Agent、LangChain、MCP……它们经常出现在同一张图里，于是很容易被误认为处在同一条技术升级路线：先有 LLM，再有 RAG，然后升级成 Agent。
但这条线是错的。它把技术范式、模型类别、应用能力、编排方式和连接协议混在了一起。
这篇文章不追求一次讲透所有细节。我想先把地图画对：每个概念是什么、位于哪里、解决什么问题，以及它和相邻概念到底是什么关系。
图里最容易被忽略的是“维度错位”。LLM 和多模态模型回答的是“使用什么模型”，RAG 和 Tool Calling 回答的是“如何补充知识与动作”，Workflow 和 Agent 回答的是“谁决定下一步”，MCP 等协议回答的是“系统之间怎样交换信息”。如果问题不同，概念就不应该排在同一条升级链上。
常见误区：把热门名词按发布时间排列，再把后出现的概念理解成前一个概念的替代品。实际上，企业应用经常会同时使用 LLM、RAG、Tool Calling、Workflow 和局部 Agent，它们各自承担不同职责。
一、先别背名词，先建立三张正交地图
理解 AI 应用，至少需要同时看三张地图。
第一张是技术与模型地图，回答“智能能力从哪里来”；第二张是系统分层地图，回答“一个应用由哪些工程层组成”；第三张是生命周期地图，回答“系统如何从数据和开发走向上线与持续优化”。
它们互相关联，但不能压成一棵树。例如，RAG 位于应用能力链路中，评估贯穿生命周期，LangGraph 主要影响编排与运行时。三者不是父子关系。
读一项新技术时，我会连续问三个问题：它改变了哪类智能能力？它位于系统的哪一层？它影响生命周期中的哪个阶段？例如，Embedding 是模型产生的一种表示能力，也会用于 RAG 的离线索引和在线检索；Eval 不是某个独立业务层，而是从开发、发布到监控都要持续执行的质量活动。
1. 技术范式、模型类别与应用能力
人工智能（Artificial Intelligence，AI）是一个目标领域：让机器完成通常需要智能的任务。机器学习（Machine Learning，ML）是实现 AI 的重要方法，深度学习（Deep Learning，DL）又是机器学习中的一类方法。
基础模型、LLM 和多模态模型属于另一个维度。基础模型强调“大规模预训练后可适配多种任务”；大语言模型（Large Language Model，LLM）是以语言为核心的一类基础模型；多模态模型则可以联合处理文本、图像、音频或视频。
生成式 AI 描述的是“生成新内容”的能力与应用范式。LLM、扩散模型和多模态模型都可能提供生成能力，所以“生成式 AI”不能简单画成 LLM 的上级或下级。
RAG、Workflow 和 Agent 更不是模型，它们是构建应用的工程方法。
边界速记：AI 是目标领域；ML、DL 是技术范式；LLM、多模态模型是模型类别；生成式 AI 是能力范式；RAG、Workflow、Agent 是应用工程方法。
以企业助手为例，它可以使用一个多模态基础模型读取文字和截图，同时使用 RAG 查询制度、使用 Workflow 执行工单流程。这并不意味着“RAG 属于 LLM”或“Workflow 属于生成式 AI”，只意味着这些组件在同一个应用中协作。
2. 一个可上线的 AI 应用远不止模型接口
如果只画“用户 → LLM → 答案”，看到的只是最短演示链路。生产系统还需要交互、业务应用、编排、知识与工具、数据、基础设施，以及贯穿所有层的治理。
因此，“换一个更强模型”通常只改变模型层。它不会自动补齐企业知识、实时业务数据、工具权限、失败恢复、质量评估和审计。
从下往上看，基础设施提供模型服务、存储、队列和缓存；数据层保存文档、索引、业务记录及权限元数据；模型层提供生成、向量表示和重排；能力与协议层把模型组合成 Prompt、RAG、Tools、Memory 等可复用能力；编排与运行时层管理状态、分支、重试和 Agent 循环；应用层承载实际业务；交互层负责用户入口。
治理层之所以画在侧面，是因为身份、授权、审计、评估和成本控制不能只放在最后一个接口上。一次检索要做权限过滤，一次写工具要做审批，一次模型输出也要留下可追踪记录。
3. 模型生命周期不等于应用生命周期
大多数团队不会从头预训练一个 LLM，而是选择已有模型，把主要精力放在数据治理、Prompt、RAG、工具连接、应用开发、评估和运行监控上。
真正的工程闭环不是“模型上线就结束”，而是：观察线上失败，沉淀评测集，再回到数据、上下文和流程设计中修正。
企业助手上线后，如果“制度版本识别错误”，修复点可能是文档元数据和检索过滤；如果“工具参数经常缺失”，修复点可能是工具 Schema、Prompt 或模型；如果“流程中断后重复退款”，修复点则在幂等和运行时恢复。生命周期地图帮助我们把失败送回正确环节，而不是笼统归因于“模型不够聪明”。
二、LLM 提供语言能力，但它不是完整应用
一次 LLM 请求可以粗略理解为：输入文本被切成 Token；Token 被映射为向量；Transformer 根据上下文计算表示；模型逐步预测下一个 Token；最后由应用接收、校验并展示结果。
Attention 让模型能够在当前上下文中关注相关信息，但“上下文窗口”不是永久记忆。模型在本次请求里看见了什么，不代表它以后仍然记得，也不代表它天然知道企业内部文档和实时业务状态。
这里的“逐 Token 生成”也解释了为什么同一个问题可能得到不同措辞，为什么长上下文会增加成本和延迟，以及为什么结构化输出仍需要校验。模型是在条件概率下继续序列，不是在数据库里查找一个唯一答案。
企业助手例子：让模型把用户描述提取成
{工单类型, 紧急程度, 影响范围}，属于语言理解能力；字段是否满足枚举、用户是否有权创建工单、写入失败是否重试，仍由系统负责。
这带来一个非常重要的区分：模型能力不等于系统能力。
LLM 可以理解语言、生成文本、提取结构和提出候选步骤；系统则要负责知识检索、工具执行、状态保存、权限判断、重试、审批、监控和审计。模型给出的是带概率的候选输出，应用必须决定如何使用它。
因此，稳定应用通常会把职责拆开：模型处理模糊语言，代码处理确定规则，检索系统提供证据，策略引擎判断权限，运行时保存状态，人工处理高风险例外。边界越清楚，失败越容易定位，替换模型时受到的连锁影响也越小。
三、RAG 解决“回答依据从哪里来”
检索增强生成（Retrieval-Augmented Generation，RAG）的核心不是某个数据库，而是一个运行模式：在生成答案前，先从外部知识源检索相关证据，再把问题和证据共同交给模型。
完整 RAG 至少包含两条链路。
离线链路负责解析文档、切分内容、建立关键词或向量索引，并保存权限和来源元数据；在线链路负责理解查询、检索候选、重排、组装上下文、生成答案、附上引用，必要时拒答。
为什么说“RAG 不等于向量数据库”？因为向量数据库只可能承担索引和相似度检索的一部分。小型知识库可以使用全文检索，精确编号和名称查询往往更适合关键词搜索，复杂场景还会组合结构化数据库、知识图谱和实时 API。
而且，检索到了内容不等于答案一定正确。文档解析错误、切分不合理、权限过滤缺失、召回偏差、重排失败和生成阶段曲解证据，都会让结果失真。
企业助手例子：员工问“差旅报销上限是多少？”时，RAG 应检索当前有效的制度条款并给出出处；如果没有足够证据，系统应该明确拒答，而不是让模型凭印象补全。
评估 RAG 也不能只看最终文字“像不像正确答案”。至少要分别检查检索是否召回正确证据、重排是否把关键条款放在前面、答案是否忠于证据、引用是否真的支持结论，以及无证据时是否能够拒答。
四、Tool Calling 解决“如何连接外部动作”
当用户问“我的工单处理到哪一步”，答案来自实时业务系统，不应该依赖模型参数，也不适合只检索静态文档。这时需要 API 或工具。
Tool Calling 的含义是：应用向模型提供工具名称和参数结构，模型返回一个结构化调用请求；应用完成权限校验和参数验证后执行工具，再把结果交回模型或直接展示。
真正执行动作的是应用，不是模型本身。一次工具调用也不自动构成 Agent。
对于“查询订单”这类只读动作，可以在校验后自动执行；对于“退款、发消息、修改配置”等写操作，应增加幂等键、额度限制和人工审批。工具越强，治理要求越高。
常见误区：模型输出了
refund(order_id=...)，不代表退款已经发生。正确链路还包括身份与权限校验、参数验证、策略判断、实际执行、结果记录和失败处理。模型只提出候选调用，应用保留最终控制权。
五、Workflow 与 Agent 的本质差异是控制权
Workflow 的路径主要由代码、规则、状态机或流程图预先定义。它适合步骤清楚、审计要求高、失败处理明确的任务。
Agent 则把一部分“下一步做什么”的选择权交给模型。它围绕目标反复观察状态、选择动作、调用工具、读取结果，直到完成、失败、被拒绝、超时或达到预算上限。
所以 Agent 不等于聊天机器人。聊天机器人可能只进行一次模型调用；Agent 也不一定有聊天界面，它可以在后台处理文档、代码或运营任务。
例如，“收到申请后校验字段、查询额度、等待审批、写入系统、发送通知”适合 Workflow，因为关键路径和失败策略可以预先定义；“阅读多份材料，判断还缺什么信息，再选择搜索、追问或调用分析工具”更适合受约束的 Agent，因为下一步取决于中间观察。
两者的关键不是有没有调用 LLM，而是谁拥有流程控制权。Workflow 中可以有多个 LLM 节点，它仍然是 Workflow；Agent 也可以调用确定性子流程，它仍然只在被授权的范围内动态决策。
工程上不必在“全部 Workflow”和“全部 Agent”之间二选一。更实用的做法是把它们看成四种组合。
纯 Workflow 最稳定；Workflow + LLM 允许某个节点完成分类、提取或生成；Workflow + 局部 Agent 只把开放性子任务交给 Agent；Agent + 子 Agent 适合确实需要专业分工的复杂任务，但成本、延迟和调试难度最高。
我的当前判断：生产系统应优先保持确定性边界，只在无法合理预写路径的局部引入 Agent。能用普通函数解决的，不必交给模型；能用 Workflow 清晰表达的，不必扩大 Agent 的自治范围。
多 Agent 也不是天然更先进。只有专业边界、上下文或权限确需隔离，且收益大于通信与评估成本时，子 Agent 才有意义。
六、把同一个企业助手逐步升级
把前面的概念放回同一个案例，关系会更直观。
普通 LLM 只能根据当前输入回答；Prompt 和结构化输出让结果更稳定；RAG 增加企业知识证据；Tool Calling 读取或改变业务状态；Workflow 固定关键流程；局部 Agent 处理路径不确定的任务；生产治理再补上身份、权限、审批、评估、追踪、成本和失败恢复。
每一步都在解决上一阶段暴露出来的具体问题，而不是为了追逐一个更热门的名词。
这条演进线不是必须走完的成熟度阶梯。只做知识问答的系统可能停在 RAG；固定的工单自动化可能停在 Workflow + LLM；只有目标开放、工具较多、路径难以穷举的部分才需要 Agent。系统复杂度应该由业务问题推动，而不是由概念新旧推动。
同时，每增加一种能力都会增加新的失败面：RAG 带来检索质量与文档权限问题，工具带来越权和副作用风险，Workflow 带来状态恢复问题，Agent 带来动态路径、预算失控和轨迹评估问题。生产治理不是第七步才开始，而是每一步同步扩展。
七、框架、运行时、Harness 和协议不是替代关系
当系统进入工程实现阶段，还会遇到另一组容易混淆的名字。
LangChain、OpenAI Agents SDK 等提供模型、工具、消息和 Agent Loop 的应用框架；LangGraph、业务 Workflow Runtime 等负责状态图、持久化、暂停恢复和人工介入；Agent Harness 在运行时之上补充计划、Todo、文件、上下文压缩、Skills、沙箱和追踪等工作环境。
这些框架可以减少重复工程，但不会替代业务规则、权限系统和质量评估，也不会让一个设计不合理的 RAG 自动变好。
图中的层也不是所有产品都必须独立部署。小型应用可以由一个框架同时承担模型调用、工具循环和简单状态；当任务变长、需要暂停恢复或人工审批时，再引入持久化运行时；当 Agent 需要在文件、终端、浏览器或沙箱中长时间工作时，Harness 的价值才会明显上升。
协议解决的是连接方向。
模型上下文协议（Model Context Protocol，MCP）采用 Host、Client、Server 架构，让 AI 应用发现和使用 Tools、Resources 与 Prompts；Agent2Agent（A2A）面向相互独立的 Agent 之间进行任务协作；Agent User Interaction Protocol（AG-UI）面向前端应用与 Agent 之间传递运行事件、消息、状态和中断。
协议不是 Agent，也不会替代认证、授权、审批或编排运行时。
连接速记：MCP 关注“应用怎样接入能力与上下文”，A2A 关注“独立 Agent 怎样协作”，AG-UI 关注“Agent 的过程怎样呈现给用户并接受中断”。它们可以组合使用，但解决的是三个方向的问题。
八、面对一个需求，应该从哪里开始
我的选择顺序是：先问普通代码和规则能否解决；如果需要语言理解或生成，再使用 LLM；如果缺少私有或可引用知识，再加入 RAG；如果需要实时数据或业务动作，再加入工具；如果步骤固定，用 Workflow；只有下一步必须根据中间结果动态决定时，才引入受约束的 Agent。
最后，无论是否使用 Agent，只要系统准备进入生产环境，都要补上权限、安全、评估、追踪、成本和人工兜底。
决策还要看风险等级：草稿可以重试，查询要校验来源；修改订单、付款或发布内容则必须限权、审批并支持回滚。
写在最后
经过这次整理，我认为最值得记住的不是某个框架名字，而是下面这组关系：
LLM 提供语言理解与生成能力；Prompt 和 Context 决定模型当前看见什么；RAG 提供外部知识证据；Tool Calling 表达动作请求；Workflow 固定可靠边界；Agent 在边界内动态选择步骤；运行时和 Harness 提供状态与工作环境；协议连接外部参与者；治理让系统能够真正上线。
这张地图只是系列的起点。下一篇会沿着其中一条链路继续拆解：
《RAG 不等于向量数据库：从文档到可信回答的完整链路》。
资料依据
Vaswani et al., Attention Is All You Need Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks LangChain Agents LangGraph Overview OpenAI Agents SDK Microsoft Agent Framework Model Context Protocol Architecture Agent2Agent Protocol AG-UI Core Architecture
框架和协议变化较快。本文对相关定位的校准日期为 2026-08-14；稳定原理与快速变化的产品能力应分开理解。