Welche verteilte Infrastruktur wird in der Agent-Ära benötigt?

Die Ära der Agent-Anwendungen rückt näher.

Seit dem Ausbruch der aktuellen Technologie der großen Modelle hat der Agent breite Aufmerksamkeit erregt. Nach dem Jahr 2026, vor allem mit dem phänomenalen Erfolg von OpenClaw, ist der Agent endgültig aus seiner Nische herausgetreten und in die breitere Öffentlichkeit gelangt. Wenn die Agenten in der Vergangenheit eher für Demos oder einige relativ maßgeschneiderte Szenarien eingesetzt wurden, können die heutigen Agenten dank der Entwicklung und Reife von Technologien wie Agent Skills nun viele praktische Szenarien bewältigen. Man kann daher annehmen, dass die Ära der Agent-Anwendungen bald hereinkommen könnte.

Der generative Unterschied in Agent-Anwendungen – Die Unsicherheit

Vor der Entstehung von Agent-Anwendungen, ob es sich um die frühesten Einzelanwendungen oder die heute weit verbreiteten cloudnativen Microservice-Anwendungen handelte, wurden die Computerprogramme, die direkt auf Anwendungen zugeschnitten waren, im Wesentlichen von Menschen für bestimmte Anwendungsfälle entwickelt. Die Logik dieser Programme war aufgrund der manuellen Programmierung der Entwickler sehr vorhersehbar. In der Ära der Agenten jedoch wird die konkrete Logik des Agenten nicht mehr von Menschen programmiert, sondern von großen Modellen generiert. Weder die Eigentümer der Geschäftsprozesse, noch die Entwicklungs- und Betriebsteams der Anwendungen, noch die Forscher und Entwickler der Agent-Frameworks und der großen Modelle können die Ausgabe der großen Modelle genau vorhersagen. Daher ist die Logik der Agenten vollkommen unvorhersehbar.

Die meisten bestehenden Infrastrukturen wurden für die cloudnativen Anwendungen und die Anwendungen der früheren Zeit entwickelt, die eine vorhersehbare Logik hatten. Sie können daher die Betriebsanforderungen von Agent-Anwendungen nicht gut erfüllen. Dies könnte ein großes Hindernis für die Einführung von Agent-Anwendungen auf Unternehmensebene darstellen. Gleichzeitig bietet es jedoch auch für die Forscher und Entwickler in der Infrastrukturbranche eine gute Chance für technologische Innovationen in der Agent-Ära.

Die einzigartigen Betriebseigenschaften und Herausforderungen, die von der Unsicherheit der Agenten entstehen

Hohe Dynamik – Die Logik der Agenten ist vollständig dynamisch und nicht vorhersehbar

Traditionelle Anwendungen werden in der Regel von Menschen für bestimmte Geschäftsszenarien entwickelt und sind daher in den meisten Fällen statisch. Wenn die Entwicklungs- und Betriebsteams die Programmlogik gut kennen, können sie im Wesentlichen die Ausführung der Anwendung genau vorhersagen. Die Ausführungslogik dieser Programme ist im Wesentlichen immer die gleiche, unabhängig davon, wann und wo sie ausgeführt werden. Nehmen wir die cloudnativen Microservices als Beispiel: Die Verarbeitungslogik jedes Microservice-Instanz für jede Anfrage ist fast identisch, und die Entwicklungs- und Betriebsteams kennen dies sehr gut. Daher können sie die Microservice-Logik in einem einheitlichen Image packen und dann über K8s mehrere Container-Instanzen mit den gleichen Spezifikationen bereitstellen, um große Unternehmensanwendungen zu unterstützen.

In der Ära der Agenten hat sich die Situation jedoch völlig verändert. Wie in der folgenden Abbildung gezeigt, wird die Ausführungslogik der Agenten von großen Modellen angetrieben. Angesichts der vielfältigen natürlichen Sprachfragen der Benutzer können die großen Modelle jedes Mal völlig unterschiedliche Ausgaben liefern, was wiederum den Agenten veranlasst, verschiedene externe Tools aufzurufen und sogar Code auszuführen, der von den großen Modellen dynamisch auf Basis der aktuellen Anfrage generiert wird. Dieser Prozess wiederholt sich, bis das große Modell glaubt, dass die Frage des Benutzers gelöst ist. Dadurch kann der Verarbeitungsprozess des Agenten für jede Anfrage völlig unterschiedlich sein.

