Die Architektur hinter AIOS.
Ein gemeinsames Objektmodell, spezialisierte Runtimes und klare Verbindungen bilden die Grundlage der Plattform.
Kontrollschicht und Oberfläche
Das Django-Backend verwaltet Objekte, APIs, Zugriff und Orchestrierung. Das Next.js-Frontend stellt die Arbeitsumgebung bereit. WebSockets halten Veränderungen und laufende Arbeit in der Oberfläche aktuell.
Verfolge eine konkrete Aufgabe durch die Architektur, bevor du einzelne Komponenten bewertest. Die Oberfläche macht den Auftrag und seinen Zustand sichtbar; das Backend verwaltet den zugehörigen Kontext und die Orchestrierung. Die Agent Runtime übernimmt die Agent-Ausführung und nutzt dabei die verfügbaren Werkzeuge und Modellverbindungen. Das entstehende Ergebnis gehört anschließend wieder in den fachlichen Zusammenhang der Aufgabe.
Ausführung in eigenen Runtimes
Die native Rust Agent Runtime führt Agent-Aufgaben aus. Modell-Runtimes verbinden lokale und externe Inferenz. Website-Projekte laufen über die Site Runtime. Dadurch können Ausführungsumgebungen getrennt vom zentralen Datenmodell weiterentwickelt werden.
Für den Betrieb ist die Unterscheidung zwischen Nachricht, Zustand und Artefakt entscheidend. Eine Nachricht beschreibt eine Änderung oder stößt Arbeit an. Relationale Daten halten strukturierte Informationen fest, während Dateien und größere Ergebnisse im Objektspeicher liegen. Plane Wiederherstellung und Fehlersuche entlang dieser unterschiedlichen Verantwortlichkeiten. Ein erreichbarer Dienst allein belegt noch nicht, dass eine Aufgabe fachlich vollständig abgeschlossen wurde.
AIOSEreignisse und dauerhafter Zustand
NATS verbindet Services über Ereignisse und Nachrichten. PostgreSQL hält relationale Daten, Redis unterstützt flüchtigen Zustand und schnelle Zugriffe. S3-kompatibler Objektspeicher verwaltet Dateien und Artefakte.
Grenze Störungen zunächst anhand der sichtbaren Wirkung ein: Fehlt ein Objekt, bleibt ein Lauf offen oder lässt sich ein entstandenes Artefakt nicht öffnen? Halte Aufgabe, Zeitpunkt und betroffenen Bereich fest, bevor du in die zuständige Komponente wechselst. Der System Manager bietet berechtigten Betreibern Einblicke in Dienste und Runtimes; er gehört nicht zum normalen SaaS-Nutzerzugang.
Ein Fundament, mehrere Betriebsmodelle
Public Cloud, dedizierte Cloud oder eigene Infrastruktur stellen unterschiedliche Anforderungen an Netzwerke, Updates und Betrieb. Die Architektur bleibt modular; Ressourcen und Zuständigkeiten müssen je Umgebung geplant werden.
Zum Ausprobieren
Passe die Platzhalter an deine Aufgabe an. Das Beispiel ist eine Vorlage für deine Arbeit mit AIOS.
Beobachteter Vorgang: [Aufgabe und erwartetes Ergebnis]
Zeitpunkt und Umgebung: [Wann und wo trat das Problem auf?]
Sichtbare Wirkung: [Fehlendes Objekt / Laufstatus / Artefakt / andere Beobachtung]
Betroffene Komponenten: [Soweit bekannt]
Vorliegender Zustand: [Was ist sichtbar, was fehlt?]
Letzte bekannte Änderung: [Konfiguration oder Update, falls bekannt]
Zuständiger Betreiber: [Person/Team]
Nächster Prüfschritt: [Konkrete Beobachtung, die die Ursache eingrenzen soll]
Annahmen getrennt von bestätigten Beobachtungen festhalten. Keine Zugangsdaten in die Übergabe aufnehmen.Komponenten nach Verantwortung lesen
| Bereich | Aufgabe in der beschriebenen Architektur | Typische Prüffrage |
|---|---|---|
| Django und Next.js | Objekte, APIs, Zugriff, Orchestrierung und Arbeitsoberfläche. | Ist der fachliche Kontext vorhanden und zugänglich? |
| Agent-, Modell- und Site-Runtimes | Spezialisierte Ausführung von Aufgaben, Inferenz und Website-Projekten. | Welche Ausführungsumgebung betrifft der Vorgang? |
| NATS und Redis | Nachrichten zwischen Services sowie flüchtiger Zustand und schnelle Zugriffe. | Welche Nachrichten oder vorübergehenden Zustände sind für den Ablauf relevant? |
| PostgreSQL und Objektspeicher | Relationale Daten sowie Dateien und Artefakte. | Sind die benötigten Daten und Ergebnisse verfügbar? |