想象你是一家餐厅的老板，准备雇一个 AI 来替你做菜。第一代员工只会照本宣科：你问“红烧肉怎么做”，他能背出一段菜谱，但你说“今天五花肉偏肥，怎么办”，他就哑火了。第二代员工学会用工具：他能查电子秤、开烤箱，但做完一道菜从不尝一口，菜糊了也不知道。直到你遇到 ReAct 型主厨——他做菜的方式是：先想下一步该干什么（先炒糖色），然后动手做（下锅），再看一眼结果（糖色微微发棕、闻到焦香），接着再想（火候要收一下）……如此循环，直到这道菜达标，才进入下一道菜。 这个“边想边做、边看边改”的循环，就是 ReAct（Reasoning + Acting）范式。它像一座桥，把只会“一问一答”的大模型，渡到了真正能“干活”的智能体（Agent）彼岸。再往后，多个这样的主厨组队协作，甚至自主规划一整季菜单——Agentic AI 的演进画卷，恰恰从 ReAct 这一笔开始。理解这张图，你就看懂了 Agent 技术从哪来、往哪去。

岗位关联

理解 ReAct，就抓住了 Agent 从“会聊天”迈向“会干活”的命门——无论你做应用、做产品还是做研究，它都是判断 AI 能力边界与演进方向的核心坐标。

目录
  1. 可视化演示
  2. 1. Agent 的本质定义：厨房里的主厨
  3. 2. 从点外卖到掌勺：范式演进脉络
  4. 3. ReAct 核心机制：边想边做的循环
  5. 4. 推理与行动的化学反应
  6. 5. ReAct 的局限与厨房瓶颈
  7. 6. 多智能体协作：后厨团队作战
  8. 7. 自主规划：主厨的菜单蓝图
  9. 8. 实践落地：把方法论搬回自家厨房
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示Thought-Action-Observation三元循环机制、ReAct与CoT/Act范式多维度对比、Agent从API调用到多智能体协作的演进历程。切换模式查看Agentic AI核心范式。

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

TAO循环：推理与行动交替执行 Thought阶段推理当前状态与下一步策略 Action阶段调用工具或API执行操作 Loop: Thought → Action → Observation → ... Observation将外部结果反馈给推理形成闭环

1. Agent 的本质定义：厨房里的主厨

想象一家餐厅的后厨。如果只把订单丢给一个只会背菜谱的机器人，它顶多照着固定流程出菜；客人说“少放辣”“香菜过敏”，它就傻眼了。真正的后厨核心，是一位主厨——他清楚今晚要做什么菜（目标），会查看冰箱和灶台状态（感知），能切、炒、调味（行动），还记得昨天的备料经验和客人的口味偏好（记忆）。这样的实体，才配叫“智能体”（Agent）。

在 AI 世界里，智能体不是某个具体算法，而是一个能感知环境、自主决策、采取行动并朝目标迭代的软件实体。它不再像传统大模型那样“你问一句、它答一句”，而是被赋予一个待完成的任务，然后自己想办法搞定它。ChatGPT 是“会聊天的百科全书”，Agent 则是“接了订单会自己去后厨忙活的主厨”。

我们可以用四元组刻画一个智能体：目标 G、观察 O、行动 A、记忆 M。目标是任务的成功标准；观察是从环境中获得的信息（工具返回值、页面内容、用户反馈）；行动是可执行的动作集合（调用 API、检索数据库、写文件）；记忆是历史轨迹和经验的存储。ReAct 之所以成为范式分水岭，正是因为它第一次让“推理”也深度参与了这套循环——主厨不仅动手，还动脑。

就像主厨必须先知道“顾客要什么、厨房有什么、自己会什么”，才能谈得上一桌好菜；Agent 的定义也划出了它与“只会对答的聊天机器人”之间的根本差别——一个有目标且会动手，一个只会张嘴。

Agent=⟨G,O,A,M⟩\displaystyle \mathrm{Agent} = \left\langle \mathcal{G}, \mathcal{O}, \mathcal{A}, \mathcal{M} \right\rangle
智能体可用“目标、观察、行动、记忆”四元组表示，它们分别回答：要什么、看到什么、能做什么、记得什么。这四个要素缺一不可。
  1. 目标 G（Goal）任务是成功的标准，像订单上客人对菜品的全部要求——少盐、微辣、半小时内上桌。
    G\mathcal{G}
  2. 观察 O（Observation）从环境中获取的信息，像主厨打开冰箱查看食材存量、摸一下锅的温度。
    O\mathcal{O}
  3. 行动 A（Action）可执行动作的集合，像切、炒、调味等具体厨艺动作，对应 Agent 的工具箱。
    A\mathcal{A}
  4. 记忆 M（Memory）历史信息的存储，像主厨记在心里的菜谱、客人的忌口和上次翻车的教训。
    M\mathcal{M}

2. 从点外卖到掌勺：范式演进脉络

