Wie verwaltet man Hunderte von Agents? Ein neuer Ansatz des Tsinghua-Teams: Session neu gestalten

Wenn die Anzahl der Agenten zunimmt, wird die Verwaltungskonfusion zu einem Problem. OpenRath schlägt vor, Session als Kern zu verwenden und das Agenten - zentrierte Design zu ersetzen, damit mehrere Agenten Zustände teilen können und eine klarere Zusammenarbeit und Kontrolle möglich wird.

Je mehr Agenten es gibt, desto ungeordneter werden die Sessions.

Dies ist eine Wand, gegen die fast alle stoßen, nachdem sie ein Multi - Agenten - System wirklich großskalig betrieben haben.

Ein Agent verwaltet einen eigenen Kontext, ein anderer Agent kopiert eine weitere Historie. Ein Task verzweigt sich in mehrere Inferenzpfade, und am Ende weiß niemand, welcher Zweig die endgültige Antwort geliefert hat. Modellaufrufe, Werkzeugausführungen, Sandbox - Umgebungen und Langzeitgedächtnis verwalten jeweils ihre eigenen Zustände. Die Demo läuft gut, aber wenn das System auf mehrere Dutzend oder sogar Hunderte von Agenten erweitert wird, beginnen die Debugging, Reproduktion und Orchestrierung außer Kontrolle zu geraten.

Kürzlich hat ein Team aus Tsinghua - Universität und Sun Yat - sen - Universität (Rath Team) ihre Lösung als Open Source veröffentlicht, genannt OpenRath: Dies ist ein Multi - Agenten - und Multi - Session - Runtime wie PyTorch.

Seine Aussage ist: Stellen Sie nicht mehr die Agenten in den Mittelpunkt. Die Session sollte wirklich als Erstes behandelt werden.

Offizielle Website: https://www.openrath.com/

Dokumentation: https://docs.openrath.com/

Blog: https://blog.openrath.com/

GitHub: https://github.com/Rath - Team/OpenRath

Open - Source - Lizenz: BSD - 3 - Clause | Aktuelle Version: v1.2.1 (PyPI)

Derzeit ist OpenRath auf PyPI in Version v1.2.1 veröffentlicht. Sie können es mit "pip install openrath" installieren. Es steht unter der BSD - 3 - Clause - Lizenz, und es gibt eine offizielle Website, Dokumentation, Blog und GitHub - Repository.

Dieser Artikel geht von der Frage "Warum" bis zur Frage "Wie benutzt man es". Der Schwerpunkt liegt auf der Aufklärung, wie sich OpenRath von Frameworks wie AutoGen und LangGraph unterscheidet - und warum es sich das Namenswort von PyTorch erlaubt.

Agent - Runtime denkt mit "Chatverlauf"

Das grundlegende Problem: Wenn ein Agent tatsächlich tätig wird, wo sollen die Beweise gespeichert werden?

Die ersten Anwendungen von großen Modellen können als "Eingabe von Prompts, Ausgabe von Antworten" zusammengefasst werden. Das Agenten - System hat diese Grenze verändert.

Ein nützlicher Agent produziert nicht nur Text. Er sucht, plant, ruft Werkzeuge auf, liest Dateien, schreibt Code, fragt APIs ab, führt Tests durch, bedient Browser und verändert manchmal auch externe Zustände. ReAct lässt Inferenz und Aktion in einer Schleife abwechseln, Toolformer lernt dem Modell, wann es Werkzeuge aufrufen soll, und das Model Context Protocol macht Werkzeuge zu einer protokollbasierten Grenze. Diese Entwicklung setzt sich fort.

Sobald ein Agent tatsächlich in die Welt eingreift, entsteht ein Problem auf der Runtime - Ebene: Wo sollen die Beweise für diese Aktionen gespeichert werden?

Wenn ein Werkzeugaufruf eine Datei liest, benötigen wir seine Parameter und Ergebnisse. Wenn er ein Repository ändert, benötigen wir die Diff. Wenn er in einer Sandbox läuft, benötigen wir die Identität der Sandbox. Wenn er fehlschlägt und erneut versucht, benötigen wir den fehlerhaften Pfad. Wenn jemand eine Aktion genehmigt oder ablehnt, benötigen wir das Prüfsignal. Ein Chatverlauf kann diese Dinge höchstens beschreiben, aber nicht wiederherstellen.

Hier ein konkretes Beispiel.

Bei einer Softwareaufgabe liest ein Forschungsagent das Issue, sucht in Notizen. Ein Codieragent ändert das Repository. Die Sandbox führt Tests durch. Ein Prüfagent lehnt den ersten Patch ab, und der Workflow verzweigt sich. Der Gedächtnis - Backend notiert diesen Fehler, um ihn in Zukunft zu vermeiden. Wenn diese Ereignisse in verschiedenen Logs verteilt sind, dann ist die endgültige Antwort fast das unwichtigste Ergebnis. Das wirklich Wertvolle ist die Beweis - Kette, die zeigt, wie die Arbeit Schritt für Schritt fortgeschritten ist.

