Curie: Die Open-Source-Plattform zum Selbst-Hosten, die Coding-Agenten zu Kollegen macht

Für wen es geeignet ist

• Für Entwicklungsteams, die KI-Zusammenarbeit in der eigenen Infrastruktur wollen: Curie ist eine Open-Source-Plattform, die sich selbst hosten lässt, in Ihrer eigenen Infrastruktur läuft und Coding-Agenten in Kollegen verwandelt, denen man Aufgaben übergeben und deren Ergebnis man abnehmen kann.
• Das Kernszenario lautet „ein GitHub-Issue delegieren und eine Implementierung zur Review zurückbekommen“: Curie übernimmt Implementierung und Review des Issues und liefert einen Pull Request oder Merge Request zurück, der auf die Annahme durch das Team wartet.
• Es passt auch zur Zusammenarbeit im Kubernetes-Betrieb: Nur-Lese-Kubernetes-Prüfungen laufen sofort, konfigurierte Änderungsoperationen verlangen eine menschliche Freigabe — gut geeignet, um Inspektionen und Diagnosen als risikoarme Routineaufgaben abzugeben.
• Für Teams, die den Freigabeschritt in Menschenhand behalten wollen: konfigurierte Änderungsoperationen brauchen jedes Mal eine neue menschliche Freigabe, und welche Aktionen vorher freigegeben werden müssen, legen Sie selbst fest.
• Teams, die bereits einen eigenen Coding-Agenten pflegen, können ihn mit dem offiziellen Befehl curie init --adopt ./my-existing-agent übernehmen.
• Wenn es nicht passt: eine Maschine, auf der Docker nicht läuft, oder fehlende Modell-Zugangsdaten für Anthropic oder OpenRouter — jede von der offiziellen Seite genannte Voraussetzung ist zwingend.

Der erste Versuch in 3 Minuten

Voraussetzungen: eine Maschine, auf der Docker bereits läuft, mit installiertem kind, kubectl und Helm, dazu Modell-Zugangsdaten für Anthropic oder OpenRouter. Fehlt auch nur eines davon, lässt es sich nicht gemäß der offiziellen Anleitung starten.

Führen Sie das offizielle Installationsskript im Terminal aus:

curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash

Das Skript stammt aus dem main-Branch des Curie-Repositories; ein Pipeline-Befehl führt ein Remote-Skript direkt mit Ihren Benutzerrechten aus — wer das nicht möchte, lädt es vorher herunter und prüft den Inhalt, bevor er es ausführt.

Für den ersten Versuch den Weg mit geringem Risiko wählen: ein Issue aus dem Repository mit klarer Beschreibung und kleinem Wirkungskreis aussuchen und Implementierung und Review an Curie delegieren. Nach Fertigstellung liefert es einen Pull Request oder Merge Request zurück, der auf die Annahme durch Ihr Team wartet. Das Erfolgssignal ist eindeutig: Auf Ihrer Code-Hosting-Plattform geht der erzeugte PR/MR ein, und Sie können die Änderungen einzeln durchgehen.

Wie man nach der Installation Modell-Zugangsdaten hinterlegt und wie man das Code-Hosting-Konto anbindet, wird offiziell nicht Schritt für Schritt erklärt; orientieren Sie sich an den Ausgabehinweisen des Skripts und an der Repository-Dokumentation.

Anwendungsfälle

Fall 1: Aus einem Issue einen PR zur Review machen. Situation: In einem Team-Repository liegt ein klar umrissenes Implementierungs-Issue, das niemand rechtzeitig bearbeiten kann. Start: Das Issue an Curie delegieren — das entspricht dem offiziell beschriebenen Ablauf „das Issue zur Implementierung und Review delegieren“. Verlauf und Ergebnis: Nach Fertigstellung kommt der PR/MR zurück, und Sie reviewen die Änderungen einzeln auf Ihrer eigenen Hosting-Plattform; der bestätigbare Endpunkt ist ein PR/MR, der auf die Annahme durch das Team wartet.

Fall 2: Nur-Lese-Inspektion in Kubernetes. Situation: Sie wollen den aktuellen Zustand des Clusters kennen, ohne für eine routinemäßige Statusprüfung den kompletten Änderungsfreigabeprozess zu durchlaufen. Start: Curie eine Nur-Lese-Kubernetes-Prüfung anfragen — verwendet werden genau die offiziell beschriebenen Nur-Lese-Kubernetes-Werkzeuge. Verlauf und Ergebnis: Nur-Lese-Operationen laufen sofort und brauchen keine zusätzliche Freigabe; verlangt man danach eine konfigurierte Änderungsoperation, holt es zuerst eine frische menschliche Freigabe ein und macht dann weiter. Bleibt die erste Inspektion im Nur-Lese-Bereich, gibt es keine Freigabewartezeit; um den Freigabeschritt zu beobachten, genügt eine zusätzliche Änderungsanfrage, und der Freigabe-Prompt erscheint. Welche Nur-Lese-Werkzeuge es konkret gibt und wie man sie aufruft, wird offiziell nicht einzeln aufgelistet.

Grenzen der Nutzung

• Umgebungsvoraussetzungen: Docker läuft, kind, kubectl und Helm sind vorhanden, dazu Modell-Zugangsdaten für Anthropic oder OpenRouter; Anforderungen an Betriebssystem und Hardware-Architektur nennt die offizielle Quelle nicht.
• Nebenwirkungen und Bestätigungspunkte: Nur-Lese-Kubernetes-Werkzeuge laufen sofort; konfigurierte Änderungsoperationen verlangen jedes Mal eine neue menschliche Freigabe; das Ergebnis einer delegierten Implementierung ist ein PR/MR, der auf die Annahme durch das Team wartet. Was das Installationsskript auf Ihrer Maschine anlegt und welche Verzeichnisse es belegt, wird offiziell nicht einzeln beschrieben — Sie können den Skriptinhalt vor der Ausführung prüfen.
• Laufort: eine selbst gehostete Plattform, die in Ihrer eigenen Infrastruktur läuft.
• Übernahme eines bestehenden Agenten: der offizielle Befehl curie init --adopt ./my-existing-agent wird bereitgestellt; die offizielle Dokumentation sagt nicht, was der Befehl vom bestehenden Agenten bewahrt. Initialisierung und Konfiguration darüber hinaus werden in der offiziellen Anleitung nicht ausgeführt.
• Was Sie vor dem Handeln im Repository überprüfen sollten: die Schritte zur Konfiguration der Zugangsdaten nach der Installation, wie das Code-Hosting-Konto angebunden wird, die vollständige Liste der verfügbaren Nur-Lese-Werkzeuge und konfigurierbaren Änderungsoperationen, ob neben diesen beiden Anbietern weitere Modell-Anbieter unterstützt werden und die exakte Liste der kompatiblen Coding-Agenten. Prüfen Sie jeden Punkt anhand der Repository-Dokumentation, bevor Sie loslegen.