一、引言
当前的 AI 应用经常出现以下命名：智能客服 Agent、企业知识 Agent、SQL Agent、报表分析 Agent、审批 Agent等，这些系统可能都调用了大语言模型，但底层控制方式差异很大。
一个系统如果只执行以下过程：
用户问题 -> 拼接提示词 -> 调用模型 -> 返回答案
它属于生成式 AI 应用，未必是 Agent。
如果系统增加知识检索：
用户问题 -> 检索知识库 -> 拼接上下文 -> 调用模型 -> 返回答案
它属于 RAG 应用，也未必是 Agent。
如果系统按预先设计的步骤执行：
识别意图 -> 查询订单 -> 检查规则 -> 生成回复
它更接近 Workflow。即使每一步都调用大模型，执行路径仍由程序控制。
Workflow 定义为“大模型和工具按照预先定义的代码路径运行”，而 Agent 则由大模型动态决定执行过程和工具使用方式。
因此，判断 Agent 的核心问题不是：系统调用了几个模型？接了多少工具？用了什么框架？而是：面对当前状态，下一步行动由代码预先指定，还是由模型结合目标和反馈动态决定？
二、技术边界图
- Chatbot 是交互形态，不是自主性等级。
- RAG 是知识增强技术，可以被 Chatbot、Workflow 或 Agent 使用。
- Workflow 与 Agent 的主要分界，在于路径由谁决定。
一个 Agent 可以没有聊天界面。例如，后台运行的告警处置 Agent 接收监控事件后，自主检查日志、查询配置并提出修复方案。
一个 Chatbot 也可以完全不是 Agent。例如，FAQ 机器人只做意图识别和固定答案匹配。
三、Chatbot：重点是对话，不是自主行动
Chatbot 的核心能力是通过文本、语音或其他对话形式接收输入并返回响应。Chatbot 包含一个典型循环：接收用户消息、识别意图、生成回答，再通过相同渠道返回结果。
用户
|
v
接收消息
|
v
识别意图
|
+--------> FAQ / 数据库查询
|
v
生成或选择回答
|
v
返回用户
Chatbot 可以调用大模型，也可以基于规则。它甚至可以调用查询接口，但“能调用接口”仍不足以证明它是 Agent。
例如，用户询问“我的订单到哪里了”，系统根据固定意图调用订单查询接口，然后返回物流状态。系统已经执行了工具调用，但它的路径在设计阶段已经确定：
订单查询意图 -> 提取订单号 -> 调用物流 API -> 格式化回复
这仍然是一个对话式 Workflow。
Chatbot 适合以下场景：
- FAQ 和制度问答
- 固定业务查询
- 信息收集
- 表单式对话
- 用户引导
- 将自然语言转换成结构化参数
这些任务的共同特点是：输入和输出相对清楚，系统无需自主规划未知步骤。
四、RAG：解决知识问题，不负责完成业务目标
RAG，即检索增强生成，先从外部数据源检索相关内容，再把检索结果提供给模型生成答案。RAG把传统信息检索系统与生成式大模型结合，使输出获得更及时、更相关的事实依据。
基础 RAG 的运行方式通常是：
用户问题
|
v
查询改写
|
v
检索知识库
|
v
召回 + 重排
|
v
构造上下文
|
v
LLM 生成答案
|
v
返回答案与引用
RAG 主要回答三个问题：
- 去哪里找知识？
- 找到哪些内容与问题相关？
- 如何让模型基于这些内容作答？
它并不天然负责：
- 规划多步任务；
- 决定调用哪些业务工具；
- 修改外部系统状态；
- 根据执行失败重新选择路径；
- 判断任务是否已经完成。
因此，“企业知识库问答”通常首先是 RAG 问题，而不是 Agent 问题。
RAG 可以成为 Agent 的一个工具：
固定 RAG 应用由程序决定何时检索；Agentic RAG 则可能由 Agent 决定：
- 是否需要检索；
- 检索哪个数据源；
- 是否改写查询；
- 当前证据是否充分；
- 是否继续第二轮检索；
- 是否需要调用非检索工具验证结论。
但不能因为 RAG 增加了查询改写或重排步骤，就自动把它称为 Agent。只要路径仍然固定，它依旧更接近 Workflow。
五、Workflow：路径确定，节点可以智能
Workflow 将任务拆成一组预定义步骤，并规定步骤之间的执行顺序、条件和异常处理方式。
开始
|
v
分类请求
|
+-------- 售后问题 -------> 查询订单 -----> 售后规则校验
|
+-------- 产品问题 -------> 检索知识库 ---> 生成回答
|
+-------- 投诉问题 -------> 情绪识别 -----> 转人工
模型可以参与分类、抽取、生成和审核，但代码仍控制整体路径。
多种常见 Workflow 模式：
- Prompt Chaining：将任务拆成固定步骤；
- Routing：根据输入路由到不同分支；
- Parallelization：并行执行独立子任务；
- Orchestrator-Workers：动态拆分子任务并汇总；
- Evaluator-Optimizer：生成、评价、修改循环。
Workflow 并不等于“没有智能”，一个 Workflow 可以包含大模型判断，也可以根据模型输出走条件分支。判断标准仍然是系统的行动空间是否由开发者预先限定，以及模型是否掌握任务级控制权。
Workflow 的优势：
- 行为更可预测 ：主要路径可枚举、可测试。
- 成本容易估算 ：模型调用次数和工具调用范围相对稳定。
- 异常容易处理 ：每个节点可设置超时、重试和补偿。
- 权限容易收敛 ：每一步只能调用指定接口。
- 审计更清晰 ：业务可以理解系统为何进入某个分支。
如果业务流程已经可以画成稳定的 BPMN、状态机或决策树，Workflow 往往比 Agent 更合适。
六、Agent：让模型在受控边界内决定下一步
AI Agent 是一个目标驱动系统。它能观察当前状态，在受控工具和权限范围内选择下一步行动，读取行动结果，并持续调整后续步骤，直到完成目标、触发停止条件或请求人工介入。
最小 Agent 闭环如下：
Agent 的关键不只是“推理”，而是形成了一个闭环：
Observe -> Decide -> Act -> Observe
Agent 的五个基本组成：
- Goal ：描述结果，而不是逐条操作指令。
- Model ：理解目标并选择下一步行动。
- State ：保存当前任务进度和工具结果。
- Tools ：让系统检索信息或改变外部状态。
- Policy ：限制权限、循环次数、成本和高风险操作。
Memory 常见但并非定义 Agent 的绝对必要条件，Agent“可以”使用记忆系统维护上下文，而不是所有 Agent 都必须具备长期记忆。
七、四者的核心区别
| 维度 | Chatbot | RAG 应用 | Workflow | Agent |
|---|---|---|---|---|
| 主要目的 | 完成对话交互 | 基于外部知识回答 | 按既定过程执行任务 | 围绕目标动态完成任务 |
| 核心问题 | 如何理解并回复用户 | 回答依据从哪里来 | 任务按什么固定路径运行 | 当前状态下下一步做什么 |
| 路径控制者 | 对话程序或模型 | 检索管线 | 代码与规则 | 模型与运行时共同控制 |
| 执行路径 | 通常较短 | 通常固定 | 预定义 | 运行时动态产生 |
| 工具使用 | 可选 | 主要使用检索工具 | 固定工具、固定节点 | 动态选择允许的工具 |
| 外部状态变更 | 通常没有 | 通常没有 | 可以 | 经常包含 |
| 环境反馈循环 | 弱 | 可能有固定迭代 | 由流程显式定义 | Agent 根据反馈决定是否继续 |
| 可预测性 | 高 | 较高 | 高 | 相对较低 |
| 成本与延迟 | 较低 | 中等 | 可估算 | 波动更大 |
| 典型场景 | FAQ、信息查询 | 企业知识问答 | 审批、工单、内容流水线 | 编程、调查、复杂运维与跨系统任务 |
现实系统经常采用混合形态，例如：
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，例如：
读取告警
-> 查询日志
-> 检查近期发布
-> 比较配置
-> 执行诊断命令
-> 生成修复方案
-> 请求人工批准
-> 执行修复
-> 验证指标
但“工具多”仍不是充分条件。如果调用顺序固定，Workflow 依旧更合适。
5.结果能否被环境验证
Agent 适合拥有客观反馈的任务：
- 测试是否通过；
- 文件是否成功生成；
- API 是否返回成功状态；
- 数据是否满足约束；
- 目标页面是否出现预期结果；
- 监控指标是否恢复。
可验证反馈帮助 Agent 判断行动是否奏效。
如果任务结果只能靠模糊的主观感觉判断，Agent 可能在错误方向上持续迭代。
6.错误是否可控、可回滚
Agent 会扩大模型错误的影响范围。文本生成错误影响一段回答；具备数据库写权限的 Agent 可能影响真实业务数据。
适合早期 Agent 化的环境通常满足：
- 工具权限可以最小化；
- 操作有审计日志；
- 高风险动作需要人工批准；
- 写操作可以回滚或补偿；
- Agent 有成本、时长和循环次数限制；
- 可以在沙箱中测试。
建议采用有边界的自主性、最小权限和按风险分级的人工审批，而不是让所有操作都自动执行或全部依赖人工盖章。
九、技术选型决策树
技术选型遵循一个原则：选择能够满足业务目标的最低复杂度架构。先寻找最简单的方案，只有在复杂度能够带来可测量收益时，才引入 Agentic System。对于许多应用，优化单次模型调用，并加入检索和上下文示例，已经足够。
十、技术体系的演进，不是从简单到“更像 Agent”
AI 应用常见的演进路径如下：
单次 LLM
|
| 增加外部知识
v
RAG
|
| 增加固定多步处理
v
LLM Workflow
|
| 允许局部动态决策
v
Agentic Workflow
|
| 允许围绕目标自主规划和执行
v
Agent
|
| 多角色、专业化与协作
v
Multi-Agent System
这并不代表后面的形态一定优于前面，每增加一层动态性，系统都会付出代价：
自主性上升
|
+--> 路径数量增加
+--> 测试空间扩大
+--> 成本与延迟波动
+--> 错误可能逐步累积
+--> 权限与安全问题扩大
+--> 调试和复现难度增加
技术选型的目标不是获得最高自主性，而是用最低的不可控性完成业务目标。
十一、先建业务闭环，再选 Agent 框架
当团队确认任务适合 Agent 后，也不应立即比较框架功能。先定义五件事：
- 目标 ：成功完成任务的可验证标准是什么？
- 环境 ：Agent 能观察哪些真实状态？
- 工具 ：每个工具解决什么问题，输入输出是否清晰？
- 边界 ：哪些操作自动执行，哪些操作必须审批？
- 停止条件 ：何时完成，何时中止，何时转人工？
可以先画出最小闭环：
Goal
|
v
Model ----选择----> Tool
^ |
| v
+----- State <--- Result
|
v
Stop / Continue / Escalate
如果这个闭环无法说清，引入 LangGraph、Agents SDK、ADK 或其他框架也不会自动解决问题。框架提供运行时、状态管理、工具封装和可观测能力，却不能替团队定义业务目标和风险边界。