Dies ist der Ausgangspunkt von OpenRath: Die Session wird als Träger der Beweise betrachtet, nicht nur als Chatverlauf.

Warum Agent Cluster?

Ein einzelner Agent wird zu einem riesigen Prompt, daher muss er aufgeteilt werden.

Früher war ein Agent im Allgemeinen ausreichend: Er empfängt Eingaben, versteht die Aufgabe, ruft Werkzeuge auf und gibt Ergebnisse zurück, wie ein verbessertes Chatbot. Aber reale Aufgaben überschreiten schnell die Grenzen eines einzelnen Agenten.

Eine ordentliche Softwareentwicklung Aufgabe muss oft in Anforderungsverständnis, Datensuche, Architekturentwurf, Codeimplementierung, Testvalidierung und Ergebnisüberprüfung aufgeteilt werden. Die erforderlichen Fähigkeiten in verschiedenen Phasen sind unterschiedlich - einige sind gut in der Planung, einige in der Codierung, einige in der Fehlerfindung. Wenn ein Agent weiterhin alles übernimmt, wird er zu einem riesigen Prompt und einem immer ungeordneteren Kontextfenster.

Daher gibt es Agent Cluster: Planner, Researcher, Coder, Reviewer, Executor und Memory Agent haben jeweils ihre Aufgaben und arbeiten um ein komplexes Ziel herum zusammen.

Mehrere spezialisierte Agenten arbeiten um eine gemeinsame Session herum zusammen: Sie lesen jeweils den aktuellen Zustand, erledigen lokale Aufgaben und schreiben die Ergebnisse zurück, damit der nächste Agent weiterarbeiten kann.

Sobald man es tatsächlich in Betrieb nimmt, treten Probleme auf: Wie teilen sich diese Agenten den Kontext? Woher stammt eine bestimmte Schlussfolgerung? Von welchem Agenten, welchem Zweig, welchem Werkzeugaufruf? Kann man bei einem Fehler eines Agenten auf den entsprechenden Zweig zurücksetzen und neu starten?

Eigentlich liegt die echte Herausforderung von Agent Cluster nie darin, "mehr Agenten zu bauen" - das Schwierige ist, den Zustandsfluss zwischen diesen Agenten zu kontrollieren.

OpenRath stellt eine weitere Frage

Andere versuchen, die Kommunikation zwischen Agenten zu lösen, OpenRath fragt, wer nach der Kommunikation die Zuständigkeit für die Arbeit übernimmt.

Das Wort Multi - Agenten bringt oft eine Gruppenchat in den Sinn: Ein Agent schlägt etwas vor, ein anderer kritisiert, ein anderer führt es aus, und ein Supervisor entscheidet, wann die Arbeit beendet wird. Dieser Ansatz ist nützlich, aber nicht ausreichend.

Es gibt bereits viele Arbeiten auf diesem Gebiet: AutoGen macht die Multi - Agenten - Kommunikation zu einem praktischen Programmier - Modell; CrewAI trennt das Agenten - Team von einem strukturierten Prozess; LangGraph verwendet Graphzustände und Supervisor - Knoten, um Routing und Kontrolle auszudrücken. Sie alle lösen das Problem der Kommunikation zwischen Agenten.

OpenRath stellt dann die Frage: Wer übernimmt nach der Kommunikation der Agenten den Zustand der Arbeit?

Ein produktionsreifes Agent Cluster muss entscheiden: Welchem Agenten soll die aktuelle Session übergeben werden, welchen Kontext soll er sehen, welche Erinnerungen hat er gelesen, in welcher Sandbox soll der nächste Befehl ausgeführt werden, welche Prüfsignale werden benötigt, bevor man fortfahren kann. Dies sind Probleme der Steuerungsebene, die nicht durch das Hinzufügen eines weiteren Rollen in die Gruppenchat gelöst werden können. Die Antwort von OpenRath ist: Lassen Sie die Session zur Routing - Einheit werden, und lassen Sie den Session Graph die Steuerungsebene darstellen - Agenten, Werkzeuge, Workflows, Gedächtnis und Sandbox - Positionen treffen sich auf diesem Graphen.

Kurz gesagt: Ein Agent - Cluster ist keine Gruppenchat, sondern eine Runtime - Steuerungsebene, die auf dem dauerhaften Session - Zustand basiert.

Deshalb wird das Multi - Agenten - System in vier Quadranten aufgeteilt, wenn man von Anzahl der Agenten × Anzahl der Sessions ausgeht:

Ein einzelner Agent und eine einzelne Session entspricht einem ChatGPT - Chat; mehrere Agenten und eine einzelne Session entspricht der Zusammenarbeit von Sub - Agenten; ein einzelner Agent und mehrere Sessions entspricht der Verzweigung wie in OpenClaw; und mehrere Agenten und mehrere Sessions (MAMS) ist die Richtung, auf die OpenRath abzielt.

