Kiro Crew: AI-Programmierung von einmaligen Gesprächen zu einem bleibenden Kollegen machen

Technik-Analyse: Analyse von AI-Frameworks – Beschreibung, Analyse, technische Bewertung, Werturteil, praktische Anwendung. Autor: Yongliang

---

title: “Technik-Analyse 008｜Kiro Crew: AI-Programmierung von einmaligen Gesprächen zu einem bleibenden Kollegen machen” cover: cover.png author: Yongliang digest: ""

Technik-Analyse: Analyse von AI-Frameworks – Beschreibung, Analyse, technische Bewertung, Werturteil, praktische Anwendung. Autor: Yongliang

---

Die meisten AI-Programmiersitzungen haben ein gemeinsames Ende: Das Chat-Fenster wird geschlossen, die in der Sitzung angesammelten Urteile, Korrekturen und der Kontext werden auf Null zurückgesetzt, und beim nächsten Mal beginnt man wieder von vorne. Im Juli 2026 warf das Kiro-Team von Amazon eine gezielte Antwort in die Open-Source-Community: Kiro Crew – eine persistente Entwicklungs-Workbench, die auf Ihrer eigenen Hardware läuft, Arbeit über Sitzungen hinweg merkt, Korrekturen in Lektionen verfestigt, wiederkehrende Muster in Fähigkeiten (Skills) gießt und auch dann weiterarbeitet, wenn der Mensch nicht anwesend ist. Das Projekt wurde vor zwei Monaten erstellt und hat bis September 2026 etwa 3.891 Stars und 213 Mitwirkende erreicht; die Version v0.6.0 wurde veröffentlicht. Dieser Artikel zerlegt sechs Aspekte: Was es ist, die Kernmechanismen bis auf Quellcodeebene, die technische Bewertung, ob es sich lohnt, wie man es einsetzt, und – wenn Sie selbst eine ähnliche persistente Workbench schreiben möchten – wie das minimale Skelett aussieht.

1. Was ist das?

Positionierung in einem Satz: Kiro Crew ist eine Open-Source-Entwicklungs-Workbench, die lokal oder auf Ihrem eigenen Server läuft. Der Kernansatz ist, dass die Arbeit nicht mit dem Schließen des Chat-Fensters enden sollte – Sitzungen, Speicher, Zeitpläne und Aufgaben-Checkpoints werden persistiert; Korrekturen und Fehler werden zu langfristigen Lektionen; wiederkehrende Muster werden zu wiederverwendbaren Fähigkeiten (Originaltext aus README: persistent, self-learning, and self-evolving).

Zuerst die wichtigsten Fakten. Repository kirodotdev/KiroCrew, erstellt am 16. Juli 2026, Hauptsprache Python (ca. 1.492 Quelldateien im Backend), Frontend ist ein React + TypeScript + Tailwind Dashboard mit einer Electron-Desktop-Hülle (ca. 3.712 Quelldateien), dazu 2.502 Testdateien. Die Lizenz ist Apache-2.0, aber die NOTICE-Datei im Repository macht deutlich: Das Copyright liegt bei Amazon.com, Inc. oder seinen Tochtergesellschaften; die Namen und Logos von Kiro und Kiro Crew sind Marken und nicht unter der Softwarelizenz enthalten. Es stammt von demselben Team wie AWSs Kiro – die Standard-Agent-Laufzeitumgebung ist das Kiro-CLI-Tool kiro-cli, das von Kiro Crew über das ACP-Protokoll gesteuert wird. In der Danksagungsliste des README sind mehrere Amazon-Mitarbeiterkonten direkt zu sehen. Die Mitwirkenden sind nach Commit-Anzahl sortiert; die ersten vier haben zusammen über 3.000 Commits, und die drei Maintainer Bolin Chen, Joe Guo und Zezhen Xu sind darunter – dies ist ein echtes Team, das intensiv arbeitet, keine künstlich aufgebaute Popularität.

2. Kernmechanismen

2.1 Dreiteilung: Laufzeitumgebung, Persönlichkeit, Gateway

