Das Fundament des Agenten neu schreiben: Orkas von Grund auf refaktoriert

Wenn ein KI-Agentenprodukt reift, sind nicht die Funktionen das Teuerste — sondern das Fundament. Dieser Artikel beschreibt die grundlegende Refaktorierung, die Orkas über seine 1.0-Versionsreihe hinweg durchgeführt hat — eine vollständige Überarbeitung von Modellaufrufen, Agentenschleife, Orchestrierung mehrerer Agenten und Tool-Ökosystem — sowie die Abwägungen hinter jeder Entscheidung.

Warum das Fundament anfassen

Orkas ist ein lokal ausgerichteter Desktop-Arbeitsbereich für KI-Agenten: Die gesamte Agentenarbeit läuft in einem Prozess auf dem Rechner des Nutzers, Daten liegen lokal, und eine durchgängige Cloud-Synchronisierung erfolgt bei Bedarf. In den frühen Versionen kamen schnell viele Funktionen hinzu — eine Skill-Bibliothek, eine Wissensdatenbank, Konnektoren, mehrere Agenten im Gruppenchat-Stil. Doch je weiter wir kamen, desto deutlicher wurde: Der eigentliche Engpass war keine einzelne Funktion, sondern drei Dinge auf „Fundamentebene“.

1. Wenn die Modellaufrufschicht dem alten Gesprächsmuster folgt, wird sie durch eine Reihe falscher Annahmen eingeschränkt. Ein großes Modell wie einen „Eine-Frage-eine-Antwort-Chat“ aufzurufen bringt eine Reihe von Voreinstellungen mit, die für Chats sinnvoll sind, aber nicht für Agenten: eine feste Obergrenze für Ausgabetokens, serielle Tool-Aufrufe, verborgene Zeitlimits, einen einzigen fest eingebauten Anbieter. Ein Agent ist ein lang laufender Ablauf, der Dutzende Gesprächsschritte nacheinander ausführt, regelmäßig an das Kontextfenster stößt, Dateien parallel lesen muss und jederzeit vom Nutzer unterbrochen werden kann — jede dieser Voreinstellungen wird im Produktivbetrieb zum Problem. Schlimmer noch: Die wertvollsten Fähigkeiten eines Desktop-Agenten — feingranulare Dateioperationen, lokale Suche, Shell-Ausführung, parallele Ausführung mehrerer Arbeitsagenten und das Lösen langwieriger Aufgaben — sind genau diejenigen, die diese Annahmenschicht ausschließt.

2. Die Orchestrierung war „statische Planung“. Die frühe Version war eine Plan-/DAG-Engine: Zuerst zerlegte das Modell die Aufgabe in einen Plangraphen, dann verteilte ein Executor die Arbeit anhand dieses Graphen. Das klingt ordentlich, doch die Realität eines Agenten ist hochdynamisch — beim Lesen einer Datei zeigt sich, dass eine Richtungsänderung nötig ist, und das Ergebnis einer Teilaufgabe bestimmt, wer den nächsten Schritt übernimmt. Werden Entscheidungen in einem vorab erzeugten Graphen eingefroren, muss jedes „Der Plan hält mit der Realität nicht mit“ im Executor nachgebessert werden.

3. Das Ökosystem war ein geschlossener Katalog. Skills konnten nur aus dem offiziellen Marktplatz stammen, Konnektoren bildeten einen fest programmierten Katalog, und externe Agenten-Tools auf dem Rechner des Nutzers waren für Orkas eine vollständige Blackbox. Ein Drittanbieter-Projekt oder einen eigenen MCP-Server einzubinden oder einen bereits auf dem Rechner vorhandenen Agenten auf die Skills und Wissensdatenbank von Orkas zugreifen zu lassen — architektonisch war nichts davon möglich.

Die Leitidee dieser Refaktorierung ist einfach: das Fundament des Agenten wieder in die eigene Hand nehmen. Konkret ergeben sich daraus vier miteinander verflochtene Linien — eine selbst entwickelte Laufzeitumgebung im eigenen Prozess, eine anbieterunabhängige Modellschicht, dynamische Gruppenchat-Orchestrierung und der Wechsel vom geschlossenen Katalog zum offenen Host. Gehen wir sie einzeln durch.

1. Den vollständigen Funktionsumfang eines Programmieragenten auf den Desktop bringen

Der Desktop ist das natürliche Umfeld des Agenten — hier gibt es ein echtes Dateisystem, eine echte Shell und eine echte lokale Toolchain. Ein Assistent, der nur chatten kann, verschenkt diese Umgebung. Was den Vorteil des Desktops tatsächlich nutzt, ist ein vollständiger Funktionsumfang eines Programmieragenten: Dateizugriffe bis hinunter zum Zeichenbereich, dateiübergreifende Suche, Ausführung von bash und Systemtools, paralleler Start mehrerer Arbeitsagenten und die Fähigkeit, über Dutzende Gesprächsschritte hinweg an komplexen Aufgaben zu arbeiten, bis sie tatsächlich abgeschlossen sind.

