## 题目 2：ReAct 是什么？它和 CoT 有什么区别？

### 题目分类
- 方向：AI Agent 架构与设计模式

### 考察点
- 能否准确解释 ReAct 通过 Reasoning 与 Acting 交替，让模型依据环境反馈持续修正任务状态
- 能否讲清 Reason、Action、Observation 各自由谁产生，以及模型与 Agent Runtime 的责任边界
- 能否从信息来源、执行能力、反馈机制、适用任务和成本风险等维度区分 ReAct 与 CoT
- 能否说明 ReAct 不是“CoT 后面加一个工具调用”，而是由观察结果驱动下一轮决策的闭环
- 能否识别工具选择错误、参数错误、观察污染、循环失控、重复副作用和推理文本泄露等生产风险
- 能否根据任务是否需要外部信息或改变环境，选择直接回答、CoT、固定 Workflow 或 ReAct Agent

### 知识讲解
#### 1. ReAct 是什么
ReAct 来自 Reasoning and Acting，核心做法是让模型的推理与外部行动交替发生。模型先根据当前目标和已知信息判断下一步，产生一个 Action；Agent Runtime 解析并执行这个 Action，把工具或环境返回的结果作为 Observation 交还给模型；模型再根据新信息继续判断，直到得到答案、完成任务或触发停止条件。

它解决的是纯语言推理的一个根本限制：模型只能基于当前上下文继续生成，遇到未知事实时容易猜，遇到外部任务时又不能只靠文字改变真实环境。ReAct 让模型可以主动搜索资料、查询数据库、调用 API、读取文件或操作业务系统，并用真实反馈修正原来的计划。

原始论文常用 `Thought → Action → Observation` 表示一轮轨迹。生产系统不一定需要向用户展示完整 Thought，也不应把自然语言推理当作执行协议。更常见的实现是让模型返回结构化工具调用，由 Runtime 负责参数校验、权限检查、执行、记录和结果回传。

#### 2. 一轮 ReAct 怎样运行
假设用户问：“上海明天会下雨吗？如果会，帮我把户外会议改到线上。”模型现有上下文里没有可靠的明日天气，先选择天气查询工具。Runtime 执行后返回降雨概率，这就是 Observation。模型根据观察结果判断是否满足改会条件，再请求日历工具修改会议。Runtime 校验用户权限、会议 ID 和幂等键后执行，最后把修改结果交还给模型组织回复。

这个过程里，Reason 负责判断当前缺什么信息、下一步目标是什么；Action 是结构化的工具意图；Observation 是环境返回的事实或执行结果。真正调用 API 的不是模型，而是宿主程序。Observation 也不是天然可信的，网页内容可能包含提示注入，工具可能超时，数据可能过期，因此回传前还需要清洗、标记来源和限制长度。

#### 3. ReAct 和 CoT 的本质区别
CoT 主要扩展模型在一次生成中的推理过程。它把复杂问题拆成中间步骤，但这些步骤通常仍然基于模型已有参数和当前上下文，不会自动获得新事实，也不会真的执行外部动作。它更像在纸上展开计算过程。

ReAct 则把“思考”和“与环境交互”交错起来。每次 Action 都可能带回新的 Observation，后续判断基于更新后的世界状态，而不是沿着最初的假设一直推下去。它更像一边处理任务，一边查资料、运行命令并检查结果。

两者不是互斥关系。ReAct 中的 Reason 可以使用多步推理，CoT 也可以作为 ReAct 的局部能力；真正的区别在于有没有外部 Action，以及 Observation 是否会反馈到下一轮决策。只生成一份工具调用计划却不读取执行结果，不构成完整的 ReAct 闭环。

图解：左侧展示 CoT 如何在已有上下文中单向展开；右侧用“查询天气后修改会议”的具体轨迹展示 Observation 如何带回新事实并修正下一步。