Beispielsweise können einige einfache Anfragen schnell ausgeführt werden und erfordern nicht viele Ressourcen. Andere komplexe Anfragen erfordern möglicherweise mehrere Runden von Interaktionen, Tool-Aufrufen oder die Ausführung von AI-generiertem Code. Einige neueste Agent-Technologien müssen sogar während der Laufzeit neue Sub-Agenten starten, was mehr Zeit und mehr Rechenressourcen erfordert. In diesem Fall können die Betriebsteams von Agent-Anwendungen die konkrete Ausführung einer Anfrage überhaupt nicht vorhersagen. Sie wissen nicht, wie viele Interaktionen mit dem großen Modell erforderlich sind, welche externen Tools aufgerufen werden müssen oder ob AI-generierter Code dynamisch ausgeführt werden muss.

Kurz gesagt, die früheren Anwendungen waren einfach und statisch, während die Agent-Anwendungen komplex und dynamisch sind.

Daraus ergibt sich zunächst ein sehr realistisches Problem: Wie sollten die Ressourcen für Agent-Anwendungen zugewiesen werden? In der Zeit der Container-Microservices konnten die Entwicklungs- und Betriebsteams aufgrund ihrer Kenntnis der Programmlogik und einiger praktischer Erfahrungen die gleichen Ressourcen für jeden Container-Microservice konfigurieren. In der Ära der Agent-Anwendungen ist es jedoch schwierig, zu schätzen, wie viele Ressourcen ein Agent benötigt. Wenn zu wenig Ressourcen zugewiesen werden, kann es zu Ausführungsfehlern oder einer Beeinträchtigung der Servicequalität kommen. Wenn man hingegen ohne Überlegung eine große Ressourcenmenge für jede Instanz zuweist, führt dies offensichtlich zu einer enormen Verschwendung von Ressourcen.

Unsicherheit – Die Tools und der AI-generierte Code sind nicht vertrauenswürdig

Ein weiteres Merkmal der Agenten ist, dass ihre Ausführungslogik möglicherweise unsicher ist. Bei der Ausführung müssen die Agenten möglicherweise Code ausführen, der von großen Modellen generiert wurde, oder bestimmte externe Tools aufrufen. Die Ausführung dieses AI-generierten Codes und dieser Tools kann tatsächlich Sicherheitsrisiken mit sich bringen. Die Isolation von traditionellen Containern ist relativ gering. Wenn schädlicher Code ausgeführt wird, kann es zu Sicherheitslücken wie Container-Escape kommen.

Eine naheliegende Lösung besteht darin, sicherere Container oder virtuelle Maschinen anstelle der traditionellen Container zu verwenden und dennoch über die Container-Schnittstelle mit traditionellen Container-Scheduling-Frameworks wie K8s zu verbinden. Dadurch können die Agenten auf der bestehenden Container-Infrastruktur laufen, und es wird eine höhere Sicherheitsisolation gewährleistet. Tatsächlich verwenden viele derzeitige Sicherheits-Sandboxes für Agenten in der Branche diese Technologien.

Dennoch kann dies möglicherweise noch nicht ausreichen. Beispielsweise in der folgenden Abbildung: Wenn die Logik des Agenten selbst und der AI-generierte Code oder andere risikobehaftete Tool-Aufrufe in einem sicheren Container/virtuellen Maschine ausgeführt werden, kann zwar die Gefahr eines Angriffs auf den Host durch die Sicherheitsisolation des Containers/virtuellen Maschine vermindert werden, aber es besteht immer noch die Möglichkeit, dass wichtige sensible Informationen (z. B. Zugangsdaten für das große Modell) im Container/virtuellen Maschine von risikobehaftetem Code abgerufen und gestohlen werden. Daher können Sicherheitsrisiken in der praktischen Agent-Anwendung nicht vollständig ausgeschlossen werden.

Eine bessere Lösung besteht darin, dass der Agent, sobald er diesen AI-generierten Code oder risikobehaftete Tool-Aufrufe ausführen muss, diese dynamisch in einen anderen sauberen sicheren Container/virtuellen Maschine planen und ausführen lässt, um sie vollständig von der Agent-Instanz zu isolieren und so die Risiken vollständig zu vermeiden.

