企业官网建设流程全解析

Agent 和 Workflow的区别

Workflow 强调开发者编排流程，Agent 强调模型自主决策。

在实际开发中这两个概念经常被搞混。一个系统里调了几次大模型，用了几个工具，很多人就以为它是 Agent。一个简单的判断方法是：如果去掉 LLM 后，系统主体流程依然存在，只是少了一个智能节点，那么它更接近 Workflow；如果去掉 LLM 后，系统失去了自主规划和决策能力，那么它更接近 Agent。

目录

• Workflow 是什么
• Agent 是什么
• 核心区别
• 代码对比
• 怎么选
• 生产级系统怎么用它们
• 小结

Workflow 是什么

Workflow 是一条开发者预先设计好的执行路径。每个节点做什么、节点之间怎么串联、什么条件走哪条分支，这些都像我们平时写后端逻辑一样固定在代码里。模型在这个流程里只是其中一个环节，负责处理需要"理解"的部分，但它不决定流程走向。

需要强调一点：Workflow 并不意味着不用大模型。一个 Workflow 可以包含多个 LLM 节点，只不过这些节点仍然按照开发者预先设计好的流程执行。

一个典型的 Workflow 长这样：

用户输入 │ ▼ [意图识别] ← LLM 在这里做分类 │ ├── 查询类 → [构造 SQL] → [执行查询] → [格式化输出] │ ├── 闲聊类 → [调用聊天模型] → [返回回复] │ └── 任务类 → [参数提取] → [调用 API] → [返回结果]

具体每一个分支的每一步都是确定的。虽然模型可以知道整个流程，但流程本身并不是由它决定的，而是由代码决定的。走哪条分支是代码根据模型输出来判断，不是模型自己选择。

用代码表示：

defworkflow(user_input:str)->str:# 第一步：LLM 做意图识别（模型只是分类器）intent=llm.classify(user_input,categories=["query","chat","task"])# 第二步：根据意图走不同分支（代码写死的逻辑）ifintent=="query":sql=llm.generate_sql(user_input)result=db.execute(sql)returnformat_output(result)elifintent=="chat":returnllm.chat(user_input)elifintent=="task":params=llm.extract_params(user_input)returnapi.call(params)

模型在这个流程里是"被调用"的角色。代码问它一个问题，它回答然后代码根据回答决定下一步。模型本身没有决策权。

Agent 是什么

Agent 的核心区别在于：模型自己决定下一步做什么。

给 Agent 一组可用工具和一个目标，它自己规划执行路径。是都需要调工具，下一步需要做什么，这些决策全部由模型在运行时做出。开发者不预设流程，只提供能力和约束。这种"自主决策"并不是无限制的。模型仍然只能在开发者提供的工具、提示词和约束范围内进行规划。Agent 的自由是在开发者给他的制度下的自由，也不是完全的想做什么就做什么。

一个最小的 Agent 循环：

defagent(query:str)->str:messages=[{"role":"user","content":query}]tools=[bash_tool,read_file_tool,write_file_tool]whileTrue:# 模型决定下一步：调工具还是直接回复response=call_llm(messages,tools)messages.append(response)# 模型觉得任务完成了，退出循环ifresponse.stop_reason!="tool_use":break# 模型想调工具，执行并把结果喂回去fortool_callinresponse.tool_calls:result=execute(tool_call)messages.append(result)returnextract_text(messages[-1])

和 Workflow 对比，就很容易看出区别。Workflow 里模型是"被调用的节点"，Agent 里模型是"做决策的核心"。Workflow 的流程是开发者编排的，Agent 的流程是模型运行时生成的。

Workflow： 开发者写流程 → 模型在某个节点执行 Agent： 开发者给工具 → 模型自己决定怎么用

核心区别

Workflow 的执行路径通常是确定的，模型在里面当打工仔；Agent 的执行路径由模型动态规划，模型在里面做主。

代码对比

用一个实际场景来对比：用户说"帮我在项目里找到所有 TODO 注释，生成一份报告"。

Workflow 的做法

开发者预先设计好步骤，每一步都是写死的：