Die Architekturdokumentation von Kiro Crew unterteilt das System in drei Ebenen. Diese Aufteilung ist der Schlüssel zum Verständnis von allem.

Ganz unten ist kiro-cli, eine Agent-Laufzeitumgebung (beachten Sie: nicht der Agent selbst): Sie hält die LLM-Verbindung, führt Tools aus (bash, Dateilesen/-schreiben, grep), verwaltet MCP-Server, persistiert Sitzungen, komprimiert Kontext und exponiert ACP – das Agent Client Protocol, eine JSON-RPC 2.0-Schnittstelle auf stdio, die von jedem Orchestrator gesteuert werden kann. Die mittlere Ebene ist die Agent-Konfiguration: JSON-Dateien unter ~/.kiro/agents/, die nur beschreiben, „wie sich dieser Agent verhält“ – System-Prompt, welche Tools aktiviert sind, welche MCP-Server eingehängt sind. Jeder Agent wird als kiro-cli acp --agent <Name> ausgeführt. Ganz oben ist Kiro Crew selbst: ein asyncio-Prozess, der die Desktop-Anwendung, das Web-Dashboard, die Befehlszeile, Slack, Discord, Telegram, Feishu, WeChat, iMessage und mehr als ein Dutzend andere Oberflächen auf dieselbe Gruppe von Laufzeiten multiplext und alles ergänzt, was die Laufzeitumgebung bewusst nicht aussagt: Zeitplanung, Genehmigung, Speicher, Sicherheitsrichtlinien, Nachrichtenverbindung.

Die vollständige Reise einer Nachricht sieht so aus: Sie passiert zuerst die Hooks des Gateways (automatische Antwort, Transformation, Injektion, Ablehnung), wird an eine Sitzung geroutet, und der ContextBuilder setzt den Kontext zusammen (Speicher, Fähigkeiten, Lektionen, Historie). Dieser wird als Prompt an kiro-cli über ACP gesendet, das Modell gibt Text und Tool-Aufrufe streamend zurück, das Gateway schiebt den Ereignisstrom zurück an die Oberfläche, hängt ihn gleichzeitig an das Sitzungsprotokoll im JSONL-Format an und löst asynchron eine Speicherkonsolidierung aus. Ein Detail ist hervorzuheben: Tool-Aufrufe gehen nicht direkt vom Gateway zur Laufzeitumgebung – jeder Tool-Aufruf muss zuerst den eigenen PreToolUse-Checkpoint von Kiro Crew passieren, bevor kiro-cli zur echten Ausführung zugelassen wird. Die Sicherheitsgrenze wird auf der Orchestrator-Ebene gezogen, nicht darauf vertraut, dass der Prompt von sich aus diszipliniert ist.

2.2 Persistenz: Fünf Speicherarten mit klaren Aufgaben

„Persistenz“ ist in Kiro Crew kein leeres Wort, sondern fünf klar strukturierte Speicherarten.

Die erste Art ist Markdown-Speicher für Menschen. memory.pys MemoryStore verwaltet drei Dateien: preferences.md (Benutzervoreinstellungen), projects.md (Kontext laufender Projekte) und Zusammenfassungen nach Tagen im Verzeichnis history/ (YYYY-MM-DD.md). Ergänzt durch einen SQLite-FTS5-Volltextindex für die Stichwortsuche. Die Historie hat ein klares Verfallsgefälle: Inhalte der letzten 14 Tage werden vollständig injiziert, von Tag 15 bis 60 nur Titel plus erster Eintrag plus verbleibende Anzahl, von 61 bis 180 werden sie zu einer Zeile mit Datum und Sitzungszahl zusammengezogen, über 180 Tage werden nicht mehr gelesen, und der Herzschlagdienst löscht Dateien, die älter als 365 Tage sind, von der Festplatte. Speicher ist nicht besser, je vollständiger er ist – dieses Gefälle ist eine technische Erklärung für den Kompromiss.

