随着大模型开始具备 Tool Calling、结构化输出、长上下文和多模态能力，AI 应用正在从简单的“问答系统”逐渐发展为可以完成复杂任务的 Agent。

但实际开发时会发现一个问题：

Agent 并不是一种固定的架构，而是一组不同的运行模式。

Workflow、Tool Calling、ReAct、Planner + Executor、Reflection、Graph、Multi-Agent，看起来都叫 Agent，但它们在控制权、执行方式、稳定性、成本和适用场景上差别非常大。

从软件架构角度，可以把 Agent 统一抽象为：

[
State_{t+1}=f(State_t,LLM,Tool,Memory,Rule)
]

不同 Agent 模式的核心差异，就是：

下一步执行什么，由谁决定。

有的由程序决定，有的由 LLM 决定，还有一些采用程序和 LLM 共同控制的混合模式。

---

一、Workflow / Pipeline 模式

Workflow 是最容易理解的一种 Agent 模式。

流程提前确定：

Request
   ↓
理解需求
   ↓
查询数据
   ↓
AI分析
   ↓
生成结果

例如 AI 经营分析：

用户问题
   ↓
IntentStage
   ↓
QueryStage
   ↓
AnalysisStage
   ↓
ReportStage

程序负责流程控制，AI 只是其中某些 Stage 的实现。

可以表示为：

[
Result=f_n(f_{n-1}(…f_1(Request)))
]

特点

优点：

• 执行路径确定
• 非常容易测试
• 容易记录日志
• 容易做重试
• 容易控制成本
• 容易做权限和事务控制
• 非常适合企业应用

缺点：

• 灵活性有限
• 无法很好处理未知任务
• 流程变化通常需要修改程序

使用场景

特别适合：

AI报表
AI PPT
合同处理
票据处理
知识库问答
审批辅助
客服流程
代码生成流程

例如：

DB
 ↓
分析
 ↓
生成结论
 ↓
生成PPT

这种场景没有必要让 AI 自己决定整个流程。

---

二、Tool Calling 模式

Tool Calling 是现在最常见的 Agent 基础能力。

LLM 不仅生成文本，还可以决定调用工具。

例如：

User
 ↓
LLM
 ↓
querySales()
 ↓
Tool Result
 ↓
LLM
 ↓
Response

工具可以是：

数据库
搜索
HTTP API
文件
计算器
邮件
日历
代码执行
业务系统

例如：

querySales(...)
queryInventory(...)
getCustomer(...)
generateChart(...)

LLM 根据用户需求选择合适的 Tool。

特点

优点：

• 实现成本低
• 灵活
• 可以把现有系统能力快速暴露给 AI
• 是其他 Agent 模式的基础

缺点：

• Tool 参数可能错误
• Tool 数量多以后选择准确率下降
• 需要 Schema Validation
• 需要权限控制
• 需要控制副作用

使用场景

适合：

AI助手
企业Copilot
数据库查询
API聚合
个人助理
知识检索
运维助手

很多所谓 Agent，本质上其实就是：

[
LLM + ToolCalling
]

---

三、ReAct 模式

ReAct 可以理解为：

边执行，边观察，边决定下一步。

执行过程：

Reason
  ↓
Action
  ↓
Observation
  ↓
Reason
  ↓
Action
  ↓
...

例如：

为什么最近销售下降？

Agent 可能：

查询整体销售
    ↓
发现下降15%
    ↓
查询门店
    ↓
发现A店下降40%
    ↓
查询A店品类
    ↓
发现女装下降明显
    ↓
查询库存
    ↓
发现缺货
    ↓
形成结论

它不会一开始就确定完整路径。

而是：

[
Action_{t+1}=LLM(State_t)
]

特点

优点：

• 探索能力很强
• 能根据中间结果改变方向
• 适合未知问题
• 很接近人的调查过程

缺点也非常明显：

• 不确定
• 容易重复调用 Tool
• 很难判断什么时候停止
• Context 会持续增长
• 成本不好控制
• 调试困难
• 生产环境稳定性一般

使用场景

比较适合：

故障排查
数据探索
Research
复杂搜索
问题诊断
根因分析

不太适合：

付款
下单
修改库存
删除数据
审批
核心事务

因为这些业务不能允许 Agent 自由尝试。

---

四、Planner + Executor 模式

Planner + Executor 把“思考”和“执行”分开。

首先规划：

Goal
 ↓
Planner
 ↓
Plan

然后：

Plan
 ↓
Executor
 ↓
Result

例如：

分析今年销售表现并生成老板汇报 PPT。

Planner 可能生成：

1. 查询整体销售
2. 做同比分析
3. 分析门店贡献
4. 分析品类
5. 查找异常
6. 总结原因
7. 生成PPT

Executor 只负责执行。

可以表示为：

[
Plan=Planner(Goal)
]

[
Result=Executor(Plan)
]

特点

优点：

• 比 ReAct 更容易理解
• 执行阶段相对稳定
• 可以提前检查计划
• 适合复杂长任务

