Workflow、Agent 与 Agentic Workflow 的区别

这三个词在日常讨论中经常被混用，但它们指向的是三个不同层次的概念。本文基于 Anthropic《Building Effective Agents》、Hugging Face 论文《Workflow vs. Agent: a Policy-vs-Script Perspective》、吴恩达 Agentic AI 课程与国内一线工程实践，做一次系统性的辨析。

一句话结论

• Workflow（工作流）：一种执行方式——LLM 和工具按照预先定义的代码路径被编排，流程拓扑在开发期固定。
• Agent（智能体）：一种自主实体——LLM 动态决定自身流程与工具使用，在运行时保持对"如何完成任务"的控制权。
• Agentic Workflow（智能体工作流）：一种系统形态——把 Agent 的自主决策能力嵌入结构化的流程编排中，是"自主性 × 结构化"的混合模式。

三者是概念层次不同的东西：Workflow 和 Agent 是两种相对的架构风格，Agentic Workflow 则是二者融合后的工程形态。

Workflow vs Agent：控制权之争

Anthropic 在《Building Effective Agents》中给出了目前最被广泛引用的定义。它把这类系统统称为 Agentic Systems，并做出关键的架构区分：

• Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
• Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

翻译过来：工作流是"LLM 和工具通过预定义代码路径被编排"的系统；Agent 是"LLM 动态指导自身流程和工具使用"的系统。

核心差异对比

维度	Workflow	Agent
流程控制权	开发者预先定义（代码/DAG）	LLM 运行时自主决定
执行路径	固定拓扑，枚举分支	动态生成，不可预知步数
可预测性	高，行为一致可审计	低，结果依赖模型决策
适用任务	步骤可清晰拆解的确定性任务	开放式问题，无法硬编码路径
成本与时延	相对可控	每轮决策都有开销，错误易级联放大
失败模式	单点失败可预期、可重试	错误可能级联累积
典型例子	提示词链、路由、并行批处理	编程助手、深度研究、computer use

一个更锋利的判据：运行时谁决定下一步？

Hugging Face 上的论文《Workflow vs. Agent: a Policy-vs-Script Perspective》指出了主流定义模糊的地方：看图上有没有循环、有没有分支，都不能判定一个系统是否 agentic。真正的问题是——

运行时，谁控制下一步动作（policy）？

• Scripted orchestration（脚本式编排）：拓扑、守卫条件、停止条件都在设计期由开发者固定，运行时只是沿着枚举过的分支走。哪怕分支再多、有重试有投票，只要所有分支是静态可知的，它仍然是 workflow。
• Policy-driven orchestration（策略驱动编排）：由一个"策略"（通常是 LLM）在运行时选择动作、工具、参数和停止时机，甚至修改后续流程。

一个有意思的灰色地带：系统先让 LLM 生成一份 DAG/计划再执行（plan-and-execute）。如果执行中严格按计划走、不做偏离，那它只是一份"AI 写的 workflow"；如果执行中可以根据观察动态修改计划——插入步骤、调整工具顺序、重新分配预算——它就跨入了 agentic 的领地。

一句话总结非常精辟：

Agents sample flows; workflows execute flows.（Agent 采样生成流程，Workflow 执行固定流程。）

一图看懂：两种编排风格的分野

用一张 Mermaid 图概括两种架构风格的分野（文本版，保证在任何 Markdown 渲染器下可读）：

graph LR
    subgraph WORKFLOW["Workflow：脚本式编排"]
        direction LR
        U1(["任务输入"]) --> S1["步骤 1"] --> S2["步骤 2"] --> S3["步骤 3"] --> O1(["结果输出"])
        G1{"校验门 gate"} -.->|"固定分支/重试"| S2
    end
    subgraph AGENT["Agent：策略驱动编排"]
        direction TB
        U2(["任务目标"]) --> C{"LLM 决策循环<br/>：下一步做什么？"}
        C -->|选工具 A| T1["工具调用 A"]
        C -->|选工具 B| T2["工具调用 B"]
        C -->|完成/达停止条件| O2(["结果输出"])
        T1 -- 环境反馈 --> C
        T2 -- 环境反馈 --> C
    end

读图要点：左边 Workflow 的每一个箭头都是设计期确定的；右边 Agent 唯一固定的是"LLM 决策循环"本身，每一步走哪条边由运行时的观察决定——这正是"策略驱动 vs 脚本驱动"的差别。

Workflow 的五种经典模式（Anthropic）

Anthropic 总结了五种生产环境验证过的 workflow 模式，可以作为 workflow 风格的参考实现：

1. 提示词链（Prompt Chaining）：任务分解为串行步骤，前一步输出作为下一步输入，可在中间加程序化校验门。适合能干净拆分为固定子任务的情况，用时延换准确率。
2. 路由（Routing）：先对输入分类，再分发到专门化的下游处理。适合"单 Prompt 优化存在类别互损"的场景，如客服分流。
3. 并行化（Parallelization）：分为 sectioning（任务拆分并行）与 voting（多结果投票）两种变体。
4. 编排者-工作者（Orchestrator-Workers）：中央 LLM 动态拆解任务分发给 worker。注意它虽然"动态"，但拆解后的子任务仍由固定代码路径分发执行，因此仍属 workflow 风格。
5. 评估者-优化者（Evaluator-Optimizer）：生成者产出、评估者反馈的循环，适合有明确评价标准的迭代优化。

