Agentic Workflow vs. Autonomous Agent: What’s the Difference?

Agentic Workflow 与 Autonomous Agent 的区别：MachineLearningMastery.com

Agentic Workflow 与 Autonomous Agent 的区别

By

Shittu Olumide

on

2026年6月25日

in

人工智能

0

分享

文章

在本文中，你将学习如何通过关注控制流程的所有者（是提前编写代码的人，还是在运行时进行推理的模型）来区分 Agentic Workflow 和 Autonomous Agent。

我们将涵盖的主题包括：

• 真正区分这些系统的轴线是可预测性与自主性，而不是是否涉及 LLM。

• 确定性工作流、编排工作流、反应式代理和自主多代理系统之间的差异，以及可运行的代码，使控制流程的区分更加具体。

• 为什么工作流，而不是完全自主的代理，在当今的生产环境中占主导地位，以及为什么混合架构是保持稳定性的模式。

引言

德勤预计到2027年，使用生成式 AI 的公司中，最多有50%将启动 Agentic AI 的试点或概念验证。这种采用浪潮足够大，以至于“Agentic”这个词几乎涵盖了任何包含 LLM 调用的内容，从一个固定五步流程中第三步调用 GPT 来生成摘要，到一个完全自主规划路径的系统，没有任何脚本。

这些并不是同一件事。将它们视为可以互换会导致两种错误之一：要么对一个简单且已被充分理解的任务进行过度设计，引入不必要的自主性；要么对一个真正开放的问题进行不足的设计，将其强制放入一个僵化的流程中，一旦现实偏离计划，系统就会崩溃。

Anthropic 在他们广受引用的“构建有效代理”一文中划定了基础界限：工作流是通过预定义代码路径协调 LLM 和工具的系统。代理是 LLM 动态指导其自身流程和工具使用，保持对如何完成任务的控制的系统。本文的所有内容都基于这一区别进行详细说明。

本文映射了确定性工作流、编排系统、反应式单代理和自主多代理系统的完整光谱，每个阶段都有代码，使控制流程的差异具体化，而不是抽象化。这里的代码说明的是架构，而不是可部署的系统；每个代码片段的重点是展示谁决定下一步发生什么，而不是部署一个功能。

Google Cloud 自己的设计模式文档在操作上明确地划定了这一界限：确定性工作流包括具有明确路径的任务，这些路径在设计时就已经确定，且从一次运行到另一次运行的变化不大。需要动态编排的工作流则涉及那些代理必须决定最佳前进方式的问题，而没有预定义的脚本。本文正是沿着这一光谱，逐步地进行介绍。

确定性工作流

这是基准情况。确定性工作流在设计时由人通过代码决定一个已知的步骤序列。一个大型语言模型（LLM）可以嵌入在任何步骤中——生成文本、对输入进行分类、起草摘要——但它不会决定在它自己的步骤运行之后会发生什么。无论模型返回什么内容，协调代码都会决定下一步要执行哪个函数。

deterministic_pipeline.py # 先决条件：除了 Python 的标准库之外没有其他要求 # 运行：python deterministic_pipeline.py def mock_llm_classify(text: str) -> str: """ 模拟 LLM 调用——代表一个真实的 API 调用，以使这个示例在不使用 API 密钥的情况下可运行。重点在于结构：无论这个函数返回什么，下面已经决定了接下来运行的函数。 """ if "refund" in text.lower() or "charge" in text.lower(): return "billing" return "general" def extract(raw_input: str) -> str: """步骤 1 —— 总是运行，总是导向步骤 2。这里没有分支。""" return raw_input.strip() def classify(cleaned_text: str) -> str: """步骤 2 —— 调用一个 LLM 生成标签，但该标签不会影响下一步运行哪个函数。这是确定性部分：模型填充数据，但不影响路径。""" label = mock_llm_classify(cleaned_text) print(f" [classify] LLM 返回标签='{label}'（仅为信息）") return cleaned_text def summarize(cleaned_text: str) -> str: """步骤 3 —— 总是在步骤 2 之后运行，无论步骤 2 的标签是什么。""" return f"Summary: {cleaned_text[:40]}..." def notify(summary: str) -> str: """步骤 4 —— 总是最后运行。路径在设计时就已经固定。""" return f"Notification sent: {summary}" def run_deterministic_pipeline(raw_input: str) -> str: """这里的控制流完全由人在设计时编写。每次运行都遵循相同的路径：提取 -> 分类 -> 摘要 -> 通知。分类()中的 LLM 调用生成一个标签，但该标签从不用于决定下一步运行哪个函数——它只是通过固定管道流动的数据。""" step1 = extract(raw_input) step2 = classify(step1) step3 = summarize(step2) step4 = notify(step3) return step4 if __name__ == "__main__": # 两个输入，LLM 会将它们分类为完全不同的结果 result_1 = run_deterministic_pipeline("I want a refund for my last charge") result_2 = run_deterministic_pipeline("What are your business hours?") print(f"\nResult 1: {result_1}") print(f"Result 2: {result_2}")

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

