
假设你问个人资料助手：

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

助手可以搜索通知、读取正文。每次工具执行后，程序把结果交给模型，让模型决定继续查，还是给出回答。

找到第一份写着截止日期的通知，就能停了吗？如果搜索结果里还有一份“报名时间调整通知”，现在回答就可能漏掉修改。反过来，调整内容和适用对象已经核对清楚，再把相同资料读一遍，也没有增加回答所需的依据。

因此，停止条件要同时回答两个问题：**什么情况下已经可以交付，什么情况下即使没完成也应该结束本次执行？** 用户需要知道自己拿到了答案，还是只拿到了当前进展。

## 1. 是否完成，要看用户要的结果有没有依据

先明确这次任务的范围：根据当前用户获准访问的已保存通知核对日期，不查询报名系统的实时状态。

假设搜索已经覆盖约定的资料范围，共找到同一场读书会的两份通知。D1 是原通知，写着 9 月 20 日截止；D2 是调整通知，完整正文写着：

> 本次读书会报名截止日期提前到2026年9月18日，原通知中的截止日期作废。

对于这个问题，完成需要有几项相互关联的依据：通知对应用户问的活动；D2 明确修改了原日期；答案采用修改后的日期，并能指出出处。约定范围内如果还有未读的相关更新或没有解决的冲突，就还缺少核对。

这些条件满足以后，可以交付：

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

这里的“完成”有明确边界。回答保存通知中的截止日期，不要求顺便证明报名系统现在仍然开放；用户没有提出这个问题，也没有提供相应的查询条件。把任务扩展为“直到确定一切相关信息才停”，会让完成标准不断后移。

程序可以直接检查一些条件，例如引用的通知是否实际读取过、出处编号是否存在、回答中是否包含日期。通知是不是同一场活动、修改是否适用，则需要理解内容。模型可以参与判断，开发者仍需用包含同名活动、日期冲突等情况的样本检查它的可靠性。仅仅返回了一个“已完成”标记，不能替代这些依据。

## 2. 下一步补不上缺口时，要结束当前的自动执行

未完成，不一定意味着应该继续调用工具。先看缺少的信息从哪里才能得到。

假设搜索找到了两个主办方的读书会，用户只说了“读书会”，现有资料也无法确定他指哪一场。读取更多通知可能会让助手更了解这两场活动，却未必能知道用户想问哪一场。此时适合补问：

> 找到了青禾书店和市图书馆的两场读书会，你想查哪一场？

这次自动执行到这里就可以结束，等用户回复后再继续处理。系统应记录“等待用户确定活动”，不能记录为“截止日期已核实”。如果问题和已有对话已经能明确活动，就没有必要再问一遍。

另外一些缺口来自当前能力的限制：

- **资料没有访问权限。** 应说明当前无法读取，等待授权条件发生变化。重复请求同一份资料不会补上权限。
- **在约定范围和搜索条件下没有找到通知。** 如果还有合理的关键词或已获准访问的来源，可以继续查；这些办法已经用尽时，应说明查找范围和结果。
- **资料服务暂时失败。** 在允许的次数和时间内，可以尝试恢复；达到限制以后，应带着失败原因结束。

判断是否值得继续，可以落到一个具体问题：**下一次动作准备补哪个缺口，为什么有机会取得新信息？**

相同关键词、相同范围连续返回相同的空结果，而条件没有变化，就缺少再次搜索的理由。但动作重复本身不能直接证明没有进展：读取下一页是在获取新内容，暂时故障后的重试也可能有意义。需要一起看执行条件和实际返回，不能只数工具名称出现了几次。

## 3. 次数、时间和费用上限，各自限制一种消耗

即使下一步看起来有理由，程序也不能无限执行。模型可能一直认为“再查一次就够了”，单次请求也可能迟迟没有返回。因此，需要由程序设置执行上限。

下面是一组用于说明区别的假设配置，具体数值要根据任务调整：

| 限制什么 | 示例约定 | 为什么需要单独限制 |
| --- | --- | --- |
| 执行次数 | 模型请求最多 6 次，工具调用最多 4 次 | 防止反复判断、反复查询；两种调用分别计数，避免漏算 |
| 等待时间 | 整个任务最多 45 秒，单次调用最多 15 秒 | 次数很少也可能等待很久；每次都没超时，也可能累计超过用户能接受的时间 |
| 费用 | 为一次任务设置费用预算 | 同样的调用次数，输入长度、输出长度及付费工具不同，花费也可能不同 |

### 次数：限制的是实际执行，计数范围要说清

“最多执行 6 轮”还不够明确。一轮如果包含一次模型请求和两个工具调用，就已经发生了三次不同的操作。格式纠正、故障重试、最后一次整理回答，也可能增加模型请求。

这个小助手可以分别统计模型请求和工具调用，并把失败尝试、重试都算进对应上限。是否还允许发起下一次操作，应在执行前检查，不能执行完才发现已经超过次数。

### 时间：单次超时要服从整个任务的剩余时间

假设任务已经用掉 42 秒，总上限是 45 秒。即使单次调用允许 15 秒，接下来也只剩 3 秒可用，不能重新给它一份完整的 15 秒。

总时间应从本次处理开始累计，包括模型等待、工具执行和重试间隔。只在每轮结束后查看时间，无法约束一项一直没有返回的请求；调用本身也需要相应的超时或取消机制。

