エージェントの再開可能性を解説：TrueForgeにおけるセッション、ターン、一時停止、再接続の仕組み

エージェントの再開は単一の操作ではありません。本番環境のシステムでは、ストリームの再接続、一時停止したワークフローの継続、そして不確実な外部副作用のリカバリを明確に区別する必要があります。

「再開」という言葉に隠された3つの異なるリカバリ課題

長時間稼働するエージェントは、従来の要求応答型APIよりも多くの箇所で障害が発生します。サーバーが処理を継続している間にブラウザが切断されることもあれば、人間やクライアント側のツール、あるいはOAuthフローによる入力待ちのためにワークフローが意図的に停止することもあります。また、ダウンストリームのAPIが変更をコミットした後にタイムアウトすることもあります。これら3つの状況はすべて「再開」と表現されることがありますが、それぞれ異なる状態、証拠、安全ルールを必要とします。

1つ目はトランスポートのリカバリです。これは、イベントを重複させることなく、実行中のストリームに再接続することを指します。2つ目はワークフローの継続です。これは、記録された一時停止状態に応答して新しい作業単位を作成することを指します。3つ目は副作用のリカバリです。これは、外部操作がコミットされたかどうかを確認した上で、再試行、補償、または停止のいずれを行うかを判断することを指します。これらを単一のメカニズムとして扱うと、最も危険なタイプの信頼性バグが生じます。つまり、現実世界でのアクションを繰り返したりスキップしたりしているにもかかわらず、成功したように見えてしまうバグです。

これら3つの分岐は、意図的に異なるアクションで終了するように設計されています。ストリームシーケンスは観測結果を修復し、必要なアクションの参照はワークフローを継続させ、操作IDは調整をサポートします。ある識別子を別のものに置き換えると、重複や誤った完了判定が発生します。

TrueForgeの階層構造から始める

TrueForgeでは、「エージェント → セッション → ターン → イベント → デルタ」という階層構造を定義しています。エージェントは再利用可能な定義です。セッションは1つの課題や会話を表し、ターンをまたいで持続します。ターンは、完了または一時停止するまで実行される1つの要求・実行サイクルです。イベントは、そのターン中に何が起こったかを記述します。一部のメッセージイベントはストリーミング中にデルタを生成しますが、永続化されたイベントリストは、ライブの断片ごとではなく、マージされたイベントを返します。

この階層構造が重要なのは、各レイヤーがリカバリに関する異なる問いに答えるからです。エージェント定義は、設定されたモデル、指示、ツール、制限を確立します。セッションは、会話の永続的な継続性を提供します。ターンは、終了状態を持つ実行境界を提供します。イベントは、クライアントのビューを再構築するために必要な順序立てられた証拠を提示します。デルタはライブ体験を最適化しますが、永続的なビジネス事実としては扱われません。

TrueForgeでは、1つのセッションで同時に実行できるターンは1つだけです。ターンは自動的に連鎖するため、アプリケーションはリクエストのたびに履歴全体を再送する必要はありません。別のターンが実行中に新しいターンを作成すると、アクティブなターンはキャンセルされます。この動作は有用ですが、UI側でユーザーのせっかちなクリックをすべて新しいターンとして処理してしまうと、意図しない動作になる可能性があるため注意が必要です。

トランスポートの再接続はワークフローの継続ではない

ライブターンは、Server-Sent Events（SSE）ストリームを使用します。ストリーミングされる各アイテムには、クライアントが保持できるシーケンス識別子が含まれています。接続が切断された場合、クライアントは最後に処理したシーケンス番号の次から再購読できます。サーバーは、同じ実行中のターンから後続のイベントをリプレイできます。適切なクライアントはイベントIDごとにイベントを保存し、デルタをベースとなるメッセージイベントにマージするため、再送によって出力が重複することはありません。

これがトランスポートの再接続です。元のターンはビジネス上の判断のために一時停止したわけではなく、単にネットワーク接続が中断されただけです。クライアントが不在の間も、サーバーは実行を継続している可能性があります。そのため、再接続するUIは「この既存のターンのうち、まだレンダリングしていないイベントはどれか？」を問うべきであり、別のターンを作成したり、元のユーザー指示を再発行したりすべきではありません。

ターンが終了すると、その永続化されたイベントを再度読み取って、確定した履歴を再構築できます。これは証拠のリプレイであり、モデルやツールの再実行ではありません。この区別はインシデント分析において重要です。同じ保存済みシーケンスであれば同じ再構築ビューが得られるはずですが、タスクを再度実行しようとすると、異なるモデル、ツール、認証情報、外部状態に遭遇する可能性があるからです。

この図は、永続的な階層構造と配信メカニズムを分離しています。デルタはライブストリームに属し、ベースとなるイベントにマージされます。一方、セッション、連鎖するターン、終了状態、および永続化されたイベントは、再接続や再起動後に使用される確定した記録を提供します。

一時停止は明示的なランタイム状態です

ターンは、最終的な回答ではなく、必要なアクションを伴って終了することがあります。TrueForgeでは、重要なケースとして「ゲート付きツールの承認が必要」「クライアントサイドツールの応答が必要」「MCPサーバーの認証が必要」という3つを定義しています。ターンの終了状態は、保留中の項目を特定します。アプリケーションは、対応する承認、ツール応答、または認証の継続を含む新しいターンを作成することで、これらの要件を満たします。

これはストリームの再接続ではなく、ワークフローの継続です。一時停止されたターンはすでに確定しています。次のターンは、保留中のアクションを参照し、セッション履歴に連結することで、因果関係の連続性を維持します。1つのターンで、並列サブエージェントスレッドからのポーズを含む複数の保留項目が発生する可能性があるため、クライアントは単一の項目のみを想定するのではなく、必要なアクションのセット全体を収集する必要があります。

承認および応答の一時停止において、ソースイベントは保留中の項目と、ツール呼び出しを提案したモデルメッセージをリンクします。このリンクにより、アプリケーションはレビュー担当者に対し、チェックポイントを作成したツール名と引数を表示できます。また、これは、継続処理が意図した呼び出しに対する回答であることを、視覚的に似た別の呼び出しと区別して検証するための基盤となります。

再開可能性のコントラクトを構築する

‍