想象你是一位主厨，要完成一道从没做过的菜。你不会照着一本死菜谱从头念到尾，而是站在灶台前反复循环三件事：看一眼锅里食材的状态——颜色、香气、浓稠度（观察）；心里盘算下一步该加盐、收汁还是转小火（思考）；然后动手翻锅、调味、调整火候（行动）。做完立刻再尝一口，用真实味道验证刚才的判断，然后进入下一轮……直到这道菜满意为止，才端出厨房。这个“看—想—做—尝”的循环，正是今天所有 AI Agent（智能体）的核心心跳，它的专业名字叫 ReAct——让大模型交替进行推理（Reasoning）与行动（Acting）。推理给 AI 计划和判断力，行动让它能真正调用工具改变外部世界，而观察用真实反馈把幻想拉回地面。这篇文章将带你从零看懂：ReAct 是什么、它的循环怎么转、工具怎么被调用、主流框架为什么都内置它，以及它有哪些力所不及的边界。

岗位关联

掌握 ReAct，你就拿到了 Agent 系统的心脏：一切能自主“干活”的 AI——客服、数据分析、代码排障——都以这个循环为引擎。它是从“会聊天”到“会做事”的分水岭，也是 Agent 工程师面试的一道必考题。

目录
  1. 可视化演示
  2. 核心定义
  3. 工作流程
  4. 核心组件
  5. 工具调用
  6. 框架应用
  7. 设计意义
  8. 局限挑战
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Agent核心架构ReAct的核心机制，通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Agent核心架构ReAct：ReAc ReAct作为Agent核心执 ReAct循环的感知推理行动观 核心机制可视化 Agent核心架构ReAct整体架构与关键组件

核心定义

想象你第一次做红酒炖牛肉。你没有照着菜谱背完整道流程才动手，而是站在灶台前“想一步、做一步”：看到牛肉上色了（观察），判断该倒红酒了（思考），于是端起酒瓶倒入锅中（行动）；闻到香气还不够浓，再想是不是要加番茄膏……真正的大厨从不“闭卷答题”，他们靠一个永不停息的回路来掌勺。这个回路，就是 ReAct 的雏形。

ReAct 是 Reasoning（推理）与 Acting（行动）的合成词，中文通常叫“推理+行动模式”。它把大模型从“一句话问答机”升级成“自主干活的 Agent”：模型先根据当前信息产生一段推理（Thought），再据此执行一个行动（Action），紧接着把行动的结果（Observation）纳入思考，继续下一轮。推理负责“想”，行动负责“做”，二者像织布一样交替编织。

在技术实现上，ReAct 让模型输出的不再只是“最终答案”，而是一条显式的轨迹：思考过程、行动调用、观察结果按固定语法交替出现。这条轨迹既服务于决策——每一步都由上一步的真实反馈驱动；也服务于审计——我们能看到 AI 每一步在想什么、做了什么、看到了什么。

回到厨房：好菜从来不是“背菜谱”背出来的，而是“尝一口、调一下”调出来的。ReAct 就是把这个“尝—调”本能程序化，让 AI 像主厨一样，永远在“看一眼、想一想、动一动手”的节奏里逼近最终目标。

ReAct=Thought⊕Action\text{ReAct} = \text{Thought} \oplus \text{Action}
公式通俗说明：ReAct 不是简单的“先想后做”，而是“想”与“做”的交替融合——⊕ 符号表示二者像织毛衣的经纬线一样交错缠绕。
  1. Thought（推理）模型在大脑里模拟问题解法，输出“下一步该做什么”的文字判断，如同主厨心里盘算“该加盐了”。
    Thought=LLM(当前状态)\text{Thought} = \text{LLM}(\text{当前状态})
  2. Action（行动）把判断落成环境中可执行的动作——搜索、计算、调用 API，如同主厨真的伸手去拿盐罐。
    Action=Execute(Thought)\text{Action} = \text{Execute}(\text{Thought})
  3. ⊕（交替融合）表示推理与行动彼此喂养，而非两个独立的先后阶段。
    循环=Thought→Action→Observation→Thought→⋯\text{循环} = \text{Thought} \to \text{Action} \to \text{Observation} \to \text{Thought} \to \cdots

工作流程

