Googles Agents CLI bekommt Erweiterungen: Teams können LangChain und eigene Richtlinien einbinden

Warum Google ein Erweiterungssystem gebaut hat

Google hat Agents CLI auf der Google Cloud Next '26 mit einer zentralen Idee vorgestellt: Der Weg von der Idee zum produktiven Agenten auf Google Cloud soll über eine einheitliche Befehlsoberfläche laufen. Für Teams, die ADK einsetzen, funktioniert dieser Weg laut Google: agents-cli create ausführen, die Agentenlogik schreiben und in etwa dreißig Minuten mit angebundener Observability und Evals auf Cloud Run ausliefern.

Die Framework-Landschaft ist seither vielfältiger geworden. Neben ADK greifen Entwickler zu LangChain und LangGraph, zu neueren Optionen wie Deep Agents oder zu hauseigenen Frameworks für einen bestimmten Fachbereich. Außerdem möchten Unternehmensadmins womöglich Governance-Vorgaben über den gesamten Entwicklungszyklus von Agenten durchsetzen, etwa einen Compliance-Scan, ein SSO-Gate oder einen Zwischenschritt im Model Risk Management.

Die Autoren Pier Paolo Ippolito und Elia Secchi beschreiben drei unbefriedigende Optionen, wenn die Toolchain an ein einzelnes Framework gebunden ist: die CLI forken und dauerhaft den Wartungsaufwand tragen, sie mit eigenen Skripten umhüllen, die Entwickler und ihre Coding-Assistenten möglicherweise umgehen, oder alles von Grund auf neu bauen, was mehrere Entwicklermonate dauern kann.

Google verweist außerdem auf eine Trennung innerhalb des Tools selbst. Sechs Befehle setzen die ADK-Runtime voraus: playground, run und vier Eval-Unterbefehle. Die übrigen rund achtzehn, darunter scaffold, infra, deploy, publish und login, sind frameworkunabhängig. Ohne Erweiterungen bedeutete die Wahl eines anderen Frameworks als ADK in einem Projekt, auf alle vierundzwanzig Befehle zu verzichten.

So funktionieren Erweiterungen

Eine Erweiterung ist ein Verzeichnis in einem Git-Repository mit einer einzigen Datei, agents-cli-extension.yaml. Die Datei legt fest, welche eingebauten Befehle sie überschreibt und welche neuen sie hinzufügt. Ein Override ersetzt einen integrierten Befehl wie playground, deploy oder eval generate und erhält die Argumente des Nutzers unverändert, sodass sich die Bedienung wie beim nativen Befehl anfühlt. Ein neuer Befehl erscheint als agents-cli <your-command>. Beides kann in derselben Erweiterung stecken.

Die Verteilung läuft über Git statt über eine eigene Paketregistry. Laut Google orientiert sich dieses Design am Erweiterungsmodell des Projekts gemini-cli. Es gibt keinen zentralen Index und kein Paketformat, das gepflegt werden müsste. Jedes Verzeichnis in jedem Git-Repository kann eine Erweiterung sein, und Git übernimmt Versionierung, Pinning und Verteilung. Plattformteams in Unternehmen können ein internes Repository für Plattform-Erweiterungen anlegen und Entwickler darauf verweisen.

Erweiterungen lassen sich auf mehrere Arten referenzieren:

• Kurzschreibweise für Erweiterungen von Google, aufgelöst auf das Repository google/agents-cli, mit agents-cli extension add <name>
• Jede GitHub-Organisation oder jedes Repository, auch auf selbst gehosteten Git-Servern, etwa acme/platform-extensions
• Ein Fragment wie #soc2-deploy, um aus einem Repository mit mehreren Erweiterungen eine auszuwählen
• Ein lokaler Pfad, der meist bei der Entwicklung von Erweiterungen zum Einsatz kommt

Es gibt zwei Installationsbereiche. Der Standardbereich, das Projekt, schreibt die Erweiterung und ihren Lockfile-Eintrag ins Projekt-Repository, sodass Teamkollegen und CI sie beim Checkout automatisch erhalten. Der Nutzerbereich, aktiviert mit dem Flag --global, gilt für alle Projekte auf dem Rechner und eignet sich für Erweiterungen, die schon vor dem Anlegen eines Projekts gebraucht werden. Definieren beide Bereiche denselben Befehl, gewinnt der Projektbereich, und agents-cli info zeigt die Quelle jedes aktiven Befehls an. Laut Google führt das System Erweiterungen nie stillschweigend zusammen und überschreibt sie auch nicht; Konflikte werden bei der Installation oder in der Erweiterungsliste sichtbar.

Lockfile, LangChain und worauf zu achten ist

Das System folgt der Disziplin von Paketmanagern wie uv oder npm. Es löst eine Git-Referenz bei der Installation auf einen exakten Commit-SHA auf und hält ihn in einem Lockfile fest. Der Befehl agents-cli install stellt die mitgelieferte Kopie aus dem fixierten SHA wieder her, ohne ihn weiterzuschieben. Das garantiert laut Google, dass CI und lokale Entwicklung bitgenau denselben Code ausführen. agents-cli extension update löst die Referenz neu auf und fragt erneut das Vertrauen gegenüber Drittanbietern ab.

Erweiterungen kamen mit Version 1.5.0. Version 1.8.0 ergänzt die LangChain-Erweiterung von Google, die die frameworkgebundenen Befehle durch LangChain-Entsprechungen ersetzt und den Rest des Lebenszyklus unangetastet lässt. Der Beitrag führt durch Scaffolding, Ausführung, Deployment und Evaluierung eines LangChain-Agenten und baut dann eine kleine eigene Erweiterung, die den Deploy-Befehl um einen Scan der Software Bill of Materials (SBOM) ergänzt, als Muster für Plattformteams, die eigene Richtlinien durchsetzen.

Eine Einschränkung gibt es: Das Extension System ist in v1.8.0 als experimentell gekennzeichnet, und Google weist darauf hin, dass sich Manifest-Schema und Befehlsumfang noch inkompatibel ändern können. Teams, die darauf bauen, sollten ihre Agents-CLI-Version fixieren.

Für Teams mit LangChain oder hauseigenen Frameworks bedeutet die Neuerung, dass sie die Deployment- und Lifecycle-Werkzeuge von Agents CLI behalten können, ohne zu ADK zu wechseln. Regulierten Organisationen bietet sie die Möglichkeit, Vorgaben für Deployment, Login oder Evaluierung zentral durchzusetzen, ohne einen Fork zu pflegen.