Die zweite Art ist Vektorspeicher. vector_memory.pys VectorMemoryStore landet ebenfalls in SQLite, unterteilt in Zeilen für semantische Schlüsselwerte, Situationsaufzeichnungen und Lektionen. Einbettungsvektoren werden als BLOB in der Datenbank gespeichert. Die Suche ist eine hybrive Bewertung – _hybrid_score im Quellcode kombiniert Schlüsselwortpunktzahl und Vektor-Kosinus-Punktzahl; ohne Vektor fällt es automatisch auf reine Schlüsselwörter zurück. Situationsaufzeichnungen haben nach Tag-Konfiguration eigene Verfallsraten, die Wichtigkeit fließt in die Sortierung ein. Die Einbettungsberechnung erfolgt im Prozess und verwendet das eingebundene llama-cpp-python, ohne dass ein separater Einbettungsdienst nötig ist; der Preis ist, dass beim Modellwechsel der gesamte Vektorraum ungültig wird. Der Quellcode implementiert dafür reconcile_embedding_space: Nach dem Modellwechsel werden alte Einbettungen komplett verworfen und neu berechnet, um zu vermeiden, dass zwei Vektorräume gemischt sortiert werden.

Die dritte Art sind Lektionen. learn.pys LessonStore ist eine nur-ergänzende (append-only) JSONL-Datei, eine Lektion pro Datensatz, nur Ergänzung, keine Änderung. Wenn der Benutzer sagt „Nein, vor dem Aufruf von ‚Fertig‘ zuerst den Frontend-Check laufen lassen“, wird dieser Satz mit Arbeitsbereich-Gültigkeitsbereich gespeichert und bei zukünftigen Sitzungen beim Injizieren des Prompts gefunden. Lektionen werden auch zu semantischen Schlüsseln vektorisiert; der Schreibpfad hat vollständige Deduplizierungs- und Ersetzungsregeln: Wenn ein neuer Wert bestätigt wird und einen alten ersetzt, werden Situationsgedächtnisse, die den alten Wert referenzieren, ausgemustert – ein Kommentar im Quellcode enthält eine Messung: In einem Speicher, der einige Stunden lief, wurden von 101 Situationsgedächtnissen 21 ausgemustert, 14 davon durch diese Regel. derselbe Kommentar erklärt auch, warum bei jeder Konsolidierung maximal 3 ausgemustert werden: Ersetzte Werte sollten wenige Datensätze, die sie wiederholen, ausmustern, nicht einen ganzen Block des Bestands abschneiden.

Die vierte Art ist das Sitzungsbuch (Session Ledger), das härteste Design für „Fortsetzung über Sitzungen hinweg“. session_ledger.py führt für jede Sitzung ein Arbeitsbuch mit den Statusfeldern goal (Ziel), phase (Phase), next_step (Nächster Schritt), tried_approach und tried_rejected_because (Was wurde versucht, warum abgelehnt), artifacts (Artefakte). Die record()-Funktion zum Schreiben des Buchs hat eine harte Disziplin, Originaltext im Quellcode: a phase must never move without a logged, classified reason – Ein Phasenfortschritt muss ein protokolliertes, klassifiziertes Ereignis haben; Leerlauf und Überspringen werden von der Datenstruktur selbst abgelehnt. Jeder Ausführungszyklus wird das Buch zu einem kleinen [work ledger]-Block gerendert und in den Prompt zurückgegeben, sodass der Agent in jeder Runde sieht, was er sich selbst vorgenommen hatte. Das Buch wird in einem Verzeichnis geschrieben, das durch eine dedizierte Sperrdatei geschützt ist; gesperrt wird der Inode, nicht der Pfad – dies verhindert, dass ein Schreiber, der in der Warteschlange steht, nach dem Löschen des Verzeichnisses eine bereits entfernte Sperre erhält und in eine Geisterdatei schreibt. agent_state.py verwendet eine Sidecar-JSON-Datei加上 eine beratende Dateisperre über Prozesse hinweg, um die Schreib-Lese-Wettlaufsituation (Race Condition) zwischen Dashboard-Prozess und CLI-Prozess für denselben Status zu lösen.