主厨最信赖的“老师”是舌头。无论菜谱写得多漂亮，最终都要靠尝味来验证：咸了？淡了？汁太稠了？这一个“尝”字，构成了整个烹饪循环的反馈枢纽。ReAct 的运转同样靠一个铁三角循环：Observation（观察）→ Thought（思考）→ Action（行动）→ 下一轮 Observation。

更严格地说，ReAct 的标准单回合从思考开始：Thought（我要查一下这道菜的历史背景）→ Action（搜索工具）→ Observation（返回三条资料）。观察结果作为新一轮的输入，触发下一个 Thought。如此往复，直到模型输出 Final Answer（最终答案）收尾。

整个循环展开后就是这样一条不断生长的链条：每一轮的观察都“落盘”到上下文里，成为下一轮思考的背景知识。Agent 不是一次性生成答案，而是像滚雪球一样，把外部世界的真实信息一点点滚进自己的判断里。

这就是为什么主厨做菜“越做越有感觉”：每一口试味都在修正下一步。ReAct 的循环同样让 Agent“越做越接近正确答案”，只要反馈真实、循环不断，答案就会在迭代中逐步收敛。

Observationt→Thoughtt→Actiont→Observationt+1\text{Observation}_t \rightarrow \text{Thought}_t \rightarrow \text{Action}_t \rightarrow \text{Observation}_{t+1}
公式通俗说明：第 t 轮先看情况、再想办法、再动手做，做出来的结果又变成第 t+1 轮的“新情况”——循环的每一环都以上一环的真实反馈为食。
  1. Observation_t（第 t 轮观察）取回环境当前的真实状态，作为本轮推理的起点，如同主厨低头看锅里的成色。
    Observationt=环境反馈\text{Observation}_t = \text{环境反馈}
  2. Thought_t（本轮思考）大模型基于观察输出推理，决定下一步动作。
    Thoughtt=LLM(Observationt)\text{Thought}_t = \text{LLM}(\text{Observation}_t)
  3. Action_t（本轮行动）执行一个具体动作，如调用工具。
    Actiont=Tool(Thoughtt)\text{Action}_t = \text{Tool}(\text{Thought}_t)
  4. Observation_{t+1}（下一轮观察）行动结果改变环境，产生新一轮反馈，循环变量推进。
    t←t+1t \leftarrow t + 1

核心组件

如果把主厨拆解成零件，至少有三样东西不可或缺：一颗会判断的大脑、一双能动手的手臂、一套连接厨房的器具。ReAct Agent 也是由这三个部件组装起来的——它们各自承担“想”“做”“连”的职责。

第一个部件是思考模块，它由大模型（LLM）充当，负责输出 Thought；第二个是行动模块，它也由 LLM 驱动，但输出的是结构化动作指令（例如“调用搜索工具，参数是'深圳人口'”）；第三个是工具接口，它维护一份工具清单——每个工具的描述、参数格式、执行函数，负责把模型发出的指令翻译成真实函数调用。

三个部件通过“上下文”粘合在一起。Agent 每一轮产生的观察、思考、行动都会追加进一段不断生长的对话历史 Context，模型每次都基于完整历史做决策。这就像一个永远写不完的厨房日志：几点加了盐、尝起来怎样，全记在本子上，下一手有据可依。

一台完整的 ReAct Agent，就像一套分工明确的“后厨班组”：大脑在想、手在动、台账在记。任何一环缺位，循环都会停摆——没有思考模块，行动变成乱撞；没有工具接口，行动变成空话；没有上下文，Agent 就是失忆的主厨。

Contextt=[O1,T1,A1,O2,T2,A2,…,Tt]\text{Context}_t = [O_1, T_1, A_1, O_2, T_2, A_2, \ldots, T_t]
公式通俗说明：第 t 轮模型能看到从第 1 轮到第 t 轮的全部记录——每轮观察 O、思考 T、行动 A 都按顺序保存在上下文里，像主厨的厨房日志越写越厚。
  1. Context_t（累计上下文）模型在第 t 轮看到的完整对话历史，是所有决策的依据。
    Contextt=历史轨迹的拼接\text{Context}_t = \text{历史轨迹的拼接}
  2. O_i（观察记录）第 i 轮工具返回的真实结果，是上下文中“事实”的来源。
    Oi=Run(Actioni)O_i = \text{Run}(\text{Action}_i)
  3. T_i / A_i（思考与行动成对出现）每个思考都对应一个行动，形成“想—做”配对。
    (Ti,Ai):推理与行动的对偶(T_i, A_i): \text{推理与行动的对偶}
  4. 写到 T_t 为止（只到当前思考）第 t 轮的行动尚未发生，属于“未来”，不在上下文里。
    At∉ContexttA_t \notin \text{Context}_t

