Agent Client Protocol (ACP)

 (agentclientprotocol.com)
15 Punkte von GN⁺ 2025-09-01 | 1 Kommentare | Auf WhatsApp teilen
  • Das Agent Client Protocol (ACP) ist ein Protokoll, das die Kommunikation zwischen Code-Editoren und AI-Coding-Agenten standardisieren soll
  • Bisher war für die Verbindung eines Editors mit einem bestimmten Agenten jeweils eine separate benutzerdefinierte Integration nötig, was zu eingeschränkter Kompatibilität und Developer-Lock-in führte
  • Wie das Language Server Protocol (LSP) bietet ACP eine standardisierte Kommunikationsweise, sodass nach einmaliger Implementierung eine freie Verbindung zwischen allen kompatiblen Editoren und Agenten möglich ist
  • Der Agent wird im Editor als Subprozess ausgeführt und kommuniziert über JSON-RPC over stdio; bei den UI-Elementen werden Diff-Anzeigen und Markdown-basierte Ausgabe unterstützt
  • Derzeit unterstützen unter anderem Zed und Neovim (CodeCompanion-Plugin) ACP; auf Agentenseite ist die Gemini CLI kompatibel, und der Support soll künftig ausgeweitet werden

Einführung

  • Das Agent Client Protocol (ACP) ist ein offenes Protokoll, das entwickelt wurde, um Interaktionen zwischen Server und Client wie Remote-Entwicklung, Port-Forwarding und Befehlsausführung zu standardisieren
  • Bestehendes Problem: AI-Coding-Agenten und Editoren sind eng miteinander verbunden, aber Interoperabilität ist nicht standardmäßig gewährleistet
    • Jeder Editor muss für jeden Agenten, den er unterstützen will, eine benutzerdefinierte Integration bauen
    • Agenten müssen spezifische Editor-APIs implementieren, um Nutzer zu erreichen
    • Das führt zu Integrationsaufwand, eingeschränkter Kompatibilität und Anbieterabhängigkeit für Entwickler
  • Die Lösung von ACP: ACP stellt ein standardisiertes Protokoll für die Kommunikation zwischen Agenten und Editoren bereit
    • Ein Agent mit ACP-Implementierung läuft in allen kompatiblen Editoren
    • Ein Editor mit ACP-Support kann auf das gesamte Ökosystem ACP-kompatibler Agenten zugreifen
    • Das ermöglicht unabhängige Innovation und erlaubt Entwicklern, die für ihren Workflow optimalen Tools zu wählen

Überblick über ACP

  • Funktionsweise: Nutzer arbeiten hauptsächlich im Code-Editor und rufen für bestimmte Aufgaben einen Agenten auf
    • Der Agent läuft als Subprozess des Editors
    • Die Kommunikation erfolgt über JSON-RPC via stdio
  • Datenformat: Es wird das JSON-Format von MCP wiederverwendet, ergänzt um benutzerdefinierte Typen für UX-Elemente von Coding-Agenten wie Diff-Anzeigen
  • Textformat: Für bessere Lesbarkeit wird standardmäßig das Markdown-Format verwendet
    • Dadurch ist reichhaltige Formatierung auch ohne HTML-Rendering möglich
  • Das Protokoll befindet sich derzeit noch in Entwicklung, ist aber bereits ausgereift genug, um interessante User Experiences darauf aufzubauen

Aktueller Support-Status

Fazit

  • Nach dem Vorbild des erfolgreichen LSP verbessert ACP die Interoperabilität zwischen AI-Coding-Agenten und Editoren grundlegend
  • Entwickler sind nicht mehr an einen bestimmten Agenten oder Editor gebunden und können die beste Tool-Kombination frei wählen
  • Die Verbreitung des Protokolls erhöht die Skalierbarkeit des Ökosystems und kann Effizienz und Flexibilität in Entwickler-Workflows steigern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-01
