|
|
@@ -0,0 +1,46 @@
|
|
|
+# 对比一下 ReAct 和 Plan-and-Execute 模式，什么场景选择使用，比如给出具体案例
|
|
|
+
|
|
|
+**ReAct**和**Plan-and-Execute**是AI Agent两种主流的设计范式，核心区别在于“**何时做规划**”：
|
|
|
+
|
|
|
+| 维度 | **ReAct 模式** | **Plan-and-Execute 模式** |
|
|
|
+| :--- | :--- | :--- |
|
|
|
+| **核心思路** | **边想边做**。推理（Reason）→ 行动（Act）→ 观察（Observe）循环，每一步都根据上一步的结果动态决策。 | **先想后做**。规划器（Planner）先生成完整执行计划，执行器（Executor）再严格按照计划逐步执行。 |
|
|
|
+| **灵活性** | **极高**。能灵活应对环境变化和意外结果，随时调整路径。 | **较低**。计划一旦生成便固定，环境突变时可能失效。 |
|
|
|
+| **可预测性/审计性** | **较低**。执行路径动态变化，难以事前完全预测。 | **较高**。步骤清晰、可控，便于审计、追溯和资源预估。 |
|
|
|
+| **资源消耗** | 每步都需调用LLM推理，**Token消耗可能较多**。 | 仅需一次规划调用，但执行失败可能导致资源浪费。 |
|
|
|
+| **适合场景** | 探索性、诊断性、不确定性高的任务。 | 流程固定、步骤间依赖明确、对审计性要求高的任务。 |
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+#### 选择 ReAct 的场景：
|
|
|
+
|
|
|
+当任务的解决路径不清晰，需要“摸着石头过河”时，ReAct是更优解。它的优势在于**适应性和探索能力**。
|
|
|
+
|
|
|
+* **具体案例：智能客服/故障排查**
|
|
|
+ * **场景**：用户报告“无法登录”，原因可能多种多样（密码错误、账号冻结、网络问题等）。
|
|
|
+ * **ReAct 的执行过程**：
|
|
|
+ 1. **推理 (Thought)**：需要先确认账号状态。
|
|
|
+ 2. **行动 (Action)**：调用`查询账号状态`工具。
|
|
|
+ 3. **观察 (Observation)**：账号状态正常。
|
|
|
+ 4. **推理**：账号没问题，可能是密码错误，尝试引导重置。
|
|
|
+ 5. **行动**：调用`发送重置链接`工具。
|
|
|
+* **其他典型场景**：实时股票交易、动态信息检索、需要多步探索的研究分析。
|
|
|
+
|
|
|
+#### 选择 Plan-and-Execute 的场景：
|
|
|
+
|
|
|
+当任务目标和流程相对明确，且执行顺序和安全性至关重要时，Plan-and-Execute模式更可靠。它的核心价值在于**结构化和可控性**。
|
|
|
+
|
|
|
+* **具体案例：月度销售报告生成**
|
|
|
+ * **场景**：每月固定从三个系统拉数据、清洗、分析、生成图表并发送邮件。
|
|
|
+ * **Plan-and-Execute 的执行过程**：
|
|
|
+ 1. **规划 (Plan)**：规划器生成计划——1. 从CRM拉销售数据；2. 从财务系统拉成本数据；3. 合并计算利润；4. 生成图表；5. 撰写报告；6. 发送邮件给管理层。
|
|
|
+ 2. **执行 (Execute)**：执行器严格按照步骤顺序执行，每一步都清晰可查。
|
|
|
+* **其他典型场景**：自动化运维（先审核再执行）、批量数据处理、合规性审计流程。
|
|
|
+
|
|
|
+#### 💡 快速决策小测试
|
|
|
+
|
|
|
+你可以用一个简单问题来判断：**在开始执行任务前，你能列出所有需要调用的工具和步骤吗？**
|
|
|
+* **能** → 优先考虑 **Plan-and-Execute**。
|
|
|
+* **不能（需要看到中间结果才能知道下一步做什么）** → 选择 **ReAct**。
|
|
|
+
|
|
|
+在实际复杂项目中，二者也常被**混合使用**：先用Plan-and-Execute制定全局框架，在每个步骤内部用ReAct的循环机制来处理细节和异常，以达到兼顾全局与灵活性的效果。
|
