ReAct：推理与行动的循环

在大语言模型的发展过程中，研究者发现两种极端策略都存在明显的局限性。纯推理策略（如 Chain-of-Thought）让模型在内部进行多步思考，但不与外部环境交互。这种方式在数学推理、逻辑推导等封闭任务上表现优异，但一旦涉及需要外部知识的开放任务——比如回答「2024年诺贝尔奖得主是谁」——模型只能依赖训练数据中的过期信息，无法获取最新事实。

另一方面，纯行动策略（如早期的 Toolformer）让模型直接调用工具，但缺少中间推理步骤。模型看到问题后直接决定调用哪个工具、传入什么参数，这就像让一个人不假思索地行动——面对复杂问题时容易做出错误决策。比如用户问「北京今天气温比上海高吗」，纯行动模型可能同时调用两个天气 API，但如果其中一个 API 返回格式异常，模型因为没有推理过程就无法灵活调整策略。

ReAct（Reasoning + Acting）的核心洞察是：推理和行动不是对立的，而是互补的。推理帮助模型制定策略、理解工具返回的结果、纠正执行中的错误；行动则为推理提供真实世界的事实依据，避免模型「闭门造车」。两者的交替循环构成了一个强大的认知框架——就像人类在解决问题时，也是边想边做、根据结果调整思路的。

# 纯推理（CoT）的局限：无法获取外部信息
prompt = """
问：埃菲尔铁塔有多高？
答：让我一步步思考。
埃菲尔铁塔是巴黎的地标建筑...
（模型只能基于训练数据回答，可能不准确或过时）
"""

# 纯行动（Toolformer）的局限：缺少策略思考
prompt = """
问：比较北京和上海今天的天气
[调用 weather_api("北京")]
[调用 weather_api("上海")]
（如果API返回异常，模型没有推理能力来处理）

# ReAct 范式：推理与行动交替
react_trace = """
Thought: 用户想知道北京和上海今天的天气差异，
        我需要分别查询两个城市的天气信息。
Action: weather_api
Action Input: {"city": "北京"}
Observation: {"temp": 22, "condition": "晴"}
Thought: 已获取北京天气，现在查询上海。
Action: weather_api
Action Input: {"city": "上海"}
Observation: {"temp": 25, "condition": "多云"}
Thought: 北京22度晴天，上海25度多云，
        上海比北京高3度。可以给出答案了。
Answer: 上海今天25度多云，北京22度晴天，上海比北京高3度。
"""

ReAct 范式由 Yao 等人在 2022 年的论文「ReAct: Synergizing Reasoning and Acting in Language Models」中正式提出。论文的核心贡献在于揭示了一个关键现象：推理轨迹和行动轨迹之间存在相互增强的协同效应。

论文通过在多个基准任务上的实验证明了这一假设。在 HotpotQA（多跳问答）任务上，ReAct 比纯推理（CoT）准确率高出 4.7 个百分点，比纯行动（Act-only）高出 10.6 个百分点。更重要的是，ReAct 在遇到错误时表现出更强的自我纠正能力——当工具返回意外结果时，模型能通过推理步骤识别异常并调整策略，而不是盲目继续。

论文提出了一个统一的提示格式，将 Thought、Action、Observation 三种信号交织在同一个序列中。这种设计的精妙之处在于：它不需要修改模型架构，只需要通过精心设计的 in-context learning 示例，就能让预训练的语言模型学会这种交替模式。论文还发现，推理轨迹对于「决策制定」（决定下一步调用什么工具）和「结果解释」（理解工具返回的内容）至关重要，而行动轨迹则为推理提供了无法从模型参数中获取的外部事实。

值得注意的是，ReAct 不仅适用于问答任务，论文还展示了它在交互决策任务（如 ALFWorld 环境中的导航）上的优异表现，证明了这一范式的通用性。

# ReAct 论文中的提示模板结构
REACT_PROMPT = """
Answer the following questions as best you can.
You have access to the following tools:

{tools}

Use the following format:

Question: the input question you must 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

Begin!

Question: {input}
Thought: {agent_scratchpad}
"""

# 论文中的 Few-shot 示例（简化版）
FEW_SHOT_EXAMPLE = """
Question: What profession does Nicholas Ray and Elia Kazan have in common?
Thought: I need to search Nicholas Ray and Elia Kazan, find their
        professions, then find the common one.
Action: Search
Action Input: "Nicholas Ray"
Observation: Nicholas Ray (born Raymond Nicholas Kienzle Jr., 1911-1979)
             was an American film director, screenwriter, and actor.
Thought: Nicholas Ray is a film director. Now I need to search
        Elia Kazan.
Action: Search
Action Input: "Elia Kazan"
Observation: Elia Kazan was a Greek-American director, producer,
             screenwriter, and actor.
