Craig McLuckie von Stacklok ist der Ansicht, dass Programmieragenten nicht an das Gerät und den interaktiven Prozess des Entwicklers gebunden bleiben sollten. Er stellt das Open-Source-Projekt Mecatl als Modell für eine verteilte Architektur vor, die die Agentenschleife von Clients, Ausführungsumgebungen, Tools und unterstützenden Diensten trennt.
Der Wert von Programmieragenten beschränkt sich längst nicht mehr auf eine Chat-Oberfläche, die Fragen beantwortet. Ihre praktische Nutzung hängt damit zusammen, dass sie über leistungsfähige Tools, ein gemeinsames Repository und Dateisystem, Unteragenten sowie Skills verfügen, die speichern, was das System aus früheren Aufgaben lernt. Laut Craig McLuckie von Stacklok besteht der nächste Schritt darin, diese Fähigkeiten vom Computer des Entwicklers auf langlebige Dienste und Schnittstellen zu verlagern, die auch von Personen genutzt werden können, die möglicherweise überhaupt kein Terminal öffnen.
Das Problem besteht darin, dass die meisten derzeitigen Frameworks für den Betrieb von Agenten um ein Desktop-Modell herum entwickelt wurden: ein Benutzer, ein Gerät, ein lokales Dateisystem und ein interaktiver Prozess, der gleichzeitig die Benutzeroberfläche, die Agentenschleife, die Isolierung, den Speicher für Zugangsdaten, das Hosting der Tools und die Sitzungsdatenbank umfasst. Dieses Modell eignet sich für einzelne Entwickler, wird jedoch weniger passend, wenn eine Organisation Hunderte Sitzungen betreiben, präzise Richtlinien für Tools durchsetzen, eine Sitzung nach dem Ausfall eines Knotens fortsetzen oder zwischen verschiedenen Geräten wechseln muss.
Die Agentenschleife vom übrigen System trennen
McLuckie schlägt vor, das, was er als „cloudnative Betriebsumgebung“ bezeichnet, von Anfang an als verteilte Anwendung zu entwickeln, statt ein Desktop-Framework lediglich in einen Container zu packen. Ein Container kann zwar den Ort verändern, an dem ein Prozess ausgeführt wird, aber er löst nicht die gegenseitigen Abhängigkeiten zwischen dessen Komponenten. Bei Stacklok wurde zu diesem Zweck das Open-Source-Framework Mecatl bereitgestellt.
In Mecatl übernimmt der Kern die Agentenschleife, einschließlich Inferenz, Verteilung von Tool-Aufrufen, Berechtigungen, Hooks und Ausgabe von Ereignissen. Die übrigen Elemente werden über klar definierte Schnittstellen angebunden:
- Endnutzer-Clients und APIs, darunter eine TUI namens mecatui, gRPC- und HTTP/SSE-Schnittstellen sowie ein SDK in TypeScript.
- Ausführungsumgebungen, Arbeitsbereiche und Befehl-Runner, in denen der Agent seine Aufgaben ausführt.
- Ein Tool-Ökosystem mit integrierten Tools, MCP-Diensten über Streaming-HTTP, Skills und anwendungsspezifischen Integrationen.
- Unterstützende Dienste für die Verwaltung von Modellanbietern, Sitzungsstatus, Ereignisprotokoll, Identität und Orchestrierung.
Was ändert sich in der Praxis?
Diese Trennung macht die Agentenschleife zu einer Komponente, die wie jeder andere Dienst versioniert, bereitgestellt und überwacht werden kann. Sie kann in einem Terminal, als Dienst oder auf Kubernetes ausgeführt werden, ohne die Schleife selbst auszutauschen. Im mecak8s-Leitfaden können Worker während des Betriebs ausgetauscht werden, während dauerhafte Sitzungen bei der Bereitstellung einer neuen Version erhalten bleiben.
Der Sitzungsstatus und das Ereignisprotokoll werden in einem dauerhaften Speicher innerhalb eines Orchestrierungsmodells mit einem einzigen Schreiber gespeichert. Wenn der Worker ausfällt, kann ein Ersatz-Worker ab dem zuletzt gespeicherten Zugriffsgrenzwert fortfahren. Dies entspricht jedoch nicht einer verteilten Transaktion: Der zum Zeitpunkt des Ausfalls laufende Vorgang wird nicht fortgesetzt, und nach der letzten erfolgreichen Speicherung ausgeführte Arbeiten können verloren gehen. Daher beschreibt das Projekt diese Fähigkeit als Persistenz auf Rollenebene und nicht als vollständige Garantie für eine verteilte Transaktion.
Der explizite Katalog ermöglicht außerdem, die zulässigen Tools, Skills und Integrationen mit Berechtigungsgrenzen, Auditing und einer Ausführungsumgebung einzuschränken. Da der Client weder über das Dateisystem noch über Zugangsdaten oder den Sitzungsstatus verfügt, kann dieselbe Schleife ein Terminal, einen entfernten Dienst, eine eingebettete Anwendung oder eine Kubernetes-Bereitstellung bedienen und sogar eine Weboberfläche, eine Slack-Integration und einen kollaborativen Editor mit derselben Sitzung verbinden.
Noch ungeklärte Fragen
Die Quelle betont, dass sich Mecatl noch in einer frühen Phase befindet und die „cloudnative Betriebsumgebung“ eher eine Architekturrichtung als eine vollständige Spezifikation ist. Zu den wichtigsten offenen Fragen gehört die Bestimmung der Identität der Stelle, die ein externes System aufruft: der Benutzer, der Agent, die Sitzung oder ein mehrstufiger Unteragent? Das Projekt schlägt einen eigenen SPIFFE-Vertrauensbereich vor, wobei die vollständige Delegationskette in einem JWT codiert wird, damit empfangende Systeme ihre Entscheidung anhand der Identitätskette treffen können.
Das Projekt untersucht außerdem Tool-Pfade, die über MCP hinausgehen, sodass ein Tool wie ein PDF-Analysator direkt auf dem Dateisystem arbeiten kann, anstatt seine gesamten Eingaben und Ausgaben über ein Kontextfenster des Modells zu leiten. Ebenfalls entsteht die Idee eines „Kontextnachweises“, also den verpackten Kontext wie jedes Artefakt in einer Software-Lieferkette auszugeben, zu signieren, zuzuordnen, zu verteilen und Richtlinien zu unterwerfen.
Redaktionelle Einschätzung: Die Bedeutung des Ansatzes liegt nicht in der Einführung einer neuen Oberfläche, sondern in der Neudefinition des Agenten als verwaltbarer Dienst statt als langlebiger persönlicher Prozess. Die Quelle unterscheidet jedoch klar zwischen dem, was derzeit in Mecatl funktioniert, und dem, was sich noch in der Entwurfsphase befindet. Auch verhindert die derzeitige Persistenz nicht den Verlust laufender Arbeiten, und das Identitätsmodell sowie die direkte Datenübertragung zwischen Tools sind noch nicht abschließend geklärt. Daher erfordert die Einführung dieses Modells eine praktische Bewertung der Bereitstellungssituation, der Berechtigungsgrenzen und der Datengarantien, bevor es als fertige Alternative zu allen lokalen Agenten-Frameworks betrachtet werden kann.