最大问题：

Plan 的质量决定 Result 的上限。

如果 Planner 规划错了：

错误计划
   ↓
高质量Executor
   ↓
准确执行错误计划

因此 Planner + Executor 的关键其实在 Planner。

使用场景

适合：

复杂数据分析
Deep Research
项目任务分解
代码修改
AI PPT
报告生成
复杂自动化任务

---

五、Adaptive Planning 模式

Planner + Executor 还有一个问题：

一开始规划的时候，还没有看到后面的数据。

因此可以采用滚动规划。

Goal
 ↓
Planner
 ↓
执行前3步
 ↓
Observation
 ↓
重新Planner
 ↓
执行下一批

即：

[
Plan_{t+1}=Planner(Goal,State_t)
]

例如销售分析：

第一次规划：

1. 比较整体销售
2. 找下降最大的门店

执行之后发现：

南京店 -35%
其他店正常

重新规划：

只分析南京店
→ 按品类下钻

然后发现：

女装 -50%

再次规划：

分析女装库存和SKU

相比一次生成十几个步骤，这种模式更加合理。

使用场景

适合：

数据分析
根因分析
研究任务
复杂诊断
动态业务问题

它可以理解为介于：

Planner

与：

ReAct

之间的模式。

---

六、Reflection / Critic 模式

Reflection 的基本思想是：

Generate
   ↓
Critic
   ↓
Improve

例如：

生成报告
 ↓
检查报告
 ↓
发现问题
 ↓
重新生成

甚至循环：

Generate
→ Critic
→ Improve
→ Critic
→ Improve

特点

优点：

• 可以改善文本质量
• 对写作、代码、推理任务有一定效果
• 可以发现一些明显遗漏

但问题同样明显：

如果：

Generator = LLM
Critic = LLM

那么：

Critic 本身也可能判断错误。

所以生产系统中更适合把 Reflection 改造成：

Generate
   ↓
Validator
   ↓
Repair

机器能检查的问题：

数字
Schema
数据来源
依赖
权限
公式

应该由程序检查。

只有：

表达质量
逻辑结构
是否重复
叙事是否合理

才交给 LLM Critic。

使用场景

适合：

文章
报告
PPT
代码生成
摘要
内容质量检查

不适合作为整个 Agent 的核心运行机制。

---

七、Router 模式

Router 是非常实用的一种模式。

它不负责执行具体任务，而是负责：

把任务交给谁。

例如：

                   User
                    ↓
                  Router
             ┌──────┼──────┐
             ↓      ↓      ↓
          SQL       PPT    Search
         Agent     Agent   Agent

例如用户说：

查一下上个月销售。

Router：

→ DataAgent

用户说：

根据这个分析做 PPT。

Router：

→ PptAgent

特点

优点：

• 简单
• 稳定
• 非常适合大型系统
• 可以减少单个 Agent 的复杂度

缺点：

• Router 判断错误会导致整个流程错误
• Agent 边界需要设计清楚

使用场景

非常适合：

AI平台
企业助手
多业务系统
SaaS平台
多技能助手

---

八、Graph / State Machine 模式

Workflow 是：

A → B → C → D

Graph 则允许：

       B
      ↗ ↘
A → C   E
      ↘ ↗
       D

例如：

          Query
            ↓
         Analyze
         /     \
    数据不足   数据充分
       ↓          ↓
     Query      Report
       ↑          ↓
       └──── Review

核心抽象是：

State
Node
Edge
Condition

每一个 Node：

[
State_{t+1}=Node(State_t)
]

特点

优点：

• 能表达复杂流程
• 支持循环
• 支持条件跳转
• 比 ReAct 更容易控制

缺点：

• 实现复杂度比 Workflow 高
• State 管理会越来越重要
• 调试复杂度提高

使用场景

适合：

复杂Agent
长任务
审批
故障诊断
Research
复杂业务流程

---

九、Multi-Agent 模式

Multi-Agent 的核心思想是：

不让一个 Agent 什么都做。

例如：

                 Manager
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   DataAgent   AnalysisAgent   PPTAgent

每个 Agent 负责不同领域。

还可以：

SQL Agent
Research Agent
Writer Agent
Reviewer Agent

特点

优点：

• 专业化
• 上下文更加聚焦
• 复杂任务容易拆分

缺点：

• Agent 间通信复杂
• Context 管理困难
• 成本高
• 容易出现重复工作
• 调试困难

最大误区是：

把所有模块都包装成 Agent。

比如：

ChartAgent
PDFAgent
DatabaseAgent

很多情况下其实只需要：

chartRenderer.render(...)
database.query(...)

确定性的能力，没有必要 Agent 化。

使用场景

适合：

大型复杂任务
跨专业任务
Research
代码开发
复杂报告
大型企业AI平台

---

十、Multi-Plan / Ensemble Planning 模式

这是 Planner + Executor 的增强模式。

不是只调用一次 Planner。

