几年前，我们说“做一个 AI 应用”，很多时候指的是接入一个聊天机器人：用户输入问题，模型返回答案。

        今天，越来越多项目开始讨论 RAG、工具调用、工作流和 Agent。模型不再只是回答问题，还被要求查询数据库、阅读文件、调用接口、编排任务，甚至在出现错误后继续尝试。

        这并不是简单地把聊天窗口换了一个名字，而是大模型应用的系统结构发生了变化。

        本文沿着一条清晰的演进路线，理解大模型应用是如何从“会聊天”逐步发展到“能完成任务”的。

        一、第一阶段：模型 API 加聊天界面

        最早的大模型应用通常非常简单：

用户输入
  ↓
后端调用模型 API
  ↓
返回模型文本

        前端有一个输入框和消息列表，后端只需要把用户消息拼进请求，再把模型返回的文本展示出来。

这种模式适合：

•  通用问答；

•  文案生成；

•  翻译和摘要；

•  代码解释；

•  简单的头脑风暴。

        它的优点是开发快、组件少、容易验证模型能力。但它也有明显限制：模型只知道当前上下文，无法自动访问企业数据，也不能真正执行外部操作。

        如果用户问“帮我查一下订单状态”，模型最多只能生成一段看起来像答案的话，却无法确认真实订单状态。

        二、第二阶段：多轮对话与上下文记忆

        为了让聊天更自然，应用开始保存历史消息：

第 1 轮：用户介绍问题
第 2 轮：用户补充条件
第 3 轮：用户要求修改答案

        后端每次调用模型时，都会把部分历史消息一同发送。这样模型能够理解“它”“上一个方案”“刚才的第二点”等指代关系。

        2.1 会话记忆并不等于长期记忆

        开发者需要区分几种不同的“记忆”：

•  短期上下文：当前对话中的历史消息；

•  会话记录：保存在数据库中的完整聊天内容；

•  用户偏好：用户主动保存的语言、格式和习惯；

•  外部知识：企业文档、产品资料和业务数据。

        它们的存储方式和使用方式并不相同。Redis 可以缓存短期会话，PostgreSQL 可以保存持久化记录，而知识库通常还需要 Embedding 和向量检索。

        2.2 上下文不是越长越好

        把所有历史消息都发送给模型，会增加 Token 消耗和延迟，也可能让真正重要的信息被淹没。实际系统需要做历史截断、摘要、分层记忆和按需召回。

        因此，多轮对话解决的是“模型能否理解对话过程”，还没有解决“模型能否获取外部事实”。

        三、第三阶段：RAG 让模型能够参考外部知识

        当用户开始询问企业内部资料，单纯依赖模型参数就不够了。RAG 由此成为大模型应用中最常见的增强方式之一。

        标准流程是：

用户问题
  ↓
问题 Embedding
  ↓
向量检索知识库
  ↓
获得相关文档片段
  ↓
将片段放入上下文
  ↓
模型生成回答

        RAG 的关键变化是：模型回答时不再只依赖训练数据和聊天历史，还可以参考应用在运行时提供的外部资料。

        例如，企业制度问答系统可以从知识库取出《差旅管理办法》的相关段落，再要求模型基于这些内容回答并附带来源。

        但 RAG 仍然主要是一条“检索后生成”的链路。模型通常不会自主决定要访问几个系统，也不会无限循环地规划任务。

        四、第四阶段：结构化输出让模型更容易被程序使用

        早期应用通常只读取模型返回的自然语言文本。后来，开发者开始要求模型按照 JSON 或特定 Schema 输出：

{
  "intent": "refund_query",
  "confidence": 0.91,
  "need_human_review": false
}

        结构化输出有几个重要作用：

•  让后端可以稳定解析模型结果；

•  把意图分类变成程序可执行的分支条件；

•  让工作流节点之间传递明确状态；

•  降低自由文本格式变化带来的错误。

        它是从“模型输出给人看”走向“模型输出给程序使用”的关键一步。

        但结构化输出本身也不代表模型拥有自主行动能力。它只是让模型更可靠地表达判断结果。

        五、第五阶段：Tool Calling 让模型能够请求外部行动

        如果说 RAG 让模型“读到外部知识”，那么 Tool Calling 则让模型“请求执行外部操作”。

        开发者可以为模型声明工具：

{
  "name": "query_order",
  "description": "查询指定订单的当前状态",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string"
      }
    },
    "required": ["order_id"]
  }
}

        用户问“订单 20260001 到哪了”，模型可以输出一个工具调用请求。真正执行查询的仍然是后端：

用户问题
  ↓
模型判断需要查询订单
  ↓
模型生成工具名称和参数
  ↓
后端校验权限与参数
  ↓
后端访问订单系统
  ↓
工具结果返回模型
  ↓
模型组织最终回答

        这里有一个非常重要的安全边界：

        模型只是提出调用请求，不能绕过后端直接操作生产数据库。

        六、第六阶段：从固定调用工具到 Agent

        如果每个问题都固定调用同一个工具，那么它仍然可以用普通代码或 Workflow 实现。

        例如：

用户输入城市
  ↓
固定调用天气 API
  ↓
