Agent、纯 LLM、Workflow 到底差在哪？一篇讲清楚“决策权“归谁-开发者社区

文章目录

- 先打个比方：把它们想成三种员工
- 纯 LLM：一次调用，一条直线
- Workflow：人把流程焊死，LLM 只是一颗螺丝
- Agent：把方向盘交给 LLM
- 一张图看清三种模式的控制流
- 一张表看懂关键差异
- 代码示例
- - 纯 LLM
  - Workflow（代码控制流程）
  - Agent（模型自主循环）
- 到底该怎么选？
- 三个最容易踩的误区
- 写在最后

做 AI 应用这两年，最容易被绕晕的一组词就是：纯 LLM、Workflow、Agent。

直接调一次 GPT 接口叫"用 AI"，用 LangChain 串几条链叫 Workflow，再加个循环和工具调用就摇身一变成了 Agent。很多文章把它们讲成三种越来越"高级"的形态，但越看越糊涂——它们到底是在比谁的模型大、谁的库新，还是真的有本质区别？

这篇文章不讲术语，只讲一件事：**下一步做什么，到底由谁决定。**把这一点想通，三者的边界、选型、坑就全都清晰了。

先打个比方：把它们想成三种员工

不看技术名词，先把抽象概念落到一个办公室场景里。

纯 LLM：一个嘴皮子极快、但坐在玻璃房里不能动的顾问。你隔着玻璃递纸条问他，他写纸条答你。他不能翻资料、不能查系统、不能算数，答完这一句就结束，不会主动追问。
Workflow：一个严格按 SOP 干活的流水线工人。第一步做什么、第二步做什么、在哪一步允许他说话，都是你提前写在操作手册里的。他非常靠谱，但手册里没写的事，他一律不会。
Agent：一个你给了一沓权限钥匙的新人。他自己看任务、自己决定先查哪个系统、自己调工具，做错了自己回头改，直到他觉得这事办完了，把结果交给你。

三种员工的能力上限都差不多（背后是同一个大模型），真正的差别是决策权在谁手里。

纯 LLM：一次调用，一条直线

最简单的形态：你把 Prompt 发过去，模型吐一段文字回来，结束。没有记忆、没有工具、没有循环。

**举个最常见的例子：**你打开 ChatGPT，贴进去一段周报，说"帮我润色得正式一点"。它输出一段润色后的文字，任务就完成了。

它的几个硬限制，你必须心里有数：

不能动：不能自己去查你的数据库、不能搜网页、不能调计算器——涉及实时数据或精确计算，它只能靠训练时的记忆瞎编。
不能续：上一轮和这一轮之间没有自动状态，多轮对话的上下文要你自己拼进 Prompt。
不能改：答得不对，它不会自己意识到，只会再顺着你的话往下编一段。纠错的责任 100% 在你。

**适合什么场景：**一次性的生成、改写、翻译、总结、头脑风暴、文案打磨。凡是"给一段输入、要一段文字输出、中间不需要查任何外部东西"的活，纯 LLM 就是最优解，别上框架。

Workflow：人把流程焊死，LLM 只是一颗螺丝

当你想让 LLM"查完资料再回答"，问题就来了：谁去查资料？什么时候查？查回来的东西塞到哪里？

Workflow 的答案是：这些步骤全部由程序员用代码写死，串成一条有向无环图（DAG）。LLM 只是图里其中一个节点，在固定位置被调用一次或几次。

举个你大概率写过的例子——RAG 知识库问答：

接收用户问题
用 BM25 + 向量混合检索，从文档库里召回 top-k 片段
把片段和问题拼进一个写死的 Prompt 模板
调一次 LLM 生成答案
后处理（去引用标记、格式化）后返回给用户

用代码表达大概就是这样：

defanswer(question):context=hybrid_retrieve(question,top_k=5)# 节点1：检索prompt=RAG_TEMPLATE.format(# 节点2：拼 prompt（模板写死）context=context,question=question)result=llm.invoke(prompt)# 节点3：LLM 生成returnpostprocess(result)# 节点4：后处理

注意一个关键细节：LLM 根本不知道整个流程，它只看到你喂给它的那一段 Prompt。它不知道你查了数据库，也不知道后面还要格式化，它就是被安排在流水线中间的一颗螺丝。

它的优点非常实在：

每一步做什么、为什么做，程序员完全看得见、改得动。
结果可复现——同样的输入，走同样的节点，输出基本稳定。
出错好 debug：是检索没召回？还是 Prompt 没拼对？一眼能定位。

**它的死穴也很明显：**用户突然问一句"顺便帮我把这个答案发到我邮箱"，系统直接抓瞎——因为代码里没写"发邮件"这个节点。凡是流程外的请求，Workflow 一律不会处理。

Agent：把方向盘交给 LLM

那能不能让 LLM 自己决定"现在该查资料还是该发邮件"？这就是 Agent。

Agent 的核心结构是一个循环，业界叫 ReAct（Reason + Act）：

LLM 看一眼用户目标和当前状态，思考下一步该干嘛
它选择一个工具（搜索、计算器、数据库、邮件……）并执行
它观察工具返回的结果
判断：够了吗？够了就输出最终答案；不够就回到第 1 步再来一轮

同样一个需求，三种做法对比一下就清楚了：

用户说：“帮我调研一下招商银行最近的股息情况，和工商银行做个对比，给我一个表格。”