deterministic_pipeline.py

先决条件：除了 Python 的标准库之外没有其他要求

运行：python deterministic_pipeline.py

def

mock_llm_classify

(

text

:

str

)

->

""

"

模拟 LLM 调用——代表一个真实的 API 调用，以使这个示例在不使用 API 密钥的情况下可运行。重点在于结构：无论这个函数返回什么，下面已经决定了接下来运行的函数。

if

"refund"

.

lower

"charge"

return

"billing"

"general"

extract

raw_input

"步骤 1 -- 总是运行，总是导向步骤 2。这里没有分支。"

strip

classify

cleaned_text

步骤 2 -- 调用 LLM 生成标签，但标签不会影响下一步运行哪个函数。这是确定性部分：模型填充数据，但不会影响流程走向。

label

=

print

f

" [classify] LLM 返回标签='{label}'（仅用于信息）"

summarize

"步骤 3 -- 总是在步骤 2 之后运行，无论步骤 2 的标签是什么。"

"摘要：{cleaned_text[:40]}..."

notify

summary

"步骤 4 -- 总是最后运行。路径在设计时就已经固定。"

"已发送通知：{summary}"

run_deterministic_pipeline

这里的控制流完全由人在事先编写。每次运行都走相同的路径：提取 -> 分类 -> 摘要 -> 通知。分类() 中的 LLM 调用生成一个标签，但这个标签从不用于决定下一步运行哪个函数——它只是通过固定管道的数据。

step1

step2

step3

step4

__name__

==

"__main__"

两个 LLM 会完全不同分类的输入

result_1

"I want a refund for my last charge"

result_2

"What are your business hours?"

"\n结果 1: {result_1}"

"结果 2: {result_2}"

如何运行：python deterministic_pipeline.py，不需要任何依赖。

输出：

[classify] LLM 返回标签='billing'（仅用于信息） [classify] LLM 返回标签='general'（仅用于信息） 结果 1: 已发送通知：摘要：I want a refund for my last charge... 结果 2: 已发送通知：摘要：What are your business hours?...

[

]

LLM

返回

'billing'

信息

仅

'general'

结果

通知

发送

I

想要

退款

我的

最后一次

收费

What

是

你们的

营业时间

?

注意发生了什么：模拟的 LLM 对两个输入进行了完全不同的分类，一个是 billing，一个是 general，但对两个输入所走的路径没有任何影响。两者都通过了完全相同的四个函数，顺序也完全相同。这就是确定性的全部定义：路径是固定的，即使 LLM 在其中一个步骤中执行了实际的工作。

协调的工作流程

这是最容易被错误标记为“智能代理”的中间地带，值得在这里放慢脚步，因为这是大多数人开始松散使用这个词时实际跨越的界限。

协调的工作流程仍然有一个完全在事先定义的可能路径图，但当前选择哪条路径取决于运行时的决定，通常由 LLM 调用做出。这仍然是一个工作流程。每个可能的分支在系统运行之前就已经被预见并写入代码。LLM 从别人编写的菜单中选择一个分支。它不会在菜单上添加新的项目。

这正是 Google Cloud 将其与真正的代理区分开来的“动态协调”类别——系统需要规划和路由，但其结构仍然完全由人设计。

orchestrated_pipeline.py

Prerequisites: none beyond Python's standard library

