很多人把"用 LLM 做事"都叫 Agent,但严格上 Anthropic 的区分是——
- Workflow = 执行路径由代码预先写死
- Agent = 由 LLM 动态决定下一步
核心区别在控制权掌握在谁手里。现实中很多标着 "Agent" 的产品,深入看其实更接近 Workflow,不过两者本身并无高下之分,真正重要的是给任务找到更合适的解决方案。
6 维对比
| 维度 | Workflow | Agent |
|---|---|---|
| 控制权 | 代码预定义,同输入必走同一路径 | LLM 动态决策,可能需要评测验证 |
| 执行方式 | 工具顺序固定,错误走预设分支 | 工具按需选择,模型可尝试自我修复 |
| 状态与记忆 | 显式状态机,节点跳转清晰 | 隐式上下文,状态在对话历史中累积 |
| 维护成本 | 改流程需改代码并重新部署 | 调整系统提示即可,无需重新部署 |
| 可观测性 | 日志定位节点,延迟可预估 | 需完整执行记录理解决策链,轮数不固定 |
| 人机协作 | 人在预设节点介入 | 人在任意轮次介入或接管 |
| 适用场景 | 流程固定、输入边界清晰 | 需要中间推理与灵活判断 |
五种 Workflow 模式
Anthropic 在 Building Effective Agents 里把"非 Agent"的 LLM 应用归纳成 5 种 Workflow 模式:
1. Prompt Chaining(提示链)
把一个任务拆成多个步骤,每一步的输出作为下一步的输入,串成一条链。每一步用同一个 LLM 但用不同的 prompt。
In → LLM Call 1 → Output 1 → Gate ─ Pass → LLM Call 2 → Output 2 → LLM Call 3 → Out
└─ Fail → Exit
适用:步骤明确、可预测的任务(如"先翻译再润色再校对")。
2. Routing(路由)
一个"分流器"先判断输入属于什么类别,然后把它转给专门处理这类问题的下游模块。
┌→ LLM Call 1 ┐
In → LLM Call ├→ LLM Call 2 ├→ Out
Router └→ LLM Call 3 ┘
适用:输入有明确分类、不同类别需要不同处理(如客服系统分流"退款 / 技术支持 / 投诉")。
3. Parallelization(并行)
把同一个任务拆给多个 LLM 并行执行,最后汇总结果。两种子模式:
- 分片:把一个大任务拆成几小份,并行处理
- 多视角:让多个 LLM 从不同角度看同一个任务
┌→ LLM Call 1 ─┐
In → ├→ LLM Call 2 ─→ Aggregator → Out
└→ LLM Call 3 ─┘
适用:任务可以并行(提速)或需要多视角投票(提质)。
4. Orchestrator-Workers(编排-执行)
一个"主控 LLM"负责拆解任务和协调,多个"工人 LLM"负责具体执行。跟 Parallelization 的区别是——这里主控动态决定要拆成几个子任务、给谁做。
┌→ LLM Call 1 ─┐
In → Orch ─→├→ LLM Call 2 ─→ Synthesizer → Out
└→ LLM Call 3 ─┘
适用:任务的拆解方式无法预先确定。这其实已经接近 Agent,区别在于 Orchestrator 走的是固定模板而非自由推理。
5. Evaluator-Optimizer(评估-优化)
一个 LLM 负责"生成",另一个 LLM 负责"评估"。两个 LLM 像"作者和编辑"一样循环迭代,直到评估方满意为止。
Solution
In → LLM Call ────────────────→ LLM Call ──Accepted──→ Out
Generator ←─────────────── Evaluator
Rejected + Feedback
适用:评估标准明确、质量要求高的任务(如代码生成、复杂文档撰写)。这本质就是 Reflection 机制的双 Agent 实现,详见 Agent规划与反思。
Agent 分辨口诀(5 问)
如果你不知道要不要做 Agent,回答这 5 个问题——
| # | 问题 | 如果回答是"不知道"或"不需要"的含义 |
|---|---|---|
| 1 | 这个需求每次执行的流程都不一样吗? | 流程一样 → 用 Workflow |
| 2 | 下一步做什么需要根据上一步的结果决定吗? | 不需要 → 用 Workflow |
| 3 | 用户能接受 3 分钟以上的等待吗? | 不能 → 重新考虑 |
| 4 | 单次任务的预算能接受 1 元以上吗?(以 Claude Sonnet 4.6 约 $3/M tokens 计) | 不能 → 用更便宜方案 |
| 5 | 出错时有降级方案吗? | 没有 → 别上线 |
5 个问题如果有 3 个以上是"否",那基本就别做 Agent 了。
Agent 模式选择决策树
任务类型
│
┌─────────────────┬───────┴────────┐
↓ ↓ ↓
单步就能完成 多步但路径固定 多步且路径不固定 → Agent
│ │ │
↓ ↓ 需要调用外部工具? → +Tool Use
不需要任何模型 Workflow 任务超过 3 步? → +Planning
直接 LLM 调用 质量要求高 + → +Reflection
评估标准明确?
Context 不够 / → +Multi-Agent
有明确分工 /
可以并行?
关键判断:先判断是否要走 Agent 路径,再决定 Agent 要叠加哪些能力。每加一个能力都意味着成本和不可预测性上升,因此叠加要克制。
实战分组拆解模板(PM 训练用)
根据用户访谈拆解一个 Agent 产品时,从 5 个维度问:
- LLM:你们打算用什么模型?为什么?
- Memory:这个 Agent 该记什么?记到哪里?
- Planning:一次任务要拆成几步?要给用户看步骤吗?
- Tools:列出核心的工具
- Action 分级:哪些动作高风险需要用户确认?
5 个维度对应的深入概念页:Agent五要素技术定义 / Agent记忆体系 / Agent规划与反思 / Agent工具与行动
相关页面
→ Agent五要素技术定义 → Agent规划与反思 → Agent工具与行动 → Multi-Agent协作 → Function Calling与MCP → 六大成熟AI应用场景(垂直 Agent 是其中一类典型应用) → AIPM课程 Day9 → AIPM课程 Day10