何为ReAct模式 & Plan+Act框架

文章目录

前言
manus介绍
ReAct模式
- 介绍
- [AI Agent能力演进的几个关键阶段](#AI Agent能力演进的几个关键阶段)
- - - [**1. "前世"：单一能力与早期探索**](#1. “前世”：单一能力与早期探索)
    - [**2. "诞生"：ReAct 模式的提出 (2022)**](#2. “诞生”：ReAct 模式的提出 (2022))
    - [**3. "进化"：Plan-and-Act 框架的兴起**](#3. “进化”：Plan-and-Act 框架的兴起)
为什么需要ReAct模式？
- 当前碰到的痛点描述
- ReAct模式如何解决？
相关工具框架
参考资料
资料获取

前言

博主介绍：✌目前全网粉丝4W+，csdn博客专家、Java领域优质创作者，博客之星、阿里云平台优质作者、专注于Java后端技术领域。

涵盖技术内容：Java后端、大数据、算法、分布式微服务、中间件、前端、运维等。

博主所有博客文件目录索引：博客目录索引(持续更新)

CSDN搜索：长路

视频平台：b站-Coder长路

manus介绍

官网：https://manus.im/

Manus（又称OpenManus）是一个先进的多智能体（Multi-Agent）框架 ，其核心理念是通过多个专业智能体（Agent）之间的分工协作 来解决复杂任务。在人工智能领域，单个大语言模型（LLM）在处理简单问答和内容生成方面表现出色，但在面对需要多步骤推理、工具调用和动态决策的复杂场景时，往往显得力不从心。Manus通过引入任务规划-执行-总结的协同工作模式，将复杂问题拆解为一系列可执行的子任务，并由专门的智能体分别处理，最终整合结果，显著提升了复杂任务的处理成功率。

Manus框架的设计遵循了ReAct（Reasoning-Acting）模式 和PLAN-ACT范式，使得AI系统不仅能够生成回答，还能进行复杂推理、分步执行和动态调整。

在实际应用中，Manus可以完成诸如"打开百度搜索阿里巴巴最近一周股价，并根据搜索到的信息绘制股价趋势图保存到本地"这样的复杂指令，这需要浏览器操作、数据提取、图表生成和文件保存等多个步骤的协调执行。与传统的单智能体系统相比，Manus的多智能体协作架构将复杂任务的端到端成功率提升了4-6倍，为AI应用从Demo演示走向生产环境奠定了坚实基础。

ReAct模式

介绍

ReAct (Reasoning + Acting) 模式

通过大模型的思考来生成推理轨迹和任务特定行动，从而允许两者之间产生更大的协同效应：推理轨迹帮助模型归

纳、跟踪和更新行动计划以及处理异常情况，而行动则使其能够与知识库或环境等外部资源接口并从中收集额外信

息，这就是ReAct模式，参考论文地址：https://arxiv.org/pdf/2210.03629 【2023年】

AI Agent能力演进的几个关键阶段

1. "前世"：单一能力与早期探索

仅推理 (Reasoning-Only) ：早期的语言模型主要专注于文本生成和补全。它们可以进行"思维链"推理，即在最终答案前生成一系列的推理步骤。这极大地提升了模型在复杂问答任务上的表现。但缺点是：模型的推理可能基于其内部知识（可能过时或不准确），且无法与外部世界互动来验证或获取新信息。
仅行动 (Acting-Only) ：也存在一些系统，它们可以调用API或工具（如计算器、搜索引擎），但它们的行动往往是基于简单的模式匹配或指令，缺乏深度的、基于上下文的推理来指导为什么 要执行这个行动以及何时执行。

2. "诞生"：ReAct 模式的提出 (2022)

核心论文 ：《ReAct: Synergizing Reasoning and Acting in Language Models》 (Yao et al., 2022)

背景：研究者意识到，将推理和行动分离限制了Agent的能力。一个真正强大的Agent应该像人类一样：在行动前先思考，在思考后验证。
核心理念 ：协同（Synergize） 。ReAct模式将Reasoning（推理） 和Acting（行动） 交织在同一个循环中。
- 推理：让Agent决定下一步该做什么、为什么要这么做。
- 行动：执行决定的操作（如调用工具），并观察结果。
工作流程（Thought - Act - Observation）：

1. Thought：Agent根据任务和之前的观察，推理出下一步应该执行什么行动，以及为什么。
2. Act ：执行具体的行动，例如 Search(...), Calculate(...), Python_REPL(...)。
3. Observation：从外部环境（工具、API）获取行动的结果。
4. 循环上述步骤，直到任务完成。

解决的问题：
- 减少幻觉：通过从外部获取事实信息，减少模型编造答案。
- 提升可信度：推理轨迹使Agent的决策过程透明化。
- 处理错误：当观察结果与预期不符时，Agent可以调整策略。

示例：回答"莱昂纳多·迪卡普里奥的女朋友是谁，她凭借哪部电影获得了金球奖？"

Thought: 我需要先找到莱昂纳多·迪卡普里奥的现任女友。我可以使用搜索工具。
Act: Search("Leonardo DiCaprio current girlfriend")
Observation: [结果显示是维基百科条目，女友是某位演员...]
Thought: 我的问题是关于这位演员凭借哪部电影获得了金球奖。我需要搜索她的获奖记录。
Act: Search("[演员姓名] Golden Globe award movie")
Observation: [结果显示她凭借《XXX》电影获奖...]
Thought: 现在我有了所有信息，可以给出最终答案了。

3. "进化"：Plan-and-Act 框架的兴起

ReAct模式在处理中等复杂度任务时表现出色，但当任务极其复杂、需要多步骤规划时，它的"走一步看一步"策略可能显得短视，容易迷失在细节中。

核心理念 ：先总体规划，再分步执行。这借鉴了经典AI中的"分层规划"思想。

Plan（规划）阶段：
- 首先，让一个专门的Planning Agent （或让主Agent进行一次深度思考）对整个任务进行全局性的、高层次的分解。
- 输出一个结构化的计划，例如一个任务列表或流程图，明确列出需要完成的子任务及其依赖关系。
Act（执行）阶段：
- 然后，由一个或多个Execution Agent（或同一个Agent）按照规划好的步骤，逐一执行每个子任务。
- 每个子任务的执行本身，可能就是一个微型的 ReAct 循环。
与ReAct的关系 ：Plan-and-Act 不是取代 ReAct，而是对它的增强和扩展。你可以将其视为：
- ReAct：战术层面的循环（如何解决当前这一步）。
- Plan-Act：战略层面的规划（整个战役的蓝图是什么）。

示例：任务"分析本季度财报，从数据库中提取销售数据，生成图表，并通过邮件发送给经理。"

Plan阶段：

1. 调用 Data_Analyst_Agent 分析财报，确定关键指标。
2. 调用 DB_Query_Agent 根据指标从数据库提取数据。
3. 调用 Chart_Generator_Agent 将数据可视化为图表。
4. 调用 Email_Agent 将分析报告和图表发送给经理。

Act阶段：系统会按照这个计划，依次或并行地调用相应的Agent去执行每个步骤。

梳理下：

ReAct模式 诞生于2022年，是为了解决推理与行动割裂的问题，是现代AI Agent的基础执行单元。
Plan-and-Act框架 是在ReAct之上，为了管理更复杂、更长期的任务而自然演进出的系统级架构。它通过引入明确的规划阶段，让Agent的行为更具目的性和条理性。

为什么需要ReAct模式？

当前碰到的痛点描述

1、一个复杂问题会导致当前目标解决不明确，循环调用工具

基于langchain4j本身提供的defaultaiservices，实际上每次就是将消息+tools发送给ai，ai如果返回了tool调用，那么就表示需要调用工具，但是我个人发现一旦问题复杂了，同时还带有多个工具的情况下，会出现目标不明确导致循环不断调用tools工具的问题，我通过思考在想是否可以通过react模式来进行解决？

2、调用工具一多，或者某个工具返回值结果过多会出现上下文撑爆的情况

对于第二个问题实际上不在本章节内容中去解决，后续会单独去优化处理，主要是解决第一个问题。

分析如下：

对于问题1，最初级的做法是直接将用户问题和一个工具列表（Tools）扔给大模型，然后期望模型能直接返回一个工具调用或最终答案。以LangChain4j的DefaultAiServices为代表的早期模式，正是这一思想的体现。这种方法在简单、单一的任务上表现良好，例如"今天的天气怎么样？"或"计算一下158的平方根"。

然而，一旦任务变得复杂、多步骤、需要上下文推理时，这种"一次性投喂"模式的局限性就会暴露无遗，这正是ReAct模式所要解决的核心问题。

一旦"目标不明确导致循环不断调用tools工具"的现象，业内常被称为"工具乱舞"或"死循环"。其根本原因在于：无法进行深度推理 ：模型在决定调用哪个工具前，缺乏一个明确的"思考"环节来解释"我为什么要调用这个工具？""我期望得到什么结果？""这个结果将如何推动任务前进？"。没有这个推理过程，模型的行动就像是条件反射，而非深思熟虑的策略。

举一个典型的失败场景 ：

用户提问："阿里巴巴和腾讯这两家公司，哪一家最近一个季度的营收增长率更高？"

在默认DefaultAiServices模式下，模型可能会：

直接调用 get_company_revenue("阿里巴巴")。
拿到结果后，直接调用 get_company_revenue("腾讯")。
然后......它可能就停住了，因为它没有"思考"到下一步应该是计算增长率 并比较。或者，它可能错误地再次调用之前的工具，因为它不知道接下来该做什么，后续还会无限不断调用工具，直到会出现死循环结束。

ReAct模式如何解决？

ReAct模式通过强制模型在每一次行动之前，都必须先产生一个明确的"思考"，完美地解决了上述问题。这个简单的设计，带来了根本性的改变：

目标导向与上下文连贯：每一个"思考"步骤都要求模型将当前行动与最终任务目标联系起来。这使得Agent的行为始终保持一致性和目的性，有效避免了偏离航向。
透明化决策过程：思考轨迹就像Agent的"工作日志"，让开发者能够清晰地看到Agent的决策逻辑。当Agent出错时，我们可以精准地定位是推理错误还是工具返回结果的问题，从而进行针对性的优化。
强大的错误恢复与适应性：当观察（工具返回结果）与预期不符时，ReAct模式的Agent可以在下一个"思考"步骤中分析这个意外，并动态调整策略。

用ReAct模式解决上述场景 ：

如用户提问："阿里巴巴和腾讯这两家公司，哪一家最近一个季度的营收增长率更高？"

拆分为三个步骤，前两个步骤分别获取某一家公司的盈利数据，最后一个步骤来进行分析思考：

Thought: 要比较营收增长率，我需要两家公司最近一个季度的营收数据，以及去年同期的数据来计算增长率。我先搜索阿里巴巴的财务报告。
1. Act : search("阿里巴巴 2024年第一季度营收")
2. Observation: [返回了新闻，包含阿里巴巴Q1营收为2000亿元，以及去年同期为1800亿元]
Thought: 很好，我拿到了阿里巴巴的数据。增长率 = (2000 - 1800) / 1800 ≈ 11.1%。现在我需要腾讯的数据。
1. Act : search("腾讯 2024年第一季度营收")
2. Observation: [返回了腾讯的财报摘要，显示Q1营收为1500亿元，去年同期为1400亿元]
3. Thought: 腾讯的增长率 = (1500 - 1400) / 1400 ≈ 7.1%。比较两者，阿里巴巴的增长率11.1%高于腾讯的7.1%。现在我可以给出最终答案了。
Final Answer: 根据最近一个季度的数据，阿里巴巴的营收增长率（约11.1%）高于腾讯的营收增长率（约7.1%）。

参考资料

1\]. 视频-Langchain4j + ReAct从零打造Manus核心架构实战：https://www.bilibili.com/video/BV1Xfauz1E1b ## 资料获取 大家点赞、收藏、关注、评论啦\~ 精彩专栏推荐订阅：在下方专栏👇🏻 * [长路-文章目录汇总（算法、后端Java、前端、运维技术导航）](https://blog.csdn.net/cl939974883/category_11568291.html?spm=1001.2014.3001.5482)：博主所有博客导航索引汇总 * [开源项目Studio-Vue---校园工作室管理系统(含前后台，SpringBoot+Vue)](https://changlu.blog.csdn.net/article/details/125295334)：博主个人独立项目，包含详细部署上线视频，已开源 * [学习与生活-专栏](https://blog.csdn.net/cl939974883/category_10700595.html)：可以了解博主的学习历程 * [算法专栏](https://blog.csdn.net/cl939974883/category_11403550.html?spm=1001.2014.3001.5482)：算法收录 更多博客与资料可查看👇🏻获取联系方式👇🏻，🍅文末获取开发资源及更多资源博客获取🍅