工作流和 Agent 怎么选？
一句话回答
工作流的执行路径是开发者预先写好的，每一步都可以调用大模型，但下一步做什么由代码决定；Agent 由模型在运行时动态决定下一步。工作流可控、可预测，成本和延迟稳定，便于测试；Agent 灵活，能处理路径无法预先确定的开放任务，但成本、延迟和结果的波动都更大。常见的工作流模式有链式、路由、并行、编排者-执行者、生成-评估循环。选型原则是从最简单的方案开始：单次调用够用就不上工作流，工作流够用就不上 Agent。
详细解析
对比
| 维度 | 工作流 | Agent |
|---|---|---|
| 下一步由谁决定 | 代码 | 模型 |
| 可控性 | 高，每一步都在预期之内 | 较低，可能走出意料之外的路径 |
| 可预测性 | 同样的输入走同样的路径，便于测试和复现 | 同一个任务每次的步骤可能不同 |
| 成本 | 调用次数固定，容易预估 | 调用次数取决于任务，波动大 |
| 延迟 | 稳定，还能通过并行优化 | 步数不定，可能很长 |
| 灵活性 | 只能处理设计时想到的情况 | 能应对开放任务和意外情况 |
| 出错排查 | 能定位到具体步骤 | 要分析整条执行轨迹 |
常见的工作流模式
| 模式 | 做法 | 例子 |
|---|---|---|
| 链式 | 上一步的输出是下一步的输入，中间可以插入代码检查 | 先写大纲，检查通过后再写正文 |
| 路由 | 先分类，再交给专门的流程、提示词或模型 | 客服问题按退款、物流、技术支持分流 |
| 并行 | 拆成独立的部分同时处理，或者同一任务跑多次再投票 | 内容审核的多个维度同时检查 |
| 编排者-执行者 | 由模型拆出子任务，分给执行者处理，再汇总 | 一次改动涉及多个文件，由模型决定改哪些 |
| 生成-评估循环 | 一个负责生成，一个按标准评估并给出意见，循环到达标 | 翻译后由评审检查术语和语气 |
链式、路由、并行的具体写法见 复杂任务怎么拆成多步 Prompt。编排者-执行者模式里，子任务是模型动态拆出来的，已经有了一些 Agent 的特点，但"拆分、执行、汇总"的整体结构仍然是固定的。这几种模式的划分参考了 Anthropic 的文章《Building Effective Agents》。
怎么选
按这几个问题判断：
- 能不能画出流程图？ 用有限的分支就能覆盖绝大多数情况，就用工作流
- 步骤数取决于中间结果吗？ 比如排查线上问题、调研一个陌生话题，走几步、走哪条路事先说不清，适合 Agent
- 出错的代价多大？ 错误难以发现或无法挽回时，优先选可控的工作流，或者给 Agent 加上人工确认
- 成本和延迟有没有硬性要求？ 有的话，工作流更容易满足
演进路径一般是：单次调用 → 工作流 → 局部使用 Agent → 完整的 Agent。很多生产系统是混合的：主流程是工作流，其中某个开放的环节交给一个受限的 Agent（限定工具、限定步数）。Agent 的基本概念见 什么是 Agent。
代码示例
混合架构：工单处理的主流程是工作流，只有复杂的技术问题交给 Agent。llm.chat 是伪接口，这里按 Schema 返回结构化结果，做法见 怎么让大模型稳定地输出 JSON：
import { z } from 'zod'
async function handleTicket(ticket: { id: string; text: string }) {
// 第 1 步：分类，一次模型调用，输出限定在几个类别里
const { category } = await llm.chat({
messages: [{ role: 'user', content: `给这条工单分类：${ticket.text}` }],
schema: z.object({ category: z.enum(['refund', 'shipping', 'technical', 'other']) }),
})
// 第 2 步：路由，走哪条路径由代码决定
switch (category) {
case 'refund':
return refundWorkflow(ticket) // 固定流程：查订单 → 校验退款规则 → 生成退款单 → 人工审核
case 'shipping':
return shippingWorkflow(ticket)
case 'technical':
// 只有这类开放问题交给 Agent：工具只读，步数有上限
return runAgent({ input: ticket.text, tools: [searchDocs, readLogs], maxSteps: 8 })
default:
return escalateToHuman(ticket)
}
}面试官可能追问
已经上线的 Agent 效果不稳定，怎么改进？
先分析执行轨迹，找出高频的固定路径，把这部分改成工作流，Agent 只处理剩下的长尾情况。同时精简工具、限定步数，建立评测集，每次改动后跑一遍回归，用完成率和成本的数据判断改进是否有效。
工作流里的每一步都要用大模型吗？
不需要。能用代码确定的事情，比如格式校验、数据库查询、规则判断，就用代码完成；大模型只用在需要理解或生成自然语言的环节。这样更便宜、更稳定，也更容易测试。
需求经常变，工作流改起来麻烦，是不是用 Agent 更好？
不一定。工作流可以通过配置化、可视化编排降低修改成本；Agent 改提示词看起来简单，但效果难以预测，每次修改都要跑评测回归。需求变化频繁，不等于执行路径无法预先确定，选型的关键还是任务本身的不确定性。
易错点
- 认为 Agent 比工作流"更先进"，什么场景都想用 Agent
- 以为工作流就是不用大模型。工作流的每一步都可以调用大模型，固定的只是执行路径
- 只比较灵活性，忽略了可测试性、成本和出错后的排查难度
AI 模拟面试官
用自己的话回答，AI 对照参考答案打分、指出遗漏，再追问，最多 3 轮
这道题你掌握了吗？
选一个最接近的状态，没掌握的题会出现在"我的进度 · 待复习"里。
学习记录暂存在本机浏览器。登录后自动同步到账号，换设备也能看到。