Appearance
Q42 · Agent 与 Workflow 中工具调用的差异是什么？
客服助手收到：“订单 A123 能自动退款吗？”无论叫它 Agent 还是 Workflow，都要查订单状态和现行政策，才能给可靠答复。真正的差别是：谁决定这一步之后调用哪个工具。如果程序事先规定“查订单 → 查政策 → 判断资格 → 回答”，这是一个 Workflow；如果模型先看当前问题与工具结果，再决定下一步查订单、查政策或请求补充信息，这是 Agent 式控制。两种方案调用的可以是同一套后台服务。
这里沿用一个假设业务例子，不是现实退款政策：咨询日为 2026 年 9 月 25 日；A123 于 9 月 20 日签收，订单系统显示已拆封。现行政策 v3 规定“签收后 7 天内且未拆封，可自动退款；已拆封需人工核验”。因此不管选择哪种控制方式，正确结论都是“A123 不能自动退款，需人工核验”。用户只问资格，没有授权系统执行退款。
术语与符号
| 术语 | 直白解释 | A123 例子中的对应物 |
|---|---|---|
| Workflow / 工作流 | 程序预先定义可能走的步骤、分支和顺序，运行时按这些规则前进 | 程序规定先查订单、再查政策、再判断 |
| Agent / 智能体 | 在应用规定的工具和边界内，模型根据当前问题与结果动态选择后续动作 | 看见“已拆封”后决定还要查现行政策 |
| 工具 | 应用提供给流程的查询或操作能力 | 查订单、查政策、执行退款 |
| 工具调用请求 | 模型输出“想用某工具及参数”；不是已完成操作 | 提议 get_order(order_id="A123") |
| 编排 / 控制流 | 决定先后顺序、条件分支、重试与结束的规则 | 决定先查谁、失败后做什么 |
| 状态 | 流程到当前为止掌握的事实和执行记录 | 已查到拆封状态、政策版本、哪些工具已调用 |
| 前置条件 | 允许进行某动作之前必须满足的条件 | 查询 A123 前核验登录用户有权查看 |
| 副作用 | 操作会改变外部系统，而不只是读取 | 真正执行退款会改变交易状态 |
| 停止条件 | 流程何时不再调用工具并返回结果或错误 | 证据齐全、服务不可用、次数或时限已满 |
本题中的 get_order 只读订单事实，get_refund_policy 只读现行规则，issue_refund 则代表真正执行退款。名称只是示例，不是某框架的固定 API。Agent 与 Workflow 的比较不能落在“有没有工具”上：两者都能调用工具、都能使用模型，也都可能有条件分支。Anthropic 的架构说明把 Workflow 概括为预定代码路径，把 Agent 概括为由模型动态引导过程与工具使用；LangGraph 当前文档也使用同样的区分。Anthropic《Building effective agents》、LangGraph《Workflows and agents》
同一问题，谁来安排下一步
图上方是程序定顺序：代码里已写好先调用 get_order，再调用 get_refund_policy。图下方是根据结果选下一步：模型先请求查订单，收到“已拆封”后再选择查政策，最后组织回答。图里两边最终都写“回答”，因为此例证据足够时两者应给出相同的业务结论。图只展示这个请求实际经过的路径，不表示 Workflow 不能分支或 Agent 一定每轮都要调用两次模型。
底层工具调用机制也很相近。以模型调用工具为例，应用发送工具定义，模型可能返回调用请求，应用核验并执行，把结果回传给模型，然后继续生成或请求下一个工具。OpenAI 的函数调用文档明确把它描述为应用与模型之间的多步交互；Spring AI 当前文档也说明，模型提出调用，应用持有执行逻辑。模型不会因为被称为 Agent 就自动得到数据库权限。OpenAI 函数调用说明、Spring AI 工具调用说明
Workflow：程序掌握路线图
先看这笔 A123 请求在一条预先写定的工作流里如何执行：
- 程序从已登录用户的请求提取 A123，先验证该用户可以查询这笔订单。验证失败就结束，不能把订单数据交给模型。
- 程序调用
get_order("A123")。工具返回 9 月 20 日签收、已拆封；若返回超时或无权限，程序走事先写好的失败分支。 - 程序调用
get_refund_policy(2026-09-25)，取得现行v3和生效日期。两项查询在业务上相互独立时也可以按预定规则并行，不是只能串行；图采用串行顺序便于看清控制权。 - 程序按政策条件判断：5 天在期限内，但已拆封，所以
auto_refund=false，处理建议为人工核验。模型若参与，主要负责把程序已核实的结论与依据写成易懂的回复；它不负责执行退款。
这条路径的“固定”是指所有可走的路线由开发者预先规定，不等于永远只有一条直线。程序可以写出“订单工具失败则重试一次”“缺政策则转人工”“已拆封则走人工核验”等分支，甚至在某个节点调用模型做分类；只要后续动作仍受预设分支控制，它仍是 Workflow。优点是调用次数和错误路径容易预计、审计与测试；代价是遇到没有预设分支的新情况时，流程只能降级或交给人，不能自行发明一条新路线。LangGraph《Workflows and agents》、Anthropic《Building effective agents》
Agent：模型根据观察选择下一步
再看同一请求在一个受限 Agent 中如何走。应用先只开放两个只读工具：get_order 和 get_refund_policy；高影响的 issue_refund 不在本轮可调用集合内。
- 模型看到“订单 A123 能自动退款吗”，选择请求
get_order(order_id="A123")。应用校验订单号与登录身份后才真正调用订单服务。 - 模型收到“9 月 20 日签收、已拆封”。它根据已知事实判断：还缺现行政策对已拆封商品的规定，于是请求
get_refund_policy(effective_on=2026-09-25)。另一种合理顺序是先查政策再查订单；顺序由本轮观察和可用工具决定。 - 应用校验政策工具参数并取得
v3。模型结合两份结果生成“不能自动退款，需人工核验”，应用再核对关键字段与来源。
Agent 的关键不在“模型是否会说出计划”，而在下一步动作是否真的可以依据上一步结果改变。如果订单结果已经是 forbidden，Agent 应停止而不是查别的来源绕过权限；如果政策缺少生效日期，它可以在允许范围内再查可信资料或请求人工核实。给模型一段“请灵活处理”的提示词，却始终让程序调用固定的两个工具，不会因为措辞而变成动态工具编排。Anthropic《Building effective agents》
动态选择不等于无限自主。应用仍决定可见工具、参数结构、数据权限、最多调用次数与总时限，并可以规定“退款资格问题必须查到现行政策与订单，才允许给结论”。OpenAI 接口支持自动选择、指定某工具、禁用工具和限制可用集合等控制方式；Spring AI 当前工具循环则由应用侧组件执行，直至模型不再请求工具或遇到限制。OpenAI 函数调用说明、Spring AI 工具调用说明
同一维度看差异
| 维度 | Workflow 中的工具调用 | Agent 中的工具调用 |
|---|---|---|
| 下一步由谁决定 | 程序按预先定义的路径、条件和分支决定 | 模型依据问题和中间结果提议下一步，应用设边界并执行 |
| 工具调用顺序 | 对每条分支事先可描述；可以串行或并行 | 在许可范围内随证据变化，调用次数和次序可能不同 |
| 模型的作用 | 可不用模型；也可用于分类、抽取、表述等某个节点 | 通常参与跨步骤决策与工具选择，同时可生成答复 |
| 错误恢复 | 开发者写好超时、重试、降级或转人工分支 | 模型可在允许范围内选择其他办法，但仍要受重试与停止规则约束 |
| 可预测性 | 路径、最坏调用数和审计通常较容易明确 | 能应对更多变体，但路径更难穷举，要记录轨迹并设预算 |
| 适合任务 | 规则清楚、步骤稳定、权限或合规要求强 | 任务开放、资料来源多、下一步难预先穷举 |
Workflow 也能调用模型来选择一个预设分支，Agent 也常运行在预设的图或循环中。实际产品可以混用：外层用固定流程完成身份核验与权限控制；只在“查找不同资料以解释原因”这段低风险任务里使用 Agent；最后再由程序核验结论。不能把某个框架名直接当成架构判断，应看谁有权改变工具顺序与目标。LangGraph《Workflows and agents》
工具失败与权限边界怎样落地
假设政策服务第一次超时。Workflow 的路径可以规定“重试一次；仍失败就回复暂不能核对政策并转人工”。Agent 可在允许范围内尝试可信的政策备份源，但应用要验证备份的版本和生效日期，并对总调用次数和时间设上限；没有可验证的现行政策时，两者都应停止资格判断。Agent 反复用同一参数查同一故障服务，不是更灵活，只是循环浪费资源。Anthropic 在 Agent 实践中也强调通过环境反馈判断进展，并设置最大迭代等停止条件。Anthropic《Building effective agents》
再假设模型请求 issue_refund("A123")。这不在用户“能否退款”的授权范围内。无论外层是 Workflow 还是 Agent，执行层都应拒绝；仅靠 Prompt 写“不要退款”不够。即使某天产品支持自动执行，仍需身份、金额、资格、审批和防重复执行等业务程序约束。模型生成的工具参数形状正确，也不说明它有权操作该订单。OpenAI 与 Spring AI 的工具调用文档均把实际执行放在应用侧，权限由应用负责。OpenAI 函数调用说明、Spring AI 工具调用说明
测试时，两种方案应使用相同输入和相同工具模拟结果：正常 A123、订单无权限、政策超时、政策版本过期、重复工具结果，以及用户突然改问 B456。除最终答案，还要比较工具轨迹是否合理、未授权调用是否被阻断、失败是否停住、延迟和成本。对于政策明确、步骤稳定的退款资格判断，固定 Workflow 通常更容易控制；若确有大量无法预设的资料查找分支，再衡量 Agent 带来的增益是否抵得过额外调用与测试成本。Anthropic《Building effective agents》
面试时可以这样回答
Agent 和 Workflow 都能调用同一批工具，差别在编排权。Workflow 由程序预先规定步骤与分支，例如先查订单、再查政策、满足条件才输出资格结论；模型可以只负责其中的分类或表述。Agent 则让模型根据当前问题和工具结果，动态提出下一步工具调用，应用逐次核验并执行。对 A123 退款咨询，两者都应拿到订单事实和现行政策，给出“已拆封，不能自动退款、需人工核验”；都不能因为模型提议就直接执行退款。Workflow 适合步骤稳定、要求可预测的任务；Agent 适合下一步难穷举的开放任务，但必须限定工具权限、调用次数、失败与停止条件。
如果追问“Workflow 有条件分支，是否就成了 Agent”，可以回答：不是。程序预先写出的条件分支仍是 Workflow；关键在模型能否根据观察动态决定后续工具路径。若追问“Agent 能否直接执行任何工具”，应回答：不能，模型只提出调用，应用决定开放集合、验证参数和权限，并实际执行。两者可以组合使用，不存在必须二选一的框架限制。