ソースコードありADK-Rust v2テストマトリックス検証済み

マルチチャネルエージェント運用

ユーザーがすでに作業している場所でエージェントを実行

ADK Gatewayはメッセージングチャネル、Webアプリケーション、その他のエージェントをADK-Rustエージェントチームに接続します。各リクエストをルーティングし、適切なコンテキストを復元し、運用ポリシーを適用し、開発者にシステムを一元管理する場所を提供します。

ADK Gateway 稼働中

ユーザーとシステム

Telegram
Slack
WhatsApp
Discord
マトリックス

アイデンティティ · ルーター · ランナー

セッションポリシーイベント配送

エージェントチーム

システムエージェント
サポートエージェント
リサーチエージェント
コーディングエージェント
ツールメモリプロトコルコントロール

なぜゲートウェイが必要か?

エージェントは有用です。運用されるエージェントシステムは製品です。

ADK-Rust エージェントは推論し、ツールを呼び出し、イベントをストリームできます。実際の展開では実用的な課題にも対応しなければなりません。 リクエストはどこに届く?どのエージェントが受け取るべき?誰のセッションを復元する?そのエージェントは何が許可されている?

ADK Gatewayは共有運用レイヤーを提供します。Telegram、Slack、WhatsApp、Discord、Matrix、Webhook、エージェント向けWebリクエストはアダプターを通じて入り、ゲートウェイはそれらを単一のメッセージ形態に変換し、アクセスルールを適用し、システムまたは専門エージェントにルーティングし、進捗を元のチャネルに返します。

ゲートウェイはすべてのエージェントを1つのアシスタントに統合しません。開発者は研究、サポート、運用、コーディングエージェントを異なるモデル、ツール、ワークスペース、権限、チャネルバインディングで分けて管理しつつ、1つのコントロールサーフェスで操作できます。

ゲートウェイなしで

  • 各チャネルには独自のエージェント統合が必要
  • セッションとIDはエントリーポイント間で移動します
  • ツールと権限は複数の場所で設定されます
  • オペレーターはエージェントシステム全体を閲覧できません

ADK Gatewayと共に

  • チャネルアダプターは一つのインバウンド契約を共有します
  • ルーティングはエージェントとセッションを意図的に選択します
  • 機能と方針はエージェントロールに紐づいたままです
  • 1 つのコントロールパネルでエージェント、チャネル、作業、状態を表示

アーキテクチャ

独立制御されたエージェントチームを囲む 1 つのゲートウェイ。

左から右へアーキテクチャを読みます。リクエストは人間またはエージェントチャネルから入ります。アイデンティティとルーティングが所属先を決定します。ADK-Rustは選択されたエージェントを独自の状態と機能で実行します。制御プレーンは会話に参加せずにすべての層を監視します。

エントリーポイント

  • Telegram · Slack
  • WhatsApp・Discord
  • マトリックス · Webhook
  • AWPリクエスト

信頼エッジ

  • ペアリング+アイデンティティ
  • 許可リスト + ロール
  • レート制限
  • JWT / SSO

Gatewayランタイム

  • メッセージルーター
  • ADK-Rust Runner
  • セッション + イベント
  • 配信

エージェントチーム

  • システムエージェント
  • スペシャリストエージェント
  • グラフワークフロー
  • ACPコーディングエージェント

機能

  • モデル + フォールバック
  • Rustツール + MCP
  • メモリ + RAG
  • 成果物 + ストレージ

オペレーター制御プレーン

完全なリクエストパスを構成、承認、監視、復旧、監査します。

コントロールパネルWebSocketイベントメトリクスログヘルス
インターフェースと配信ID と運用ポリシールーティングと実行状態と機能

1つのリクエストを追跡する

Telegramメッセージから適切な専門エージェントへ。

すべての対応チャネルに同じフローが適用されます。アダプターと配信形式のみが変わり、ルーティング、セッション、エージェント実行、ポリシー、証拠は共有されます。

  1. 01Channel adapter

    1つのメッセージ形式を受信

    Telegram、Slack、WhatsApp、Discord、Matrix、およびWebhookは異なる形式で届きます。各アダプターはそれらを同じ受信メッセージ契約に変換します。

  2. 02Access boundary

    継続可能な人物を特定する

    ペアリングルール、許可リスト、グループメンションポリシー、マルチユーザーアイデンティティ、レート制限、およびオプションのJWTチェックはリクエストがエージェントに届く前に実行されます。

  3. 03メッセージルーター

    適切なエージェントを選択する

    ルーティングはチャネル、アカウント、個人またはグループをチェックします。最も具体的な一致が勝ち、システムエージェントが最終フォールバックです。

  4. 04ADK-Rust Runner

    会話を復元

    Runnerはエージェント実行開始前に正しいセッション、ユーザーコンテキスト、メモリ、キャンセル状態、モデルフォールバックチェーンをアタッチします。

  5. 05Specialist agent

    割り当てられた機能のみを使用する

    選択されたエージェントはRustツール、MCPサーバー、知識、ワークフロー、または承認済みACPコーディングエージェントを使用できます。役割ポリシーは呼び出せる内容を制限します。

  6. 06Delivery + evidence

    進捗を返し記録を保持

    型付きイベントはタイピングインジケーター、進捗メッセージ、画像、または最終応答になります。メトリクス、ログ、タスク履歴、監査イベントが何が起きたかを説明します。