Run: python orchestrated_pipeline.py

def mock_llm_classify(text: str) -> str: """Mock LLM classification call.""" text_lower = text.lower() if "refund" in text_lower or "charge" in text_lower: return "billing" if "crash" in text_lower or "error" in text_lower or "bug" in text_lower: return "technical" return "general"

def extract(raw_input: str) -> str: return raw_input.strip()

Three pre-defined downstream handlers. A human wrote all three of these

in advance. The LLM does not invent a fourth path -- it can only select

among branches that already exist in this code.

def handle_billing(text: str) -> str: return f"[BILLING TEAM] Routed: {text[:50]}"

def handle_technical(text: str) -> str: return f"[TECH SUPPORT] Routed: {text[:50]}"

def handle_general(text: str) -> str: return f"[GENERAL QUEUE] Routed: {text[:50]}"

The branch map IS the entire decision space. Every key here was written

by a human ahead of time. The LLM's job is to pick a key -- not define one.

ROUTE_MAP = { "billing": handle_billing, "technical": handle_technical, "general": handle_general, }

def run_orchestrated_pipeline(raw_input: str) -> str: """Still a workflow, not an agent: every possible path was anticipated and coded by a human ahead of time, sitting in ROUTE_MAP. The LLM call decides WHICH pre-built branch executes for this specific input, but it cannot invent a branch that isn't already a key in ROUTE_MAP.""" cleaned = extract(raw_input) label = mock_llm_classify(cleaned) print(f" [route] LLM classified as '{label}' -> dispatching to handle_{label}()") handler = ROUTE_MAP.get(label, handle_general) return handler(cleaned)

if __name__ == "__main__": test_inputs = [ "I was charged twice for my refund request", "The app keeps crashing with an error on startup", "What are your business hours?", ] for inp in test_inputs: result = run_orchestrated_pipeline(inp) print(f" Result: {result}\n")

How to run: python orchestrated_pipeline.py, no dependencies required.

[route] LLM 被分类为 'billing' -> 转发至 handle_billing() 结果：[BILLING TEAM] 路由：我的退款请求被收取了两次 [route] LLM 被分类为 'technical' -> 转发至 handle_technical() 结果：[TECH SUPPORT] 路由：应用在启动时出现错误并持续崩溃 [route] LLM 被分类为 'general' -> 转发至 handle_general() 结果：[GENERAL QUEUE] 路由：你们的营业时间是什么时候？

route

被分类为

dispatching

到

BILLING

TEAM

路由

被收取了两次

请求

'technical'

TECH

SUPPORT

应用

持续崩溃

出现错误

启动

GENERAL

QUEUE

这三个不同的输入这次选择了三条不同的路径——这与上一部分相比是新的。但请看 ROUTE_MAP：在这些输入到达之前，所有可能的目的地已经写入了代码中。LLM 对使用哪个键进行了判断。它从未有机会创建一个不存在的键。这个区别——固定的可能路径集合与运行时发明的路径——正是下一节所要讨论的内容。

反应式代理：ReAct 循环和真正开放的路径

真正的自主性从这里开始。ReAct 模式——由 Yao 等人在 2022 年引入的推理加行动——让模型在每一步根据从上一步操作中观察到的内容自行决定下一步采取什么行动。没有预先写好的分支来涵盖所有情况。代理在思维、行动和观察的迭代循环中运行，直到满足退出条件，而这个过程本身——步骤数量、顺序以及使用哪些工具——在开始之前是无法预知的。只有可用的操作是固定的；通过它们的路径则不是。

这是前两部分所构建的架构门槛。在编排的工作流程中，系统运行之前，人类将所有可能的分支写入了 ROUTE_MAP。在这里，模型在运行时决定路径和序列长度，即使工具集本身仍然是固定的。

