ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别?实际项目怎么选型?


一则或许对你有用的小广告

欢迎加入小哈的星球,你将获得:专属的实战项目(4个项目都能学) / 1v1 提问 / 简历修改 / Java 学习路线 / 社群讨论 / 学习打卡 / 每月赠书

  • 《Spring AI 项目实战(问答机器人、RAG 智能客服、联网搜索)》已完结,基于 Spring AI + Spring Boot 3.x + JDK 21...查看介绍

  • 《从零手撸:仿小红书(微服务架构)》 已完结,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...查看介绍;演示链接:http://116.62.199.48:7070/

  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接:http://116.62.199.48/

  • 新开坑项目:《从零手撸:秒杀系统高并发优化实战》 正在更新中...,查看介绍

截止目前,星球内专栏累计输出 150w+ 字,讲解图 5110+ 张,还在持续爆肝中.. 后续还会上新更多项目,已有 4700+ 小伙伴加入学习,欢迎点击围观

面试考察点

  1. 范式理解深度:面试官想知道你是不是真理解这三种范式背后的 推理机制差异,不是只会说 "ReAct 就是边想边做"。这三种范式对应的是不同的任务假设,确定性任务、探索性任务、需要自我纠错的任务,能说清楚这个才算入门。

  2. 工程选型能力:能不能根据任务特点(步骤数、确定性、成本敏感度、错误容忍度)选合适的范式?这块是区分 "会用 LangChain4j" 和 "能独立设计 Agent 架构" 的分水岭。

  3. 组合应用意识:知不知道这三种范式 不是非此即彼,可以组合使用?生产级 Agent 一般都是 "Plan-and-Execute 做骨架 + ReAct 做执行 + Reflection 做兜底"。

核心答案

先给结论,一句话概括这三种范式的本质区别:

范式 核心机制 关键词 一句话定位
ReAct Reasoning + Acting 交替循环 "走一步看一步" 边想边干,实时反馈
Plan-and-Execute 先规划全局,再分步执行 "先画地图再走路" 全局视野,执行高效
Reflection 执行后自我反思 + 纠错重试 "做完复盘再做" 自我改进,提升准确率

选型核心逻辑

  • 任务路径不确定、需要边做边探索 → ReAct
  • 任务步骤多且复杂、需要全局规划 → Plan-and-Execute
  • 任务对准确率要求极高、允许多次重试 → Reflection(通常作为增强层叠加在前面两者之上)

实际项目里,这三种范式往往组合着用,不是单选题。

深度解析

一、ReAct 范式:边想边做的 "侦探"

ReAct(Reasoning and Acting)是最早的 Agent 范式之一,2022 年由 Yao Shunyu 等人提出。它让 LLM 交替输出 Thought(思考)→ Action(动作)→ Observation(观察结果),形成一个推理-执行循环。

ReAct 范式工作流程
ReAct 范式工作流程

上图是 ReAct 的核心循环。每一次 LLM 调用,模型都要走完 "想清楚下一步干啥 → 调工具 → 看结果 → 再想" 这个闭环。几个阶段:

  • Thought 阶段:模型把推理过程写出来,算是 Chain-of-Thought(CoT)的延伸
  • Action 阶段:模型决定调哪个工具、传什么参数
  • Observation 阶段:工具结果回灌给模型,作为下一轮推理的输入

ReAct 的优势

  • 实时适应性强:每一步都基于最新观察做决策,适合探索性任务
  • 实现简单:一个 Prompt 模板 + 工具循环就能跑起来
  • debug 友好:Thought 链路清晰可见,容易定位问题

ReAct 的短板

  • 没有全局视野:模型每次只看一步,复杂任务里容易跑偏。比如 "本想查 A,结果查到一半被 B 带跑了"
  • Token 消耗高:每一步都要把历史 Thought + Observation 全部塞进 Prompt,步骤一多上下文就爆
  • 容易陷入死循环:弱模型经常在 "再查一次" 这种动作里绕不出来

我做 AI 项目面试的时候,这道题几乎必问。很多候选人只知道 ReAct "好",说不出它在复杂任务上的短板,这就很难拿高分。

LangChain4j 实现 ReAct

LangChain4j 原生的 AiServices 默认走的就是 ReAct 风格的工具调用循环,看一段最小可运行代码:

// === Maven 依赖 ===
// <dependency>
//     <groupId>dev.langchain4j</groupId>
//     <artifactId>langchain4j</artifactId>
//     <version>1.0.0</version>
// </dependency>
// <dependency>
//     <groupId>dev.langchain4j</groupId>
//     <artifactId>langchain4j-open-ai</artifactId>
//     <version>1.0.0</version>
// </dependency>

