TinyAGI Architektur und Runtime
1. Die Form des Workspace​
Die README offenbart bereits die zentrale Produktstruktur:
| Bereich | Warum es wichtig ist |
|---|---|
| Agents | isolierte Worker mit spezialisierten Rollen |
| Teams | Kollaborationsschicht fĂĽr Ăśbergaben und Fan-out |
| Channels | externe Messaging-Oberflächen |
| SQLite-Queue | atomare Jobs, Retries, Dead-Letter-Handling |
| TinyOffice | Browser-Dashboard und visuelle Steuerungsebene |
Das ist eine umfangreichere Runtime als eine normale Single-Assistant-Terminal-App.
2. Das mentale Modell der Runtime​
Zur Laufzeit funktioniert TinyAGI ĂĽblicherweise so:
- eine Nachricht oder Aufgabe gelangt ins System,
- die Queue persistiert und plant sie,
- ein Agent oder Team verarbeitet sie,
- Ergebnisse werden nach TinyOffice und in die Logs gestreamt,
- Antworten können über Channels zurückkehren oder im Portal bleiben.
3. Warum die Queue wichtig ist​
Die SQLite-Queue ist kein langweiliges Implementierungsdetail. Sie ist einer der GrĂĽnde, warum TinyAGI Folgendes unterstĂĽtzen kann:
- parallele Arbeit,
- Retries,
- Hintergrundbetrieb,
- und ein robusteres 24/7-Verhalten.
4. Warum TinyOffice wichtig ist​
TinyOffice ist nicht nur ein Dashboard. Es ist die menschliche Steuerungsoberfläche für:
- Chat,
- Agents und Teams,
- Aufgaben,
- Logs,
- und Einstellungen.
Das macht es zentral fĂĽr die Runtime, besonders fĂĽr Betreibende, die nicht im Terminal arbeiten.
5. Was du zuerst im Code lesen solltest​
Beginne mit:
- dem Schnellstart der README,
- den Queue- und Daemon-Oberflächen,
- dem Team- und Agent-Code,
- den TinyOffice-bezogenen Bereichen,
- zuletzt den Channel-Adaptern.