别急着上 Agent：一文厘清AI Agent 的边界

一、引言

当前的 AI 应用经常出现以下命名：智能客服 Agent、企业知识 Agent、SQL Agent、报表分析 Agent、审批 Agent等，这些系统可能都调用了大语言模型，但底层控制方式差异很大。

一个系统如果只执行以下过程：

rust 复制代码

用户问题 -> 拼接提示词 -> 调用模型 -> 返回答案

它属于生成式 AI 应用，未必是 Agent。

如果系统增加知识检索：

rust 复制代码

用户问题 -> 检索知识库 -> 拼接上下文 -> 调用模型 -> 返回答案

它属于 RAG 应用，也未必是 Agent。

如果系统按预先设计的步骤执行：

rust 复制代码

识别意图 -> 查询订单 -> 检查规则 -> 生成回复

它更接近 Workflow。即使每一步都调用大模型，执行路径仍由程序控制。

Workflow 定义为"大模型和工具按照预先定义的代码路径运行"，而 Agent 则由大模型动态决定执行过程和工具使用方式。

因此，判断 Agent 的核心问题不是：系统调用了几个模型？接了多少工具？用了什么框架？而是：面对当前状态，下一步行动由代码预先指定，还是由模型结合目标和反馈动态决定？

二、技术边界图

Chatbot 是交互形态，不是自主性等级。
RAG 是知识增强技术，可以被 Chatbot、Workflow 或 Agent 使用。
Workflow 与 Agent 的主要分界，在于路径由谁决定。

一个 Agent 可以没有聊天界面。例如，后台运行的告警处置 Agent 接收监控事件后，自主检查日志、查询配置并提出修复方案。

一个 Chatbot 也可以完全不是 Agent。例如，FAQ 机器人只做意图识别和固定答案匹配。

三、Chatbot：重点是对话，不是自主行动

Chatbot 的核心能力是通过文本、语音或其他对话形式接收输入并返回响应。Chatbot 包含一个典型循环：接收用户消息、识别意图、生成回答，再通过相同渠道返回结果。

yaml 复制代码

用户
  |
  v
接收消息
  |
  v
识别意图
  |
  +--------> FAQ / 数据库查询
  |
  v
生成或选择回答
  |
  v
返回用户

Chatbot 可以调用大模型，也可以基于规则。它甚至可以调用查询接口，但"能调用接口"仍不足以证明它是 Agent。

例如，用户询问"我的订单到哪里了"，系统根据固定意图调用订单查询接口，然后返回物流状态。系统已经执行了工具调用，但它的路径在设计阶段已经确定：

rust 复制代码

订单查询意图 -> 提取订单号 -> 调用物流 API -> 格式化回复

这仍然是一个对话式 Workflow。

Chatbot 适合以下场景：

FAQ 和制度问答
固定业务查询
信息收集
表单式对话
用户引导
将自然语言转换成结构化参数

这些任务的共同特点是：输入和输出相对清楚，系统无需自主规划未知步骤。

四、RAG：解决知识问题，不负责完成业务目标

RAG，即检索增强生成，先从外部数据源检索相关内容，再把检索结果提供给模型生成答案。RAG把传统信息检索系统与生成式大模型结合，使输出获得更及时、更相关的事实依据。

基础 RAG 的运行方式通常是：

yaml 复制代码

用户问题
   |
   v
查询改写
   |
   v
检索知识库
   |
   v
召回 + 重排
   |
   v
构造上下文
   |
   v
LLM 生成答案
   |
   v
返回答案与引用

RAG 主要回答三个问题：

去哪里找知识？
找到哪些内容与问题相关？
如何让模型基于这些内容作答？

它并不天然负责：

规划多步任务；
决定调用哪些业务工具；
修改外部系统状态；
根据执行失败重新选择路径；
判断任务是否已经完成。

因此，"企业知识库问答"通常首先是 RAG 问题，而不是 Agent 问题。

RAG 可以成为 Agent 的一个工具：

固定 RAG 应用由程序决定何时检索；Agentic RAG 则可能由 Agent 决定：

是否需要检索；
检索哪个数据源；
是否改写查询；
当前证据是否充分；
是否继续第二轮检索；
是否需要调用非检索工具验证结论。