Thought: Both are film directors. I can answer now.
Final Answer: Film director.
"""

ReAct 的核心运行机制是 Thought-Action-Observation（思考-行动-观察）循环，这是一个不断迭代直到找到答案的过程。理解这个循环的关键在于把握每个环节的职责和它们之间的信息流动。

Thought（思考）是循环的起点和决策中枢。在每个 Thought 步骤中，模型需要完成三件事：第一，分析当前状态——我已经知道了什么？还缺什么信息？第二，决定下一步行动——应该调用哪个工具？传入什么参数？第三，判断是否可以结束——我已经掌握了足够的信息来回答原始问题吗？这三个子任务构成了 Thought 的完整思维链。

Action（行动）是将决策转化为实际操作。模型从可用的工具集中选择一个，并构造合适的输入参数。这个步骤看似简单，但实践中经常出现问题：参数格式错误、工具选择错误、或者在不该调用工具的时候调用了工具。一个好的 ReAct 实现需要在提示词中清晰地描述每个工具的用途、输入格式和返回格式。

Observation（观察）是工具执行后返回的结果。这个步骤通常被低估，但实际上Observation 的质量直接影响下一轮 Thought 的效果。如果 Observation 信息量不足（比如搜索引擎只返回了标题没有摘要），模型在下一轮 Thought 中可能做出错误判断。因此，工具的设计需要确保返回的信息是「对模型有用的」——简洁、结构化、包含关键信息。

循环的终止条件是模型在 Thought 中判断「I now know the final answer」，然后输出 Final Answer。但循环也可能因为达到最大步数限制而强制终止，这时需要设计优雅降级策略。

# Thought-Action-Observation 循环的伪代码实现
class ReActLoop:
    def __init__(self, llm, tools, max_iterations=10):
        self.llm = llm
        self.tools = tools
        self.max_iterations = max_iterations
    
    def run(self, question: str) -> str:
        scratchpad = ""
        for i in range(self.max_iterations):
            # Thought: 模型决定下一步
            response = self.llm.generate(
                prompt=question, scratchpad=scratchpad
            )
            thought, action, action_input = response.parse()
            
            if response.is_final_answer:
                return response.final_answer
            
            # Action: 执行工具调用
            observation = self.tools.execute(action, action_input)
            
            # 更新 scratchpad，进入下一轮
            scratchpad += f"\nThought: {thought}\n"
            scratchpad += f"Action: {action}\n"
            scratchpad += f"Action Input: {action_input}\n"
            scratchpad += f"Observation: {observation}\n"
        
        return "达到最大步数，无法完成"

# 一个完整的 TAO 循环示例（追踪天气比较）
# Iteration 1
thought_1 = "我需要查询北京和上海的天气来比较"
action_1 = "weather_query"
input_1 = '{"city": "北京", "field": "temperature"}'
obs_1 = '{"city": "北京", "temp": 22, "unit": "celsius"}'

# Iteration 2
thought_2 = "北京是22度，还需要查上海的温度"
action_2 = "weather_query"
input_2 = '{"city": "上海", "field": "temperature"}'
obs_2 = '{"city": "上海", "temp": 25, "unit": "celsius"}'

# Iteration 3
thought_3 = "北京22度，上海25度，上海更高"
final_answer = "上海比北京高3度（25°C vs 22°C）"

print(f"共执行 {3} 轮 TAO 循环得到答案")

理解 ReAct 最好的方式是将它与相关的推理范式进行对比。Chain-of-Thought（CoT）、Tree-of-Thoughts（ToT）和 ReAct 代表了三种不同的增强 LLM 推理能力的思路，它们各有适用场景。

CoT（思维链）是最早的推理增强方法，通过在提示中要求模型「一步步思考」，引导模型生成中间推理步骤。CoT 的优势是简单——不需要任何外部工具或环境交互，只需要修改提示词。但 CoT 的根本局限是「封闭性」：所有的推理都在模型内部完成，无法获取训练数据之外的信息。如果问题需要实时数据、API 调用或环境交互，CoT 就无能为力。

ToT（思维树）是对 CoT 的扩展，它不再线性地推进推理，而是维护一棵推理树——在每一步生成多个可能的推理分支，通过评估函数选择最优路径。ToT 适合需要搜索和回溯的复杂规划问题，比如下棋、写作、代码生成。但 ToT 的 token 消耗是 CoT 的数倍，而且同样缺乏与环境交互的能力。

ReAct 与两者的关系可以用一个公式概括：ReAct = CoT 的推理能力 + 环境交互能力。与 CoT 相比，ReAct 多了行动和观察环节，使推理可以基于真实世界的事实。与 ToT 相比，ReAct 的搜索空间更受约束（每次只有一个 Action 分支），但获得的 Observation 是真实可靠的反馈，而不是模型的自我评估。在实际应用中，这三种方法不是互斥的——可以在 ReAct 的 Thought 步骤中使用 CoT 风格的详细推理，也可以在 ToT 的每个节点中使用 ReAct 与环境交互。

# CoT vs ReAct 的 prompt 对比
# CoT prompt - 只思考不行动
COT_PROMPT = """
Question: 如果一家公司年收入增长20%，成本增长15%，
        利润率会如何变化？