Das zentrale Ergebnis der Refaktorierung dient genau dazu, diese Fähigkeiten nativ in den eigenen Prozess von Orkas zu integrieren — eine eigenständige, dynamisch ladbare Agenten-Laufzeitumgebung innerhalb des Prozesses (im Code core-agent genannt). Das ist nicht noch eine Chat-Hülle, sondern eine Agenten-Engine, die Orkas selbst kontrolliert.

Die entscheidende Architekturentscheidung war die Aufteilung in zwei Schichten:

• Engine-Schicht (eigenständiges Paket): reine Agentenmechanik — die Tool-Aufrufschleife, Streaming-Ereignisse, Kontextverdichtung, Fehlerklassifizierung und Wiederholungen, Anbieterabstraktion, Sandbox, Skill-Erkennung, Gedächtnis und Selbstweiterentwicklung. Sie weiß nichts über die Geschäftslogik von Orkas: Sie liest keine Geschäftsdatenverzeichnisse, kennt das Gesprächsdateiformat nicht und greift nie auf IPC zu.
• Adapterschicht (im Hauptprozess): bindet die Engine in Orkas ein — Sitzungspersistenz, Anbieterrotation, Tool-Berechtigungen, Skill-Register, Konnektoren, Wissensdatenbank und verschiedene Generierungstools. Sie übersetzt die nativen Ereignisse der Engine in die Ereignisformen von Orkas, sodass die Geschäftslogik nur eine stabile Schnittstelle sieht.

Diese Grenze zwischen Engine und Adapter ist die Grundlage der gesamten folgenden Flexibilität. Die Engine lässt sich unabhängig testen und weiterentwickeln; die Adapterschicht kann Orkas-spezifische Komplexität (Rotation, Abkühlphase, Sandbox, Berechtigungen) sicher aufnehmen, ohne die Engine damit zu belasten. Das Architektur-Review des Teams fasste es in einem Satz zusammen: Diese Komplexität ist gerechtfertigt — führen Sie die Schichten nicht zusammen.

Was der Funktionsumfang tatsächlich umfasst

Die Laufzeitumgebung selbst zu kontrollieren dient nicht der Selbstdarstellung, sondern ermöglicht dem Agenten, auf dem Desktop wirklich „mit anzupacken“. Die Fähigkeiten lassen sich grob in vier Gruppen einteilen:

• Feingranulare Dateioperationen und lokale Suche. read_file unterstützt das Lesen nach Zeichenbereich und extrahiert automatisch Text aus PDF-/Office-Dokumenten; edit_file führt präzise Ersetzungen nach dem Muster „alte Zeichenfolge → neue Zeichenfolge“ aus und verlangt vor jedem Schreiben einen Lesezugriff; write_file speichert das Arbeitsergebnis und protokolliert es; stat_file ermittelt die Größe; search_files sucht nach Name/Glob, grep_files durchsucht Inhalte dateiübergreifend. Diese Gruppe ermöglicht es dem Agenten, wie ein Entwickler in einem echten Arbeitsbereich „Code zu durchforsten und Dateien zu ändern“, statt nur ganze Blöcke aufnehmen und ausgeben zu können.
• Bash und Systemtools. Ein Shell-Executor in einer Sandbox, mit Hintergrundmodus (lange Aufgaben lösen sich vom aktuellen Gesprächsschritt, Protokolle gehen in eine Datei) und nach Risiko abgestuften Freigaben für gefährliche Vorgänge. Ein großer Teil der Leistungsfähigkeit eines Desktop-Agenten entsteht gerade dadurch, dass er die System-Toolchain direkt steuern kann.
• Mehrere parallele Arbeitsagenten. Innerhalb eines Gesprächsschritts laufen unabhängige, rein lesende Tools gleichzeitig; auf Aufgabenebene kann der Commander außerdem unabhängige Teilaufgaben parallel auf mehrere Arbeitsagenten verteilen (siehe Abschnitt 3). Sichere Parallelisierung ist der Schlüssel, um „langwierige Aufgaben“ auf eine akzeptable tatsächliche Laufzeit zu verkürzen.
• Langfristiges Schlussfolgern und Aufgabenlösen. Eine Schleife, die Dutzende Gesprächsschritte nacheinander ausführen, ihren eigenen Kontext verwalten, sich von Fehlern erholen und nicht auf der Stelle treten kann — das unterscheidet „eine komplexe Arbeit fertigstellen“ von „eine Frage beantworten“.

Wie sie technisch produktionsreif wurde

„Eine eigene Schleife schreiben“ klingt, als würde man Probleme suchen, und es verursacht tatsächlich Wartungsaufwand. Dafür erhält man feingranulare Kontrolle über den gesamten Lebenszyklus des Agenten. Diese Kontrolle ist nicht abstrakt — sie besteht aus konkreten Verbesserungen, von denen jede darüber entscheidet, ob eine der genannten Fähigkeiten im Produktivbetrieb Bestand hat:

