multica-runtimes-and-repos

Multica ランタイムとリポジトリ

クイックスタート

「エージェントが実行されなかった」または「リポジトリのチェックアウトに失敗した」という場合は、何かを変更する前にこのチェーンを確認してください：

multica agent get <agent-id> --output json
multica runtime list --output json
multica repo checkout <repo-url>

ランタイムとリポジトリのコマンドは、実行中のエージェントの実行に影響を与えます。テストのためだけにデーモンを再起動したり、ランタイムを更新したり、任意のリポジトリをチェックアウトしたりしないでください。

コアモデル

ランタイムとは、エージェントの背後にある実行ターゲットです。デーモンはローカルのランタイムプロセスを所有し、サーバーからキューに入れられたタスクをクレームします。

チェーンは次のとおりです：

1. ユーザーの操作により、agent_task_queue の行が作成または更新されます；
2. タスクはエージェントとランタイムを指します；
3. 可能な場合、サーバーはデーモンの websocket を介してランタイムを起動します；
4. デーモンがタスクをポーリングしてクレームします；
5. サーバーがタスクコンテキスト、リポジトリ、プロジェクトリソース、以前のセッション/作業ディレクトリのヒント、およびタスクトークンを返します；
6. デーモンが作業ディレクトリを準備し、プロバイダーの CLI を起動します；
7. multica repo checkout はローカルのデーモンと通信し、GitHub と直接通信するわけではありません。

CLI

multica runtime list --output json
multica runtime usage <runtime-id> --output json
multica runtime activity <runtime-id> --output json
multica runtime update <runtime-id> --target-version <version> --output json
multica runtime delete <runtime-id>
multica repo checkout <url>
multica repo checkout <url> --ref <branch-or-sha>

runtime update と runtime delete は書き込み操作です。ランタイム更新の開始は、そのオーナーまたはワークスペースのオーナー/管理者に限定されます。元の開始者は、管理者ロールが変わった場合でも、その特定の進行中のリクエストを引き続きポーリングできます。runtime delete はランタイムの登録を削除します。アクティブなエージェントがまだバインドされている場合、ユーザーが明示的に --cascade を渡さない限り拒否されます。--cascade はそれらのエージェントをアンバインドし、ランタイムを削除する前にキューに入れられた/実行中のタスクをキャンセルします。アンバインドはエージェントと、それが所有するすべてのもの — インストラクション、スキル、チャット、ラベル、チャネルインストール、オートパイロット、タスク履歴 — を保持し、agent.runtime_id をクリアするだけです。アンバインドされたエージェントは、再びランタイムにバインドされるまで実行できず（multica agent update <id> --runtime-id <runtime-id>）、すべてのトリガーパスが agent_runtime_required でそれを拒否します。repo checkout はタスクの作業ディレクトリに専用のブランチを作成します。ほとんどのランタイムはリンクされた worktree を使用します。Linux と Windows の Codex はタスクローカルの Git メタデータを使用するため、共有の .repos キャッシュを書き込み可能にすることなく、タスクがステージングとコミットを行えます。

repo checkout には MULTICA_DAEMON_PORT と、注入されたタスクスコープの MULTICA_TOKEN の両方が必要です。これはアクティブなデーモンタスク内から、そのタスクの作業ディレクトリ（またはその子孫）から実行することを想定しています。ローカルデーモンは、トークンを自身のアクティブタスクレジストリに対して認証し、ワークスペース/タスク/エージェントの識別情報を自身で導出し、そのタスク外の呼び出し元が指定した作業ディレクトリを拒否します。どちらかの変数が存在しない場合、通常のエージェントチェックアウトパスにはいません。プロジェクトの github_repo リソースが resource_ref.ref を持つ場合、repo checkout <url> は現在のタスクに対してデフォルトでその ref を使用します。明示的な repo checkout <url> --ref <branch-or-sha> はそれを上書きします。

タスク CLI の境界

デーモンは、Multica API コマンド用にタスクスコープの mat_ 認証情報と、プライベートなタスクローカルの Multica 設定ルートを注入します。その管理されたタスクコンテキスト内では、次のようになります。