Dies erfordert jedoch, dass die Infrastruktur nicht nur die statische Bereitstellung von Container-Anwendungen während der Bereitstellungsphase unterstützt, sondern auch die dynamische Planung und Ausführung von neuen sicheren Container/virtuellen Maschine-Instanzen und die Ausführung bestimmter Code-Aufgaben während der Laufzeit der Anwendung unterstützt. Diese aufgabenorientierte dynamische Planungs- und Ausführungsfähigkeit fehlt in der traditionellen K8s-Container-Microservice-Technologie.

Lange Sitzungen – Wie kann die Konsistenz des Sitzungszustands bei langer Laufzeit gewährleistet werden?

Um die Wartung und die horizontale Skalierung von Instanzen zu erleichtern, wurden cloudnative Microservices in der Vergangenheit in der Regel als zustandslose Microservices entwickelt. Die tatsächlichen Geschäftsprozesse vieler Anwendungen sind tatsächlich relativ einfach. Beispielsweise werden viele Geschäftsdaten bereits in der Datenbank gespeichert, und der Verarbeitungsprozess einer Anfrage besteht nur darin, die Datenbank gemäß den Anfrageparametern zu aktualisieren. Die Ausführungslogik selbst ist tatsächlich zustandslos.

Agenten hingegen erfordern von Natur aus einen Zustand. Beispielsweise in einem Szenario mit mehrfachen Dialogen müssen die mehrfachen Eingaben des Benutzers immer von der gleichen Agent-Instanz verarbeitet werden, um die Konsistenz des Kontexts zu gewährleisten und sicherzustellen, dass der Agent weiterhin richtig arbeiten kann.

Zudem entwickeln sich die Agenten immer mehr in Richtung der Verarbeitung komplexerer Aufgaben. Dadurch wird der Ausführungsprozess eines einzelnen Agenten für eine Anfrage immer länger, und es gibt eine große Anzahl von externen Tool-Aufrufen. Wenn in der Produktionsumgebung ein Instanzfehler während des Verarbeitungsprozesses einer Anfrage auftritt, wurden möglicherweise bereits mehrere Agent-Schleifen ausgeführt, und einige externe Tool-Aufrufe haben bereits wirksam geworden. In einem solchen Fehlerfall kann das einfache Neustarten der Instanz und das erneute Ausführen der Anfrage wie in der Microservice-Zeit möglicherweise aufgrund der Unsicherheit der Agent-Logik zu einem völlig anderen Ausführungsweg führen, was wiederum andere Tools aufruft. Dies kann dazu führen, dass der Agent mehrmals inkonsistente externe Tool-Aufrufe ausführt, was schließlich zu einem für das Geschäft nicht akzeptablen Ausführungsergebnis führt und in der Unternehmensproduktion fatale Probleme verursacht.

Nehmen wir als Beispiel die obige Abbildung: Angenommen, ein Ticketbuchungs-Agent hat während des Verarbeitungsprozesses einer Anfrage vor dem Fehler ein Flugticket für eine bestimmte Reise gebucht. Bevor die Anfrage vollständig verarbeitet wurde, trat ein Maschinenfehler auf. Nachdem der Agent von diesem Fehler erholt wurde und die Anfrage erneut verarbeitete, hat er aufgrund der Unsicherheit des Agenten tatsächlich eine neue Bahnkarte für die gleiche Reise gebucht. Ein solcher Fehler würde offensichtlich enorme Geschäftseinbußen verursachen. Wir wissen, dass in der praktischen Unternehmensproduktionsumgebung immer wieder Maschinenfehler auftreten, wenn die Laufzeit lang genug ist.

Zusammenfassend stellen die Eigenschaften wie hohe Dynamik, Unsicherheit und lange Sitzungen, die von der Unsicherheit der Agenten herrühren, eine große Herausforderung für die bestehende Infrastruktur dar, die durch K8s-Container-Microservices repräsentiert wird. Es ist schwierig, auf der Grundlage der bestehenden Infrastruktur eine echte Masseneinführung von Agenten zu erreichen. Welche verteilte Infrastruktur wird also in der Agent-Ära benötigt?