把时间轴拉长，Agent 的进化就像一个人学做饭的四个阶段。第一阶段是“点外卖”：把需求发给大模型，一次调用直接返回答案，中间没有任何调整余地——好吃难吃都是它，你只能干等。第二阶段是“照着菜谱做”：模型掌握了调用外部工具的能力（比如搜索、计算器），但依旧是一次规划、一次执行，做砸了也不会返工。

第三阶段就是 ReAct：主厨边做边尝——推理一步、执行一步、观察结果、再推理一步，把“做菜”从单次动作变成了自适应循环。第四阶段是“后厨团队”：多个各有所长的智能体分工协作，有人备菜、有人掌勺、有人摆盘，最后拼成一桌完整的宴席。这条脉络抓住了 Agent 技术最本质的跃迁：从“被任务推着走”到“主动奔着目标去”。

这条路径可以用一条链式公式概括，每个环节都叠加了新的控制能力，而没有扔掉前面的能力：

回头看，每一次范式跃迁都没有丢掉前面的能力，而是叠加上一层新的“控制权”：从单次应答，到会调用工具，到会基于反馈迭代，再到会分工协作。未来的自主规划趋势，则是给这套协作再装上一个“提前规划整季菜单”的大脑。

LLMcall→LLMtool→ReActloop→Multi-Agentcollab\displaystyle \text{LLM}^{\text{call}} \rightarrow \text{LLM}^{\text{tool}} \rightarrow \text{ReAct}^{\text{loop}} \rightarrow \text{Multi-Agent}^{\text{collab}}
范式的演进是“能力叠加”而非“推倒重来”：单次问答加了工具变成工具调用，工具调用加了反馈循环变成 ReAct，ReAct 加了协作协议变成多智能体。
  1. 单次问答（LLM^call）像直接点外卖，模型一次性生成答案，没有中途调整机会，也不接触真实世界。
    LLMcall\text{LLM}^{\text{call}}
  2. 工具调用（LLM^tool）像照着菜谱取用现成调料，模型会调用外部函数，但缺少基于结果的迭代。
    LLMtool\text{LLM}^{\text{tool}}
  3. ReAct 循环（ReAct^loop）像边做边尝的主厨，推理与行动交替，观察结果再决定下一步，形成闭环。
    ReActloop\text{ReAct}^{\text{loop}}
  4. 多智能体（Multi-Agent^collab）像后厨团队分工协作，多个 Agent 各司其职、消息互通，最终拼出完整答案。
    Multi-Agentcollab\text{Multi-Agent}^{\text{collab}}

3. ReAct 核心机制：边想边做的循环

ReAct 的核心，用一个动作就能概括：“想一步、做一步、看一眼、再想。”回到厨房：主厨接单后并不盲目下锅，他先想“这道红烧肉要先炒糖色”（Thought）；接着动手炒糖（Action）；看到糖色微微发棕、闻到焦香（Observation）；再推理“火候还要再收一下”——如此循环，直到一道菜达到验收标准。

ReAct 的名字来自 Reasoning + Acting 的拼接。论文的核心观察是：单独让模型推理（Reasoning）容易陷入空想——想得再周密也没见过真实世界；单独让模型行动（Action）容易蒙头猛冲——做了也不回头检查。把两者交替组织成一条轨迹，效果反而是 \(1+1>2\)。实现上，模型可以在回答过程中交错生成 Thought、Action、Observation 三个字段，其中 Observation 来自环境（工具返回、检索结果），而不是模型自己编的。

这条交替轨迹在形式化层面可以写成一条链：每个三元组都代表“思考→动手→看结果”的一轮，链的长度由任务复杂度决定，终点是模型认为可以输出最终答案的时刻。

主厨不会一口气把整桌菜全做完再看效果，而是一道菜一道菜地调整；ReAct 也一样，把长任务切成“一步一反馈”的小循环，让每一步都站在真实信息之上，而不是凭空想象。

τ=(T1,A1,O1)→(T2,A2,O2)→⋯→(Tn,An,On)⇒Answer\displaystyle \tau = (T_1, A_1, O_1) \rightarrow (T_2, A_2, O_2) \rightarrow \cdots \rightarrow (T_n, A_n, O_n) \Rightarrow \text{Answer}
ReAct 的轨迹是一串“推理-行动-观察”三元组首尾相连，像主厨的记录单：每一步都写清楚想了什么、做了什么、看到了什么，直到最后写下一个“成”字。
  1. 推理 T（Thought）模型用自然语言写出这一步的计划或原因，像主厨自言自语“该炒糖色了”。
    T1T_1
  2. 行动 A（Action）调用具体工具或执行动作，像主厨真的把糖倒进热锅——行动会真实地改变环境。
    A1A_1
  3. 观察 O（Observation）环境返回的结果，像主厨看到糖色变化、闻到焦香——这是外部世界给的“回执”。
    O1O_1
  4. 循环直至答案（Answer）三元组不断交替推进，直到模型认为信息足够，输出最终答案，像主厨尝了一口后确定“可以出锅了”。
    (Tn,An,On)⇒Answer(T_n, A_n, O_n) \Rightarrow \text{Answer}