Rustでのルーティング

ルーティングは明示的でテスト可能です。

開発者はエージェントをチャネル全体、チャネル上の1アカウント、または特定の個人やグループにバインドできます。ルーターは最も具体的なルールを最初にチェックし、予測可能にフォールバックします。

例は読みやすさのためにソース実装を凝縮しています。リポジトリは正確なアカウントレベル、チャネルレベル、レガシー、デフォルトのルーティング動作をテストします。

router.rs · simplified resolution order
/// Most-specific binding wins.
pub fn resolve_agent(&self, message: &InboundMessage) -> &str {
    // 1. channel + account + person or group
    if let Some(agent) = self.exact_binding(message) {
        return agent;
    }

    // 2. channel + account, then channel-only
    if let Some(agent) = self.account_binding(message)
        .or_else(|| self.channel_binding(message))
    {
        return agent;
    }

    // 3. configured legacy rules, then the system agent
    self.legacy_binding(message)
        .unwrap_or(&self.default_agent_id)
}
gateway.json · agent, channel, and role
{
  "agent": {
    "model": {
      "primary": "openai/gpt-5.4-mini",
      "fallbacks": ["openai/gpt-5.4-nano"]
    }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "${TELEGRAM_BOT_TOKEN}",
      "dmPolicy": "pairing"
    }
  },
  "user_agents": [{
    "id": "support",
    "name": "Customer support",
    "tools": ["order_lookup", "refund_request"],
    "channel_bindings": [{ "channel_type": "telegram" }],
    "role": {
      "allow": ["order_lookup", "refund_request"],
      "deny": ["refund_issue"]
    },
    "auto_start": true
  }]
}

埋め込みコントロールパネル

システムを見て、意図的に変更する。

ReactコントロールパネルはRustバイナリにコンパイルされ、以下で提供されます /ui. It is the operator interface for configuration, agent lifecycle, approvals, sessions, memory, scheduled work, logs, and health.

セットアップ

モデルプロバイダーを選択し、資格情報を保存し、チャネルアカウントを接続し、ゲートウェイをユーザーに開放する前に検証します。

初回起動ウィザードモデルフォールバックチャネル接続テスト検証済みJSON構成

エージェントを指示

スペシャリストを作成し、ツールとチャネルを割り当て、プロセスを開始または停止し、どのエージェントが作業を委任できるかを定義。

エージェントライフサイクルチャネルバインディング委任権限スケジュールされたタスク

コントロールを維持する

機密ツール呼び出しをレビューし、ユーザーをペアリングし、セッションを終了し、同意を検査し、タスクを継続すべきでない場合に介入します。

ツール承認ペアリングと役割セッション終了AWP同意

操作する

チャネルとエージェントをリアルタイムで監視し、エラーを検査し、メモリを検索し、稼働中のゲートウェイの状態を追跡します。

ライブ WebSocket ダッシュボードログとメトリクスメモリブラウザコンポーネントの健全性

プロトコル境界を開く

ツール、コーディングエージェント、ウェブサイト、アプリケーションを接続。

チャネルはゲートウェイと人を接続します。プロトコルはそれを機能や他のソフトウェアに接続します。各境界は明確な役割を持つため、開発者はランタイム全体を再設計せずに一つを追加できます。

MCP

エージェントに外部ツールを提供する

ブラウザ、コンピュータ、メディア、データ、ビジネスシステム用の機能サーバーを接続。ゲートウェイはすべての統合をバイナリに組み込むことなく、設定済みのMCPサーバーを追加、一覧表示、削除できます。

ACP

コーディング作業を委任

監視された境界内でサポートされるコーディングエージェントプロセスを実行します。作業スペースポリシー、許可リクエスト、進捗、コスト、キュー状態、タスク履歴はゲートウェイに表示され続けます。

AWP

エージェント向けのウェブインターフェースを公開する

ディスカバリー、機能、ヘルス、同意、サブスクリプション、およびエージェントメッセージエンドポイントを公開し、他のソフトウェアがゲートウェイとの連携方法を理解できるようにします。

HTTP + WebSocket

統合と運用

インバウンドWebhookは他アプリケーションから作業を取り込みます。HTTP APIとライブWebSocketイベントが組み込みコントロールパネルと外部操作ツールを支えます。

現在の境界: ソースはAWPサーフェス下でagent-messageルートを公開しています。このページは別途検証された完全なA2Aサーバーサーフェスや本番AWPコマース実装を主張しません。