纯 LLM：凭训练数据里的印象给你编几个数字，很可能是过时的、甚至是错的。
Workflow：你得提前写死四个节点——查招行股息 → 查工行股息 → 算股息率 → 拼表格。少写一个节点，这事就干不完。
Agent：它自己想——先搜招行年报，发现数据不全，再调财经 API；发现股息率口径不对，换个字段重算；发现两家单位要统一，自己调计算器；最后拼出表格。整个过程走了几步、调了哪几个工具，你事先并不知道。

Agent 的威力在这里：任务的路径不再需要人提前枚举，模型根据中间结果动态决定。

但代价也同样明显：

贵：每一步都要多轮 LLM 调用，token 成本是 Workflow 的几倍甚至几十倍。
飘：它可能绕远路、可能死循环、可能为了"完成任务"而强行调用不该用的工具。
不可复现：同样的问题，今天走 3 步、明天走 7 步，输出可能都不一样。

一张图看清三种模式的控制流

把上面三节压缩成一张图，差异一眼可见：左边是一条直线，中间是焊死的流水线，右边是一个带回路的循环。

纯LLM、Workflow、Agent三种模式的控制流对比图：纯LLM是一条直线，Workflow是人写死的DAG，Agent是LLM在中间循环调用工具。

看图的关键不是看节点多少，而是看箭头是谁画的：纯 LLM 没有箭头分支；Workflow 的箭头是程序员在代码里画死的；Agent 的箭头是 LLM 在运行中临时决定的。

一张表看懂关键差异

维度	纯 LLM	Workflow	Agent
谁决定下一步	无（一次到位）	程序员（代码写死）	LLM 自己（运行时决定）
流程是否固定	只有一步	固定 DAG，可预测	动态路径，不可预测
能否调工具	不能	在指定节点硬编码调用	按需动态选择工具
出错怎么办	靠人重新问	节点失败即中断，需人工修复流程	观察结果后自我调整、重试
可控性	高（但能力弱）	高，可审计、可复现	低，必须加护栏
Token 成本	1 次调用	固定 N 次	不固定，可能 N×3~N×10
典型场景	润色、翻译、总结、头脑风暴	RAG 问答、合同抽取、客服机器人	自动调研、代码修复、运维排障
典型实现	直接调 OpenAI / Claude API	LangChain Chain、Dify Workflow、Coze 工作流	LangGraph ReAct、AutoGPT、Claude Agent SDK

代码示例

纯 LLM

# 仅单次调用prompt="写一份周报"resp=llm.invoke(prompt)print(resp.content)

Workflow（代码控制流程）

# 步骤、分支全部写死user_input=input()# step1 LLM意图分类intent=llm.invoke(f"分类：{user_input}")ifintent=="查订单":order_data=query_order_tool()# 代码决定调用工具ans=llm.invoke(f"整理订单结果：{order_data}")elifintent=="退款":res=refund_api()ans=llm.invoke(f"退款结果：{res}")else:ans="转人工"print(ans)

Agent（模型自主循环）

# 开发者只给目标+工具列表，模型自己循环goal="安排上海出差，预算3000周五回"tools=[search_train,search_flight,search_hotel]agent=ReActAgent(llm,tools)result=agent.run(goal)# 内部自动循环思考、调用工具，直到模型判断完成print(result)

到底该怎么选？

别被"Agent 是未来"这种话带节奏。落到项目里，选型就三个问题：

**任务是不是一次性能干完？**是 → 纯 LLM，别上任何框架。
**步骤能不能提前写死、写死了会不会丢场景？**企业知识库问答、合同要素抽取、标准化客服——这些流程稳定、要求结果可审计，用 Workflow 是最稳的。
路径根本无法预先枚举——比如"帮我排查这个线上报错"、“帮我调研一下这个行业并出报告”——才上 Agent。

而一旦上了 Agent，下面三件事必须做，否则就是给自己埋雷：

工具白名单最小化：只给它完成任务必需的工具，不给"删除数据库""发全员邮件"这种核武器权限。
步数上限：硬编码 max_iterations，防止它死循环烧钱。
高危动作人工确认：发邮件、转账、删数据这类动作，执行前必须弹给人确认。

说句大实话：**80% 的业务场景，Workflow 就够了。**Agent 是为那 20% 路径真的不确定的场景准备的，不是拿来替代所有 Workflow 的。

三个最容易踩的误区

误区一：Workflow 里加个 if 分支就是 Agent 了。

不是。分支条件是你写的（比如"如果用户问价格就走节点 A，否则走节点 B"），LLM 没有决策权，它还是被安排的。真正的 Agent，是 LLM 自己在那一步决定"我现在该调哪个工具"，而不是你替它决定。

误区二：Agent 是 Workflow 的升级版，应该全面替代。

它们不是替代关系，而是一个连续谱。生产上最常见的形态是混合体：主干是一条 Workflow，在某个复杂节点内部跑一个小 Agent。比如客服机器人主干是 Workflow（识别意图 → 查订单 → 生成回复），但"用户投诉了怎么办"这个节点，交给一个小 Agent 去读工单历史、查退款政策、决定补偿方案。

误区三：Agent 越 Autonomous 越好。

落地时恰恰相反。自主度越高，越要把护栏焊死。工具权限最小化、关键动作人工确认、全链路日志可回溯——这些不是限制 Agent，是让它敢在生产环境跑起来的前提。