Multi-Channel Agentenbetrieb
ADK Gateway verbindet Messaging-Kanäle, Webanwendungen und andere Agenten mit einem Team von ADK-Rust-Agenten. Es leitet jede Anfrage weiter, stellt den richtigen Kontext wieder her, wendet Betriebsvorschriften an und gibt Entwicklern einen Ort, um das System zu sehen und zu steuern.
Personen und Systeme
Identität · Router · Runner
Agententeam
Warum ein Gateway?
Ein ADK-Rust-Agent kann schlussfolgern, Tools aufrufen und Ereignisse streamen. Eine reale Implementierung muss auch praktische Fragen beantworten: Wo kommen Anfragen an? Welcher Agent soll sie erhalten? Wessen Sitzung soll wiederhergestellt werden? Was darf dieser Agent tun?
ADK Gateway stellt diese gemeinsame Betriebsschicht bereit. Telegram, Slack, WhatsApp, Discord, Matrix, Webhooks und agentenorientierte Webanfragen gelangen über Adapter herein. Das Gateway wandelt sie in eine einheitliche Nachrichtenform um, wendet Zugriffsregeln an, leitet sie an ein System- oder Spezialistenagenten weiter und liefert den Fortschritt über den ursprünglichen Kanal zurück.
Das Gateway fasst nicht jeden Agenten zu einem Assistenten zusammen. Entwickler können Forschungs-, Support-, Betriebs- und Programmieragenten getrennt halten – mit unterschiedlichen Modellen, Werkzeugen, Arbeitsbereichen, Berechtigungen und Kanalbindungen – und sie dennoch über eine Steueroberfläche betreiben.
Architektur
Lesen Sie die Architektur von links nach rechts. Anfragen kommen über menschliche oder Agenten-Kanäle herein. Identität und Routing entscheiden, wohin sie gehören. ADK-Rust führt den ausgewählten Agenten mit eigenem Zustand und Fähigkeiten aus. Die Steuerungsebene beobachtet jede Ebene, ohne Teil des Gesprächs zu werden.
Einstiegspunkte
Vertrauensgrenze
Gateway-Laufzeit
Agententeam
Funktionen
Operator-Steuerungsebene
Konfigurieren, genehmigen, beobachten, wiederherstellen und auditieren Sie den kompletten Anforderungspfad.
Einer Anfrage folgen
Der gleiche Ablauf gilt für jeden unterstützten Kanal. Nur Adapter und Lieferformat ändern sich; Routing, Sitzungen, Agentenausführung, Richtlinien und Beweise bleiben geteilt.
Telegram, Slack, WhatsApp, Discord, Matrix und Webhooks kommen in unterschiedlichen Formaten an. Jeder Adapter wandelt sie in denselben eingehenden Nachrichtenvertrag um.
Kopplungsregeln, Zulassungslisten, Gruppen-Erwähnungsrichtlinien, Multi-User-Identität, Ratenbegrenzungen und optionale JWT-Prüfungen werden ausgeführt, bevor die Anfrage einen Agenten erreicht.
Routing prüft Kanal, Konto sowie Person oder Gruppe. Die spezifischste Übereinstimmung gewinnt; der Systemagent ist die letzte Rückfalloption.
Der Runner hängt vor Beginn der Agentenausführung die korrekte Sitzung, Benutzerkontext, Speicher, Abbruchstatus und Modell-Fallback-Kette an.
Der ausgewählte Agent kann seine Rust-Werkzeuge, MCP-Server, Wissen, Workflows oder einen genehmigten ACP-Coding-Agenten verwenden. Die Rollenrichtlinie begrenzt, was er aufrufen darf.
Getippte Ereignisse werden zu Tippindikatoren, Fortschrittsmeldungen, Bildern oder einer finalen Antwort. Metriken, Protokolle, Aufgabenverlauf und Audit-Ereignisse erklären, was passiert ist.
Routing in Rust
Ein Entwickler kann einen Agenten an einen ganzen Kanal, ein Konto auf diesem Kanal oder eine bestimmte Person oder Gruppe binden. Der Router prüft zuerst die spezifischste Regel und fällt dann vorhersehbar zurück.
Das Beispiel fasst die Quellimplementierung zur besseren Lesbarkeit zusammen. Das Repository testet exaktes, konto-, kanal-, legacy- und standardmäßiges Routing-Verhalten.
/// 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)
}{
"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
}]
}Eingebettetes Bedienfeld
Das React-Bedienfeld wird in die Rust-Binärdatei kompiliert und bereitgestellt unter /ui. It is the operator interface for configuration, agent lifecycle, approvals, sessions, memory, scheduled work, logs, and health.
Wähle Modellanbieter, speichere Zugangsdaten, verbinde Kanalaccounts und validiere das Gateway, bevor du es für Nutzer öffnest.
Erstellen Sie Spezialisten, weisen Sie Werkzeuge und Kanäle zu, starten oder stoppen Sie deren Prozesse und definieren Sie, welche Agenten Arbeit delegieren dürfen.
Überprüfen Sie sensible Werkzeugaufrufe, koppeln Sie Benutzer, beenden Sie Sitzungen, prüfen Sie Einwilligungen und greifen Sie ein, wenn eine Aufgabe nicht fortgesetzt werden sollte.
Kanäle und Agenten in Echtzeit beobachten, Fehler prüfen, Speicher durchsuchen und die Gesundheit des laufenden Gateways verfolgen.
Protokollgrenzen öffnen
Kanäle verbinden das Gateway mit Menschen. Protokolle verbinden es mit Fähigkeiten und anderer Software. Jede Grenze hat eine eigene Aufgabe, sodass Entwickler eine hinzufügen können, ohne die gesamte Laufzeit neu zu gestalten.
MCP
Verbinden Sie Fähigkeitsserver für Browser, Computer, Medien, Daten und Geschäftssysteme. Das Gateway kann konfigurierte MCP-Server hinzufügen, auflisten und entfernen, ohne jede Integration in seine Binärdatei einzubinden.
ACP
Führen Sie unterstützte Coding-Agent-Prozesse hinter einer überwachten Grenze aus. Workspace-Richtlinien, Berechtigungsanfragen, Fortschritt, Kosten, Warteschlangenstatus und Aufgabenverlauf bleiben für das Gateway sichtbar.
AWP
Veröffentlichen Sie Discovery, Fähigkeiten, Gesundheitsstatus, Einwilligungen, Abonnements und einen Agenten-Nachrichtenendpunkt, damit andere Software mit dem Gateway arbeiten kann.
HTTP + WebSocket
Eingehende Webhooks bringen Arbeit aus anderen Anwendungen. HTTP-APIs und Live-WebSocket-Ereignisse steuern das eingebettete Bedienfeld und externe Operationstools.
Aktuelle Grenze: die Quelle stellt ihre agent-message-Route unter der AWP-Oberfläche bereit. Die Seite beansprucht keine separat verifizierte, vollständige A2A-Server-Oberfläche oder Produktions-AWP-Commerce-Implementierung.
Governance
Agentenautonomie sollte eine konfigurierte Betriebsentscheidung sein. ADK Gateway platziert Identität, Autorität, Grenzen und Nachweise entlang desselben Ausführungspfads, der die Anfrage trägt.
Kopplung, Zulassungslisten, Multi-User-Sitzungen, JWT/JWKS und Rollen-Mapping beantworten, wer die Anfrage stellt.
Pro-Agent Zulassungs- und Ablehnungsregeln sowie Tool-Freigaben bestimmen, welche Funktionen eine Person oder ein Agent nutzen darf.
Ratenbegrenzung, Anforderungs-Timeouts, Abbruch, begrenzte Tool-Schleifen und Gesundheitsrichtlinien begrenzen die Arbeitsdauer.
Audit-Ereignisse, Logs, Metriken, Aufgabenverlauf, Tool-Ergebnisse und Gesundheitsverlauf liefern ein Betriebsprotokoll.
Bereitstellung
Eine Entwicklerarbeitsstation, ein interner Server oder ein Container können dieselbe Gateway-Form ausführen. Die Sitzungsdaten können für ein lokales Experiment im Speicher bleiben oder für ein eingesetztes System zu SQLite, PostgreSQL, Redis oder Firestore wechseln.
Der Rust-Dienst bettet das kompilierte React-Bedienfeld ein. Installieren oder kopieren Sie eine ausführbare Datei und halten Sie die Konfiguration daneben.
Das Repository enthält eine Dockerfile sowie dokumentierte Volume- und Port-Verträge für Container-Bereitstellung.
Eine systemd-Einheit unterstützt Boot-Start, Neustart-Richtlinie, Bereitschaft, Protokolle und vom Betreiber verwaltete Umgebungsdateien.
Eine launchd-Definition startet ein persistentes lokales Gateway für Entwickler- und Arbeitsstationsagenten.
Migration und Verifikation
Die Produktfunktionen auf dieser Seite stammen aus der lokalen Gateway-Quelle, Konfiguration, Dokumentation und Testsuiten. Die ADK-Rust v2-Migration besteht nun die Verifikation von Bibliothek, Eigenschaft, Integration, generiertem Agenten und Bedienfeld.
Kanaladapter, Nachrichtenrouting, Agentenregistrierung, Prozesslebenszyklus, Sitzungen, Speicher, RAG, geplante Aufgaben, Werkzeugfreigabe, Zugriffskontrolle, Steuerungsfeld-Routen, AWP, MCP, ACP-Integration, Bereitstellungsressourcen und Tests befinden sich im überprüften Repository.
Jede ADK-Abhängigkeit verweist auf den lokalen 2.0-Arbeitsbereich. Rust 2024 und Rust 1.95 kompilieren für alle Ziele und Funktionen. Alle 845 Bibliothekstests, 276 eigenständigen Eigenschafts- und Integrationstests sowie 81 Steuerungsfeldtests bestehen.
Der verifizierte v2-Zustand ist derzeit eine lokale Quellmigration, keine veröffentlichte adk-gateway v2 Crate. Die Installationsanleitung sollte weiterhin zwischen einem Quell-Checkout und der crates.io v1-Version unterscheiden.
Jeder Messaging-Anbieter, Modellanbieter, externe MCP-Server, persistenter Backend, Identitätsanbieter und Produktionsbereitstellung benötigt weiterhin Anmeldeinformationen, Infrastruktur und Sicherheitsüberprüfung durch den Betreiber.
Die Multi-Agenten-Codegenerierung dokumentiert noch Platzhalter-A2A-Endpunkte, und AWP Commerce ist deklariert, aber nicht als vollständiges Transaktionssystem implementiert. Keines davon wird hier als produktionsbereit dargestellt.
Quellenüberprüfung: Alle ADK-Abhängigkeiten verweisen auf den lokalen v2.0.0-Arbeitsbereich, das Projekt zielt auf Rust 2024 mit MSRV 1.94 ab, und die Kompilierung für alle Ziele/alle Features besteht. Die Verifikation besteht 845 Bibliothekstests, 276 eigenständige Property- und Integrationstests sowie 81 Kontrollpanel-Tests; crates.io veröffentlicht weiterhin die v1-Version.
ADK Gateway wird als quellbasiertes Softwareprodukt präsentiert, nicht als webgehosteter Dienst. Die lokale Migration auf v2 ist verifiziert, während crates.io weiterhin v1 verwendet. Messaging-Kanäle, Modellanbieter, externe MCP-Tools, persistente Backends und Produktionssicherheit hängen von Betreiberanmeldedaten und Bereitstellungskonfiguration ab; experimentelle Codegenerierung und AWP-Commerce bleiben in der Quell-Dokumentation ausdrücklich eingeschränkt.
Baue die Betriebsschicht
Starten Sie von der verifizierten v2-Quelle. Das Repository enthält das Gateway, das eingebettete Bedienfeld, Konfigurationsreferenzen, Kanal-Anleitungen, Deployment-Assets und Testsuiten, die zum Verständnis und Betrieb des kompletten Systems benötigt werden.