如果你观察过 AI 编程助手排查 Bug 的过程，应该见过这样的模式：它先分析问题，修改代码，运行测试，读取报错结果，再根据新的信息决定下一步怎么改。

这类“边推理、边行动、再根据结果继续推理”的行为，本质上就是 ReAct（Reasoning and Acting）模式。

如今，ReAct 已经成为生产级 Agent 系统中非常常见的一种设计模式。它的优点是结构简单、容易实现，而且能力往往比看起来更强；但也正因为它依赖持续循环调用模型和工具，当请求量增长、任务链条变长之后，延迟和成本也会迅速上升。

本文将系统介绍 ReAct Agent 的基本机制、它与其他 Agent 模式的区别、上下文与记忆如何管理，以及在生产环境中真正运行这类 Agent 时需要关注的问题。

什么是 ReAct Agent？

ReAct Agent 是一种通过“推理 + 行动”循环完成任务的 AI 系统。

它不会只调用一次大模型，然后直接给出最终答案，而是会不断重复类似下面的过程：

1. 判断当前任务还缺少什么信息；
2. 选择下一步行动，例如调用工具、执行搜索、查询记录；
3. 获取工具执行结果；
4. 根据新结果重新推理；
5. 决定继续行动，还是生成最终答案。

这正是 ReAct 这个名字所表达的含义：模型根据当前信息规划下一步，执行行动，从真实环境中获得反馈，再利用这些反馈继续调整后续决策。

单独依赖模型内部推理时，大模型只能基于自己当前上下文中的信息进行判断，并不会真正接触外部世界。ReAct 则通过工具调用，把推理过程与外部反馈连接起来。

这有助于缓解单纯 Chain-of-Thought（CoT）推理可能出现的幻觉和错误累积问题。在原始 ReAct 研究中，ReAct 在 ALFWorld 基准上的成功率，相比模仿学习和强化学习方法取得了 34 个百分点的绝对提升。

在 LangChain、LangGraph 等生产框架里，ReAct 与其说是一种复杂的研究算法，不如说更像一个 while 循环：

只要模型还没有生成最终答案，也没有触发终止条件，就继续执行“推理 → 调用工具 → 获取结果 → 再推理”。

每次循环中，模型决定需要什么工具，应用负责真正执行工具，再把结果返回给模型。这个过程会一直持续，直到 Agent 认为信息已经足够，或者达到预设的最大执行次数。

ReAct 的推理—行动循环是如何工作的？

理解 ReAct 最直观的方式，是看它最经典的一种 Prompt 结构。

LangChain 早期的 create_react_agent 会要求模型按照类似下面的格式工作：

Question: the input question to answer
Thought: you should always think about what to do
Action: the action to take, should be one of [{tool_names}]
Action Input: the input to the action
Observation: the result of the action
... (this Thought/Action/Action Input/Observation can repeat N times)
Thought: I now know the final answer
Final Answer: the final answer to the original input question

整个循环可以拆成四个阶段。

1. ### Thought：判断下一步需要做什么

模型根据当前问题、之前的工具调用结果以及已经获得的信息，更新当前计划，并决定下一步应该采取什么行动。

1. ### Action：选择并调用工具

模型从允许使用的工具集合中选择一个工具，并生成对应的调用参数。

随后，控制权交回应用程序。

1. ### Observation：读取工具执行结果

应用真正执行工具，例如：

• 搜索网页；
• 查询数据库；
• 调用 API；
• 读取文件；
• 运行代码；
• 查询业务系统。

得到结果后，应用将结果重新加入模型上下文，作为新的 Observation。

1. ### Repeat or Finish：继续循环或结束

模型读取新的 Observation，然后重新判断：

是继续执行下一轮 Thought → Action → Observation，还是已经拥有足够的信息，可以生成最终答案。

这里有一个很重要的职责边界：

模型负责生成决策和工具调用意图，应用程序负责真正执行工具以及控制循环。

因此，每一轮通常只有几种可能结果：

• 再调用一个工具；
• 输出最终结构化结果；
• 工具执行报错；
• 达到最大轮数并停止。

生产框架一般都会设置硬性终止条件，避免 Agent 因为错误规划陷入无限循环。例如 LangGraph 就支持配置 recursion limit，在循环超过限制时主动终止执行。