4. 推理与行动的化学反应

为什么“想”和“做”交替出现，比单纯想或者单纯做都强？回到厨房——如果主厨闭眼空想菜谱，他永远不知道今天的五花肉偏肥、炉灶的火力偏弱；如果他闷头猛炒，不看颜色不尝味道，焦了也不知道。只有“动作触发反馈、反馈修正思考”，做菜才是一个自校正的过程。ReAct 的巧妙，正在于把这两个环节焊成了一个闭环。

技术上，推理（Thought）为行动提供方向和理由，避免模型像无头苍蝇一样随机试工具；行动（Action）调用外部工具，把“世界的信息”引入上下文；观察（Observation）则是环境给的硬反馈——不是模型自说自话的“我觉得”，而是工具真实返回的“事实上”。三者形成闭环后，模型生成下一步时，是在真实环境状态上做条件概率采样，而不是在自己编造的假设上空转。

这一步“条件生成”的关系可以写成下面的式子：下一步推理以上一步观察为条件，而观察本身是行动作用于环境的函数。

这一机制带来的直接收益有三：第一，抑制幻觉——工具返回值像事实锚点，模型“编造”的空间被压缩，正如主厨以“尝味道”而不是“猜味道”为准；第二，轨迹可解释——每一步 Thought 和 Action 都记录在案，像品控日志，出了问题可以回溯到底是哪一步跑偏；第三，任务可分解——复杂问题被化整为零，一步一块，稳扎稳打。

Tt+1∼LLM(H<t,Ot),Ot=E(At)\displaystyle T_{t+1} \sim \mathrm{LLM}\left( \mathcal{H}_{<t}, O_t \right), \qquad O_t = \mathcal{E}(A_t)
当前时刻的推理，是由“此前所有轨迹 + 最新的环境观察”共同决定的；而观察不是凭空出现，它是模型上一个行动在真实世界里激起的涟漪。
  1. 行动触发反馈\(A_t\) 被执行后，环境会返回观察结果，如同把食材扔进油锅，锅里立刻给出“噼啪”的反馈。
    Ot=E(At)O_t = \mathcal{E}(A_t)
  2. 历史轨迹\(\mathcal{H}_{<t}\) 是此前所有推理、行动和观察的完整记录，是模型“记忆”的载体，像主厨手上那张写满步骤的品控单。
    H<t\mathcal{H}_{<t}
  3. 条件生成LLM 把历史与最新观察拼在一起作为输入，在前文约束下生成下一步推理，而不是凭空发挥。
    LLM(H<t,Ot)\mathrm{LLM}\left( \mathcal{H}_{<t}, O_t \right)
  4. 概率采样\(T_{t+1}\) 从模型输出的概率分布中采样得出，意味着下一步思考不是唯一确定的，保留了探索的余地。
    Tt+1∼⋯T_{t+1} \sim \cdots

5. ReAct 的局限与厨房瓶颈

再好的主厨也有翻车的时候，ReAct 不是万能钥匙。把它放回后厨，你会看到几类典型事故：第一，推理深度不足——对于需要十几步长链条的任务，模型经常在第五步就忘了第三步的结论，像主厨同时烧五个灶，顾此失彼；第二，历史遗忘——所有信息都堆在上下文里，有用信号被大量无关的“观察”淹没，像十道菜的半成品混在同一张料理台上，手忙脚乱。

第三，效率开销——每走一步都要调用一次大模型，就像每翻一次锅都要把主厨叫来开一次会，时间和成本同步飙升；第四，可靠性问题——单点推理一旦出错，错误会沿轨迹一路传导，一步错步步错，最后整桌菜都跑偏。这些问题不是 ReAct 的 bug，而是单循环范式的固有边界。

其中“错误累积”最能说明问题，它可以用一个简单的概率公式刻画：假设每一步的出错率是 \(e_t\)，那么所有步骤都幸运存活、整条轨迹不中断的概率，是各步成功率的连乘——步数越多，整体成功率掉得越快。

正是这些瓶颈，催生了后面的两大演进方向：多智能体协作和自主规划。没有人指望一个主厨单挑满汉全席——那就组个团队；也没有人指望走一步看一步能规划整季菜单——那就让 Agent 长出“全局视野”。