react_loop.py # 先决条件：仅需 Python 标准库 # 运行方式：python react_loop.py def search_knowledge_base(query: str) -> str: """代理可以调用的工具。是否以及何时调用由模型在运行时决定，而不是在此处决定。""" mock_kb = { "退款政策": "购买后30天内可以退款。", "发货时间": "标准发货需要5-7个工作日。", } for key, value in mock_kb.items(): if key in query.lower(): return value return "知识库中未找到匹配信息。" def escalate_to_human(reason: str) -> str: """代理可以调用的第二个工具。同样，是否调用此工具而不是搜索工具的决定由模型做出，而不是由这段代码决定。""" return f"已转交给人工代理。原因：{reason}" AVAILABLE_TOOLS = { "search_knowledge_base": search_knowledge_base, "escalate_to_human": escalate_to_human, } def mock_llm_decide_next_step(observations: list[str], user_query: str) -> dict: """模拟 LLM 调用，用于代替 ReAct 的推理步骤。在实际系统中，这是一次实际的模型调用，会读取完整的 Thought -> Action -> Observation 历史，并决定下一步操作。关键点：这个函数——而不是下面的调用循环——决定调用哪个工具以及何时停止。在 run_react_loop() 中没有任何“如果查询包含 X，调用 Y”的分支。每次迭代都会根据累积的上下文，从头开始做出决定。""" if not observations: return { "thought": "我需要先查找政策，然后才能回答。", "action": "search_knowledge_base", "action_input": user_query, } last_observation = observations[-1] if "知识库中未找到匹配信息" in last_observation: # 这个分支从未由人类提前编写——模型 # 根据刚刚观察到的内容，决定需要升级。 return { "thought": "知识库中没有答案。我应该升级这个问题。", "action": "escalate_to_human", "action_input": "知识库中没有匹配项：" + user_query, } return { "thought": "我找到了答案。任务完成。", "action": "finish", "action_input": last_observation, } def run_react_loop(user_query: str, max_steps: int = 5) -> str: """Thought -> Action -> Observation，重复直到模型本身决定停止。将此与上一节中的 run_orchestrated_pipeline() 直接对比：这里没有 ROUTE_MAP。没有人类编写的分支说“如果发生 X，调用 Y”。下一步发生的所有决定都由模型在运行时根据到目前为止观察到的内容做出。""" observations: list[str] = [] for step in range(max_steps): decision = mock_llm_decide_next_step(observations, user_query) print(f" 第 {step + 1} 步 -- 思考：{decision['thought']}") if decision["action"] == "finish": return f"最终答案：{decision['action_input']}" tool_fn = AVAILABLE_TOOLS.get(decision["action"]) if tool_fn is None: return f"错误：模型请求了未知工具 '{decision['action']}'" observation = tool_fn(decision["action_input"]) print(f" 第 {step + 1} 步 -- 动作：{decision['action']}({decision['action_input']!r})") print(f" 第 {step + 1} 步 -- 观察：{observation}\n") observations.append(observation) return "达到最大步骤数仍未解决问题。" if __name__ == "__main__": print("=== 查询 A：可以从知识库中找到答案 ===") result_a = run_react_loop("退款政策是什么？") print(f"结果：{result_a}\n") print("=== 查询 B：不在知识库中，应触发升级 ===") result_b = run_react_loop("你能处理我的国际税务退款为加密货币吗？") print(f"结果：{result_b}")

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

react_loop.py

运行: python react_loop.py

search_knowledge_base

query

"代理可以调用的工具。是否以及何时调用由模型在运行时决定，而不是在此处决定。"

mock_kb

"退款政策"

"购买后30天内可以退款。"

"发货时间"

"标准发货需要5-7个工作日。"

key

value

items

"知识库中未找到匹配信息。"

escalate_to_human

reason

"代理可以调用的第二个工具 -- 再次强调，选择调用此工具而不是搜索工具的决定由模型做出，而不是由这段代码决定。"

"已升级至人工代理。原因：{reason}"

AVAILABLE_TOOLS

"search_knowledge_base"

"escalate_to_human"

mock_llm_decide_next_step

observations

list

user_query

dict

模拟LLM调用，代表ReAct流程中的推理步骤。

在实际系统中，这会是实际的模型调用，读取完整的

Thought -> Action -> Observation 历史，并决定下一步操作。

关键点：这个函数 -- 而不是下面的调用循环 -- 决定调用哪个工具以及何时停止。代码中没有写任何关于

contains

X

call

Y

分支的代码。每次迭代的决策都是基于累积的上下文重新做出的。

not

"thought"