OpenRath nennt diesen Ansatz MAMS (Multi - Agent Multi - Session). Seine Einschätzung ist klar: Was wirklich geforkt (verzweigt), gemergt (zusammengeführt), wiederverwendet und verfolgt werden muss, ist der gesamte Session - Datenstrom - nicht die von jedem Agenten separat verwaltete Nachrichtenliste.

Mit anderen Worten: Die meisten Frameworks sammeln eine Menge intelligenter Arbeiter, OpenRath baut zuerst die Arbeitsplätze, Arbeitsaufträge und Produktionslinien auf. Mit den Worten der offiziellen Dokumentation: Agenten sind die Arbeiter, die Session ist die Arbeit selbst.

Erstellen Sie einen Agent - Cluster wie in PyTorch

Dies ist kein Versuch, den Namen zu missbrauchen.

OpenRath hat die drei Design - Merkmale, die PyTorch so gut machen, übernommen.

Der klügste Schritt von OpenRath ist, diejenige Abstraktion, die Deep - Learning - Entwickler am besten kennen, auf das Agenten - System zu übertragen.

Warum ist PyTorch so gut? Weil es komplexe Berechnungen in klare Bausteine aufteilt: Tensor ist der fließende Datenstrom, Module/Layer sind die kombinierbaren Einheiten, die diese Daten transformieren, device bestimmt, wo die Berechnung stattfindet, und der gesamte Berechnungsgraph wächst erst während der Ausführung. OpenRath hat für das Agenten - System fast eine eins - zu - eins - Abbildung vorgenommen:

Core - Abbildung: Tensor → Session, Module/Linear → Workflow/Agent, Device → Sandbox / Backend, Parameter → Memory, Function → Tool, Steuerfluss → Selector.

In den nächsten drei Abschnitten werden die drei wichtigsten Paare dieser Abbildung erklärt, von der Terminologie - Übersetzung bis zur Frage warum diese Design - Entscheidungen getroffen wurden.

Diese Abbildung ist kein Gag. Wenn man sie auseinander nimmt, lehrt PyTorch OpenRath tatsächlich drei Dinge - die nächsten drei Abschnitte sind die drei Säulen für das Verständnis von OpenRath.

Säule 1: Agenten sind Transformationsschichten, nicht allmächtige Helfer

Layer halten keine Daten; Agenten halten auch keine Zustände.

In PyTorch ist nn.Linear keine Anwendung, sondern nur eine Transformationsschicht: Sie nimmt einen Tensor auf und gibt einen Tensor aus. Die Fähigkeiten eines Netzwerks stammen aus vielen solcher Schichten, die übereinander gestapelt werden.

OpenRath hat die Agenten als solche Transformationsschichten entworfen. Ein Agent ist eine Transformationsschicht auf der Session. Sein Kern ist ein Pfad forward(session) -> session: Eine Session kommt rein, eine Session geht raus.

Das Wichtige ist, dass es verschiedene Arten von Transformationsschichten gibt. Auch wenn die Form forward(session) -> session dieselbe ist, können völlig unterschiedliche Aufgaben darin implementiert werden:

• Ein Agent ruft Werkzeuge auf, ändert Dateien im Workspace und schreibt die Ausführungsergebnisse in die Session zurück;
• Ein Compressor komprimiert eine lange Session, die über mehrere Runden gelaufen ist, zu einer kurzen Nachricht (Beispiel 8 in der offiziellen Dokumentation zeigt dies);
• Ein Agent ruft vor der Ausführung Erinnerungen ab und speichert sie nach der Ausführung, was einer "Indizierung und Archivierung" dieser Session entspricht;
• Sie können auch einen Agenten schreiben, der nur Zusammenfassungen erstellt, nur prüft oder nur umschreibt.

Außen haben sie alle dieselbe Schnittstelle, sodass sie wie die Schichten eines neuronalen Netzwerks beliebig gestapelt und verschachtelt werden können. Dies ist der Sinn von Workflow (entspricht nn.Module): Subklassen müssen nur eine forward(session) -> session - Methode implementieren, und darin können mehrere Agenten verbunden, Sessions geforkt, der Kontext komprimiert, Werkzeuge aufgerufen und an Unter - Workflows verteilt werden. Da bei jeder Schicht eine Session hinein und eine Session herauskommt, kann der Workflow wie nn.Module ineinander geschachtelt werden, und jede Schicht muss nicht eine eigene Zustandsformulierung erfinden.

Die Verwaltung von Hunderten von Agenten wird somit von der Kombination von Prompts zur Konstruktion von Modulen. Layer halten keine Daten, die Daten sind Tensoren; Agenten halten keine Zustände, die Zustände sind Sessions.

Hier steckt auch ein leicht zu übersehender Vorteil. Da der Agent