import dev.langchain4j.agent.tool.Tool;
import dev.langchain4j.memory.chat.MessageWindowChatMemory;
import dev.langchain4j.model.chat.ChatLanguageModel;
import dev.langchain4j.model.openai.OpenAiChatModel;
import dev.langchain4j.service.AiServices;

public class ReActAgentDemo {

    // 1. 定义工具(LangChain4j 通过 @Tool 注解自动识别)
    public static class WeatherTools {

        @Tool("查询某个城市的实时天气")
        public String getWeather(String city) {
            // 实际项目里这里调外部天气 API
            return city + " 今天晴,气温 26℃";
        }

        @Tool("查询某个城市的景点推荐")
        public String getAttractions(String city) {
            return city + " 推荐景点:故宫、颐和园、天坛";
        }
    }

    // 2. 定义 Agent 接口
    interface TravelAssistant {
        String chat(String userMessage);
    }

    public static void main(String[] args) {
        // 配置 LLM(这里用 OpenAI,生产可换成通义千问、DeepSeek 等)
        ChatLanguageModel model = OpenAiChatModel.builder()
                .apiKey(System.getenv("OPENAI_API_KEY"))
                .modelName("gpt-4o")
                .build();

        // 3. 构建 Agent —— LangChain4j 底层自动走 ReAct 循环
        TravelAssistant agent = AiServices.builder(TravelAssistant.class)
                .chatLanguageModel(model)
                .chatMemory(MessageWindowChatMemory.withMaxMessages(20))
                .tools(new WeatherTools())  // 注册工具
                .build();

        // 4. 测试:模型会自动 Thought → Action → Observation 多轮循环
        String answer = agent.chat("我想去北京旅游,先帮我看看天气,再推荐几个景点");
        System.out.println(answer);
    }
}

这段代码的执行过程就是标准的 ReAct 循环:模型先想 "需要查天气"(Thought)→ 调用 getWeather(Action)→ 拿到天气结果(Observation)→ 再想 "需要查景点"(Thought)→ 调用 getAttractions(Action)→ 综合生成最终回答。

二、Plan-and-Execute 范式:先画地图再走路的 "项目经理"

Plan-and-Execute 是 LangChain 团队在 2024 年提出的范式,主要解决 ReAct "没有全局视野" 的痛点。核心思路是 把规划和执行彻底解耦

Plan-and-Execute 规划执行架构
Plan-and-Execute 规划执行架构

上图是 Plan-and-Execute 的双角色架构,几个角色分工:

  • Planner(规划器):拿到用户任务后,一次性 生成完整的多步骤计划,这一步要用推理能力强的大模型
  • Executor(执行器):严格按计划逐步执行,每个步骤可以是一个 ReAct 子 Agent,也可以是直接的工具调用
  • Re-planning(重规划):执行中发现原计划走不通(比如某个工具返回异常),可以回到 Planner 重新调整计划

对比 ReAct 的优势

维度 ReAct Plan-and-Execute
规划方式 边走边想 先想全再走
LLM 调用次数 多(每步都要推理) 少(规划一次,执行直接跑)
全局视野
Token 成本 高(历史越长 Prompt 越大) 低(Executor 只看当前步)
任务保持度 容易跑偏 强(有计划约束)

Plan-and-Execute 的坑

  • 计划僵化:任务环境变化快的话,静态计划会过时。所以 必须支持 Re-planning,否则就是 "一条道走到黑"
  • Planner 质量决定上限:Planner 用的模型不行,整个计划就是错的,Executor 再努力也白搭
  • 简单任务杀鸡用牛刀:3 步以内的小任务用 Plan-and-Execute 纯属浪费

LangChain4j 的 langchain4j-agentic 模块(2025 年新增):

LangChain4j 在 1.0 版本之后推出了 langchain4j-agentic 模块,支持用声明式方式编排多步骤 Agent 工作流,本质就是 Plan-and-Execute 思想的 Java 实现:

// === Maven 依赖 ===
// <dependency>
//     <groupId>dev.langchain4j</groupId>
//     <artifactId>langchain4j-agentic</artifactId>
//     <version>1.0.0</version>
// </dependency>

import dev.langchain4j.agentic.*;
import dev.langchain4j.model.chat.ChatLanguageModel;
import dev.langchain4j.model.openai.OpenAiChatModel;

public class PlanAndExecuteDemo {

    // 1. 定义各个执行步骤(每个方法对应 Plan 中的一个步骤)
    public static class ResearchWorkflow {

        @AgentTask(description = "第一步:根据用户问题收集背景资料")
        public String research(String topic) {
            // 实际项目里这里可以调用搜索工具 / RAG 检索
            return "已收集到关于 " + topic + " 的核心资料:...";
        }

