Chat、Workflow 还是 Agent？小白也能看懂的 AI 应用选择指南

很多 AI 产品都喜欢把自己叫作 Agent。

有的只是给聊天框接了几个按钮，有的会根据问题选择一条预设流程，还有的真的会观察结果、改变计划并持续执行。它们看起来都“比普通聊天更自动”，但工程上并不是同一种东西。

如果只记住一句话，请记住：

区分 Chat、Workflow 和 Agent，关键不是看它有没有聊天框、会不会调用 API，而是看谁决定下一步。

这篇文章不假设你了解模型、Function Calling 或 Agent 框架。我们从一个生活例子开始。

同一个任务，三种做法

假设你说：“帮我安排一次周末旅行，预算 3000 元，希望轻松一点。”

Chat：你问一句，它答一句

Chat 会给你几个目的地、行程建议和注意事项。看完之后，由你决定要不要继续问天气、比较酒店或调整预算。

你决定下一步 → AI 回答 → 你再决定下一步

AI 负责提供信息，人负责推进任务。

Workflow：程序提前写好路线

Workflow 可能被设计成：

读取出发地 → 查询天气 → 搜索交通 → 筛选酒店 → 生成行程

如果下雨，就走“室内景点”分支；如果机票超过预算，就改查高铁。流程可以有很多条件，但这些条件和允许走的路径，通常由开发者提前写好。

Agent：给目标，让模型根据现场选路

Agent 拿到的是目标、工具和边界。它可能先确认出发地，再查天气；发现目的地暴雨后，换一个城市；发现酒店超预算后，调整住宿区域；信息足够时自行停止并汇报。

目标 → 观察 → 选择动作 → 获取结果 → 再判断 → 完成

这三种方式没有谁天然更高级。它们只是把不同程度的控制权交给人、程序或模型。

先纠正一个误会：它们不完全在同一维度

日常讨论常把 Chat、Workflow 和 Agent 并列，但严格说，它们回答的问题不同：

概念	主要回答
Chat	人如何和系统交流？
Workflow	程序如何预先编排步骤？
Agent	谁在运行时决定下一步？

因此，一个聊天框背后可以接普通模型，也可以接 Workflow 或 Agent。一个 Agent 也可以完全没有聊天界面，在后台定时运行。

常见组合包括：

• Chat UI + 普通模型：你问，它答。
• Chat UI + Workflow：你发一句话，后台启动固定流程。
• Chat UI + Agent：你给目标，后台自主调用工具并持续执行。
• Workflow + Agent：外层流程固定，某个复杂节点交给 Agent 探索。

这也是为什么“它有聊天框”从来不是判断 Agent 的依据。

Chat：人保持在决策回路里

Chat 的核心不是“模型能力弱”，而是人持续拥有推进权。

它特别适合：

• 解释概念、头脑风暴和方案讨论；
• 写一段文案、总结一份材料；
• 需要人逐步确认的高风险任务；
• 问题短、目标会随着对话逐渐清晰的场景。

Chat 的优势是自然、透明、容易纠偏。你随时能说“不是这个意思”或“先别继续”。它的限制也很明显：任务一长，人就要不断复制结果、发起下一步、检查是否遗漏。

所以 Chat 不是“低级 Agent”。人在环内本身就是一种控制和安全设计。

Workflow：步骤由程序预先定义

Workflow 像一条流水线。输入从一个节点流向下一个节点，代码决定允许有哪些分支、重试几次、什么时候失败、最后输出到哪里。

例如，一个解题产品可能这样工作：

图片 → OCR → 题型分类 → 对应解法模板 → 格式化 → 返回结果

即使“题型分类”由模型完成，只要分类结果映射到开发者预设的几条路径，它仍然更接近 Router + Workflow，而不是完整 Agent。

Workflow 适合：

• 规则稳定、频率很高的重复任务；
• 每一步都能清楚验证的处理链；
• 审批、计费、数据导入等要求可预测性的场景；
• 错误代价高，不能让模型自由尝试的操作。

它的代价是灵活性需要提前编码。遇到未覆盖的新情况，系统只能失败、转人工，或者继续增加分支。流程越多，维护和测试的组合也越多。

Agent：模型拥有有限的运行时决策权

Agent 的区别，不是“能调用工具”，而是模型会根据当前目标、上下文和工具结果，决定下一步做什么。

一个最小 Agent 通常包含：

• 目标与指令：要完成什么，什么不能做；
• 上下文与状态：已经知道什么，已经做过什么；
• 工具：搜索、读取文件、调用 API 或执行其他动作；
• 决策循环：观察结果后继续、换策略或结束；
• 停止条件：什么时候算完成，什么时候必须求助；
• 护栏：权限、预算、时间、审批和验证。