而是：

                Goal
                 │
      ┌──────────┼──────────┐
      ↓          ↓          ↓
 Planner A   Planner B  Planner C
      ↓          ↓          ↓
   Plan A      Plan B     Plan C
      └──────────┼──────────┘
                 ↓
           PlanSynthesizer
                 ↓
             FinalPlan
                 ↓
             Executor

即：

[
P_i=Planner_i(Context)
]

然后：

[
P^*=Synthesize(P_1,P_2,…P_n)
]

最后：

[
Result=Executor(P^*)
]

这种模式的核心思想可以概括为：

规划阶段允许发散，执行阶段必须收敛。

使用场景

尤其适合：

高价值分析
复杂决策
经营分析
AI PPT
Deep Research
复杂项目规划

缺点主要是成本增加。

所以一般没有必要运行十几个 Planner。

3 个候选 Plan 通常已经有明显价值。

---

十一、Hybrid Agent 模式

从企业软件角度看，我认为最终最重要的其实不是前面的任何一种单一模式。

而是：

Hybrid Agent

即：

Workflow
+
Tool Calling
+
Planner
+
局部ReAct
+
Validator

例如 AI + DB + PPT：

                  Workflow
                     │
                IntentStage
                     ↓
               PlanningStage
                     ↓
          ┌─────────────────────┐
          │ Adaptive Analysis   │
          │                     │
          │ Planner             │
          │   ↓                 │
          │ DB Query            │
          │   ↓                 │
          │ Observation         │
          │   ↓                 │
          │ Replan              │
          └─────────────────────┘
                     ↓
                Conclusion
                     ↓
                PPT Render
                     ↓
                 Validator

这里：

• Workflow 控制大流程
• Planner 处理任务分解
• Tool Calling 访问外部能力
• ReAct 只处理局部探索
• Validator 保证质量
• Renderer 保证确定性输出

这可能是企业 Agent 最终最常见的形态。

---

十二、各种模式的核心区别

模式	谁控制流程	灵活性	稳定性	实现复杂度	典型场景
Workflow	程序	★★	★★★★★	★	企业流程
Tool Calling	LLM局部	★★★	★★★★	★★	AI助手
Router	LLM/规则	★★★	★★★★★	★★	多业务平台
Planner + Executor	Planner	★★★★	★★★★	★★★	复杂任务
Adaptive Planning	Planner动态	★★★★★	★★★★	★★★★	数据分析
ReAct	LLM	★★★★★	★★★	★★★★	探索、诊断
Reflection	LLM	★★★	★★	★★★	内容优化
Graph	Graph+LLM	★★★★	★★★★	★★★★	复杂Agent
Multi-Agent	多Agent	★★★★★	★★★	★★★★★	跨领域复杂任务
Multi-Plan	多Planner	★★★★★	★★★★	★★★★	高价值复杂规划
Hybrid	程序+LLM	★★★★★	★★★★★	★★★★	企业级Agent

---

十三、怎么选择 Agent 模式

可以用一个非常简单的原则判断。

如果任务执行路径明确：

使用 Workflow

如果只是需要访问外部能力：

使用 Tool Calling

如果需要把不同任务分流：

使用 Router

如果任务复杂但可以先规划：

使用 Planner + Executor

如果中间结果会改变后续策略：

使用 Adaptive Planning

如果问题本身需要探索：

使用 ReAct

如果需要生成之后检查：

使用 Validator + Repair

如果流程存在循环和复杂分支：

使用 Graph

如果任务跨越多个专业领域：

考虑 Multi-Agent

如果 Planning 本身风险很高：

使用 Multi-Plan + Synthesizer

---

十四、一个更重要的判断标准

其实选择 Agent 模式，可以归结成一个问题：

系统中到底有多少“不确定性”？

确定性越高：

Workflow

越合适。

不确定性越来越高：

Workflow
   ↓
Planner
   ↓
Adaptive Planner
   ↓
ReAct

但自主性提高的同时：

稳定性下降
成本上升
调试难度增加
安全风险增加

所以企业软件并不是 Agent 越自主越先进。

真正合理的原则应该是：

只把不确定的部分交给 AI。

能通过程序确定的事情，继续使用程序。

---

结论

AI Agent 并不存在一种万能的开发模式。

真正成熟的 Agent 系统，很可能是多种模式组合：

            Agent Runtime
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
   Workflow    Planner     Router
       │          │          │
       └──────┬───┴──────┬───┘
              ↓          ↓
            Tool       ReAct
              │          │
              └────┬─────┘
                   ↓
                Validator
                   ↓
                 Result

从软件架构角度看，未来真正值得建设的，并不是一个“万能 Agent”。

而是一套能够组合：

Workflow
Planner
Tool
Router
Validator
Loop
State
Executor

这些基础能力的 Agent Runtime。

不同的 Agent 开发模式，本质上只是这些基础能力的不同组合。

[
AgentMode=Compose(RuntimePrimitives)
]

当这一层抽象稳定下来以后，Agent 才真正从“大模型应用技巧”，进入软件工程体系。