ReAct 与其他 Agent 模式有什么区别？

ReAct 并不是构建 Agent 的唯一方式。

不同 Agent 架构的核心差异，通常不在于“是否使用工具”，而在于两个问题：

什么时候规划？规划多少次？

ReAct 的典型特点是：每执行一步，就重新调用一次 LLM 进行下一步规划。

这种机制很灵活，但也存在两个明显缺点：

• 每次工具调用通常都伴随着一次 LLM 调用；
• 每轮只规划当前的一个子问题，很少提前形成完整计划。

因此，一些其他 Agent 模式主要就是围绕这两个问题进行优化。

Plan-and-Execute：先完整规划，再逐步执行

Plan-and-Execute 会先生成一份相对完整的执行计划，然后再逐步完成各个步骤。

这种设计可以减少反复进行规划的次数。

其中一个代表性变体是 ReWOO（Reasoning WithOut Observation）。它将推理过程和 Observation 分离，在某些任务中能够显著提高 Token 使用效率。

代价是，面对简单任务时，ReAct 反而可能更高效。

因为 ReAct 可以直接开始行动，不需要先付出一次完整规划的模型调用成本。

Reflexion：在 ReAct 基础上增加自我反思

Reflexion 可以看成是 ReAct 的扩展。

当一次执行失败后，模型不会只是简单重试，而是先生成一段自然语言形式的反思：

• 哪里做错了；
• 为什么失败；
• 下一次应该怎样调整。

然后将这段反思加入上下文，再重新尝试。

这种方法本质上是用更多计算成本换取更高的输出质量，因此更适合质量敏感型任务，而不是对响应延迟非常敏感的在线业务。

Multi-Agent：让多个专业 Agent 分工

Multi-Agent Orchestration 会把一个复杂任务拆给多个专业 Agent。

典型结构可能是：

• 一个主 Agent 负责总体规划；
• 多个子 Agent 分别处理搜索、分析、编码、验证等任务；
• 主 Agent 最后整合结果。

这类架构非常适合复杂研究和多领域协同任务，但 Token 消耗通常也明显高于单 Agent 流程。

实际工程中，一个很重要的原则仍然是：

优先采用能够解决问题的最简单架构，只有当任务价值足以覆盖复杂度和成本时，再升级到更复杂的 Agent 模式。

这也是 ReAct 至今仍然非常常见的原因之一：它足够简单，同时又能覆盖相当广泛的任务。

ReAct Agent 的上下文存在哪里？

ReAct 能够连续执行多个步骤，有一个基本前提：

Agent 必须知道自己之前已经做过什么。

而这部分“记忆”实际上并不只存在一个地方。生产系统中通常可以分成三个层级。

第一层：Prompt 内的工作记忆

最直接的一层，就是当前 Prompt 或消息历史本身。

随着 Agent 不断执行，里面会逐渐积累：

• 用户原始问题；
• 之前的对话；
• 模型的中间输出；
• 工具调用；
• Observation；
• 当前执行状态。

应用会在每一轮调用模型时，把这些上下文重新发送给模型。

它的优点是访问速度快、实现简单。

缺点同样明显：

只要当前执行循环结束，这部分状态通常也就随之消失。

而且随着执行轮数增加，Prompt 会不断变长。

第二层：Thread 级持久化

第二层是会话或 Thread 级别的持久化状态。

它允许一个对话即使跨越多次运行、暂停甚至应用重启，也能够继续恢复。

以 LangGraph 为例，可以通过 checkpointer 在每一步执行结束后保存 Agent 状态快照，并按照 Thread ID 进行组织。

之后再次传入相同的 Thread ID，就可以从之前的位置恢复执行。

这种机制还可以支持：

• Human-in-the-loop；
• 长任务暂停和恢复；
• 故障恢复；
• 多轮长期对话。

第三层：跨会话长期记忆

更长期的一层，是 Cross-thread Long-term Memory。

它不依赖某一个具体会话，而是让 Agent 能够跨不同 Thread 保留信息，例如：

• 用户偏好；
• 过去做过的重要决策；
• 已经学习到的事实；
• 历史交互中值得长期保存的信息。

这类信息通常被存储在一个持久化数据层中，并通过语义相似度进行检索。