• Tatsächliches Kontextfenster + Verdichtung erst bei 80%. Die Engine liest für jedes Modell das tatsächliche Kontextfenster (einschließlich Modellen mit Millionen-Token-Fenstern) und löst die Verdichtung erst bei 80% Auslastung aus — statt vorsichtshalber schon bei 60% zu beginnen und 40% des nützlichen Kontexts wegzuwerfen. Es gibt außerdem einen Schutz vor „Verdichtung ohne Gewinn“: Wenn der beibehaltene jüngste Verlauf das Fenster bereits ausfüllt (etwa durch ein sehr großes Dateileseergebnis), kann die Verdichtung nichts freigeben. Dann wird nur eine Warnung protokolliert und der Vorgang übersprungen, statt einen nutzlosen Zusammenfassungsaufruf auszuführen. Davon hängt ab, ob eine langwierige Aufgabe sich „an das Vorherige erinnern“ kann.

• Benachbarte rein lesende Tools parallel. Wenn das Modell in einem Gesprächsschritt mehrere unabhängige rein lesende Tools wie Dateilesen, Dateisuche und Webrecherche auslöst, bündelt die Engine benachbarte parallelisierbare Aufrufe und führt sie gleichzeitig aus. Schreibende Tools bilden natürliche Grenzen und behalten ihre deklarierte Reihenfolge. Tool-Aufrufe und Ergebnisse werden strikt in der deklarierten Reihenfolge festgeschrieben, sodass Parallelität nie das Protokoll verletzt. Die häufigsten rein lesenden Tools wechseln damit auf einen Schlag von seriell zu parallel, und die tatsächliche Laufzeit des gesamten Pakets sinkt spürbar.

• Lesen vor Schreiben + optimistische Nebenläufigkeitskontrolle. Vor der Bearbeitung einer Datei muss sie gelesen werden. Die Engine erfasst einen Ausgangsstand der gelesenen Datei und prüft bei der Bearbeitung, ob dieser unverändert ist. Wenn parallele Arbeitsagenten gleichzeitig dieselbe Datei ändern, erhält der unterlegene einen klaren Fehler wegen eines veralteten Stands, statt dass Änderungen stillschweigend überschrieben werden. Wenn mehrere Arbeitsagenten parallel im selben Arbeitsbereich arbeiten, ist dieser Schutz unverzichtbar.

• Unterbrechungen während der Ausführung sofort einbeziehen. Wenn ein Nutzer während der Arbeit des Agenten eine weitere Nachricht ergänzt, nimmt die Engine diese eingereihte Nachricht in den aktuellen Gesprächsschritt an der Grenze der Tool-Schleife als Eingabe auf, statt auf einen separaten Gesprächsschritt zu warten. So wird „während der Ausführung den Kurs korrigieren“ zu einer natürlichen Interaktion.

• Schleifenerkennung. Wenn derselbe Tool-Aufruf direkt hintereinander wiederholt wird, gibt die Engine zunächst einen Hinweis (beim 3.) und stoppt dann hart (beim 5.); jede abweichende Signatur setzt den Zähler zurück — zulässige Varianten wie Seitennavigation oder Polling lösen daher nicht fälschlich aus. Wenn das Modell festhängt, verbraucht es nicht mehr stillschweigend Tokens.

• Aufhebung der festen Ausgabegrenze für Hauptgesprächsschritte. Die Ausgabe im Hauptgesprächsschritt ist nicht mehr auf eine winzige Obergrenze festgelegt, sodass lange Berichte und große Änderungen nicht stillschweigend abgeschnitten werden. Hilfsaufrufe (Verdichtung, Reflexion) verwenden weiterhin vorsichtshalber eine kleine Grenze.

Ein sehr „lokales“ Detail verdient Erwähnung: Tokenschätzung für gemischten chinesisch-englischen Text. Eine allgemeine Schätzung unterschätzt rein chinesische Gespräche um den Faktor zwei bis drei. Die Engine behandelt chinesische und englische Zeichen anhand ihrer Zeichenklassen unterschiedlich. Erst dadurch wird die Verdichtungsschwelle verlässlich. Solche Dinge nimmt Ihnen ein allgemeines SDK nicht ab.

Zusammen beantworten diese Verbesserungen die Frage „Warum nicht einfach ein fertiges SDK verwenden?“: Weil die stärksten Fähigkeiten eines Desktop-Agenten genau in der Schicht liegen, die ein SDK nicht offenlegt. Um sie produktionsreif zu machen, muss man die Schleife selbst kontrollieren.

2. Das Modell verfügbar halten: die mehrschichtige Anbieterhülle