Etotal=1−∏t=1n(1−et)\displaystyle E_{\text{total}} = 1 - \prod_{t=1}^{n} \left( 1 - e_t \right)
总失败率等于“1 减去所有步骤都成功的概率”。如果每步 90% 不出错，连续五步后整体成功率只有约 59%——这就是长任务容易功亏一篑的数学本质。
  1. 单步出错率\(e_t\) 表示第 \(t\) 步推理或工具调用失败的概率，假设每步 10%，像主厨每道工序有十分之一的几率手抖。
    ete_t
  2. 单步成功率\((1 - e_t)\) 是这一步“没搞砸”的概率，即每道工序顺利完成的把握。
    (1−et)(1 - e_t)
  3. 连乘求全成功\(\prod\) 把所有步骤的成功率乘起来，得到整条链不中断的概率——任何一步断了，整道菜就废了。
    ∏t=1n(1−et)\prod_{t=1}^{n} \left( 1 - e_t \right)
  4. 求总失败率用 1 减去全成功概率，得到至少一步出错的总体概率；代入 5 步、每步 10% 出错率，约等于 41%。
    1−∏t=1n(1−et)1 - \prod_{t=1}^{n} \left( 1 - e_t \right)

6. 多智能体协作：后厨团队作战

满汉全席面前，一个主厨再厉害也会累垮。真实餐厅的解法是组建后厨团队：有人专门备菜，有人专门掌勺，有人专门摆盘，各司其职。多智能体（Multi-Agent）协作正是这个思路的 AI 版本——把 ReAct 的“个体循环”升级为“群体协作”，让每个 Agent 在自己的岗位上跑循环，再通过通信把成果拼起来。

多智能体协作有四个关键要素。角色分工：每个 Agent 有自己的提示词、工具集和职责边界，像切墩的不负责颠勺；消息通信：Agent 之间传递中间产出，像传菜口的一声“走菜”；任务分解：把总目标拆成可并行的子任务，像一桌菜拆成凉菜、热菜、汤品三线推进；冲突裁决：当各方意见不一致时要有收敛机制，像主厨拍板“听我的”。

这套协作在形式化层面可以写成：总任务等于若干子任务的并集，最终答案是所有子产出的某种聚合函数——无论是投票、仲裁还是顺序拼接，都脱不开这个结构。

当然，后厨团队也有代价：沟通有损耗、配合有摩擦。多智能体的工程难点正是设计“传菜铃和出菜单”——消息格式、同步机制、冲突仲裁——这些协议设计得越好，团队协作的效率就越高。

Task=⋃i=1kSubtaski,Answer=f(Out1,Out2,…,Outk)\displaystyle \text{Task} = \bigcup_{i=1}^{k} \text{Subtask}_i, \qquad \text{Answer} = f\left( \text{Out}_1, \text{Out}_2, \ldots, \text{Out}_k \right)
多智能体的本质是“分而治之 + 聚合收敛”：先把大任务拆给 k 个角色，再把 k 份产出汇成一个答案。协作协议的质量，决定了这桌菜能不能顺利上齐。
  1. 任务分解总任务被拆成 \(k\) 个互不重叠的子任务，像一桌宴席拆成备菜、掌勺、摆盘三个模块。
    Task=⋃i=1kSubtaski\text{Task} = \bigcup_{i=1}^{k} \text{Subtask}_i
  2. 各自产出每个智能体完成份内工作，产出一份结果 \(\text{Out}_i\)，像掌勺的端出红烧肉、备菜的备齐配料。
    Outi\text{Out}_i
  3. 聚合函数\(f\) 把各份产出聚合起来，可能是投票表决、争论仲裁或按顺序拼接，像传菜员按顺序把菜一道道端上桌。
    f(Out1,Out2,…,Outk)f\left( \text{Out}_1, \text{Out}_2, \ldots, \text{Out}_k \right)
  4. 最终答案聚合后的交付物，就是用户拿到的完整结果，像服务员面前那桌热气腾腾的宴席。
    Answer\text{Answer}

7. 自主规划：主厨的菜单蓝图

如果说 ReAct 是“接一单做一单”，那么自主规划就是“提前排好整季菜单”。真正的大厨不会每天临场发挥，他会在周初规划：周二的招牌菜需要周一的备料，周五的宴会要提前三天腌制。遇到突发情况，还能复盘调整——哪道菜被客人投诉了，下次改进。这种“长远眼光 + 自我修正”的能力，正是下一代 Agent 的方向。

自主规划趋势下，Agent 需要补强四类能力。长程规划：把最终目标拆成带依赖关系的子目标序列，像“先备料、再腌制、后烹调”；自我反思：像试菜后写下改进笔记，Agent 执行完一步会回头检查自己哪里做得不对；记忆机制：长期记忆与短期记忆分离，重要经验要能跨任务复用；世界模型：对环境的预判能力，像老主厨看一眼食材就知道它明天会是什么状态。

这套能力在决策科学里的标准表述是：在所有可能的策略中，寻找一个让“整段轨迹累计回报期望”最大的策略。从“被任务推着走”到“以目标为锚自主规划”，数学上就是从这个优化目标出发的。

值得强调的是：ReAct 是这一切的起点。没有“边做边看”的循环控制，规划拆出的子目标无人执行与验证；没有观察反馈，反思和纠错无从谈起；没有轨迹沉淀，记忆机制也无米下锅。自主规划不是抛弃 ReAct，而是站在 ReAct 肩膀上长出的大脑。

