
假设你问个人资料助手：

> 帮我查一下保存的读书会通知，报名截止日期是哪天？如果有调整，以调整后的通知为准。

助手有两个工具：“搜索通知”用于查找资料，“读取通知”用于取得某份资料的全文。模型根据问题提出工具请求，程序检查后执行，再把结果交给模型。

如果只有两份短通知，搜索时直接返回全文，就可能足够回答。现在换成资料较多、文件较长的情况：搜索先返回编号、标题和简短摘要，需要了解细节时，再按编号读取正文。

这样，第一次搜索完成以后，任务还没有结束。模型需要先看到找到了哪些通知，再决定读哪一份；读完之后，还要判断能否回答，或者是否需要继续查。

**要让助手接着做，程序需要把每次执行的真实结果送回下一次判断。** “判断—行动—观察”的循环，就从这条反馈关系开始。

## 1. 下一步需要什么，可能要做完这一步才知道

先约定本次任务的范围：只根据当前用户获准访问的已保存通知回答，不查询报名系统的实时状态。两项工具也只读资料，不修改通知。

下面是一条用于解释流程的假设路径。本次搜索在约定范围内已查完，共找到 D1、D2 两份通知，属于同一主办方、同一场读书会；表中动作是设计示例。

| 本轮已有的信息 | 模型可提出的下一步 | 程序执行后取得的信息 |
| --- | --- | --- |
| 用户要核对报名截止日期，尚未取得通知 | 搜索“读书会 报名” | 找到 D1《读书会报名通知》和 D2《读书会报名时间调整通知》，附编号、发布日期和摘要 |
| 搜索结果中有一份调整通知，但还没读到完整修改内容 | 读取 D2 | 正文写明：“本次读书会报名截止日期提前到2026年9月18日，原通知中的截止日期作废。” |
| 已取得 D2 的完整修改说明，且确认对应用户问的活动 | 给出有依据的回答 | 不再执行工具，向用户呈现答案 |

这时可以回答：

> 按查到的 D2《读书会报名时间调整通知》，报名截止日期已提前到 2026 年 9 月 18 日，原通知中的日期作废。

第一轮结束时，新增的是“找到了哪些资料”；第二轮结束时，新增的是“调整通知具体改了什么”。这些变化分别解决不同缺口，才使任务能够走到回答。

模型可以在最初就提出“先搜索，再读调整通知”的计划，但 D2 的编号和具体内容仍要等执行后才能取得。计划描述的是准备做什么，下一步操作所用的资料标识和回答依据，则应来自实际返回。

## 2. 程序怎样把一次调用接成循环

为便于看清回路，这里每轮只处理一个工具请求。程序每次将当前问题、工具说明和已有结果交给模型，接收一个下一步动作；执行并取得反馈后，再发起下一次模型请求。

```mermaid
flowchart TD
    A[用户问题与已有记录] --> B{程序检查是否仍允许继续}
    B -- 可以 --> C[模型根据当前信息选择下一步]
    B -- 达到上限 --> H[结束本次处理并说明进度与限制]
    C -- 请求工具 --> D[程序校验请求并执行允许的操作]
    D --> E[取得实际结果或明确的拒绝与失败信息]
    E --> F[保存调用与对应结果，加入后续输入]
    F --> B
    C -- 回答、补问或说明限制 --> G[向用户回复，结束本次处理]
```

沿着这张图看，三个动作各有具体含义：

- **判断**：模型根据用户目标和当前依据，提出下一步需要做什么。例如读 D2，或者说明现有信息不足。
- **行动**：程序检查工具名称、参数和权限，执行允许的操作。模型提出“读取 D2”以后，仍要由程序真正读取。
- **观察**：程序把执行得到的内容带回，模型在后续请求中据此重新判断。这里的“观察”包括成功取得的正文，也包括未找到、拒绝访问或读取失败。

关键连接点是图中的回路：工具结果进入后续输入，下一次判断才能利用它。给同一个模型连续发三次请求，如果每次都只有原问题，新的查询结果没有带入，就没有建立这条反馈关系。

程序还要提供明确出口。这个小助手可以先设置模型请求次数上限，并为模型调用和工具执行设定超时，防止重复查询或等待一直持续；达到上限时，报告已完成什么、还缺什么。模型选择回复用户，也只表示本次处理告一段落：补问意味着还在等信息，给出答案则仍需要核对是否有依据。

## 3. 下一轮必须知道“为什么查”和“查到了什么”

假设读取 D2 成功，程序下一次只把通知正文发给模型。模型虽然看到了日期，却可能缺少原问题，不知道用户问的是报名截止日、通知发布日期，还是当前能否报名。

相反，如果程序只保留原问题，没有加入 D2 的结果，下一轮又缺少刚刚取得的依据。

所以，最小循环需要持续保留一份与当前任务有关的记录。对于前面的路径，这份记录可以按发生顺序组织为：

```text
用户问题：核对保存的读书会通知中的报名截止日期，有调整则采用调整后的通知。

第 1 次工具请求：搜索“读书会 报名”。
对应结果：找到 D1、D2，附各自的标题、发布日期和摘要。

第 2 次工具请求：读取 D2。
对应结果：D2 的完整正文，说明截止日期提前到 2026 年 9 月 18 日，原日期作废。
```

