Kommunikation zwischen KI-Agenten auf verschiedenen Rechnern: Neues Open-Source-Projekt ACP-lite v0.7.0 veröffentlicht
ACP-lite (Agent Connect Personal) soll AI-Agenten auf unterschiedlichen Computern miteinander reden lassen. Das Projekt hat trotz gleichem Kürzes nichts mit Zeds Agent Client Protocol oder dem Agentic Commerce Protocol von OpenAI und Stripe zu tun.
ACP-lite (Agent Connect Personal) v0.7.0 ist erschienen. Hinweis: Das Projekt steht in keinem Zusammenhang mit Zeds Agent Client Protocol sowie dem Agentic Commerce Protocol von OpenAI und Stripe, trägt lediglich dasselbe Kürzel.
Ich betreibe sechs KI-Agents auf drei Maschinen: Codex und DSH auf meinem Desktop, Hermes und OpenClaw auf einem Netbook. Die Kommunikation von Mensch zu Agent ist einfach, etwa über WeChat oder DingTalk. Aber wie reden Agents miteinander?
Sucht man nach Antworten, findet man Enterprise-Stacks: Googles A2A, RabbitMQ, Kafka. Alles gebaut für Rechenzentren. Mein Bedarf ist viel kleiner: zwei Heimcomputer, beide hinter NAT, ohne öffentliche IP, ohne Server, bei denen Agents einander Nachrichten und Aufgaben übergeben. Dafür baut niemand etwas.
Deshalb habe ich ACP-lite (Agent Connect Personal) gebaut: eine minimale Implementierung einer hostübergreifenden Agenten-Vernetzung. v0.7.0 ist gerade erschienen, lizenziert unter der MIT-Lizenz.
Die gesamte Idee in einem Satz: Jede Maschine betreibt ein Postamt, und Agents lesen und schreiben ausschließlich lokale Dateien.
Kein zentraler Server, keine dauerhaften Netzwerkverbindungen. Der Watch-Prozess verschiebt nur Dateien und ruft nie ein Modell auf, sodass der Leerlauf null Tokens kostet. Das ist für den privaten Einsatz wichtig: Ein Monat Dauerbetrieb verursacht keine zusätzlichen Kosten.
Bezüglich der großen Namen: A2A ist das Enterprise-Protokoll in voller Ausbaustufe, ACP-lite die persönliche Minimalimplementierung, also eine andere Liga. MCP verbindet Agents mit Tools, ACP-lite verbindet Agents mit Agents. Beides ergänzt sich.
Ein Briefkasten allein reicht nicht: Der Brief kommt an, aber der Agent auf der anderen Seite schläft. v0.7.0 ergänzt die Türklingel, das Aufwecken per SSH.
Die Architekturregel ist festgelegt: SSH ist die Türklingel, ACP der Briefkasten; die Klingel überträgt nur einen Verweis, der Briefinhalt reist immer über ACP. Der Aufweckbefehl erhält lediglich den absoluten Pfad der empfangenen Briefdatei; der Prompt läuft über eine Datei plus stdin (gemessen rund 20-mal weniger Tokens als bei der Übergabe als CLI-Argument, und keine durch die Shell verhunzte Kodierung).
Letzte Woche stand der Integrationstest mit zwei Kanälen an, inklusive Zeitachse:
Die Abschlusskriterien sind dreifach, alle erforderlich: Artefakt auf der Festplatte, längere Audit-Kette, signierte Empfangsbestätigung. Verlass nie allein auf den Exit-Code 0, denn ein im Read-Only-Sandbox-Modus geweckter Agent erzählt gern etwas übers Arbeiten und beendet sich mit 0, ohne etwas getan zu haben.
All das mühsam erkundet; die README enthält die vollständige Liste (Q5 bis Q13). Vier Highlights:
1. ALL_PROXY kapert alles. Seit Syncthing 2.1 wird nur ALL_PROXY beachtet und NO_PROXY ignoriert, wodurch ein lokales Clash-Setup stillschweigend alle Verbindungen abgefangen hat; alles sah korrekt aus, es kam aber nie eine Verbindung zustande. Debugging-Reihenfolge bei einer neuen Maschine: zuerst die Proxy-Umgebungsvariablen prüfen, erst dann die Firewall verdächtigen.
2. Niemals Nicht-ASCII-Text als CLI-Argument übergeben. Windows-Shells lesen UTF-8 als GBK, und man erhält Zeichensalat. Prompts laufen immer über eine Datei plus stdin.
3. --root nicht weglassen. Lässt man es weg, ist der Exit-Code trotzdem 0 und sieht damit wie Erfolg aus, während der Brief im maschinenprivaten Verzeichnis landet, wo niemand sonst ihn sieht. Maßstab ist immer, dass eine Datei wirklich in outbox/ existiert, niemals der Exit-Code.
4. Die Sandbox-Stufe beim Aufwecken entscheidet, ob es funktioniert oder nur_performance ist. Codex-Weckvorgänge benötigen workspace-write; DSH-Weckvorgänge benötigen DSH_PERMISSION_MODE=danger-full-access, fest im Skript verankert. Falsche Stufe, und der Agent spielt Fleiß-Theater.
Man muss deutlich sagen: Es ist keine SaaS, es gibt keinen Ein-Klick-Installer. Der eine korrekte Weg: Gib deinem Coding-Agent den Repo-Link und lass es ihn anhand der README installieren:
Die README führt Schritt für Schritt: Schritt eins, Schritt zwei, wobei jeder Schritt nur das Zu-Tuende plus Befehle zum wörtlichen Kopieren enthält. Nach dem Lesen kann ein Agent dasselbe auf deinen beiden eigenen Maschinen einrichten. Es gibt zudem eine llms.txt, falls man alles auf einmal an ein LLM verfüttern möchte.
Die Motivation ist einfach: Die Lösungen der großen Anbieter sind alle für Unternehmen gebaut; niemand baut eine maschinenübergreifende Agenten-Vernetzung für Einzelnutzer. ACP-lite ist eine minimale Antwort auf das Szenario ein paar eigener Computer und ein paar eigener Agents.
Probiert es aus; Issues gehen direkt ins Repository. Bei diesem Projekt zählt das erste Issue einer fremden Person mehr als hundert Sterne.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
ACP-lite (Agent Connect Personal) v0.7.0 is out: https://github.com/furoute/acp-lite Note: unrelated to Zed's Agent Client Protocol and OpenAI+Stripe's Agentic Commerce Protocol — same acronym, different project.
I run 6 AI agents across 3 machines: Codex and DSH on my desktop, Hermes and OpenClaw on a netbook. Human-to-agent is easy — WeChat, DingTalk, done. But how do agents talk to each other?
Search for answers and you get enterprise stacks: Google's A2A, RabbitMQ, Kafka. All built for data centers. My need is much smaller: two home computers, both behind NAT, no public IP, no server — agents passing messages and tasks to each other. Nobody builds for that.
So I built ACP-lite (Agent Connect Personal): a minimal implementation of cross-host agent interconnect. v0.7.0 just shipped, MIT licensed.
The whole idea in one sentence: each machine runs a "post office"; agents only ever read and write local files.
No central server, no persistent network connections. The watch process only moves files — it never calls a model, so idling costs zero tokens. That matters for personal use: run it for a month, pay nothing extra.
How it relates to the big names: A2A is the enterprise-grade full protocol; ACP-lite is the personal minimal implementation — different leagues. MCP connects agents to tools; ACP-lite connects agents to agents. Complementary.
A mailbox alone isn't enough: the letter arrives, but the agent on the other side is asleep. v0.7.0 adds the "doorbell" — SSH wake-up.
The architecture rule is fixed: SSH is the doorbell, ACP is the mailbox; the doorbell carries only a pointer, the letter body always travels via ACP. The wake-up command passes just the absolute path of the received letter file; the prompt goes through a file + stdin (measured ~20x fewer tokens than passing it as a CLI argument, and no shell-mangled encoding).
Last week's dual-channel integration test, timeline included:
The completion criteria are threefold, all required: artifact on disk, longer audit chain, signed receipt. Don't trust exit code 0 alone — an agent woken in read-only sandbox mode will happily "talk about doing the work" and exit 0 with nothing done.
All earned the hard way; the README has the full list (Q5–Q13). Four highlights:
1. ALL_PROXY hijacks everything. Since Syncthing 2.1, it honors only ALL_PROXY and ignores NO_PROXY — a local Clash setup silently captured all dials, and everything looked correct but never connected. Debugging order for a new machine: check proxy env vars first, suspect the firewall second.
2. Never pass non-ASCII text as CLI arguments. Windows shells read UTF-8 as GBK and you get mojibake. Prompts always go through a file + stdin.
3. Don't omit --root. Omit it and the exit code is still 0 — looking like success — while the letter lands in the machine-private directory where nobody else can see it. The criterion is always "a file really exists in outbox/", never the exit code.
4. The wake-up sandbox level decides whether it works or performs. Codex wake-ups need workspace-write; DSH wake-ups need DSH_PERMISSION_MODE=danger-full-access baked into the script. Wrong level, and the agent performs diligence theater.
Be clear about this: it's not SaaS, there's no one-click installer. The one correct usage — hand the repo link to your coding agent and let it install from the README:
The README is step-by-step: step one do this, step two do that, each step only "what to do + commands to copy verbatim". After reading it, an agent can set the same thing up on your own two machines. There's also an llms.txt if you'd rather feed the whole thing to an LLM at once.
The motivation is simple: big-vendor solutions are all built for enterprises; nobody builds cross-machine agent interconnect for individual users. ACP-lite is one minimal answer for the "a few of my own computers, a few of my own agents" scenario.
Try it out — issues go directly to the repo. For this project, the first issue from a stranger matters more than a hundred stars.