ACP テストとサポートのマトリクス

ACP は双方向です。有用な相互運用性テストでは、通知とネストされたリクエストが到着する間も 1 本の接続を開いたままにしておく必要があります。切断された JSON 行の連続だけではセッションの動作を証明できません。

検証済みのテスト

adk-acp スイートは、公式の SDK Client を ADK-Rust SDK Agent にインメモリ転送経由で接続し、次を実施します:

initialize
  → session/new
  → session/prompt
  ← session/update
  ← PromptResponse(end_turn)
  → session/close
  → session/list
  → session/resume
  → session/close
  → session/delete

個別のテストでは、セッションのキャンセル、JSON-RPC リクエストのキャンセルと復旧、イベントのマッピング、最初に拒否する権限メニュー、透過的なオプション ID、捏造された選択、待機された人間の判断、正確な呼び出しの allow-once 動作、MCP 設定の検証、そして秘密情報を伏せたデバッグ出力をカバーします。フェーズ 2 では、session/load の再生順序テスト（再生された session/update は保存されたイベントの時系列順に一致する）、マルチモーダルなプロンプトのマッピングと拒否テスト（画像と音声は受け入れられ、未公開のコンテンツは拒否される）、サーバー権限ブリッジの approve/deny/cancel テスト（キャンセルは deny にマップされ、function-call id で相関付けられる）、およびクライアント忠実性テスト（ToolCallUpdate と UsageUpdate の面が、エージェントのテキスト面を退化させることなく表示されることを証明する）を追加します。フェーズ 3 では、セッションモードと設定オプションのテスト（set_mode / set_config_option は広告された値を記録し、未知の値を拒否し、選択は session/load をまたいで保持される）、session/fork 分離テスト（fork の履歴は source の履歴と等しく、source は変更されない）、available-commands と session-info の有効化テスト（エージェントがコマンドを宣言するかタイトルを記録した場合にのみ更新が発行される）、そして、モードと設定オプションが SessionControls provider が存在する場合にのみ広告されることを含め、広告された capabilities が登録済みハンドラーと有効なコンテンツマッピングに正確に対応することを主張する capability accuracy テストを追加します。

ライブな MCP ライフサイクルゲートは、実際の stdio MCP 子プロセスを起動し、ハンドシェイクを完了し、ACP セッションで使用されるのと同じ McpToolset を通じてそのツールを発見します。

ゲートを実行する

cargo test -p adk-acp --all-features
cargo test -p adk-agent --test tool_confirmation_tests
cargo test -p adk-tool --features mcp --test mcp_server_lifecycle_integration_tests test_tool_aggregation -- --ignored --exact

cargo test --manifest-path examples/acp_client_host/Cargo.toml
cargo check --manifest-path examples/acp_kiro/Cargo.toml
cargo check --manifest-path examples/acp_server/Cargo.toml
cargo test --manifest-path examples/acp_full_protocol/Cargo.toml

acp_full_protocol ゲートは、実行可能なフェーズ 2 の安全網です。no-API-key の Runner バックの AcpServer を、プロセス内チャネルを介して公式の SDK で駆動し、サブプロセスやモデル認証情報なしで、サーバー方向のフェーズ 2 の完全な面（組み込みリソースおよび画像/音声プロンプト、権限ブリッジ、session/load の再生順序、UsageUpdate / ToolCallUpdate の表出）を検証します。

現在のサポート

領域	状態	注記
安定版 wire protocol v1	実装済み	公式 Rust SDK 1.2; プロトコルバージョンは別途ネゴシエートされる
ローカル stdio クライアント transport	実装済み	単発、ストリーミング、永続セッション
クライアント権限	実装済み	デフォルトでは拒否、意味論的マッチング、非透過ID、同期または非同期ポリシー
クライアントのファイルシステムコールバック	実装済み API	読み取りと書き込みは個別に公開
クライアントの端末コールバック	実装済み API	create/output/wait/kill/release trait を完備
クライアント提供の MCP	実装済み	stdio 必須; HTTP/SSE は capability-gated
ADK-Rust ACP サーバー	実装済み	新規, プロンプト, 読み込み, 更新, キャンセル, 閉じる, 一覧, 再開, フォーク, set_mode, set_config_option, 削除
サーバーセッションの読み込み + 再生	実装済み	永続化されたセッションを再アクティブ化し、保存されたイベントを時系列順に再生する; `load_session` が公開される
サーバーセッションのフォーク	実装済み	履歴と関連する状態を新しいセッション ID にコピーし、元のセッションは変更しない; `fork` が公開される
サーバーセッションのモード + 設定オプション	実装済み	`SessionControls` によるプロバイダーゲート付き; `set_mode` / `set_config_option` は検証され、読み込み/再開/フォーク全体で永続化される; 宣言された場合のみ公開される
Server の available-commands + session-info	実装済み	エージェントがコマンドを宣言するかタイトルを記録したときにアクティベーション時に送出され、それ以外ではなし
Server の plan 更新	休止中	`Plan` `SessionUpdate` のマッピングは存在するが、ADK の plan primitive が plan エントリを表示するまで無効
Server session MCP	実装済み	stdio、セッションごと、起動とクリーンアップが制約付き
Text と resource-link の prompts	実装済み	共有 content module を通じてマッピングされる
マルチモーダルプロンプト（画像、音声）	実装済み	`Part::InlineData` にマッピング; `image`/`audio` が公開される; 公開されていないコンテンツは拒否される
埋め込みリソースのプロンプト	実装済み	`Part::EmbeddedResource` にマッピング; `embedded_context` が公開される
サーバー ADK のツール承認から ACP へ	実装済み	`ToolConfirmationRequest` が `session/request_permission` にブリッジされる; allow → approve、deny/cancel → deny、function-call id により相関付け
クライアントのツール更新と使用状況の忠実性	実装済み	`OutputChunk::ToolUpdate` と `OutputChunk::Usage` が External_Agent の `ToolCallUpdate`/`UsageUpdate` を表面化する; agent のテキストは変更なし
クライアントのリッチなプロンプト内容	実装済み	`prompt_agent_content_with_policy` は非テキストの ADK コンテンツを対応する ACP ブロックとして送信します
リモート ACP HTTP/WebSocket	公開されていません	安定版の実装はローカル stdio です
実験的なプロトコル機能	公開されていません	実装と相互運用性テストの後にのみ追加してください

手動エディタテスト

examples/acp_serverをビルドし、その後ACPクライアントを構成して、絶対マニフェストパスとモデル認証情報を指定してそのバイナリを起動します。次を確認してください:

初期化レスポンスがプロトコルバージョン 1 を報告すること;
新しいセッションが意図した絶対プロジェクトディレクトリを受け入れること;
最終レスポンスの前にテキストがライブ更新として表示されること;
read ツールが開始し、完了がクライアントに表示されること;
キャンセルしても接続を閉じずにターンが終了すること;
後続のプロンプトが同じセッションで成功すること;
セッションサービスが永続的な場合、close と resume によって履歴が保持されること。

このテストではecho | cargo runを使用しないでください。各 pipe は異なるプロセスを開始するため、接続やセッションを保持できません。

acp_client_host
acp_kiro
acp_server
acp_full_protocol — no-API-key、Runner-backed の Phase 2 サーバー方向リファレンスで、エンドツーエンドの検証テスト付き