Die fünfte Art sind isolierte Speicher für mehrere Mitglieder. memory_stores.py implementiert einen Mechanismus für benannte Speicher: Jedes Mitglied kann seinen eigenen Speicher haben, mit einer Eigentümerliste, um zu verhindern, dass andere Mitglieder oder rekonstruierte Prozesse alte Daten übernehmen. Ausmusterung hat ein spezielles Markierung, die Unterscheidung zwischen V1-Alt und V2-Neu ist in die Ladelogik eingebaut. Die Erklärung im Quellcode für diesen Mechanismus ist sehr direkt: Wenn dasselbe Prädikat stillschweigend vom Code, der es erschuf, abweichen kann, lieber auf dieses Prädikat verzichten – ein stilles Versagen ist schlimmer als kein Prädikat. Solche Kommentare sind im Repository sehr dicht; Designentscheidungen bleiben zusammen mit der Begründung direkt im Code.

2.3 Planung und Ausführungsschleife: Drei „Wecker“ für unbeaufsichtigte Abläufe

Unbeaufsichtigter Betrieb ist kein einfach „im Hintergrund eine Schleife laufen lassen“, im Quellcode sind es drei Mechanismen.

Die erste Art sind zeitgesteuerte Aufgaben. cron.pys CronService speichert Aufgaben in crons.json und unterstützt die drei Ausdrücke every, at und cron; Zeitzonen werden als IANA-Namen über ZoneInfo aufgelöst – Anforderungen wie „Werktags um 9 Uhr“ werden in der Zeitzone des Erstellers gespeichert. Bei jedem Auslösen gibt es eine Budgetaufschlüsselung: Zündung, Prüfung bei Inanspruchnahme, Warteschlange im Sitzungspool, gesamte Aktivierung – jede dieser vier Phasen bekommt ein Zeitlimit, ein Gesamtbudget (deadline) fängt die ganze Runde ab, Überschreitung bedeutet Fehlschlag, und kontinuierlich fehlgeschlagene Aufgaben werden automatisch pausiert statt endlos wiederholt.

Die zweite Art ist der Herzschlag. heartbeat.pys HeartbeatService verwaltet eine Aufgabenliste HEARTBEAT.md, die periodisch aufwacht und sie nacheinander ausführt. Wenn die Antwort des Agents den Wächter HEARTBEAT_KEEP enthält, wird diese Aufgabe als unvollständig eingestuft und für den nächsten Zyklus zurückgestellt – „Noch nicht fertig, im nächsten Durchgang nochmal“ wird zu einem maschinenlesbaren Signal gemacht, statt darauf zu vertrauen, dass das Modell den Zustand von sich aus wiederholt. Lese- und Schreibzugriff auf die Liste erfolgen über prozessübergreifende Sperren; die endgültige „Lese→Ersetze“-Transaktion des Herzschlagdienstes überschreibt keine Aufgaben, die gerade von einem anderen Prozess angehängt wurden.

Die dritte Art ist automatische Erinnerung (Auto-Nudge). autonudge.pys AutoNudgeService verwaltet Erinnerungsschleifen, die an Sitzungen gebunden sind: Eine Sitzung kann eine Zielschleife haben, und wenn der Inaktivitätstimer abläuft, wird sie einen Schritt weitergeschoben. Die Schleife hat ein Budget an der Wanduhr, bei Überschreitung stoppt sie automatisch, alle Stoppgründe werden auf die Festplatte geschrieben, und nach einem Gateway-Neustart setzt die Schleife vom Festplattenstatus fort. Ergänzend gibt es strukturierte Monitore – wenn der Agent sagt „Behalte diese Deployment im Auge, sag mir Bescheid, wenn es fertig ist“, analysiert das System diesen Satz zu einer Überwachungsschleife mit Sondenstatus, statt darauf zu hoffen, dass der Agent selbst zurückkommt, um nachzusehen.