Das Ziel der Modellschicht lässt sich in einem Satz ausdrücken: Was auch immer mit einem bestimmten Schlüssel, Anbieter oder Netzwerk schiefgeht — dieser Gesprächsschritt des Nutzers soll nach Möglichkeit erhalten bleiben. Dazu legt die Adapterschicht mehrere Hüllen über die Anbieterabstraktion der Engine — Rotation, Abkühlphase, Registrierung und externe Anpassung.

Die wichtigste Entwurfsentscheidung ist, dass der Rotator unterhalb des Runners liegt. Die Engine schreibt die Nutzernachricht in die persistente Sitzung, bevor sie überhaupt einen Anbieter aufruft. Würden Wiederholungen oder Rotation auf Engine-Ebene erfolgen, müsste man entweder die Nutzernachricht erneut einreichen oder eine vollständige Sitzungsrücksetzung implementieren. Liegt der Rotator unterhalb der Engine, wird die Nutzernachricht genau einmal geschrieben, und „mit einem anderen Kandidaten erneut versuchen“ bleibt für den Sitzungszustand vollständig transparent.

Auch die Entscheidung des Rotators ist zurückhaltend und orientiert sich an der Grenze des ersten Inhaltsereignisses:

• Ein Fehler, bevor das Modell substanziellen Inhalt ausgibt (Text/Tool-Aufruf) — sicherer Wechsel zum nächsten Kandidaten;
• Sobald das erste Inhaltsereignis ausgegeben wurde — Rotation stoppen und den Fehler nach oben weitergeben, da das Modell möglicherweise bereits einen vollständigen Gesprächsschritt ausgeführt hat und eine Wiederholung Nebenwirkungen doppelt auslösen würde.

Die Fehlerklassifizierung entscheidet zwischen „rotieren, nicht rotieren oder wiederholen“. Kontobezogene Fehler wie Authentifizierungsfehler, unzureichendes Guthaben, Ratenbegrenzung oder abgelaufenes Abonnement — Abkühlphase markieren und rotieren; vorübergehende Netzwerkfehler wie ein Verbindungsabbruch — keine Abkühlphase, einige zustandslose Wiederholungen an derselben Stelle. Fehlerhafte Anfragen, Inhaltsrichtlinien und Server-5xx-Fehler, die mit einem anderen Schlüssel genauso auftreten würden, werden dagegen direkt ohne Rotation weitergegeben. Die Abkühlphase ist ein zehnminütiger, prozessinterner, nicht persistenter Hinweis: Sie ist nur ein kurzfristiges Signal, das nicht bei jedem Fehler auf die Festplatte geschrieben werden muss, und ein Prozessneustart ist genau der richtige Zeitpunkt für eine erneute Prüfung.

Beim Anbieterbestand führt die Refaktorierung drei Arten von Quellen zu einer einheitlichen Abstraktion zusammen:

• Von Orkas verwaltetes LLM: ein serverseitiger Proxy, nach der Anmeldung sofort nutzbar, wobei der Server zwischen Text-/Bildmodellen routet;
• Eigener Schlüssel: übliche etablierte Anbieter großer Modelle;
• Externe Direktverbindungsadapter: eine Gruppe von Modellen, die eine direkte Verbindung benötigen oder eine eigene Abrechnung haben und manuell an dieselbe Anbieterschnittstelle angepasst wurden.

Für die darüberliegenden Schichten erscheint all das nur als ein stabiles (provider, model) Paar — Rotation, Abkühlphase und externe Anpassung sind vollständig in der Adapterschicht verborgen.

3. Gruppenchat als Orchestrierung: vom statischen Plan-DAG zum eingebundenen Commander

Dies ist der Teil der Refaktorierung, der das stärkste Umdenken verlangt.

Das alte Modell war statische Planung: Das Modell erzeugt zuerst einen Plan/DAG, und der Executor arbeitet den Graphen ab. Das neue Modell entfernt diesen Graphen vollständig und ersetzt ihn durch eine dynamische Gruppenchat-Orchestrierung mit eingebundenem Commander.

Ihre Metapher ist ein Gruppenchat-Raum:

• Der Commander ist der Gastgeber des Raums, keine unsichtbare Middleware;
• Arbeitsagenten sind vollwertige, gleichberechtigte Mitglieder im Raum;
• Alle Interaktionen sind asynchrone Nachrichten, die über einen einzigen Nachrichtenbus eingereiht werden (es gibt keinen privaten Weg zur parallelen Verteilung).

Die „Beauftragung“ durch den Commander ist kein im Fließtext geschriebenes @somebody — wenn ein LLM @AgentA in den Nachrichtentext schreibt, ist das nur Markdown aus Trainingsdaten und nicht vertrauenswürdig. Das eigentliche Beauftragungssignal ist ein strukturierter Tool-Aufruf, der nach der Refaktorierung auf drei semantisch klare Aktionen hinausläuft:

