pdf版下载链：https://pan.quark.cn/s/9cc742e9c2a8

22 Agent 规划与反思：ReAct、Reflexion 与 LATS

难度： ⭐⭐⭐⭐⭐
更新： 2026-10-12
考点： ReAct局限性、Plan-and-Solve、REWOO、Reflexion、LATS、自主演规划、动态重规划

📋 目录

1. 从 Copilot 到 Agent：范式转变
2. 规划模式：ReAct 局限与优化
3. 反思模式：自我修正架构
4. 高阶架构：LATS 与 Reflexion
5. 工程实践与面试总结

一、从 Copilot 到 Agent：范式转变

Q1: Copilot 和 Agent 的核心区别是什么？为什么需要规划和反思？

图解：Copilot vs Agent

💡 答案要点

核心区别：控制权归属

为什么 Agent 需要规划和反思？

LLM 本质是"下一个 Token 预测器"——概率性、无记忆、自主性弱
没有外部架构约束 = 误差累积（Error Compounding）
一步错 → 步步错

所以需要：
规划（Planning）= 解决"视野狭窄"问题，强制先建立全局观
反思（Reflection）= 解决"误差累积"问题，执行-观察-评价-修正循环

面试话术：

"Copilot 偏人主导，Agent 偏目标驱动闭环。长任务要把计划、执行状态、验收条件和恢复点外置；是否引入 Planner、并行 Executor 或反思器，要用任务成功率、成本和尾延迟做消融。"

Q2: 什么是 Chain（链）和 Loop（环）的架构差异？

💡 答案要点

Chain vs Loop 对比：

Chain（传统 LLM 应用）：
Input → Step A → Step B → Step C → Output
                    ↑
              任何一步错 → 整体失败

Loop（Agent 架构）：
┌─────────────────────────────────────┐
│         Goal（目标）                  │
│             ↓                       │
│         Plan（规划）                  │
│             ↓                       │
│         Act（执行）                   │
│             ↓                       │
│        Observe（观察）                │
│             ↓                       │
│        Reflect（反思）                │
│         ↓         ↓                  │
│     达标✓     未达标→ Re-plan ──────┘

为什么 Loop 更适合复杂任务？

面试话术：

"从 Chain 到 Loop 是从线性执行到递归闭环的升级。Chain 容错性差，Agent 任何一步幻觉都会导致最终结果错误。Loop 引入了反思——生成代码后先自我 Review，不达标就打回重做。这种'生成-评估-修正'循环是用延迟换质量，对生产级 AI 应用至关重要。"

二、规划模式：ReAct 局限与优化

Q3: ReAct 模式的核心原理是什么？它有哪些常见工程缺陷？

图解：ReAct 的优势与风险

💡 答案要点

ReAct = Reason + Act（边想边做）

三个常见缺陷（并非所有实现必然出现）：

缺陷1：上下文漂移（Context Drift）

• 长链路任务中，ReAct 容易"忘记"原始目标
• 每一步的 Thought 都是贪婪的局部最优
• 10 步任务 → 第8步 Agent 可能已经跑偏
• 结果：误差累积，最终答案与目标南辕北辙

缺陷2：高延迟（串行执行）

问题：ReAct 必须等上一步完成才能下一步
三个搜索无依赖，ReAct 串行执行：
  总时间 = T1 + T2 + T3
实际上可以并行：
  并行时间 = max(T1, T2, T3) ≈ T1

缺陷3：规划与执行耦合

• ReAct 的 Prompt 混合了"策略规划"和"参数填充"
• 模型既要决定下一步做什么，又要决定用什么工具、填什么参数
• 认知负担重，容易产生幻觉参数

面试话术：

"ReAct 的优势是观察后可动态调整，代价是上下文增长、局部决策和潜在串行。任务是否需要 Planner/Executor 解耦，应根据依赖图、可逆性和错误成本决定。"

Q4: 什么是 Plan-and-Solve？它和 ReAct 的核心区别是什么？

图解：Plan-and-Solve 流程

💡 答案要点

Plan-and-Solve = 先规划，再执行（解耦）

Plan-and-Solve（先规划后执行）：
阶段1（规划）：Planner 一次性制定完整 DAG
  → "1. 搜索iPhone15 → 存#A
     2. 搜索Pixel8  → 存#B    （与#A无依赖，可并行）
     3. 比较#A和#B"