工具调用

主厨的调料台上摆满了罐子：盐、糖、酱油、醋，每个罐子都贴着标签。要用哪个、放多少，全凭脑子判断。ReAct 里的“工具”就是这些贴着标签的调料罐——搜索 API、计算器、数据库、内部系统接口，都是可以被调度的外部能力。

当模型进入 Action 阶段，它要先做两个决定：选哪个工具（tool_k），以及传什么参数（args_t）。这通常以结构化 JSON 输出完成，例如 {"name": "搜索", "arguments": {"query": "深圳人口 2024"}}。运行时解析这段指令，找到对应工具函数真实执行，再把返回值包装成 Observation 写回上下文。

工具接口的关键设计在于“注册表”：把工具的 name、description、parameters schema 作为提示词的一部分提供给模型，模型才能“知道厨房里有什么罐子”。工具描述写得越清楚，模型选择越准；参数 schema 越严格，执行越少出错。真实工程里，一个 Agent 往往挂载 5-30 个工具，靠这套注册机制维持调度秩序。

工具调用让 ReAct 完成从“想”到“做”的惊险一跃：模型说的每句话，都可能触发真实世界的动作。正如主厨的每一个判断都要落到铲子和盐罐上，Agent 的每一个思考都必须落到工具调用上，才能产生真实价值。

toolk,argst=LLM(Contextt)Observationt+1=Run(toolk,argst)\text{tool}_k, \text{args}_t = \text{LLM}(\text{Context}_t) \qquad \text{Observation}_{t+1} = \text{Run}(\text{tool}_k, \text{args}_t)
公式通俗说明：模型从“工具菜单”里点菜——选出工具并填好参数，后厨（运行时）真实做菜，把成品端回来当成下一轮观察。
  1. LLM(Context_t)（模型决策）模型基于上下文同时输出工具序号与参数。
    toolk,argst∼LLM(Contextt)\text{tool}_k, \text{args}_t \sim \text{LLM}(\text{Context}_t)
  2. tool_k（工具选择）从注册表中挑选一个工具，如同主厨挑中“温度计”。
    k=arg⁡max⁡匹配度(意图,工具描述)k = \arg\max \text{匹配度}(\text{意图}, \text{工具描述})
  3. args_t（参数生成）按该工具的 schema 生成具体参数。
    argst={query:"深圳人口"}\text{args}_t = \{ \text{query}: \text{"深圳人口"} \}
  4. Run 执行并返回观察运行时真实执行工具，返回值写入上下文。
    Observationt+1=TOOLS[k](argst)\text{Observation}_{t+1} = \text{TOOLS}[k](\text{args}_t)

框架应用

一家成功的餐厅不会只靠一位天才主厨，而是把主厨的“看—想—做—尝”流程标准化成后厨流水线，让任何厨师按步骤操作都能做出稳定菜品。AI 工程界也做了同样的事：把 ReAct 循环封装进主流开发框架，让开发者不用从零编写循环。

LangChain 是最典型的例子——它的 Agent 模块内置了 ReAct 风格执行器：开发者只需声明工具列表和模型，框架自动完成“模型输出→解析动作→调用工具→写回观察”的循环调度。OpenAI 的 Function Calling 则在模型层面原生支持结构化工具调用，把“选工具+传参数”变成模型输出的一种格式，同样是 ReAct 思想的工业实现。此外，AutoGPT、自研 Agent 引擎等也大多以 ReAct 或其变体（如带记忆模块的扩展版）作为核心引擎。

在这些框架里，Agent 被抽象成三个可配置的插槽：LLM（大脑）、Tools（工具包）、Memory（记忆）。开发者通过配置而非改代码，就能组装出一个能干活的多步 Agent。这也是为什么“几乎所有主流 Agent 框架都内置 ReAct”——它已经被验证为最稳健的基础执行范式。

