Long-running Agentは動き続けているわけではない

私たちは通常、「長時間稼働する」と聞くと、一つのプロセスが長く生き続ける姿を思い浮かべる。データベース、メッセージキュー、Webサービスは、プロセスが終了するまでメモリを使い、リクエストを待ち受ける。その直感に従えば、Long-running Agentも常にオンラインで思考を続けるモデルインスタンスのように見える。

Agentは別の方法で連続性を保つ。数時間にわたって推論せず、プロセスもマシンもすでに解放され、次回は別のモデルで起動するかもしれない。それでも以前の目標、履歴、判断を復元できれば、私たちは「同じAgent」とみなす。Long-running Agentの長期性は、状態を何度でも再構築できることから生まれる。

Agentはほとんどの時間動いていない

従来のLong-running Serviceは、次のようなライフサイクルを持つ。

プロセスを起動する → 動き続ける → プロセスが終了する

その連続性はプロセスの生存と強く結び付いている。プロセスが終了すればメモリ上の状態も消えるため、サービスを続けるには再起動、データの復元、接続の再確立が必要になる。

Long-running Agentは別のパターンに近い。

起こされる
  → 永続状態を読み込む
  → 現在のContextを組み立てる
  → 1回のTurnを実行する
  → 結果を保存する
  → 休眠する

二度の起動の間には、モデルインスタンスも実行中の推論もなく、推論リソースを消費していないことがある。たとえば月曜日にコードを分析して次の計画を記録し、水曜日に新しいイベントで起こされて同じプロジェクトを再開する。その間に計算がなくても、復元されたAgentが目標、完了済みの作業、次の手順を理解していれば、二度の実行は一つの連続した仕事になる。

Agent、Conversation、Session、Turnを区別する

Long-running Agentを考えるとき、次の四つはしばしば混同される。

• Agent：長期にわたって持続できるIdentityと、その行動上の制約。
• Conversation：Agentに紐づく永続的な対話履歴。
• Session：ユーザーまたはシステムとAgentの一回の有効な接続。
• Turn：モデルを呼び出し、一回の推論を行う単位。

一つのSessionには複数のTurnが含まれ、一つのConversationは複数のSessionをまたぎ、一つのAgentが複数のConversationに参加することもある。ブラウザを閉じればSessionは終わっても、Conversationは残る。モデルのコンテナが解放されればTurnは終わっても、保存された目標やMemoryは次の接続で読み込める。マシン、Runtime、モデルを変えたときも、復元されたIdentity、履歴、目標、行動に十分な一貫性があれば、連続性は保たれる。

ここでいうIdentityは、システム指示、ユーザーとの関係、タスク状態、Long-term Memory、Conversation履歴、実行環境のリソースや権限といった永続化可能な材料からできている。一回の実行時にそれらを組み直し、そこで生まれる行動が現在のAgentを形作る。

HarnessはAgentのオペレーティングシステム

一回のモデル呼び出しが見られるのは、Context Windowに渡された内容だけだ。呼び出しが終わっても、モデルが経験を自動保存したり、次回に自然と思い出したりはしない。保存と復元はモデルの外側にあるHarnessが担う。HarnessはConversation、Memory、ツール、環境、モデル呼び出しを管理し、各Turnの前にContextへ入れる情報を選ぶ。

Conversationは増え続けられても、Context Windowには限りがある。Harnessは古い内容を圧縮し、最近のメッセージを残し、現在のタスクに関連する履歴を検索する。現在のワーキングセットへ何を残し、何を外へ出し、いつ再び読み込むかを決めるメモリ管理に近い。Harnessは呼び出しのたびに、その選択から現在のAgentを再構築する。

連続性はコンパイルの結果である

Agentが起こされるたびに、Harnessは複数の情報源から材料を集める。

system prompt
+ agent memory
+ conversation summary
+ recent messages
+ recalled history
+ current environment
+ available tools
= 今回のTurnでモデルが実際に見るAgent

この処理は再生よりコンパイルに近い。限られたContextに合わせて履歴を選び、圧縮し、組み直して、現在のTurnで使えるワーキングセットを作る。システムが保存するのは元の材料であり、モデルが見るのはコンパイル後の結果である。

3か月前のメッセージに重要な決定が残っていても、要約に含まれず、検索でも見つからなければ、現在のモデルはそれを知らない。履歴がデータベースに残っていることは、材料を取り出せることだけを意味する。連続性は、Harnessが現在のタスクに必要な履歴をContextへ正しくコンパイルできるかにかかっている。

Conversationは増えても、Memoryには限界がある

多くのAgent製品は、Conversationを無制限に続けられるように見せる。しかしHarnessができるのはContextの上限を隠すことまでで、選択に伴う情報損失は残る。

1. 圧縮による損失

要約は結論を残しても、具体的な表現、証拠の出所、却下した選択肢、決定が有効であるための条件を失うことがある。

現在はデプロイ環境が案Bをサポートしていないため、案Aを選ぶ。環境が更新されたら再評価する。

この結論が、圧縮後には次の一文だけになるかもしれない。

プロジェクトでは案Aを使うと決めた。

決定は残っても、その理由と見直す条件が消えている。

2. Recallの失敗

検索結果は現在のクエリに左右される。表現が変わったり、Agentが過去の履歴との関係に気づかなかったりすると、情報が存在していても見つからない。システムが今それを探すべきだと判断できない、検索層の忘却である。

3. Identityのドリフト

重要な経験がConversation履歴にしかなければ、復元されるたびに状態が少しずつ変わりうる。ある要約はユーザーの好みを強調し、別の要約は現在のタスクを強調する。検索が過去の合意を見つける回と、見落とす回もある。こうした不完全な復元を重ねるうちに、行動範囲、表現、判断の根拠が徐々にずれていく。履歴をすべて保存することより、次の行動に必要な部分を復元することのほうが難しい。

RecoverabilityでLong-running Agentを測る

設計の重点は、プロセスのUptimeから状態の復元へ移る。重要な制約が必要なときにContextへ戻るかを確認し、直近のワーキングセット、Conversationのアーカイブ、長期的な経験、現在の環境を区別する。

Agentの連続性は、次のような問いで判断できる。

• 起きたとき、自分の目標と完了済みの行動を理解しているか。
• 重要な決定と、その成立条件を復元できるか。
• ユーザーとの長期的な合意を覚えているか。
• 環境が変わったとき、古い事実と現在の事実を区別できるか。
• モデルやRuntimeを変えても、中核となる行動は安定しているか。

評価では、意図的にプロセスを終了し、しばらく休眠させ、必要ならRuntimeやモデルも替えてからAgentを起こす。目標、完了済みの行動、重要な決定の適用条件、長期的なユーザーとの合意を復元できるかを確かめ、環境の変化も識別させる。対話がデータベースに残っていても、復元後のAgentがそれを使えなければ、連続性は成立していない。