Agent Client Protocol: ein Drahtformat zwischen Editor und Agent

ACP: ein Drahtformat zwischen Editor und Codieragent

Das Agent Client Protocol, kurz ACP, standardisiert die Kommunikation zwischen Code-Editoren und Codieragenten. Die Begriffe sind im README ungewöhnlich sauber gefasst. Ein Editor ist ein interaktives Programm zum Ansehen und Bearbeiten von Quellcode, ein Codieragent ein Programm, das generative KI einsetzt, um Quellcode selbstständig zu verändern. ACP legt fest, was beide Seiten austauschen.

Das Repository dahinter ist in Rust geschrieben, lizenziert unter Apache-2.0, der Standardzweig heißt main, und die Projektseite liegt unter agentclientprotocol.com. Der letzte erfasste Stand datiert vom 20. August 2026. Für den Protokollkern zählt genau eine Zahl: Die aktuelle stabile Protokollfassung ist 1.

Warum so etwas gebraucht wird, verrät der Untertitel, ein Protokoll, das jeden Editor mit jedem Agenten verbindet. Ohne gemeinsames Drahtformat entsteht aus n Editoren und m Agenten eine Matrix aus n mal m Einzelanbindungen, und jede davon will gepflegt werden.

Zwei Rust-Crates: schema gegen Laufzeit

Dieses Repository enthält nicht die Laufzeitbibliothek, sondern die Typenebene. Die Rust-Crate im Wurzelverzeichnis heißt agent-client-protocol-schema und liegt auf crates.io. Sie stellt das Datenmodell für die ACP-Nachrichten bereit: Anfragen, Antworten, Benachrichtigungen, den JSON-RPC-Umschlag und Typen für die Protokollfassung.

Das README ist an dieser Stelle unmissverständlich. Wer einen ACP-Agenten oder einen ACP-Client in Rust baut, soll mit der höheren Laufzeit-Crate agent-client-protocol beginnen, die die Client- und die Agenten-Schnittstellen bereitstellt. Die Schema-Crate ist die Fläche darunter und dann die richtige Wahl, wenn direkter Zugriff auf Protokolltypen, werkzeugnahe Verarbeitung des Schemas oder Eingaben für die Code-Erzeugung gebraucht werden.

Für beide Wege gibt es Beispielcode in Rust, examples/agent.rs und examples/client.rs. Diese Trennung in zwei Crates ist die erste Entscheidung, die ein Rust-Projekt treffen muss, und das README beantwortet sie eindeutig: Wer eine Anwendung baut, nimmt die Laufzeit-Crate.

Vier Versionszahlen und warum nur protocolVersion zählt

Die Versionslage ist gewöhnungsbedürftig und der aufschlussreichste Teil des gesamten Repositories. Am 20. August 2026 erschienen drei Ausgaben nebeneinander: Rust Crate v1.7.0, Schema v1.21.0 und Schema v2.0.0-alpha.3. Zusammen mit der Protokollfassung 1 sind das vier Zahlen mit vier Bedeutungen, und keine der drei Ausgabenummern beschreibt das Drahtprotokoll.

