NanoClaw Architektur und Laufzeit
1. Die Gestalt des Workspace​
Die README liefert eine bemerkenswert klare Architekturzusammenfassung:
| Bereich | Zweck |
|---|---|
| Host-Prozess | Routing, Zustellung, Sweeps, Sitzungsauflösung |
| Container pro Agent | fĂĽhren Claude- oder andere anbietergestĂĽtzte Agent-Logik aus |
| SQLite-Sitzungsdateien | ein- und ausgehender Nachrichtenfluss |
| Kanal-Adapter | verbinden mit Telegram, Discord, Slack und anderen |
| Anbieter-Registry | konfiguriert Claude standardmäßig und andere Anbieter über Skills |
Das ist eine von NanoClaws größten Stärken: Die Architektur ist erklärbar.
2. Das mentale Laufzeitmodell​
Die Upstream-Architekturskizze lautet:
- ein Kanal empfängt eine Nachricht,
- der Host routet sie zur richtigen Gruppe und Sitzung,
- die Nachricht landet in
inbound.db, - der containerisierte Runner verarbeitet sie,
- das Ergebnis wird in
outbound.dbgeschrieben, - der Host stellt es ĂĽber den Kanal-Adapter zurĂĽck.
Das ist ein starkes Design, weil es Zuständigkeiten getrennt hält und gemeinsamen In-Process-Agent-Zustand vermeidet.
3. Warum das Zwei-Datenbank-Modell wichtig ist​
Die README hebt hervor, dass jede Sitzung Folgendes nutzt:
- einen Writer fĂĽr eingehend,
- einen Writer fĂĽr ausgehend,
- keine Shared-Memory-IPC,
- und kein fragiles stdin-Piping.
Das macht die Laufzeit leichter durchschaubar und robuster im Hintergrundbetrieb.
4. Skills statt Features​
Ein weiterer wichtiger Architekturpunkt ist, dass Kanäle und zusätzliche Anbieter per Skill installiert werden sollen, statt dauerhaft im Trunk zu leben.
Das hält Forks schlank und macht das Projekt komponierbarer.
5. Was man im Code zuerst lesen sollte​
Beginne mit:
- dem Architekturabschnitt der README,
src/index.ts,- den Router- und Zustellungsdateien,
- dem Container-Runner und den Anbieterflächen,
groups/und den per Skill installierten Modulen.