但不能因为 RAG 增加了查询改写或重排步骤，就自动把它称为 Agent。只要路径仍然固定，它依旧更接近 Workflow。

五、Workflow：路径确定，节点可以智能

Workflow 将任务拆成一组预定义步骤，并规定步骤之间的执行顺序、条件和异常处理方式。

rust 复制代码

开始
  |
  v
分类请求
  |
  +-------- 售后问题 -------> 查询订单 -----> 售后规则校验
  |
  +-------- 产品问题 -------> 检索知识库 ---> 生成回答
  |
  +-------- 投诉问题 -------> 情绪识别 -----> 转人工

模型可以参与分类、抽取、生成和审核，但代码仍控制整体路径。

多种常见 Workflow 模式：

Prompt Chaining：将任务拆成固定步骤；
Routing：根据输入路由到不同分支；
Parallelization：并行执行独立子任务；
Orchestrator-Workers：动态拆分子任务并汇总；
Evaluator-Optimizer：生成、评价、修改循环。

Workflow 并不等于"没有智能"，一个 Workflow 可以包含大模型判断，也可以根据模型输出走条件分支。判断标准仍然是系统的行动空间是否由开发者预先限定，以及模型是否掌握任务级控制权。

Workflow 的优势：

行为更可预测：主要路径可枚举、可测试。
成本容易估算：模型调用次数和工具调用范围相对稳定。
异常容易处理：每个节点可设置超时、重试和补偿。
权限容易收敛：每一步只能调用指定接口。
审计更清晰：业务可以理解系统为何进入某个分支。

如果业务流程已经可以画成稳定的 BPMN、状态机或决策树，Workflow 往往比 Agent 更合适。

六、Agent：让模型在受控边界内决定下一步

AI Agent 是一个目标驱动系统。它能观察当前状态，在受控工具和权限范围内选择下一步行动，读取行动结果，并持续调整后续步骤，直到完成目标、触发停止条件或请求人工介入。

最小 Agent 闭环如下：

Agent 的关键不只是"推理"，而是形成了一个闭环：

rust 复制代码

Observe -> Decide -> Act -> Observe

Agent 的五个基本组成：

Goal ：描述结果，而不是逐条操作指令。
Model ：理解目标并选择下一步行动。
State ：保存当前任务进度和工具结果。
Tools ：让系统检索信息或改变外部状态。
Policy ：限制权限、循环次数、成本和高风险操作。

Memory 常见但并非定义 Agent 的绝对必要条件，Agent"可以"使用记忆系统维护上下文，而不是所有 Agent 都必须具备长期记忆。

七、四者的核心区别

维度	Chatbot	RAG 应用	Workflow	Agent
主要目的	完成对话交互	基于外部知识回答	按既定过程执行任务	围绕目标动态完成任务
核心问题	如何理解并回复用户	回答依据从哪里来	任务按什么固定路径运行	当前状态下下一步做什么
路径控制者	对话程序或模型	检索管线	代码与规则	模型与运行时共同控制
执行路径	通常较短	通常固定	预定义	运行时动态产生
工具使用	可选	主要使用检索工具	固定工具、固定节点	动态选择允许的工具
外部状态变更	通常没有	通常没有	可以	经常包含
环境反馈循环	弱	可能有固定迭代	由流程显式定义	Agent 根据反馈决定是否继续
可预测性	高	较高	高	相对较低
成本与延迟	较低	中等	可估算	波动更大
典型场景	FAQ、信息查询	企业知识问答	审批、工单、内容流水线	编程、调查、复杂运维与跨系统任务

现实系统经常采用混合形态，例如：

lua 复制代码

Chatbot UI
    |
    v
Workflow 控制主流程
    |
    +----> RAG 提供知识
    |
    +----> Agent 处理开放子任务
    |
    +----> 人工审批高风险操作

混合架构通常比"全流程自主 Agent"更容易进入生产环境。

八、什么场景真的需要 Agent

判断是否需要 Agent，可以检查以下六个问题。

1.业务给出的是目标，还是明确步骤

适合 Workflow 的需求：收到退款申请后，查询订单；金额低于 500 元且未超过 7 天则自动退款，否则转人工。

适合 Agent 候选的需求：调查该客户近期所有异常扣费，判断可能原因，收集相关证据，并提出处理方案。

