AI SDK エージェント ループ: 停止した理由を証明する

AI SDK エージェント ループは、単に戻っただけでは正常ではありません。戻り値は、1 つの制御フロー パスが終了したことを証明します。つまり、モデルが別のツール呼び出しなしで終了した、ツールが実行できなかった、承認が必要だった、構成された停止条件が発動した、などです。これらの事実はいずれも、請求書が作成されたこと、チケットが更新されたこと、またはレポートが目的地に到着したことを証明するものではありません。 実際のデフォルトでは、SDK の制限付きループを保持し、1 つの明示的な停止原因を記録し、意図した外部結果を個別に検証します。承認リクエストは待機中として、ステップまたは予算の上限は制限付きストップとして、結果の受信なしの自然終了は誤った完了として扱います。 このガイドでは、リリースされた [email protected] パッケージおよび Node.js 22.23.1 の動作を固定します。付随するコンテンツなしの再生では、11 の運用ケースにわたって実際にエクスポートされた停止条件関数が実行されました。 11 の分類と 4 つの直接 SDK アサーションがすべて合格しました。 SDK はいくつかの正当な理由で停止する可能性があります の AI SDK ループ制御ガイド 4 つの終端ルートに名前を付けます。 1. モデルは tool calls 以外の終了理由を返します。 2. 呼び出されたツールには execute 関数がありません。 3. ツール呼び出しには承認が必要です。 4. 設定された停止条件は true を返します。 これらのルートは 1 つの completed: true フィールドにまとめてはいけません。これらは、さまざまなオペレーターのアクションを意味します。 ツールを使用しない自然な仕上げは、研究の答えとしては完全に有効ですが、オブジェクト ストレージ内のファイルを必要とする契約のワークフローにとっては不完全です。 execute を持たないツールは、構造化された done 信号として意図的に動作できますが、その信号には、モデルが主張した内容が含まれており、副作用が成功したという独立した証拠は含まれていません。承認リクエストは意図的な一時停止です。ステップ キャップは、タスクが失敗したか成功したかを意味するのではなく、安全境界が機能したことを意味します。 現在のドキュメントには、 ToolLoopAgent のデフォルトは isStepCount(20) であると記載されています。これを isLoopFinished() に置き換えると、歩数カウントの停止条件が削除されます。これは、厳密に制御されたローカル実験では合理的ですが、モデル呼び出しとコストに対する単純な制限も取り除きます。アプリケーションが独自の期限、予算、およびキャンセル制御を説明できない場合は、デフォルトの上限を維持することがより安全な決定です。 3 つの小さな実装の詳細が診断を変える 固定されたバージョン ストップコンディションソース 直接監査するには十分短いです。 isStepCount(n) は、 steps.length === n の場合に true になり、カウントが n 以上の場合ではありません。 hasToolCall(name) は、最後に完了したステップのツール呼び出しを検査します。 isLoopFinished() は停止条件として常に false を返し、自然終了、未実行のツール、またはループ終了の承認を残します。 これらのセマンティクスは、インシデントを再構築するときに重要です。アプリケーションが最終テキストと合計ステップ数のみを保持するとします。関連する条件によって最後のステップがチェックされるため、2 番目のステップで done を呼び出した 3 ステップの実行では、後で hasToolCall("done") が終了の原因となったことを証明することはできません。同様に、21 ステップの観察では、 isStepCount(20) が発火したことは示されません。これは、設定されたポリシー、記録された数、または実行境界が想定と異なるという証拠です。 条件入力と選択したポリシーのバージョンを実行時に保持します。事後的にダッシュボードから推測しないでください。 健全性状態を選択する前に停止レシートを作成する 役に立つレシートは少額です。プロンプト、モデルの応答、未加工のツール ペイロードは必要ありません。 stopCause は、最終的な散文に基づく推測ではなく、統合境界から得られる必要があります。実行がツール以外の終了に達したか、指定された停止条件に一致したか、承認リクエストを発行したか、未実行の完了ツールを呼び出したか、中止されたか、タイムアウトしたか、ツールの実行に失敗したかどうかを記録します。 次に、優先順位ルールを適用します。 証拠 州 オペレーターの判断 ツールの実行に失敗しました FAILED 工具境界を診断します。不確実な副作用を盲目的に再試行しないでください。 承認は所有者、期限、再開トークンとともに保留中です WAITING 決定をルーティングし、再開可能性を維持します。 データをルーティングせずに承認が保留中です WAITING UNROUTED 待機が表示されなくなる前に、所有者とエスカレーション パスを追加します。 有効な進捗が得られないままタイムアウトになりました STUCK 最後の永続的な進行状況を検査し、限定された回復を 1 つ選択します。 ステップ、トークン、またはユーザー中止境界が起動される BOUNDED STOP 部分的な作業を保存します。新しい制限された実行が正当化されるかどうかを決定します。 自然な仕上がりまたは明示的な done と結果の領収書 VERIFIED COMPLETE 実行を閉じます。 自然な仕上がりまたは結果の受領書なしの明示的な done FALSE COMPLETE 宛先を確認するか、タスクを再度開きます。 信号が一致しない、または原因が記録されていない UNCERTAIN 行動する前に尋ねてください。 順序が重要です。 4 番目のステップでのタイムアウトは、ステップ数がたまたま 4 に等しかったとしても、依然としてタイムアウトです。承認リクエストは、一般的な不完全な状態に一掃されるのではなく、待機したままにする必要があります。成果物のない自然な仕上がりは、テキストが自信に満ちているように見えても、偽完了のままであるべきです。 モデルを呼び出さずにポリシーを再生します 監査では、リリースされた isStepCount 、 hasToolCall 、および isLoopFinished 関数をインポートしました。完了したステップ レコードのコンテンツのない配列を渡し、その出力をレシート分類子に結合しました。モデルの呼び出し、プロンプト、シークレット、または外部ツールの効果は必要ありませんでした。 4 つのアサーションによって SDK 境界が確立されました。 次に、11 ケースのフィクスチャでは、結果ありとなしの自然な終了、結果ありとなしの done 、ステップ キャップ、トークン バジェット、ルーティングされた承認とルーティングされていない承認、ツール エラー、タイムアウト、およびユーザーの中止がカバーされました。明らかになったペアは、エキゾチックな失敗ではありませんでした。どちらの自然仕上げの治具も、制御フローの原因が同じでした。宛先領収書を持っているものだけが VERIFIED COMPLETE になりました。同じ分割が done ツールにも発生しました。 これが反証可能な結果の核心です。ループ終了だけが有用な完了であることが判明した場合、それらのペアのフィクスチャは同じ正常な判定を受けるはずです。彼らはそうしませんでした。 制御フローの停止後に宛先を確認する の ToolLoopAgent リファレンス 生成された結果で完了したステップを公開し、 abortSignal およびタイムアウト制御を受け入れます。これらのフィールドは有用な証拠ですが、成功の定義は依然としてアプリケーションにあります。 ユーザーの実際の要求に応える、最も安価な確定的チェックを選択します。 ファイルの場合、予想されるパスまたはオブジェクト キー、コンテンツ タイプ、サイズの下限、およびタスク固有のハッシュまたはスキーマを確認します。 データベースの変更の場合は、宛先レコードを読み取り、目的のフィールドを比較します。 メッセージの場合は、プロバイダーの受信と宛先の ID を保持します。 デプロイメントの場合は、不変バージョン、公衆衛生上の対応、およびユーザー向けルートを検証します。 分析では、散文を受け入れる前に、必要なセクション、ソース範囲、機械可読出力を検証します。 結果のレシートをモデルのアサーションの 2 番目のコピーにしないでください。同じループによって発行される {"status":"done"} は独立した検証ではありません。コードで結果を安全にチェックできない場合は、レシートは宛先、決定論的バリデータ、または人間の決定から取得される必要があります。 承認には別の境界線も必要です。 SDK ドキュメントには、承認リクエストを収集し、承認応答として会話に追加し、後続の呼び出しに渡すことができることが示されています。運用上、これは、同じ決定を再開するために十分なコンテキストを待機中に保持する必要があることを意味します。再開トークンを持たない所有者は手動で再構築作業を作成します。所有者のないトークンは目に見えないキューを作成します。 このリプレイでは証明できないこと この実験では、プロバイダー モデルの呼び出し、部分出力のストリーミング、または外部ツールの実行は行われませんでした。したがって、プロバイダー固有の終了理由の動作、ネットワークのキャンセルのタイミング、または副作用の冪等性は確立されません。これらは、実際のモデル、ツール、宛先に関する統合テストに属します。 また、1 つの普遍的なステップやトークン制限も推奨しません。 4 ステップのルックアップと 40 ステップの移行ではエンベロープが異なります。運用上の要件は、選択した境界が明示的で記録され、到達したときに安全なアクションに関連付けられることです。 このルールはより狭く、耐久性が高くなります。つまり、ループが停止した理由を保存し、失敗とは区別して正当な待機を維持し、有用な完了を宣言する前に宛先の証拠を要求します。 Sidewisp は、既存のランタイム全体で証拠、待機状態、制限付きリカバリ、結果の検証を簡単に検査できるようにすることを目的とした AI エージェント正常性プラットフォームです。実稼働エージェントの正常性収集と AI SDK モニタリングは通常、本日出荷されません。 Sidewisp は現在プライベートプレビュー段階です。 この終了通知が独自のエージェントの障害モードと一致する場合、プライベート プレビューの待機リストは、必要なランタイムと証拠の境界を共有する適切な場所です。