Phantom: ein Agent, der sein eigenes Docker-Socket bekommt

Das Problem: jeder Chat beginnt wieder bei Tag eins

Die README beschreibt den Ausgangspunkt ohne Umschweife: Agenten seien heute Einwegware. Man öffne einen Chat, bekomme eine Antwort, schließe den Tab, und der Kontext sei weg. Beim nächsten Mal fange man von vorn an. Phantom setzt dagegen auf eine eigene Maschine für den Agenten, auf der er Software installiert, Datenbanken startet, Dashboards baut und sich merkt, was man ihm letzte Woche gesagt hat. Die Zielgruppe sind demnach nicht Gelegenheitsnutzer, die eine Frage beantwortet haben wollen, sondern Teams, die eine dauerhaft laufende Instanz betreiben können. Das Projekt positioniert sich ausdrücklich nicht als Chatbot, sondern als Kollege, der auf Slack läuft, unter /chat eine Weboberfläche hat, eine eigene E-Mail-Adresse besitzt und Werkzeuge selbst anlegt. Ob dieser Anspruch im Alltag trägt, hängt an der Bereitschaft, dem Agenten echte Rechte auf einem echten Host zu geben. Genau dort liegt die Bruchlinie, die die README selbst benennt.

Was die Beispiele aus der README tatsächlich belegen

Die README führt drei Vorfälle an, die laut eigener Aussage auf Produktionsinstanzen passiert sind. Ein Phantom habe ClickHouse auf seiner VM installiert, den Hacker-News-Datensatz geladen, 28,7 Millionen Zeilen über den Zeitraum 2007 bis 2021 eingespielt, ein Dashboard mit interaktiven Diagrammen gebaut und eine REST-API ergänzt, die anschließend als MCP-Tool registriert wurde. In einem zweiten Fall habe der Agent auf die Frage nach Discord geantwortet, der Kanal sei nicht verdrahtet, aber er könne ihn bauen, und danach über einen Magic Link für die sichere Token-Übergabe den Container gestartet. Im dritten Fall habe er das Systemwerkzeug Vigil entdeckt, in die bestehende ClickHouse-Instanz integriert und eine Pipeline gebaut, die alle 30 Sekunden Metriken überträgt, insgesamt 890.450 Zeilen mit 25 Metriken. Diese Zahlen stammen aus der Projektbeschreibung, nicht aus einer unabhängigen Messung. Wer sie als Leistungsnachweis liest, sollte im Kopf behalten, dass die Auswahl der Geschichten naturgemäß die spektakulären Fälle zeigt und nicht die vielen Versuche, bei denen ein Agent eine halbe Stunde in einer Sackgasse verbringt.

Sieben Provider, ein YAML-Block, und was dabei konstant bleibt

Phantom bindet sich nicht an einen Anbieter. Die README nennt sieben Optionen: Anthropic als Standard, Z.AI mit GLM-5.1 und GLM-4.5-Air über eine Anthropic-kompatible API, OpenRouter, Ollama für GGUF-Modelle auf eigener GPU, vLLM mit OpenAI-kompatiblen Endpunkten, LiteLLM als lokalen Proxy sowie einen Custom-Eintrag für jeden Endpunkt, der die Anthropic Messages API spricht. Der Wechsel erfolgt über einen Block in phantom.yaml, in dem provider.type, api_key_env und model_mappings gesetzt werden, etwa sonnet auf glm-5.1. Der Schlüssel selbst gehört in .env. Interessant ist die Reichweite dieser Einstellung: Laut README laufen sowohl der Hauptagent als auch jeder Evolution-Judge über den gewählten Provider. Damit hängt die Qualität der Selbstverbesserung an demselben Modell wie die Ausführung. Wer auf ein günstigeres Modell umstellt, senkt nicht nur die Inferenzkosten, sondern verschiebt auch das Urteilsvermögen der Komponente, die über neue Fähigkeiten entscheidet. Die README behandelt diesen Zusammenhang nicht als Problem.

Installation über Docker Compose in vier Schritten

Der empfohlene Weg führt über Docker. Zwei curl-Aufrufe holen docker-compose.user.yaml und .env.example, danach wird .env bearbeitet und der Stack gestartet. Konkret nennt die README ANTHROPIC_API_KEY, Slack-Tokens und OWNER_SLACK_USER_ID als Pflichtwerte, RESEND_API_KEY optional für den E-Mail-Versand. Der Start erfolgt mit docker compose up -d. Beim Hochfahren zieht der Stack das Embedding-Modell für Ollama, startet Qdrant für die Erinnerung und bootet den Agenten. Der Health-Endpunkt liegt unter http://localhost:3100/health, die Weboberfläche unter /chat. Ist Slack konfiguriert, meldet sich der Agent per DM, sobald er bereit ist. Das ist eine kurze Kette, aber sie verlangt mehrere Konten und Secrets, bevor überhaupt etwas läuft. Wer keinen Slack-Workspace einrichten will, muss prüfen, ob der Webhook- oder E-Mail-Kanal ohne diese Tokens sinnvoll startet; die README beschreibt den Slack-Pfad als den, der einen beim Fertigwerden benachrichtigt.

Der Docker-Socket: die eine Zeile, die den Einsatzort bestimmt