        @AgentTask(description = "第二步:基于资料撰写大纲")
        public String outline(String researchResult) {
            return "大纲:\n1. 背景\n2. 核心分析\n3. 结论";
        }

        @AgentTask(description = "第三步:根据大纲完成正文")
        public String writeContent(String outline) {
            return "正文:基于上述大纲展开的完整文章...";
        }
    }

    public static void main(String[] args) {
        ChatLanguageModel model = OpenAiChatModel.builder()
                .apiKey(System.getenv("OPENAI_API_KEY"))
                .modelName("gpt-4o")
                .build();

        // 2. 用 AgenticOrchestrator 串成工作流 —— 规划 + 执行一体化
        //    底层逻辑:Planner LLM 决定调用顺序,Executor 逐步执行
        var workflow = AiServices.builder(ResearchWorkflow.class)
                .chatLanguageModel(model)
                .build();

        // 3. 触发执行
        String result = workflow.research("AI Agent 范式选型");
        System.out.println(result);
    }
}

多说一句,langchain4j-agentic 模块还在快速迭代,注解名和 API 可能会调整,实际项目落地前务必查阅 LangChain4j 官方文档 确认最新用法

三、Reflection 范式:会自我复盘的 "学生"

Reflection(也叫 Reflexion)是 Illinois 大学 2023 年提出的思路,核心是 让 Agent 对自己的输出做自我批判,然后基于反思结果重试

Reflection 反思范式流程
Reflection 反思范式流程

上图就是 Reflection 的工作方式。它不是一个独立的执行框架,是 可以叠加在任何执行框架之上的增强层。几个要点:

  • 自我批判:用另一个 LLM(或同一个 LLM 换角色)对上一次输出做评价,找出错误和不足
  • 记忆机制:把反思结论(verbal reinforcement)存入短期记忆,下次重试时作为上下文
  • 多次迭代:直到反思器判定通过,或达到最大重试次数

Reflection 的适用场景

  • 代码生成:生成代码 → 反思 → 修正 → 再生成,HumanEval 准确率能提升 10%+
  • 复杂推理:数学题、逻辑题这种有明确对错的任务
  • 文案润色:初稿 → 反思 → 精修

Reflection 的代价

  • LLM 调用次数翻倍:每轮都要额外做一次反思调用,成本敏感场景慎用
  • 可能过度反思:弱模型反思器会 "鸡蛋里挑骨头",越改越差
  • 对反思器质量要求高:反思器得能看出问题,否则等于白做

Spring AI 实现 Reflection

Spring AI 没直接提供 Reflection 的开箱即用 API,但它的 ChatClient 流式调用和 Advisor 机制,可以方便地实现 Reflection 循环:

// === Maven 依赖 ===
// <dependency>
//     <groupId>org.springframework.ai</groupId>
//     <artifactId>spring-ai-starter-model-openai</artifactId>
// </dependency>

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.chat.model.ChatModel;
import org.springframework.stereotype.Service;

@Service
public class ReflectionAgent {

    private final ChatClient executorClient;   // 执行器:生成答案
    private final ChatClient reflectorClient;  // 反思器:批判答案

    private static final int MAX_ITERATIONS = 3;

    public ReflectionAgent(ChatModel chatModel) {
        this.executorClient = ChatClient.builder(chatModel)
                .defaultSystem("你是一个严谨的技术答主,请根据问题生成高质量回答。")
                .build();

        // 反思器用不同的 system prompt,扮演 "面试官" 角色
        this.reflectorClient = ChatClient.builder(chatModel)
                .defaultSystem("""
                    你是一个严格的技术面试官,请批判性地评估下面的回答。
                    如果回答存在事实错误、逻辑漏洞、遗漏关键点,请明确指出并给出改进建议。
                    如果回答已经足够好,请回复 "PASS"。
                    """)
                .build();
    }

    public String answerWithReflection(String question) {
        // 1. 初次生成
        String currentAnswer = executorClient.prompt()
                .user(question)
                .call()
                .content();

        // 2. 反思 + 迭代
        for (int i = 0; i < MAX_ITERATIONS; i++) {
            String reflection = reflectorClient.prompt()
                    .user("问题:" + question + "\n\n当前回答:" + currentAnswer)
                    .call()
                    .content();

            // 反思器认为合格,提前退出
            if (reflection.contains("PASS")) {
                break;
            }

            // 带着反思建议重新生成
            currentAnswer = executorClient.prompt()
                    .user("""
                        问题:%s
                        上一版回答:%s
                        反思建议:%s
                        请根据反思建议,重新生成更好的回答。
                        """.formatted(question, currentAnswer, reflection))
                    .call()
                    .content();
        }

        return currentAnswer;
    }
}