• dispatch_to — einen Agenten bis zum Abschluss arbeiten und das Ergebnis zurückgeben lassen, das der Commander zusammenführt. Mehrere unabhängige Aufgaben können gleichzeitig verteilt werden.
• run_worker — eine Teilaufgabe, die der Commander selbst verantwortet und deren Ergebnis synchron zurückgegeben wird; ein anonymer Arbeitsagent ist die „Hand“ des Commanders (für den Nutzer unsichtbar), während ein benannter Arbeitsagent ein sichtbarer Spezialist ist.
• hand_off_to — die Übergabe des Gesprächs an den Agenten; der Commander zieht sich zurück, und der Agent antwortet dem Nutzer in diesem Gesprächsschritt direkt, ohne zusätzliche Zusammenfassung.

Warum Gruppenchat statt Orchestrator oder Unteragentenbaum

Mehrere Agenten als Gruppenchat zu organisieren bringt Vorteile, die ein herkömmlicher Orchestrator oder Unteragentenbaum nicht erreicht:

• Sichtbarkeitsausschnitte. Jede Nachricht wird nur dem Ausschnitt derjenigen hinzugefügt, „die sie sehen dürfen“. Wenn ein Arbeitsagent startet, spielt er nur seinen eigenen Ausschnitt erneut ein, sodass große Ausgaben anderer Agenten seinen Kontext nicht belasten. Der Commander sieht alles.
• Minimaler Zustand. Der Kernzustand der gesamten Orchestrierung besteht nur aus „Wer hat gerade das Wort?“ und einem schlanken Aufgabenregister. Kein DAG, kein komplexer Zustandsautomat.
• Von Natur aus wiedergebbar und synchronisierbar. Nachrichten lassen sich von selbst nach Zeitstempel sortieren, sodass Neuladen und geräteübergreifende Synchronisierung direkt auf dem Nachrichtenstrom aufbauen. Das Mobilgerät nutzt genau diesen Strom zur Fernsteuerung — sämtliche Agentenberechnungen laufen auf dem Desktop, während das Mobilgerät lediglich eine gespiegelte Darstellung zeigt und kein spezielles Orchestrierungsprotokoll benötigt.

Das Architektur-Review des Teams war auch hier eindeutig: Ein Gruppenchat-Bus mit eingebundenem Commander ist die Form der Mehragentenarbeit von Orkas. Einen weiteren parallelen Unteragenten-Beauftragungsweg im Prozess hinzuzufügen würde dagegen die Invariante „nur ein Beauftragungsweg über den Gruppenchat“ verletzen.

Neu in dieser Version: interaktive Übergabe

Die neueste Ergänzung in diesem Bereich ist die interaktive Agentenübergabe.

Das Problem ist konkret: Ein Agent vom Typ „Tutor“ unterrichtet den Nutzer einen Gesprächsschritt lang. Der Nutzer möchte weiter nachfragen, aber das System gibt das Wort zwangsweise an den Commander zurück, sodass der Nutzer bei jeder Frage erneut per @ den Agenten ansprechen muss.

Die Lösung ist ein serverseitig verbindliches Rederecht plus ein vom Modell bestimmter Empfänger:

• Das Rederecht wird zu einem persistenten Zustandsfeld, das beim Neuladen erhalten bleibt und über das bestehende Zustandsänderungsereignis für die automatische Synchronisierung mit allen Endgeräten übertragen wird — kein neuer Ereignistyp erforderlich.
• Nachdem der Commander mit hand_off_to das Wort an einen interaktiven Agenten übergeben hat, gehen die folgenden Nutzernachrichten „ohne @“ direkt an diesen Agenten, bis der Agent von sich aus zurückgibt oder der Nutzer wieder den Commander anspricht.
• Der Agent gibt die Kontrolle mit der Markierung <handback /> zurück; die Auswertung prüft streng auf eine echte Übereinstimmung (damit ein beiläufiges <handback im Fließtext nicht als Übergabe fehlinterpretiert wird).
• Wenn bei der Rückgabe unerledigte Aufgaben im Register stehen, übernimmt der Commander sie daraus und arbeitet weiter.

Damit einher geht auch eine Verbesserung der Bedienung — Nachrichtenblasen für die Commander-Schleife. Die Schleife „beauftragen → Ergebnis lesen → erneut beauftragen“ des Commanders innerhalb eines Gesprächsschritts wurde früher zu einer einzigen Blase zusammengefasst und sprang beim Neuladen sogar aus der Reihenfolge ans Ende. Die Refaktorierung teilt einen Gesprächsschritt an jeder sichtbaren Beauftragungsgrenze in mehrere Abschnitte, jeweils als eigenständige Nachricht mit aufsteigendem Zeitstempel. Erstmals kann der Nutzer sehen, wie der Commander die Orchestrierungsschleife durchläuft, und auch die Reihenfolge nach dem Neuladen stimmt.