Let's think step by step.
（模型在内部推理，不调用任何工具）
"""

# ReAct prompt - 边思考边行动
REACT_PROMPT = """
Question: Apple 公司 2024 年 Q3 的营收是多少？
Thought: 我需要查询 Apple 最新的财报数据。
Action: search
Action Input: "Apple Q3 2024 revenue"
（模型先思考，然后调用搜索工具获取真实数据）
"""

# ToT vs ReAct 的搜索策略对比
# ToT：广度优先探索多个推理路径
def tot_search(problem, depth=3, breadth=5):
    """Tree of Thoughts - 维护一棵推理树"""
    tree = {problem: []}  # 根节点
    for level in range(depth):
        for node in get_current_leaves(tree):
            # 每个节点生成多个候选
            candidates = generate_thoughts(node, breadth)
            # 评估并选择最优
            scored = [(c, evaluate(c)) for c in candidates]
            tree[node] = sorted(scored, key=lambda x: -x[1])[:2]
    return extract_best_path(tree)

# ReAct：线性但带真实反馈
def react_search(problem, max_steps=6):
    """ReAct - 线性推理但每步有真实工具反馈"""
    scratchpad = ""
    for step in range(max_steps):
        thought, action = generate_next(problem, scratchpad)
        if is_answer(thought):
            return extract_answer(thought)
        observation = execute_tool(action)  # 真实反馈
        scratchpad += f"\n{thought}\n{action}\n{observation}"

ReAct 的强大之处在于它可以与各种外部工具集成。工具是 ReAct Agent 与世界交互的「手脚」，没有工具，再好的推理也只是空中楼阁。本节探讨三种最常用的工具类型及其集成方式。

搜索工具是最基础也是最常用的工具。它让 Agent 能够获取互联网上的实时信息，包括新闻、文档、API 响应等。集成搜索工具时，关键设计点在于：搜索结果的结构化程度（是返回原始 HTML 还是提取后的文本）、搜索范围的限制（是否需要 domain-specific 搜索）、以及搜索结果的排序（如何让最重要的信息排在前面）。在实际应用中，往往需要组合多种搜索策略：通用搜索引擎用于广泛查询，专业 API（如 Wikipedia API、学术搜索 API）用于精确查询。

代码执行工具让 Agent 能够运行 Python、JavaScript 等代码。这对于数学计算、数据处理、格式转换等任务非常有用。集成代码执行工具的核心挑战是安全性——必须确保模型生成的代码在沙箱环境中运行，不能访问文件系统或网络（除非明确授权）。此外，代码执行结果的返回格式也很重要：应该包含 stdout、stderr 和退出码，以便模型在下一轮 Thought 中判断执行是否成功。

计算器工具看似简单，但实际上是 ReAct Agent 中出错率最高的工具之一。LLM 本身不擅长精确数学运算（特别是在大数运算上），所以需要外部计算器。但集成时需要注意：浮点数精度问题、单位转换、以及数学表达式的解析。一个好的计算器工具应该支持基本运算、科学计算函数，并且返回格式清晰明了。

# 搜索工具集成（使用 DuckDuckGo）
from duckduckgo_search import DDGS
from typing import Dict

class SearchTool:
    name = "search"
    description = "搜索互联网获取实时信息"
    
    def execute(self, query: str) -> str:
        """执行搜索并返回格式化的结果"""
        with DDGS() as ddgs:
            results = list(ddgs.text(query, max_results=3))
        
        formatted = []
        for i, r in enumerate(results, 1):
            formatted.append(
                f"[{i}] {r['title']}\n"
                f"    {r['body']}\n"
                f"    URL: {r['href']}"
            )
        return "\n\n".join(formatted)

tool = SearchTool()
print(tool.execute("2024年诺贝尔物理学奖"))

# 代码执行工具（带沙箱安全控制）
import subprocess
import re

class CodeExecutionTool:
    name = "python_repl"
    description = "执行 Python 代码并返回结果"
    
    ALLOWED_MODULES = {"math", "json", "re", "datetime", "collections"}
    FORBIDDEN_PATTERNS = [
        r"import\s+os", r"import\s+sys", r"subprocess",
        r"open\(", r"__import__", r"eval\(", r"exec\("
    ]
    
    def _is_safe(self, code: str) -> bool:
        for pattern in self.FORBIDDEN_PATTERNS:
            if re.search(pattern, code):
                return False
        return True
    
    def execute(self, code: str) -> str:
        if not self._is_safe(code):
            return "Error: 代码包含不安全的操作"
        result = subprocess.run(
            ["python3", "-c", code],
            capture_output=True, text=True, timeout=10
        )
        return result.stdout or result.stderr

LangChain 是目前最流行的 LLM 应用开发框架之一，它内置了对 ReAct Agent 的一流支持。本节通过一个完整的示例，展示如何用 LangChain 构建一个 ReAct Agent，并深入理解其内部工作原理。

LangChain 的 ReAct Agent 实现基于三个核心组件：LLM（作为推理引擎）、Tools（作为行动能力）和 AgentExecutor（作为循环控制器）。LLM 负责生成 Thought 和决定 Action，Tools 负责执行具体的操作并返回 Observation，AgentExecutor 负责管理 Thought-Action-Observation 循环——它接收 LLM 的输出，解析出 Action 部分，调用对应的工具，将结果追加到对话历史中，然后再次调用 LLM。

构建一个实用的 ReAct Agent 需要关注几个关键设计决策。首先是工具选择：不是工具越多越好，过多的工具会增加模型的选择困难，导致选错工具的概率上升。建议从 3-5 个核心工具开始，根据实际需求逐步扩展。其次是提示词模板：LangChain 提供了默认的 ReAct 提示词模板，但针对特定领域任务，往往需要自定义模板以获得更好的效果。最后是错误处理：当工具执行失败或 LLM 输出了无法解析的格式时，Agent 应该如何应对？好的错误处理策略是将错误信息作为 Observation 返回给 LLM，让它自行决定是重试还是调整策略。

# 用 LangChain 构建 ReAct Agent 的完整示例
from langchain_openai import ChatOpenAI
from langchain.agents import create_react_agent, AgentExecutor
from langchain.tools import Tool
from langchain import hub

# 1. 定义工具
def search_wikipedia(query: str) -> str:
    """搜索 Wikipedia 获取百科知识"""
    import wikipedia
    try:
        return wikipedia.summary(query, sentences=3)
    except:
        return f"未找到关于 {query} 的信息"

def calculate(expression: str) -> str:
    """计算数学表达式"""
    return str(eval(expression, {"__builtins__": {}}, {}))

tools = [
    Tool(
        name="Wikipedia",
        func=search_wikipedia,
        description="搜索 Wikipedia 获取人物、事件、概念的百科信息"
    ),
    Tool(
        name="Calculator",
        func=calculate,
        description="计算数学表达式，如 2**10 或 3.14*5*5"
    ),
]

# 2. 创建 ReAct Agent
llm = ChatOpenAI(model="gpt-4", temperature=0)
prompt = hub.pull("hwchase17/react")
agent = create_react_agent(llm, tools, prompt)
executor = AgentExecutor(
    agent=agent, tools=tools, verbose=True,
    max_iterations=8, handle_parsing_errors=True
)

# 3. 运行
result = executor.invoke({
    "input": "如果一个圆的半径是5cm，它的面积是多少？"
})
print(result["output"])

# 自定义 ReAct 提示词模板
from langchain.prompts import PromptTemplate

CUSTOM_REACT_PROMPT = PromptTemplate.from_template("""
你是一个专业的研究助手，擅长使用工具来回答问题。
你可以使用以下工具：

{tools}

请按以下格式回答：

Question: 你需要回答的问题
Thought: 思考下一步应该做什么
Action: 工具名称，必须是 [{tool_names}] 之一
Action Input: 工具的输入
Observation: 工具执行的结果
... （可以重复 Thought/Action/Observation 多轮）
Thought: 我现在知道最终答案了
Final Answer: 对原始问题的最终回答

开始！

