AI Agents vs AI Workflows：判据、代价、怎么选

这个系列的第一件事是把两个词分开，因为后面所有的设计选择都挂在这条线上。

判据只有一条

下一步做什么，是代码决定的还是模型决定的。

代码决定是 workflow，模型决定是 agent。不看工具数量、不看步数、不看框架。

Anthropic 的表述和这个一致：workflow 是 LLM 被编排在预先写好的代码路径里；agent 是 LLM 自己指挥流程和工具使用。

交出控制权，同时交出了三样东西

这是这一篇的核心，也是多数教程不会强调的。

一、可复现性。 同一份输入两次运行可能走不同路径。有论文专门论证这件事，主张用预定的图替代反应式循环，理由就是loop 的非确定性让结果不可复现。

二、可比较性。 路径不一样，两个版本的产出就没法相减。而没有可比较性，你的所有「我改进了」都只是感觉。

三、发现错误的速度。 workflow 的每一步你知道会发生什么；agent 可能在第三步做了个你没预料的决定，你在第十步才看见后果。

有个说法把这件事讲得很准：错误的代价随它被发现之前存活的轮数放大，而循环按其构造就是一台最大化轮数的机器。

那什么时候值得交出去

三种情况：

反过来，这几种情况明确该用 workflow：步骤确定、需要比较版本、出错代价高、或者要给别人审计。

混合是常态

真实系统很少是纯的。一个我认为合理的形状：

输入处理     → workflow（步骤确定）
探索/理解    → agent（路径未知）
产出生成     → workflow（有固定结构）
验证         → 独立的 agent 或确定性检查

关键是每一段都要说得出「这里为什么是这种」。 说不出来的那一段，多半是默认选了 agent —— 而默认往 agent 走是这两年最常见的过度设计。

一个很实用的中间形态

有一种做法值得单独提：让模型决定内容，让代码决定流程。具体怎么造下一篇讲。

比如生成一份报告：章节顺序、每节要不要出图、字数上限由代码定死；每节写什么由模型定。

这样拿到的是：产出的结构完全可预测（能比较、能校验），而灵活的部分交给模型。

很多被做成 agent 的需求，其实这个形态就够了。

边界与代价

workflow 的代价是僵硬。 遇到没设计过的情况它直接卡住，而 agent 至少会尝试 —— 代价是那笔按轮数乘上去的账。如果你的输入分布很宽，写死所有分支的维护成本会超过不确定性的成本。

「能用 workflow 就别用 agent」不是保守，是有理由的：agent 的复杂度成本主要不在代码难写，在你失去了衡量自己进步的手段。

这条判据不能解决所有争论。 有些系统一半路径写死一半交给模型，叫它什么都行 —— 那时候有用的问题不是「它是不是 agent」，而是**「哪几段是模型决定的，那几段出错我多久能发现」**。