阶段2（执行）：Executor 并行执行所有无依赖步骤
  → 同时触发：search("iPhone15") 和 search("Pixel8")
  → 结果填充到 #A 和 #B

阶段3（求解）：Solver 根据填充好的计划生成答案

核心区别对比：

面试话术：

"Plan-and-Solve 解耦规划与执行，无依赖节点可以并行；但环境变化大时要配动态重规划，收益必须按任务 DAG 实测。"

Q5: 什么是 REWOO？它有哪些核心优势？

图解：REWOO 变量化执行

💡 答案要点

REWOO = Reasoning Without Observation（不用观察的推理）

核心思想：把"工具调用"和"推理"完全分开

REWOO：
阶段1（Plan）：只生成计划，不包含任何 Observation
  → Prompt = 用户问题 + "生成包含变量占位符的计划"
  → 输出：Plan = "E1: search(#A="iPhone"), E2: search(#B="Pixel")"

阶段2（Execute）：并行执行所有工具，不读 Prompt
  → 并行执行：search("iPhone") → #A, search("Pixel") → #B

阶段3（Solve）：用原始问题 + 执行结果生成答案

REWOO 的三大优势：

面试话术：

"REWOO 把计划、工具执行和求解分开，可减少 observation 反复进入规划上下文；但遇到依赖实时观察的任务需要重规划或退回交互式执行。"

Q6: 什么是动态重规划？什么时候需要触发重规划？

图解：何时触发动态重规划

💡 答案要点

动态重规划 = 执行过程中发现计划失效，实时更新计划

触发重规划的三种情况：

重规划架构：

def execute_with_replanning(goal):
    plan = planner.create_plan(goal)
    for attempt in range(max_retries):
        results, failed_step = execute_plan(plan)
        if failed_step is None:
            return results  # 全部成功
        # 触发重规划，传入当前状态+失败原因
        plan = planner.replan(goal, results, failed_step)
    return {
   "status": "failed"}

面试话术：

"动态重规划解决的是'静态计划的脆弱性'问题。我的实现是：每个执行节点用 try-catch 包裹，失败就把当前状态和错误原因传回 Planner，Planner 更新剩余计划而不是全盘重来。这样避免了'一步错就全盘重来'的资源浪费，实测重规划触发率约 15-20%。"

三、反思模式：自我修正架构

Q7: 什么是 Generator-Evaluator 架构？为什么需要反思？

💡 答案要点

Generator-Evaluator = 生成器-评估器 循环

反思架构：
用户问题 → Generator → 初步输出
                          ↓
                    Evaluator 评估
                          ↓
                   达标？ → ✅ → 返回
                      ↓ ❌
                   Reflector 生成修改意见
                          ↓
                    Generator 修正
                          ↓
                      再评估（循环）

为什么需要反思？

面试话术：

"反思机制是生成、评估、修正循环；只有评估信号可验证且额外轮次的质量收益超过成本时才值得启用。"

Q8: Reflexion 和普通反思有什么区别？它的记忆机制是什么？

图解：Reflexion 反思记忆机制

💡 答案要点

Reflexion = 通过语言反馈和 episodic memory 改进后续 trial，不更新模型权重

普通反思（单任务内）：
  Task1: 生成 → 反思(失败) → 修正 → 成功
  问题：Task2 的失败教训无法传递给 Task3

Reflexion（跨 trial 的 episodic memory）：
  Task1: 生成 → 反思(失败) → 修正 → 成功 → 存入记忆
  Task2: 生成 → 检索记忆 → 发现Task1相关经验 → 避免重蹈覆辙

Reflexion 三步循环：

1. Act（行动）：Agent 尝试执行任务
2. Evaluate（评估）：外部 Evaluator 打分
3. Reflect（反思）：
   • 失败 → 生成语言反思存入记忆
   • 成功 → 也存入（记录成功路径）
   • 下次遇到类似任务 → 检索记忆避免重蹈覆辙

面试话术：

"Reflexion 把环境/评估反馈转成文字反思，放入 episodic memory 指导下一次尝试；原论文不是通过梯度更新，也不能直接等同于任意跨用户的永久记忆。"

四、高阶架构：LATS 与 Reflexion

图解：LATS 搜索与反思

Q9: 什么是 LATS？它和 Reflexion 有什么区别？

💡 答案要点

LATS = Language Agent Tree Search（语言 Agent 树搜索）

核心思想：用树搜索做规划和反思

ReAct：线性探索，一条路走到黑
Reflexion：单路径 + 记忆
LATS：同时探索多条路径，选最优

LATS 树结构：
                    Root（目标）
                   /   |   \
              Node1  Node2  Node3（三个不同策略）
             / | \   / | \   / | \
           ...  (每个节点都是一次 Act-Eval-Reflect 循环)

评估：每条路径都走一遍 → 选得分最高的路径

LATS vs Reflexion 对比：

面试话术：

"LATS 是树搜索在 Agent 规划中的应用，核心思想是'多路径探索+选择最优'。Reflexion 像'错题本'，同类题做错了记下来；LATS 像'试错'，同时试三条路选走得最远的。LATS 适合高风险决策场景（比如金融交易），普通 Agent 任务 Reflexion 就够了。"

Q10: 如何设计一个具备"反思"能力的生产级 Agent？有哪些关键工程问题？

💡 答案要点

五大工程挑战：

挑战1：评估器准确率

• Evaluator 本身也是 LLM，可能误判
• 解决：用多维度打分而非单一判断

挑战2：反思死循环

• Agent 反反复复无法收敛
• 解决：设置最大循环次数 + 收敛判断

挑战3：Token 成本爆炸

• 反思循环的多次 LLM 调用 → 成本暴增
• 解决：分层评估，简单任务用小模型，复杂任务才调大模型

挑战4：记忆存储与检索

• Reflexion 记忆太多检索变慢
• 解决：用向量数据库存储 + 按类型分类

挑战5：何时触发反思

• 反思不是免费的，何时该触发？
• 解决：基于规则 + 基于置信度双保险

面试话术：

"生产级反思 Agent 的核心是平衡'质量'和'成本'。五大工程坑：评估器可能误判（用多维度代替单判断）、反思死循环（设 max_iter + 收敛判断）、Token 成本爆炸（分层评估简单任务用小模型）、记忆检索慢（向量数据库）、触发时机（规则+置信度双保险）。我的经验是：先用 Reflexion 简单实现看效果，瓶颈出现再逐个优化。"

版本: v3.0 | 更新: 2026-10-12

六、2026年新型 Agent 架构：Voyager 与 AutoGen v3（Q11-Q12）

Q11: Voyager 是什么？为什么它仍是技能库架构的重要参考？

💡 答案要点

Voyager = Minecraft 世界里的"终身学习 Agent"

Voyager 是 2023 年论文中的 Minecraft Agent，不是 2026 年新发布。其长期价值在于自动课程、迭代式 prompting 和可执行技能库三个组件，为“把成功轨迹沉淀为可复用技能”提供了清晰范式。

核心组件：

Voyager 架构：
┌─────────────────────────────────────────────────────┐
│                  技能库（Skill Library）              │
│  minecraftcraft_sword() / build_shelter() / ...   │
│  每个技能 = 可复用的 Python 函数                      │
└─────────────────────────────────────────────────────┘
                         ↑
┌─────────────────────────────────────────────────────┐
│ 迭代式 Prompt 优化（Iterative Prompting）            │
│  任务失败 → 修改 Prompt → 再试 → 直到成功             │
│  成功 → 提取为技能存入技能库                          │
└─────────────────────────────────────────────────────┘
                         ↑
┌─────────────────────────────────────────────────────┐
│                 环境反馈（Environment）               │
│  Minecraft 游戏状态 + LLM 判断                       │
└─────────────────────────────────────────────────────┘

与 Reflexion 的关键区别：

为什么重要：

传统 Agent：每次任务从零开始
Voyager：每次任务从技能库开始

工程价值：
- 成功行为可沉淀为带描述的可执行技能
- 后续任务检索并组合技能，而非完整重放历史轨迹
- 技能必须版本化、测试、最小权限、支持撤销，不能直接信任模型生成代码

面试话术：

"Voyager 的启发是把经验从自由文本升级为可检索、可执行、可验证的技能；生产系统还需给技能加测试、权限、版本和审计。"

Q12: AutoGen 和 CrewAI 有什么区别？“指挥官-工作器”模式如何落地？

💡 答案要点

