Agent 设计模式

Workflow vs Agent：先搞清楚你要什么

一个反直觉的观点：最成功的 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

LLM 和工具通过预定义的代码路径编排。开发者在写代码时就决定了执行顺序：先做 A，再做 B，最后做 C。

关键词：确定性、可预测、开发者控制流程

Agent

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

关键词：自主性、动态决策、模型控制流程

流程对比

Workflow：代码决定流程

输入

步骤 A

步骤 B

输出

Agent：模型决定流程

输入

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 就够了。复杂度是成本，不是功能。只在明确带来收益时才增加复杂度。