Session と Run

Session、Run、Event のログの関係。

Session は 1 つの作業単位で、会話、チケット、バックグラウンドジョブなどがこれにあたります。Session は Workspace に属し、作成時に使う Agent のバージョンが決まります。Session の中で起きたことは、すべて追記専用のログに記録されます。

Run は、このログをもとに Agent が行う 1 ターン分の作業です。入力があると Run が始まり、Run は進むにつれて自分の Event をログに追記します。終わるときは、終了を表す Event をちょうど 1 つ記録します。

Session と Run を分けて考えるのは、Session が Run より長く存続するからです。Run が失敗したり、停止されたり、Run を見ていた接続が切れたりしても、Session はログを保ったまま残り、次の入力を受け付けます。

何がいつ確定するか

	確定するとき
Agent のバージョン	Session の作成時	その時点の最新バージョンです。後から公開したバージョンは、それ以降に作成した Session にだけ反映されます。
Skill と Function のバージョン	Session の作成時	各 Grant の最新はその時点の最新バージョンに決まり、固定は指定したバージョンのままです。
Vault	Session の作成時	Session が使う Credential です。Session ごとに選びます。
Metadata	Session の作成時	独自に付けるキーで、すべての使用量の記録にコピーされます。

そのため、今朝始めた Session は、途中で何が公開されても、開始時と同じ指示、Tool、Credential のまま最後まで進みます。

すべての Event にはシーケンス番号が付き、ログがすべての事実を表します。メッセージ、Agent の Thinking、Tool の呼び出しとその結果、承認、フォーム、Client の参加と退出、各 Run の開始と終了が記録されます。ログはコンソールの Event タブで確認でき、API ではページ単位で取得したりストリーミングしたりできます。Event の全種類は Event リファレンスにあります。

事実を持っているのは接続ではなくログです。そのため Client は、接続が切れても、最後に受け取ったシーケンス番号から再開できます。1 時間後にページを再読み込みしても、同じ会話が表示されます。

Run の流れ

ログから始める

Run はコミット済みの Event から状態を組み立て直します。そのため、失敗した Run の次の Run も、実際に起きたことから始まります。

モデルを呼び出す

呼び出しは Subako を経由するので、Run がキーを持つことはありません。Model Provider のキーは Subako の中に封じられたままです。長い会話は、モデルの Context window に近づくと圧縮されます。

Tool を呼び出す

各 Tool は、それを提供する Grant を通じ、その Grant の Policy に従って呼び出されます。MCP サーバーと Function の呼び出しには Session の Credential が付き、Client tool の呼び出しはアプリに送られます。

終わる

run_completed、run_failed、run_cancelled のいずれかで終わります。承認やフォームで人を待っている Run は、そのまま最大 1 日待ちます。

Run の実行中に送った入力は、後ろに並んで待つのではなく 実行中の Run に加わります。Run は次のステップでその入力を読み込みます。Run の停止は協調的です。Run は次のチェックポイントで止まって run_cancelled で終わり、それまでにコミットした内容はログに残ります。