Welche verteilte Infrastruktur wird in der Agent-Ära benötigt?

Traditionelle verteilte Infrastrukturen wie K8s sind eigentlich gut darin, die Ressourcen eines Clusters in Form von Containern zu verwalten und an verschiedene Anwendungen zu verteilen. K8s weiß und interessiert sich nicht dafür, welche Anwendungslogik in den ausgelieferten Containern läuft oder ob die Ressourcen in den Containern ausreichend genutzt werden. Dies sind Fragen, die die Benutzer von K8s zu beachten haben. Auch die Frage, wie viele Ressourcen einem Container zugewiesen werden sollen, wird an die Benutzer weitergegeben. K8s ist nur für die Bereitstellung von Containern mit den vom Benutzer angegebenen Spezifikationen verantwortlich. Dies war in der Ära der cloudnativen Microservices mit vorhersagbarer Ausführung kein großes Problem. In der Ära der unsicheren Agenten stoßen wir jedoch auf die oben genannten Herausforderungen.

Im Wesentlichen benötigt die Agent-Ära angesichts der Eigenschaften und Herausforderungen wie hohe Dynamik, Unsicherheit und lange Sitzungen, die von der Unsicherheit der Agenten herrühren, nicht nur die manuelle Planung und Bereitstellung von vorhersagbarer Anwendungslogik in mehrere identische Container für unabhängigen Betrieb. Stattdessen wird ein flexibleres und leistungsfähigeres verteiltes System benötigt. Dieses System kann den Agenten während seiner langen Laufzeit nach der Planung und Ausführung seinen korrekten Sitzungszustand aufrechterhalten. Gleichzeitig kann es dynamisch neue Teilaufgaben starten, um möglicherweise risikobehafteten Code oder Sub-Agenten auszuführen. Darüber hinaus unterstützt es den Austausch und die Übertragung wichtiger Kontextdaten zwischen ihnen. Agenten und die von ihnen gestarteten Teilaufgaben/Sub-Agenten sollten die Ressourcen des Clusters effizient und dynamisch nutzen, ohne dass der Benutzer dies im Voraus festlegen muss.

Klingt das nicht bekannt? Es ist ähnlich wie beim Ausführen von Programmen auf einem Einzelcomputer-OS. Die Programme können als Prozesse langfristig laufen, interne Speichervariablen zugreifen und ändern. Sie können auch nach Bedarf neue Sub-Prozesse starten und Daten über RPC oder geteilten Speicher austauschen und kooperieren. Alle Prozesse nutzen die Ressourcen des Einzelcomputers effizient, ohne dass der Benutzer dies im Voraus festlegen muss.

Der einzige Unterschied ist, dass wir Agenten jetzt in einem Cluster ausführen müssen, um Unternehmensanwendungen zu unterstützen. Im Wesentlichen benötigen wir also ein verteiltes System in einem Cluster, das ähnliche Fähigkeiten wie ein Einzelcomputer-OS für die flexible und dynamische Planung und die elastische Nutzung von Ressourcen hat und das langfristigen zustandsbehafteten Betrieb unterstützt. Aufgrund der Besonderheiten eines verteilten Systems muss es auch die automatische Wiederherstellung bei Fehlern unterstützen und die Konsistenz des Zustands nach der Wiederherstellung gewährleisten.

Gibt es derzeit in der Branche ein verteiltes System, das die Betriebsanforderungen von Agenten erfüllt?

Verwandte Arbeiten in der Branche

Die Antwort ist ja. Hier werden einige Arbeiten in der Branche vorgestellt, die der Autor als relevant erachtet, um den Lesern einen Überblick zu geben.

openYuanrong

Nach unseren gegenwärtigen Erkenntnissen ist das am besten passende Open-Source-System openYuanrong[1].

Das Kernkonzept von openYuanrong besteht darin, ein verteiltes Kernsystem zu entwickeln, das ähnlich einem Einzelcomputer-OS funktioniert. Mit diesem Kernsystem können alle Arten von verteilten Anwendungslasten einheitlich unterstützt werden. Dies eignet sich sehr gut für die Lösung der typischen Probleme im Agent-Szenario.

Unterstützung der hohen Dynamik von Agenten

Indem Agenten auf openYuanrong ausgeführt