这是记录内容的示意，不是某个接口要求的消息格式。实际使用时，应按接口约定保存模型返回的调用项，并把工具结果对应到原来的调用。这样才能辨认某份结果属于哪一次搜索或读取。

组织输入时，先保留稳定的任务规则和工具说明，再放本次用户问题，已经发生的调用与结果随进展追加。模型下一次能使用哪些信息，取决于程序实际传入了什么，或接口按约定续接了什么。程序在本地执行过一个函数，并不会自动让下一次模型请求知道结果。

失败也需要进入这份记录。例如，D2 读取超时，程序应带回“读取 D2 超时，未取得正文”。模型此时只能知道有一份调整通知，不能据标题猜出调整后的日期。如果允许再次尝试，可以提出重读；如果无法继续，就应说明仍未核实修改内容。

从这条失败分支可以看出，循环并不是每轮都离成功更近。它让后续判断得到最新情况，也可能让系统及时发现当前任务无法继续。

## 4. ReAct 怎样把判断、行动和反馈连起来

[ReAct 研究项目](https://react-lm.github.io/)将推理与行动交替组织：模型结合当前情况生成推理文字和下一步动作，外部环境执行动作并返回观察结果，再供后续判断使用。

作者公开的问答实现中，这个过程有明确的程序对应关系。其 [HotpotQA 示例代码](https://github.com/ysymyth/ReAct/blob/6bdb3a1fd38b8188fc7ba4102969fe483df8fdc9/hotpotqa.ipynb)每轮先让模型生成推理文字和动作，并在准备生成观察结果的位置停止；随后由程序执行动作，取得环境返回，再把这一步的动作与真实观察追加到后续输入。

这解释了为什么工具反馈必须经过程序：搜索返回了什么，由搜索执行结果决定。模型生成的文字不能直接充当“这次已经查到的内容”。

作者编写的[提示示例](https://github.com/ysymyth/ReAct/blob/6bdb3a1fd38b8188fc7ba4102969fe483df8fdc9/prompts/prompts_naive.json)展示了一次调整动作的过程：搜索 `High Plains` 后，反馈指出这个名称可能指向不同地区，于是下一步改为更明确的 `High Plains (United States)`。新的搜索条件来自刚得到的歧义信息。这是用于向模型示范的轨迹，说明了反馈怎样影响动作选择；它本身不代表任意模型都能稳定完成同样的判断。

原始 ReAct 方案显式使用了推理文字。理解更一般的工具循环时，还可以直接观察模型提出了什么请求、程序执行了什么、返回了什么，以及下一步如何变化。这样的调用记录足以检查反馈有没有传回、动作是否有依据；不需要把可见的解释文字当作模型全部内部推理的记录。

## 5. 什么情况下值得让模型每轮重新判断

回看“搜索通知—读取 D2—回答”这条顺利路径，普通程序也可以安排相同的步骤。资料关系和处理规则足够稳定时，固定流程容易检查，也能减少中间的模型请求。

让模型每轮选择动作，更适合下一步取决于当时取得的内容，而且这些分支难以提前列全的任务。例如，通知正文引用了另一份补充说明，需要继续核对；搜索结果出现同名活动，需要判断是否先补问；读取失败后，需要结合已有依据决定能回答到哪里。

这种灵活性也有成本：每增加一次判断，通常会增加一次模型请求的等待和费用，传入的任务记录也会占用更多词元(Token)。模型还可能选择无关资料，或者反复执行没有进展的搜索。因此，应让每次新动作对应一个具体缺口，并由程序控制允许继续的范围。

可以用三个变化检验自己是否理解了循环：

- **搜索已经返回两份通知的完整正文，修改关系也很明确，还要再读取 D2 吗？** 如果没有新的核对需求，就不必增加这一步。动作是否需要，取决于还缺什么依据。
- **读取 D2 失败，下一轮却仍然收到一份“读取成功”的旧结果，会怎样？** 模型可能沿旧情况继续回答。需要核对结果与调用的对应关系，并准确带回本次失败，循环才能反映当前进展。
- **连续两次用同样条件搜索，都得到相同的空结果，还能因为“需要继续判断”而一直查吗？** 如果没有新的信息、条件或暂时故障可供处理，重复执行缺少继续的理由；程序应限制次数，并让助手说明当前范围内未找到。

一个有用的循环，让每次行动取得的事实改变后续判断：有了充分依据就回答，出现新缺口就选择相应动作，条件不允许时就停止并说明。判断、执行和反馈之间的连接是否真实、完整，决定了多次调用能否共同推进同一个任务。


助手有两个工具：“搜索通知”用于查找资料，“读取通知”用于取得某份资料的全文。模型根据问题提出工具请求，程序检查后执行，再把结果交给模型。

工具调用 5｜执行一次还不够：怎样形成“判断—行动—观察”的循环？

人工智能

工具循环通过“判断-行动-观察”反馈机制驱动多步任务：模型先搜索获取通知列表，再读取调整通知正文，最终确定报名截止日期提前至2026年9月18日。程序将每次执行结果传入后续请求，确保决策基于真实反馈，并设置请求上限和超时防止循环失控。

代码解释

ReAct 

Solid

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

工具调用 5｜执行一次还不够：怎样形成“判断—行动—观察”的循环？-腾讯云开发者社区-腾讯云

工具调用 5｜执行一次还不够：怎样形成“判断—行动—观察”的循环？

工具调用 5｜执行一次还不够：怎样形成“判断—行动—观察”的循环？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