面试官：Workflow 和 Agent 的本质区别到底是什么？

发布时间：2026/10/26 18:22:38

一、开场：这是整个系列的核心题

前两篇我们铺了两块砖：

第 1 篇：Tools 是能力单元，两种架构都要用它；
第 2 篇：Workflow 是预定义代码路径，Anthropic 给了五种模式。

现在回到题干本身。阿里、腾讯爱问这题，不是想听定义——它想筛掉一类人：接到需求就上 Agent，跑不通再堆 prompt 的人。

先给一句话答案，后面全部围绕它展开：

控制流写在代码里，是 Workflow；控制流由模型在运行时生成，是 Agent。

再给一个比定义更好用的判断标准：

你能不能画出这个系统的完整流程图？
画得出来（哪怕分支很多）→Workflow
画不出来，因为路径是模型现场决定的 →Agent

这两句话背下来，这题就答对八成了。

二、拆开看：本质区别在三个层次

层次一：下一步由谁决定

这是最硬的那条线。

Workflow	Agent
谁决定下一步	你，在写代码的时候	模型，在运行时
同样输入 → 同样路径？	是	不一定

Anthropic 的原话：Workflow 是 “systems where LLMs and tools are orchestrated throughpredefined code paths”；Agent 是 “systems where LLMsdynamically direct their own processesand tool usage”。

这是二元判断，不是程度问题。只要"下一步做什么"是你用 if/else 写死的，哪怕里面塞了二十次 LLM 调用，它也是 Workflow。反过来，只要模型能自己决定"我还要不要再调一次工具"，哪怕只有三步，它已经是 Agent 了。

层次二：失败模式不同

这条最容易被忽略，但它是生产事故的分水岭。

Workflow 的失败是显式的：某个节点报错，异常栈直接指到第 3 步，你能定位。
Agent 的失败是静默的：它不会报错，而是自信地做错**——沿着一条偏掉的路径一路跑完，最后给你一个看起来很合理的错误答案。**

为什么？因为 Agent 的错误会在循环中累积：第 1 步的小偏差，会变成第 2 步的错误前提，到第 5 步已经离题万里。而整个过程中没有任何一个环节会抛异常。

所以 Agent 必须额外配一套"偏航检测"，这是 Workflow 不需要的。

层次三：成本结构不同

Workflow：步数固定，单次 token 消耗稳定 →乘十万次调用，是一份可以规划预算的数字。
Agent：单次成本是随机变量。它可能三步搞定，也可能绕二十步——你没法预测，只能设上限。

这个差别在规模化时是致命的。一个 Agent 单次贵 3 倍听起来能接受，但它的方差会让你的成本预算失去意义。

三、关键认知：Agent 不是 Workflow 的升级版

这是本题最该主动说出来的一句。

很多人默认"Workflow 是初级，Agent 是高级，先把 Workflow 跑通再升级成 Agent"。错。它们是两种不同形状，没有高下。

Anthropic 说得很直白：

最成功的实现，用的不是复杂框架，而是简单、可组合的模式。

还给了一条明确的选型建议：

Find the simplest solution possible, and only increase complexity when needed —which sometimes means not building agentic systems at all.

有时这意味着根本不该上 Agent 系统。

我的观察：滥用 Agent 是这两年最常见的工程事故。一个明明是四步固定流程的任务，硬要做成 Agent，三个月后拆掉换回 Workflow，成本降 60%、准确率还涨——这种事我见过不止一次。

为自主性而自主性，是架构选型的第一杀手。

那 Agent 存在的意义是什么？

既然 Workflow 这么好，什么时候必须上 Agent？三个条件，通常要同时满足：

步骤数无法预先确定——Anthropic 的原话是"开放式问题，难以或不可能预测所需步数，且无法硬编码固定路径"；
下一步依赖上一步的真实结果——研究、排查、调试这类；
结果可以被验证——这一点常被漏掉但极关键。Anthropic 特别推崇编程 Agent，原因就是代码可以通过自动化测试验证**。**

反过来，只要你能把步骤写下来，就该用 Workflow。判断方法很朴素：如果一个新人能照着 checklist 做下来，Workflow 也能。

四、代码：Spring AI 2.0 里两者的样子

Workflow：控制流是普通 Java 代码

