面经策

ReAct 是什么？说说它的原理 ​

  • 标签：AI、大模型

🏛 业务架构师 ​

ReAct（Reasoning + Acting）是 Agent 的基础推理范式：让模型交替执行"思考（Thought）→行动（Action）→观察（Observation）"的循环——先推理"我该做什么"，再调用工具，看到结果后继续推理下一步，直到得出最终答案。

举个例子：用户问"这个客户的应收账款多少"——模型 Thought：需要先查客户 ID；Action：调 CRM 查询接口；Observation：ID 是 C1024；Thought：再查应收表……如此往复。

它解决的业务问题：纯推理（CoT）模型会"想当然"，不查实际数据就编答案；纯行动则缺乏规划，工具调得很乱。ReAct 把两者结合——用推理指导行动、用行动的真实结果校准推理，幻觉显著下降，还能向用户展示"我是怎么查到的"，答案可解释、可审计，这对 B 端交付至关重要。

2026 年现状：ReAct 已内化为所有主流模型的内置行为模式（模型训练时就带工具调用能力），开发者不再需要手写 "Thought/Action" 提示模板。但理解它依然是架构基本功——设计 Agent 的工具清单、日志埋点、失败重试策略，本质上都是在为 ReAct 循环服务。

🏗 系统架构师 ​

ReAct = Reasoning + Acting：让 LLM 交替进行"推理（Thought）"和"行动（Action）"的 Agent 范式——先想清楚下一步干什么、为什么，再调工具，拿到观察（Observation）后继续思考，循环直到结论。经典循环：Thought → Action → Observation → Thought → ... → Final Answer。

为什么它是基石：纯推理（CoT）没有外部信息，会幻觉；纯行动（机械调工具）没有规划，路径混乱。ReAct 把两者耦合：推理决定行动，行动反馈修正推理——这就是"感知-决策-执行"闭环在 LLM 上的实现，今天几乎所有 Agent 框架（含 Function Calling 的多轮循环）本质都是 ReAct 变体。

架构师视角的三个生产问题：

  • 循环失控：步数上限、token 预算、时长熔断是标配，否则一个死循环任务能烧几十万 token；
  • 错误恢复：工具报错时 Observation 里要带回结构化错误信息让模型改道，配合 Reflexion 类自反思可显著提升完成率；
  • 延迟与成本：每步一次 LLM 调用，N 步任务延迟线性放大，实时场景要限制步数或异步化（先回确认，完成后推送）。

我的经验：ReAct 适合探索型任务；流程可枚举的任务用固定 workflow 更便宜更稳。

💻 全栈开发专家 ​

ReAct = Reasoning + Acting：让模型交替输出「思考（Thought）→ 行动（Action）→ 观察（Observation）」三段式循环，直到得出最终答案。2022 年的论文，至今仍是 Agent 的基础范式。

一轮实际长这样：

Thought: 用户要查订单 A123 的物流，我需要先调订单接口
Action: query_order[order_id=A123]
Observation: 已发货，顺丰 SF123，昨晚 23:00 揽收
Thought: 还需要查顺丰轨迹才能回答预计送达
Action: query_logistics[track_no=SF123]
Observation: 已到深圳转运中心
Thought: 信息足够，可以回答
Final Answer: 您的订单已发货……预计明天送达

为什么有效：一是把「想」外化成文字，模型每步被迫显式推理而不是一口气瞎答；二是 Observation 把真实世界的反馈喂回来，错误能被下一轮纠正，这比纯 CoT（闭眼推）可靠得多。

工程现状：现在主流是「原生 tool calling + 隐式 ReAct」——模型的思考藏在 reasoning 内容里，工具调用是结构化 JSON 而非文本协议，但「推理-行动-观察」循环的本质没变。手写文本 ReAct 只在接不开 FC 的小模型时才需要。