Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

id: ADR-008 title: 耐久性のあるタスク制御プレーンにゴールモードをアンカーする date: 2026-06-25 status: accepted relates-to:

  • https://github.com/zeroclaw-labs/zeroclaw/issues/8303
  • https://github.com/zeroclaw-labs/zeroclaw/issues/7929
  • https://github.com/zeroclaw-labs/zeroclaw/pull/8217
  • crates/zeroclaw-runtime
  • crates/zeroclaw-config
  • crates/zeroclaw-tools

ADR-008: 目標モードを永続的なタスク制御プレーンに固定する

コンテキスト

ゴールモードは、エージェントの対話を単一の応答からユーザーの目標に向けた自律的な作業へと変化させます。ゴールは、それを開始した受信メッセージよりも長く存続し、入力や外部依存関係を待つ間は一時停止し、デーモンの再起動後に復旧し、複数のワーカー、検証機、または委任された呼び出しにわたってモデル使用量を消費できます。

この種の作業には、そのライフサイクルを管理する単一の永続的な権威が必要です。システムは、どの作業が生存中か、どの作業が次のターンを実行する資格があるか、どの作業が一時停止中か、どの作業が終端状態にあるか、そしてどのアクターまたはルートがそれを再開またはキャンセルする権限を持つかを答えられなければなりません。プロンプト規約やサイドレジストリでは、これらの答えが重複した状態に依存することになります。

予算管理では、信頼できる唯一の情報源に関する制約がもう1つ加わります。トークン数とコストは、モデルプロバイダーへの呼び出しによって生成される事実です。残りの予算は、上限と消費済みの使用量から算出されます。これを独立した可変カウンターとして保存すると、2つ目の会計システムが生じることになります。

ゴールモードも信頼境界を越えます。スラッシュコマンドとモデル生成リクエストはいずれも、ゴールを開始すべきであることを表明できますが、呼び出し元 ID、ルート、チャネル、エージェントの適格性などの信頼済みのランタイム情報を自ら認可できてはなりません。

検討された主な選択肢は、プロンプトによるガイダンスを用いる通常のマルチターンチャット、独立した目標サブシステム、または目標固有の拡張状態を備えた既存の永続タスク制御プレーンを基盤として目標モードを実装することでした。

決定

並行するゴールタスクシステムを構築するのではなく、ゴールモードを永続タスクのコントロールプレーン内に位置付けます。

タスクコントロールプレーンは、ゴールのライフサイクル、所有権、ルート、プリンシパル、親関係、およびリカバリ適格性に関する信頼できる唯一の情報源です。ゴール固有の状態でタスクレコードを拡張してもかまいませんが、タスクレコードが所有するライフサイクル、ID、ルート、タイムスタンプ、配信、または終端状態のファクトを重複させてはなりません。

消費されたモデル使用量は、正規の使用量台帳が保持し続けます。目標予算は使用量レコードに照らして解釈される上限であり、残りの予算は常に導出されるものであって、2番目の可変な合計値として保存されることはありません。

一時停止、再開、キャンセル、再起動からの復旧、および完了は、コントロールプレーンのポリシー上の判断です。プロンプトテキストは、これらの遷移について説明したり、要求したりできますが、それらを認可するものではありません。

すべてのゴールエントリパスは、信頼された単一のRust側アドミッションゲートを使用します。ランタイムコンテキストは、surface、channel、principal、route、エージェントの適格性といった信頼されたファクトを提供します。モデルが提供する引数はこれらのファクトを宣言できません。

目標の完了には、目標コントローラーによる明示的な完了判断が必要です。沈黙、以降のツール呼び出しがないこと、または最終回答のように見えるアシスタントメッセージだけでは、永続的な自律作業を完了と見なすには不十分です。

結果

ゴールモードは、2つ目のタスクレジストリを追加するのではなく、既存の監視タスクライフサイクルを継承します。これにより、再起動リカバリ、キャンセル、および将来の監視改善が1つのコントロールプレーンコントラクトに紐付けられます。

コントロールプレーンは、一時停止されているが再開可能なゴール作業を、終了・喪失・実行中の作業と区別する責任を負います。これにより、正確なタスクステータス遷移と再起動リカバリーポリシーの重要性が高まります。

消費済み使用量が正規の使用量レコードから導出されるため、予算制限の適用は監査可能になります。また、ゴールに対して費用を消費し得るすべてのモデル呼び出しが、ゴールへの帰属情報付きで使用量を報告するまでは、ゴールモードは正しく機能しないことも意味します。

委譲およびバックグラウンド作業は、同じライフサイクルと使用量の境界を尊重しなければなりません。完了と使用量を所有元のゴールに報告できない作業は、ゴールモードに安全に参加できません。

単一の信頼できる受付ゲートを設けることで、コマンド起点とモデル起点のエントリーパスが別々の認可システムになることを防ぎます。その代償として、サポートされるすべてのサーフェスが、共有されたコマンド/受付機構を通じてゴールのエントリーをルーティングしなければなりません。

コマンド構文、一時停止理由の一覧、ペイロードの形式、検証ツールの設定、ロールアウトの段階的展開など、詳細な実装上の選択は、実装計画と後続のPRに委ねられます。これらは、このADRで定めるソース・オブ・トゥルースの境界と一貫していなければなりません。

参照