如果说单次对话是“私房菜小灶”，框架化的 ReAct 就是“中央厨房”——同样的味道，批量生产。理解了内核循环，再看任何 Agent 框架的文档，你都能一眼认出：万变不离 ReAct 的“看—想—做—尝”。

Agent=ReAct(LLM,Tools,Memory)\text{Agent} = \text{ReAct}(\text{LLM}, \text{Tools}, \text{Memory})
公式通俗说明：一个可用 Agent 等于“会思考的大脑 + 一整套工具 + 记忆能力”，由 ReAct 循环把三者串成自动运转的流水线。
  1. LLM（大脑）负责产生 Thought 与 Action 决策。
    LLM:思考模块\text{LLM}: \text{思考模块}
  2. Tools（工具包）行动可触达的外部能力集合。
    Tools:行动模块\text{Tools}: \text{行动模块}
  3. Memory（记忆）保存 Context 轨迹，支撑长期与短期记忆。
    Memory:上下文存储\text{Memory}: \text{上下文存储}
  4. ReAct(……)（调度循环）把三者组装成“思考→行动→观察”的自动引擎。
    ReAct:循环调度器\text{ReAct}: \text{循环调度器}

设计意义

为什么主厨坚持反复试菜？因为舌头是唯一能戳破想象的工具。菜谱可能记错、火候可能判断失误，但尝一口是真实的。ReAct 的设计哲学同样朴素：用真实观察锚定推理，让模型少一点自说自话。

这带来三个核心价值。第一，增强自主性：模型不再等待人类喂下一步指令，而是自己规划并执行多步操作，一个人就能完成“查天气→订机票→订酒店”的完整任务链。第二，提升可解释性：每一步的 Thought、Action、Observation 都被记录下来，出错时可以像回放录像一样定位是哪一轮判断失误。第三，减少幻觉：观察结果不断把推理拉回事实，模型“编造”的空间被大幅压缩。

从概率视角看，ReAct 的最终答案不是一次抽样生成，而是基于完整轨迹的条件生成。每一轮真实观察都在为答案提供“证据”，让结论长在事实的土壤上，而不是悬浮在模型的统计记忆里。

所以 ReAct 的意义不只是“多了一个流程”，而是重新定义了 AI 的认知方式：从“回忆答案”走向“调查答案”。主厨的菜之所以稳定好吃，是因为每一勺都有舌头的反馈；Agent 的答案之所以可信，是因为每一个结论都有观察的支撑。

Answer=LLM(ContextT),ContextT=⋃t=1T{Ot,Tt,At}\text{Answer} = \text{LLM}\Big(\text{Context}_T\Big), \qquad \text{Context}_T = \bigcup_{t=1}^{T}\{O_t, T_t, A_t\}
公式通俗说明：最终答案不是“空想”出来的，而是综合了 T 轮所有真实观察、思考与行动之后才给出的——像主厨尝了无数次才定下最终配方。
  1. Answer（最终答案）由最后一轮 LLM 调用产生的结论。
    Answer=LLM(完整历史)\text{Answer} = \text{LLM}(\text{完整历史})
  2. Context_T（完整轨迹）汇聚全部轮次的观察、思考、行动。
    ContextT={O1,T1,A1,…,OT,TT}\text{Context}_T = \{O_1, T_1, A_1, \ldots, O_T, T_T\}
  3. ∪（信息累积）每一轮信息都保留并叠加，而非覆盖。
    Ot∈ContextT,∀t≤TO_t \in \text{Context}_T, \forall t \le T
  4. 真实观察（关键锚点）答案被工具返回的事实“钉”在地面上。
    幻觉概率∝1观察次数\text{幻觉概率} \propto \frac{1}{\text{观察次数}}

局限挑战

再厉害的主厨也有翻车的时候：灶台太小，摆不下一百个调料罐；一步火候失误，整锅菜就毁了；每道菜都反复试味，时间成本翻倍。ReAct 同样有这三道坎。

第一道坎是上下文限制。轨迹不断累积，而模型上下文窗口有限，超过长度后最早的历史会被截断，Agent 可能“失忆”。工程上需要压缩、摘要或检索历史。第二道坎是错误累积：多步推理中，任何一步判断失误都会污染后续所有决策，就像汤里一开始就放多了盐，后面怎么调都带着咸味。第三道坎是成本开销：每一步都调用一次大模型，token 消耗与延迟随轮数线性增长，复杂任务可能“做得起，等不起”。