生成天气说明

        Agent 的出现，通常意味着任务路径变得不确定。用户只给出一个目标，模型需要根据当前状态决定下一步：

用户目标：分析销售下降原因
  ↓
模型判断先查询销售数据库
  ↓
读取统计结果
  ↓
模型发现需要按区域拆分
  ↓
再次调用分析工具
  ↓
模型判断是否需要搜索市场信息
  ↓
综合结果并输出报告

        Agent 的典型循环可以概括为：        

理解目标
  ↓
选择行动
  ↓
调用工具
  ↓
观察结果
  ↓
继续行动或结束

        与普通聊天机器人相比，Agent 的核心变化不是“回答更长”，而是它开始参与任务规划和环境交互。

        七、第七阶段：Workflow 让 Agent 变得可控

        Agent 能动态行动，但完全自由的动态行动并不适合所有业务。金融、合同、订单、医疗和企业审批等场景，需要明确的权限、审计和人工确认。

        因此，生产系统经常采用 Workflow 约束 Agent：

固定节点：问题分类
  ↓
固定节点：权限判断
  ↓
受限 Agent：在白名单工具中完成分析
  ↓
固定节点：结果校验
  ↓
固定节点：人工审批或执行

        Workflow 负责边界和流程，Agent 负责边界内部的不确定决策。两者不是互相替代，而是互相补充。

        LangGraph 官方文档把 Workflow 描述为预先确定代码路径的系统，把 Agent 描述为动态决定过程和工具使用的系统。它还将状态、节点和边作为构建图式应用的基本要素。

        八、从聊天到智能体，究竟增加了哪些组件？

        可以用下面的对比理解系统复杂度变化：

阶段	主要组件	新增能力
单轮聊天	模型 API、前端、后端	文本生成
多轮对话	会话存储、上下文管理	理解对话历史
RAG 应用	文档解析、Embedding、向量库	参考外部知识
工具调用	工具 Schema、业务 API、权限校验	获取实时数据、执行动作
Agent	状态、规划、循环、终止条件	动态选择行动
生产级 Agent	Workflow、监控、评估、人工介入	可控、可审计、可恢复

        组件变多并不等于系统一定更好。每增加一种能力，就增加了延迟、成本、故障点和安全边界。

        九、一个典型智能客服是如何演进的？

        假设我们要做一个电商客服，可以分阶段建设。

        9.1 第一步：通用问答

        模型回答“退货规则是什么”，但内容可能过时，也没有引用来源。

        9.2 第二步：接入 RAG

        模型从最新的售后政策中检索相关段落，再生成带依据的回答。

        9.3 第三步：接入订单工具

        用户询问具体订单时，模型可以请求后端查询订单状态。

        9.4 第四步：加入工作流

        退款、换货和投诉分别进入不同流程，高风险操作转人工审核。

        9.5 第五步：引入受限 Agent

        面对复杂问题，Agent 可以在允许的知识库、订单查询和物流查询工具之间选择，但不能直接退款或修改订单。

        这是一条渐进式路线，而不是一开始就部署“全能 Agent”。

        十、不要把“自主性”当成唯一目标

        大模型应用的价值不只是让模型做更多决定，也包括让系统更稳定地完成任务。

        在以下场景中，固定流程通常优于 Agent：

•  每次处理步骤完全一致；

•  需要严格审计和重放；

•  操作风险高；

•  可以用明确规则解决；

•  任务不值得承担额外模型调用成本。

        在以下场景中，Agent 才更有价值：

•  用户目标明确，但实现路径不确定；

•  需要组合多个工具；

•  中途需要根据结果调整计划；

•  人工很难提前枚举所有分支；

•  任务允许一定程度的探索和重试。

        十一、用四个问题判断项目处在哪个阶段

        当你面对一个新的 AI 需求，可以依次询问：

1.  只需要生成文本，还是需要访问外部知识？

2.  只需要访问知识，还是需要查询实时业务数据？

3. 工具调用路径固定，还是需要模型动态选择？

4. 任务是否需要审批、人工介入、状态恢复和完整审计？

        如果答案依次是“文本、知识、固定、严格”，你更适合从聊天或 RAG + Workflow 开始；如果答案逐渐走向“实时数据、动态选择、复杂任务”，才有必要引入 Agent。

        十二、结语：智能化是逐步增加能力，不是一次堆满名词

        从聊天机器人到智能体，大模型应用经历的不是一次简单升级，而是能力边界逐步外扩：

生成文本
  ↓
理解对话
  ↓
检索知识
  ↓
调用工具
  ↓
动态规划
  ↓
在受控流程中完成任务

        理解这条演进路线后，你就不会再把 RAG、Agent 和 Workflow 当成三个互相竞争的概念。

        它们分别解决知识、行动和流程问题，真正成熟的系统，往往会根据业务风险和任务不确定性，把三者组合在一起。

---

参考资料

1.  LangChain Documentation：Workflows and agents

2.  LangGraph Documentation：Graph API overview

3.  LangGraph Documentation：LangGraph overview

4.  OpenAI Platform Documentation：Using tools

      2.从聊天机器人到智能体：大模型应用经历了什么变化？