Agent 适合路径难以提前穷举的任务，例如开放式调研、复杂代码修改、故障排查，以及中间结果会持续改变计划的工作。

它的代价同样来自这份自由：运行时间和成本会波动，结果不完全可复现，目标理解错时还可能非常高效地做错事。因此，Agent 越自主，外层边界越要明确。

从 Router 到 Agent Loop：不是开关，而是光谱

现实系统很少刚好落在两个极端。更实用的理解是一条决策权光谱：

形态	模型决定什么	程序决定什么
固定 Workflow	节点内生成内容	全部步骤和顺序
Router	选择预设类别	类别对应的固定路径
工具自动匹配	在候选工具中选择一次动作	候选范围和后续流程
受约束 Agent Loop	根据结果持续选择动作并判断结束	权限、预算、工具和硬性门禁

回到前面的解题系统：

• 模型只判断题型，代码进入对应模板：Router / 动态 Workflow。
• 模型可以从计算器、OCR、检索工具中选一个：工具自动匹配，已有部分 Agent 特征。
• 模型能根据工具结果继续调用、重试、换策略并自行结束：受约束 Agent Loop。

真正值得问的不是“它是不是 Agent”，而是：我们具体把哪些决策权交给了模型？

怎么选择：先看不确定性，再看错误代价

做选择前，问四个问题：

1. 下一步能否提前写清楚？
2. 中间结果是否经常改变后续计划？
3. 做错一次的代价有多大？
4. 是否允许系统在无人看管时继续？

可以得到一个实用判断：

只需要回答，且人愿意持续推进
→ Chat

路径稳定，结果必须可预测
→ Workflow

路径未知，需要根据现场调整
→ Agent

骨架稳定，但局部问题需要探索
→ Workflow + Agent

场景	更合适的起点	原因
解释一段报错	Chat	人能立刻判断答案是否有用
每月生成固定财务报表	Workflow	步骤稳定、需要可复现
调研陌生市场并整理证据	Agent	搜索路径取决于中间发现
发票报销审批	Workflow	金额和权限不该自由探索
修复跨文件代码问题	受约束 Agent	需要读代码、运行测试、根据结果调整
客服系统	Hybrid	常见问题固定路由，复杂问题再交给 Agent 或人工

一个稳妥原则是：能用 Workflow 可靠解决的问题，不要为了“更智能”强行改成 Agent。 Agent 应该用来消化真正无法提前编码的不确定性。

六个常见误区

“调用 API 就是 Agent”

不是。程序按固定顺序调用三个 API，仍然是 Workflow。

“有工具就是 Agent”

工具只是手脚。模型是否能根据工具结果继续决策，才决定它有多少 Agent 性。

“有 Router 就一定是 Agent”

如果 Router 只把输入映射到预设路径，它仍是动态 Workflow。路由可以由规则或模型完成。

“多个 Prompt 就是 Multi-Agent”

多个角色 Prompt 可能只是模板切换。是否存在独立状态、目标、执行和协调，才是更关键的问题。

“Agent 一定比 Workflow 高级”

支付、审批和数据迁移往往更需要确定性。自由度不是成熟度。

“自动化越多越好”

自动化会同时放大正确目标和错误目标。高风险动作需要权限、审批、回滚和审计。

为什么生产系统通常是 Hybrid

成熟系统往往把两者组合起来：

固定外壳：鉴权 → 输入校验 → 预算 → 审批 → 写库 → 通知
                         ↓
探索内核：搜索 → 工具选择 → 拆解 → 重试 → 生成候选结果

外层 Workflow 负责确定性和合规，内层 Agent 负责处理不确定性。最终结果再回到固定流程中验证和落库。

一句话概括：

Workflow 提供轨道，Agent 在轨道允许的范围内寻找路线。

最后：不要先问“能不能做 Agent”

先问：这个任务的未知部分在哪里？谁应该决定下一步？错误发生时，谁能发现并阻止它？

如果答案是“人持续判断”，用 Chat。如果路线可以提前定义，用 Workflow。如果中间结果确实会改变行动，而且这部分自由值得它带来的成本和风险，再使用 Agent。

下一篇：Agent 不只一种：从软路由、工具自动匹配到自主循环，再用 Pi 跑起最小 Agent，会继续拆解 Agent 内部的几种工程形态，并给出一个可运行的最小实践。

延伸阅读：OpenClaw 完全入门指南 · Harness Engineering：AI Agent 时代的新工程范式