错误累积还可以从数学上理解：若每一步的失误概率为 ε_t，那么整个循环最终出错的概率不是简单相加，而是“只要有一个环节错就全错”的复合事件。步数越多，成功概率乘积越小，总失误率越高。这提示我们：设计 Agent 时，步数越短越好，关键决策点越靠前越好，并且要设置最大步数兜底。

承认这些局限，不是否定 ReAct，而是让我们更聪明地使用它：把大任务切成小循环、给工具调用加校验、设好最大步数、及时止损。主厨也会在灶台前备好灭火器——理解边界，才是一个成熟 Agent 工程师的标志。

---

Etotal=1−∏t=1T(1−εt)E_{\text{total}} = 1 - \prod_{t=1}^{T}(1 - \varepsilon_t)
公式通俗说明：整串循环不出错的概率 = 每一步都不出错的概率相乘；步数越多，乘积越小，总失误率就越接近 1——一环失手，满盘皆输。
  1. E_total（总失误率）整个 ReAct 循环最终至少错一步的概率。
    Etotal=P(至少一步出错)E_{\text{total}} = P(\text{至少一步出错})
  2. ε_t（单步失误率）第 t 步（思考或工具执行）出错的概率。
    εt=P(第 t 步出错)\varepsilon_t = P(\text{第 } t \text{ 步出错})
  3. ∏(1 - ε_t)（全程无错概率）所有步都正确的联合概率，每一步都对才最终成功。
    P(成功)=∏t=1T(1−εt)P(\text{成功}) = \prod_{t=1}^{T}(1 - \varepsilon_t)
  4. 1 - ……（取补事件）总失败率 = 1 减去全程成功概率。
    Etotal=1−∏t=1T(1−εt)E_{\text{total}} = 1 - \prod_{t=1}^{T}(1 - \varepsilon_t)

AI 应用场景

客服工单自动处理

阶段：多步工具调用与反馈评估

解决的问题：传统客服机器人只能查 FAQ 或做单轮问答，遇到“查订单→判断是否超时→发起退款”这种多步流程就断链。ReAct Agent 把问题拆成 思考→行动→观察：查询订单 API、核对规则、调用退款工具、确认结果，全程轨迹可审计。

具体案例：某电商用 ReAct 处理“我的订单超时未发货”投诉：Agent 先调用订单查询工具拿到物流状态，观察到“超时”后调用赔付工具，最后生成安抚话术回复用户，全程不到 5 次工具调用。

数据分析问答助手

阶段：工具选择与参数生成

解决的问题：业务同学要“上季度华南区销售额”，传统 BI 需要人工写 SQL。ReAct Agent 将自然语言转成结构化查询动作：选表、生成 SQL、执行、观察结果、再决定是否补充查询，最后返回结论。

具体案例：某 SaaS 公司让 Agent 连接指标库与 SQL 执行器；观察到“总额偏小”时 Agent 主动补充“是否包含退款订单”的二次查询，再给出带口径说明的答案。

代码仓库问题定位助手

阶段：环境感知与执行反馈

解决的问题：传统 Copilot 只能生成代码片段，无法自主验证。ReAct Agent 通过“搜索代码→读文件→运行测试→观察失败信息→修改再验证”的循环完成排障。

具体案例：开发者把“登录接口报 500”抛给 Agent，它依次调用代码搜索、文件读取、日志查询工具，观察错误堆栈后定位到空指针并给出补丁。

Python 演示