Die README enthält einen Security-Hinweis, der deutlicher kaum sein könnte. docker-compose.yaml bindet /var/run/docker.sock in den Phantom-Container ein, damit dieser Geschwister-Container starten kann, etwa für sandboxed code execution. Der Hinweis nennt das ausdrücklich einen beabsichtigten architektonischen Trade-off und stellt klar, dass der Socket dem Container root-äquivalenten Zugriff auf den Docker-Daemon gibt. Ein kompromittierter Phantom-Prozess könnte damit jeden Container auf dem Host anlegen, verändern oder zerstören. Als Gegenmaßnahme empfiehlt die README, Phantom auf einer dedizierten Maschine oder VM zu betreiben und nicht auf dem persönlichen Arbeitsplatz. Das ist keine Fußnote, sondern die zentrale Betriebsentscheidung. Ein Agent, der sich selbst erweitert und eigene Werkzeuge registriert, läuft mit genau den Rechten, die er zum Bauen braucht, und diese Rechte sind auf einem geteilten Host zu weitreichend. Wer diese Zeile entfernt, verliert die Fähigkeit zur Container-Erzeugung und damit einen Teil dessen, was die Beispiele oben möglich gemacht hat.

Grenzen: Selbstverbesserung ohne veröffentlichte Release-Historie

Die Materialbasis ist hier dünn, und das ist selbst ein Befund. Es liegen keine Releases vor, die jüngste Aktivität am Repository datiert auf Juni 2026, die Version im Badge lautet 0.20.2. Wie der Evolution-Pipeline-Mechanismus im Detail funktioniert, welche Prüfungen ein selbst erzeugtes Werkzeug durchläuft und wie ein Fehlschlag zurückgerollt wird, geht aus der README nicht hervor. Genau diese Frage ist aber die wichtigste für jeden, der einen Agenten mit Schreibrechten auf die eigene Infrastruktur stellt. Die README verweist auf docs/, ohne den Ablauf dort wiederzugeben. Ein zweiter Punkt: Die Beispiele zeigen einen Agenten, der ungefragt eine Analytics-Plattform baut. Für Umgebungen mit Change-Control, Vier-Augen-Prinzip oder Kostenobergrenzen pro Tag ist das kein Feature, sondern ein Risiko. Phantom ist das falsche Werkzeug, wenn jede Änderung an der Infrastruktur vorab genehmigt werden muss oder wenn der Agent keinen eigenen, isolierten Host bekommen kann.

Alternative: Claude Agent SDK direkt, ohne Betriebsschicht

Phantom baut auf dem Claude Agent SDK auf. Wer nur Werkzeugaufrufe, Konversationsschleifen und MCP-Anbindung braucht, kann dieses SDK direkt verwenden und den Agenten im eigenen Prozess laufen lassen. Der Unterschied liegt nicht im Modellzugriff, sondern in allem drumherum: Phantom liefert Qdrant für persistente Erinnerung, einen Docker-Compose-Stack, Slack-, Telegram-, E-Mail- und Webhook-Kanäle sowie die Selbstverbesserungs-Schleife mit. Eine direkte SDK-Integration bringt nichts davon mit, dafür bleibt der Prozess im eigenen Deployment und braucht keinen Docker-Socket. Umgekehrt gilt: Wer die Kanäle, die Erinnerung und die Werkzeugregistrierung selbst nachbauen müsste, findet in Phantom eine fertige Zusammenstellung. Die Wahl ist damit keine Frage der Modellqualität, sondern eine Frage, ob man eine betriebene Instanz mit eigenem Host will oder eine Bibliothek im eigenen Code.

Lizenz, Wartung und der Aufwand nach dem ersten Start

Phantom steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Sie enthält eine ausdrückliche Patentgewährung und, anders als manche Copyleft-Lizenzen, keine Pflicht, eigene Änderungen offenzulegen. Das ist für den internen Betrieb unkompliziert. Ob für den gehosteten Dienst unter ghostwright.dev/phantom separate Bedingungen gelten, lässt sich aus dem Material nicht ableiten; das ist vor einer kommerziellen Nutzung zu klären, nicht durch Auslegung der Repository-Lizenz. Zum Wartungsaufwand: Der Stack zieht beim Start ein Embedding-Modell über Ollama, betreibt Qdrant und läuft als Container. Jeder Providerwechsel erfordert eine Änderung an phantom.yaml und einen Neustart, jeder Kanal wie Discord entsteht laut README dadurch, dass der Agent selbst einen Container hochzieht. Das bedeutet, dass die Zahl der laufenden Container mit der Nutzung wächst und die Ressourcenplanung nicht statisch bleibt. Wer Phantom länger als eine Woche betreibt, sollte auf dem Host mitzählen, was der Agent sich selbst dazugestellt hat.

Redaktionelles Fazit

Wer Phantom ausprobieren will, sollte zuerst eine dedizierte VM oder einen eigenen Host bereitstellen, nicht den Arbeitsrechner, und in .env die Werte ANTHROPIC_API_KEY, OWNER_SLACK_USER_ID und optional RESEND_API_KEY setzen. Wer den Agenten nur als Chat-Frontend für gelegentliche Fragen braucht, ist mit einem normalen Chat-Interface besser bedient, weil Phantom genau dann seinen Aufwand nicht rechtfertigt. Vor dem ersten Start ist zu prüfen, ob der Docker-Socket-Mount im eigenen Betrieb akzeptabel ist, denn die README stuft ihn ausdrücklich als Trade-off ein, der einem kompromittierten Prozess root-äquivalenten Zugriff auf den Daemon gibt.

Offizielle Quellen

1. ghostwright/phantom on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README