Die Unterstützung auf Sitzungsseite ist auch im Quellcode: Hinter einer aktiven Sitzung steht entweder ein dedizierter kiro-cli ACP-Prozess oder ein Sitzungs-Handle auf einer gemeinsamen multiplexierten Laufzeitumgebung – die Sitzung ist die logische Isolierungsgrenze, nicht unbedingt gleich einem Betriebssystemprozess; im Leerlauf gehende Sitzungen gehen in den Warm-Pool, um wiederverwendet zu werden.

2.4 Selbstverbesserung: Dreistufige Festigung von Korrekturen zu Fähigkeiten

„Selbstverbesserung“ ist in drei Stufen unterteilt, jede mit eigenem Speicher und Auslösebedingungen.

Die erste Stufe sind Lektionen: Korrekturen werden sofort in die Datenbank (LessonStore) aufgenommen; beim Schreiben in den Lektionsbereich des Vektorspeichers erfolgt eine semantische Deduplizierung – wiederholte Einreichung derselben Regel stapelt sich nicht. Die zweite Stufe ist Konsolidierung: Ein asynchron laufender LLM-Konsolidierer presst das Sitzungsprotokoll zu Voreinstellungen, Projektkontext und täglichen Zusammenfassungen; Auslösebedingungen sind die Anzahl der Nachrichten (Voreinstellungen und Projekte ca. 30 Nachrichten) und die Leerlaufdauer (tägliche Historie ca. 3 Stunden Inaktivität). Die dritte Stufe sind Fähigkeiten (Skills): Wiederkehrende Arbeitsmuster werden automatisch zu einer SKILL.md-Datei verfestigt, im YAML-Kopf mit Herkunftsnachweis (automatisch generiert, aus welcher Sitzung, Erstellungs- und Verfeinerungszeit, Wiederverwendungszahl). Die Klasse für den Herkunftsnachweis heißt AutoSkillProvenance. Fähigkeiten sind nicht fertig, sobald sie generiert sind – byte-genau doppelte Fähigkeiten werden dedupliziert, Fähigkeiten, die von zeitgesteuerten Aufgaben referenziert wurden, sind von der Aussonderung befreit; alle Fähigkeiten sind im Dashboard sichtbar, bearbeitbar und löschbar.

Wenn man es zusammenrechnet: Dieser Mechanismus wird derzeit von ca. 1.492 Python-Quelldateien gestützt, 2.502 Testdateien, mehr als der Quellcode – bei einem zwei Monate alten Projekt spricht dieses Verhältnis selbst dafür, wo die Team Zuverlässigkeit ansiedelt.

3. Technische Bewertung

Zuerst zur Form der Schlussfolgerung: Dieses Projekt hat keine Benchmarks und keine Leistungszahlen, die man zitieren könnte; die Bewertung kann nur anhand des Ingenieurgrads und der Governance-Qualität erfolgen. Und genau das sind seine härtesten Teile.

Was den Ingenieurgrad angeht, zwei Indikatoren. Erstens die Dichte der Entscheidungen in den Quellcode-Kommentaren: Die Begründung für das Sperren des Inode in session_ledger.py, die Messgrundlage für „Ausmusterungslimit 3“ in vector_memory.py, die Lese-Schreib-Disziplin „unlesbar bedeutet nicht meinungslos“ in agent_state.py – fast jede nicht-triviale Funktion trägt eine Erklärung „warum wir das so tun“, das ist die Spur, die langfristige Maintainer hinterlassen. Zweitens das Test-Verhältnis: 2.502 Testdateien zu 1.492 Quelldateien, in der Konfiguration gibt es Baseline-Dateien, Fehlercode-Baseline-Dateien, Sicherheitsregeln haben semmerge-Scan-Verzeichnisse. Was die Governance-Qualität angeht: Das Repository hat zehn sortierte Designprinzipien (TENETS, der erste Safety first, bei Konflikten gewinnt der vordere und der Kompromiss muss aufgeschrieben werden), ein dokumentiertes RFC-Verfahren, eine Erklärung zur Trennung von Marke und Code-Lizenz – dieser Governance-Text ist bei einem zwei Monate alten Projekt eine übergroße Ausstattung.

