很多团队第一次接触 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 元自动退款5002000 元需要主管审批超过 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 决定得越多越好。真正成熟的设计是清楚知道哪些地方需要智能哪些地方根本不应该让智能插手。 别急着做 Agent：先判断任务有没有不确定性
很多团队第一次接触 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 元自动退款5002000 元需要主管审批超过 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 决定得越多越好。真正成熟的设计是清楚知道哪些地方需要智能哪些地方根本不应该让智能插手。