ガバナンス

エージェントに可視境界内で作業できる空間を与える。

エージェントの自律性は設定可能な運用判断であるべきです。ADK Gatewayはリクエストを運ぶ同じ実行パスにID、権限、制限、証拠を配置します。

01

アイデンティティ

ペアリング、許可リスト、マルチユーザーセッション、JWT/JWKS、および役割マッピングは誰がリクエストを行っているかを判定します。

02

権限

エージェントごとの許可・拒否ルールとツール承認により、ユーザーやエージェントが使用可能な機能が決まります。

03

制限

レート制限、リクエストタイムアウト、キャンセル、制限付きツールループ、ヘルスポリシーにより作業継続時間を制御します。

04

証拠

監査イベント、ログ、メトリクス、タスク履歴、ツール結果、ヘルス履歴が運用記録を提供します。

展開

ゲートウェイの実行場所を選択する。

開発者のワークステーション、内部サーバー、またはコンテナは同じゲートウェイ形態を実行できます。セッションストレージはローカル実験ではメモリに保持し、展開システムではSQLite、PostgreSQL、Redis、Firestoreに移行可能です。

01

単一バイナリ

Rustサービスはコンパイル済みのReactコントロールパネルを埋め込みます。実行ファイルを1つインストールまたはコピーし、その隣に設定を保持してください。

02

コンテナ

リポジトリにはDockerfileとコンテナ展開用のボリュームおよびポート契約のドキュメントが含まれています。

03

Linux サービス

systemdユニットは起動時の自動起動、再起動ポリシー、準備完了、ログ、オペレーター管理の環境ファイルをサポートします。

04

macOSサービス

launchd定義は開発者とワークステーションエージェントのために永続的なローカルゲートウェイを実行します。

マイグレーションと検証

今日検証されているものは?

このページの製品機能はローカルのGatewayソース、設定、ドキュメント、テストスイートから提供されています。ADK-Rust v2移行はライブラリ、プロパティ、統合、生成エージェント、コントロールパネルの検証を通過しました。

検証済みソース

Gateway製品アーキテクチャ

チャネルアダプター、メッセージルーティング、エージェントレジストリ、プロセスライフサイクル、セッション、メモリ、RAG、スケジュールタスク、ツール承認、アクセス制御、コントロールパネルルート、AWP、MCP、ACP 統合、デプロイ資産、およびテストはレビュー済みリポジトリに存在します。

テスト検証済み

ローカル ADK-Rust v2 マイグレーション

すべての ADK 依存関係はローカルの 2.0 ワークスペースに解決されます。Rust 2024 と Rust 1.95 はすべてのターゲットと機能でコンパイルされます。845 件のライブラリテスト、276 件の単体プロパティおよび統合テスト、81 件のコントロールパネルテストがすべて合格しています。

公開リリース

crates.ioはv1のままです

検証済みの v2 状態は現在ローカルのソースマイグレーションであり、公開された adk-gateway v2 クレートではありません。インストールガイダンスは引き続きソースチェックアウトと crates.io の v1 リリースを区別する必要があります。

オペレーター検証

認証済みかつ展開された動作

すべてのメッセージングプロバイダー、モデルプロバイダー、外部 MCP サーバー、永続バックエンド、ID プロバイダー、および本番デプロイメントは、オペレーターによる資格情報、インフラストラクチャ、およびセキュリティレビューがまだ必要です。

明示的な制限

実験的なサーフェス

マルチエージェントコード生成はまだプレースホルダーの A2A エンドポイントを文書化しており、AWP コマースは宣言されていますが完全なトランザクションシステムとしては実装されていません。どちらもここでは本番対応として提示されていません。

レビューソース: すべてのADK依存関係はローカルのv2.0.0ワークスペースに解決され、プロジェクトはRust 2024をターゲットにし、MSRVは1.94です。すべてのターゲット・すべての機能のコンパイルが成功しています。検証では845のライブラリテスト、276の単体プロパティおよび統合テスト、81のコントロールパネルテストが通過しています。crates.ioは引き続きv1リリースを公開しています。

ADK Gatewayはウェブサイトホスティングサービスではなく、ソースベースのソフトウェアとして提供されています。ローカルのv2移行は検証済みである一方、crates.ioはv1のままです。メッセージングチャネル、モデルプロバイダー、外部MCPツール、永続的バックエンド、および本番環境のセキュリティはオペレーターの資格情報とデプロイ設定に依存しています。実験的なコード生成とAWPコマースはソースドキュメントで明示的に制限されています。

運用レイヤーを構築する

1つのチャネルを接続。1つのリクエストをルーティング。すべての決定を可視化。

検証済みv2ソースから開始。リポジトリにはゲートウェイ、埋め込みコントロールパネル、設定リファレンス、チャネルガイド、デプロイ資産、テストスイートが含まれ、完全なシステムの理解と運用に必要です。