从聊天机器人到智能体大模型应用经历了什么变化码海寻道 · 大模型、智能体与 RAG 工程组件系列第 2 篇几年前我们说“做一个 AI 应用”很多时候指的是接入一个聊天机器人用户输入问题模型返回答案。今天越来越多项目开始讨论 RAG、工具调用、工作流和 Agent。模型不再只是回答问题还被要求查询数据库、阅读文件、调用接口、编排任务甚至在出现错误后继续尝试。这并不是简单地把聊天窗口换了一个名字而是大模型应用的系统结构发生了变化。本文沿着一条清晰的演进路线理解大模型应用是如何从“会聊天”逐步发展到“能完成任务”的。一、第一阶段模型 API 加聊天界面最早的大模型应用通常非常简单用户输入 ↓ 后端调用模型 API ↓ 返回模型文本前端有一个输入框和消息列表后端只需要把用户消息拼进请求再把模型返回的文本展示出来。这种模式适合通用问答文案生成翻译和摘要代码解释简单的头脑风暴。它的优点是开发快、组件少、容易验证模型能力。但它也有明显限制模型只知道当前上下文无法自动访问企业数据也不能真正执行外部操作。如果用户问“帮我查一下订单状态”模型最多只能生成一段看起来像答案的话却无法确认真实订单状态。二、第二阶段多轮对话与上下文记忆为了让聊天更自然应用开始保存历史消息第 1 轮用户介绍问题 第 2 轮用户补充条件 第 3 轮用户要求修改答案后端每次调用模型时都会把部分历史消息一同发送。这样模型能够理解“它”“上一个方案”“刚才的第二点”等指代关系。会话记忆并不等于长期记忆开发者需要区分几种不同的“记忆”短期上下文当前对话中的历史消息会话记录保存在数据库中的完整聊天内容用户偏好用户主动保存的语言、格式和习惯外部知识企业文档、产品资料和业务数据。它们的存储方式和使用方式并不相同。Redis 可以缓存短期会话PostgreSQL 可以保存持久化记录而知识库通常还需要 Embedding 和向量检索。上下文不是越长越好把所有历史消息都发送给模型会增加 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状态、规划、循环、终止条件动态选择行动生产级 AgentWorkflow、监控、评估、人工介入可控、可审计、可恢复组件变多并不等于系统一定更好。每增加一种能力就增加了延迟、成本、故障点和安全边界。九、一个典型智能客服是如何演进的假设我们要做一个电商客服可以分阶段建设。第一步通用问答模型回答“退货规则是什么”但内容可能过时也没有引用来源。第二步接入 RAG模型从最新的售后政策中检索相关段落再生成带依据的回答。第三步接入订单工具用户询问具体订单时模型可以请求后端查询订单状态。第四步加入工作流退款、换货和投诉分别进入不同流程高风险操作转人工审核。第五步引入受限 Agent面对复杂问题Agent 可以在允许的知识库、订单查询和物流查询工具之间选择但不能直接退款或修改订单。这是一条渐进式路线而不是一开始就部署“全能 Agent”。十、不要把“自主性”当成唯一目标大模型应用的价值不只是让模型做更多决定也包括让系统更稳定地完成任务。在以下场景中固定流程通常优于 Agent每次处理步骤完全一致需要严格审计和重放操作风险高可以用明确规则解决任务不值得承担额外模型调用成本。在以下场景中Agent 才更有价值用户目标明确但实现路径不确定需要组合多个工具中途需要根据结果调整计划人工很难提前枚举所有分支任务允许一定程度的探索和重试。十一、用四个问题判断项目处在哪个阶段当你面对一个新的 AI 需求可以依次询问只需要生成文本还是需要访问外部知识只需要访问知识还是需要查询实时业务数据工具调用路径固定还是需要模型动态选择任务是否需要审批、人工介入、状态恢复和完整审计如果答案依次是“文本、知识、固定、严格”你更适合从聊天或 RAG Workflow 开始如果答案逐渐走向“实时数据、动态选择、复杂任务”才有必要引入 Agent。结语智能化是逐步增加能力不是一次堆满名词从聊天机器人到智能体大模型应用经历的不是一次简单升级而是能力边界逐步外扩生成文本 ↓ 理解对话 ↓ 检索知识 ↓ 调用工具 ↓ 动态规划 ↓ 在受控流程中完成任务理解这条演进路线后你就不会再把 RAG、Agent 和 Workflow 当成三个互相竞争的概念。它们分别解决知识、行动和流程问题真正成熟的系统往往会根据业务风险和任务不确定性把三者组合在一起。下一篇我们继续进入模型与向量基础《Embedding 是什么大模型为什么需要把文字变成向量》参考资料LangChain DocumentationWorkflows and agentsLangGraph DocumentationGraph API overviewLangGraph DocumentationLangGraph overviewOpenAI Platform DocumentationUsing tools本文为“码海寻道”原创技术文章。模型能力、工具调用格式和框架 API 会随版本变化正式开发时请以对应项目的最新官方文档为准。
