AI SDK 代理循环：证明其停止原因

AI SDK 代理循环不能仅因返回了结果就被视为健康。返回证明一个控制流路径已结束：模型在没有其他工具调用的情况下完成、工具无法执行、需要批准或触发配置的停止条件。这些事实都不能证明发票已创建、票证已更新或报告已到达目的地。 实际的默认设置是保留 SDK 的有界循环，记录一个显式停止原因，并单独验证预期的外部结果。将批准请求视为等待，将步骤或预算上限视为有界止损，将没有结果收据的自然完成视为错误完成。 本指南将行为固定到已发布的 [email protected] 封装和 Node.js 22.23.1。随附的无内容重播在十一个操作案例中执行了实际导出的停止条件功能。所有 11 个分类和 4 个直接 SDK 断言均已通过。 SDK 可能会因多种合法原因而停止 这 AI SDK回路控制指南 列出了四种终止路线： 1. 模型返回 tool calls 以外的完成原因； 2. 被调用的工具没有 execute 函数； 3. 工具调用需要批准； 4. 配置的停止条件返回 true。 这些路由不应折叠到一个 completed: true 字段中。它们意味着不同的操作员操作。 自然的非工具完成对于研究答案来说可能是完全有效的，但对于合同需要对象存储中的文件的工作流程来说是不完整的。没有 execute 的工具可以故意充当结构化 done 信号，但该信号包含模型声称的内容，而不是副作用成功的独立证据。批准请求是有意的暂停。阶梯上限意味着安全边界有效，而不是任务失败或成功。 当前文档称 ToolLoopAgent 默认为 isStepCount(20) 。将其替换为 isLoopFinished() 可消除步数停止条件。这对于严格控制的本地实验来说是合理的，但它也消除了模型调用和成本的简单限制。如果应用程序无法解释其独立的截止日期、预算和取消控制，则保留默认上限是更安全的决定。 三个小实施细节改变了诊断 版本固定 停止条件源 足够短，可以直接审计： isStepCount(n) 仅在 steps.length === n 时为真，而不是在计数大于或等于 n 时为真。 hasToolCall(name) 检查最近完成的步骤中的工具调用。 isLoopFinished() 始终返回 false 作为停止条件，留下自然终止、未执行的工具或批准结束循环。 这些语义在重建事件时很重要。假设应用程序仅保留最终文本和总步数。在第二步中调用 done 的三步运行稍后无法证明 hasToolCall("done") 导致终止，因为相关条件会检查最后一步。同样，对 21 个步骤的观察并没有表明 isStepCount(20) 被触发；这是配置的策略、记录的计数或运行边界与假设不同的证据。 运行时保留条件输入和选定的策略版本。不要事后从仪表板推断它们。 在选择健康状态之前建立停止收据 有用的收据很小。它不需要提示、模型响应或原始工具负载： stopCause 应该来自整合边界，而不是基于最终散文的猜测。记录运行是否达到非工具完成、匹配指定的停止条件、发出批准请求、调用未执行的完成工具、中止、超时或工具执行失败。 然后应用优先规则： 证据 状态 运营商决策 工具执行失败 FAILED 诊断刀具边界；不要盲目重试不确定的副作用。 正在等待所有者、截止日期和恢复令牌的批准 WAITING 路由决策并保持可恢复性。 正在等待批准，没有路由数据 WAITING UNROUTED 在等待变得不可见之前添加所有者和升级路径。 超时已过，没有任何有用的进展 STUCK 检查最后一个持久进度并选择一个有限恢复。 步骤、令牌或用户中止绑定已触发 BOUNDED STOP 保留部分工作；决定新的有界运行是否合理。 自然完成或明确的 done 加上结果收据 VERIFIED COMPLETE 关闭运行。 自然完成或明确的 done ，无结果收据 FALSE COMPLETE 验证目的地或重新启动任务。 信号不一致或未记录原因 UNCERTAIN 行动前先询问。 顺序很重要。即使步数恰好等于四，第四步的超时仍然是超时。批准请求应该保持等待状态，而不是陷入一般的不完整状态。没有可交付成果的自然完成应该保持错误完成，即使其文本听起来很自信。 重放策略而不调用模型 审计导入了已发布的 isStepCount 、 hasToolCall 、 isLoopFinished 函数。它传递已完成步骤记录的无内容数组，并将其输出连接到收据分类器。不需要模型调用、提示、秘密或外部工具效果。 四个断言确立了 SDK 边界： 然后，十一个案例的固定装置涵盖了有和没有结果的自然完成、有和没有结果的 done 、步骤上限、代币预算、路由和未路由批准、工具错误、超时和用户中止。这对揭示真相的配对并不是奇特的失败。两种自然光洁度装置具有相同的控制流原因；只有带有目的地收据的那张变成了 VERIFIED COMPLETE 。 done 工具也出现了相同的分裂。 这是核心可证伪的结果：如果循环终止本身被证明是有用的完成，那么那些配对的装置应该得到相同的健康结论。他们没有。 控制流停止后验证目的地 这 ToolLoopAgent 参考 公开生成结果的已完成步骤并接受 abortSignal 和超时控制。这些字段是有用的证据，但应用程序仍然拥有成功的定义。 选择能够满足用户实际请求的最便宜的确定性检查： 对于文件，验证预期的路径或对象密钥、内容类型、大小下限以及特定于任务的哈希或模式； 对于数据库突变，读取目标记录并比较预期字段； 对于消息，保留提供者收据和目的地身份； 对于部署，验证不可变版本、公共卫生响应和面向用户的路线； 对于分析，在接受散文之前验证所需的部分、源代码覆盖范围和机器可读的输出。 不要将结果收据作为模型断言的第二个副本。同一循环发出的 {"status":"done"} 不是独立验证的。当结果无法通过代码安全检查时，收据应来自目的地、确定性验证器或人为决定。 批准也需要一个单独的边界。 SDK 文档显示，可以收集批准请求，将其作为批准响应附加到对话中，然后传递到后续调用中。从操作上来说，这意味着等待必须保留足够的上下文才能恢复相同的决策。没有恢复令牌的所有者创建手动重建工作；没有所有者的令牌会创建一个不可见的队列。 这个重播并没有证明什么 该实验没有调用提供者模型、流式传输部分输出或执行外部工具。因此，它不会建立特定于提供商的结束原因行为、网络取消计时或副作用幂等性。这些属于围绕实际模型、工具和目标的集成测试。 它还不建议采用一种通用步骤或令牌限制。四步查找和四十步迁移具有不同的范围。操作要求是所选界限是明确的、记录的，并且在达到时与安全操作相关联。 该规则更窄且更持久：保留循环停止的原因，保持合法等待与失败不同，并在声明有用的完成之前需要目标证据。 Sidewisp 是一个 AI 代理健康平台，旨在使证据、等待状态、有限恢复和结果验证更容易在现有运行时进行检查。生产代理健康采集和 AI SDK 监控目前一般不发货。 Sidewisp 目前处于私密预览阶段。 如果此终止收据与您自己的代理中的故障模式匹配，则私人预览等待列表是共享您所需的运行时和证据边界的适当位置。