例如，当一个新会话开始时，Agent 可以根据当前问题检索过去相关的用户信息，然后再将这些内容注入当前上下文。

上下文并不是越长越好

如果完全不管理第一层 Prompt 上下文，它会随着 ReAct 循环不断增长，最终触及模型或框架的限制。

因此，Agent 框架通常还会提供：

• Context Trimming；
• Summarization；
• Retrieval。

这些技术都在解决同一个问题：如何避免把所有历史信息一直留在 Prompt 中。

但它们也存在取舍。

Trimming 会直接丢弃部分信息；Summarization 虽然能压缩内容，却可能遗漏后来才发现非常关键的细节。

因此，生产级 Agent 的上下文管理并不是简单地“把上下文窗口做大”，而是需要决定：

什么信息应该一直放在当前上下文里，什么信息应该长期存储，需要时再快速取回。

ReAct Agent 适合哪些实际场景？

如今，很多 Agent 产品实际上都采用了与 ReAct 非常接近的执行模式。

客户服务 Agent

这是目前最典型的 Agent 应用之一。

一个客户服务 Agent 可能需要：

• 查询用户账户信息；
• 检查订单状态；
• 查询物流；
• 阅读企业知识库；
• 判断问题能否自动处理；
• 判断什么时候应该转人工。

其中既包含工具调用，也包含根据工具结果不断调整决策的过程，非常符合 ReAct 模式。

Coding Agent

编程 Agent 同样是非常典型的 ReAct 应用。

例如：

1. 读取 Stack Trace；
2. 查看相关代码；
3. 修改文件；
4. 执行测试；
5. 读取新的失败结果；
6. 再次调整代码。

只要一个 Coding Agent 会根据执行反馈不断修改下一步行动，它实际上就在运行一种 ReAct 风格的循环。

Research Agent

研究型 Agent 通常也采用类似结构：

1. 分析问题；
2. 生成搜索 Query；
3. 执行搜索；
4. 阅读结果；
5. 判断信息是否足够；
6. 继续搜索或者生成结论。

这种“搜索—阅读—再规划”的模式，本质上同样属于 ReAct。

Agent 应用仍处在快速发展阶段。Gartner 曾预测，到 2026 年底，约 40% 的企业级应用将包含某种任务型 AI Agent，而 2025 年这一比例还不到 5%。

其中相当一部分系统都会采用某种形式的“推理 + 工具调用 + 反馈循环”。

为什么 ReAct 在生产环境中容易越来越慢、越来越贵？

ReAct 最大的工程问题之一，就来自它自己的循环结构。

假设 Agent 执行了多轮任务。

每一轮模型调用通常都需要重新发送此前积累的上下文，包括：

• 原始用户问题；
• 之前的推理和输出；
• 所有工具调用；
• 所有 Observation；
• 工具定义；
• 当前状态。

因此，每多执行一步，下一次 LLM 请求的输入往往都会更长。

单次请求的输入长度可能是线性增长的，但从整个任务累计 Token 成本来看，增长速度可能接近二次关系。

也就是说，一个执行 10 步的任务，并不只是一个执行 1 步任务的 10 倍成本，实际 Token 消耗可能远高于此。

而且，在实际 Agent Session 里，占据上下文最多的往往并不是用户输入。

更常见的是：

工具返回结果和工具定义。

因为模型需要在每一轮看到这些信息，才能理解自己目前拥有哪些工具以及之前发生了什么。

这也是为什么相比单纯扩大 Context Window，Prompt Hygiene——也就是决定哪些信息应该保留、裁剪、摘要或者按需检索——往往更加重要。

上下文过多还可能降低 Agent 质量

上下文增长带来的问题并不只有成本。

过长、未经管理的上下文还可能让模型本身表现变差。

实践中常见的几类问题包括：

Context Poisoning

某一次模型幻觉或者错误信息进入上下文后，在后续步骤中不断被重新引用。

错误因此被持续放大。

Context Distraction

上下文过长后，模型开始过度关注自己此前生成的大量历史内容，而不是根据新信息重新制定更好的计划。

Context Confusion

上下文中存在大量与当前任务无关的信息，模型错误使用了这些内容，最终降低输出质量。

Context Clash

新获取的信息与 Prompt 中此前保存的信息发生冲突，而模型没有正确判断哪一份信息更新、更可靠。