Agent：LLM + 工具 + 环境反馈的循环

与很多人想象中复杂的多智能体架构不同，Anthropic 指出生产级 Agent 的实现往往出奇简单：

它们通常只是LLM 基于环境反馈循环使用工具。

Agent 的运行逻辑是：接收任务 → 自主规划 → 执行工具调用 → 从环境获得"地面真相"（工具返回结果、代码执行输出）→ 评估进度 → 决定下一步或停止。它需要的关键配套是：

• 精心设计的工具集（Anthropic 提出了 ACI——Agent-Computer Interface 的概念，认为工具文档投入应当比肩 HCI）；
• 停止条件（如最大迭代次数），防止模型陷入自我循环；
• 沙盒环境与护栏（guardrails），因为 Agent 的自主性意味着更高的成本和错误级联的风险。

Agentic Workflow：吴恩达的四种设计模式

"Agentic Workflow"这个词的流行很大程度上来自吴恩达。他提出的核心洞察是：与其让模型一次性"憋"出答案，不如让它迭代式地工作——这能让一个普通模型在复杂任务上超越更强的模型。

他总结了四种 Agentic Workflow 的设计模式：

1. Reflection（反思）：让 AI 检查自己的输出并自我改进。例如写完代码后再把代码交给 AI"检查正确性、效率和可读性"，根据反馈迭代。生成与评估可以是两个独立模型的分工。
2. Tool Use（工具调用）：让 LLM 借助 Web 搜索、代码执行、文档检索等工具，突破自身知识与能力的边界。
3. Planning（规划）：让 LLM 把复杂任务自主分解为子任务并按序执行，而非按人类预设的步骤走。
4. Multi-agent Collaboration（多智能体协作）：多个角色（如"写代码的"、"评审代码的"、"测试的"）分工协作，模拟一个开发团队的运作。

值得注意的是，这套"迭代式"理念与 Anthropic 的定义并不矛盾：Reflection、Planning 等模式既可以以固定 workflow 的形式落地（评估者-优化者循环就是 Reflection 的 workflow 化），也可以以自主 Agent 的形式落地（Agent 在循环中自己决定何时反思、何时规划）。这正是两种架构风格的交汇点。

IBM 等机构对 Agentic Workflow 的定义也印证了这一点：把智能体的自主性与工作流的结构化特性融合的混合模式——它不是"Agent 的工作流"这么简单，而是包含了传统软件、LLM、AI Agent 等在内的新型业务流程形态。

选型决策框架

什么情况选 Workflow

• 任务需求清晰稳定，步骤可以预先拆解；
• 可预测性和可审计性是硬要求（如金融合规、审批流）；
• 需要精确的成本与时延控制；
• 系统可靠性和调试优先级高于灵活性。

什么情况选 Agent

• 任务开放式、探索性强，无法预知需要多少步；
• 需要根据中间结果动态调整策略（如深度研究、复杂编码）；
• 环境会变化，需要"感知-决策-执行-反馈"闭环；
• 可以接受较高成本换取更好效果，且能提供沙盒与护栏。

实际上：两者都在混合使用

生产系统几乎都不是二选一，而是三种常见混合模式：

1. Workflow-in-Agent：Agent 在自主决策中，遇到确定性子任务时调用固定的脚本化技能（如 book_flight()）。CodeAct 是其最纯粹的形式——策略生成代码，代码确定性执行。
2. Agent-in-Workflow：以工作流为骨架，在需要开放式推理的节点委托给 Agent，完成后回到脚本。典型如"简单退款 → 脚本处理；复杂纠纷 → Agent 接管对话"。
3. Agent 以 Workflow 为工具：把整个工作流封装为可调用 API，由 Agent 决定何时触发。

国内的工程实践同样验证了这个原则——保持简洁，非必要不增加复杂性：对规则明确、流程固定的环节用 workflow 保证效率；对场景多变、需要主观判断的环节引入 Agent 的自主决策。Anthropic 的建议甚至更激进：从最简单的方案开始，很多场景优化单次 LLM 调用（加检索和上下文示例）就足够了，只有在简单方案明确失效时才引入多步 agentic 系统。

总结

用一张表收束全文：

概念	本质	关键问题
Workflow	一种执行方式	流程由谁定义？→ 开发者，设计期固定
Agent	一种自主实体	运行时谁决定下一步？→ LLM
Agentic Workflow	一种混合系统形态	如何让自主性与结构化各得其所？→ 混合编排

如果只能记住一句话，那就是 Hugging Face 论文的那句判据：别争论抽象名词，去问"运行时是谁在控制编排"——脚本式的叫 workflow，策略驱动的叫 agentic；而成熟的系统则是"策略负责选择与适应，工作流负责确定性兜底"。

参考资料

• Anthropic — Building Effective Agents
• Hugging Face — Workflow vs. Agent: a Policy-vs-Script Perspective
• Prompt Engineering Guide — AI Workflows vs. AI Agents
• 吴恩达 Agentic AI 系列课程（DeepLearning.AI）
• 腾讯云开发者社区 — Workflow 和 Agent 的区别与构建