Appearance
Q66 · 什么时候工作流比 Agent 更合适？
客服系统收到一句话：“订单 A123 的耳机有杂音，帮我提交检测申请。”系统要查订单、核对售后规则、取得用户确认，再创建检测工单。这几个动作事先就能列清，顺序和失败后的处理也能写成规则。此时把“下一步做什么”每次都交给模型重新决定，通常没有额外好处，却会增加调用、等待和误操作的机会。
这里的工作流是应用预先规定步骤与分支，运行时按条件走其中一条路；Agent 则让模型根据当前目标和反馈，动态选择下一步、工具及参数。它们都能用大语言模型（LLM，即根据输入生成文本或结构化内容的模型）和外部工具。区别在于谁控制下一步。Anthropic 与 LangGraph 的官方材料都用“预设代码路径”和“动态决定过程及工具”区分两者。Anthropic：Building effective agents · LangGraph：Workflows and agents
术语与本文的具体数据
| 词或记号 | 在这里是什么意思 |
|---|---|
| 工作流（workflow） | 事先画好步骤、条件和异常出口的业务执行过程。条件分支、循环、并行和人工暂停都可以是工作流的一部分。 |
| Agent | 由模型根据任务与中途结果决定接下来调用什么工具、是否再查资料或何时回答的执行过程。应用仍要限制可用工具和边界。 |
| 固定步骤 / 显式条件 | 程序规定“先核订单，再核规则”；或规定“订单不属于本人就停止”。“固定”指可走的路径预先定义，未必每次走同一条。 |
| 工具 | 应用提供给模型或工作流的外部能力，例如“查订单”“建检测单”；模型提出调用后，真正访问数据库或接口的是应用。 |
| 状态 | 一次处理过程中记录的事实，如订单归属、政策版本、用户是否确认、工单号；后续步骤据此判断。 |
| 副作用 / 幂等 | 建单会改变外部系统，属于副作用；幂等指同一业务请求重复送达，也只产生一张有效工单。 |
| 人工节点 | 流程停下，向有权限的人展示证据，让其确认、拒绝或补资料后再继续。 |
u7、A123 | 假设的当前用户与其声称的耳机订单号。系统必须实际查验归属，不能只相信用户话术。 |
P2、R7、T900 | 本例虚构的售后政策版本、这次建单请求的唯一业务编号、成功创建后的检测工单号。R7 用于查重和故障后对账。 |
| 延迟 / token 成本 | 用户等到结果的时间 / 模型处理输入输出文本的计费量。工具与人工处理也各有成本，不能只比较 token。 |
下文的售后规则是教学假设：A123 于 2026 年 9 月 10 日签收；今天是 2026 年 9 月 20 日；生效的 P2 允许签收后 30 天内就故障现象提交检测申请，但不保证检测通过、维修、换货或退款。用户 u7 已明确说“帮我提交”，这构成建检测单的意图，仍需服务端核实订单归属和规则。T900 只是申请受理编号，不代表售后结果。
看同一笔申请怎样走完
图中的绿色主线只表示各项检查通过后才能走的路；从“检查规则”向下的分支表示资料不清时暂停主线，不能一边补查一边继续建单。图只放关键动作，实际系统还有身份校验、用户意图核对、故障恢复和审计记录。
正常路径：已知条件用工作流执行
- 核身份与订单。 应用先确认当前会话对应
u7，用有权限的订单接口查询A123。接口返回耳机订单、签收日期 9 月 10 日，且订单归u7所有；若缺少任何一项，就不能继续使用客户自行报出的日期或归属。 - 查当前规则。 应用读取生效的
P2，用已验证的签收日期计算：从 9 月 10 日到 9 月 20 日为 10 天，落在假设的 30 天申请窗口内。规则还要求记录故障现象“耳机有杂音”。这里的结论仅是“可提交检测申请”，不能偷换成“应退款”。 - 核对动作并建单。 确认用户请求的是“提交检测申请”，再调用建单接口。应用给这次业务动作附上
R7；接口按R7查重并创建一张检测单，返回T900。应用将T900和“等待检测结果”回复给用户，同时记录政策版本与检查依据。
这三步可以由普通程序、状态机或编排框架实现。若用户表述很口语化，也可以在指定位置调用一次模型，把“左耳有电流声，想售后”归为“故障检测申请”并抽取描述；归类结果必须经过校验，最终能否建单仍由已定义的条件控制。工作流里用了 LLM，不会因此自动变成 Agent。LangGraph 官方的工作流示例也包含模型分类、条件路由、检索和人工审核。LangGraph：Thinking in LangGraph
异常路径：停止、补查和人工分别有出口
如果订单接口返回 A123 属于另一位用户，工作流立即停止并给出适当提示；不能让模型猜“可能是家人的订单”并越权查询。若 P2 缺失或与订单适用规则冲突，系统先暂停建单，检索可信规则或请求人工确认；检索不到依据时保持“待核实”，不应让模型编出一个期限。
另一类难点是建单接口超时：请求也许已经成功，只是返回丢了。把超时直接解释成“未创建”再发一次，可能产生两张工单。应用先用 R7 查询是否已有结果；找到 T900 就返回该编号，确认没有创建且接口支持幂等键时才按策略重试；仍无法确认则进入待对账或人工处理。工具调用失败与业务拒绝是不同状态，不能统一写成“再试三次”。这类处理详见 Q39：工具调用失败时，Agent 应该怎么处理。
为什么此时工作流更合适
判断依据是业务路径能否在上线前写清并验证，而不是任务看起来“聪不聪明”。同一个售后问题，可以按下面几项逐一检查。
| 判断维度 | 本例中偏向工作流的原因 | 若改用自主 Agent，需要多解决什么 |
|---|---|---|
| 步骤是否可枚举 | 查归属、查政策、建单和异常出口都已知 | 模型每轮重新选择动作，却没有新路径可发现 |
| 规则是否可明确校验 | 订单归属、签收日和政策窗口可由系统核验 | 模型可能误读政策或跳过一个检查；程序仍得复核 |
| 写操作的风险 | 建单需要授权、查重、留痕和故障对账 | 动态工具调用不能替代权限检查与幂等保障 |
| 结果是否要可预测、可审计 | 每一步的条件、依据和责任人可在流程中定位 | Agent 路径随中间输出变化，需要额外记录决策和回放 |
| 延迟与费用 | 常规单可少用或不用模型，工具次数有上限 | 多轮模型调用和工具探索通常增加延迟与费用 |
“通常”有前提：复杂工作流可能比一个简单 Agent 更慢、更贵；模型调用一次也有随机性；Agent 可以被限制步骤、工具和预算。Anthropic 的建议是从能满足需求的简单方案开始：明确定义的任务更适合工作流的可预测性和一致性，开放任务才更值得承担 Agent 的灵活性、延迟与成本。Anthropic：Building effective agents
因此，多步程序不自动叫 Agent。预先写好“先查订单再查规则”的流程，即使包含十步、条件分支、重试、并行查询与人工审核，下一步仍由代码设定。相反，若模型读到维修史后自主决定先查质检知识库、再问用户故障出现频率、接着调取上次工单，路径事前难以穷举，就更接近 Agent。进一步比较见 Q22：什么是 AI Agent？它和传统 AI 应用的区别是什么？。
模糊问题怎样与固定主线混用
设同一个 u7 改口说：“A123 上次修过还是有杂音，我现在该怎么办？”订单归属仍可按固定步骤核验，但下一步可能取决于上次维修记录、质检结论、现行政策和用户的新症状。可以让一个受限的 Agent 只负责补查与整理证据：它能选择查维修史和售后知识库，必要时向用户追问；只读、限次数、限时，并给出所查记录的编号及尚不确定之处。它不能自行写入退款或换货结果。
随后固定工作流接管：核查证据和适用规则；证据足够且只是检测申请，走已授权的建单动作；政策冲突、身份异常或涉及退款裁量时，暂停交人工。人工确认后也要由应用重新核验权限并执行写操作。Anthropic 将路由、提示链和 Agent 视为可组合的模式；LangGraph 同样展示在显式流程中设置人工审核节点。Anthropic：Building effective agents · LangGraph：Thinking in LangGraph
这种混用把“理解不清楚的问题”交给模型，把“允许做什么和怎样安全落地”留在可检查的规则里。但人工并非所有问题的万能兜底：应明确待审核队列、责任人、超时处理和用户告知，否则请求可能无限等待。Agent 补查的来源也可能过期或无权限；系统要保存引用、版本和查询权限，并在证据不足时停止，而不是把流畅的文字当证明。
选型前怎样验证，而不凭感觉
先收集真实问题，将“常规提交”“订单不属于本人”“政策冲突”“建单超时”“旧维修记录缺失”等分别做成测试样例。对同一批样例比较：合法申请成功率、越权或重复建单次数、错误政策引用率、人工转接率、平均与高分位等待时间、模型及工具成本。高分位等待时间指慢请求有多慢，例如 95% 的请求不超过多少秒；只看平均值会掩盖少数很慢的补查路径。
如果常规单占多数，工作流能覆盖它们，并让异常安全停住，优先上线工作流。若大量请求的下一步确实依赖难以枚举的新信息，且 Agent 在同一批样例里提高了正确处理率，再把 Agent 放进明确边界的分支。无论哪种方案，都要测权限、幂等、误判、重试和人工接管；“Agent 有自主性”不是放弃工程控制的理由。
面试时可以这样说
当步骤和判断条件能事先列清、结果需要稳定可审计，尤其涉及授权和建单等写操作时，我会优先用工作流。它可以有分支、循环，也可以在某个节点用模型理解用户的话，但下一步仍由明确的规则控制。比如耳机售后申请，固定核订单归属、签收日和政策，再用幂等编号建检测单；身份不符停止，政策冲突或结果不明交人工。只有用户问题开放、必须根据中间信息动态决定查什么时，我才让 Agent 在受限范围内补查，然后让工作流或人工做最终写操作。选型还要用成功率、错误率、延迟和成本来验证。
面试官若追问“工作流能不能循环？”可以答：能，预设重试或“缺材料→请用户补充→继续”都是循环；区别是循环条件和可走出口由应用事先定义。若追问“Agent 一定比工作流贵吗？”应答：不一定，取决于模型次数、工具耗时和流程复杂度；对路径清楚的高频任务，工作流通常更容易限制调用次数和成本，但仍要实测。若追问“加一个分类模型算 Agent 吗？”应答：不算，分类模型只负责某个预定节点，后续路径仍由显式条件决定。
资料依据
- Anthropic Engineering：Building effective agents：工作流与 Agent 的定义、选简单方案、延迟与成本权衡，以及模式组合。
- LangGraph：Workflows and agents：预设路径与动态过程的区分，以及 Agent 的工具循环。
- LangGraph：Thinking in LangGraph：模型分类、条件路由、状态和人工审核组合的官方示例。