截至 2026-10，AutoGen 官方稳定文档提供 AgentChat、Core 和 Extensions 等分层；常用 AgentChat API 包括 AssistantAgent、CodeExecutorAgent、UserProxyAgent 等。官方稳定 API 中没有 from autogen import Agents 或 Agents.ManagerAgent，不要背诵不存在的 “AutoGen v3” 示例。参考：AutoGen 官方文档。

AutoGen 与 CrewAI 的差异应从抽象层和控制方式回答，而不是简单概括成“动态 vs 静态”：

指挥官-工作器模式：

用户目标
   ↓
Commander：拆解任务、分配预算、定义验收条件
   ├─ Researcher：检索并返回带来源的证据
   ├─ Analyst：分析数据并输出结构化结论
   └─ Writer：基于证据生成最终内容
   ↓
Commander：校验覆盖率、冲突、成本和完成条件

生产落地要点：

1. 子任务使用结构化 schema，明确输入、输出、截止时间和验收条件。
2. 只有相互独立的子任务并行；存在数据依赖时按 DAG 执行。
3. Commander 不盲信子 Agent，必须核验来源、工具结果和输出格式。
4. 设置最大步数、预算、超时、取消和失败补偿，避免 Agent 相互对话不停止。
5. 记录任务树、消息、工具调用、模型版本、Token 和最终结果，支持轨迹评估。

面试话术：

"我不会把多 Agent 等同于让多个模型自由聊天。指挥官负责拆解、预算和验收，工作器只拿最小必要上下文并返回结构化结果；编排层负责超时、重试、取消和审计。框架选 AutoGen 还是 CrewAI 取决于消息运行时与流程控制需求，简单任务优先单 Agent 或确定性工作流。"

七、2026 长任务 Agent 架构（Q13）

Q13: 如何让 Agent 稳定执行跨小时、跨进程、跨上下文窗口的长任务？

💡 答案要点

长任务不是“给模型更长上下文”就能解决。UltraHorizon、AgentLongBench、AMA-Bench 等论文显示，动态状态综合、高密度工具日志、因果/目标记忆和早期子计划错误仍会随 horizon 放大。

推荐六层架构：

Goal Contract
  ├─ 成功/失败/停止条件、预算、权限
Durable Plan
  ├─ DAG、依赖、版本、剩余任务，不把计划只放在对话里
Durable Runtime
  ├─ checkpoint、幂等节点、重试/取消/补偿、租约与心跳
Context Manager
  ├─ 工作集、摘要/compaction、旧工具结果清理
Memory
  ├─ episode/事实/技能分层；按需检索；来源、TTL、权限、删除
Verifier & Human Gate
  └─ 环境断言、代码/规则/LLM judge；不可逆动作人工确认

截至 2026-10 的官方实现事实：

• LangGraph：checkpointer 在 super-step 边界保存状态，成功节点可保留 pending writes；interrupt() 可暂停并以同一 thread_id 恢复。节点恢复时可能从函数开头重跑，因此副作用必须幂等。
• MCP 2026-07-28 Tasks 扩展：tasks/get、tasks/update、tasks/cancel 和 durable task ID 支持异步长操作；客户端应持久化 task ID 以便崩溃后继续轮询。
• Anthropic：长会话以 server-side compaction 为主，context editing 可清理旧 tool/thinking 内容，memory tool 把跨会话文件存储交给客户端控制。
• OpenAI Agents SDK：Session 管理运行间历史，Runner 有 max_turns，handoff 可过滤上下文，tracing 记录 model/tool/guardrail/handoff；这些能力仍需业务侧持久任务状态。

重规划与反思策略：

1. 只在前提变化、工具失败、验证不通过或预算漂移时重规划；保留已验证产物，不全盘重来。
2. 反思必须引用失败证据并输出可执行修正；限制轮数，检测重复状态。
3. 工作记忆只保留当前约束、未决问题和已验证结论；原始日志进入外部存储，可按需回取。
4. 技能/长期记忆写入前做去重、事实核验、权限和 TTL；用户可查看、修正和删除。
5. 用任务完成率、恢复率、错误发生步、无效工具调用、人工介入率、成本和 wall-clock 评估，不只看最终文案。

面试话术：

"长任务的关键不是无限上下文，而是把计划、状态和产物持久化；每个节点可重放且幂等，context 只放当前工作集，完成条件由环境验证。模型进程可以随时重启，任务仍能从 checkpoint 恢复。"