Hacker-News-Kommentare

  • Jemand hat Claude gebeten, ein Kommunikationsprotokoll zwischen AI-Agenten und IDEs/Editoren zu entwerfen, dazu auch Node-, Python- und Rust-Bibliotheken zu entwickeln und sogar eine Website mit Landingpage dafür zu bauen

    • Ehrlich gesagt bin ich versucht zu testen, ob Gemini ein Sublime-Text-Plugin nutzen kann, das dieses Protokoll implementiert; in letzter Zeit scheint sich fast alles auf VSCode zu konzentrieren, weshalb neue Tools oft nur noch dort Unterstützung bieten. Ich möchte nicht gezwungen werden zu wechseln, nur weil Sublime nicht mehr unterstützt wird. Sublime ist wirklich ein großartiger Editor und wird nicht einmal von einem riesigen Unternehmen getragen.

    • Und man könnte es wohl auch absichtlich so bauen, dass es ein Agent wird, der nur Gemini unterstützt, um die eigenen Spuren zu verwischen

    • Lustig, das ist ein viel zu egozentrischer Wunsch

  • Ich hoffe wirklich, dass dieses Projekt gut läuft. Zed kehrt gerade zum eigentlichen Kern von Zusammenarbeit zurück, und ich glaube, das könnte auch die Kategorie der agentischen IDEs verändern. Dann müsste Zed nicht so viel Zeit darauf verwenden, direkt zu konkurrieren, und hätte zugleich ein echtes Alleinstellungsmerkmal. Ich bin gespannt, wie stark das unter CLI-Agenten angenommen wird (es ist schon schön zu sehen, dass Gemini CLI bereits integriert ist). Der harte Wettbewerb im Markt für LLMs und Coding-Assistenten ist immer willkommen, weil solche Veränderungen die Wechselkosten zwischen den Tools hoffentlich weiter senken.

    • Ich bin selbst schon fast bei Zed gelandet. Es hat fast alle Funktionen, die ich mir seit Jahren von einem Editor wünsche, plus viele großartige Dinge, auf die ich selbst nie gekommen wäre. Ich war vom Status quo so enttäuscht, dass ich einmal versucht habe, selbst einen Editor als Prototyp zu bauen, aber ein wirklich guter Editor ist enorm viel Arbeit. Zed hat diese Arbeit geleistet. Ich begrüße sehr, dass sie offen zusammenarbeiten wollen.

    • Ganz ehrlich, ich hoffe, dass diese Veränderung dazu führt, dass diese billigen VS-Code-Forks verschwinden. Zed hätte echte Anerkennung verdient. Es fühlt sich an, als hätten AI-Editoren der Branche förmlich den Sauerstoff entzogen.

  • Ich baue gerade ein Tool, mit dem Claude Code ACP verwenden kann (weil ich CC und Zed oft nutze). Bisher klappt es mit dem Claude Code SDK und der ACP-Client-Bibliothek ziemlich gut. Ein paar Dinge müssen noch aufpoliert werden, aber ich will es morgen etwas weiter verfeinern und dann veröffentlichen.

  • Es gibt bereits ein ACP unter agentcommunicationprotocol.dev, deshalb könnte der Name verwirrend sein. Es gibt Unterschiede zwischen den beiden Projekten, aber so etwas beschäftigt mich trotzdem.

    • Im März 2025 hat IBM das Agent Communication Protocol (ACP) vorgestellt, inzwischen aber beschlossen, den Namen ACP aufzugeben und die damit verbundene Arbeit mit Googles Agent2Agent-Protokoll (A2A) zusammenzuführen. Diese Entscheidung fällt in eine Phase, in der alle ACP-Entwicklungsteams aufgelöst werden, während sich die Branche unter Führung der Linux Foundation zunehmend auf A2A ausrichtet. Damit soll eine Zersplitterung bei AI-Agenten-Standards vermieden und auf ein communitygetriebenes offenes Protokoll hingearbeitet werden hier mehr dazu

  • Was mich am meisten interessiert, ist die Frage, warum man den Bedarf von LLMs nicht durch einen LSP-Server oder eine Erweiterung des LSP-Protokolls abdecken kann

    • Weil es bei LSP keinen AI-Boom gab. AI erlebt gerade eine Phase, in der wie bei frühen JavaScript-Bibliotheken explosionsartig unzählige Tools entstehen. Dabei werden die zuvor gesammelten Erfahrungen und Erkenntnisse praktisch ignoriert, und man löst die falschen Probleme mit den falschen Werkzeugen. Am Ende führt dieser Ansatz wie bei den JS-Bibliotheken nur zu mehr Komplexität und Ineffizienz. Wenn man Probleme falsch löst, entstehen neue Probleme, die dann wiederum mit noch mehr schlechten Lösungen überdeckt werden müssen.

  • Ich behandle AI lieber wie einen echten menschlichen Entwickler. Ich bitte die AI zum Beispiel, ein Feature zu implementieren, einen Bug zu beheben oder ein Refactoring zu machen, und lese mir dann den resultierenden Commit durch. Wenn mir der Commit nicht gefällt, mache ich ein git reset --hard, verbessere den Prompt und lasse die AI es erneut versuchen. Ich nenne das „Prompt Coding“. Eine direkte Interaktion zwischen meiner Coding-Umgebung und der AI brauche ich nicht; sie arbeitet wie ein menschlicher Entwickler, ohne in meinem Editor herumzufummeln mehr dazu

    • In letzter Zeit heißt es oft, dass Prompting besser geworden sei, aber da bin ich skeptisch. Für einige sehr spezifische Aufgaben ist AI hilfreich, aber sie erzählt immer noch viel Unsinn. Besonders schwer akzeptabel ist es, wenn sie Dinge wie APIs einfach erfindet.

    • Ich lasse die AI nicht bis zum Commit gehen. Ich muss ihre Ergebnisse fast immer an mehreren Stellen überarbeiten. Mir ist die Zeit zu schade, endlos neu zu prompten; wenn sie nicht gleich beim ersten Mal liefert, was ich will, korrigiere ich es lieber selbst. Wenn sie von Anfang an wirklich versteht, was ich möchte, und den passenden Code liefert, steigt mein Vertrauen in die AI deutlich.

  • Ich hoffe, dass sich diese Idee weiter verbreitet. Eine Frage, die ich dazu habe, betrifft die Unterschiede zwischen Dateisuche und ungespeicherten Dateien. In der Praxis verwenden Agenten für die Suche im Dateisystem oft Dinge wie ripgrep, aber wenn das Protokoll auch Lesen und Schreiben auf ungespeicherte Dateien erlauben soll, entsteht ein Genauigkeitsproblem: ripgrep kann ungespeicherte Dateien nicht durchsuchen.

  • Ich hoffe wirklich, dass Anthropic dieses Protokoll in Claude Code einführt. Mindestens eine Integration auf dem Niveau dessen, was in VSCode geboten wird, wäre zu erwarten. Und es wäre schon hilfreich, wenn man wenigstens Zugriff auf die Diagnosedaten des Editors hätte.

  • Auch MCP hat einmal mit JSON-RPC über stdio angefangen. Mit Umgebungen wie GitHub Codespaces, devcontainers und „background agents“ könnte sich das vielleicht zu so etwas wie JSON over SSE weiterentwickeln. Meine aktuelle Entwicklungsumgebung nutzt Claude Code lokal, während die App in Containern läuft. Der Agent kann selbstständig docker compose exec backend ausführen. Hürden für die Einführung eines git-worktree-basierten Workflows sind bei mir die gemeinsam genutzte Datenbank-Engine (mangelnde lokale Ressourcen) und die Dauer der initialen Migrationen. Es wäre ein interessantes Szenario, solche Lasten in die Cloud auszulagern.

  • Ich hoffe, dass sich solche Protokolle verbreiten, damit ich nicht immer an eine einzelne bestehende IDE gebunden bin