Die Fassung der Rust-Crate und die Fassung der Schema-Ausgaben beschreiben die Artefakte selbst, also die Rust-Schnittstelle, den Aufbau der erzeugten Schemadateien und deren Ablage. Die Drahtkompatibilität wird getrennt davon beim Vorgang initialize über das Feld protocolVersion ausgehandelt. Auch das Feld version in den Dateien schema/*/meta*.json nennt die Protokollfassung, die das jeweilige Schema abbildet.

Die Folgerung wiegt schwer. Zwei Ausgaben der Schema-Artefakte können dieselbe drahtkompatible Protokollfassung beschreiben und trotzdem unterschiedlich aufgebaut sein, etwa weil Definitionen anders geordnet, benannt oder ausgegeben werden. Das verändert die Arbeitsweise von Code-Erzeugern, nicht die ausgetauschten Nachrichten.

Schema-Artefakte unter schema/v1 und schema/v2

Die erzeugten Schema-Artefakte liegen in den Verzeichnissen schema/v1 und schema/v2. Das Schema der stabilen Fassung ist unmittelbar im Repository unter schema/v1/schema.json zu finden. Bei einer Schema-Ausgabe werden die versionierten json-Dateien zusätzlich an die passende schema-v-Ausgabe auf GitHub angehängt, und genau dort sollen Erzeuger und andere Automatisierung sie herunterladen. Das README nennt diese Ausgaben die empfohlene Bezugsfläche.

Die Bezeichnung schema-v2.0.0-alpha.3 deutet an, was kommt. Eine zweite Schemafassung liegt als Alpha vor, während die stabile Protokollfassung weiterhin 1 ist. Wer heute einen Erzeuger baut, sollte sich bewusst für eine Bezugsquelle entscheiden, statt Dateien aus dem Quellbaum zu ziehen, und die Artefaktfassung anschließend festhalten.

Innerhalb einer Protokollfassung entscheidet nicht die Nummer, sondern das Ergebnis des Aushandlungsvorgangs, welche optionalen Nachrichten und Merkmale unterstützt werden. Das README formuliert das als Nutzung der ausgetauschten Fähigkeiten. Eine Prüfung der Versionsnummer allein reicht damit nicht aus.

Offizielle SDKs für Kotlin, Java, Python, Rust und TypeScript

Für die Umsetzung gibt es offizielle Bibliotheken in fünf Sprachen. Für Kotlin heißt das Paket acp-kotlin und unterstützt nach README-Angabe die JVM; weitere Ziele sind in Arbeit, Beispiele liegen in einem eigenen samples-Verzeichnis. Für Java gibt es java-sdk, für Python python-sdk, beide mit eigenen Beispielverzeichnissen.

Bei Rust ist die Lage zweigeteilt, wie oben beschrieben. Die Laufzeit-Crate agent-client-protocol ist der Einstieg, die Schema-Crate das Fundament darunter. Für TypeScript heißt das Paket @agentclientprotocol/sdk und liegt auf npm, Beispiele liegen in einem Verzeichnis src/examples.

Darüber hinaus verweist das Projekt auf eine Seite mit Bibliotheken aus der Gemeinschaft. Welchen Reifegrad diese Bibliotheken haben und ob alle dieselbe Protokollfassung abdecken, sagt das README nicht. Diese Prüfung bleibt bei der anwendenden Person, und bei einem Protokoll mit mehreren Artefaktfassungen ist sie keine Formalie.

Die Alternative Direktintegration und ihre N-mal-M-Lücke

Die Alternative zu ACP ist keine einzelne Bibliothek, sondern die geübte Praxis. Jeder Codieragent bringt seine eigene Anbindung an die Editoren mit, die er bedienen will. Der Aufwand wächst auf beiden Seiten mit der Zahl der Teilnehmer, und jede neue Kombination wird ein eigenes kleines Projekt mit eigener Fehlerfläche.

ACP kehrt das um, indem es eine Schnittstelle in der Mitte festlegt. Editor und Agent implementieren je einmal gegen das Protokoll, alle weiteren Kombinationen ergeben sich daraus. Der Preis ist eine zusätzliche Schicht, deren Merkmalsumfang durch das Aushandeln begrenzt wird. Was die Protokollfassung 1 nicht vorsieht, lässt sich zwischen zwei ACP-Teilnehmern nicht vereinbaren, auch wenn beide mehr könnten.

Hinzu kommt ein zweiter Preis, den das README beschreibt, ohne ihn so zu nennen. Veränderungen am Protokoll folgen einem strukturierten Verfahren, das in CONTRIBUTING.md beschrieben ist. Eine Erweiterung, die ein einzelner Agent dringend braucht, läuft damit durch einen Prozess, der auf breite Annahme ausgelegt ist und nicht auf Geschwindigkeit.

Apache-2.0 ohne CLA und was hier fehlt

Lizenziert ist das Repository unter Apache-2.0. Bemerkenswert ist die Beitragsregel: Es wird keine Vereinbarung über die Einräumung von Nutzungsrechten verlangt, also kein CLA. Wer beiträgt, stimmt zu, dass der Beitrag unter Apache-2.0 steht, und bestätigt, das Recht daran zu haben und keinen fremden Code einzubringen.

Das ist eine bewusste Entscheidung gegen eine Hürde, die bei Projekten mit mehreren beteiligten Unternehmen sonst üblich ist. Für ein Protokoll, das auf breite Annahme zielt, senkt das die Schwelle für einzelne Beitragende erheblich, und es erklärt, warum der Änderungsprozess selbst so stark formalisiert ist.

Was fehlt, ist ebenso deutlich zu benennen. Das Repository beschreibt Schemadateien und Bibliotheken, aber keine Befehle, um einen Agenten oder einen Client zu starten, zu installieren oder zu konfigurieren. Diese Anleitungen liegen bei den einzelnen SDKs und auf der Projektseite. Wer ACP einsetzen will, beginnt deshalb nicht in diesem Repository, sondern bei der Bibliothek der eigenen Sprache und bei schema/v1/schema.json.

Redaktionelles Fazit

ACP passt zu Entwicklern von Editoren und von Agenten, die eine Anbindung einmal bauen und gegen viele Gegenstellen wiederverwenden wollen, sowie zu Teams, die aus dem Schema einen Client erzeugen. Der Einstieg führt über die passende SDK und die Schema-Artefakte der schema-v-Ausgaben, nicht über dieses Repository. Weniger geeignet ist es für Vorhaben, die eigene Merkmale rasch über die Leitung schieben müssen, weil Änderungen am Protokoll durch ein strukturiertes Verfahren laufen und die stabile Fassung bei 1 liegt. Wer einsteigt, sollte zuerst prüfen, welche protocolVersion die eigene Bibliothek aushandelt, und die Artefaktfassung des Schemas festhalten.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes