Workflow、Tool Calling 和 Agent 的决策边界
提出问题
很多团队讨论 AI 自动化时，会把 Workflow、Tool Calling 和 Agent 混成一个问题：模型能不能自己调用工具完成任务。
真正的工程判断不是“要不要 Agent”，而是“控制权应该放在哪里”。有些流程应该由状态机控制，模型只负责局部判断；有些任务只需要模型调用一个受控工具；只有当下一步确实依赖观察结果、路径无法提前列清，并且系统已经具备状态、权限、确认和恢复能力时，才应该进入 Agent。
场景
看一个企业工单处理系统。
客户提交工单：
我们这个月的账单金额比上个月高很多，帮我查一下原因。如果是套餐升级导致的，请生成一条给客户成功经理的跟进任务；如果是误扣费，请帮我申请退款。
这个请求里同时出现三种自动化形态：
如果把整件事都做成 Workflow，异常样本会越来越多：有的涨价来自套餐升级，有的来自席位增加，有的来自优惠过期，有的来自人工调整。固定分支很快膨胀。
如果把整件事都交给 Agent，它可能把“申请退款”理解成直接退款，也可能在证据不足时扩大查询范围，甚至在没有确认的情况下创建多个任务。
更稳的做法通常是组合：
Workflow 控制主流程，Tool Calling 读取事实或执行小动作，Agent 只处理“证据路径不固定”的子任务。
分析问题
问题类型
三者的差别可以用“谁决定下一步”来理解。
还可以按任务类型拆：
Tool Calling 不是 Agent 的同义词。一次模型调用工具，可以只是 Workflow 的一个节点。Agent 也不等于“能调用工具”，而是系统允许它根据观察结果自主决定后续步骤。
收益和成本判断
Workflow 的收益是可预测：
- 状态、节点、失败分支和责任人清楚。
- 权限、审批、审计和 SLA 容易落地。
- 节点可以独立重试，成本和延迟可控。
- 适合高频、稳定、强合规的业务流程。
Tool Calling 的收益是连接真实系统：
- 模型可以读取实时数据，而不是凭记忆回答。
- 工具参数和返回值可结构化。
- 低风险动作可以自动化。
- 工具调用可以纳入权限、确认、审计和 Eval。
Agent 的收益是处理动态长尾：
- 能根据工具结果调整下一步。
- 能在信息不完整时探索证据路径。
- 能覆盖规则难以穷举的异常样本。
- 能把多轮查证、生成和验证串成一个任务。
成本也按这个顺序上升。Workflow 需要状态机和任务日志；Tool Calling 需要工具契约、runtime、权限、幂等和错误 schema；Agent 还需要目标边界、计划状态、checkpoint、循环检测、回放、恢复和过程 Eval。
所以不要用 Agent 解决 Workflow 已经能稳定表达的问题，也不要用自由文本回答代替应该由 Tool Calling 读取的事实。
列举方案
方案阶梯
可以按控制权逐级开放。
第一层是规则、表单和查询。账单金额差异可以先用确定性 SQL 和业务规则找出明显原因。
第二层是 prompt 节点。模型只负责把已知事实解释成用户能读懂的文字。
第三层是 Prompt + Schema。模型输出结构化原因、风险等级、建议动作，再由程序校验。
第四层是 Workflow。固定执行“读取账单 -> 对比变化 -> 生成解释 -> 人工确认 -> 写入结果”。
第五层是 Workflow + Tool Calling。模型或程序在固定节点调用 get_invoice_items、get_plan_change_history、create_followup_task 等工具。
第六层是受控 Agent 子任务。只有当固定证据不足时，允许 Agent 在有限工具集内动态查证，例如查询最近合同、工单和沟通记录。
第七层是 Agent 编排。复杂任务可以拆成 planner、executor、reviewer，避免一个模型同时规划、执行和自评。
第八层是 Agent Ops。生产 Agent 需要回放、Eval、监控、预算、人工接管和恢复演练。
什么时候 Workflow 足够
以下情况优先用 Workflow：
- 步骤顺序固定。
- 分支条件能提前列清。
- 工具调用集合固定。
- 失败节点明确，能独立重试。
- 输出会写入业务系统或触发审批。
- 业务要求强审计、强 SLA 或强责任链。
在账单工单里，退款申请、审批流转、任务分派、通知发送，都应该由 Workflow 控制。模型可以生成建议，但不应该自由决定这些状态如何流转。
什么时候 Tool Calling 足够
以下情况只需要 Tool Calling，不需要 Agent：
- 用户只需要查询一个或少数几个业务对象。
- 工具调用顺序固定或很短。
- 模型只负责从自然语言中抽取参数。
- 工具结果足以直接生成回答。
- 失败后可以追问、重试或转人工。
- 工具动作低风险，或已经有确认和幂等。
例如“查一下订单 E20260509018 的发票状态”，用 get_invoice_status 就够了。没有必要让 Agent 规划多步任务。
什么时候才需要 Agent
以下情况才考虑受控 Agent：
- 用户目标开放，需要系统拆解步骤。
- 需要查询哪些信息无法提前确定。
- 工具结果会改变下一步计划。
- 异常样本很多，Workflow 分支会快速膨胀。
- 任务可能跨多轮或长时间运行。
- 系统已经具备权限、预算、checkpoint、幂等和回放。
- Agent 输出先作为证据包、建议或草稿，而不是直接执行高风险动作。
在账单场景里，“查清复杂账单异常原因并整理证据”可以是 Agent 子任务；“退款生效”必须是审批 Workflow。
决策判断
方案选型表
反模式
第一种反模式：把 Tool Calling 当成 Agent。
模型调用了一个工具，不代表系统就进入 Agent。很多工具调用只是 Workflow 的一个节点，仍然应该由程序决定流程和状态。
第二种反模式：看到多步骤就上 Agent。
多步骤不等于动态路径。固定步骤用 Workflow 更便宜、更稳、更容易恢复。
第三种反模式：让 Agent 执行高风险终态动作。
退款、改权限、删除、发布和对外承诺应该进入确认或审批流。Agent 可以准备证据和草稿，但不应该绕过责任链。
第四种反模式：把 MCP 当成治理层。
MCP 解决工具暴露和客户端复用，不自动解决权限、确认、幂等和审计。没有 runtime 的 MCP Server 只是更标准地暴露风险。
第五种反模式：没有状态却允许长任务。
Agent 如果没有计划状态、动作日志、checkpoint 和恢复策略，中途失败后只能猜自己做过什么。
第六种反模式：用更长 prompt 代替控制边界。
“请谨慎、不要越权、不要重复执行”不是边界。边界必须由工具 runtime、Workflow、权限系统和确认流程执行。
工程清单
- 场景边界：任务是固定流程、单次工具调用，还是动态探索。
- 控制权：下一步由程序、模型工具选择，还是 Agent 计划决定。
- 工具分级：查询、写入、高风险工具是否分开。
- 契约设计：工具 name、description、input、output、error schema 是否明确。
- Runtime：权限、timeout、retry、幂等、审计和脱敏是否统一。
- Workflow：固定步骤、状态、失败分支、人工队列是否可见。
- Agent 状态：目标、计划、动作、产物和预算是否持久化。
- 执行预算：步数、时间、token、工具调用次数和费用是否有限制。
- 人工确认：哪些动作必须确认，确认界面是否展示证据、参数和影响。
- 回放恢复：能否复现工具结果、模型版本、计划变化，并从安全断点继续。
- Eval：是否覆盖工具选择、参数质量、plan drift、loop、恢复和最终结果。
- MCP 判断：是否真的需要跨客户端复用，是否已有稳定契约和统一 runtime。
结论收束
Workflow、Tool Calling 和 Agent 的核心区别，是控制权和状态责任。
Workflow 适合稳定流程，Tool Calling 适合读取事实和执行受控动作，Agent 适合路径动态的查证和规划。生产系统通常不是三选一，而是组合使用：Workflow 控制主流程，Tool Calling 连接业务系统，Agent 只在必要的动态子任务中工作。
判断边界时先问三个问题：下一步能否提前确定，动作是否有副作用，失败后能否恢复。只要答案不清楚，就先把控制权留给 Workflow 和 runtime，而不是交给开放 Agent。