这段代码用 Spring AI 的 ChatClient 把 Executor 和 Reflector 拆成两个独立的客户端。生产环境强烈建议用两个不同规格的模型:Executor 用便宜的小模型跑量,Reflector 用强模型把关,成本和效果都能兼顾。

四、三种范式的横向对比

一眼看清差异,画个综合对比图:

三种 Agent 范式对比
三种 Agent 范式对比

从执行复杂度和适用任务维度再拉个表格:

维度 ReAct Plan-and-Execute Reflection
决策时机 每一步实时决策 开头一次性规划 执行后事后批判
典型步骤数 1-5 步 5-20 步 任意(迭代增强)
LLM 调用成本 中(每步都推理) 低(规划一次) 高(每轮多一次反思)
任务确定性 路径不明确 路径明确但复杂 要求高准确率
典型场景 信息检索、客服问答 复杂报告生成、多源数据整合 代码生成、数学推理、文案润色
失败模式 跑偏、循环 计划僵化 过度反思、成本爆炸

五、实际项目怎么选型?给个可落地的决策树

说了这么多,面试官最爱问的还是 "你项目里怎么选的"。我给一个我自己在用的决策思路:

Agent 范式选型决策图
Agent 范式选型决策图

结合这张图,说几个我踩过的坑和总结的经验:

  1. 默认选项就是 ReAct:80% 的简单 Agent 场景(客服、问答、工具调用),用 LangChain4j 默认的 AiServices 就够了。别一上来就堆 Plan-and-Execute,那是过度设计。

  2. 步骤数超过 5 步、有关键依赖链,才考虑 Plan-and-Execute:比如 "查竞品数据 → 分析市场份额 → 生成报告 → 发邮件" 这种长链路任务,ReAct 很容易在中间步骤跑偏,Plan-and-Execute 能稳住。

  3. Reflection 作为增强层用,别独立用:纯 Reflection 没意义,它必须叠加在 ReAct 或 Plan-and-Execute 之上。最常见的组合是 Plan-and-Execute + Reflection:规划后执行,执行后反思,不行就重规划。

  4. 成本敏感场景慎用 Reflection:每次反思都是一次完整的 LLM 调用,用户量大的话成本直接翻 2-3 倍。建议只在关键步骤加反思,不是每步都反思。

  5. 2026 年的新趋势,混合架构 + Multi-Agent:Spring AI 官方博客在 2026 年初推出了 Agentic Patterns 系列文章 ,LangChain4j 也推出了 langchain4j-agentic 模块,都是奔着 "让开发者更容易组合这些范式" 去的。面试时提到这个趋势,面试官会觉得你一直在跟进最新实践

面试高频追问

  1. 追问一:ReAct 和 Plan-and-Execute 能不能用同一个模型?

    可以,但建议分工。Planner 用推理能力强的大模型(如 GPT-4oClaude SonnetDeepSeek-R1),Executor 可以用便宜快的小模型(如 GPT-4o-miniQwen-Turbo),这样在成本和效果之间找平衡,是生产环境的常见做法。

  2. 追问二:Reflection 会不会陷入 "越改越差" 的死循环?

    会。这叫 过度反思(over-reflection)。解决办法有三:(1)设置最大迭代次数(如 3 次);(2)用强模型当反思器,弱模型当执行器;(3)反思器必须有明确的 "PASS" 退出机制,不能无限制改下去。

  3. 追问三:Multi-Agent 和这三种范式是什么关系?

    Multi-Agent 是 架构层面 的概念(多个 Agent 协作),这三种是 单 Agent 内部 的推理范式。Multi-Agent 系统里的每个子 Agent,内部仍然可以用 ReAct 或 Plan-and-Execute。两者是正交关系,不是替代。

常见面试变体

  • "ReAct 范式的 Thought-Action-Observation 循环,具体是怎么实现的?"
  • "为什么 Plan-and-Execute 比 ReAct 更省 Token?"
  • "Reflection 和 RLHF 有什么区别?"(前者是推理时自我纠错,后者是训练阶段优化)
  • "你在项目里遇到过 Agent 死循环怎么解决的?"(这个特别爱问,准备好真实案例)

记忆口诀

"一思一做 ReAct,先画图后走路 PE,做完复盘 Reflection"

或者更精简:ReAct 边走边想,PE 先想后走,Reflection 想完再走

总结

这三种范式不是替代,是互补:ReAct 适合探索性任务,Plan-and-Execute 适合复杂确定性任务,Reflection 是叠加在任何框架之上的准确率增强层。面试时把握住 "根据任务特点选型 + 生产环境组合使用" 这两条主线,基本就能答到面试官想听的点上。