开场：先搞清楚你要什么

一个反直觉的观点：最成功的 AI 实现，往往不是最复杂的那个。 在动手搭 Agent 框架之前，先搞清楚你真正需要什么。

"The most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns."

这句话值得每个 AI 产品经理背下来。行业里充斥着各种 Agent 框架（LangChain、AutoGen、CrewAI……），但生产环境反复验证的规律是：真正跑得好的系统，用的是最朴素的组合模式。

本文讲清三件事：Workflow 和 Agent 到底差在哪、什么时候根本不需要 Agent、以及业界验证有效的五种 Workflow 编排模式。

一、Workflow vs Agent：两条路怎么选

Workflow： LLM 和工具通过预定义的代码路径编排。开发者在写代码时就决定了执行顺序：先做 A，再做 B，最后做 C。关键词：确定性、可预测、开发者控制流程。

Agent： LLM 动态决定自己的执行流程和工具使用。模型在每一步自主判断下一步做什么、要不要调用工具、什么时候结束。关键词：自主性、动态决策、模型控制流程。

Workflow：代码决定流程           Agent：模型决定流程
输入 → 步骤A → 步骤B → 输出      输入 → LLM决策 → 工具/思考/再决策 → 输出

差异对比

维度	Workflow	Agent
控制权	开发者（代码路径固定）	模型（每步动态决定）
可预测性	高：输入确定则输出路径确定	低：同样输入可能走不同路径
适用场景	任务拆解明确、步骤固定	任务开放、需要灵活决策
成本	可控（调用次数固定）	不确定（循环次数未知）
调试难度	低（路径确定，容易复现）	高（行为不确定，难以复现）
典型例子	文案生成管道、数据清洗流水线	Cursor、Claude Code、Devin

二、什么时候不要用 Agent

大多数情况下，你不需要 Agent。

实践证明：对于大多数应用场景，优化单次 LLM 调用配合检索增强（RAG）就够了。只有当简单方案明确无法满足需求时，才应考虑引入 Workflow 或 Agent 的复杂度。

常见的过度设计：用一个 Agent 框架来做本质上一个 Prompt 加一次搜索就能解决的问题。框架引入的延迟、成本、不确定性远大于它带来的收益。

核心原则：复杂度阶梯

先找最简方案，复杂度只在明确提升效果时才加。

1. 先试单次 LLM 调用：优化 Prompt、加 Few-shot、调 Temperature
2. 不够？加检索增强（RAG）：让 LLM 能访问外部知识
3. 还不够？用 Workflow：把任务拆成多步，用代码控制流程
4. 真的需要灵活决策？才上 Agent：让模型自主规划执行

不是所有问题都需要 Agent，很多时候 Workflow 就够了，甚至一个精调的 Prompt 就够了。复杂度是成本，不是功能，只在明确带来收益时才增加复杂度。

三、五种 Workflow 模式：由简到繁

业界已验证有效的五种 Workflow 编排模式，每种解决特定类型的问题。不追求最复杂的，追求最合适的。

① Prompt Chaining（提示链）

把一个大任务拆解为多个顺序步骤，上一步的输出直接作为下一步的输入。每一步都是一次独立的 LLM 调用，专注做好一件事。步骤之间可以插入质量门（programmatic gate），只有通过检查才进入下一步。

适用场景： 任务能自然拆解为多个固定步骤；需要在中间环节做质量检查；用准确度换取延迟。

真实例子： 生成营销文案（Step 1）→ 翻译为目标语言（Step 2）→ 格式化为特定平台样式（Step 3）。中间 Gate：检查 Step 1 输出是否包含品牌关键信息。

② Routing（路由）

先分类输入，然后将其导向不同的专门处理分支。每个分支可以有独立的 Prompt、模型甚至工具配置。核心价值：关注点分离，让每个分支只处理一种类型的输入。

适用场景： 输入类型多样，不同类型需要完全不同的处理逻辑；需要成本优化（简单问题用便宜模型，复杂问题用强模型）。

真实例子： 客服系统——简单 FAQ 用 Haiku（快且便宜），退款相关用 Sonnet + 订单工具，技术故障用 Sonnet + 日志查询。一个分类器决定走哪条路，实现成本与效果的最优平衡。

③ Parallelization（并行化）

让多个 LLM 调用同时执行，再聚合结果。两种子模式：

• Sectioning（拆分并行）： 把一个任务拆为独立子任务，并行处理后合并
• Voting（多次投票）： 同一个任务用相同 Prompt 跑多次，取多数/最佳结果

适用场景： 子任务之间没有依赖关系；需要提升速度（并行比串行快）；需要提升置信度（多次投票降低随机性）。

真实例子 - Sectioning： 代码审查中，一个 LLM 检查安全漏洞、一个检查性能问题、一个检查代码风格，最后汇总所有发现。

真实例子 - Voting： 内容审核中，同一段文本让 3 个 LLM 分别判断是否违规，取多数意见作为最终结果。

④ Orchestrator-Workers（编排者-工人）

一个中心 LLM（编排者）动态拆解任务并分配给多个工人 LLM。与 Parallelization 的区别：子任务由编排者在运行时动态决定，代码里没有预先定义。这是最接近 Agent 的 Workflow 模式。

适用场景： 子任务不能提前预知（需要根据输入动态决定）；涉及对多个文件/资源的并行操作。

真实例子： 代码修改需求「给项目加国际化支持」。编排者分析代码库后动态决定：Worker 1 改 Button 组件、Worker 2 改 Header 组件、Worker 3 创建语言文件。不同需求产生不同数量和类型的 Worker。

⑤ Evaluator-Optimizer（评估-优化）

一个 LLM 负责生成，另一个 LLM 负责评判，二者形成迭代循环：生成者根据评判者的反馈不断改进输出，直到评判者认为满意或达到迭代上限。

适用场景： 有明确的质量评估标准；迭代改进能显著提升输出质量；单次生成很难达到要求。

真实例子： 文学翻译中，生成者做初步翻译，评判者检查信达雅和风格一致性并给出具体修改建议，生成者根据建议改进。循环 2-3 次后输出终稿，每次迭代的翻译质量都在提升。

五种模式一览

模式	核心思想	典型场景	复杂度
Prompt Chaining	顺序串联，逐步处理	文案生成管道	低
Routing	分类导向，专门处理	智能客服分流	低
Parallelization	并行处理，聚合结果	多维度代码审查	中
Orchestrator-Workers	动态拆分，分布执行	跨文件代码修改	中高
Evaluator-Optimizer	生成评判，迭代改进	高质量翻译	中

结语：追求最合适，不追求最复杂

"Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short."

回顾全文：先搞清楚你要什么——Workflow 是代码定流程，Agent 是模型定流程，差异在控制权、可预测性与成本；大多数时候你不需要 Agent——按复杂度阶梯走：单次 LLM 调用 → RAG → Workflow → Agent，每一级都只在简单方案不够用时才升级；五种模式由简到繁——从 Prompt Chaining 开始，只在确认简单方案不够用时才升级到更复杂的模式。

记住最关键的一句话：不要追求最复杂的模式，要追求最合适的。 每增加一层复杂度，都要问自己：这个复杂度带来的收益，值得额外的延迟、成本和调试难度吗？