关于 Agent，流传着三种说法：
- 任务一复杂，就该上 Agent。
- 只要用了大模型、输入是自然语言，就是 Agent。
- Agent 是更高级的 Workflow。
这三句话都是错的。这篇文章先给出一个判断标准，再用这个标准逐一拆掉这三个误区。
一、只有一道判断题
你能不能在执行之前，把正确的步骤基本写出来？
能，优先 Workflow。
不能，系统就必须在运行过程中根据环境、反馈和已有信息，不断决定"下一步做什么"。这时才需要 Agent。
所以两者真正的分界线，不是任务有多复杂，而是 下一步由谁决定：Workflow 里是开发者提前定义，Agent 里是模型在运行时决定。
由此还能推出一个非常好用的测试，不妨叫它 拔掉大模型测试：
如果把 LLM 去掉，这个流程还能不能画成 BPMN、DAG 或者状态机？
如果答案是"基本可以"，那大概率就是 Workflow。
这个区别也决定了两者完全不同的工程特性：
| 维度 | Workflow | Agent |
|---|---|---|
| 下一步怎么做 | 开发者提前定义 | 模型运行时决定 |
| 路径 | 有限、可枚举 | 开放、很难枚举 |
| Tool 调用 | 哪一步调用什么通常已知 | 自己选择工具 |
| 出错处理 | retry / fallback / branch |
理解错误后重新规划 |
| 可预测性 | 高 | 较低 |
| 审计 | 容易 | 更困难 |
| 成本 | 通常低 | 通常高 |
| 适合 | 流程问题 | 决策 / 探索问题 |
请记住表格的后四行。Agent 用灵活性换来了更低的可预测性、更难的审计、通常更高的成本 。这笔代价，是后面所有判断的底层理由：步骤写得出来，就没有理由付这笔钱。
二、误区一："复杂"就该上 Agent
先看一个你可能没听过的场景：半导体晶圆厂的异常处理。
假设在一家类似台积电的晶圆厂里，传感器发现某批 wafer 的 etching 参数异常。这件事要牵扯设备数据、MES、recipe version、quality control，还有 engineer approval。横跨好几套系统，看起来复杂得吓人。
但把处理流程画出来，你会发现它非常规整：
整条流程里只有一个 判断点：Within tolerance?。判断条件和两个出口，在运行之前就已经写在图上了。"发生什么情况 → 做什么"，全部事先知道。
你完全没必要让 Agent 在产线边上琢磨："Hmm，这批 wafer 好像有问题，我下一步是不是应该查 MES？"
在这里，多出来的自由度不是能力，反而是危险。
判决：Workflow。 复杂的是系统，不是决策。系统再多，只要决策能提前写出来，就是 Workflow。
三、误区二："用了 LLM"就是 Agent
"帮我处理发票。"
很多人看到自然语言，就觉得应该上 Agent。但把典型的 invoice processing 画出来，它是一条笔直的流水线：
LLM 确实参与了，它负责从 PDF 里抽取 supplier、invoice number、amount、GST、PO number。但它只占一个节点。抽完之后去 Match PO、再去 Match goods received、再去 Check tolerance，每一步都是开发者写好的。
用"拔掉大模型测试"检验：把 LLM extraction 换成一个传统的抽取模块，这张图一笔都不用改。
判决：Workflow。 使用 LLM ≠ Agent。 判断标准从来不是"有没有用大模型"，而是"下一步由谁决定"。
四、那真正的 Agent 问题长什么样？
拆完两个误区，再看正面的例子。它们有一个共同点：目标明确，路径未知。
冷链集装箱：分叉点藏在证据里
一家物流公司发现，一个价值 200 万美元 的冷链集装箱，运输途中温度异常了 9 小时 。系统只有一个目标：Find out what happened and recommend what to do.
Agent 可能先查 container telemetry、GPS history、vessel schedule、port handling logs。接下来往哪走，取决于一个开工前没人知道的答案：温度异常发生在哪里？
如果发现异常发生在 Singapore transshipment ，它会去查 terminal event log，发现 container 被 unplug 了 8 小时，再顺着港口操作记录找到 handling contractor，查 refrigeration alarm，最后判断货物是否仍符合 cold-chain standard。
如果 GPS 显示异常发生在海上，它要查的就完全是另一批东西：reefer unit logs、vessel power logs、generator failure、maintenance records。
两条路线用的工具不同、查的对象不同。你几乎不可能提前画出完整的 DAG。
保险追偿与云成本：每一步都踩在上一步的证据上
再看两个领域完全不同、结构却一模一样的调查：
保险追偿（Subrogation） ：保险公司因为一家餐厅火灾赔了 $180,000，想知道有没有第三方应该承担责任。fire report 指向 commercial fryer；维修记录显示两周前刚修过；maintenance invoice 显示用了非原厂 thermostat；recall database 显示这个型号有 recall。最后得出三个潜在责任方：maintenance contractor、thermostat manufacturer、equipment distributor。
云成本调查 ：一家公司过去三个月云成本涨了 40%。Cost Explorer 指向 NAT Gateway；VPC Flow Logs 显示大量 cross-AZ traffic；Kubernetes 显示某服务扩容；GitHub commits 里有一次 architecture change；对应的 PR 显示 Redis 从 local 改成了 cross-AZ cluster。
看图 5 的结构：每一行查什么，都是上一行的发现决定的。 在开工之前，这张表你一行都写不出来。这类任务没法写成 if xxx: tool_a() else: tool_b()，因为你根本不知道调查会发现什么。
判决：Agent。 目标明确，路径未知，下一步只能由证据决定。
五、决定类型的，是问题，不是对象
到这里你可能会想：那是不是"调查类"的领域就用 Agent，"运维类"的领域就用 Workflow？
也不对。看同一台机器的两种问法：
一座风电场有 600 台风机，其中一台发电效率下降了 17%。
问法一： 检测效率下降，获取 vibration data、wind speed、gearbox temperature，超阈值就创建 maintenance ticket。步骤、工具、阈值全部写死。这是 Workflow。
问法二： "找出为什么这台风机最近效率下降。"Agent 查风速，正常；查 pitch angle，异常；查 controller logs，正常；查 maintenance records，发现 blade cleaning 被跳过；查天气，过去两周有 dust storm。于是推测：blade contamination。
然后它又发现，附近其他 turbine 同样在下降。这条新证据推翻了原来的假设：可能不是设备问题，而是 environmental condition。
这就是 Agent 最擅长、而传统 Workflow 很难自然表达的循环：
Hypothesis → Investigation → Evidence → Change hypothesis
Workflow 难以表达它，原因很直接：你没法提前知道假设会被推翻几次、往哪个方向推翻。
判决：问法一是 Workflow，问法二是 Agent。 设备没变，问题变了，系统就跟着变。
六、误区三："Agent 是更高级的 Workflow"
如果 Agent 真是 Workflow 的升级版，那最好的系统应该全部用 Agent。但现实中最成熟的系统恰恰相反：两者是搭档，不是替代。
港口重排：Agent 调约束，Solver 算方案
港口船舶泊位调度平时就是一条标准流程：Ship ETA → Assign berth → Assign crane → Unload → Load → Departure。这是 Workflow 加 optimization。
然后几件坏事同时发生：船 A 晚 11 小时 ，船 B 提前 6 小时 ，Crane 7 故障，码头 3 被关闭，天气预报 8 小时后有大风。问题变成："怎么重新安排整个港口？"
Agent 负责理解扰动，查泊位、起重机产能和船舶优先级，生成备选方案；optimization solver 负责计算；Agent 再检查结果、调整约束，让 solver 再跑一次。
这里出现了一个特别重要的模式：
text
Agent → Workflow / Solver → Agent而不是所有东西都交给 Agent。
银行欺诈调查：Agent 只建议，Workflow 来执行
企业系统里最成熟的架构，通常长这样：
text
┌─────────────┐
│ Agent │
│ reasoning │
└──────┬──────┘
│
decide what should happen
│
┌───────────┼───────────┐
▼ ▼ ▼
Workflow A Workflow B Workflow C
refund investigate escalateAgent 负责 Which process? Workflow 负责 Execute the process correctly.
银行 fraud investigation 把这条分工体现得最清楚：
你绝对不希望 LLM 自由决定调用 stripe.refund()、transfer_money()、close_account()。正确的做法是：Agent 给出建议，"I recommend freezing this card."；然后由确定性的 Workflow 依次完成 verify permission、check policy、create audit log、freeze card、notify customer。
为什么必须这么分？回到第一节表格的后四行。Agent 可预测性较低、审计更困难 ，而动钱、动账户的操作恰恰最需要可预测和可审计。把执行交给 Workflow，比 Agent → tool → tool → tool → database → payment 一路直连安全得多。
判决： 让 Agent 决定去哪，让 Workflow 保证怎么走。
七、一张图带走
把前面所有判断收拢起来，就是四种情况：
text
已知目标 + 已知路径 → Workflow
已知目标 + 未知路径 → Agent
未知目标 + 未知路径 → 通常不是 Agent 问题，而是需求还没定义清楚
大方向未知 + 局部步骤已知 → Agent → Workflow → Agent → Workflow第三类经常被忽略：目标都没定义清楚，换什么技术都救不了，先把需求写清楚。
第四类是现实世界里最常见的，也就是 Agentic Workflow。港口和银行都属于这一类：开放的部分交给 Agent，确定的部分交给 Workflow。
写在最后：Agent 没有消灭软件工程
你会发现，真正 enterprise-level 的 Agent 架构做到最后，往往会重新长出那些你很熟悉的东西：
state machine、queue、event bus、approval、RBAC、retry、idempotency、audit log、workflow engine。
这并不奇怪。Agent 并没有消灭传统软件工程，它只是填补了过去最难编码的那一块：
无法提前枚举的决策空间。
其余的部分，依然要靠那些老老实实的工程手段来兜底。
所以下次有人说"这个流程挺复杂，上个 Agent 吧"，先别急着点头。把大模型拔掉，看看这张图还画不画得出来。
画得出来，交给 Workflow。画不出来，再请 Agent。