"在回答之前，我需要查找相关政策。"

"action"

"action_input"

last_observation

-

"未找到匹配信息"

这个分支从未被人类预先编写过 -- 模型基于它刚刚观察到的内容，决定需要升级。

"知识库中没有答案。我应该升级这个请求。"

"知识库中没有匹配项："

+

"我找到了答案。任务完成。"

"finish"

run_react_loop

max_steps

int

Thought -> Action -> Observation，重复直到模型本身决定停止。将此与上一部分的 run_orchestrated_pipeline() 直接对比：这里没有 ROUTE_MAP。没有人类编写的分支说明 "

happened

" 关于下一步发生什么的每一个决定，都是由模型在运行时根据它迄今为止观察到的内容做出的。

step

range

decision

"第 {step + 1} 步 -- 思考：{decision['thought']}"

"最终答案：{decision['action_input']}"

tool_fn

is

None

"错误：模型请求了未知工具 '{decision['action']}'"

observation

"第 {step + 1} 步 -- 动作：{decision['action']}({decision['action_input']!r})"

"第 {step + 1} 步 -- 观察：{observation}\n"

append

"达到最大步数仍未解决。"

"=== 查询 A：可以从知识库中回答 ==="

result_a

"退款政策是什么？"

"结果：{result_a}\n"

"=== 查询 B：不在知识库中，应触发升级 ==="

result_b

"你能处理我的国际税务退款为加密货币吗？"

"结果：{result_b}"

如何运行：python react_loop.py，不需要依赖项。

=== 查询 A：可以从知识库中找到答案 === 步骤 1 -- 思考：在回答之前，我需要查找相关政策。步骤 1 -- 动作：search_knowledge_base('What is the refund policy?') 步骤 1 -- 观察：退款可在购买后30天内办理。步骤 2 -- 思考：我已经找到了答案。任务完成。结果：最终答案：退款可在购买后30天内办理。 === 查询 B：不在知识库中，应触发升级 === 步骤 1 -- 思考：在回答之前，我需要查找相关政策。步骤 1 -- 动作：search_knowledge_base('Can you process my international tax refund in crypto?') 步骤 1 -- 观察：知识库中未找到匹配信息。步骤 2 -- 思考：知识库中没有答案。我应该升级这个问题。步骤 2 -- 动作：escalate_to_human('No KB match for: Can you process my international tax refund in crypto?') 步骤 2 -- 观察：已升级给人类代理。原因：No KB match for: Can you process my international tax refund in crypto? 步骤 3 -- 思考：我已经找到了答案。任务完成。结果：最终答案：已升级给人类代理。原因：No KB match for: Can you process my international tax refund in crypto?

===

answerable

from

knowledge

base

--

Thought

need

look

up

policy

before

can

answer

Action

'What is the refund policy?'

Refunds

available

within

days

of

purchase

found

Task

complete

Final

B

should

trigger

escalation

'Can you process my international tax refund in crypto?'

No

matching

information

has

escalate

this

'No KB match for: Can you process my international tax refund in crypto?'

Escalated

human

agent

KB

match

you

process

international

tax

crypto

看看两次运行之间的差异：查询 A 在两步内完成，而查询 B 则用了三步，并且查询 B 执行了一个动作 —— 升级 —— 这个动作并没有硬编码为“当退款查询提到加密货币时会发生什么”。相同的循环，相同的代码，产生了两个真正不同的步骤数量和顺序，因为模型在运行时根据观察到的内容决定了路径。这就是“没有预定义的代码路径”的实际、具体含义 —— 不是一句口号，而是一个可衡量的差异，即运行了多少步骤以及它们是什么。

这种模式的生产实现通常会将累积的思考/观察历史封装在一个“草稿本”中，并在将其反馈到循环之前对工具输出进行总结，因为将原始错误日志或大型 API 响应直接重新输入上下文往往会混淆下一步的推理，而不是帮助它。

自主多代理系统

在光谱的另一端，这种系统直接建立在上面的 ReAct 循环之上，只是嵌套了。在一个多代理设置中，一个协调器运行自己的 ReAct 循环，其中一些可用的“动作”是对其他代理的调用，每个代理内部都运行自己的完整 ReAct 循环。协调器推理出要委托的任务，委托它，观察结果，并继续 —— 正如上一节中单代理循环一样，只是其中一些“工具”是完整的代理，而不是简单的函数。