Im Vergleich mit ähnlichen Lösungen sind die führenden Lösungen in diese Richtung grob in drei Kategorien unterteilt: Terminal-basierte Pair-Programming-Tools, universelle Agent-Orchestrierungs-Frameworks, cloud-gehostete Agent-Dienste. Kiro Crew sitzt mit keinem in derselben Schublade: Es lagert die „Laufzeitumgebung“ an kiro-cli aus und verwaltet selbst nur Orchestrierung und Status; die fünf Status-Teile (Sitzung und Protokolle, Speicher, Genehmigung, Governance-Obergrenzen, Ereignisbus) werden von der Plattform mit dem letzten Wort gehalten, alle anderen Oberflächen werden zu austauschbaren Apps gemacht – der zehnte Grundsatz lautet wörtlich everything is an app; wenn eine Oberfläche nicht gut app-ifiziert werden kann, ist das ein Fehler der Plattform, nicht eine Lizenz, die Oberfläche in den Kern zu stopfen. Der Preis ist ebenso klar: Das gesamte System hängt hart von kiro-cli ab, agent.provider ist fest auf acp gesetzt, ohne in das Kiro-Ökosystem einzusteigen, läuft das Zeug nicht.

Bei den Hypedaten ist etwas Wasser in den Wein zu gießen. Ca. 3.891 Stars, 213 Mitwirkende, beides keine niedrigen Zahlen, aber die offenen Issues und PRs zusammen sind 1.548, eine sehr hohe Rate im Verhältnis zu den Stars – viele Ausprobierer, die Polierung ist unvollendet. Auch die Vertriebskanäle sind speziell: nicht über PyPI und npm, Desktop-Pakete und Installationsskripte laufen über das eigene CDN des Projekts, Container-Images auf GHCR, Downloadzahlen sind nicht öffentlich statistisch erfassbar; auf der Liste der Mitwirkenden nehmen Amazon-Mitarbeiterkonten prominente Plätze ein, der Anteil externer Community-Beiträge ist noch klein. Die tatsächliche Nutzungsgröße ist begrenzt, dieses Urteil muss auf den Tisch gelegt werden.

4. Werturteil

Das echte Problem ist echt: Der Agent vergisst, sobald die Arbeit getan ist; Korrekturen wiederholen sich; Zeitplanung und Genehmigung sind verstreut in Chat-Fenstern – das ist der Verlust, den jedes Team, das 2026 ernsthaft AI-Programmierung nutzt, erlebt. Die Antwort von Kiro Crew ist, den Arbeitsbereichsstatus als Infrastruktur zu behandeln: fünf Speicherarten, drei Wecker, dreistufige Festigung, alles auf der eigenen Hardware, Speicher lokal priorisiert, standardmäßig kein Hochladen. Für die Positionierung „Kollege“ gibt es eine sehr vollständige technische Erklärung.

Die Grenzen sind ebenso klar. Erstens, Ökosystem-Bindung: harte Abhängigkeit von kiro-cli und dem Kiro-Kontosystem; wer AWS Kiro nicht nutzt, wird bereits im ersten Schritt abgeschreckt, das ist die schwerste Fessel für ein allgemeines Open-Source-Projekt. Zweitens, architektonische Obergrenze: Das Gateway ist ein Einprozess-Modell mit Sitzung, Laufzeitumgebung und Status auf derselben Maschine; horizontale Skalierung und Multi-Maschinen-Deployment stehen derzeit nicht auf dem Plan. Drittens, Plattformunterschiede: Windows hat keinen gleichwertigen Betriebssystem-Sandbox; die Wahl im Quellcode ist Scheitern-Schließen – ohne Erklärung des Verlassens wird keine Nicht-Sandbox-Ausführung zugelassen. Viertens, die Marke liegt bei Amazon, der Code kann geforkt werden, der Name kann nicht mitgenommen werden. Wann man es nutzen sollte: bereits im Kiro-Ökosystem, will eine sitzungsübergreifende bleibende Entwicklungs-Workbench, und Daten müssen auf der eigenen Maschine bleiben – es ist die fertige Antwort. Wann man es nicht nutzen sollte: Teams ohne kiro-cli, Szenarien, die Multi-Maschinen-Orchestrierung benötigen, oder nur eine leichte Chat-Hülle wollen – für die ersten beiden erfüllt es architektonisch nicht, für das letzten ist es unnötig schwer.

