跳到主要内容

第 1.5.6 节：用 ReAct、Plan-and-Solve 和 Reflection 选择 Agent 范式

本节围绕“用 ReAct、Plan-and-Solve 和 Reflection 选择 Agent 范式”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够说清 ReAct、Plan-and-Solve 和 Reflection 的处理顺序、关键检查点和失败处理。

上一节已经把第一个 Agent（智能体）整理成演示脚本和面试讲法。本节继续补一个新手很容易跳过、但面试常被追问的问题：这个 Agent 到底采用哪种经典范式，为什么不是另一种？

这里不追求背论文名词，而是把 ReAct、Plan-and-Solve 和 Reflection 变成工程选择表。读完本节后，你应该能用同一个客服退款投诉任务，说明三种范式的状态字段、失败模式、适用边界和验收证据。

经典范式的价值不是给项目贴标签，而是帮助你控制任务如何推进、何时调用工具、何时停止、何时复核。工程边界是：范式只能决定流程组织方式，不能替代权限系统、字段契约、工具审批和人工复核。

三种范式先放到工程语言里​

范式工程理解适合的问题不适合的问题
ReAct（推理与行动交替）每一步都在“判断下一步、调用工具、读取结果、更新状态”之间循环。信息需要边查边判断，例如先查订单，再决定是否需要售后政策和人工审批。步骤固定、无需中途观察的简单分类任务。
Plan-and-Solve（先计划再执行）先生成任务计划，再按计划逐步执行，并在关键节点校验计划是否仍成立。多步骤任务、跨工具任务、需要向用户说明执行路线的任务。用户问题很短、一步就能完成的任务。
Reflection（反思修正）先产出候选结果，再用规则、样例或评审器检查并修正。需要提高回答质量、格式稳定性或风险控制的生成任务。高风险业务动作本身。反思不能替代权限、审批和工具校验。

实现步骤或决策流程​

实现时先不要问“用哪个框架更高级”，而要按任务复杂度、工具依赖、风险等级和验收证据选择范式。

同一个任务怎么选择​

任务：用户说“我买的耳机坏了，客服之前说可以退，我现在要你马上给我退款。”

读图重点：读图时先比较三条回环：观察回环、计划回环、修正回环；它们都不能绕过权限和人工门禁。

判断维度ReActPlan-and-SolveReflection
最小目标逐步确认订单、售后政策和风险。先拆出确认订单、核对政策、判断审批、生成回复四步。检查回复有没有承诺退款、有没有遗漏订单号、有没有风险提示。
必备状态字段current_step、tool_results、missing_fields、next_action、stop_reason。plan_steps、active_step、step_status、blocked_reason。draft_answer、review_findings、revision_count、final_decision。
最容易失败工具循环失控；每一步都查一点，但没有收束。计划写得漂亮，执行时没有根据工具结果调整。自我修正变成改写文案，没有发现业务风险。
停止条件信息不足、工具失败、需要人工审批、任务完成。计划完成、计划失效、关键步骤阻塞、需要重规划。达到修正次数、通过规则检查、仍不确定则转人工。
验收证据工具调用轨迹和状态迁移表。计划表、执行日志和计划变更记录。候选输出、检查项、修正记录和最终输出。

Mock-first 示例：ReAct 最小轨迹​

这里的“判断摘要”不是模型隐藏推理，而是系统允许记录的可审计决策摘要。

步骤输入或观察动作状态更新
1用户要求立即退款，但没有订单号。不调用退款工具，先识别缺失字段。missing_fields=["order_id"]，risk_level="medium"。
2用户补充订单号。调用 get_order_status 查询订单。used_tools=["get_order_status"]，保存工具结果摘要。
3工具返回订单已签收 45 天。调用 get_refund_policy 查询售后规则。current_step="policy_check"。
4规则显示超过普通退货期，但可走质保检测。生成安全回复并准备工单草稿。next_action="create_ticket_draft"，stop_reason="needs_user_confirm"。

ReAct 适合这个任务，是因为任务中间必须读取工具结果再决定下一步。如果只是“用户输入分类”，用 ReAct 反而会让流程变重。

Mock-first 示例：Plan-and-Solve 最小计划​