想象一下上一个例子中的 AVAILABLE_TOOLS 字典，只不过其中的条目不再是 search_knowledge_base 和 escalate_to_human，而是 research_agent、finance_agent 和 coding_agent —— 调用其中一个并不会返回一个简单的字符串；而是会启动该子代理自己的独立的“思考-行动-观察”循环，这个循环可能需要经过多个步骤之后才会将结果返回给协调器。没有人提前写明哪个子代理会被调用、调用的顺序是什么，或者它们各自会运行多少次。

Google Cloud 的文档将这种极端情况称为“swarm”模式 —— 一组没有中央协调器的协作代理，正因为它们之间的互动没有任何限制，所以能够产生出异常高质量、富有创造力的解决方案。但这种缺乏结构的方式也带来了风险：如果没有人为设计的互动限制，swarm 可能陷入无产出的循环，或者根本无法达成一致；而运行多个代理经过多轮互动的成本会迅速累积。

这正是在光谱上可预测性轴线偏离最远的一端。通过构造，确定性流水线每次都能产生相同的输出结构。而由自主代理组成的 swarm 则提供了灵活性，可以处理那些事先未被预料到的问题，但代价是无法提前预测它会做什么，或者需要多长时间才能完成。

为什么这种区别在实际生产中真的重要

这不是一个学术上的区别。它对团队实际交付的内容有直接、可衡量的影响。尽管围绕自主代理的宣传声势浩大，但 2025 年的生产实践表明，AI 工作流 —— 而不是完全自主的代理 —— 在实际部署中胜出：工作流仍然是成功生成式 AI 部署的主要模式，而完全自主的多代理系统在大多数领域之外仍然主要处于探索阶段。

原因直接映射到本文开头提到的可预测性轴线。代理系统本质上是非确定性的；相同的输入在不同运行中可能会产生不同的输出，这在受监管、可审计或高风险的流程中是一个严重的缺陷。如果一个流程必须逐步向合规团队或监管机构解释，那么默认情况下这不是代理的领域；它需要额外的防护措施和人工介入的检查点，才能被信任用于产生实际后果的场景。

在成熟的系统中，实际上正在出现的模式是混合型的，而不是非此即彼的选择。一个更高层次的代理设定目标并协调整体任务，而关键的、已被充分理解的计算仍然在由人类完全指定的确定性模块中运行。例如，一个医疗诊断系统可能会使用代理来解释模糊的症状并决定需要进行哪些检查 —— 这是真正的自主性，因为正确的检查顺序在事先是无法确定的 —— 而每个检查本身则通过一个经过验证的确定性流程运行，因为这个问题的这部分已经存在已知的正确路径，没有理由引入任何变数。

结论

“Agentic workflow”和“autonomous agent”描述的是同一连续谱的两个极端，而不是两种相互竞争的技术。这里所探讨的四个阶段——确定性、协调性、反应性以及自主多代理——并不是从差到好的排名。它们是针对同一个问题的不同答案：下一步由谁决定？这个决定是通过人类提前编写代码做出的，还是通过模型在运行时进行推理做出的？

确定性工作流通过构造提供了可审计性和可重复性；相同的输入每次都会走相同的路径，毫无例外。反应性和多代理系统则放弃了这种保证，以换取处理那些在事前根本无法预见其形态的问题的能力。这两种特性都不是免费的，也没有哪一种架构默认就是正确的。

在生产环境中表现良好的系统不会选择这个连续谱的某一极端，并在所有地方都应用它。它们会将问题的每个部分放置在该连续谱上真正需要的位置——在已知正确路径存在且可重复性重要的地方，采用固定的结构；而在那些本身就没有预定义正确路径的问题部分，保留真正的自主性。

更多相关内容

• 如何使用 Python 对时间序列数据集进行差分

• 如何去除趋势和季节性……

• 测试数据集和验证数据集的区别是什么？

• 机器学习中算法和模型的区别

• 反向传播和随机梯度下降的区别

• 参数和变量在机器学习中的区别是什么？