5. Wie man es einsetzt

Installation in einer Zeile, danach öffnen Sie http://localhost:5476 für das Dashboard:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

Voraussetzung ist nur eine: kiro-cli auf der Maschine des Gateways installieren und separat anmelden, beim ersten Start wird automatisch geprüft und Anleitung gegeben. Der Installer verwendet standardmäßig ein selbst verwaltetes CPython 3.12 (uv-geführt), rührt den System-Interpreter nicht an; für dauerhaften Betrieb kirocrew service install, unter Linux systemd-Service, unter macOS launchd. Auch der Container-Pfad ist fertig:

docker run -d --name kirocrew -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew ghcr.io/kirodotdev/kirocrew:stable

Der tägliche Gebrauch deckt die meisten Szenarien mit fünf Befehlen ab: kirocrew chat für interaktive Gespräche, kirocrew run TASK.md für Aufgaben mit Checkpoints, kirocrew cron für zeitgesteuerte Aufgaben, kirocrew spawn run "Aufgabe" für parallele Unter-Agenten, kirocrew security für das Audit. Auf der Ops-Seite merken Sie sich drei: kirocrew doctor für den Check-up, kirocrew logs für die Logs, im Dashboard Settings kann man den täglichen anonymen Nutzungs-Herzschlag ausschalten. Auswahl-Empfehlung zwei: Das Datenverzeichnis mit KIROCREW_HOME explizit angeben und in die Sicherung einbeziehen – Speicher, Lektionen, Fähigkeiten sind alles drin; das Dashboard nach außen exponieren Sie unbedingt über eine Remote-Konfiguration mit Token-Authentifizierung, die Standard-Bindung an Loopback ist Sicherheitsbaseline, nicht der Standardwert.

6. Wie man selbst eine ähnliche Lösung baut

„Selbst ein Set bauen“ ist bei diesem Thema besonders machbar, da Kiro Crew selbst bewiesen hat, dass Laufzeitumgebung und Statusschicht getrennt werden können. Das minimale Skelett in sieben Schritten:

1. Zuerst Schichten trennen: Wählen Sie eine fertige Agent-Laufzeitumgebung (kiro-cli, ACP-Adapter von claude-code, oder jede Laufzeitumgebung, die über stdio JSON-RPC gesteuert werden kann), Sie schreiben nur das Gateway – Nachrichtenrouting, Sitzungstabelle, Statusspeicher. Mit diesem einen Schnitt wird die Schwierigkeit halbiert.
2. Sitzungsbuch: Für jede Sitzung ein nur-ergänzendes (append-only) JSONL-Transkript, plus eine Statusdatei für goal, phase, next_step, tried_approach. Schreiben mit atomarem Schreiben über temporäre Datei plus Umbenennen, bei Szenarien mit vielen Lesern/Schreibern eine beratende Dateisperre über Prozesse hinweg hinzufügen. Machen Sie „Phasenfortschritt muss mit Begründung sein“ zu einer Schreibvalidierung, das ist die Schlüsseldisziplin, damit unbeaufsichtigter Betrieb nicht abdriftet.
3. Doppelindex-Speicher: Markdown-Dateien für Menschen zum Lesen, SQLite FTS5 verwaltet Stichwörter, Vektoren werden als BLOB in derselben Datenbank für die semantische Suche gespeichert, hybrive Bewertung, ohne Vektor Degradierung zu Stichworten. Für Einbettungen reicht eine Lösung wie llama-cpp-python im Prozess; beim Modellwechsel werden alte Vektoren komplett verworfen.
4. Konsolidierer: Starten Sie eine asynchrone Schleife, die durch Nachrichtenanzahl oder Leerlaufdauer ausgelöst wird, und lassen Sie das Modell das Transkript zu drei Stufen komprimieren: Voreinstellungen, Projekt, tägliche Zusammenfassungen; Zusammenfassungen mit Verfallsfenster (14 Tage Volltext / 60 Tage gekürzt / 180 Tage eine Zeile).
5. Lektionsbibliothek: Eine append-only JSONL reicht, vor dem Injizieren in den Prompt nach Gültigkeitsbereich filtern, beim Schreiben semantische Deduplizierung und Ausmusterung alter Datensätze von ersetzten Werten.
6. Drei Wecker: Cron-Ausdrücke für Zeitplanung mit Zeitzone und Zeitlimit für jede Phase, Herzschlagdatei verwendet ein Wächter-Signal für „noch nicht fertig“, Zielschleife mit Budget an der Wanduhr und protokolliertem Stoppgrund.
7. Sicherheitstor: Alle Tool-Aufrufe gehen zuerst durch den eigenen Checkpoint, bevor sie durchgelassen werden, ergänzt durch Verzeichnis für Ablehnungen, Schutz sensibler Pfade und Anonymisierung von Anmeldedaten. Dieser Schritt darf nicht weggelassen werden – unbeaufsichtigter Betrieb vergrößert die Berechtigungen, nicht die Intelligenz.