随着 ReAct 循环持续执行，这些风险都会逐渐累积。

因此，在实际系统中，合理的上下文裁剪和按需 Retrieval，往往比一味增加 Context Window 更重要。

延迟问题同样如此。

一个 Agent 每完成一次任务可能需要调用 LLM 多次。随着工具数量和执行步骤增加，整体响应时间很容易从不到一秒上升到十几秒甚至几十秒。

因此，大多数 ReAct 性能优化最终都围绕同一个目标：

尽量减少必须长期留在上下文窗口中的内容，并保证真正需要的信息能够被快速取回。

为 ReAct Agent 构建实时 Context Layer

一旦开始使用上下文裁剪、分层记忆和缓存，Agent 底层的数据层就会变得越来越重要。

这也是 Redis Iris 所针对的场景。

Redis Iris 是面向 AI Agent 的实时 Context Engine，目标是将 Agent 所需要的多种上下文能力整合到一个数据层中，而不是分别运行：

• Vector Database；
• Cache；
• Session Store。

对于 ReAct Agent 来说，一次任务可能会反复访问数据层，因此 Context Layer 的访问延迟会直接影响整个 Agent 的响应速度和运行成本。

Redis Iris 中的服务也可以对应到前面提到的不同记忆层级。

Redis Agent Memory：短期与长期记忆

Redis Agent Memory 提供双层记忆机制。

短期记忆主要保存当前活跃 Session，让 Agent 能够快速读取当前任务相关状态。

长期记忆则负责保存从历史交互中提取出的事实。这些内容可以以文本形式保存，同时生成 Vector Embedding，从而支持跨会话的语义检索。

如果使用 LangGraph，可以通过 langgraph-checkpoint-redis 将 Redis 接入其状态持久化体系。

其中：

• RedisSaver 可用于 Thread 级状态持久化；
• RedisStore 可用于跨 Thread 的长期记忆。

这样，Agent 的工作状态和长期知识就不必全部堆积在当前 Prompt 中。

Semantic Cache：减少重复的 LLM 调用

另一项重要能力是 Semantic Cache。

传统 Cache 通常要求 Key 完全一致才能命中，但用户针对同一件事情的提问往往存在不同表达。

Semantic Cache 会判断当前请求与过去请求在语义上是否足够接近。

如果之前已经生成过可以复用的结果，就可以直接返回缓存内容，而不必重新执行完整的 LLM 推理过程。

对于 ReAct 来说，这一点尤其重要，因为一次缓存命中可能直接避免整个 Agent Loop 中最昂贵的模型调用。

Redis LangCache 的测试结果显示，在相关场景下，LLM 推理成本最高可以降低约 73%。

RedisVL 则是 Redis 面向 AI 应用提供的 Python Client，可以从代码中使用：

• Vector Search；
• Hybrid Search；
• Semantic Routing；
• LLM Memory。

这些能力本质上都在解决一个共同问题：如何让 Agent 更快地找到真正需要的上下文，而不是不断把所有历史信息重新发送给模型。

ReAct 的性能最终取决于上下文管理

ReAct 的优势非常明确。

它结构简单，可以根据真实世界反馈不断调整行动，因此非常适合：

• 客户服务 Agent；
• Coding Agent；
• Research Agent；
• 各种需要连续工具调用的自动化系统。

但它的缺点也来自同样的设计。

随着循环轮数增加，Agent 会不断重新发送越来越长的历史上下文，从而导致：

• Token 成本增加；
• LLM 调用次数增加；
• 延迟不断叠加；
• 上下文污染和冲突风险上升。

因此，当 ReAct Agent 真正进入生产环境后，决定其性能和成本的往往已经不只是模型本身，而是整个 Context Layer 的设计。

一个更合理的方向通常是：

控制 Working Memory 的规模，将长期信息持久化到 Prompt 之外，并对已经付过推理成本的结果进行缓存。

Redis Iris 的设计目标，就是将这些能力整合成统一的实时 Context Layer，让 Agent 不必分别维护多个彼此独立的数据系统。

对于准备把 ReAct Agent 从 Demo 推向生产环境的团队来说，真正值得重点设计的，已经不只是“如何让模型调用工具”，而是如何让每一轮推理都能以尽可能低的成本、尽可能快地拿到真正需要的上下文。