ADK-Rust v2: Vom Agenten-Framework zur Produktionslaufzeit.
Die Geschichte, wie Tools, Workflows, Zustände, Echtzeitmedien, Coding Agents, offene Protokolle und Betriebssteuerungen zu einem zusammensetzbaren Rust-System wurden.
Im März veröffentlichten wir die Geschichte von ADK-Rust v0.5. Dieses Release erweiterte die Fähigkeiten des Frameworks: Retrieval, Code-Ausführung, zusätzliche Modell-Provider, persistente Graphen, verschlüsselte Sessions und ein CLI, das ein nützliches Startprojekt erstellen konnte.
Die nächste Frage war schwieriger. Konnten diese Fähigkeiten zu einem Produktionssystem werden, das ein Entwickler zusammensetzen, beobachten, sichern, bereitstellen und am Laufen halten konnte? Der Weg zu v2 ist die Antwort. Er verwandelte ADK-Rust von einem wachsenden Agenten-Toolkit in eine Rust-Laufzeit für Produkte, deren Agenten sprechen, Tools verwenden, Arbeit koordinieren, Artefakte erstellen und über offene Protokolle zusammenarbeiten.
Lesen Sie das vorherige Kapitel: ADK-Rust v0.5Der Weg zu v2
Sechs Monate, um Agenten-Funktionen in ein System zu verwandeln.
Jedes Release löste einen anderen Teil des Produktionsproblems. Zusammen veränderten sie, was Entwickler vernünftigerweise um eine Rust-Laufzeit herum aufbauen können.
Das Framework lernte mehr Arten von Arbeit
RAG, Code-Ausführung, Provider-Verbesserungen, persistente Graphen, verschlüsselte Sessions und cargo-adk erweiterten die Möglichkeiten eines Rust-Agenten.
Agenten überschritten echte Systemgrenzen
A2A erreichte vollständige Remote-Task-Flows. AWP gab Websites eine Agenten-Schnittstelle. MCP-Server erhielten verwaltete Lebenszyklen, während Speicher und gemeinsam genutzter Zustand für größere Produkte sicherer wurden.
Komposition wurde zu einem Entwicklererlebnis
Feature-Tiers reduzierten die Standard-Abhängigkeitsoberfläche. ACP kam hinzu, Schemas passten sich an jeden Modell-Provider an, und Templates plus Add-ons machten Architektur zu einer Wahl statt einer Kopierübung.
Die Grundlage wurde stabil
Neununddreißig Crates erreichten die stabile Stufe mit semantischen Versionsverwaltungs-Verpflichtungen, stärkeren Dokumentations-Gates, Sicherheitsarbeit, Evaluierung, verwalteten Laufzeiten und Enterprise-Deployment-APIs.
Die Laufzeit wurde zum Produkt-Rückgrat
CodingAgent und CodeAct traten der Agenten-Familie bei. Tool-Aufrufe, Fortschritt, Ergebnisse, Abbruch, Echtzeitmedien, Wissensgraphen-Speicher und offene Protokolle durchlaufen nun explizite Laufzeitverträge.
Der Wendepunkt
Ein Produktionsagent ist viel mehr als ein Modellaufruf.
Frühe Agentenbeispiele konzentrierten sich natürlich auf einen Prompt, ein Modell und eine Antwort. Echte Produkte zeigten schnell den Rest der Arbeit: entscheiden, wer ein Tool aufrufen kann, den Zustand bewahren, Fortschritt anzeigen, nach einer Genehmigung fortfahren, eine generierte Datei verschieben, einen Fehler verfolgen und mit Diensten sprechen, die einem anderen Team gehören.
v2 behandelt diese Verantwortlichkeiten als Framework-Belange mit Rust-Verträgen. Das Modell bleibt wichtig, läuft aber innerhalb eines Aufrufs mit Tools, Sessions, Events, Callbacks, Grenzen und Betriebsrichtlinien. Sie können das Modell ersetzen, ohne das Produkt darum herum neu zu gestalten.
Das ist die architektonische Verschiebung hinter der Hauptversion: Agentenverhalten und Produktinfrastruktur treffen sich nun in derselben Laufzeit, bleiben aber getrennt genug, um sie zu komponieren und zu testen.
Die v2-Architektur
Verfolgen Sie eine Aufgabe durch das gesamte Produkt.
Eine Anfrage kann über eine menschliche Schnittstelle oder ein Agentenprotokoll eingehen. Der Runner gibt ihr Kontext, ruft die richtige Agentenform auf und streamt typisierte Ereignisse, während Tools, Zustand und Betriebssteuerungen die Arbeit unterstützen.
Menschen und Systeme
Produktoberflächen
Ein Ausführungsvertrag
Runner und typisierter Ereignisstrom
Wählen Sie die Form der Arbeit
Zusammensetzbare Agenten
Geben Sie den Agenten nützliche Reichweite
Tools, Wissen und Zustand
Produktion verständlich halten
Betriebssteuerungen
Innerhalb des Prozesses
Agenten, Tools, Sessions, Callbacks, Ereignisse und Abbruch teilen sich Rust-Traits und -Typen.
Über eine Grenze hinweg
MCP, A2A, ACP, AWP, HTTP und Echtzeit-Transporte verbinden Systeme mit unterschiedlichen Besitzern.
Für das Produkt sichtbar
Derselbe Ereignisstrom kann ein CLI, eine Web-UI, einen API-Client, einen Trace-Viewer oder einen Remote-Agenten steuern.
So funktioniert es
Der Ausführungspfad ist eine Produktschnittstelle.
Ein nützlicher Agent muss mehr zeigen als seinen letzten Satz. v2 gibt jedem bedeutsamen Schritt einen Platz im Ereignisstrom, sodass Entwickler Schnittstellen um die laufende Arbeit herum aufbauen können.
Anfrage
Eine Person, ein Dienst oder ein Agent startet die Arbeit.
Entscheiden
Ein Agent oder Workflow wählt die nächste bedeutsame Aktion.
Handeln
Ein Tool, Spezialist, Modell oder Remote-System führt den Schritt aus.
Streamen
Typisierte Ereignisse übermitteln Aufrufe, Fortschritt, Ergebnisse und Zustandsänderungen.
Fortsetzen
Die Laufzeit antwortet, pausiert für Eingaben, versucht es erneut oder wird später fortgesetzt.
Stellen Sie sich einen CodingAgent vor, der eine Testsuite ausführt. Die UI empfängt den Tool-Aufruf, zeilenweise stdout und stderr, das typisierte Ergebnis, alle Zustands- oder Artefaktänderungen und die nächste Entscheidung des Agenten über einen korrelierten Stream. Wenn die Aufgabe eine Genehmigung erfordert oder der Prozess unterbrochen wird, bieten die Session und der Checkpoint einen klaren Punkt zum Fortsetzen.
Was v2 einem Entwickler bietet
Ein Framework für den Agenten-Lebenszyklus.
Sie können mit einem konversationellen Agenten beginnen und Struktur nur dann hinzufügen, wenn das Produkt sie benötigt. Dieselben Kernverträge bleiben bestehen, während das System wächst.
Agenten können auf verschiedene Weisen arbeiten
Verwenden Sie einen LLM-Agenten für flexibles Denken, deterministische Workflow-Agenten für bekannte Sequenzen, Graphen für Verzweigungen und persistente Arbeit, Echtzeit-Agenten für Sprache und Video, CodingAgent für Repository-Arbeit oder CodeAct, wenn ein Modell eine mehrstufige Aktion als ausführbaren Code ausdrücken soll.
Fortschritt ist Teil der API
Tool-Aufrufe und Tool-Ergebnisse sind typisierte Ereignisse. Langlaufende Tools können Fortschritt in denselben Stream wie die Agentenantwort ausgeben, wobei Aufruf-IDs die Anfrage, Live-Ausgabe und das Endergebnis verknüpfen. Eine UI kann die Arbeit rendern, ohne Logs zu scrapen.
Zustand kann einen Modell-Durchlauf überdauern
Sessions bewahren die Konversation, Artefakte speichern generierte Dateien, Graphen-Checkpoints setzen Workflows fort, und semantischer oder bi-temporaler Wissensgraphen-Speicher gibt Agenten Kontext, der über spätere Sessions hinweg nützlich bleibt.
Offene Protokolle haben klare Aufgaben
MCP verbindet Tools und Ressourcen, A2A verbindet unabhängig bereitgestellte Agenten, ACP verbindet CodingAgent-Clients und -Server, und AWP gibt einer Website eine strukturierte Schnittstelle für Agenten neben ihrer menschlichen Schnittstelle.
Autonomie hat operative Grenzen
Autorisierungs-Callbacks, bereichsbezogene Tools, Guardrails, Genehmigungen, Sandbox-Richtlinien, Abbruch, Telemetrie, Evaluierung und Audit-Nachweise ermöglichen es einem Team zu entscheiden, was ein Agent tun darf, und zu überprüfen, was danach geschah.
Sie kompilieren das Produkt, das Sie benötigen
Die minimale Stufe hält einen ersten Agenten klein. Standard fügt den gängigen Produktions-Stack hinzu; Enterprise fügt Echtzeit, Browser, RAG, Zahlungen und AWP hinzu; Full fügt die umfangreichsten Audio- und Ausführungsfunktionen hinzu. Einzelne Funktionen bleiben verfügbar, wenn ein Preset zu breit ist.
Das Starterlebnis
Wählen Sie eine Arbeitsform, dann machen Sie sie zu Ihrer eigenen.
Das v2 CLI kann die Ausführungsform gerüstet und die umgebenden Funktionen hinzufügen. Das generierte Projekt sieht immer noch aus wie Rust, das Sie selbst schreiben und überprüfen würden.
Erstellen und überprüfen
cargo install cargo-adk
cargo adk new support-agent \
--template tools \
--addon sessions \
--addon telemetry \
--addon guardrails
cd support-agent
cargo adk build
cargo runDen Agenten komponieren
let agent = LlmAgentBuilder::new("support")
.description("Resolves customer issues")
.instruction("Use the reviewed tools and cite evidence.")
.model(Arc::new(model))
.tool(Arc::new(LookUpOrder))
.before_tool(approval_gate)
.build()?;
Launcher::new(Arc::new(agent))
.run()
.await?;Zwölf Templates decken gängige Startarchitekturen ab. Neun Add-ons komponieren Funktionen wie Sessions, Telemetrie, MCP, Auth, Browser-Tools und Guardrails. Fünf Enterprise-Muster bieten größere Bereitstellungsformen. cargo adk build überprüft das generierte Projekt vor der Bereitstellung.
Gegen die v2-Quelle verifiziert
Die Details hinter der Geschichte.
Das nächste Kapitel beginnt mit einem echten Agenten
Bauen Sie den ersten Workflow. Halten Sie den Weg zur Produktion offen.
Beginnen Sie mit einer Anfrage, einem sichtbaren Tool-Aufruf und einer Session, die Sie verstehen. ADK-Rust v2 bietet diesem kleinen Agenten einen direkten Weg zu Workflows, Speicher, offenen Protokollen, Echtzeit-Schnittstellen, Sicherheit und Bereitstellung, wenn das Produkt dafür bereit ist.