Appearance
44. 什么时候工作流比 Agent 更合适？
难度 P1 高频 · 岗位 应用 · 频率 ★★★★☆ · 预计阅读 8 min 公司 Anthropic · LangChain 相关题 Q47 Agent 边界 · Q56 Manus · Q61 反射模式
本题阅读地图
- 面试场景还原 — 1 min
- TL;DR 速记 — 30 sec
- 图解 — 30 sec
- 详细解析 — 5 min
- 4.1 核心区别：确定性 vs 灵活性
- 4.2 工作流的核心优势
- 4.3 Agent 的核心优势
- 4.4 选型决策框架
- 4.5 混合架构：Agentic Workflow
- 常见踩坑与反例 — 1 min
- 面试官可能继续追问 — 1 min
面试场景还原
👔面试官：假设你要做一个客服系统，用户的问题是"我昨天买的东西什么时候发货？"，这个需求应该用工单系统固定流程处理，还是上 Agent？
🙋♂️我：这看起来是固定的查询流程，用工作流更合适？
👔面试官：对。那如果用户说"我想买一台适合旅行的相机，能推荐一下吗？"这个需求呢？
🙋♂️我：这个需要多轮对话和动态推荐，应该用 Agent？
👔面试官：很好。你能总结一下判断标准吗？什么时候工作流更合适，什么时候 Agent 更合适？
🙋♂️我：流程固定的工作流，动态不确定的用 Agent。
👔面试官：对。关键是看确定性和灵活性的需求。而且企业中 80% 的场景其实更适合工作流，Agent 适合那 20% 的开放任务。
TL;DR 速记
- 工作流核心：确定性、可控性、可审计性，适合固定流程
- Agent 核心：灵活性、适应性、自主性，适合开放任务
- 选型标准：步骤是否固定？路径是否已知？输出格式是否明确？是否需要强可控？
- 企业实践：80% 场景用工作流，20% 场景用 Agent
- 混合架构：复杂系统中两者结合，用 Agent 做编排、工作流做执行
图解
图 1：工作流 vs Agent 对比
图 2：选型决策树
详细解析
核心区别：确定性 vs 灵活性
工作流（Workflow）：
- 定义：预定义的、确定的执行路径
- 特点：每个节点做什么、顺序如何，事先明确
- 类比：工厂流水线——每个工位固定，流程标准化
Agent：
- 定义：具备自主决策能力的智能体
- 特点：根据输入动态决定下一步做什么
- 类比：助理——根据任务灵活安排行动
| 维度 | 工作流 | Agent |
|---|---|---|
| 执行路径 | 预先定义，固定不变 | 动态决策，灵活调整 |
| 输入处理 | 标准化输入，固定流程 | 理解意图，自适应处理 |
| 错误处理 | 预定义重试/回退策略 | 自主判断，动态恢复 |
| 可控性 | 高，每个节点可控 | 中，依赖模型推理 |
| 可审计性 | 高，执行路径可追溯 | 中，推理过程需额外记录 |
| 成本 | 可预测，固定 | 不确定，可能超支 |
| 开发复杂度 | 中等，需定义流程 | 较高，需设计决策逻辑 |
工作流的核心优势
1. 确定性（Determinism）
python
# 工作流：每次执行路径完全相同
def process_invoice_workflow(invoice):
# 节点 1：验证格式
validated = validate_format(invoice)
# 节点 2：提取信息
extracted = extract_fields(validated)
# 节点 3：匹配订单
matched = match_po(extracted)
# 节点 4：生成凭证
voucher = generate_voucher(matched)
return voucher
# 同样的输入，永远产生同样的执行路径和输出优势：
- 结果可预测，易于测试
- 不会出现意外行为
- 适合合规性要求高的场景
2. 可控性（Controllability）
yaml
# LangGraph 工作流定义
workflow:
nodes:
- name: classify_input
type: llm
model: gpt-4
prompt: "分类用户意图"
- name: human_review
type: human_in_the_loop
condition: "高风险分类"
# 人工审核点精确控制
- name: process_request
type: tool
retry_policy:
max_attempts: 3
backoff: exponential
# 失败重试策略明确
- name: notify_result
type: callback
timeout: 30s
# SLA 可衡量优势：
- 人工介入点精确控制
- 失败重试策略可配置
- SLA（服务等级协议）可衡量
3. 可审计性（Auditability）
json
{
"workflow_id": "invoice_processing_v2",
"execution_id": "exec_12345",
"trace": [
{
"node": "validate_format",
"input": {...},
"output": {...},
"duration_ms": 150,
"timestamp": "2024-01-15T10:30:00Z"
},
{
"node": "extract_fields",
"input": {...},
"output": {...},
"duration_ms": 800,
"llm_calls": 1,
"timestamp": "2024-01-15T10:30:01Z"
}
],
"final_output": {...},
"total_duration_ms": 2500
}优势：
- 每个节点输入输出可记录
- 执行路径完全可追溯
- 满足企业合规要求
- 便于调试和优化
4. 成本可预测（Predictable Cost）
工作流中每个节点的成本是固定的：
- 节点数量 × 每个节点的平均成本 = 总成本上限
- 不会出现无限循环或意外的高 Token 消耗
工作流典型场景：
| 场景 | 为什么适合工作流 |
|---|---|
| 文档分类 | 输入是文档，输出是固定类别，流程确定 |
| 内容审核 | 有明确的审核规则，需记录审核路径 |
| 发票处理 | 字段提取→验证→入账，固定流程 |
| 报告生成 | 数据查询→分析→格式化，步骤确定 |
| 工单流转 | 状态机明确，审批路径固定 |
| 数据同步 | ETL 流程标准化，可审计 |
Agent 的核心优势
1. 灵活性（Flexibility）
python
# Agent：根据情况动态决策
async def handle_customer_query(query, context):
# Agent 分析意图
intent = await analyze_intent(query)
# 根据意图动态选择策略
if intent == "order_status":
return await check_order_status(context)
elif intent == "product_inquiry":
# 可能需要多轮搜索和比较
return await research_and_recommend(query)
elif intent == "complaint":
# 可能需要升级处理
return await escalate_to_human(context)
else:
# 未知意图，尝试通用处理
return await general_response(query)优势：
- 适应未预见的场景
- 根据中间结果动态调整
- 能处理开放性问题
2. 适应性（Adaptability）
Agent 可以处理路径不确定的任务：
- 研究型任务：需要先查什么后查什么，无法预先定义
- 客服对话：用户可能跳跃式提问，需要灵活应对
- 代码调试：问题可能出在任何地方，需要系统排查
3. 自主性（Autonomy）
Agent 可以自主决定：
- 是否需要调用工具
- 调用哪个工具
- 什么时候停止
- 是否需要澄清
Agent 典型场景：
| 场景 | 为什么适合 Agent |
|---|---|
| 研究助手 | 路径不确定，需要多轮检索和验证 |
| 智能客服 | 用户意图多样，需要动态判断 |
| 代码 Agent | 问题定位不确定，需要逐步调试 |
| 旅行规划 | 约束条件多，需要动态优化 |
| 数据分析 | 探索性分析，路径不可预测 |
| 创作助手 | 创意过程难以流程化 |
选型决策框架
决策 checklist：
□ 任务步骤是否完全确定？
└─ 否 → 考虑 Agent
└─ 是 → 继续
□ 输出格式是否明确？
└─ 否 → 考虑 Agent
└─ 是 → 继续
□ 是否需要强可控/审计？
└─ 是 → 考虑工作流
└─ 否 → 继续
□ 是否可接受不确定性？
└─ 是 → 考虑 Agent
└─ 否 → 考虑工作流
□ 成本预算是否严格？
└─ 是 → 考虑工作流
└─ 否 → 两者均可企业实践比例：
根据行业经验，企业 AI 应用场景的大致分布：
- 80% 工作流：大多数业务流程是确定的
- 20% Agent：开放性问题、探索性任务
但这并不意味着 Agent 不重要——那 20% 的 Agent 场景往往是高价值、差异化的竞争力所在。
混合架构：Agentic Workflow
复杂系统中，往往不是二选一，而是两者结合：
架构 1：Agent 编排 + 工作流执行
示例：
- Agent 识别用户要做「月度财务分析」
- 分解为：数据提取（工作流 A）、异常检测（工作流 B）、报告生成（工作流 C）
- Agent 协调执行顺序，整合结果
架构 2：工作流为主，Agent 节点点缀
yaml
workflow:
nodes:
- name: classify
type: llm # LLM 作为节点
- name: human_review
type: conditional
condition: "confidence < 0.8"
- name: auto_resolve
type: agent # Agent 节点，处理复杂情况
when: "classification == 'complex'"
- name: standard_process
type: workflow # 标准工作流
when: "classification == 'standard'"演进路径：
纯工作流 → 工作流 + LLM 节点 → Agentic Workflow → 纯 Agent
确定性 ↑ 灵活性 ↑
建议演进策略：
1. 从工作流开始，确保基础功能稳定
2. 在关键决策点引入 LLM（如分类、摘要）
3. 逐步增加 Agent 节点处理复杂分支
4. 最终形成自适应的 Agentic Workflow常见踩坑与反例
踩坑 1：给确定性任务上 Agent
错误做法： 发票处理、订单状态查询等固定流程，用 Agent 实现。
问题：
- 成本高（Agent 推理 Token 消耗大）
- 不可控（可能走错分支）
- 难审计（决策过程不透明）
- 延迟大（需要多轮推理）
正确做法： 固定流程用工作流，只在需要决策的环节用 LLM 节点。
踩坑 2：工作流节点职责不清
错误做法： 一个工作流节点既做分类又做摘要又做提取。
问题：
- 难以测试和调试
- 失败时不知道问题在哪
- 难以复用
正确做法： 单一职责原则：每个节点只做一件事。
踩坑 3：忽视降级策略
错误做法： Agent 任务失败时，没有备选方案。
正确做法：
python
async def robust_task_execution(task):
try:
# 尝试 Agent 方式
result = await agent_handle(task)
except Exception:
# 降级到工作流
logger.warning(f"Agent failed, falling back to workflow: {task.id}")
result = await workflow_handle(task)
return result踩坑 4：工作流过于僵化
错误做法： 工作流完全不用 LLM，纯规则处理。
问题：
- 难以处理边缘情况
- 规则维护成本高
正确做法： 工作流 + LLM 节点结合，用 LLM 处理理解类任务（分类、摘要），用规则处理逻辑类任务。
踩坑 5：混合架构设计不当
错误做法： Agent 和工作流层级混乱，互相嵌套过深。
正确做法： 明确分层：Agent 做高层决策和编排，工作流做底层执行。
面试官可能继续追问
追问 1：Workflow 中哪些节点适合交给 LLM？ 答题要点：理解类任务（意图分类、内容摘要、情感分析、实体提取）适合 LLM；逻辑类任务（数据验证、格式转换、规则匹配）适合传统代码；决策类任务可以用 LLM 辅助，但关键决策需要人工介入。
追问 2：人工审核点应该加在哪里？ 答题要点：高风险操作前（如资金转账）；置信度低的分类结果；涉及敏感信息的处理；合规要求的关键节点；Agent 自主决策的边界检查点。
追问 3：工作流如何逐步升级成 Agentic Workflow？ 答题要点：第一步：在决策节点引入 LLM（如智能路由）；第二步：允许 LLM 动态选择执行路径；第三步：引入 ReAct 循环处理复杂分支；第四步：增加自我反思和错误恢复能力。
追问 4：如何衡量 Agent 和 Workflow 的效果？ 答题要点：Workflow：准确率、延迟、通过率、成本；Agent：任务完成率、用户满意度、平均步数、成本效率；共同指标：端到端延迟、错误率、用户满意度。
面试总结
工作流 vs Agent 的选型是 AI 应用设计的核心决策。面试时强调三点：
- 核心判断标准：确定性 vs 灵活性——步骤固定、输出明确、强可控需求 → 工作流；开放任务、动态决策、路径不确定 → Agent
- 企业实践：80% 场景用工作流，20% 场景用 Agent；复杂系统采用混合架构（Agentic Workflow）
- 演进思路：从工作流开始确保稳定性，逐步引入 LLM 节点，最终形成自适应的 Agentic Workflow
记住：不要为了用 Agent 而用 Agent。大量企业场景其实更适合工作流。Agent 的价值在于处理那些无法流程化的开放任务，两者不是替代关系，而是互补关系。