停止等待与远端停止执行还可能是两件事。是否能取消已经发出的请求，要看服务支持什么，不能据本地超时就认定远端没有产生费用。

### 费用：下一次操作要在发起前纳入预算

如果任务只剩 0.20 元预算，而下一次操作可能花费 0.30 元，等它完成后再统计，已经无法守住预算。

因此，需要结合输入规模、最大输出长度和服务的计费规则，为下一次调用预留费用；付费工具也应计入。词元(Token)用量可以帮助估算模型费用，但词元(Token)数量本身不等于金额，不同计费项目的价格可能不同。

调用完成后，再按服务返回的实际用量及计费规则更新记录。超时或失败时如果没有用量信息，应保留“费用待核实”，不能直接按零费用处理。如果服务无法提供可靠的费用上界，这套控制只能视为估算和预警，不能承诺精确封顶。

次数、时间和费用控制的是不同事情，不能相互替代。具体保留哪些限制，取决于任务会消耗什么；一旦配置了这些限制，开始下一次操作就必须同时满足它们。

## 4. 公开实现怎样区分“结束”与“答对”

[ReAct 的公开问答示例](https://github.com/ysymyth/ReAct/blob/6bdb3a1fd38b8188fc7ba4102969fe483df8fdc9/hotpotqa.ipynb)提供了一个具体对照。它让模型搜索、查找资料，也允许模型提交 `Finish[answer]`，表示给出答案并结束。

这段实现同时保留了由程序控制的出口：主循环最多执行 7 步；如果循环结束时仍未收到结束结果，程序会执行 `finish[]`，以空答案结束这一轮。这个限制让运行不会仅仅因为模型还想继续，就一直增加步骤。7 是该示例采用的数值，并不是所有任务的推荐值。

代码里还有一个容易忽略的细节：如果模型输出不符合预期格式，程序可能再次请求模型补出动作。因此，最多 7 个循环步骤，并不等于最多 7 次模型请求。要限制真实调用数量，就要把这样的额外请求也算进去。

“结束”也没有被当成“答对”。[环境执行代码](https://github.com/ysymyth/ReAct/blob/6bdb3a1fd38b8188fc7ba4102969fe483df8fdc9/wikienv.py)收到结束动作后记录答案并设置结束标志；[问答评估代码](https://github.com/ysymyth/ReAct/blob/6bdb3a1fd38b8188fc7ba4102969fe483df8fdc9/wrappers.py)再拿答案与参考答案比较，单独计算结果。

这个设计说明了两个独立的判断：运行是否已经结束，以及交出的答案是否满足要求。资料助手通常没有一份预先给定的标准答案，就需要回到任务约定，核对资料、修改关系和出处。循环的结束标志只负责表达执行状态。

## 5. 停下以后，要交代这次拿到了什么

停止规则最终需要落到程序行为上：执行前检查是否还允许发起操作；执行后保存实际结果、更新消耗，再决定交付、补问、继续或结束。模型可以建议下一步，程序负责落实已经约定的限制。

达到上限时，也要区分已有结果的状态。如果完整答案及出处已经取得并通过检查，仍然可以交付，不能因为计数恰好到顶，就把成功结果改成失败。如果还缺关键依据，就说明缺口。

例如，程序已经读到 D1 的旧日期，但 D2 的正文读取超时，且本次执行时间已用尽。合适的交付应保留这项限制：

> 原通知 D1 写的是 9 月 20 日截止。我还找到了 D2《读书会报名时间调整通知》，但正文读取超时，本次未能核实调整后的日期。可以稍后重新读取 D2，或由你提供这份通知的正文。

这段说明让用户知道已经查到什么、为什么还不能确定，以及什么条件变化后可以继续。旧日期没有被包装成最终结论，已经完成的查找也没有被一句“失败了”抹掉。

如果还要请求模型整理这段说明，这次请求同样占用次数、时间和费用。可以提前为收尾留出预算；预算已经耗尽时，则由程序根据保存的事实生成简短状态说明，不能为了报告停止而无条件再增加一次调用。

可以用三个变化检查停止条件是否合理：

- **用户只问“D1 原通知写的日期是什么”，完整 D1 已经读取，还必须查完所有更新吗？** 不需要为这个问题扩展搜索。可以回答 D1 原文，并明确这是原通知中的日期。
- **模型已经写出“核对完成”，但记录里只有 D2 的标题，没有正文，能按成功结束吗？** 不能据此认定完成。还需要核对修改内容；无法继续时，应说明依据不足。
- **最后一次允许的调用已经返回完整、可交付的答案和出处，还要因为次数用尽而报错吗？** 不必。上限阻止的是新增调用，已有结果仍然可以检查和交付。

助手什么时候该停，取决于任务的完成依据、尚缺信息的来源，以及继续执行的条件。让每次结束都能说明自己属于哪种情况，用户才知道可以采用结果，还是需要补充信息、等待恢复或调整任务范围。


助手可以搜索通知、读取正文。每次工具执行后，程序把结果交给模型，让模型决定继续查，还是给出回答。

工具调用 6｜助手什么时候该停下来？

人工智能

回答：根据已保存的《读书会报名时间调整通知》，报名截止日期已提前至2026年9月18日，原通知9月20日截止作废。

ReAct 

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

工具调用 6｜助手什么时候该停下来？-腾讯云开发者社区-腾讯云

工具调用 6｜助手什么时候该停下来？

工具调用 6｜助手什么时候该停下来？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