用「谁决定下一步」判断该用 AI 工作流还是 AI 智能体

把 AI 接进业务流程时，最常见的分歧是：这件事该用工作流编排，还是交给智能体自己决定？两者都能生成文字，也都能调用检索之类的工具，所以只对着功能清单比较，往往看不出差别。真正有用的判断轴只有一条：下一步做什么，是开发者事先写死的，还是 AI 根据中途结果自己选的。

这篇教程面向正在设计自动化流程的开发者与产品负责人，用「根据公开 FAQ 起草答复」这个例子，把两种方式的边界、选择方法、混合设计、以及「完成 / 停止 / 失败」的状态划分讲清楚。文中所有示例都是说明用的设计草案，不涉及任何具体产品的接口调用，也没有经过生产环境验证；涉及具体产品的价格、配额、可用功能，请以该产品官网当前信息为准。

准备工作

在动手设计之前，先把下面几样东西准备好。它们不需要写代码，但缺了任何一样，后面的判断都会变成拍脑袋。

一个具体的自动化任务。不要选「客服自动化」这种大词，选「收到用户提问后，查公开 FAQ，起草一段答复」这种能画出流程的粒度。
一份可检索的资料范围。例如公开 FAQ 页面清单。范围必须能明确列举，否则无法限制检索边界。
一份允许调用的工具清单。例如「按关键词搜索 FAQ」「按 URL 读取页面内容」。清单之外的操作一律不允许。
成功与失败的判定标准。要能回答「凭什么说这次输出是合格的」，而不是「看起来还行」。
预算与时限的初步上限。包括最多调用几次工具、最长跑多久、最多消耗多少用量。具体数值按实际业务和预算定，不要照抄别人的数字。

另外要提前接受一个事实：把流程固定下来，并不等于 AI 的输出每次都一样。流程的走向可以确定，但生成内容的准确性需要单独验证。这两件事必须分开检查。

操作步骤

第一步：确认「下一步」由谁决定

先不要看产品文档里的名词，直接问自己：在这个任务里，AI 有没有权力决定「接下来做什么」？

如果 AI 只在开发者画好的路径上执行，路径由代码决定，那就是工作流。
如果 AI 拿到目标和上一步的结果后，自己挑选下一步动作或工具，那就是智能体。

注意两个常见误判：流程里出现了 AI 调用，不代表就是智能体；流程里有循环和重试，也不代表就是智能体。判断标准只有一个——分支的选择权在代码手里，还是在模型手里。不同产品对这两个词的用法并不统一，所以不要靠名字下结论，去看实际是哪一环由 AI 决定。

打个比方：工作流像一张连换乘站都标好的行程表；智能体像你只告诉它目的地和限制条件，路线由它现场规划。

第二步：用对比表定位自己的场景

比较维度	AI 工作流	AI 智能体
下一步处理	从预先设定的路径中选择	AI 观察中途结果后选择
擅长的工作	输入会变，但工序基本相似	要查哪些地方、需要哪些步骤，随输入大幅变化
容易追踪的东西	失败发生在哪个环节	选了哪些工具，以及每次调用的结果
设计时的风险点	分支遗漏、非法输入、失败路径缺失	权限过大、缺少停止条件、判断错误层层累积

工作流同样可以有分支和循环。比如让 AI 先给问题分类，程序校验分类结果，再走对应的固定路径——这依然是工作流，因为走哪条路由代码决定。

第三步：工序能写清楚，就先做工作流

以「接收提问 → 查公开 FAQ → 起草答复」为例。如果一开始就把问题限定为「营业时间」和「使用方法」两类，整个流程可以完全固定下来：

接收提问，校验输入。为空则要求用户补充。
由 AI 对问题进行分类。
程序校验分类结果。若为范围外的值或格式损坏，转人工。
按分类结果获取对应的公开 FAQ 内容。
基于检索到的依据起草答复。
由人工复核内容。

这里 AI 只负责两件事：分类和起草。而「分类为营业时间就去取这份 FAQ」这条路由，是程序写死的。

分类结果的校验非常关键。假设只允许 hours 和 usage 两个值，那么当 AI 返回其他值或格式异常时，不要试图猜测它的意图，直接转人工。还要注意：格式正确不代表分类正确。所以后续环节仍要检查取回的 FAQ 是否真的对得上问题。

工序固定还有一个额外好处：出问题时定位快。取回了不相关的 FAQ，就去看分类和检索环节；FAQ 取对了但答复写错了，就去看生成和依据核对环节。

第四步：调查路径会变，再考虑智能体

把问题换成：「使用步骤在两个公开页面上写得不一样，请确认哪个更新，并据此答复。」这时需要做什么，取决于中途查到什么——比较更新日期、再找别的页面、核对矛盾点，这些下一步动作无法事先穷举。这种场景才适合引入智能体。

但引入智能体不等于把执行权全交出去。一个可控的设计是这样的：

接收目标与限制条件。
AI 提出下一步要查什么。
程序校验：是否在允许范围内、是否超出调用次数、是否超时。
执行被允许的只读工具。
检查结果。若仍需补充调查，回到第 2 步；否则进入第 6 步。
输出带依据的草稿，或转人工。

在这个设计里，检索范围被限定在指定的公开 FAQ 内，可用工具只有搜索和读取。AI 提出的 URL 或操作，必须由程序侧校验，越界的访问直接拦下。结束条件也要提前定好，例如「依据齐备就出草稿」「矛盾无法消解就转人工」。调用次数、耗时、用量的上限，按实际业务量和预算设定。

