1.4 Agent、Workflow、Chatbot 的边界在哪
一句话结论：三者唯一的区别是「下一步由谁决定」——没人决定（Chatbot）、代码决定（Workflow）、模型决定（Agent）。绝大多数场景你只需要前两种，把它们做成 Agent 是当下最普遍的过度设计。
读这篇之前
需要先读 1.1（一次性调用的局限）和 1.2（四模块闭环）。这一篇是第 1 章的判断题，读者最容易在这里省错钱。
一、一个反直觉的开场
先摆一个可能让做 Agent 的人不太舒服的判断：
最成功的 AI 实现，往往不是最复杂的那个。[原文 4627]
原文引用的那段话值得每个做 AI 产品的人背下来：
「The most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.」
行业里充斥着各种 Agent 框架，但生产环境反复验证的规律是：真正跑得好的系统，用的是最朴素的组合模式。
所以这一篇的目的不是教你造 Agent，而是教你判断什么时候不该造。
二、三者唯一的区别：谁决定下一步
把三个词放进同一张表，差别立刻清楚：
| 下一步由谁决定 | 流程可预测性 | 典型形态 | |
|---|---|---|---|
| Chatbot | 没有人决定——就是一次问答 | 完全可预测 | 客服问答、单轮检索 |
| Workflow | 代码决定（预定义的固定路径） | 高：输入相同则路径相同 | 文案流水线、数据清洗管道 |
| Agent | 模型决定（每轮看着情况判断） | 低：同样输入可能走不同路径 | 编码助手、自主助理 |
定义：
- Workflow：LLM 和工具通过预定义的代码路径编排。开发者在写代码时就决定了执行顺序：先做 A，再做 B，最后做 C。关键词是确定性、可预测、开发者控制流程。
- Agent：LLM 动态决定自己的执行流程和工具使用。模型在每一步自主判断下一步做什么、要不要调工具、什么时候结束。关键词是自主性、动态决策、模型控制流程。[原文 4627]
一张图看清：
Workflow：代码决定流程
输入 → 步骤A → 步骤B → 输出
Agent：模型决定流程
输入 → LLM 决策 → 工具/思考/再决策 → 输出
三、六个维度的差异
光知道"谁决定"不够，实际选型时你会关心成本、调试、风险。这六个维度的对照最能帮上忙：[原文 4627]
| 维度 | Workflow | Agent |
|---|---|---|
| 控制权 | 开发者（代码路径固定） | 模型（每步动态决定） |
| 可预测性 | 高：输入确定则路径确定 | 低：同样输入可能走不同路径 |
| 适用场景 | 任务拆解明确、步骤固定 | 任务开放、需要灵活决策 |
| 成本 | 可控（调用次数固定） | 不确定（循环次数未知） |
| 调试难度 | 低（路径确定，容易复现） | 高（行为不确定，难以复现） |
| 典型例子 | 文案生成管道、数据清洗流水线 | 编码助手、自主助理 |
这张表里最该被重视的是后三行。
"成本可控 vs 不确定"直接影响商业模式——你没法给用户报价，如果每次调用的次数你自己都不知道。
"调试难度"影响团队——一个无法复现的 bug，可能要盯几十条轨迹才能定位。
"可预测性"影响合规——在需要可审计的行业里，"同样输入走不同路径"本身就是风险。
这三条恰恰是 Agent 最难解决的软肋，也是很多团队做完 PoC 就停在那里的原因。
四、什么时候不要用 Agent
大多数情况下，你不需要 Agent。[原文 4627]
实践中反复验证的结论是：对于大多数应用场景，优化单次 LLM 调用配合检索增强（RAG）就够了。只有当简单方案明确无法满足需求时，才应考虑引入 Workflow 或 Agent 的复杂度。
最常见的过度设计是：用一个 Agent 框架去做本质上一个 Prompt 加一次搜索就能解决的问题。 框架引入的延迟、成本、不确定性远大于它带来的收益。
复杂度阶梯
所以正确的做法是从下往上走，每上一级都要有明确理由：
| 级别 | 方案 | 什么时候够用 | 升级理由 |
|---|---|---|---|
| 0 | 单次 LLM 调用 | 任务信息全在输入里 | 效果不够 |
| 1 | 加 RAG 检索 | 需要外部知识 | 需要多步操作 |
| 2 | Workflow 编排 | 步骤可预先确定 | 步骤依赖运行时判断 |
| 3 | Agent（自主循环） | 分支无法预先枚举 | —— |
核心原则：先找最简方案，复杂度只在明确提升效果时才加。
这个阶梯在原文里对应的是更细的一段：[原文 4627]
- 先试单次 LLM 调用：优化 Prompt、加 Few-shot、调参数
- 不够？加检索增强（RAG）：让 LLM 能访问外部知识
- 还不够？用 Workflow：把任务拆成多步，用代码控制流程
- 真的需要灵活决策？才上 Agent
注意第 1、2 步常常能解决 80% 的需求，而它们的成本只是第 4 步的零头。
五、一条可操作的判据
把上面的判断压缩成一个可以直接用的问句：
我能不能在写代码的时候，把所有可能走的分支都枚举出来？
- 能枚举 → 用 Workflow。模型只负责"填充每个分支内的细节"。
- 不能枚举（取决于运行时才拿得到的信息）→ 才需要 Agent。
再补两条辅助判据：
| 问题 | 如果答案是"是" | 结论 |
|---|---|---|
| 任务步骤每次都一样吗？ | 是 | Workflow |
| 出错时必须能一模一样复现吗？ | 是 | Workflow |
| 每次要拆几个子任务事先不知道吗？ | 是 | Agent |
| 需要一个可报价的固定成本吗？ | 是 | Workflow |
六、中间的灰区：混合架构
真实系统几乎不落在两极，而是走在一条光谱上：[原文 4577]
完全固定流程 ──────────────────────────────── 完全自主
代码决定每一步 代码定骨架+模型填细节 模型每步自主决策
绝大多数生产系统在中间地带：外层用代码控制阶段，内层让模型决定具体动作。
混合架构的典型形态：
[代码] 解析请求 → 判断类型
├─ 类型 A → [Workflow] 固定三步骤
├─ 类型 B → [Agent] 自主处理（分支不可枚举）
└─ 类型 C → [单次调用] 直接回答
这种"外层确定、内层灵活"的结构同时拿到了可预测性和灵活性，也更容易在出问题时定位是哪一层出的错。
所以别纠结"我这个算不算 Agent"，要问的是：哪些环节需要模型现场判断，哪些环节可以写死？
七、Workflow 这一档的五种形态
如果判断下来你该用 Workflow，接下来的问题是「Workflow 有哪几种写法」。业界反复验证有效的编排模式，从简到繁大致五种：[原文 4627]
| # | 模式 | 结构 | 适合什么 | 注意事项 |
|---|---|---|---|---|
| 1 | 单次调用 | 一个提示词，一次请求 | 绝大多数任务——先验证这里够不够 | 最容易低估的一档 |
| 2 | 链式 Chaining | 步骤串行，上一步输出是下一步输入 | 任务可明确拆成有序步骤 | 误差会逐级放大 |
| 3 | 路由 Routing | 先分类，再分发给专用提示词 | 输入类型差异大、混在一起互相干扰 | 分类错了后面全错 |
| 4 | 并行 Parallelization | 多个调用同时跑，最后汇总 | 子任务互不依赖；或多角度交叉验证 | 注意汇总环节的取舍规则 |
| 5 | 编排者-工作者 Orchestrator-Workers | 一个调用负责拆解，动态分派给多个执行者 | 子任务数量与内容事先不确定 | 已踩在 Agent 边界上 |
怎么选：三个问题
- 输入是否同类？ 不同类 → 加路由。
- 步骤能否确定顺序？ 能 → 用链式；不能但彼此独立 → 用并行。
- 要拆几个子任务事先知道吗？ 不知道 → 才考虑编排者-工作者。
为什么这五种值得记住
因为它们覆盖了「不用 Agent 但要做到多步」的全部常见需求。第 12 章会把第 5 种和更复杂的编排（DAG、状态机、可视化）展开讲。
这五种模式的价值在于：当你觉得"需要一个 Agent"时，先在上面这张表里找找，很可能第 2 或第 3 种就够了，而它们比 Agent 便宜、稳定、好调试得多。
八、五个真实场景的选型演练
抽象的判据不好用，看五个具体场景。
场景一：日报生成
每天 9 点，拉取昨日数据 → 生成摘要 → 发到群
判断：步骤固定、无需运行时判断 → Workflow（链式）。
理由：定时触发、输出格式固定、失败要能告警重跑。
场景二：故障排查助手
用户描述现象 → 助手查日志、查监控、查发布记录 → 给结论
判断：要查什么取决于查到了什么 → Agent。
理由：分支不可枚举（这是 12.1 讲的"解决未知问题"）。
场景三：代码审查
读取 diff → 按清单检查 → 输出问题列表
判断：清单固定 → Workflow（单次或链式）。
理由：审查维度可枚举；不需要"自主决定查什么"。
场景四：数据清洗管道
读数据 → 校验 → 清洗 → 转换 → 写入
判断：完全固定 → 连 Agent 都不需要，纯代码。
理由：中间不需要模型判断。
这一条最值得强调：并非所有"AI 项目"都需要模型。
场景五：技术选型顾问
用户描述需求 → 助手提问澄清 → 给建议 → 追问深入
判断：交互式、需要根据回答调整 → Agent（或用 Workflow + 多轮）。
理由：需要判断"还缺什么信息"。
但注意：这类场景常常用"Workflow + 多轮对话"就够了，不必真做自主循环。
九、从 Workflow 迁移到 Agent 的风险
如果你有一个跑得不错的 Workflow，想"升级成 Agent"，先看这张表。
| 风险 | 说明 |
|---|---|
| 成本失控 | 从固定次数变成不确定次数（1.3） |
| 行为不可复现 | 同样输入走不同路径（2.4） |
| 审核变难 | Workflow 能预先审核每一步，Agent 不能 |
| 错误传播 | 一步错，后续全错且难察觉 |
| 调试成本 | 要看轨迹而不是看代码 |
一个中间方案：局部 Agent 化
不必整体迁移。更稳的做法是只把某一环换成 Agent：
Workflow:
① 读数据（代码）
② 判断异常（代码 + 规则）
③ **分析根因（Agent：要自主查多源）** ← 只有这一步是 Agent
④ 生成报告（单次模型调用）
⑤ 发送（代码）
收益：只在一个真正需要灵活性的环节引入不确定性。
代价：只在那一步有不可预测性。
这是实践中最多见的形态，也是 12.1 讲的混合架构。
十、一个可以立刻用的判断清单
七个问题，中三个以上就该用 Workflow：
| # | 问题 |
|---|---|
| 1 | 我能画出完整流程图吗？ |
| 2 | 每一步的输入输出能写清楚吗？ |
| 3 | 出问题时我需要能复现吗？ |
| 4 | 我需要预先审核每一步吗？ |
| 5 | 成本必须可预测吗？ |
| 6 | 用户能接受"每次行为略有不同"吗？（答"不能"→Workflow） |
| 7 | 我是否只是觉得"Agent 更酷"？ |
十一、常见误区
误区一：不上 Agent 就是落后。
恰恰相反。生产环境里最稳的系统用的是最朴素的组合模式。复杂度是成本，不是卖点。
误区二：Workflow 不叫 AI。
Workflow 里每一步照样是模型在判断，只是"走哪条路"由代码决定。它是 AI 应用的一大类，而且是最可靠的那一类。
误区三：Agent 更智能所以效果更好。
不一定。Agent 的自由度带来不可预测性；在步骤固定的任务上，Workflow 的准确率往往更高，因为它不会"临场发挥"。
误区四：用了 Agent 框架就算 Agent。
框架只是把循环、工具、上下文管理封装好了。如果流程里模型根本没在做判断，那你用的是 Workflow 套了层框架的皮。
误区五：先做 Agent，不行再降级。
顺序反了。降级比升级难得多——一旦业务逻辑长在模型的自由决策上，想改成固定流程等于重写。从简到繁，别反过来。
十二、下一篇
边界讲完了。但有一种说法一直很流行，需要单独拆掉：
「Agent 不就是把提示词写长一点、让它多想想吗？」
下一篇正面回答这个问题，并讲清一个更实际的差异：为什么有些系统看起来像 Agent，实际上只是会演戏的 Chatbot。