Workflow 和 Agent：什么时候该固定流程，什么时候该让模型决策？

今天先记住

Workflow 是把步骤预先写死，Agent 是在边界内动态决定下一步。工程里不要一上来追求“全自动 Agent”，先判断任务变化点在哪里：稳定步骤交给 Workflow，不确定分支才交给 Agent。

它在大地图里的位置

继续把 Agent 放回整条链路里看：

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

前几课讲了闭环和工具调用。今天讲的是“谁来安排这些动作”：如果每一步都能提前确定，就是 Workflow；如果下一步要根据上下文、工具结果或失败原因临场选择，才需要 Agent。

它到底是什么

Workflow 像一张固定流程图：先 A，再 B，成功走 C，失败走 D。它适合规则清楚、输入形态稳定、失败处理可枚举的任务。

Agent 像一个带工具的决策者：它知道目标和边界，但每一步要看当前状态再选。比如它可能先读文件，发现缺少上一课，就补查目录；构建失败，就读错误；错误来自链接，就改链接；错误来自配置，就检查 VitePress。

所以二者不是敌人。好的 Agent 系统通常是“Workflow 做骨架，Agent 处理不确定节点”。

为什么 Agent 里会用到它

如果所有步骤都让模型自由决定，系统会难调试：同一个任务今天先查资料，明天先改文件，后天忘了构建。失败时你很难知道是规则错、工具错，还是模型决策飘了。

如果所有步骤都写死，系统又会僵：一旦输入和预期不一样，比如上一课缺失、构建报错类型变了、资料源不可用，流程只能失败退出。

所以真实项目里常见做法是：用 Workflow 固定不可省略的检查点，用 Agent 处理“该选哪个工具、该改哪里、失败后换哪条路”。

怎么判断它有没有用

如果任务每次都按同样顺序执行，比如“生成文件 -> 构建 -> 提交 -> 推送”，先用 Workflow。

如果中途结果会改变下一步，比如“构建失败后要读错误并判断改正文还是改配置”，这里适合放 Agent。

如果动作风险高，比如发消息、删文件、改线上配置，关键步骤要固定在 Workflow 里，不能让模型随口决定越权执行。

如果你无法写出清晰的失败分支，先不要做全自动 Agent；先把失败点记录下来，再决定哪些分支值得交给模型。

一个小例子

txt

Input:
生成并发布 2026-07-15 的每日 Agent 学习文档。

Workflow:
1. 读取写作框架。
2. 找到上一课。
3. 写入当天 Markdown。
4. 运行 docs:build。
5. 只提交相关文件并 push。

Agent 决策点:
上一课如果存在，就判断下一个主题；
如果构建失败，就读取错误并决定改正文、改链接，还是改配置；
如果 Git 状态里有无关文件，就跳过，不一起提交。

Output:
状态从“当天课程不存在”变成“课程文件存在、构建通过、相关提交已推送”。

这个例子能说明一个判断标准：固定的发布顺序不需要模型发挥，失败后的诊断和主题延续才需要 Agent。

常见误区

以为 Workflow 不够智能。稳定流程本来就应该固定，少让模型参与反而更可控。
以为 Agent 可以替代所有流程编排。没有固定检查点，Agent 很容易漏步骤。
以为用了 LangGraph 之类框架就一定是 Agent。图里每个节点都写死时，它更像 Workflow。
以为动态决策越多越好。动态越多，越需要日志、权限和评估兜住。

今天自测

一个任务里，哪些步骤应该固定成 Workflow？
什么样的分支才值得交给 Agent 判断？
如果构建失败，系统该如何区分“固定流程失败”和“Agent 决策失败”？

Workflow 和 Agent：什么时候该固定流程，什么时候该让模型决策？ ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​