// 路径完全由代码决定，模型只是其中几个节点 public String handleTicket(String ticket) { Route r = classifier.classify(ticket); // 节点 1 var ctx = dataService.fetchParallel(r); // 节点 2（并行取数） String draft = generator.draft(ctx); // 节点 3 if (!guardrail.pass(draft)) { // 程序化检查点 throw new GuardrailException("合规未通过"); } return draft; }

每一步做什么、出错怎么办，都在代码里。失败时异常栈直接指向具体节点。

Agent：控制流交给 Advisor 循环

ChatClient agent = ChatClient.builder(chatModel) .defaultSystem("你是排障助手，自主决定查什么、什么时候收尾。") .defaultTools(new DiagnoseTools()) .build(); // 一次调用，框架内部循环 N 轮，轮数由模型决定 String answer = agent.prompt() .user("生产环境订单接口 P99 突然飙高，帮我定位") .call() .content();

这里没有任何一行代码写"下一步做什么"——是ToolCallingAdvisor驱动循环，模型每轮决定调哪个工具、还要不要继续。

想加护栏，就继承ToolCallingAdvisor重写钩子（第 1 篇讲过四个扩展点）：

@Override protected ChatClientResponse doAfterCall(ChatClientResponse r, CallAdvisorChain chain) { if (++iterations > MAX_ITERATIONS) { throw new IllegalStateException("超过最大轮次，熔断"); } return r; }

注意这个MAX_ITERATIONS——它不是优化项，是必需品。没有停止条件的 Agent 就是一笔 unbounded 的账单。

五、上 Agent 的四道护栏

如果你判断确实该上 Agent，这四道必须提前配好，缺一不可：

1. 停止条件（三重）
最大轮次 + 预算上限 + 超时。三者都要有——轮次防不住单次超长调用，预算防不住单轮巨贵，超时防不住卡死。

2. 沙箱隔离
Anthropic 明确建议：在沙箱里充分测试之后，才让 Agent 碰真实系统。它会尝试你没预料到的操作，这是自主性的必然结果。

3. 人工检查点
高风险操作必须暂停确认：写库、付款、删除、对外发送。别为了"全自动化"省掉它——在关键节点请求确认的自主系统，实际表现比一味追求全自动的更好。

4. 可观测
记录每一步的决策轨迹。没有这个，出问题你面对的是一团概率云，根本无法定位。

一条演进路线

正确姿势不是二选一，而是从简单出发，被需求推着往上走：

单次 LLM 调用 + 检索 ↓Workflow（提示链 / 路由 / 并行） ↓编排器-工作者 ↓简单 Agent（单循环 + 工具） ↓自主 Agent（循环 + 评估 + 记忆）

升级的信号是"下面那级撑不住了"，不是"我想用新技术"。

六、两个高频追问

追问一：编排器-工作者算 Workflow 还是 Agent？

这是个好问题，答案在边界上：Anthropic 把它归为Workflow，因为子任务虽然由编排器现场决定，但循环不会无限进行下去。不过它也确实已经很接近 Agent 端了。

结论：这是一条光谱，不是一堵墙。能说出"光谱而非二元"，比硬给答案更显功力。

追问二：用了 Agent 框架就等于上 Agent 了吗？

不是。Anthropic 特意提醒过：框架会加一层抽象，把底层的 prompt 和响应盖住，反而更难调试，还容易诱使你在简单方案足够时把系统搞复杂。

判断依据永远是你自己的控制流归谁，不是你引了什么依赖。

七、收尾：30 秒标准答案

Workflow 和 Agent 的本质区别只有一个：控制流归谁。Workflow 是预定义代码路径编排 LLM 和工具，下一步做什么由我写代码时决定；Agent 是 LLM 动态决定自己的流程和工具使用，下一步由模型在运行时生成。判断方法很朴素——你能不能画出这个系统的完整流程图，画得出是 Workflow，画不出才是 Agent。
更深的区别在失败模式和成本结构：Workflow 显式失败，能定位到具体节点；Agent 是静默跑偏、自信地做错，错误还会在循环里累积。成本上 Workflow 可预算，Agent 的单次成本是随机变量，只能设上限。
关键认知是Agent 不是 Workflow 的升级版，它们是不同形状没有高下。Anthropic 的原话是最简单方案优先，有时这意味着根本不该上 Agent。该上 Agent 的三个条件：步骤数无法预先确定、下一步依赖上一步的真实结果、结果可以被验证——编程 Agent 就是因为有自动化测试能验证。如果确实要上，四道护栏必须配齐：停止条件三重（轮次+预算+超时）、沙箱隔离、人工检查点、可观测。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～