前一个任务路径清楚，规则可以编码。后一个任务的证据来源、调查步骤和所需工具取决于过程中发现的信息。

2.执行路径能否提前穷举

如果开发者能够列出主要步骤和分支，优先选择 Workflow。

如果下一步取决于前一步产生的开放结果，并且分支数量难以穷举，Agent 才有明显价值。

3.任务是否需要根据环境反馈调整计划

Agent 的价值往往出现在意外情况中：

第一个数据源缺少记录，需要换数据源；
API 返回权限错误，需要申请授权或选择替代路径；
代码修改后测试失败，需要分析错误并重新修改；
初次检索证据不足，需要生成新的检索策略。

如果系统无论得到什么结果都执行同样的下一步，那么动态 Agent 循环可能没有必要。

4.是否需要跨多个工具采取行动

只生成文本的任务通常可以从单次 LLM 调用、RAG 或 Workflow 开始。

需要在多个系统间读取和写入的任务更可能需要 Agent，例如：

rust 复制代码

读取告警
  -> 查询日志
  -> 检查近期发布
  -> 比较配置
  -> 执行诊断命令
  -> 生成修复方案
  -> 请求人工批准
  -> 执行修复
  -> 验证指标

但"工具多"仍不是充分条件。如果调用顺序固定，Workflow 依旧更合适。

5.结果能否被环境验证

Agent 适合拥有客观反馈的任务：

测试是否通过；
文件是否成功生成；
API 是否返回成功状态；
数据是否满足约束；
目标页面是否出现预期结果；
监控指标是否恢复。

可验证反馈帮助 Agent 判断行动是否奏效。

如果任务结果只能靠模糊的主观感觉判断，Agent 可能在错误方向上持续迭代。

6.错误是否可控、可回滚

Agent 会扩大模型错误的影响范围。文本生成错误影响一段回答；具备数据库写权限的 Agent 可能影响真实业务数据。

适合早期 Agent 化的环境通常满足：

工具权限可以最小化；
操作有审计日志；
高风险动作需要人工批准；
写操作可以回滚或补偿；
Agent 有成本、时长和循环次数限制；
可以在沙箱中测试。

建议采用有边界的自主性、最小权限和按风险分级的人工审批，而不是让所有操作都自动执行或全部依赖人工盖章。

九、技术选型决策树

技术选型遵循一个原则：选择能够满足业务目标的最低复杂度架构。先寻找最简单的方案，只有在复杂度能够带来可测量收益时，才引入 Agentic System。对于许多应用，优化单次模型调用，并加入检索和上下文示例，已经足够。

十、技术体系的演进，不是从简单到"更像 Agent"

AI 应用常见的演进路径如下：

yaml 复制代码

单次 LLM
   |
   | 增加外部知识
   v
RAG
   |
   | 增加固定多步处理
   v
LLM Workflow
   |
   | 允许局部动态决策
   v
Agentic Workflow
   |
   | 允许围绕目标自主规划和执行
   v
Agent
   |
   | 多角色、专业化与协作
   v
Multi-Agent System

这并不代表后面的形态一定优于前面，每增加一层动态性，系统都会付出代价：

lua 复制代码

自主性上升
   |
   +--> 路径数量增加
   +--> 测试空间扩大
   +--> 成本与延迟波动
   +--> 错误可能逐步累积
   +--> 权限与安全问题扩大
   +--> 调试和复现难度增加

技术选型的目标不是获得最高自主性，而是用最低的不可控性完成业务目标。

十一、先建业务闭环，再选 Agent 框架

当团队确认任务适合 Agent 后，也不应立即比较框架功能。先定义五件事：

目标：成功完成任务的可验证标准是什么？
环境：Agent 能观察哪些真实状态？
工具：每个工具解决什么问题，输入输出是否清晰？
边界：哪些操作自动执行，哪些操作必须审批？
停止条件：何时完成，何时中止，何时转人工？

可以先画出最小闭环：

lua 复制代码

Goal
  |
  v
Model ----选择----> Tool
  ^                  |
  |                  v
  +----- State <--- Result
             |
             v
     Stop / Continue / Escalate

如果这个闭环无法说清，引入 LangGraph、Agents SDK、ADK 或其他框架也不会自动解决问题。框架提供运行时、状态管理、工具封装和可观测能力，却不能替团队定义业务目标和风险边界。