Question: {input}
Thought: {agent_scratchpad}
""")

# 使用自定义提示词创建 Agent
agent = create_react_agent(llm, tools, CUSTOM_REACT_PROMPT)
executor = AgentExecutor(
    agent=agent, tools=tools, verbose=True,
    max_iterations=6
)

尽管 ReAct 是一个强大的范式，但它并非没有局限性。理解这些局限性对于在生产环境中正确使用 ReAct 至关重要。

评估 ReAct Agent 的效果需要从多个维度进行。首先是准确性（Accuracy）：Agent 给出的最终答案是否正确？这通常通过在标准基准数据集（如 HotpotQA、FeverOUS）上运行来测量。其次是效率（Efficiency）：完成一个任务需要多少步？多少 token？多少时间？高效的 Agent 应该用最少的步骤达到正确的答案。第三是鲁棒性（Robustness）：当工具返回错误或意外结果时，Agent 是否能优雅地处理？最后是泛化能力（Generalization）：Agent 是否能处理训练示例中未曾见过的问题类型？

ReAct 的主要局限性包括：Token 消耗大——每一轮 TAO 循环都需要 LLM 重新生成完整的上下文，导致 token 使用量随步数线性增长；传播错误——一步错则步步错，如果某一步的 Observation 是错误的（比如搜索返回了不相关的结果），后续的所有 Thought 和 Action 都可能基于这个错误信息做出错误决策；工具依赖——ReAct 的效果高度依赖于工具的质量，如果工具返回的信息不完整或不准确，再好的推理也无法得到正确答案；解析脆弱性——LLM 可能输出不符合预期格式的 Action，导致 Agent 无法正确解析和执行。

针对这些局限性，研究者提出了多种改进方案：Reflexion 框架让 Agent 在每次执行后进行自我反思，从错误中学习；Plan-and-Execute 策略先让 Agent 制定完整计划，再按计划逐步执行，减少了不必要的探索步骤。这些改进方案与 ReAct 的核心思想并不冲突，而是对其的补充和增强。

# ReAct Agent 的多维度评估
from dataclasses import dataclass
from typing import List

@dataclass
class ReactMetrics:
    accuracy: float           # 答案正确率
    avg_steps: float          # 平均步骤数
    avg_tokens: float         # 平均 token 消耗
    tool_error_rate: float    # 工具调用失败率
    parse_error_rate: float   # 解析失败率
    self_correction_rate: float  # 自我纠正率

def evaluate_agent(agent, test_cases: List[dict]) -> ReactMetrics:
    results = []
    for case in test_cases:
        trace = agent.run_with_trace(case["question"])
        results.append({
            "correct": trace.final_answer == case["answer"],
            "steps": len(trace.ta_iterations),
            "tokens": trace.total_tokens,
            "tool_errors": trace.tool_errors,
            "parse_errors": trace.parse_errors,
            "corrections": trace.self_corrections,
        })
    
    n = len(results)
    return ReactMetrics(
        accuracy=sum(r["correct"] for r in results) / n,
        avg_steps=sum(r["steps"] for r in results) / n,
        avg_tokens=sum(r["tokens"] for r in results) / n,
        tool_error_rate=sum(r["tool_errors"] for r in results) / n,
        parse_error_rate=sum(r["parse_errors"] for r in results) / n,
        self_correction_rate=sum(r["corrections"] for r in results) / n,
    )

# Reflexion 改进：自我反思式 ReAct
class ReflexionAgent:
    """在 ReAct 基础上增加自我反思机制"""
    def __init__(self, base_agent, reflection_model=None):
        self.base_agent = base_agent
        self.reflection_model = reflection_model or base_agent.llm
        self.reflections = []  # 历史反思记录
    
    def run(self, question: str) -> str:
        # 第一次尝试
        result = self.base_agent.run(question)
        
        if not result.success:
            # 反思：为什么失败了？
            reflection = self.reflection_model.generate(
                f"任务：{question}\n"
                f"执行轨迹：{result.trace}\n"
                f"结果：失败 - {result.error}\n"
                f"请分析失败原因并给出改进建议。"
            )
            self.reflections.append(reflection)
            
            # 第二次尝试（带上反思）
            result = self.base_agent.run(
                question, context=f"之前的教训：{reflection}"
            )
        return result

截至 2026 年中，ReAct 范式已经从研究论文中的概念演变为所有主流 AI Agent 框架的底层基础。Claude Code、Cursor、Codex、Antigravity 等工具的核心循环本质上都是 ReAct 思想的工程化实现。

2026 年的关键演进：

ReAct + 计算机使用（Computer Use）：Anthropic 在 Q1 2026 为 Claude Code 集成 Computer Use 功能后，ReAct 循环扩展到了图形界面操作领域。Agent 不再只是调用 API，而是能通过截屏推理（Thought）→ 鼠标点击/键盘输入（Action）→ 界面变化反馈（Observation）的循环来操作 GUI 应用程序。这极大地扩展了 ReAct 的适用范围——大量企业工作流发生在 GUI 而非 API 中，例如 ERP 系统操作、网页表单填写等。

ReAct + 子代理编排（Sub-Agent Orchestration）：Google Antigravity 2.0 展示了一种 ReAct 的层次化扩展——一个主 Agent 使用 ReAct 循环来决定何时启动专门的子代理。在这种架构中，ReAct 循环运行在元级别：主 Agent 的 Thought 是「需要启动一个 Android 子代理来构建这个功能」，Action 是「调用 Android Agent」，Observation 是子代理返回的构建结果。这种分层 ReAct 是 2026 年 Agent 架构的重要趋势。

ReAct + 记忆持久化：Claude Cowork 的 Dreaming 模式（Scheduled Tasks）和 Cursor 的 .cursorrules 持久化解决了 ReAct 的一个核心局限——每次从零开始。通过将历史经验、项目偏好、常见错误模式持久化到记忆中，Agent 在每次新的 ReAct 循环中可以继承历史经验，而不是重复相同的错误。这与 Reflexion 思想（第 8 章）一脉相承，但在 2026 年已经工程化为产品功能。

ReAct + 安全沙盒：随着 Agent 获得越来越多的系统访问权限，ReAct 循环中的 Action 步骤必须在安全沙盒中执行。Antigravity 2.0 的跨平台沙盒确保 Agent 的 shell 操作不会破坏宿主系统。这意味着 ReAct 的工程实现需要额外考虑安全隔离层——Action 的执行环境必须是受控的、可审计的、可回滚的。

ReAct 的未来：2026 年下半年，我们预计 ReAct 范式将进一步演进为持续感知型循环——Agent 不仅在被提问时执行 ReAct 循环，还会主动监控环境变化（如代码仓库更新、依赖安全漏洞通知），并在检测到异常时自主启动 ReAct 循环进行响应。这将使 Agent 从「被动响应」走向「主动运维」。

2026 年 ReAct 演进时间线：

2022.10  Yao et al. 发表 ReAct 论文（NeurIPS）
2023.Q1  LangChain ReAct Agent 实现
2023.Q3  LlamaIndex ReAct 查询引擎
2024.Q1  Claude Code 终端 Agent（ReAct 思想实现）
2024.Q3  OpenAI Function Calling + ReAct 模式
2025.Q2  Claude Code 自主工作流（ReAct 循环扩展）
2026.Q1  Claude Code Computer Use（ReAct + GUI）
2026.Q1  Claude Cowork Dreaming（ReAct + 记忆持久化）
2026.Q1  Cursor v3.0 Background Agents（ReAct 并行化）
2026.05  Google Antigravity 2.0（ReAct + 子代理编排）
2026.H2  预期：持续感知型循环（ReAct + 主动监控）

本轮更新追加了 ReAct 循环在 2026 年新型 Agent 架构中的演进分析，以及 MiMo 万亿参数模型对 ReAct 推理深度的影响。

Orchestkit 对 ReAct 的工程化封装：2026 年 6 月，开源项目 Orchestkit 在 GitHub 上获得了大量关注（184 星），它提供了一个面向 Claude Code 的 103 个技能、36 个 Agent 的完整开发工具包。Orchestkit 的核心创新在于：将 ReAct 循环封装为可组合的技能模块。每个技能都是一个独立的「Thought-Action-Observation」循环单元，多个技能可以组合成更复杂的工作流。这意味着 ReAct 不再是一个「论文中的范式」，而是一个可复用、可组合的工程原语。开发者不需要理解 ReAct 的底层原理，只需要像搭积木一样组合预定义的技能模块。

MiMo 1T 万亿参数模型对 ReAct 的影响：MiMo 1T 模型实现了 千 tokens/s 的推理速度，这对 ReAct 循环的执行效率有直接的提升。ReAct 循环的核心瓶颈在于：每个 Thought-Action-Observation 步骤都需要调用 LLM 进行一次推理。如果推理速度从传统的 50 tokens/s 提升到 1000 tokens/s，意味着一个需要 10 步 ReAct 循环的任务，执行时间从几十秒缩短到几秒。推理速度的提升，使得 ReAct 循环可以在实时交互场景中应用——这是之前不可能做到的。

ReAct 循环在 2026 年的三个演进方向：第一，从单次循环到并行循环——传统 ReAct 是串行的（完成一个 TAO 循环再进入下一个），新型 Agent 框架支持并行执行多个 ReAct 循环（如同时搜索多个信息源、同时执行多个工具调用）。Orchestkit 的 36 Agent 架构本质上就是并行 ReAct 的体现。第二，从显式推理到隐式推理——随着模型能力的提升，部分推理过程被内化到模型的预训练知识中，不再需要显式的 Thought 步骤。这降低了 Token 消耗，但牺牲了可解释性。第三，从通用 ReAct 到领域特化 ReAct——不同领域的 Agent 需要不同的 Thought-Action-Observation 模式。法律 Agent 的 Thought 需要关注法规引用和案例匹配，编程 Agent 的 Thought 需要关注代码逻辑和测试用例。领域特化的 ReAct 模板正在成为 Agent 框架的标配。

智能体理性落地对 ReAct 的验证：2026 年，行业从「Agent 概念炒作」转向 ROI 评估阶段。企业不再关心 Agent 是否「智能」，而是关心 Agent 是否带来了 可量化的业务价值。ReAct 循环的优势在于它的可观测性——每个 Thought、Action、Observation 都可以被记录和审计。这使得 ReAct 架构的 Agent 在「理性落地」评估中具有天然优势：你可以精确统计 Agent 在哪个步骤出错、哪个工具调用失败、哪个 Thought 导致了错误的决策。这种细粒度的可观测性是其他 Agent 架构（如端到端 LLM 调用）难以提供的。

本轮更新追加了 Apple Intelligence 三层架构对 ReAct 的分层启发，以及 Claude Code 9 天重构 Bun 百万行代码事件引发的 ReAct 安全治理讨论。

Apple Intelligence 对 ReAct 的分层启发：

Apple Intelligence 的三层架构（端侧 3B 模型 → PCC 私有云计算 → 第三方模型集成）本质上是一个分层 ReAct 循环。当用户发出请求时，系统执行 Thought（复杂度判断）→ Action（选择处理层级）→ Observation（处理结果）→ 新 Thought（是否需要回退到更高层级）。这一架构证明：ReAct 范式不仅在 Agent 层面适用，在系统架构层面同样适用。

具体来说，Apple Intelligence 的分层 ReAct 有三个关键特征：第一，Thought 的层级化——端侧模型的 Thought 负责快速判断请求复杂度，PCC 层的 Thought 负责深度推理，第三方模型的 Thought 负责特殊能力（如联网搜索）。不同层级的 Thought 使用不同规模的模型，在成本和质量之间取得平衡。第二，Action 的路由化——Action 不再是"调用某个工具"，而是"将请求路由到某个处理层级"。这是一种元级别的 Action，它不直接执行任务，而是决定由谁来执行任务。第三，Observation 的标准化——不同层级的处理结果需要统一的 Observation 格式，才能被上一层级的 ReAct 循环理解和使用。Apple 通过系统级的 API 抽象实现了这种标准化。

Claude Code 重构 Bun 事件对 ReAct 安全治理的启示：

2026 年 6 月，Claude Code 在 9 天内重构了 Bun 项目 100 万行代码，引发了业界对 AI 自主编程安全性的深度质疑。这一事件对 ReAct 范式提出了新的安全治理要求：

ReAct 循环中的 Action 步骤需要安全边界。 在 Claude Code 的 ReAct 循环中，Action 是"执行代码编辑"。当单次 Action 涉及的代码量达到 100 万行时，传统的 Observation（代码变更 diff）已经无法被人工有效审查。这意味着 ReAct 循环需要在 Action 步骤增加规模限制和变更影响评估——当 Action 的规模超过安全阈值时，需要触发额外的审批流程。

ReAct 循环的可观测性是双刃剑。 一方面，ReAct 的 Thought-Action-Observation 轨迹提供了完整的审计线索——你可以精确追踪 AI 在每一步做了什么决策、为什么做这个决策。另一方面，当 ReAct 循环的步数达到数千甚至数万时（如 100 万行代码重构），审计轨迹本身就变得不可审查。这是 ReAct 范式在大规模应用中的可观测性悖论——观察得越细，数据量越大，最终反而无法观察。

解决方案：分层 ReAct + 摘要级 Observation。 对于大规模任务，不要使用单一的 ReAct 循环，而是使用分层的 ReAct 架构。底层的 ReAct 循环处理具体的代码变更（每次不超过 5000 行），上层的 ReAct 循环接收底层循环的摘要级 Observation（如"模块 A 重构完成，变更 3000 行，测试通过率 99.8%，发现 2 个回归 bug"），然后决定下一步策略。这种摘要级 ReAct 在保持可观测性的同时，控制了审计数据量。

ReAct 在 2026 年下半年的三个新趋势：

第一，从单次循环到并行循环——新型 Agent 框架支持并行执行多个 ReAct 循环（如同时搜索多个信息源、同时执行多个工具调用）。Orchestkit 的 36 Agent 架构本质上就是并行 ReAct 的体现。并行 ReAct 可以大幅提升执行效率，但也增加了复杂度和调试难度。

第二，从显式推理到隐式推理——随着模型能力的提升，部分推理过程被内化到模型的预训练知识中，不再需要显式的 Thought 步骤。这降低了 Token 消耗，但牺牲了可解释性。在安全敏感的场景中，建议保持显式推理。

第三，从通用 ReAct 到领域特化 ReAct——不同领域的 Agent 需要不同的 Thought-Action-Observation 模式。法律 Agent 的 Thought 需要关注法规引用和案例匹配，编程 Agent 的 Thought 需要关注代码逻辑和测试用例，安全 Agent 的 Thought 需要关注漏洞模式和攻击向量。领域特化的 ReAct 模板正在成为 Agent 框架的标配。

AI Master 的最终判断：

ReAct 范式已经从 2022 年的研究论文成长为 2026 年的行业基础设施。Apple Intelligence 的分层架构、Claude Code 的安全事件、Orchestkit 的技能化封装——所有这些发展都在验证一个核心判断：ReAct 不是 Agent 的一种实现方式，而是 Agent 的本质。 任何智能系统，只要需要在不确定的环境中做决策并执行行动，就不可避免地遵循 ReAct 的逻辑。

对于开发者来说，理解 ReAct 不再是一个"加分项"，而是构建任何 AI 应用的必备基础。无论是调用一个 API、编写一个 Agent、还是设计一个系统级 AI 架构，ReAct 的思维模型都能帮助你理清思路、减少错误、提高可观测性。

本轮更新追加了 OpenAI IPO 进程对 ReAct Agent 商业模式的影响分析，以及 全球 AI 烧钱竞赛下 Agent 基础设施成本的可持续性讨论。

OpenAI IPO 对 ReAct Agent 的影响：

2026 年 6 月，OpenAI 正式向 SEC 递交 IPO 申请，标志着 AI Agent 基础设施从「开源实验」走向「商业化产品」。OpenAI 的 ChatGPT Agent Store 已经支持用户创建和发布基于 ReAct 循环的自定义 Agent，这意味 ReAct 范式首次获得了直接的商业变现路径。

从技术架构来看，ChatGPT Agent 本质上是一个 托管的 ReAct 循环：用户定义 Agent 的目标和可用工具（Thought 模板），平台负责执行 Action（调用 API、搜索网页、运行代码）并返回 Observation。平台方通过订阅费和使用量计费实现盈利，开发者通过 Agent 的市场分发获得分成。

这种商业模式的成立依赖于两个前提：第一，ReAct 循环的执行成本必须低于用户愿意支付的价格；第二，Agent 的输出质量必须足够可靠，用户才会持续使用。当前最大的挑战是第一个前提——一个多步 ReAct 循环的 Token 消耗可能是单步调用的 5-10 倍，在 OpenAI 的定价模型下，这意味着 Agent 的运行成本可能非常高。

全球 AI 烧钱竞赛下的 Agent 成本挑战：

据 2026 年 6 月的行业报告，头部 AI 公司的月度运营支出已超过 5 亿美元。这意味着每个 Agent 调用背后都有巨大的基础设施成本支撑。对于使用 ReAct 循环的 Agent 来说，成本挑战更为突出：

第一，推理步骤的 Token 开销——ReAct 循环中的每个 Thought 都是纯文本推理，不产生实际价值但消耗 Token。如果能在模型预训练阶段将这些推理能力内化（即让模型在内部完成推理，不需要显式的 Thought 步骤），可以大幅降低成本。

第二，工具调用的延迟成本——每个 Action 步骤涉及网络调用（搜索 API、数据库查询），延迟在 100-500ms 之间。对于需要 10 步以上 ReAct 循环的任务，总延迟可能超过 5 秒，严重影响用户体验。

第三，Observation 的存储成本——大规模 Agent 部署会产生海量的 Thought-Action-Observation 轨迹数据，这些数据的存储和检索成本不容忽视。

成本优化的三个方向：

1. 推理压缩——使用更小的模型做 Thought 推理（如用 3B 模型做路由决策，只在需要深度推理时才调用大模型）；2. 工具缓存——对重复的工具调用结果进行缓存，避免重复的网络请求和 Token 消耗；3. Observation 压缩——对工具返回的结果进行摘要和过滤，只保留对后续 Thought 有用的信息。

AI Master 的判断：

ReAct 范式的产业落地正在 2026 年迎来转折点。OpenAI IPO 意味着市场需要看到可持续的商业模式，而不仅仅是技术上的可能性。ReAct 循环的成本结构是目前最大的商业化障碍——如果一个 Agent 每次回答问题的成本是 0.1 美元，而用户愿意支付的价格是 0.01 美元，这个商业模式就无法成立。

解决这个问题的关键不在于降低 Token 价格（这是外部因素），而在于优化 ReAct 循环的效率——减少不必要的 Thought 步骤、缓存重复的工具调用、压缩 Observation 数据量。这些优化方向正是 2026 年下半年 Agent 框架研发的重点领域。

本节为第 8 章节的补充说明。

2026 年 ReAct 范式的核心判断： 从 Claude Code 的 Computer Use 到 Orchestkit 的 36 Agent 并行编排，ReAct 已经从「论文概念」成长为「行业基础设施」。Anthropic Claude Haiku 4.5 的发布进一步降低了 ReAct 循环的推理成本，使得多步 TAO 循环在经济上更加可行。

Anthropic 系列模型对 ReAct 的影响：

• Claude Sonnet 4.5（2025年9月发布）在编码和推理基准上刷新记录，使得 ReAct 循环中的 Thought 步骤质量显著提升
• Claude Haiku 4.5 提供了「前几个月的 SOTA 编码能力」但成本极低，非常适合作为 ReAct 循环中的路由模型（决定何时调用大模型、何时直接用小模型回答）
• Claude Opus 4.1 专注于复杂 Agent 任务，是 ReAct 循环中需要深度推理步骤的理想选择
• Anthropic Agent SDK 为构建基于 ReAct 的 Agent 提供了标准化的开发框架

ReAct 循环的成本优化新方案： 随着 Anthropic 模型家族从 Haiku 到 Opus 的价格梯度越来越清晰，开发者可以采用分层 ReAct 策略——用 Haiku 处理简单的 Thought 步骤（成本极低），用 Sonnet 处理中等复杂度的 Thought，只在需要极致推理能力时才调用 Opus。这种策略可以将 ReAct 循环的总成本降低 50-70%。

本轮更新追加了 端侧AI与4B认知模型对ReAct范式的冲击，以及 腾讯全栈智能体和微信Agent生态对ReAct工程实践的影响。

端侧AI与4B认知模型：ReAct 的运行环境正在迁移

2026年6月，仅4B参数的小型认知模型在端侧部署上展现出与GPT-5.4相媲美的性能，这一趋势对 ReAct 范式有直接影响。ReAct 循环传统上依赖云端大模型的强大推理能力，但当 4B 模型能够在端侧高效运行时，ReAct 的执行环境正在从云端向端侧迁移。这一迁移带来了三个关键变化：

第一，延迟革命。端侧 ReAct 循环消除了网络调用的 100-500ms 延迟，Thought-Action-Observation 的每一步都在本地完成。对于需要快速响应的 Agent 场景（如实时对话、交互式编程），端侧 ReAct 将延迟从秒级降低到毫秒级。

第二，隐私保护。端侧 ReAct 循环的 Thought 轨迹（包含用户的完整推理过程）不再离开设备，这解决了企业部署 ReAct Agent 时最大的隐私顾虑。Thought 轨迹包含了 Agent 的完整思考过程，在云端运行时，这些数据暴露给第三方是不可避免的。端侧部署彻底消除了这一风险。

第三，成本结构重构。端侧 ReAct 不再依赖按 Token 计费的云端 API，而是使用本地算力。这意味着 ReAct 循环的边际成本趋近于零——用户可以无限制地运行 ReAgent，而不必担心 Token 费用。对于高频 ReAct 场景（如每钟执行一次 TAO 循环的监控 Agent），端侧部署的成本优势是压倒性的。

腾讯全栈智能体：ReAct 在企业级场景的新范式

2026年6月，腾讯云发布全栈智能体架构，一个入口串起全栈智能体。这一架构对 ReAct 范式的影响在于：它将 ReAct 循环从「单个 Agent 的认知模式」升级为「全栈编排的协调模式」。

在腾讯全栈智能体架构中，ReAct 循环运行在多个层级：

第一层：用户入口层。用户在微信小程序、企业微信或腾讯云控制台发起请求。这一层的 ReAct 循环负责意图理解——Thought（用户想做什么）→ Action（路由到哪个智能体）→ Observation（路由结果）。

第二层：智能体编排层。入口层将请求分发给专业智能体（如客服 Agent、数据分析 Agent、代码生成 Agent）。这一层的 ReAct 循环负责任务分解——Thought（任务需要哪些子智能体）→ Action（启动子智能体并传递上下文）→ Observation（子智能体的执行结果）。

第三层：工具执行层。专业智能体调用具体工具（数据库查询、API 调用、文件操作）。这一层的 ReAct 循环是经典的 Thought-Action-Observation，但执行环境被腾讯的安全沙盒隔离。

这种分层 ReAct 架构是 2026 年企业级 Agent 部署的重要趋势——它解决了单 ReAct 循环无法处理复杂企业工作流的问题。

微信 Agent 生态：ReAct 的最大规模应用场景

微信 Agent 生态的推出意味着 ReAct 范式将在十亿级用户规模上运行。微信小程序 AI 接入让互联网「半壁江山」响应 Agent 化，这给 ReAct 范式提出了前所未有的工程挑战：

规模化 ReAct 循环的并发问题——当数亿微信用户同时与各自的 Agent 交互时，ReAct 循环的并发量可能达到每秒数百万次。传统的串行 ReAct 循环无法支撑这种规模，必须实现并行 ReAct——同一用户的多个 ReAct 循环可以并行执行（如同时查询多个数据源），不同用户的 ReAct 循环分布在不同的计算节点上。

ReAct 循环的标准化问题——微信 Agent 生态需要统一的 ReAct 循环接口，否则每个小程序开发者都需要自行实现 Thought-Action-Observation。腾讯的方案是提供ReAct SDK——封装了 TAO 循环的核心逻辑，开发者只需要定义 Thought 模板和注册 Action 工具，框架自动管理循环流程。

ReAct 循环的可观测性挑战——在十亿级用户的 Agent 生态中，每个 Agent 的 ReAct 循环都会产生日志。如何从海量日志中识别异常（如某个 Agent 的 ReAct 循环陷入了死循环）是一个巨大的工程挑战。行为基线 + 异常检测是解决方案的核心——为每种 Agent 类型建立正常的 ReAct 循环基线（平均步数、典型 Thought 模式、常见 Action 序列），当实际循环偏离基线时自动告警。

AI Master 的判断：

2026年下半年的 ReAct 范式正在经历从「个人开发者工具」到「企业级基础设施」的蜕变。端侧AI降低了 ReAct 的成本和延迟，腾讯全栈智能体扩展了 ReAct 的架构边界，微信 Agent 生态将 ReAct 推向了十亿级用户规模。ReAct 不再是论文中的概念——它是 2026 年 AI Agent 的事实标准。

2026 年 6 月，两个重要的技术进展对 ReAct 范式产生了深远影响——Apple 的 Private Cloud Compute（PCC）架构扩展到了 Google Cloud 和 NVIDIA GPU 平台，以及Anthropic 发布 Claude Fable 5 与 Mythos 5下一代模型。

Apple PCC 与 ReAct 的隐私保护

Apple 将 PCC 扩展到 Google Cloud 和 NVIDIA GPU 平台，意味着云端 ReAct 循环也可以获得设备级的隐私保障。在 PCC 架构下，用户的 Thought 内容（包含搜索查询、工具调用参数等敏感信息）可以在可验证的安全环境中执行，即使数据离开本地设备，也能保证：

• Thought 不被日志记录：PCC 环境中不保留 ReAct 循环的中间状态
• Action 参数加密传输：工具调用的参数在传输过程中不可被中间节点读取
• 可验证的隐私承诺：用户设备可以验证云端环境是否运行在 PCC 认证的安全飞地中

这对于企业级 ReAct Agent 尤为重要。在金融、医疗等敏感行业，Agent 的 Thought 中包含客户隐私数据、交易信息等，PCC 架构提供了端到端的隐私保护方案。

Claude Fable 5 对 ReAct 推理能力的提升

Claude Fable 5 在 SOTA 基准上的表现，特别是在多步推理和工具调用方面的提升，直接增强了 ReAct 循环的核心能力：

• 更长的 Thought 链：Fable 5 支持更复杂的 Thought 推理步骤，可以维持更长的推理链而不偏离主题
• 更精准的工具选择：在多工具场景下，Fable 5 的工具选择准确率显著提升，减少了错误调用
• 更低幻觉率：Observation 阶段的幻觉率降低，意味着 Agent 更不容易被错误的工具返回结果误导

定价策略的影响：Fable 5 定价减半的策略，使得 ReAct Agent 的运营成本大幅下降。对于一个需要执行 10-20 步 ReAct 循环的复杂任务，模型成本降低 50% 意味着端到端的 Agent 成本可以控制在更低范围内。

ReAct 范式在 2026 下半年的定位

AI Master 的判断：

ReAct 范式正在经历从「技术方案」到「行业标准」的蜕变。PCC 架构解决了企业采用的最大障碍（隐私合规），Claude Fable 5 的推理能力提升让 ReAct 更可靠，定价下降让大规模商用成为可能。2026 年下半年，ReAct 将从「能不能用」转向「怎么用得更好」。

2026 年 6 月，Anthropic 发布的 Claude Mythos 5 采用了分层发售策略，这一策略对 ReAct Agent 的构建成本和使用模式产生了直接影响。

分层发售策略的核心

Mythos 5 的分层发售意味着同一模型家族被划分为不同能力等级和定价档位，用户可以根据任务复杂度选择对应层级：

• 基础层（Lite）：适用于简单查询和分类任务，成本最低
• 标准层（Standard）：覆盖大部分日常 ReAct 循环，性价比最优
• 高级层（Pro）：支持复杂多步推理和长上下文，适合深度分析
• 旗舰层（Ultra）：极致推理能力，用于最关键的任务节点

对 ReAct Agent 架构的影响

分层发售为 ReAct Agent 的动态路由提供了新思路：

上图展示了基于分层模型的智能路由 ReAct Agent 架构。通过前置复杂度评估器，Agent 可以为不同任务选择最经济的模型层级，而不是「一刀切」使用最贵的模型。

成本优化效果： 研究表明，在典型的企业 Agent 工作负载中，80% 的请求可以用 Lite/Standard 层处理，只有 20% 需要 Pro/Ultra 层。这种分层策略可以将总体成本降低 40-60%。

动态路由的实现思路

ReAct 范式的下一步演进

分层模型 + 动态路由正在将 ReAct 从单一模型的固定循环推向多模型协作的弹性架构。未来的 ReAct Agent 可能不再是一个模型跑完所有 Thought-Action-Observation 步骤，而是：

1. 轻量路由器快速评估任务类型
2. 分派到对应层级模型执行 ReAct 循环
3. 结果聚合与交叉验证（用更高层级模型验证低层级输出）
4. 自适应升级（当低层级模型多次失败时自动升级到更高层级）

这种架构既保证了成本效益，又确保关键任务的推理质量。ReAct 范式正在从「一个模型搞定一切」进化为「让合适的模型做合适的事」。

from dataclasses import dataclass
from enum import Enum

class ModelTier(Enum):
    LITE = "claude-mythos-5-lite"
    STANDARD = "claude-mythos-5-standard"
    PRO = "claude-mythos-5-pro"
    ULTRA = "claude-mythos-5-ultra"

@dataclass
class TaskComplexity:
    max_steps: int
    tools_needed: list[str]
    context_length: int
    reasoning_depth: str  # "simple" | "moderate" | "complex"

def route_to_tier(task: TaskComplexity) -> ModelTier:
    """根据任务复杂度动态选择模型层级"""
    if task.reasoning_depth == "simple" and task.max_steps <= 2:
        return ModelTier.LITE
    elif task.max_steps <= 5 and len(task.tools_needed) <= 2:
        return ModelTier.STANDARD
    elif task.reasoning_depth == "complex" or len(task.tools_needed) > 3:
        return ModelTier.PRO
    else:
        return ModelTier.ULTRA

2026 年 6 月，ReAct 范式在 Agent 生态中的演进呈现出三个值得关注的新方向。

15.1 ReAct 自我优化的新方向

2026 年一个重要的研究方向是让 ReAct Agent 从历史执行经验中自动学习最优推理策略。这种思路正在从「人工设计 Prompt」向「数据驱动的策略优化」演进：

• 经验积累：Agent 在每次 ReAct 循环后记录完整的执行轨迹，包括推理路径、工具选择和最终结果
• 策略评估：对不同推理步骤的有效性进行量化评分，识别最优执行模式
• 策略优化：基于历史数据自动调整推理策略，逐步提升 Agent 的整体表现

15.2 ReAct 范式的端侧演进

随着 Agent 应用场景从服务器端向端侧扩展，ReAct 范式也在适应新的部署环境：

• 轻量化 ReAct：在手机、小程序等资源受限环境中，需要更精简的 Thought-Action 循环
• 分层推理：将复杂推理拆解为多个轻量级子循环，适配不同算力层级的执行环境
• 本地化工具调用：端侧 Agent 更依赖本地 API 和轻量工具，而非云端重型服务

15.3 ReAct 在物理世界中的新挑战

当 ReAct 从纯数字场景延伸到物理世界（如机器人控制、IoT 设备管理）时，面临新的挑战：

• 安全约束：物理世界中的行动具有不可逆性，Thought 阶段需要加入安全验证层
• 实时性要求：控制循环的延迟需要控制在毫秒级，传统的 ReAct 同步模式需要优化
• 多模态感知：物理世界的 Observation 需要融合传感器数据、视觉信息和环境状态

15.4 ReAct 范式的 2026 下半年展望

综合以上趋势，ReAct 范式在 2026 年下半年将面临以下关键演进：

ReAct 不再只是一个 Prompt 模板，它正在成为 Agent 操作系统的核心调度机制。

2026 年 6 月，Apache 基金会正式发布了 Burr 框架——一个专为 AI Agent 工作流设计的开源构建框架。Burr 的入场为 ReAct 范式的工程实践带来了新的选择和对比维度。

16.1 Burr 框架与 ReAct 的天然契合

Burr 的核心设计哲学是步骤（Step）+ 状态（State）+ 执行引擎（Executor）。这与 ReAct 的 Thought-Action-Observation 循环有着天然的契合点：Burr 的 Step 对应 ReAct 中的 Thought 或 Action，State 承载完整的 Thought-Action-Observation 历史，Executor 负责循环调度。

这种架构的优势在于：Burr 提供了比 LangGraph 更轻量、更透明的状态管理机制。LangGraph 的图结构虽然灵活，但对于简单的 ReAct 循环来说可能过于复杂——你需要定义节点、边、条件路由，而 Burr 只需要定义步骤函数和状态转换规则。

对于以 ReAct 为核心的 Agent 系统，Burr 提供了一种更直接的实现方式：每个 Thought 是一个 Step，每个 Action 是一个 Step，每个 Observation 更新 State，Executor 自动判断是否需要继续循环或输出 Answer。

16.2 LangGraph vs Burr：ReAct 实现的两种路径

选择建议：如果你的 Agent 只需要 ReAct 循环（即单 Agent、顺序执行、有工具调用），Burr 是更简洁的选择。如果你需要多 Agent 协作、条件分支、嵌套子图——LangGraph 的图抽象仍然不可替代。

16.3 数据驱动 Agent 工作流中的 ReAct

Burr 的一个独特优势是其数据驱动的 Agent 工作流支持。传统的 ReAct Agent 每次处理一个独立的输入，而 Burr 支持批量数据流式处理——将数据集作为输入流，每个数据点经过 ReAct 循环，中间状态可以被记录、回放和分析。

这种模式在以下场景特别有用：数据清洗 Agent（遍历数据集，对每条记录进行 ReAct 循环判断如何处理）、批量分类 Agent（对大量文档进行自动分类）、数据增强 Agent（基于现有数据生成新的训练样本）。

ReAct 在这种场景下的表现取决于两个关键因素：批量处理的吞吐量优化（能否并行处理独立的 ReAct 循环）和状态持久化（能否在中间步骤失败后从检查点恢复）。Burr 的内置检查点机制天然支持这种需求。

16.4 2026 年 ReAct 生态总结

截至 2026 年中，ReAct 范式已经从最初的论文提示模板，发展为一个拥有多种工程实现的成熟范式：

• LangChain/LangGraph：最成熟的 ReAct 实现，生态最大，适合复杂 Agent 系统
• Apache Burr：最轻量级的 ReAct 实现，适合数据驱动的 Agent 工作流
• CrewAI/AutoGen：多 Agent 协作框架中的 ReAct，侧重团队协作而非单 Agent 推理
• Claude Fable 5 / 原生工具调用：模型层面的 ReAct 支持，通过内置工具调用能力实现

ReAct 的核心思想——推理与行动的交替循环——已经成为 AI Agent 设计的默认模式。不同框架只是在实现方式和适用场景上有所差异。