Schließlich zwei durchgängige Sicherheitsnetze: Der Gruppenabbruch ist der einzige Stopppfad für alle Beteiligten (sobald der Nutzer auf Stopp klickt, wird das Abbruchsignal jedes Arbeitsagenten ausgelöst; selbst anonyme Unteragenten werden durch einen Ersatzabgleich erfasst); sowie die bereits erwähnte Steuerung durch Unterbrechung, die Zwischenbemerkungen des Nutzers während der Ausführung in den aktuellen Gesprächsschritt einbezieht.

4. Vom geschlossenen Katalog zum offenen Host

Wenn es bei den ersten drei Linien darum ging, das Fundament zu festigen, geht es hier darum, alle Türen und Fenster zu öffnen — Orkas von einem geschlossenen Katalog in einen offenen Host zu verwandeln — und dabei die Sicherheitsgrenze ohne jeden Abstrich zu halten.

Die Refaktorierung beseitigte systematisch mehrere „geschlossene“ Engstellen:

• Externe Pakete. Der Nutzer gibt eine Repository-Adresse an, und Orkas verwaltet das Paket lokal, unverändert in einen Ordner geklont — niemals normalisiert, niemals umgeschrieben, niemals mit der Cloud synchronisiert (weil es Abhängigkeitsverzeichnisse Dritter enthält). Ein eigenständiges Kommandozeilentool verwaltet Installation, Aktualisierung, Start und Stopp, prüft auf „Skill-Form“ (mit Skill-Beschreibungsdatei) oder „CLI-Form“ (mit ausführbarem Einstiegspunkt) und schreibt die Metadaten in ein Register außerhalb des Paketverzeichnisses (damit spätere Pull-Aktualisierungen nie in Konflikt geraten). Die Installation von Abhängigkeiten erfolgt über eine zweistufige Bestätigung nach dem Prinzip „einmal fragen, merken“; für ausführbare Einstiegspunkte werden Shims erzeugt und in den PATH des bash-Tools eingefügt, sodass das Modell diese Drittanbieter-CLIs direkt aufrufen kann.

• Skill-Laden aus mehreren Wurzelverzeichnissen. Der einzige Einstiegspunkt für die Skill-Ausführung wurde von zwei bekannten Wurzeln auf vier nach Priorität aufgelöste Ebenen erweitert — benutzerdefiniert / Marktplatz / externes Paket / global. Skripte innerhalb eines externen Pakets bevorzugen dessen eigene mitgelieferte Abhängigkeitsumgebung. Diese Engstelle birgt das höchste Regressionsrisiko und ist durch eine vollständige Testdatenmatrix abgesichert.

• Globale Skill-Interoperabilität. Orkas liest direkt aus den globalen Skill-Verzeichnissen, die andere Agenten-Tools auf dem Rechner des Nutzers bereits verwalten, und erreicht so Interoperabilität auf Skill-Ebene — ein an einer Stelle gesammelter Skill ist auch in Orkas nutzbar. Das Ablegen eines Skills in diesen Verzeichnissen durch den Nutzer gilt selbst als Autorisierung. Deshalb ist dies standardmäßig aktiviert, mit einem zentralen Schalter als Kontrollmöglichkeit. Diese Skill-Beschreibungen Dritter sind eine nicht vertrauenswürdige Angriffsfläche für Prompt-Injektionen. Daher durchlaufen sie den Loader der „offenen Ebene“, sind nur für den Commander sichtbar und können strukturell nicht in die Skill-Zulassungsliste eines Agenten gelangen.

• Vom Nutzer konfiguriertes MCP. Konnektoren sind kein fest programmierter Katalog mehr. Der Nutzer kann jeden MCP-Server hinzufügen — als entfernte HTTP-Verbindung (geringes Risiko) oder lokalen Unterprozess (hohes Risiko). Das Formular selbst ist die Zustimmungsoberfläche (der manuell eingegebene Befehl wird wortgetreu angezeigt), die Transportkonfiguration einschließlich Geheimnissen wird vollständig verschlüsselt gespeichert, und benutzerdefinierte Instanzen tragen stets ein festes Präfix, sodass sie niemals einen offiziellen Konnektor im Katalog imitieren können.

• Rückwärtsbrücke: externe Agenten auf dem Rechner können ihrerseits Orkas wahrnehmen. Dies ist der interessanteste Teil. Externe Agenten-Tools auf dem Rechner des Nutzers waren für Orkas früher eine Blackbox. Wenn Orkas sie jetzt beauftragt, fügt es einen Brückenkanal ein, über den sie in umgekehrter Richtung Orkas-Skills auflisten, lesen und ausführen, Konnektoren aufrufen und die Wissensdatenbank durchsuchen können. Die Brücke läuft über einen lokalen Interprozesskanal (ohne geöffneten Netzwerkport), authentifiziert mit einer einmaligen Zugangsinformation, die für jede Ausführung einzigartig ist und bei deren Ende vernichtet wird. Jeder Konnektoraufruf mit externen Nebenwirkungen durchläuft einen Bestätigungsdialog für den Nutzer — keine heuristische Lese-/Schreibbewertung anhand des Tool-Namens (die zu großzügig ausfallen würde), sondern eine Bestätigung pro Kombination aus Agent und Konnektor, optional mit „Immer erlauben“.

