AI 智能体 vs 聊天机器人：当你需要执行业务流时有何不同

很多团队真正需要的是智能体系统，但一开始做的却是聊天机器人。两者不是一回事，用错了方向，代价比想象中高很多。

从一个错误的起点开始

当一个团队说"我们想在客服流程里加 AI"或者"我们需要自动处理录入工作"，脑子里浮现的画面通常是一个对话框。用户输入问题，系统输出回答。

这个画面没有错，只是太窄了。

聊天机器人擅长一件事：根据输入生成回应。它是无状态的、被动的、为文本交换而优化的。如果工作是从知识库里找答案、总结一份用户粘进来的文档、或者起草一封供人审核的邮件，聊天机器人确实够用。

但真实业务里的工作流程，大多数不是问答结构。它们是一系列决策、工具调用、数据查询、条件判断、审批和交接。聊天机器人无法独立完成这些事情。

最典型的做法是：把 AI 能力当成一个流程插件直接插进去。团队找到一个太依赖人工的工作流程——客服分类、文件录入、内部请求路由—— 然后在前面挂一个语言模型。测试用例跑得很顺，demo 看起来不错，然后上线了。

上线之后，问题开始出现。

失败模式几乎都一样：模型不知道自己不知道什么。它没有可靠的方式说"我需要先查一下再回答"、"这个情况需要人工处理"、或者"第一步完成了但第二步失败了"。它只会生成下一段最合理的文字。

聊天机器人没有跨 session 的记忆，除非你手动接进去。没有工具调用能力，除非你明确定义什么时候用哪个工具。它不知道工作流程当前处于哪个状态—— 任务是否在进行中、已完成、卡住了、还是在等审批。这不是模型本身的问题，而是聊天机器人这个架构模式本来就没有解决这些问题。

智能体系统是把语言模型作为推理组件放进一个更大的运行闭环里的软件。模型是系统的一部分，不是系统本身。

在一个设计合理的智能体系统里，模型负责的是：解读上下文，决定下一步该做什么。围绕模型的系统负责其他所有事情：检索对应的文档，调用对应的 API，执行业务规则，在多个步骤之间维护状态，在置信度低的时候路由到人工审核，记录每一个动作用于审计，出错的时候回滚。

我们在森睿内部用 Sense · Reason · Rock 来描述这个结构。

Sense 是接入上下文的层——文档、API 响应、系统状态、人工输入。

Reason 是模型工作的地方：给定这些上下文，下一步该做什么？

Rock 是执行：动作真正发生，被记录，系统进入下一个状态。

每一层职责清晰。模型不负责即兴发挥数据检索。检索层不做判断。执行层不决定执行什么。这种分工是让系统可审计、可维护、可在生产环境安全运行的基础。

以下几个维度是两种架构真正分叉的地方。

聊天机器人通常在 session 之间没有持久状态，除非你手动接入。智能体系统显式地追踪工作流程状态—— 某个案例走到哪一步了，哪些已完成，哪些在等待，哪些失败了。

聊天机器人可以加工具调用能力，但什么时候用哪个工具往往定义模糊。智能体系统里，工具调用是工作流程设计的一部分：特定步骤可以调用特定工具，有明确的输入输出契约。

聊天机器人可以在被提示时转交人工，但转交逻辑通常很脆弱。智能体系统里，人工复核点是一级架构元素。系统知道什么时候到了需要人工介入的节点，暂停执行，把相关上下文呈现给审核者，等待决定后再继续。

聊天机器人通常是黑盒—— 你知道输入和输出，中间发生了什么很难追踪。智能体系统产生完整的执行追踪：每一步、每次工具调用、每个模型决策、每个人工动作都有记录。出了问题可以调试，需要解释的时候可以审计。

聊天机器人失败的时候通常是静默的，或者给出一个听起来合理但实际错误的回答。智能体系统可以检测到某个步骤失败了，决定是重试、升级处理还是停止，并带着足够的上下文记录下来以便排查。

如果你想自动化的工作是这样的，配置好的聊天机器人或 RAG 系统可能就够了：

如果工作是下面这些情况之一，你需要的是智能体系统：

大多数真实的业务工作流程至少符合上面三条。这也是为什么很多团队从聊天机器人开始，六个月后又在重新做智能体系统。

做了聊天机器人再发现需要智能体系统，代价不只是浪费的开发时间。还有运营代价——系统以你看不见的方式悄悄出错；信任代价——运营团队慢慢不再依赖它；以及重建代价——最终还是要从头再做一遍。

更好的做法是在写任何代码之前，先把工作流程图画出来。涉及哪些步骤？每一步需要什么数据？决策在哪里发生？哪些地方人工必须保持控制？这张图画清楚了，合适的架构通常自己就浮出来了。

如果图看起来像一个线性问答交换，做聊天机器人。如果图看起来像一个有外部依赖和人工介入节点的决策图，做智能体系统。这个区别不是哪种技术更厉害的问题，而是哪种技术在真实工作上真正跑得住的问题。

先把图画对，架构的选择自然就清楚了。