python40 行
import mathimport re TOOLS = {    "计算器": lambda expr: str(eval(expr, {"__builtins__": {}}, {"abs": abs, "round": round, "sqrt": math.sqrt})),    "查城市人口": lambda city: "%s人口约 %s" % (        city,        "1756 万" if "深圳" in city else ("2189 万" if "北京" in city else "未知"),    ),} # A minimal ReAct loop: think -> act -> observedef fake_llm(context):    text = " | ".join(context)    if "观察：深圳人口" in text:        return "思考：已经拿到深圳人口数据。\n行动：Finish(答案：深圳人口约 1756 万)"    if "人口" in text:        return "思考：需要查询城市人口数据。\n行动：查城市人口('深圳')"    return "思考：没有可用工具，直接结束。\n行动：Finish(答案：无法回答)" def parse_action(output):    thought = output.split("思考：")[1].split("\n")[0]    match = re.search(r"行动：(\w+)\((.*)\)", output)    return thought, match.group(1), match.group(2).strip("'\"") def run_agent(question, max_steps=4):    steps = ["用户问题：" + question]    for i in range(max_steps):        output = fake_llm(steps)        thought, action, arg = parse_action(output)        print("第 %d 轮 | 思考：%s" % (i + 1, thought))        if action == "Finish":            return arg        observation = TOOLS[action](arg)        print("行动：调用[%s] -> 观察：%s" % (action, observation))        steps.append("观察：" + observation)    return "达到最大步数，未完成" if __name__ == "__main__":    print("最终答案：", run_agent("深圳人口多少？"))
目的：用 50 行代码实现一个迷你 ReAct Agent，演示“思考→行动→观察→再思考”的完整循环，以及工具调用和观察回写的机制。
  1. TOOLS = {...}注册工具清单，相当于厨房调料罐的标签，模型只能“看见”注册过的工具
  2. def fake_llm(context):用一个规则函数模拟大模型，根据上下文状态输出“思考+行动”格式的文本
  3. if "观察：深圳人口" in text:模型“看到”真实观察后决定收尾，这正是循环的反馈驱动机制
  4. parse_action(output)解析模型输出的结构化动作，提取工具名和参数，对应 JSON 工具调用的简化版
  5. observation = TOOLS[action](arg)真实执行工具函数，得到环境反馈（观察）
  6. steps.append("观察：" + observation)把观察写回上下文，让下一轮思考有据可依
  7. if action == "Finish": return arg模型判断任务完成，输出最终答案，退出循环

常见误区

误区我以为只要在提示词里写上“请一步步思考并行动”，让模型输出一大段推理过程，就实现了 ReAct。

正解ReAct 的本质是推理与行动交替、且行动必须触发真实工具调用并接收真实观察反馈。只输出长文本而没有工具执行与结果回写，那只是 CoT（思维链），模型仍然在“闭卷答题”。判断标准很简单：有没有外部动作？有没有观察被写回上下文？二者缺一，就不是 ReAct。

为何常见：因为 ReAct 的思考过程看起来和普通长推理很像，容易把“输出格式”误当成“机制本身”。

误区我一直以为 ReAct 里的 Action 就是把要做的事用文字描述出来，比如“搜索人口数据”，就算完成任务了。

正解Action 必须是可执行的指令：指定工具名称和参数，由运行环境真实调用（搜索 API、计算器、数据库）。仅描述动作而没有真实执行，观察永远不会出现，循环也无法推进。就像主厨只念叨“我要加盐”却不伸手撒盐，菜永远不会变咸。

为何常见：因为对 Chat 模型的习惯是把输出当“回复”而非“指令”，没意识到 Agent 的输出是要被程序调度执行的。

误区如果工具调用失败了，我会让模型“猜一个合理的结果”写进观察里，继续往下走。

正解观察必须来自工具的真实返回。编造观察等于切断 Agent 与环境的连接，推理会重新漂浮在幻觉上。真实实践里，工具失败时应把错误信息作为观察回传，让模型决定换工具或结束，而不是替工具作答。

为何常见：因为单轮对话中模型习惯“自圆其说”，而 ReAct 的价值恰恰在于用外部事实打断这种自圆其说。

误区我觉得只要多循环几轮，让模型多思考多尝试，答案一定会越来越正确，最好设成无限循环。

正解每多一轮，既多一次错误累积的机会，也多一份 token 成本与延迟。ReAct 实践通常设最大步数（如 5-8 轮），配合“尽早 Finish”的约束。无界循环反而容易在错误轨迹上越陷越深，正如错误累积公式所示：步数越多，总失误率越接近 1。

为何常见：因为直觉上“多想几遍更保险”，忽略了多步推理的误差会相乘，也忽略了成本约束。

面试题

Q1. ReAct 中“Re“和”Act”分别指什么？

单选题 · easy

  • A.推理与行动← 正确答案
  • B.记忆与计划
  • C.搜索与规划
  • D.学习与执行

答案：A。ReAct 是 Reasoning（推理）与 Acting（行动）的合成词，正如主厨的“想”与“做”；记忆与计划是其他 Agent 范式的关注点，不是 ReAct 名字的来源。

