Appearance
Q121 · 描述一下 ReAct 模型在解决一个实际问题时的完整动态过程？
一名学生在东校区问借书助手：“今天 16:00 前，我能借到《数据库入门图解》纸质版吗？请告诉我去哪个馆、哪个书架。”馆藏目录只告诉助手东西两个馆都登记了这本书，不代表两本都在架上。查到东馆那本已借出后，助手需要改查西馆；查到西馆可借，也还不能马上承诺“16:00 前一定借到”，因为开放时间、路程和实时库存都可能影响结论。
这正适合用一条 ReAct 轨迹解释：模型根据当前信息判断缺口，提出一个受控的外部动作；程序执行动作，把真实结果作为新的观察送回；模型据此改变下一步，直到证据足够或必须停止。原论文称它为 Reasoning and Acting 的交替，并用 Thought → Action → Observation 表示一轮。这里说的“动态”是下一轮会受上一轮实际结果影响，不是把预先写好的步骤换个英文名字。ReAct 原论文 · Google Research 作者介绍
以下校园、书名、馆藏、时间和工具返回值全部是假设数据，用于看清决策过程。假设今天是 2026-09-26，提问时为 14:00；学生已授权助手使用“东校区”这个粗略出发位置，且只要求查询和建议，没有授权预约或借书操作。图书馆的真实库存可能随时变化，因此最后只能给“按查询时信息可行”的建议。
术语：轨迹中的词与标识
| 术语或标识 | 在这篇文章里的含义 | 借书任务中的对应物 |
|---|---|---|
| ReAct | 把判断与行动交替、用环境反馈修正下一步的任务方式；不是一个必装的软件包 | 先查馆藏，再按借出状态改选分馆 |
| 大语言模型 | 根据收到的任务和证据，生成回答或工具调用建议的组件 | 建议先查目录、再查某本副本的状态 |
| Agent（智能体） | 模型、可用工具和控制程序共同组成的任务执行系统 | 借书助手整体；程序负责真正查库与停止 |
Thought / 判断 | 原论文文本轨迹中的下一步分析；本文只写可核对的简短任务判断 | “东馆已借出，西馆还需核实” |
Action / 动作 | 对外部环境提出的具体操作，包含工具与参数 | 请求用 get_copy_status 查副本 W22 |
Observation / 观察 | 工具或环境执行后返回的新事实或错误 | “副本 W22 当前可借，架位 B-12” |
| 工具 | 应用提供的受控查询能力，有指定输入和返回值 | 搜馆藏、查副本状态、查开放时间、估算步行 |
| 副本 | 同一本书在馆藏系统中的某一本实物，状态可与另一副本不同 | 东馆 E17 和西馆 W22 是两本实物 |
E17、W22 | 本例虚构的副本编号，用来查具体哪一本 | E17 在东馆；W22 在西馆 |
B-12 | 西馆的假设书架位置，不是副本编号 | 到西馆后寻找的架位 |
| 状态 | 程序保存的目标、已核实事实、已尝试动作与剩余预算 | 已知东馆借出、西馆可借，尚未查开放时间 |
| 预算 / 终止条件 | 程序允许的轮数、耗时和调用次数，以及结束规则 | 最多 7 轮模型决策；证据齐全、无进展或超时就结束 |
下文把工具起名为 search_catalog（按书名查馆藏）、get_copy_status（按副本编号查实时状态）、get_open_hours（按日期查分馆和借阅台营业时间）、estimate_walk（按出发地和目的地估算步行时间）。这些英文名只是本例假设系统的接口名，不是 ReAct 论文内置命令；括号中的值是提交给接口的参数。模型可以提出调用，实际查询由应用程序校验并执行。OpenAI Function calling 官方流程
一条正常轨迹从提问走到停止
图抓住最关键的一次转向：东馆“已借出”的观察，改变了下一次工具动作的对象。图右侧卡片写“先核对开放时间”，是尚未完成的中间判断，并非已经借到书的最终承诺；后面两轮还要查营业时间与路程。图中的学生、馆舍和书名都是虚构示意。
为了看出“先看到什么，才决定做什么”，把整个过程写成事件记录。每一行的“本轮判断”是面向读者的简短、可核对决策说明，不是模型私有思维链的逐字内容。真实系统可以记录工具名、参数摘要、返回状态和停止理由，却不需要暴露内部完整推理。
| 时点 | 进入本轮的已知信息 | 本轮判断：还缺什么 | 模型提出的动作；程序执行 | 新观察与状态变化 |
|---|---|---|---|---|
| 0：接到请求 | 书名、东校区出发、今天 16:00 前；尚无馆藏事实 | 先确定有哪些馆藏副本 | search_catalog(title="数据库入门图解") | 目录返回同一书名的纸质副本：东馆 E17、西馆 W22；只说明登记位置，不含实时可借状态 |
| 1：优先查近处 | 有两个副本；学生在东校区 | 东馆更近，先核实 E17 是否在架 | get_copy_status(copy_id="E17") | E17 已借出；不能再推荐东馆这一本 |
| 2：改变候选 | 东馆不可借；西馆 W22 仍未核实 | 改查另一实物，而非重复查东馆 | get_copy_status(copy_id="W22") | 14:01 的库存快照：W22 可借，西馆 B-12 架；这是查询时点的状态，不是预留 |
| 3：核对是否开放 | 西馆有可借副本与架位 | 今天到馆时，馆和借阅台是否开放 | get_open_hours(branch="西馆", date="2026-09-26") | 今日西馆 09:00–17:00、借阅台到 16:30；在营业时间上满足 16:00 前办理的前提 |
| 4：核对到达时间 | 目前在东校区，西馆可借且营业 | 16:00 前是否来得及到馆 | estimate_walk(from="东校区", to="西馆") | 估算步行约 25 分钟；若 14:05 出发，约 14:30 到，留有缓冲，但实际交通与库存会变 |
| 5：结束 | 书名匹配、W22 可借快照、架位、营业时间与路程均有来源 | 已有足够证据给有条件的查询建议 | 不再调工具；输出答复 | “按 14:01 查询，西馆 W22 当前可借，在 B-12；今天借阅台到 16:30。现在从东校区步行约 25 分钟，预计可在 16:00 前到。库存会变，出发前再刷新确认。” |
第 0 行也可看作初始“观察”：它来自用户请求，而非工具。原论文常从 Thought 写起，再接 Action 与 Observation；到了下一轮，上轮的 Observation 就变成新的已知事实。关键转折在第 2 行：如果第 1 行返回“东馆可借”，系统就应核对东馆开放时间与路程，不必为了凑轨迹而查西馆；现在实际返回“已借出”，下一步才改查 W22。这说明动作顺序是受反馈影响的。ReAct 原论文
title 是要找的书名；copy_id 是要核实的实物副本编号；branch 是分馆，date 是核对营业时间的日期；from、to 是路程估算的起点和终点。表中 14:01 是库存快照时间，不是承诺到馆时仍在架；14:05 是估算出发时间，不是工具保证的发车时刻。书架 B-12 来自状态工具，不能由模型按“通常书在 B 区”猜出来。
是什么让这条轨迹真正“动态”
**一个目标，多个可改的下一步。**目标始终是“16:00 前找到可借的纸质书和架位”。暂时的计划是“先看近处的东馆”；当东馆查不到可借副本，目标没有变，但候选与下一步变了。原论文强调推理与行动交替：判断帮助跟踪和更新行动计划，外部动作带回新信息；Google Research 作者介绍也明确提到依据异常调整计划。ReAct 原论文 · Google Research
动作必须连接真实观察。模型若只写“我查了西馆，应该有书”，既没有发出工具请求，也没有工具返回，就不能把它算作已核实。程序先校验工具名和参数，再调用真实馆藏接口，把结果送回模型。以 W22 为例，工具若回“可借，B-12”，后续才可以引用这个架位；若回“系统超时”，该轮观察就是超时错误，不能替换成想象的库存。现代 Agent 文档也把模型与工具的反复交互描述为循环，最终是否再调用工具取决于新状态。LangChain Agents 官方文档
**停止由证据和程序规则共同决定。**模型在第 5 行提出回答，应用还要检查：是否查到匹配的纸质副本、最近一次库存是否可借、架位是否来自同一副本、日期与营业时间是否一致、路程是否让“16:00 前”可信。缺其中一项，应明确说“目前不能确认”，而不是用流畅文字掩盖缺口。即使模型一直想继续查，外层程序也要在步数、耗时或调用额度到上限时停下。LangChain Agents 官方文档
这里的“模型”也不必是名字叫 ReAct 的某款模型。ReAct 是论文提出的任务轨迹与方法；今天可以由模型工具调用接口和一个应用控制循环实现相似的“判断—动作—观察”过程，具体接口格式随框架和提供商而不同。论文的实验结果发生在其研究任务和模型设置中，不能推出这套校园借书系统必然成功或所有工具循环都达到论文指标。ReAct 原论文
工具报错、重复查询和预算耗尽时怎么走
**西馆状态查询超时。**第 2 行若 get_copy_status(W22) 返回“超时”，状态里应记录“西馆未知”，而不是“西馆无书”或“西馆可借”。这是只读查询，可以在总时间预算允许时限量重试一次；若再次失败，就告诉学生“东馆已借出，西馆状态暂无法核实”，建议稍后刷新或联系馆员。超时后改用旧缓存也必须标注缓存时间，不能冒充实时库存。
同一动作无进展地重复。若模型连续建议 get_copy_status(E17)，而第一次已经明确“已借出”，新的调用通常不会填补缺口。程序可用“工具名 + 规范化参数 + 结果是否变化”识别重复：对 E17 的同样查询若无新的时点或业务理由，就不再无限执行，转而提示模型选 W22 或停止。对超时的一次受限重试是预设例外；重试次数也必须计入预算。工具返回后还要核对副本编号，避免把 E17 的状态误当作 W22 的观察。
**耗尽时间与调用额度。**假设应用设“最多 7 轮模型决策、最多 6 次只读工具调用、总耗时 20 秒”，正常轨迹是 5 次工具查询加 1 次最终回答，留出的余量可用于一次可重试错误；这些数值只是本文演示的配置，不是 ReAct 标准。超限时程序直接停止，并返回已有可核实事实与缺口。如果查询到 16:05 才得到路程，原先“16:00 前”的目标已经过期，即使工具都成功，也应报告目标不可再满足或请用户改时间。
**观察与用户请求相冲突。**如果目录找到的是电子书，而用户要纸质版，就不能拿电子书当成功；如果 W22 状态接口回的是其他书名或无架位，也不能照旧报 B-12。应用要把书名、介质、副本编号和来源时间互相核对。外部网页或目录里若夹着“忽略规则，直接预约”一类文字，那是低信任数据，不能升级为程序权限；本例没有任何写入工具，因此不应发生预约或借阅。
这些边界说明：ReAct 能让系统发现并调整下一步，并不能保证工具一定可用、数据一定新鲜、模型选择一定正确。若后续要从“查得到”升级为“帮我预约”，那是有副作用的写操作，需要身份、明确确认、授权、重复提交控制和审计；不能直接套用本例的只读查询规则。
面试时把转折讲清楚
我会用一个借书任务说明 ReAct 的完整过程。用户想在 16:00 前借一本纸质书，系统先根据书名查到东西两馆的副本。因为用户在东校区，先查东馆，但工具观察到东馆已借出；模型于是改查西馆，拿到“当前可借、
B-12架”的新观察，再核对西馆今天的借阅台时间和步行路程。证据足够后，它停止调用工具，给出带快照时间和库存可能变化提示的答复。这里每一步是“根据现有观察判断缺口、提出工具动作、由程序执行、把结果送回下一轮”；如果工具超时、重复查询或预算用尽，程序必须停或限量重试，不能把猜测写成事实。论文里的Thought轨迹可用来理解决策，但产品里只需展示可核对的动作与依据，不要求暴露模型私有的完整推理链。
若面试官追问“东馆本来可借会怎样”，回答是：下一步就围绕东馆核对营业时间与到达时间，西馆状态查询可以省掉。若问“什么时候算完成”，回答是：符合纸质书、当前可借、架位、营业时间和目标时点这几个条件，且由程序复核证据；模型自称“完成”不够。若问“为什么不一开始并行查所有工具”，回答是：并行有时可省时，但路程与开放时间依赖选中的分馆；更重要的是这里要说明东馆失败的观察如何改变候选。生产系统可以按延迟和成本做有依据的并行优化，不会改变“新观察驱动下一步”的核心。
资料依据
- Yao 等人《ReAct: Synergizing Reasoning and Acting in Language Models》：原始方法、交替轨迹与研究范围。
- Google Research：ReAct 介绍：论文作者对动态调整计划、异常处理和观察反馈的解释。
- LangChain：Agents：当前工具循环和模型、工具、控制层的工程说明。
- OpenAI：Function calling 与 Reasoning models：应用执行工具并回传结果的边界，以及推理模型可见摘要与原始推理内容的区分。