![image.png](https://developer.qcloudimg.com/http-save/yehe-8338883/ac4705a92d59a9441bff4c324ae54f1a.png)

#### 4. 什么时候选哪一种
问题所需信息已经在上下文里，只需要多步计算、逻辑推导或方案比较时，CoT 或结构化分解通常足够。任务步骤固定、规则明确、每一步都可预先编排时，固定 Workflow 往往比 ReAct 更稳定，例如“上传文件后依次解析、校验、入库和通知”。

任务需要在运行时决定查什么、调用哪个工具，且下一步依赖上一步真实结果时，ReAct 更合适。例如开放式研究、跨系统排障、动态信息查询、代码修改与测试，以及无法预先穷举路径的多工具任务。

简单查询没有必要启用多轮 Agent，直接调用确定性 API 更便宜。涉及付款、删除、发信、发布和权限变更等高风险动作时，也不能让 ReAct 自由执行；需要白名单、参数校验、审批、幂等、限额和可回滚机制。判断原则不是任务“看起来像 Agent”，而是是否真的需要模型根据环境反馈动态选择下一步。

#### 5. 生产实现的关键控制
Runtime 要为每次循环维护明确状态，包括用户目标、已完成步骤、工具结果、剩余预算和终止原因。系统必须限制最大轮数、总 token、工具次数和执行时间，并识别无进展循环，例如模型反复用相同参数调用同一个工具。

工具层需要 schema 校验、权限控制、超时、重试和幂等。读操作与写操作应分级，产生副作用的动作尽量先生成预览，再由用户确认。工具结果应保留来源、时间和错误类型，不能把失败响应伪装成普通 Observation 继续推理。

可观测性不能只记录最终回答。至少要记录每轮工具选择、参数校验结果、执行耗时、Observation 摘要、状态变化、停止原因和人工介入点。评估除了最终任务成功率，还应看工具选择正确率、参数正确率、平均轮数、无效调用率、循环率、失败恢复率、端到端延迟和成本。

### 面试回答
ReAct 是 Reasoning and Acting 的组合，它让模型一边判断下一步，一边调用外部工具，并根据工具返回的 Observation 继续修正决策。典型过程是一轮 `Reason → Action → Observation`，循环到任务完成或满足停止条件。

它和 CoT 的差别不只是“能不能调工具”。CoT 主要是在当前上下文里展开中间推理步骤，适合计算、逻辑和方案分析；ReAct 会真正与外部环境交互，获得新事实或改变系统状态，而且每次观察结果都会影响下一步。ReAct 可以在 Reason 阶段使用 CoT，所以两者更像包含关系，而不是两个完全独立的方案。

实现时模型只负责给出结构化的工具意图，Agent Runtime 才负责校验参数、检查权限、执行工具并把结果回传。原始 ReAct 轨迹里虽然有 Thought，但生产系统没有必要向用户暴露完整推理文本。真正需要记录的是工具调用、输入输出、状态变化和停止原因，这些才是可审计的执行证据。

选择上，如果信息已经齐全，只需要多步推导，用 CoT 或结构化分解就够了；步骤固定时优先用 Workflow；只有当下一步需要根据外部结果动态决定时，才值得用 ReAct。它带来的代价是更多轮模型调用、更高延迟和成本，以及工具误用、提示注入、循环失控和重复副作用等风险。

生产里会限制最大轮数、时间和 token 预算，对写操作增加审批与幂等，监控工具选择正确率、无效调用率、循环率、任务成功率和失败恢复率。ReAct 的价值不在于让 Agent 多想几轮，而在于让决策能被真实环境反馈纠正，同时让执行过程保持可控。

### 面试官追问
1. ReAct 中的 Reason、Action 和 Observation 分别由谁产生？
2. 为什么模型返回 tool call 不代表工具已经执行？
3. ReAct 与 Plan-and-Execute 有什么区别？
4. 什么情况下固定 Workflow 比 ReAct 更合适？
5. 如何防止 Agent 重复调用同一个工具形成死循环？
6. 工具返回内容为什么可能带来 Prompt Injection？
7. 写操作如何处理审批、幂等和回滚？
8. 怎样评估一个 ReAct Agent 的效果，而不是只看最终回答？

### 高分回答要点
- 能说明 ReAct 是推理、行动和观察交替发生的反馈闭环
- 能划清模型负责决策、Runtime 负责校验和执行的边界
- 能从信息来源、环境交互和反馈机制解释其与 CoT 的本质区别
- 能根据任务动态性选择直接调用、CoT、Workflow 或 ReAct
- 能覆盖循环预算、工具安全、提示注入、副作用和失败恢复
- 能提出任务、工具、轨迹、成本和延迟等多层评估指标

### 常见扣分回答
- 只说 ReAct 是“思考加工具调用”，没有解释 Observation 如何改变下一步
- 认为模型自己执行了 API 或业务代码，忽略 Agent Runtime
- 把 ReAct 和 CoT 说成互斥方案，不知道 ReAct 的 Reason 可包含多步推理
- 所有任务都套 ReAct，没有比较直接调用和固定 Workflow
- 只设置最大轮数，没有处理重复副作用、权限和提示注入
- 只记录最终答案，不记录工具轨迹、状态变化和停止原因

### 项目结合话术
需要根据外部结果动态推进的任务会采用 ReAct，但模型只负责选择下一步工具并生成结构化参数。Runtime 统一完成 schema 校验、权限、超时、幂等和结果回传；查询类工具可以自动执行，写操作先生成预览并等待确认。每轮保留工具轨迹、状态变化和停止原因，同时限制轮数、时间与 token 预算，用任务成功率、无效调用率、循环率和失败恢复率判断这套 Agent 是否真的比固定 Workflow 更合适。

### 参考来源
- [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629)
- [Chain-of-Thought Prompting Elicits Reasoning in Large Language Models](https://arxiv.org/abs/2201.11903)

能否准确解释 ReAct 通过 Reasoning 与 Acting 交替，让模型依据环境反馈持续修正任务状态

2026AI面试题-ReAct和CoT

人工智能

前端

ReAct是推理与行动交替的反馈闭环，模型生成结构化工具调用，AgentRuntime负责执行并回传Observation，驱动下一轮决策。它区别于CoT的关键在于：CoT仅扩展上下文内推理，不获取新事实；ReAct则通过环境反馈修正计划。适用于需动态决策的外部任务，但需控制轮数、权限和副作用。

数据库

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

2026AI面试题-ReAct和CoT-腾讯云开发者社区-腾讯云

2026AI面试题-ReAct和CoT

2026AI面试题-ReAct和CoT

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