π∗=arg⁡max⁡π  Eτ∼π[∑t=1Hr(st,at)]\displaystyle \pi^{\ast} = \arg\max_{\pi} \; \mathbb{E}_{\tau \sim \pi} \left[ \sum_{t=1}^{H} r(s_t, a_t) \right]
自主规划要解决的是“长期收益最大化”：不是让当前这一步最舒服，而是让整条轨迹的累计回报最高。就像主厨不为一道菜将就，而为整季菜单布局。
  1. 策略\(\pi\) 是从环境状态到动作的完整决策规则，像主厨脑中“看到什么食材就怎么处理”的成熟套路。
    π\pi
  2. 轨迹展开\(\tau \sim \pi\) 表示按该策略执行得到的一连串状态与动作，像一整桌菜从备料到上桌的全程记录。
    τ∼π\tau \sim \pi
  3. 累计回报\(r(s_t, a_t)\) 是每步的好坏打分，\(\sum\) 把它们累加起来，像每道菜上桌后客人满意度的总和。
    ∑t=1Hr(st,at)\sum_{t=1}^{H} r(s_t, a_t)
  4. 最优策略\(\arg\max\) 在候选策略中找到期望回报最高的那一个，也就是最优的“整季菜单规划方案”。
    π∗=arg⁡max⁡πEτ∼π[⋅]\pi^{\ast} = \arg\max_{\pi} \mathbb{E}_{\tau \sim \pi}[\cdot]

8. 实践落地：把方法论搬回自家厨房

学完理论，回到你自己的小厨房（业务场景）该怎么下手？第一件事是克制：不是所有任务都适合 ReAct。如果任务一次问答就能答好、不需要外部信息、也不存在“做坏了要返工”的场景，硬上 ReAct 只会徒增延迟和成本——就像点个煎蛋也要惊动整个后厨。

第二，提示词设计要显式定义"Thought / Action / Observation"的交替格式，并且给出工具使用的示例，就像给新主厨一份带图示的菜谱，告诉他每一步输出什么。第三，工具链搭建决定观察质量——工具返回的数据是否干净、结构化，直接决定模型下一步推理的上限；一个返回一堆噪声的工具，等于给主厨端上一盆杂乱无章的食材。第四，评估迭代要有量化指标，用真实任务集持续度量。

衡量 Agent 质量最朴素的指标是成功率（Success Rate）：跑一百个任务，多少个完全做对了。这个数字是 Agent 迭代的“仪表盘”——低了，就回到提示词、工具、分解策略里找瓶颈。

落地的最优路径永远是“最小闭环”：先挑一个真实、高频、边界清晰的任务，用 ReAct 跑通端到端，测出成功率，再逐步扩张到更复杂的场景。像新主厨先学会一道拿手菜，再慢慢扩充菜单——而不是第一天就想包下整场婚宴。

SR=#成功轨迹#总轨迹\displaystyle \text{SR} = \frac{\#\text{成功轨迹}}{\#\text{总轨迹}}
成功率 = 成功轨迹数 ÷ 测试轨迹总数。它是 Agent 从“能跑”走向“好用”的核心标尺，每一次迭代都要盯着这个数字做对照实验。
  1. 总轨迹数分母是评测集里所有任务运行轨迹的总数，像一个月里接待的全部订单数。
    #总轨迹\#\text{总轨迹}
  2. 成功轨迹数分子是最终结果完全达标的轨迹数，像让客人满意而归的一道道菜。
    #成功轨迹\#\text{成功轨迹}
  3. 取比值两者相除得到成功率，衡量 Agent 整体质量的核心指标，也是优化迭代的基准线。
    SR=#成功轨迹#总轨迹\text{SR} = \frac{\#\text{成功轨迹}}{\#\text{总轨迹}}

AI 应用场景

智能客服工单处理

阶段：Agent 落地（推理-工具-反馈循环）

解决的问题：传统客服机器人只能做关键词匹配和 FAQ 检索，遇到“我的订单为什么还没发货？”这类需要查实时数据的问法就答非所问，动辄转人工。ReAct 式客服 Agent 先推理判断用户真实意图，再调用订单查询工具，观察返回的物流状态后组织成自然语言回答；若发现物流异常，继续推理是否需要升级处理或转接人工，形成完整闭环。

具体案例：某电商平台将售后机器人升级为 ReAct 流程后，用户询问退款进度时，Agent 依次调用“订单查询”“退款状态查询”两个工具，根据真实返回数据给出精确答复，人工转接率下降约 40%，用户等待时间从分钟级降到秒级。

自然语言数据问答助手

阶段：工具调用与推理交替（ReAct 直接应用）

解决的问题：业务同学想用自然语言问数据，传统方式要么排期等数仓写 SQL，要么套固定报表模板，灵活性差、时效性低。用 ReAct 搭建的数据问答 Agent，可以边推理边“查数”，并在拿到中间结果后决定是否需要二次查询。