Q2. ReAct 标准单回合的顺序是？

单选题 · easy

  • A.行动—观察—思考
  • B.思考—行动—观察← 正确答案
  • C.观察—思考—行动
  • D.行动—思考—观察

答案：B。标准 ReAct 单回合按“思考→行动→观察”展开，观察结果再喂给下一轮思考；选项 B 恰好对应这个顺序，其他选项把顺序颠倒或漏掉了关键环节。

Q3. 观察结果在 ReAct 循环中充当什么角色？

单选题 · mid

  • A.作为最终输出
  • B.作为决策的依据← 正确答案
  • C.作为丢弃的缓存
  • D.作为训练的目标

答案：B。观察结果不是最终答案（A 错），也不是被丢弃的中间态（C），更不是训练目标（D）。它作为下一轮思考的输入，让推理获得真实世界的“味道反馈”，正如主厨的试味。

Q4. 在 ReAct 中，工具调用的返回结果通常被当作什么？

单选题 · easy

  • A.充当观察结果← 正确答案
  • B.充当推理输出
  • C.充当行动指令
  • D.充当最终答案

答案：A。工具返回结果被当作 Observation 写入上下文，模型据此修正下一步计划。它是循环的“尝一口”环节，而不是推理或行动本身。

Q5. 下列哪项是 ReAct 提升答案可靠性的关键机制？

单选题 · mid

  • A.扩大模型参数规模
  • B.用真实观察校正推理← 正确答案
  • C.随机重试所有工具
  • D.持续压缩上下文窗口

答案：B。ReAct 用真实观察校正推理，让模型少“闭卷瞎编”；扩大参数量是静态能力的提升，随机重试是野蛮策略，压缩上下文是管理手段，都不是 ReAct 的核心机制。

Q6. ReAct 相比纯推理（CoT）的主要区别是？

单选题 · mid

  • A.可调用工具获取新信息← 正确答案
  • B.会生成更长的推理文本
  • C.无需任何上下文信息
  • D.只能用于图像类任务

答案：A。与 CoT 相比，ReAct 多出“工具调用→观察回传”这一闭环；CoT 只在文本内部推理，无法获取新信息，就像只看菜谱却不进厨房。

Q7. 上下文窗口有限时，ReAct 会面临什么问题？

单选题 · hard

  • A.推理速度会明显变慢
  • B.历史轨迹将被截断← 正确答案
  • C.工具无法完成注册
  • D.模型将无法再训练

答案：B。轨迹不断累积而窗口有限，最早的历史会被截断，Agent 可能“失忆”，忘记前面的观察与行动；这不影响工具注册或模型训练，速度变化也不是主要问题。

Q8. 下列哪些属于 ReAct 中“核心组件”的范畴？（多选）

多选题 · mid

  • A.思考模块← 正确答案
  • B.行动模块← 正确答案
  • C.工具接口← 正确答案
  • D.文件系统

答案：ABC。ReAct 的三大核心组件是思考模块（LLM）、行动模块（动作生成）、工具接口（注册与分发），三者对应主厨的大脑、手臂和调料台；文件系统只是可挂载的工具之一，不是组件本身。

Q9. 下列哪些属于 ReAct 的常见局限？（多选）

多选题 · hard

  • A.错误会在多步中累积← 正确答案
  • B.每步产生额外推理开销← 正确答案
  • C.必须海量标注训练数据
  • D.天生无法调用任何工具

答案：AB。ReAct 的常见局限是错误在多步传播、每步额外调用 LLM 产生成本与延迟；它不需要海量标注数据（C 错），而且恰恰需要工具接口来执行动作，并非无法调用工具（D 错）。

Q10. 关于 ReAct 与 Agent 框架的关系，下列说法正确的是？（多选）

多选题 · extreme

  • A.多数框架默认内置 ReAct← 正确答案
  • B.ReAct 是 Agent 核心循环← 正确答案
  • C.ReAct 完全替代模型训练
  • D.变体可扩展记忆与规划← 正确答案

答案：ABD。LangChain、OpenAI Function Calling 等主流框架默认内置 ReAct 或其变体作为核心执行引擎；ReAct 是推理时的调度范式，不替代模型训练（C 错）；扩展版可加入记忆、规划等模块，正如主厨的中央厨房可加装新设备。