• Programmieransatz für seltene Sonderfälle. Der Entscheidungsbaum des Commanders erhält einen Zweig: Wenn es keinen passenden Agenten, Skill oder Konnektor gibt, eine direkte Lösung mit bash und einem kurzen Skript prüfen, sie in diesem Gesprächsschritt ausführen, das Ergebnis prüfen und optional anbieten, daraus einen benutzerdefinierten Skill zu machen. Dazu gehören die bash-Ausführung im Hintergrund (lange Aufgaben lösen sich vom aktuellen Gesprächsschritt, Protokolle gehen in eine Datei) und vom Nutzer freigegebene Verzeichnisse.

Offen, aber nicht unkontrolliert

Wer Türen und Fenster öffnet, fürchtet vor allem Zugluft. Die Disziplin dieser Refaktorierung lautet: Keine einzige Start-Engstelle für „gefährliche Aktionen“ wird verändert. MCP startet an genau einer Stelle, Skills laufen über genau einen Runner und bash über genau einen Sandbox-Executor. Darüber liegen mehrere zusätzliche Schutzschichten:

• Dateioperationen durchlaufen immer die Pfad-Sandbox (Arbeitsbereich + aktuelle Anhänge + ausdrücklich vom Nutzer freigegebene Verzeichnisse), während Zugangsdatenverzeichnisse, Systemverzeichnisse und Orkas-eigene Verzeichnisse nicht freigegeben werden können;
• Gefährliche bash-Vorgänge (Datenabfluss, destruktives Löschen, Rechteausweitung, sensible Pfade) lösen eine Berechtigungsbestätigung mit den Optionen „Nur dieses Mal / Für diese Ausführung / Ablehnen“ aus. Protokolle erfassen nur Kategorie und Länge — niemals den Befehlstext;
• Die Installation externer Pakete verweigert im Zweifel den Zugriff und lehnt Pakete mit symbolischen Verknüpfungen vollständig ab (damit darüber keine sensiblen Dateien außerhalb der Sandbox eingelesen werden können), und die Klonquelle ist auf eine Protokoll-Zulassungsliste beschränkt;
• Alle Zugangsdaten enthaltenden Transportkonfigurationen und Geheimnisse werden verschlüsselt gespeichert, und Brückenzugangsdaten sind pro Ausführung isoliert;
• Die Open-Source-/gehostete Distribution entfernt Host-exklusive Fähigkeiten anhand einer Kürzungsregel.

In einem Satz: Jede ausdrückliche Nutzerhandlung (installieren / freigeben / Formular absenden / Bestätigung anklicken) ist der Nachweis der Zustimmung, und jede Zustimmung bleibt auf die ihr zustehende Grenze beschränkt.

5. Über Sitzungen hinweg intelligenter werden: Gedächtnis und Selbstweiterentwicklung

Die grundlegende Überarbeitung erneuerte außerdem zwei Subsysteme, die den Agenten „mit zunehmender Nutzung intelligenter machen“. Beide folgen derselben technischen Disziplin — standardmäßig aus, begrenzt, beobachtbar.

Sitzungsübergreifendes Gedächtnis nutzt hybride Suche: semantische Vektorsuche + Stichwortsuche (BM25), zusammengeführt über RRF (Reciprocal Rank Fusion), damit nicht ein einzelner Suchkanal ausfällt. Die Daten werden lokal gespeichert (mit Volltextindex). Es gibt zwei Arten von Gedächtnis — eigene Notizen des Agenten und das Nutzerpräferenzprofil — jeweils mit einer Zeichenobergrenze, vor dem Schreiben auf Injektionsrisiken geprüft und als unveränderlicher Stand zu Beginn jedes Gesprächsschritts in den Systemprompt eingefügt. Das gesamte Gedächtnissystem dient nur dazu, dass der Agent den aktuellen Nutzer besser versteht. Die Daten bleiben immer lokal, und der Nutzer kann sie jederzeit in den Einstellungen ansehen, bearbeiten und exportieren.

Selbstweiterentwicklung besteht aus einer agenteneigenen Skill-Bibliothek (getrennt von der gemeinsam genutzten Skill-Bibliothek der Plattform gespeichert) plus einer Ebene metakognitiver Reflexion. Die Engine entscheidet anhand einer Reihe von gewichteten Signalen, ob reflektiert wird: Nutzerkorrektur (höchstes Gewicht), Erholung von einem nicht trivialen Fehler, Aufgabenkomplexität, Auslösen oder Überwinden einer bekannten Schwäche, Wirkungslosigkeit eines Skills … Die Reflexion startet erst, wenn die gewichteten Signale einen Schwellenwert überschreiten. Die Reflexion selbst ist eine periodische Hintergrundaufgabe (ungefähr eine Runde alle 12 Stunden, mehrere Stunden Abkühlphase, ein mehrtägiger Ersatzrhythmus), die mit einem günstigen kleinen Modell eine Zusammenfassung der jüngsten Aktivität liest und entscheidet, ob ein Skill erstellt oder angepasst und das „Kompetenzprofil“ des Agenten aktualisiert wird.