具体案例：数据分析 Agent 收到“哪个大区的销售额连续三个月下滑”后，先推理出需要“大区维度 + 近三个月订单表”，调用 SQL 工具查出结果，观察返回数据后继续推理是否需要对比去年同期，最终产出一段带结论和图表引用的摘要，全程无需人工写 SQL。

智能运维告警排查

阶段：多步推理与多工具协作（ReAct 的进阶形态）

解决的问题：线上故障时，运维工程师要在海量日志和指标里人工定位根因，平均耗时长、压力大。ReAct Agent 能自动推理可疑点，交替调用日志检索、指标查询、配置检查等多个工具，像侦探一样逐步缩小范围，最终收敛到根因并执行恢复动作。

具体案例：某公司把告警响应接入 ReAct 流程后，Agent 收到“支付接口 P99 延迟飙升”告警，先查询最近变更记录，再检索异常日志，锁定某次发布引入的配置错误，自动触发回滚，全程约 3 分钟，而此前人工排查平均需要 40 分钟。

Python 演示

python103 行
#!/usr/bin/env python# -*- coding: utf-8 -*-"""最小 ReAct 智能体演示：推理-行动-观察循环""" import re  class ReActAgent:    """一个极简的 ReAct 智能体，由 LLM 模拟器 + 工具集组成"""     def __init__(self, llm, tools):        self.llm = llm          # 语言模型函数：接收提示词，返回回复        self.tools = tools      # 工具字典：名称 -> 可调用函数        self.history = []       # 保存 (thought, observation) 历史     def _build_prompt(self, question, history):        lines = [            "你是一个能推理并调用工具回答问题的智能体。",            "可用工具：" + "、".join(self.tools.keys()),            "输出格式：先写 Thought: 你的推理，再写 Action: 工具名(参数) 或 Final: 答案",            "问题：" + question,        ]        for thought, observation in history:            lines.append("Thought: " + thought)            lines.append("Observation: " + observation)        return "\n".join(lines)     def think(self, question):        """生成一步推理（Thought）"""        prompt = self._build_prompt(question, self.history)        return self.llm(prompt).strip()     def act(self, text):        """从模型输出中解析出工具调用"""        match = re.search(r"Action:\s*(\w+)\(([^)]*)\)", text)        if not match:            return None, None        name = match.group(1)        args_text = match.group(2).strip()        args = []        if args_text:            for part in args_text.split(","):                part = part.strip()                if part.isdigit():                    args.append(int(part))                else:                    try:                        args.append(float(part))                    except ValueError:                        args.append(part)        return name, args     def observe(self, name, args):        """执行工具，返回观察结果"""        func = self.tools.get(name)        if func is None:            return "错误：没有名为 " + name + " 的工具"        try:            return str(func(*args))        except Exception as exc:            return "工具执行失败：" + str(exc)     def run(self, question, max_steps=5):        """运行 ReAct 循环，直到模型给出 Final 答案或达到步数上限"""        for _index in range(max_steps):            output = self.think(question)            print("Thought: " + output.split("\n")[0])            name, args = self.act(output)            if name is None:                final_match = re.search(r"Final:\s*(.+)", output)                return final_match.group(1) if final_match else output            observation = self.observe(name, args)            print("Action: " + name + " " + str(args))            print("Observation: " + observation)            self.history.append((output, observation))        return "达到最大步数，未得到确定答案"  def add(a, b):    """加法工具"""    return a + b  def multiply(a, b):    """乘法工具"""    return a * b  def fake_llm(prompt):    """模拟的大模型：根据提示词内容决定下一步输出"""    if "Observation: 20" in prompt:        return "Thought: 乘法结果 20 就是答案。\nFinal: (2+3) 乘以 4 等于 20"    if "Observation: 5" in prompt:        return "Thought: 加法结果是 5，接下来乘以 4。\nAction: multiply(5, 4)"    if "2+3" in prompt:        return "Thought: 需要先计算括号里的 2+3。\nAction: add(2, 3)"    return "Thought: 先调用加法工具。\nAction: add(0, 0)"  if __name__ == "__main__":    agent = ReActAgent(llm=fake_llm, tools={"add": add, "multiply": multiply})    answer = agent.run("计算 (2+3) 乘以 4 等于多少？")    print("最终答案：" + answer)
目的：用 100 行不到的代码实现一个完整的 ReAct 循环——模型先思考、再行动、观察结果、继续思考，直到输出最终答案，直观展示“边想边做”的核心机制。
  1. self.history = []用列表保存每轮（思维，观察）记录，这是 Agent 的短期记忆，供下一轮推理参考，像主厨的品控日志越写越厚。
  2. def _build_prompt(self, question, history):把问题、工具清单和历史轨迹拼成提示词，相当于把“菜谱 + 品控日志”同时摆到主厨面前。
  3. return self.llm(prompt).strip()调用底层大模型生成一步推理，模拟“主厨思考”这个脑内过程。
  4. match = re.search(r"Action:\s*(\w+)\(([^)]*)\)", text)用正则从模型输出里抽出“行动”字段：工具名和参数，像从主厨的话里听出他要动哪个锅。
  5. func = self.tools.get(name)根据工具名查表获取真实函数，找不到就返回错误观察，防止 Agent 乱调不存在的工具。
  6. return str(func(*args))真正执行工具并取回结果，这个结果会成为下一轮的 Observation，是“环境给模型的回执”。
  7. self.history.append((output, observation))把每一步的思维与观察写回历史，形成循环闭环，下一轮 prompt 里就能看到它。
  8. final_match = re.search(r"Final:\s*(.+)", output)模型不输出 Action 而输出 Final，说明它认为信息已足够，循环可以终止，像主厨喊一声“出锅”。
  9. for _index in range(max_steps):设置最大步数上限，防止 Agent 陷入死循环空转，像给主厨一个“最晚出菜时间”。

