面试题 · Prompt
搜索「成本」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
ReAct（Reasoning + Acting）框架结合了推理与外部操作。请解释其核心思想，并分析相比单纯的提示工程（prompting），它为何能在复杂任务（如问答、决策）中取得更优表现。
ReAct 将任务决策、工具行动和外部观察交织成有界循环：
Decision → Action → Observation → Decision → ...模型根据当前状态选择搜索、计算或业务 API 等行动，读取真实返回，再决定继续、改路或停止。生产系统无需向用户暴露隐藏思维链；应记录可审计的行动、参数、观察摘要、状态变化和最终依据。
| 维度 | 直接提示、单次生成 | ReAct 工具循环 |
|---|---|---|
| 外部信息 | 只能使用请求中给出的上下文和模型参数知识 | 可以查询当前数据或执行工具 |
| 分支处理 | 适合路径清楚、一次即可完成的任务 | 可根据工具结果调整下一步 |
按学习路线查看教程、项目和面试题。
| 成本与延迟 | 通常较低、行为更容易限定 | 多次模型和工具调用，成本与失败面更大 |
| 可审计性 | 可记录输入与最终输出 | 还可记录行动、观察和状态迁移 |
ReAct 更适合依赖动态事实、外部执行或多步条件分支的任务。例如退款处理需要查询订单状态、读取当前政策、计算金额，再依据每步结果决定是否继续。这里的收益来自真实工具结果和反馈闭环，而不是“多想几步”本身。
直接提示在静态问答、改写、分类和路径固定的短任务中通常更简单、更快。若所需证据已放进上下文，或流程能用确定性代码表达，引入 Agent 循环可能只会增加延迟、成本和不确定性。
ReAct 不保证比直接提示更准确。搜索可能召回错误资料，工具可能超时，模型可能误读观察、重复调用或在提示注入下越权。落地时应设置工具白名单与最小权限、参数校验、幂等键、超时和有限重试、最大步数、停止条件与人工兜底。
选型要在同一任务集上比较任务成功率、事实或执行正确率、工具错误恢复率、平均步骤、P95 延迟、成本和越权率。只有目标任务上的证据能说明 ReAct 是否值得使用；简单任务直接调用更好，多步任务也可能更适合固定工作流或 Plan-and-Execute。
场景切入
假设你在做一个智能客服，用户问“帮我查一下上周的订单”，模型直接答可能编造信息。如果让你设计一个方案，让模型能自己决定去查数据库再回答，你怎么做？
层层追问
你平时用提示词让模型回答复杂问题，效果怎么样？……如果问题需要查实时数据或做多步计算，纯提示词容易出错吧？……那你怎么让模型能一边推理一边调用工具，还能根据结果调整思路？
直球架构
请解释ReAct框架的核心思想，它如何将推理和行动交织在一起？对比纯提示工程，它在信息获取、错误修正和可解释性上有什么本质优势？
ReAct 的核心不是让模型把完整思维过程展示出来，而是让系统在决策、工具行动和外部观察之间形成有界循环。模型根据当前状态选择搜索、计算或业务接口，读取返回，再决定继续、改路还是停止。生产系统应记录行动、参数、观察摘要、状态变化和最终依据，没必要向用户暴露隐藏思维链。
选型时我先看任务是否真的依赖外部事实或动态分支。静态问答、改写、分类，或者所需证据已经放进上下文时，单次提示通常更简单、更快。退款处理则可能要查订单状态、读取当前政策、计算金额，并根据每一步结果决定是否继续，这类任务才有工具反馈循环的价值。即便步骤很多，如果路径稳定、规则明确，确定性工作流也可能比自由 Agent 更可靠。
ReAct 不能天然减少幻觉。搜索可能召回错误资料，工具可能超时，模型会误读观察、重复调用，也可能被工具返回里的提示注入诱导。业务接口还涉及对象权限和真实副作用。因此服务端要限制工具白名单与最小权限，校验参数，给写操作配置幂等键和确认边界，并设置超时、有限重试、最大步数、停止条件与人工兜底。
我也不会把 ReAct 直接等同于 Agent。它是一种工具循环范式；Plan-and-Execute、固定状态机或多 Agent 协作是其他组织方式。选择哪种结构，要看任务分解、恢复、审计和风险需求。
最后必须用同一任务集比较。除了最终答案，还要看事实或执行正确率、工具错误恢复率、平均步骤、P95 延迟、成本和越权率。只有这些证据能说明 ReAct 是否值得引入；简单任务不需要为了“更智能”而增加循环。