Der wichtigste Sicherheitsaspekt: Selbstweiterentwicklung ist nur für Sitzungen mit ausdrücklich zugeordnetem Agenten aktiviert — die standardmäßige Commander-Sitzung entwickelt sich nicht selbst weiter. Die Reflexion hat eine doppelte Tokenbegrenzung (Anzahl + Gesamtmenge), der Fehler eines Agenten blockiert die anderen nicht, und die Kosten pro Ausführung werden extrem niedrig gehalten. Den Agenten intelligenter machen, ohne ihn außer Kontrolle geraten zu lassen.

Technische Philosophie: gerechtfertigte Komplexität — nicht wegvereinfachen

Das Team führte während der Refaktorierung mehrere Architektur-Reviews durch. Eine Schlussfolgerung kehrte immer wieder und verdient eine eigene Hervorhebung: Zwischen „organisatorischem Wildwuchs“ und „gerechtfertigter Komplexität“ unterscheiden und nur Ersteren verändern.

• Die verschiedenen Zusammenführungsstrategien der Synchronisierungs-Engine, die selbst entwickelte Agentenschleife, die mehrschichtige Anbieterhülle und die Grenze der mobilen Fernsteuerung wirken komplex, doch jede Schicht hat ihren Grund (letztliche Konsistenz über mehrere Geräte, tiefe Integration, Rotation mehrerer Schlüssel, eine produktseitig festgelegte Endgerätegrenze). Sie gewaltsam zu „vereinfachen“ würde nur Datenverlust verursachen und die Schichtentrennung verwischen.
• Was tatsächlich verändert werden sollte, sind „Gottmodule“ und lokale Duplizierung: zustandslose reine Funktionen aus dem aufgeblähten Gruppenchat-Bus herauslösen (Prompt-Zusammenstellung, Commander-Tools, CLI-Gesprächsschritt) und das mehrfach duplizierte Muster „Bestätigungsdialog“ in einer gemeinsamen Komponente zusammenführen.

Solche Entscheidungen stützen sich auf feste Regeln im Dokument mit den Projektvorgaben: Grenzen (ein Prozess, IPC als einziger Weg, Laufzeitumgebung nur dynamisch ladbar), Schichten (Abhängigkeitsrichtung jeder Schicht), eine einzige maßgebliche Quelle (Kategorien, Telemetrietaxonomie, Domains) und ein verpflichtendes „Prompt-Audit“ bei jedem Commit mit Prompt-Bezug. Nicht ein raffinierter Entwurf ermöglicht die grundlegende Überarbeitung ohne Zusammenbruch — sondern die durchgängige Einhaltung dieser Invarianten.

Schluss

Zusammengenommen ersetzen die vier Linien das Fundament von Orkas durch eine Agentenbasis, die selbst kontrolliert, anbieterunabhängig, dynamisch orchestriert, nach außen offen und zur Selbstweiterentwicklung fähig ist:

• Eine zweischichtige Engine-/Adapter-Laufzeitumgebung im eigenen Prozess, die alle Stärken eines Programmieragenten — Dateioperationen, lokale Suche, Systemtools, mehrere parallele Arbeitsagenten, langfristiges Aufgabenlösen — nativ auf den Desktop bringt und jede davon produktionsreif macht;
• Eine mehrschichtige Modellschicht, die das Gespräch bei Problemen mit Schlüsseln, Anbietern oder Netzwerken so weit wie möglich am Leben hält;
• Eine Mehragenten-Orchestrierung im Gruppenchat-Stil mit eingebundenem Commander, die „statische Planung“ durch „dynamische Entscheidung“ ersetzt und Übergaben zwischen Agenten erstmals natürlich wirken lässt;
• Ein Ökosystem auf dem Weg vom geschlossenen Katalog zum offenen Host, in dem externe Pakete, globale Skills, benutzerdefiniertes MCP und die Rückwärtsbrücke geöffnet werden — während sich die Start-Engstellen keinen Millimeter verschieben;
• Und Gedächtnis sowie Selbstweiterentwicklung, standardmäßig aus, begrenzt und beobachtbar.

Funktionen lassen sich einzeln ergänzen, aber ein Fundament sollte man nur einmal gründlich überarbeiten müssen. Ist das erledigt, geht alles, was darauf aufbaut, schneller — und genau darauf zielte diese Refaktorierung ab.