很多团队第一次接触 Agent，都会产生一种冲动：既然模型已经会思考、会调用工具、会执行多步任务，那是不是可以把原来的自动化流程全部“Agent 化”？
比如用户提交一个报销单，让 Agent 判断类型、读取制度、计算金额、填写系统、提交审批、发送通知。听起来很先进。
但仔细看会发现，其中相当一部分步骤根本不需要“思考”。金额计算有公式，审批权限有规则，提交接口也固定。让 LLM 每次重新决定怎么做，只会增加成本、延迟和不可预测性。
判断一个任务该不该用 Agent，关键不是看它有多少步骤，而是看：执行过程中，到底存在多少无法提前写死的判断。
Agent 的价值，来自“下一步无法提前确定”
Anthropic 对 Workflow 和 Agent 做过一个很实用的区分：Workflow 是由预先定义的代码路径编排模型和工具；Agent 则让模型动态决定自己的执行过程和工具使用。
这个区别比“自动化程度高不高”重要得多。
假设我们要处理一份发票：
读取 PDF → 提取金额 → 校验税号 → 查询订单 → 写入财务系统。
如果每一步都确定，这就是 Workflow。即使其中“从 PDF 提取字段”使用了 LLM，整个系统仍然不需要成为 Agent。
换一个任务：
“帮我调查为什么这个客户突然停止续费，并给出下一步行动建议。”
这时路径很难提前写死。模型可能先查 CRM，再看客服记录；发现客户最近投诉后，又去查产品故障；发现真正的问题是价格，则需要进一步分析合同和历史折扣。
它必须根据中间结果不断决定下一步。
这才是 Agent 真正擅长的地方。
OpenAI 在 Agent 构建指南中也把复杂决策、大量非结构化数据，以及难以维护的复杂规则，列为更适合 Agent 的场景。
所以，一个很简单的判断方法是：
如果你能在开始执行之前，把流程图完整画出来，通常先做 Workflow。
如果很多箭头只能写成“视情况而定”，Agent 才开始有价值。
流程确定时，让 LLM 决策反而是一种浪费
假设公司规定：
订单金额低于 500 元自动退款；
500～2000 元需要主管审批；
超过 2000 元转人工。
这里需要 Agent 吗？
不需要。
因为决策规则已经完全确定。写三个if，比让模型阅读退款政策、理解订单金额、再判断应该走哪条路径更便宜，也更稳定。
很多所谓“AI Agent 项目”的问题，就出在这里：把原本确定性的程序问题，重新包装成概率性的语言模型问题。
模型可能连续一百次都判断正确，但代码可以直接保证这条规则每次一致。
而且 Agent 的自主性不是免费的。它意味着更多模型调用、工具调用、更长执行链路，以及更多可能出错的中间状态。Anthropic 也明确建议从能够解决问题的最简单方案开始，因为 Agent 往往是在用更高的成本和延迟换取灵活性。
因此，流程越稳定、规则越明确、异常越少，固定 Workflow 的优势越明显。
这并不“落后”。
恰恰说明你已经知道问题应该怎么解决。
真正好用的系统，往往是 Workflow 里嵌几个 LLM
现实中的选择通常不是：
“传统代码还是 Agent？”
更常见的是第三种方案：
大部分流程固定，只把真正模糊的步骤交给 LLM。
例如客服工单处理：
接收工单 → 判断用户意图 → 查询订单 → 检查退款条件 → 执行退款 → 通知用户。
这里“判断用户意图”很适合 LLM，因为用户可能写：
“东西我已经寄回去了，怎么钱还没到？”
也可能写：
“算了，不想要了。”
它们都可能对应退款问题，却很难靠关键词规则穷举。
但查询订单、判断是否超过退款期限、计算退款金额、修改数据库，这些事情最好继续交给代码。
于是系统变成：
LLM 负责理解，代码负责执行确定规则。
这种架构往往比“让一个 Agent 从头做到尾”更容易测试，也更容易发现问题出在哪里。
你甚至可以把它理解成公司里的分工：人负责判断那些制度没有覆盖的情况，系统负责执行已经写进制度的事情。
没有必要让经理亲自计算每张发票的税额。
判断“代码还是 LLM”，可以问五个问题
设计一个步骤时，不妨依次检查几个维度。
结果是否存在唯一正确答案？
加减乘除、日期计算、格式转换、权限检查、数据库查询，都应该优先使用代码。
如果答案允许合理差异，比如判断一封邮件的意图、总结投诉原因、评估文本风险，则更适合 LLM。
规则能否清楚写出来？
“金额超过 1000 元需要审批”，用代码。
“判断这个客户的投诉是否已经严重影响合作关系”，很难写成几十条稳定规则，更适合模型参与。
输入是不是非结构化的？
表格中的金额很好处理。
几十封邮件、会议记录、合同、聊天记录，要从中理解含义，LLM 的优势就会出现。
错误结果能不能立即验证？
写代码是一个典型例子。Agent 修改程序后，可以运行测试；失败了，再继续修改。这种“行动—观察—修正”的循环非常适合 Agent。Anthropic 对 Agent 的实践描述也反复强调这种根据环境反馈持续调整的机制。
反过来，如果系统执行错了以后很难恢复，例如直接转账、删除生产数据、签署合同，就不应该轻易把最终权限完全交给 Agent。
下一步是否依赖刚刚得到的新信息？
如果答案是“是，而且分支很多”，Agent 的价值会上升。
如果答案是“否，后面步骤早就知道”，Workflow 通常足够。
最容易犯的错，是从“我要做 Agent”开始设计
比较健康的设计顺序其实应该反过来。
先问：我要解决什么问题？
然后尝试用最简单的代码解决。
规则开始出现语义模糊时，在那个节点加入一次 LLM。
流程出现几个明确分支，就建立 Workflow。
只有当任务需要模型持续观察环境、选择工具、根据结果改变计划，而且你很难提前枚举执行路径时，再把自主权扩大成 Agent。
可以把它想成一条复杂度阶梯：
代码 → LLM 调用 → Workflow → Agent。
不是越往右越先进，而是越往右，系统获得更多灵活性，同时也承担更多成本、延迟、评估难度和风险。
尤其是 Agent。它能够调用工具、修改状态并连续执行多步任务，错误也可能沿着执行链不断累积，因此评估不能只看最后一句回答，还要关注整个执行轨迹和最终环境状态。
这也是为什么“能不能做 Agent”不是最重要的问题。
更重要的问题是：这里是否真的需要一个拥有自主决策权的系统？
下次设计 AI 自动化时，可以先做一个小练习：把整个任务画成流程图。
确定的部分，用代码锁死；需要理解语言的部分，放入 LLM；少量已知分支，用 Workflow 编排；只有那些真正无法提前确定、必须根据环境持续探索的部分，才交给 Agent。
好的 AI 系统并不是让 LLM 决定得越多越好。
真正成熟的设计，是清楚知道：哪些地方需要智能，哪些地方根本不应该让智能插手。