Agent编排范式深度解析_从论文到实战
Agent编排范式深度解析：从论文原理到工程实战
六种主流范式的论文溯源、运行机制、适用场景与真实项目落地
引言：为什么理解Agent编排范式是构建智能系统的第一课？
2023-2025年，LLM Agent从实验室概念迅速走向生产落地。但在实际构建Agent系统时，开发者面临的第一个关键决策不是"选哪个模型"，而是**“用什么范式来编排Agent的推理和执行流程”**。
这个决策的影响是根本性的——它决定了系统的准确率上限、延迟下限、token成本结构和调试复杂度。
本文以**“论文溯源 → 运行机制 → 优劣分析 → 实战案例”**的结构，系统讲解6种主流Agent编排范式：
| 范式 | 论文 | 时间 | 核心思想 | 一句话总结 |
|---|---|---|---|---|
| ReAct | Yao et al., ICLR 2023 | 2022.10 | 推理与行动交替进行 | 边想边做，每一步都基于上一步的观察 |
| ReWOO | Xu et al., 2023 | 2023.05 | 推理与观察解耦 | 先规划全局蓝图，再批量执行 |
| LLMCompiler | Kim et al., ICML 2024 | 2023.12 | 编译器思维+DAG并行 | 找出独立任务并行执行，3.7倍加速 |
| Plan-and-Execute | 多源演进 | 2024 | 规划与执行分离 | 先制定完整计划，再按计划逐步执行 |
| Reflexion | Shinn et al., NeurIPS 2023 | 2023.03 | 语言化反思强化 | 从失败中学习，用文本反思替代梯度更新 |
| Multi-Agent | 多源演进 | 2023-2025 | 多角色分工协作 | 专家各司其职，合成统一结论 |
最后，我们将结合某投顾Agent平台的真实架构，展示如何将这些范式组合成一个生产级多Agent系统。
一、ReAct：Agent编排的奠基之作
1.1 论文溯源
ReAct: Synergizing Reasoning and Acting in Language Models
- 作者：Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao（Google Research + Princeton）
- 发表：ICLR 2023，arXiv: 2210.03629
- 时间：2022年10月首次提交
1.2 核心问题
在ReAct之前，LLM的能力被两条独立的线研究：
- 推理线（Reasoning）：Chain-of-Thought（CoT）让模型输出中间推理步骤，提升复杂问题的准确性。但CoT是"闭门造车"——模型只能依赖自身参数中的知识，遇到不知道的事实就产生幻觉。
- 行动线（Acting）：让模型调用外部工具（搜索、计算器等），但纯行动模式缺乏规划——模型不知道何时该搜索、何时该停止搜索开始回答。
ReAct的核心洞察：这两条线不应该分离。推理指导行动（“我需要查什么”），行动反过来修正推理（“查到的结果是X，所以我之前的假设是错的”）。两者的协同产生了1+1>2的效果。
1.3 运行机制
ReAct的核心是一个 Thought → Action → Observation 循环：
用户问题: "2023年诺贝尔物理学奖得主的博士导师是谁？"
Step 1:
Thought: 我需要先知道2023年诺贝尔物理学奖得主是谁
Action: search[2023 Nobel Prize in Physics winners]
Observation: Pierre Agostini, Ferenc Krausz, Anne L'Huillier...
Step 2:
Thought: 问题问的是博士导师，我需要查Anne L'Huillier的博士导师
Action: search[Anne L'Huillier PhD advisor]
Observation: Anne L'Huillier's PhD advisor was Nanny Fröman...
Step 3:
Thought: 我已经有完整答案了
Action: finish[Anne L'Huillier的博士导师是Nanny Fröman...]
关键机制：
- Thought（思考）：内部推理，不影响外部环境。用于分解目标、分析当前状态、决定下一步行动。
- Action（行动）：调用外部工具或环境接口。从预定义的动作空间中选取（如
search[query]、lookup[string]、finish[answer]）。 - Observation（观察）：外部环境返回的结果，被追加到上下文中，为下一轮思考提供信息。
整个过程的上下文以线性序列方式增长：
c(t) = (instruction, Thought₁, Action₁, Observation₁, ..., Thoughtₜ, Actionₜ, Observationₜ)
1.4 实验结果
| 任务 | 类型 | ReAct | CoT-only | Act-only |
|---|---|---|---|---|
| HotpotQA | 多跳问答 | 35.1 | 29.4 | 25.7 |
| FEVER | 事实验证 | 64.6 | 56.3 | 51.3 |
| ALFWorld | 文字游戏 | 71% | - | 45% |
| WebShop | 网页导航 | 40% | - | 30% |
关键发现：在ALFWorld上，ReAct仅用1-2个few-shot示例就超越了基于10^5条任务实例训练的模仿学习+强化学习基线（71% vs 37%）。
1.5 优劣分析
| 优势 | 劣势 |
|---|---|
| 可解释性强——每一步的推理过程完全透明 | Token消耗随步骤线性增长（每次都要传完整历史） |
| 减少幻觉——外部观察持续修正模型的知识盲区 | 严格串行执行——不能并行处理独立子任务 |
| 灵活性高——模型可以根据中间结果动态调整策略 | 长链路中容易"迷失"——上下文越长，模型越难保持一致性 |
| Few-shot效率极高——1-2个示例即可显著提升效果 | 对prompt设计高度敏感——动作空间的表述方式直接影响成功率 |
1.6 适用场景
- 需要与外部环境或知识源交互的开放式问题
- 步骤数不确定、需要根据中间结果动态决策的任务
- 对可解释性和可审计性有要求的场景
二、ReWOO：去观察化的高效推理
2.1 论文溯源
ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models
- 作者：Binfeng Xu, Zhiyuan Peng, Bowen Lei, Subhabrata Mukherjee, Yuchen Liu, Dongkuan Xu
- 发表：arXiv: 2305.18323（2023年5月）
2.2 核心问题
ReAct有一个结构性的效率缺陷：每一步思考都需要等待上一步的工具调用结果返回。对于"查A→根据A查B→根据B查C"这种三跳问题，ReAct需要3次LLM调用+3次工具调用，串行执行。而且每次LLM调用都要把之前所有历史重新传一遍，token消耗呈线性增长。
ReWOO提出的激进改进是：推理可以在看到任何观察结果之前完成。
2.3 运行机制
ReWOO将流程拆分为三个解耦模块：
┌──────────┐
│ Planner │ 一次性生成完整蓝图（不需要等任何工具返回结果）
│ (规划器) │
└────┬─────┘
│ 输出: 计划 + 工具调用列表 + 依赖关系
┌──────────┼──────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│Tool 1│ │Tool 2│ │Tool 3│ 全部并行/批量执行
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
└─────────┼─────────┘
▼
┌──────────┐
│ Solver │ 综合所有观察结果，生成最终答案
│ (求解器) │
└──────────┘
Planner的输出示例：
Plan: 要回答"X的博士导师是谁"，需要先找到X是谁
#E1 = search[2023 Nobel Physics winner]
Plan: 用#E1的结果查具体人物的博士导师
#E2 = search[#E1 PhD advisor]
Plan: 综合以上信息给出最终答案
Worker批量化执行 #E1 和 #E2（如果两者无依赖则并行），Solver拿到所有结果后一次性生成答案。
2.4 实验结果
- 5倍token效率提升（相比ReAct）
- HotpotQA上准确率+4%
- 工具失效场景下表现出更强的鲁棒性
- 支持模型蒸馏：可将175B GPT-3.5的Planner能力蒸馏到7B LLaMA上
2.5 优劣分析
| 优势 | 劣势 |
|---|---|
| Token效率极高——规划阶段只需一次LLM调用 | 无法根据工具返回的"意外结果"动态调整策略 |
| 支持工具调用并行化 | 对规划质量高度依赖——如果Planner推理出错了，整个计划报废 |
| 工具失效鲁棒性好——Solver可以感知到"某工具失败了"并调整 | 不适用于需要多轮交互试错的任务 |
| 小模型蒸馏友好 | 规划和执行之间的"断层"可能导致信息利用不充分 |
2.6 适用场景
- 步骤间依赖关系在推理前可预先确定的确定性任务
- Token预算极度受限的场景
- 需要批量处理大量同类问题的系统
三、LLMCompiler：编译器视角的并行函数调用
3.1 论文溯源
An LLM Compiler for Parallel Function Calling
- 作者：Sehoon Kim, Suhong Moon, Ryan Tabrizi, Nicholas Lee, Michael W. Mahoney, Kurt Keutzer, Amir Gholami（UC Berkeley SqueezeAILab）
- 发表：ICML 2024，arXiv: 2312.04511
3.2 核心问题
ReAct是串行的，ReWOO是"一次性规划→批量执行"。但ReWOO的问题是它无法处理需要动态决策的场景。LLMCompiler试图在两者之间找到平衡：保留规划的全局视野，同时支持动态调度。
核心洞察来自经典编译器设计：编译器在生成代码前会先做依赖分析（Dependency Analysis），找出哪些指令是独立的（可以并行），哪些有依赖（必须串行）。LLMCompiler将这一思想迁移到Function Calling场景。
3.3 运行机制
LLMCompiler由三个组件构成：
用户查询: "比较Apple和Microsoft的市值，并计算它们的PE比率"
┌─────────────────────────────────────────────┐
│ Function Calling Planner │
│ (一次LLM调用，生成DAG计划) │
│ │
│ 输出: │
│ Task A: get_market_cap("AAPL") [独立] │
│ Task B: get_market_cap("MSFT") [独立] │
│ Task C: get_stock_price("AAPL") [独立] │
│ Task D: get_stock_price("MSFT") [独立] │
│ Task E: get_shares_outstanding("AAPL") │
│ Task F: get_shares_outstanding("MSFT") │
│ Task G: compute_PE(A, C, E) [依赖A,C,E]
│ Task H: compute_PE(B, D, F) [依赖B,D,F]
│ Task I: compare_and_summarize(G, H) [依赖G,H]
└────────────────────┬────────────────────────┘
│
┌────────────────────▼────────────────────────┐
│ Task Fetching Unit (动态调度器) │
│ 分析DAG → 识别就绪任务 → 批次调度 │
│ │
│ 第1批(并行): A, B, C, D, E, F │
│ 第2批(并行): G, H │
│ 第3批: I │
└────────────────────┬────────────────────────┘
│
┌────────────────────▼────────────────────────┐
│ Executor (执行器) │
│ 按批次并行执行 → 汇总结果 │
└─────────────────────────────────────────────┘
3.4 实验结果
相比ReAct：
- 延迟降低3.7倍
- 成本节省6.7倍
- 准确率提升约9%
3.5 与ReWOO的关键差异
LLMCompiler常被与ReWOO混淆，但两者有一个核心区别：
- ReWOO：规划时不需要任何工具结果，所有推理在"真空"中完成。适合工具调用结果可预测的场景。
- LLMCompiler：规划时定义了依赖图，允许分批次执行——第1批的结果会影响第2批的调度。比ReWOO更灵活，比ReAct更高效。
3.6 适用场景
- 多工具调用之间存在复杂依赖关系的场景
- 需要并行化以降低延迟的生产系统
- Agent工具集中既有独立任务又有依赖任务的混合场景
四、Plan-and-Execute：规划与执行的工程化分离
4.1 范式溯源
Plan-and-Execute不是一个单一起源的论文范式，而是2024年由多个研究和工程团队并行演进形成的架构模式共识。其核心理念在以下工作中被系统化：
- LLMCompiler（ICML 2024）提供了DAG规划的理论基础
- LangGraph（LangChain, 2024）提供了循环图的条件化执行框架
- Plan-Then-Execute安全综述（arXiv 2509.08646, 2025）提供了系统性的安全加固指南
4.2 核心思想
Plan-and-Execute的本质是关注点分离（Separation of Concerns）——将"制定策略"和"执行操作"拆分为两个明确独立的阶段：
| 组件 | 职责 | 特点 |
|---|---|---|
| Planner | 接收高层目标，分解任务，生成结构化计划 | 纯LLM推理，不执行任何工具调用 |
| Executor | 解析计划，按依赖关系执行各步骤，管理状态和错误 | 确定性代码驱动，LLM仅在需要推理的步骤介入 |
2024-2025年的关键演进在于从"一次性静态计划"升级为带动态重规划的闭环系统：
用户目标
│
▼
┌─────────┐
│ Planner │ ──→ 生成结构化计划 (JSON/DAG)
└────┬────┘
│
▼
┌─────────┐ ┌──────────────┐
│Executor │────→│ Replanner │ ← 评估每步执行结果
│(按步执行)│ │ (条件重规划) │
└─────────┘ └──────┬───────┘
│
┌────────┼────────┐
▼ ▼ ▼
继续执行 修正计划 判定完成
4.3 2025年安全最佳实践
Plan-Execute模式的一个重要演进方向是安全加固。核心原则是：
“自动规划 + 人工监督执行"优于"人工参与规划”
反直觉但经实证验证（He et al., 2025）：人类在规划阶段介入容易被"看起来很有道理"的错误计划误导。但在执行阶段面对具体工具调用和结果时，能更有效地发现和纠正错误。
Plan-Validate-Execute（高风险场景变体）：执行前由专家审批计划，适用于金融交易、医疗诊断等合规场景。
4.4 与ReAct的量化对比
| 维度 | Plan-and-Execute | ReAct |
|---|---|---|
| 准确率 | ~92% | ~85% |
| Token消耗 | 3000-4500（前期高） | 2000-3000（线性增长） |
| 首次响应延迟 | 较高（需完整计划） | 较低（快速首步） |
| 并行执行 | 原生支持 | 不支持 |
| 控制流可审计性 | 计划是静态产物 | 步进式，难审计 |
| 安全性 | 架构级隔离 | 易受提示注入劫持 |
4.5 架构决策框架
任务复杂度
│
├── 简单（1-2步，无依赖）────→ Function Calling / ReAct
│
├── 中等（3-5步，部分依赖）──→ P-t-E (线性计划)
│
└── 复杂（多步，高依赖）────→ P-t-E + DAG + Re-planning
│
└── 高风险/合规 ──→ Plan-Validate-Execute
五、Reflexion：让Agent从失败中学习
5.1 论文溯源
Reflexion: Language Agents with Verbal Reinforcement Learning
- 作者：Noah Shinn, Beck Labash, Ashwin Gopinath（Northeastern + MIT）, Federico Cassano, Karthik Narasimhan, Shunyu Yao（Princeton）
- 发表：NeurIPS 2023，arXiv: 2303.11366
5.2 核心问题
传统强化学习需要大量训练样本和模型权重更新，对于基于LLM的Agent来说计算成本极高。能否让Agent不修改权重、仅通过文本反思来实现自我改进？
5.3 运行机制
Reflexion的核心是在标准Actor-Evaluator循环中加入一个**反思（Reflexion）**步骤：
┌──────────────────────────────────────────────────┐
│ Reflexion Loop │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Actor │───→│Evaluator │───→│ Reflexion │ │
│ │(执行任务) │ │(评估结果) │ │(口头自我反思) │ │
│ └──────────┘ └──────────┘ └──────┬───────┘ │
│ ↑ │ │
│ │ ▼ │
│ │ ┌──────────────────────────┐ │
│ └─────────│ Episodic Memory │ │
│ (注入反思到 │ (存储历史反思文本) │ │
│ 下一轮尝试) └──────────────────────────┘ │
└──────────────────────────────────────────────────┘
核心流程：
- Actor：在当前任务上执行一次尝试（使用ReAct或其他执行模式）
- Evaluator：评估执行结果（通过环境反馈、测试用例或LLM评判）
- Reflexion：基于失败的原因，用自然语言生成一段反思——“我为什么错了？下次应该如何不同？”
- Memory：将反思存储到情景记忆缓冲区
- 下一次尝试：Actor的上下文中注入了之前的反思，从而改进策略
5.4 实验结果
| 任务 | 成功率 | 对比基线 |
|---|---|---|
| ALFWorld（序列决策） | 97% | ReAct: 71% |
| HotPotQA（知识问答） | 51% | ReAct: 35% |
| HumanEval（编程） | 91% pass@1 | GPT-4直接: 80% |
最惊人是HumanEval——Reflexion让GPT-4的编程能力在无权重更新的情况下超越了自身SOTA 11个百分点。这说明"口头反思"是一种极低成本但高效的能力增强手段。
5.5 优劣分析
| 优势 | 劣势 |
|---|---|
| 无需微调——零权重更新成本 | 反思质量高度依赖LLM的自我诊断能力 |
| 反馈信号灵活——标量值或自然语言均可 | 验证阶段的错误会传导至反思（约70%的错误来自验证失败） |
| 效果显著——多轮反思后的提升幅度接近微调 | 反思token的累积可能导致上下文溢出 |
| 可叠加到任何基础范式之上 | 过度反思可能导致"分析瘫痪" |
5.6 适用场景
- 有明确成功/失败反馈信号的任务（编程、游戏、数学证明）
- 需要多轮尝试才能解决的复杂问题
- 可以叠加到ReAct、Plan-Execute等任何基础范式之上作为"外挂增强层"
六、Multi-Agent：多角色分工协作
6.1 范式溯源
Multi-Agent没有单一起源论文，而是由多个工作共同推动形成：
- CAMEL（Li et al., 2023）：Communicative Agents for “Mind” Exploration，首次系统探索了角色扮演式多Agent对话
- AutoGen（Microsoft, 2023）：多Agent对话框架，支持复杂的Agent间通信模式
- ChatDev（Qian et al., 2023）：用多Agent模拟软件公司组织架构
- TradingAgents（2024）：多Agent分析辩论框架，用于金融分析决策
6.2 核心思想
单一Agent的认知能力受限于单一LLM的推理边界。Multi-Agent通过角色分工 + 结构化通信来突破这一边界：
┌──────────────────┐
│ Orchestrator │
│ (编排调度器) │
└────────┬─────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Agent A │ │ Agent B │ │ Agent C │
│ 角色: 分析师 │ │ 角色: 风控官 │ │ 角色: 策略师 │
│ 视角: 机会 │ │ 视角: 风险 │ │ 视角: 综合 │
│ 工具: 数据API│ │ 工具: 合规库 │ │ 工具: 回测引擎│
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└──────────────────┼──────────────────┘
│
▼
┌──────────────────┐
│ Synthesis Layer │
│ (冲突消解+整合) │
└──────────────────┘
6.3 关键设计维度
角色定义：每个Agent需要有清晰的角色边界——包括它的专业领域、分析视角、可用工具和输出格式。角色不能重叠（否则产生冗余），也不能有盲区（否则产生遗漏）。
通信模式：多Agent之间的信息传递有三种主流模式：
- 广播模式：所有Agent的输出对所有其他Agent可见（信息冗余高但实现简单）
- Hub模式：所有Agent只与中心编排器通信，互不可见（信息效率高但编排器是单点）
- 图模式：Agent之间根据依赖关系选择性通信（最灵活，实现最复杂）
冲突消解：当不同Agent给出矛盾结论时，必须有明确的仲裁机制。常见的策略包括：
- 优先级仲裁：某些角色（如风控）具有一票否决权
- 多数投票：多个Agent投票决定最终结论
- 独立合成：由一个合成的LLM角色综合各方论据后做出独立判断
6.4 适用场景
- 需要多角度交叉验证的复杂分析任务（金融、医疗、法律）
- 不同子任务需要不同领域知识的场景
- 对输出正确性要求极高的场景（单Agent可能有盲区，多Agent互相校验）
七、实战：投顾Agent系统中的多范式组合
以上六种范式并非互斥——在实际的生产系统中，它们被组合使用，各自负责最适合的环节。以下以券商智能投顾Agent平台为例，展示多范式的组合方案。
7.1 系统架构中的范式分布
用户请求: "帮我全面分析持仓，看看要不要调仓"
┌─────────────────────────────────────────────────────┐
│ [Plan-and-Execute] + [LLMCompiler] │
│ 顶层编排器： │
│ 1. 意图识别 + 等级判断 │
│ 2. 根据等级生成执行计划： │
│ A级 → 4 Agent并行会诊 │
│ B级 → 2 Agent并行 │
│ C级 → 单Agent串行 │
│ 3. DAG调度：标记独立Agent并行执行 │
└──────────────────────┬──────────────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ [ReAct] │ │ [ReAct] │ │ [ReAct] │
│ 持仓分析 │ │ 股票诊断 │ │ 风险扫描 │
│ Agent │ │ Agent │ │ Agent │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
│ 每个Agent内部采用ReAct模式: │
│ Thought → Tool Call → Observe → Thought → ...
│ │
└───────────────┬───────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ [Multi-Agent 合成层] │
│ Research Manager角色 (Orchestrator + Synthesizer) │
│ 1. 接收各Agent结构化输出 │
│ 2. 冲突检测: 选股推荐买入 vs 风险发出预警 │
│ 3. 优先级仲裁: 风险 > 推荐 │
│ 4. 逻辑串联: 因果关系而非简单罗列 │
└──────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ [Reflexion] 质量保证回路 │
│ A级客户报告: 投顾审核 → 通过/驳回 │
│ 驳回 → 自动反思 → 反思存入Episodic Memory │
│ 下次同类请求 → 注入历史反思 → 质量持续提升 │
└──────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ Polish + 合规注入 → 返回客户端 │
└─────────────────────────────────────────────────────┘
7.2 为什么这样组合？
| 系统层级 | 选用范式 | 选择理由 |
|---|---|---|
| 顶层编排 | Plan-and-Execute + LLMCompiler | 5个客户等级×6个Agent=30种路由路径，需要Plan-and-Execute的结构化可审计性；A/B级4/2 Agent并行需要LLMCompiler的DAG并行调度 |
| 子Agent内部 | ReAct | 每个Agent需要多轮工具调用（查行情→查财务→查新闻→综合判断），ReAct的Thought-Action-Observe循环是最自然的选择 |
| 多Agent合成 | Multi-Agent + Hub模式 | 需要4个不同视角交叉验证；冲突消解需要明确的优先级仲裁机制 |
| 质量迭代 | Reflexion | 投顾审核提供明确的成功/失败反馈信号，正好匹配Reflexion的强化学习范式 |
7.3 范式选择决策树
在实际工程中，可以用以下决策树来指导范式选择：
开始
│
├── 任务是否包含多个可并行的独立子任务？
│ ├── 是 + 依赖关系可预知 ──→ Plan-and-Execute / ReWOO
│ ├── 是 + 依赖关系复杂 ──→ LLMCompiler
│ └── 否 ──→ 继续
│
├── 子任务是否需要多轮动态工具调用？
│ ├── 是 ──→ ReAct（每个子Agent内部）
│ └── 否 ──→ 直接Function Calling
│
├── 是否需要多视角交叉验证？
│ ├── 是 ──→ Multi-Agent + 合成层
│ └── 否 ──→ 单Agent
│
└── 是否有明确的成功/失败反馈信号？
├── 是 ──→ 叠加 Reflexion
└── 否 ──→ 保持当前范式
7.4 产品化要点
通过在生产系统中实际运行这套多范式组合，我们沉淀了以下产品化要点：
-
范式不是越多越好：每增加一个范式就增加一个故障面。本项目从最初的"所有Agent都自己判断要不要调工具"收敛到"顶层Plan+子Agent ReAct+合成Multi-Agent"三层结构后，系统可调试性显著提升。
-
执行轨迹记录是范式质量的生命线：每个Agent的Thought-Action-Observation序列必须完整记录。这不是为了调试，而是为了做依赖分析——只有知道"这个Agent在第3步搜索了什么、得到了什么"，才能在出错时定位到具体环节。
-
不同等级的客户适合不同的范式深度：A级客户触发完整的4 Agent会诊+Reflexion反思回路，E级客户只走最简单的单Agent ReAct。让80%的算力消耗发生在最有价值的20%客户身上——这既是商业策略也是架构策略。
-
Reflexion的"记忆"需要设定有效期：反思记忆不能无限累积——两个月前的反思可能基于过时的市场环境。本项目中反思记忆的TTL设置为14天，超期自动淘汰。
八、总结与趋势展望
8.1 核心范式对比总结
| 范式 | 核心理念 | 效率 | 灵活性 | 可解释性 | 多步鲁棒性 | 最佳场景 |
|---|---|---|---|---|---|---|
| ReAct | 推理与行动交替 | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 动态探索型任务 |
| ReWOO | 先规划再批量执行 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐ | 步骤可预知的确定性任务 |
| LLMCompiler | 编译器式DAG并行调度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | 多工具复杂依赖场景 |
| Plan-and-Execute | 规划与执行工程化分离 | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 生产级系统首选 |
| Reflexion | 从失败中口头反思学习 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 有明确反馈信号的任务 |
| Multi-Agent | 多角色分工协作 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 需要多视角验证的复杂决策 |
8.2 2025-2026趋势展望
-
从"选一个范式"到"范式自动组合"：目前范式选择是人工的架构决策。未来可能出现自动范式选择器——根据任务特征动态决定使用哪种编排模式，甚至在同一任务的不同阶段切换范式（类似ADOPT论文的Shapley自适应分配思想）。
-
Reflexion + ADOPT的融合：将Reflexion的语言化反思与ADOPT的依赖感知梯度估计结合——反思不再是自由形式的"我觉得哪里错了"，而是结构化的"步骤i的输出在维度j上偏离了预期，修正方向是k"。
-
编译范式 vs 运行范式的统一：LLMCompiler的DAG静态规划和ReAct的动态探索目前是两个极端。如何在编译阶段保留一部分"运行时可调整"的弹性（类似于JIT编译的思想），是一个开放问题。
-
多Agent的标准化通信协议：目前每个Multi-Agent系统都定义自己的通信格式。类似A2A（Agent-to-Agent Protocol）的标准化工作正在进行，未来不同系统之间的Agent可能可以跨平台协作。
参考论文：
- Yao et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023.
- Xu et al. (2023). ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models. arXiv:2305.18323.
- Kim et al. (2024). An LLM Compiler for Parallel Function Calling. ICML 2024.
- Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023.
- Zhao et al. (2025). ADOPT: Adaptive Dependency-Guided Joint Prompt Optimization for Multi-Step LLM Pipelines. arXiv:2512.24933.
小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用
更多推荐
8
0- 0
已为社区贡献1条内容
所有评论(0)