要意识到代价：智能体因为要自己选步骤和工具，处理时间和成本会随选择而变化。只有当灵活性确实必要、并且你能承担这份波动时，才选它。

第五步：用三个问题做最终判断

问题	回答「是」时该做什么
能先写出正常流程的工序和分支吗？	用工作流把这些工序显式写出来
调查的下一步会因取到的信息而大幅变化吗？	把这段调查交给智能体
能说清判定成功的依据和停止条件吗？	在小范围内试跑并评估结果

如果第三个问题答不上来，那么无论选哪种方式，都不适合扩大自动执行的范围。因为「回答得好就结束」这句话里，谁、用什么标准判断「好」，是空的。

两种方式也可以组合：输入校验、权限校验、转人工这些环节用工作流固定住，只把中间的检索调查交给智能体。这样即使调查环节的自由度提高了，整个流程的出口仍然是确定的。

一个完整示例

下面把前面的设计串成一个可执行的判断与落地流程，仍然以「根据公开 FAQ 起草答复」为例。

场景设定

输入：用户提问文本。
允许的分类值：hours（营业时间）、usage（使用方法）。
允许的工具：按关键词搜索 FAQ、按 URL 读取页面。
输出：带依据 URL 的答复草稿，或转人工。

流程定义

接收提问
  └─ 输入为空或格式不可处理 → 返回原因，请用户重新输入
  └─ 输入有效
       └─ AI 分类
            └─ 分类值不在 {hours, usage} 内 → 转人工
            └─ 分类值合法
                 └─ 检索对应 FAQ
                      └─ 检索工具报错 → 记录为处理失败，不视为「没有答案」
                      └─ 检索成功
                           └─ 核对 FAQ 是否与问题匹配
                                └─ 不匹配 → 转人工
                                └─ 匹配 → 起草答复
                                     └─ 人工复核

如果后续要扩展到「两个页面说法不一致」这类问题，就在「检索成功」之后插入智能体调查段：由 AI 提出下一步查什么，程序校验范围与次数，执行只读工具，检查结果，直到依据齐备或触发停止条件。

状态划分

无论用哪种方式，都不要把「返回了一段文字」当成成功。把结束状态明确拆开：

状态	结束条件	保留什么、下一步做什么
草稿完成	有对应问题的依据，且必要校验通过	保留草稿与依据 URL，交人工复核
需要修正输入	提问为空，或格式无法处理	返回原因，请用户重新输入
需要人工判断	超出范围、依据不足、矛盾未消解	交出已核实的依据与未解决的点
处理失败	检索等工具返回错误	记录失败发生在哪个环节，判断能否重试
中断	用户主动中止，或触及上限	保留已完成环节，停止后续执行

特别提醒：不要把工具报错解释成「FAQ 里没有答案」。取不到资料和取到了但资料里没有答案，后续处理完全不同。同样，不要凭 AI 说的「已完成」判断工具调用成功，要去看程序侧记录的实际结果。检索成功与答复准确，也要分别评估。

验证用例

实现时，把下面这些情况放进同一张表里逐条验证，最容易发现结束条件的漏洞：

输入或状况	期望结果
询问营业时间，且 FAQ 中有依据	产出带依据 URL 的草稿
传入空提问	在调用 AI 和检索工具之前就要求修正输入
AI 返回未允许的分类值	不擅自走默认路径，转人工
检索工具返回错误	不把答复当作完成，记录为处理失败
公开页面矛盾无法消解	不猜测采用其中一方，交出未解决的点
调查中触及次数上限或收到中止指令	停止后续执行，保留中途状态

比较两种方案时，务必使用同一组用例和同一组输入。然后测量：是否产出了带依据的草稿、该转人工的案例是否都转出去了、工具调用次数、处理耗时、用量。在测出数据之前，不要断言哪种方式更便宜、更快或更准确。

注意事项

分支和循环不是智能体的标志。工作流里同样可以有 AI 分类、条件分支和重试。判断依据始终是「谁决定下一步」。
流程固定不等于输出稳定。路径可以确定，但生成内容的准确性必须单独验证。
格式校验不能替代语义校验。分类值合法，分类结论仍可能错，所以后续环节要再核对一次依据是否对得上问题。
权限要收窄。给智能体开放检索时，把可访问范围限定在指定资料内，可用工具限定为只读，AI 提出的 URL 和操作由程序侧校验。
停止条件要提前写。包括依据齐备、矛盾未解、调用次数、耗时、用量上限，以及用户主动中止。
不要把失败当成「没有答案」。工具报错与资料中确实没有答案，是两种不同的状态，处理方式不同。
不要用 AI 的自述判断执行结果。工具是否成功，以程序侧记录为准。
扩展到写操作前先加审批。如果后续要从「起草」扩展到「发送」或「更新数据」，在执行前设置审批环节，明确审批对象与目标，并在执行前重新确认权限。
网络中断可能造成结果不明。此时不要直接重试，先核对执行结果再决定。
中断不会撤销已完成的写操作。已经成功执行的外部操作，不会因为流程中止而回滚。
成本随选择变化。智能体选多少步骤、调多少工具，会直接影响耗时和用量，需要按业务与预算设定上限。

动手的第一步其实很简单：挑一个要自动化的任务，把正常工序和「什么情况下转人工」写在纸上。然后把这些工序分成两类——哪些可以固定，哪些必须看结果再定。分完之后，选哪种方式通常就清楚了。