Zusammengenommen kann ein Zwei-Personen-Team in einem Quartal eine brauchbare Version liefern. Die über zweitausend Testdateien von Kiro Crew erinnern an die andere Hälfte der Wahrheit: Ein Skelett, das läuft, ist nichts wert; das Sperren, die Grenzen, die Fehlermodi Zoll für Zoll richtig zu schleifen, ist das, was wert ist.

Fazit

Kiro Crew definiert die AI-Programmier-Workbench neu von „einem Gespräch“ zu „einem persistenten Status“: fünf Speicherarten, drei Wecker, dreistufige Festigung, alles lokal priorisiert, und jede Ebene gibt eine Erklärung auf Quellcodeebene. Es ist ein Open-Source-Werk des Amazon Kiro-Teams, hart an kiro-cli gebunden, die tatsächliche Nutzungsgröße bleibt zu verifizieren – aber für Teams, die bereits im Kiro-Ökosystem sind und wollen, dass Agenten Arbeit über Sitzungen hinweg merken, ist es die derzeit am vollständigsten ausgebaute fertige Antwort; für die, die selbst eines bauen wollen, ist der Quellcode ein ehrlicheres Lehrbuch als jeder Blog.

Referenzquellen

• Kiro Crew GitHub-Repository (README, TENETS, GOVERNANCE, NOTICE, MAINTAINERS): https://github.com/kirodotdev/KiroCrew
• Kiro Crew Architekturdokumentation (docs/architecture/overview.md: Dreiteilung, Nachrichtenfluss, Speicherlebenszyklus, Backend-Komponentendiagramm): https://github.com/kirodotdev/KiroCrew/blob/main/docs/architecture/overview.md
• Kiro Crew Quellcode: src/kiro_crew/agent.py (Agent-Spezifikation und Governance-Projektion), session.py (Sitzungspool und Lebenszyklus), memory.py (MemoryStore, Markdown + FTS5), vector_memory.py (VectorMemoryStore, hybrive Suche und Vektorraum-Abstimmung), memory_stores.py (benannte Speicher und Eigentum), learn.py (LessonStore, append-only JSONL), session_ledger.py (Arbeitsbuch und record-Disziplin), agent_state.py (Sidecar-Status und prozessübergreifende Sperre), cron.py (CronService-Planung und Budgetaufschlüsselung), heartbeat.py (HeartbeatService und HEARTBEAT_KEEP-Wächter), autonudge.py (AutoNudgeService-Zielschleife), skills.py (Fähigkeiten laden, Herkunftsnachweis und Deduplizierung), session_summary.py (Zusammenfassung und Anonymisierung)
• GitHub-Repository-Metadaten und Mitwirkendenliste (api.github.com, Stand September 2026); neuestes Release v0.6.0 (2026-09-11)
• kiro.dev (Kiro und kiro-cli offizielle Website)