• issue list、issue get、issue runs などの API コマンドは、注入されたタスク ID を使用し、デーモンの Owner が保存した Multica プロファイルにフォールバックすることはありません。
• config show と config set は、タスクローカルの Multica 状態のみを操作します。タスク設定ルートが存在しない場合は、フェイルクローズします。
• auth status はタスク ID を検証できますが、出力からはすべてのトークン関連情報を省略します。
• daemon status と daemon disk-usage は、このタスクをホストしているランタイムについて報告します。status はデーモンが注入したヘルスポートをプローブし、disk-usage はデーモンが注入したワークスペースルートをスキャンします。どちらも --profile を拒否し、disk-usage はさらに --all-profiles と --workspaces-root も拒否します。また、その STATUS 列は空白のままです。これを埋めると Owner の認証情報を消費してしまうためです。
• 人間/ローカル向けのプロファイルおよびデーモンコマンド — login、logout、setup、workspace switch、ローカルランタイムプロファイルのパス変更、daemon start / stop / restart、daemon logs、daemon probe-runtimes など — は利用できません。特に daemon stop は、このタスクを実行しているデーモンと、その上のすべての兄弟タスクを終了させてしまいます。

MULTICA_DAEMON_PORT だけでは、タスクセーフな API およびプロファイル解決のための弱い多層防御シグナルにすぎず、人間/ローカルコマンドの拒否におけるタスク ID ではありません。本物のタスクは MULTICA_AGENT_ID / MULTICA_TASK_ID、MULTICA_TASK_CONFIG_ROOT、またはデーモン管理の作業ディレクトリマーカーも持ちます。ポートが唯一のシグナルである場合、daemon status は選択されたホストプロファイルから導出されたヘルスポートを使用します。通常の API およびプロファイル解決コマンドは依然としてフェイルクローズします。ホスト運用者は MULTICA_DAEMON_PORT をエクスポートすべきではありません。デーモンは選択されたプロファイルからホストのヘルスポートを導出し、その変数を自らタスクに注入します。

デーモンは、gh、aws、kubectl、npm などのプロバイダーツールのために、実際の HOME と XDG 変数を引き続き保持します。これは CLI 解決の堅牢化であり、厳密なファイルシステムの機密性ではありません。同じ OS ユーザー下のプロセスは、明示的に既知の Owner パスを依然として開くことができます。そのより強力な分離には、専用の Unix ユーザー、コンテナ、VM、または同等の OS 境界が必要です。

実行されなかったエージェントのデバッグ

次の順序で確認してください。

1. タスクは作成されるはずだったのでしょうか? issue/コメント/autopilot のコンテキストを確認してください。
2. 担当者はエージェントまたはスクワッドですか? スクワッドはそのリーダーにルーティングされます。
3. エージェントはアーカイブされているか、アクターが使用できないランタイムにバインドされていますか?
4. ランタイムはオンラインですか? multica runtime list --output json。
5. デーモンは最近ハートビートを行いましたか? ランタイムの last_seen_at が目に見える手がかりです。
6. タスクはクレームされましたか、それとも pending/running/ローカルディレクトリ待ちのままスタックしていますか?
7. リポジトリのチェックアウトが失敗した場合は、タスク/プロジェクトのコンテキストにリポジトリのコンテキストが存在したかどうかを確認したうえで分類してください。

リポジトリ

ランタイムブリーフには、このタスクで利用可能なリポジトリが一覧表示されます。ユーザーが明示的に新しいプロジェクトリソースのバインドを求めない限り、その一覧をエージェントのチェックアウトに関する権威として扱ってください。

ワークスペースリポジトリとプロジェクトリソースは同じものではありません。

• ワークスペースリポジトリのメタデータはワークスペースコンテキストに現れることがあります。
• github_repo プロジェクトリソースは永続的なプロジェクトコンテキストであり、将来のタスクに影響を与える可能性があります。オプションの resource_ref.ref は、そのプロジェクト内のタスクのデフォルトチェックアウト ref を固定します。
• local_directory リソースは、デーモンが所有するパスを指し、ローカルマシンの前提を伴います。

repo checkout が失敗したからといって、プロジェクトリソースを追加しないでください。まず、ユーザーが永続的なプロジェクトコンテキストを求めたのか、単なるタスクのチェックアウトを求めたのかを判断してください。

ソースに基づく詳細: references/runtimes-and-repos-source-map.md。