计划步骤执行条件失败处理
1. 收集订单号和商品问题用户没有提供订单号时阻塞。追问订单号，不进入工具调用。
2. 查询订单状态订单号格式合法。查询失败时记录错误并转人工。
3. 查询售后政策订单存在且商品类目明确。政策缺失时不能承诺退款。
4. 生成回复和工单草稿政策、风险和缺失字段明确。高风险或不确定时要求人工确认。

Plan-and-Solve 适合向读者或面试官展示“这个 Agent 怎么拆任务”。但计划不是一次写完就永远正确，工具结果可能让计划重排或提前停止。

Mock-first 示例：Reflection 最小检查​

检查项不合格样例修正方向
是否越权承诺退款“我马上给你退款。”改成“需要先核对订单和售后政策”。
是否遗漏必要字段没有订单号仍继续创建退款。先追问订单号或创建缺信息工单。
是否说明下一步只安抚用户，没有动作。明确下一步是核对订单、质保检测或人工处理。
是否保留审计信息没有记录为何拒绝自动退款。记录 review_findings 和 stop_reason。

Reflection 适合做输出质量和风险复核，不适合直接决定高风险业务动作。退款、审批、权限和资金动作仍然要交给工具契约、权限系统和人工门禁。

范式选择表​

场景首选范式为什么需要补的工程保护
客服问题分流简单状态机或轻量 ReAct只需识别意图、风险和缺失字段。输出 schema 校验、停止条件。
退款投诉预处理ReAct + Reflection需要查询订单和政策，也要检查回复是否越权。工具权限、审批、修正次数上限。
多部门工单流转Plan-and-Solve + ReAct需要先拆计划，再逐步执行。计划版本、步骤状态、异常转人工。
RAG 知识库问答ReAct 或 Reflection需要检索证据，也需要复核引用是否支撑答案。引用校验、拒答规则、检索日志。
高风险自动审批不建议只靠 Agent 范式范式不能替代业务控制。人工审批、权限系统、审计日志。

作品集里怎么写​

不要写“我使用了 ReAct 框架”。更好的写法是：

我把客服退款投诉任务拆成 ReAct 风格的受控循环：每一步只允许读取状态、调用白名单工具、保存工具结果摘要并判断停止条件。对最终回复再做 Reflection 风格的风险检查，防止越权承诺退款。整个流程有状态字段、工具轨迹、失败兜底和回归样例。

常见错误​

错误后果改法
把范式当成框架名词面试时只能背概念，讲不出工程边界。用同一个业务任务解释状态、工具、停止条件和验收证据。
用 Reflection 代替审批高风险动作可能被模型自我修正后直接放行。Reflection 只做输出复核，退款、删除、发布等动作仍走权限和人工门禁。
ReAct 没有停止条件工具循环失控，成本和延迟不可控。为每个循环设置最大步数、失败分支和转人工条件。
Plan-and-Solve 不允许重规划工具结果变化后仍按旧计划执行。给计划加版本、步骤状态和阻塞原因。

练习题​

基础练习​

用自己的话解释 ReAct、Plan-and-Solve 和 Reflection 的区别。要求用“查订单并生成售后回复”这个任务举例。

项目练习​

为你的第一个 Agent 写一张范式选择表，至少包含：任务类型、首选范式、必备状态字段、失败模式、停止条件和验收证据。

挑战任务​

把“售后投诉预处理 Agent”改成组合范式：先用 Plan-and-Solve 生成计划，再用 ReAct 执行工具步骤，最后用 Reflection 检查回复。要求说明每一层的边界，不能让 Reflection 直接批准退款。

本节交付物与面试讲法​

交付物要求
范式选择表能解释为什么选某种范式，以及为什么不用其他范式。
状态字段表至少列出计划、当前步骤、工具结果、修正次数和停止原因。
失败模式表覆盖循环失控、计划失效、自我修正失真、越权工具调用。
面试讲法能把范式讲成工程控制方式，而不是只背概念。

小结​

经典 Agent 范式不是标签，而是任务控制方式。ReAct 解决边观察边行动，Plan-and-Solve 解决先拆任务再执行，Reflection 解决候选结果复核。真正的工程能力，是知道什么时候组合它们，什么时候不用它们，以及用哪些状态、日志、权限和验收样例兜住风险。

继续学习​