deftodo_report_workflow(project_path:str)->str:# 第一步：用 find 命令搜索 TODOfiles=subprocess.run(["grep","-r","TODO",project_path],capture_output=True,text=True).stdout# 第二步：LLM 分类每个 TODO 的优先级priorities=llm.classify_todos(files)# 第三步：按优先级排序sorted_todos=sorted(priorities,key=lambdax:x["priority"])# 第四步：LLM 生成报告report=llm.generate_report(sorted_todos)returnreport

流程是：搜索 → 分类 → 排序 → 生成报告。每一步做什么、用什么工具，全在代码里。模型只负责"分类"和"生成报告"两个节点的工作。

Agent 的做法

开发者只提供工具，让模型自己决定怎么完成任务：

deftodo_report_agent(project_path:str)->str:messages=[{"role":"user","content":f"在{project_path}里找到所有 TODO，生成报告"}]tools=[bash_tool,read_file_tool,write_file_tool]whileTrue:response=call_llm(messages,tools)messages.append(response)ifresponse.stop_reason!="tool_use":breakfortool_callinresponse.tool_calls:result=execute(tool_call)messages.append(result)returnextract_text(messages[-1])

Agent 拿到任务后，可能先用bash跑grep，发现结果太多，决定换一种方式，先用find找到所有.py文件，再逐个read_file检查。也可能它觉得报告应该分类展示，于是自己决定按文件分组。整个过程没有预设路径，模型根据中间结果实时调整策略。两种方式都能完成任务，但背后的思路是不同的。

怎么选

Anthropic 在《Building Effective Agents》中提出了一个非常务实的建议：When possible, prefer workflows over agents.中文可以理解为：能用 Workflow，就尽量不要使用 Agent。

这不是说 Agent 不好，而是说 Agent 的灵活性是有代价的。代价包括：

• 不确定性。每次执行路径可能不同，同样的输入不一定得到同样的输出，测试覆盖率很难保证。
• 成本更高。Agent 的循环意味着多次 LLM 调用，Token 消耗比 Workflow 的固定几次调用要多。
• 调试困难。出了问题你很难复现，因为模型下次可能走另一条路。

什么时候该用 Workflow：

• 流程是固定的，步骤不会变
• 需要高可靠性和可预测性
• 对延迟和成本敏感
• 需要通过合规审计

什么时候该用 Agent：

• 任务是开放性的，无法预先规划所有路径
• 需要根据中间结果动态调整策略
• 任务复杂度高，硬编码流程会非常臃肿
• 用户需求多样，无法穷举所有分支

一个判断标准：如果你能够在开发前就把主要执行路径画出来，那么 Workflow 往往更合适；如果执行路径需要根据运行时信息不断调整，那么 Agent 更适合。

生产级系统怎么用它们

说了这么多区别，实际上两者的边界没那么清晰。很多生产级系统是混合架构：外层用 Workflow 做编排，保证主流程可控；内层用 Agent 处理复杂子任务，保证灵活性。

Workflow（外层编排） │ ├── Step 1：意图识别（确定性） │ ├── Step 2：调用 Agent 处理复杂子任务 │ │ │ └── Agent Loop（动态决策） │ ├── 工具调用 A │ ├── 工具调用 B │ └── 返回结论 │ ├── Step 3：格式化输出（确定性） │ └── 返回结果

Claude Code 就是一个典型的例子。它可以看作一种 Workflow + Agent 的混合架构：外层负责权限校验、上下文管理等确定性流程；真正完成编码任务时，则由 Agent 自主规划工具调用和执行策略。Workflow 保证了入口和出口的可控性，Agent 保证了中间执行的灵活性。

所以与其纠结"这到底算 Agent 还是 Workflow"，不如想清楚一个问题：你系统里的不确定性应该放在哪一层。流程层面的不确定性交给 Agent，节点层面的确定性留给 Workflow。

小结

Workflow 决定"流程怎么走"，Agent 决定"任务怎么完成"。生产环境里，两者通常不是互相替代，而是互相配合。Workflow 保证系统可控，Agent 提供系统的智能性。回到开头的判断方法：如果你的"Agent"去掉 LLM 之后，主体流程依然能跑，只是少了一个智能节点，那它更接近 Workflow。如果去掉 LLM 之后，系统失去了自主规划和决策的能力，那它更接近 Agent。