常见误区

误区“ReAct 不就是让模型'多想想'吗？在提示词里加一句'请一步一步思考'，效果应该差不多。”

正解ReAct 的关键不在于“多想”，而在于“想一步、做一步、看一步”——其中的 Observation 来自真实环境（工具返回值），不是模型自己编的。只加“逐步思考”的提示词没有引入外部反馈，推理链条断了也无人纠正，就像主厨闭着眼颠勺，颠得再久也不知道菜炒糊没有。

为何常见：因为 ChatGPT 时代的思维链提示词（Chain-of-Thought）也是“让模型多想一步”，两者在字面上都有“推理”二字，很容易被混为一谈。

误区“我的模型已经接了搜索和计算器 API，这不就是 Agent 了吗？”

正解工具调用只是 Agent 的“手”。智能体的核心在于有明确目标、能根据环境反馈循环决策、自主决定下一步调用哪个工具以及何时停止。如果只是按固定脚本调一次 API 就返回，那是自动化的流水线，不是 Agent——就像厨房里一台只会自动开烤箱的机器，算不上主厨。

为何常见：很多 Agent 产品在演示时都突出“它能调工具”，镜头语言强化了“工具调用即智能”的错觉。

误区“ReAct 这么强，把任何任务丢给它都能做好。”

正解ReAct 擅长的是“需要多步信息获取与反馈”的任务，比如查资料、调接口、逐步计算。但面对需要几十步长程推理、需要大量历史记忆、或工具反馈噪声很大的任务，单循环 ReAct 会出错累积、遗忘前文、开销剧增。就像让一个主厨独自承办百人婚宴，他再厉害也会手忙脚乱。

为何常见：看到 ReAct 在 HotpotQA、ALFWorld 等基准上大幅提升，容易高估它的泛化上限，忽略了这些任务的步数其实都相对有限。

误区“多智能体协作？那我把我那个 Agent 多部署几个实例，让它们一起跑，是不是就成了？”

正解多智能体的价值不在“数量多”，而在“角色异质”——不同 Agent 有不同职责、工具和提示词，通过消息通信交换中间结果，并对冲突进行裁决。复制 N 个一模一样的 Agent 只会得到 N 份同样的错误，就像雇十个手艺相同、习惯相同的厨师，菜品不会因此更丰富。

为何常见：分布式系统里“多副本”是常见的高可用手段，这个“多=好”的直觉被误搬到了多智能体上，忽略了异质分工才是协作的前提。

误区“为了让 Agent 记得住，我把所有历史对话和观察结果都塞进上下文，这样它肯定更聪明。”

正解上下文窗口有物理上限，且无关信息会稀释有效信号——LLM 的注意力同样会被噪声分散。ReAct 的局限之一正是“历史遗忘”，工业界的解法是用显式记忆机制（摘要、向量检索、关键信息提炼）管理历史，而不是无脑堆积。就像主厨不会把十道菜的原料全堆在同一张案板上，而是分门别类放好，需要时再取。

为何常见：字面上“信息越多推理越准”很有道理，忽视了模型注意力与上下文窗口的物理限制，属于直觉胜过实证的典型误区。

面试题

Q1. ReAct 中的 "Re" 对应下面的哪个英文单词？

单选题 · easy

  • A.Retrieve（检索）
  • B.Reasoning（推理）← 正确答案
  • C.Reward（奖励）
  • D.Reflection（反思）

答案：B。ReAct 是 Reasoning + Acting 的合成词，强调推理与行动交替。Retrieve 是 RAG 的 R，Reward 是强化学习的核心概念，Reflection 是反思类 Agent 的关键词——三者都因首字母相同容易混淆，但只有 Reasoning 才是 ReAct 的"Re"。

Q2. 一个完整的 ReAct 循环，正确的交替顺序是？

单选题 · easy

  • A.行动 → 观察 → 推理
  • B.推理 → 行动 → 观察← 正确答案
  • C.观察 → 行动 → 推理
  • D.推理 → 观察 → 行动

答案：B。ReAct 的标准顺序是先推理再行动，行动触发环境反馈形成观察，观察又作为下一步推理的依据。C 选项把观察放在最前，缺少行动触发的前提；D 选项把观察放在行动之前，逻辑上不通；A 选项虽然循环自洽，但打破了“推理先行”的原则。

Q3. 相比一次性大模型调用，ReAct 最核心的改进是什么？

单选题 · mid

  • A.模型参数规模显著增大
  • B.环境反馈能够进入后续推理← 正确答案
  • C.提示词长度不再受限
  • D.完全不需要任何人工设计

答案：B。ReAct 让模型基于真实环境反馈（工具返回值）修正下一步判断，这是它区别于单次调用的根本点。参数规模、提示词长度都不是范式层面的改进；D 选项过于绝对，工具设计和提示词格式仍需人工参与，ReAct 只是让“反馈闭环”成为可能。

Q4. Observation（观察）在 ReAct 中的核心作用是什么？

单选题 · mid

  • A.保存训练数据供模型微调
  • B.把真实世界信息送回推理← 正确答案
  • C.替代 Thought 完成最终作答
  • D.压缩上下文以节省计算

答案：B。观察是行动触发的环境回执，它进入下一轮提示词，成为推理的事实依据。它不是训练数据、不替代思考、也不以压缩上下文为目的。观察的本质是“真实世界的回流信息”，这正是 ReAct 抑制幻觉、让决策落地的基础。

Q5. ReAct 能抑制幻觉的主要机制是什么？

单选题 · mid

  • A.模型经过了更多轮微调
  • B.外部工具结果提供事实锚点← 正确答案
  • C.推理步数减少导致出错率低
  • D.输出长度被严格限制截断

答案：B。ReAct 每次生成前都有真实工具结果作为上下文约束，模型“凭空编造”的空间被压缩，工具返回值就像事实锚点。微调、缩短输出都不是 ReAct 引入的机制；减少推理步数反而可能缺失必要信息，与抑制幻觉没有因果关系。

Q6. 多智能体协作主要弥补了单智能体的哪类短板？

单选题 · hard

  • A.复杂任务难以由单点完成分解← 正确答案
  • B.单模型推理速度太慢的瓶颈
  • C.单卡显存容量不足的限制
  • D.训练数据质量不高的缺陷

答案：A。多智能体的核心价值是任务分解与角色分工，让擅长不同环节的 Agent 各司其职，避免单个 Agent 包揽一切导致推理链条过长而崩溃。速度、显存、数据质量都不是多智能体范式直接解决的工程问题，它解决的是“单点能力与复杂任务不匹配”的结构性短板。

Q7. 下列哪一项不属于智能体四元组的组成？

单选题 · easy

  • A.目标 Goal
  • B.观察 Observation
  • C.行动 Action
  • D.参数 Parameter← 正确答案

答案：D。智能体的四元组是目标、观察、行动、记忆，分别回答“要什么、看到什么、能做什么、记得什么”。参数是模型自身的权重，属于底层模型的一部分，不属于智能体的结构组成。这道题考察的是对 Agent 定义边界的清晰认知。

Q8. 下列哪些是 ReAct 范式当前的已知局限？

多选题 · mid

  • A.多步推理后错误逐步累积← 正确答案
  • B.每一步都调用模型开销偏高← 正确答案
  • C.长程任务依赖额外的记忆机制← 正确答案
  • D.工具调用结果必定准确无误

答案：ABC。A 对应错误累积公式——步数越多整体成功率越低；B 是效率问题，每步一次模型调用导致成本与延迟上升；C 是历史遗忘问题，长任务需要显式记忆机制补强。D 只是理想假设，现实中工具返回也可能出错，ReAct 并不保证工具结果准确，选项过于绝对。

Q9. 从单次问答到多智能体，范式演进的关键变化包括哪些？

多选题 · mid

  • A.从被动应答转向主动规划← 正确答案
  • B.从无环境反馈转向反馈迭代← 正确答案
  • C.从单角色转向多角色分工← 正确答案
  • D.从文本生成转向图像生成

答案：ABC。演进的主线是主动性增强（被动应答→主动规划）、反馈闭环引入（无反馈→基于观察迭代）、以及协作分工出现（单角色→多角色）。生成模态（文本还是图像）不是这条范式的核心变化维度，D 属于无关干扰项。

Q10. 面向自主规划趋势，Agent 需要重点补强的能力有哪些？

多选题 · hard

  • A.长程规划与子目标拆解← 正确答案
  • B.自我反思与错误修正← 正确答案
  • C.持久记忆与世界模型← 正确答案
  • D.更复杂的提示词模板

答案：ABC。自主规划要求 Agent 能拆解长程目标、在执行中反思纠错、并借助持久记忆与世界模型预判环境变化，这正是“从走一步看一步到全局掌控”的能力跃迁。提示词模板只是工程实现手段，不是能力层面的补强方向，D 属于把工具当本质的典型误判。