Werkzeuge, Fähigkeiten und Gedächtnis werden zu einem Netz verknüpft. Die Peking-Universität und weitere beteiligte Einrichtungen haben das selbstevolutionäre Programmdiagramm PG vorgeschlagen, das mit zunehmender Nutzung immer intelligenter wird.

Wenn ein Agent bereits Werkzeuge aufrufen, Fähigkeiten nutzen und Erinnerungen speichern kann, stellt sich eine weitergehende Frage: Wie kooperieren diese Fähigkeiten bei Aufgaben und wie sammeln sie wiederverwendbare Erfahrungen aus vergangenen Ausführungen?

Die Möglichkeit, Flugpreise abzufragen, bedeutet nicht, dass man weiß, wann man nach der Abfrage aufhören soll; die Fähigkeit, Notizen zu speichern, bedeutet auch nicht, dass man sie vor der nächsten Entscheidung wieder liest. Der Agent muss sich zudem mit der Reihenfolge, den Bedingungen und der Verknüpfung zwischen Operationen befassen.

Forscher von Google, dem Georgia Institute of Technology und der Peking University haben zu diesem Thema Procedural Graphs (PG, Verfahrensgraphen) vorgeschlagen, die Werkzeugaufrufe, Fähigkeitsschritte, interne Schlussfolgerungen und Aufgabenzustände in bedingten Verknüpfungen organisieren, um dem Agenten eine Grundlage für das weitere Vorgehen zu liefern.

Arbeitspapier: https://arxiv.org/pdf/2609.09153

Aus der Perspektive des Agent-Harness – des Ausführungsunterstützungssystems um das Modell herum – bietet PG eine Möglichkeit, Komponenten wie Tools, Skills und Memory zu einem Netz zu verbinden, beschreibt, unter welchen Bedingungen diese Fähigkeiten genutzt werden, wie sie verknüpft sind und welche Fehler vermieden werden müssen.

Bei der Ausführung von Aufgaben liest der Agent den Teilgraphen in der Nähe des aktuellen Schritts, um Anweisungen für die aktuelle Situation zu generieren; in der Offline-Phase schlägt das System Änderungsvorschläge für den Graphen anhand der Ausführungsspuren vor und entscheidet nach unabhängiger Prüfung, ob diese beibehalten werden.

Erfahrungen werden dadurch zu abrufbaren, prüfbaren und überarbeitbaren Verfahrensbeziehungen, und die Aktualisierung des Graphens erfordert kein erneutes Training der Modellgewichte.

Von unabhängigen Komponenten zu Verfahrensbeziehungen: Was verbindet ein solcher Graph?

Tools, Skills und Memory haben jeweils eigene Funktionen. Werkzeuge liefern konkrete Operationen wie Abfragen, Berechnungen oder Einreichungen, Fähigkeiten kapseln wiederverwendbare Vorgehensweisen, und Erinnerungen behalten Aufgabeninformationen und historische Erfahrungen. Während der Ausführung muss der Agent zudem beurteilen: Wann soll Erinnerung abgerufen werden, welche Fähigkeit welches Werkzeug aufrufen soll, und was soll nach Erhalt des Ergebnisses gespeichert werden.

PG schreibt diese Verknüpfungsbeziehungen explizit als Tripel „Prozess – Beziehung – Prozess“.

Knoten können eine Fähigkeit, eine Werkzeugfunktion, eine interne Schlussfolgerung oder auch ein Aufgabenzustand sein. Die gerichteten Kanten, die zwei Knoten verbinden, beschreiben die Beziehung für den Übergang vom aktuellen Schritt zum nachfolgenden Schritt und enthalten drei Felder: Anwendungsbedingung (condition), Ausführungsanweisung (guidance) und zu vermeidende Probleme (pitfalls).

Beispielsweise kann „Cashflow-Prognose“ mit „Finanzierungsantrag stellen“ verbunden werden. Die Bedingung dieser Kante ist, dass die voraussichtliche Bargeldhaltedauer unter dem Sicherheitspuffer liegt; die Anweisung lautet, den Antrag frühzeitig zu stellen, um Zeit für den Eingang der Gelder einzuplanen; das zu vermeidende Problem besteht darin, wiederholt Anträge zu stellen, während ein früherer Antrag noch nicht abgeschlossen ist.

Dadurch erhält dieselbe Werkzeugaktion einen vollständigeren Nutzungskontext: Warum wird sie jetzt aufgerufen, welche Bedingungen müssen vor dem Aufruf erfüllt sein und unter welchen Umständen soll man warten.

Wissensgraphen organisieren Fakten normalerweise nach dem Muster „Entität – Beziehung – Entität“, um dem System die Antwort auf Fragen wie „Was ist das?“ und „Wo ist es?“ zu ermöglichen. Verfahrensgraphen konzentrieren sich auf eine andere Art von Wissen: Was zu tun ist, in welcher Reihenfolge es zu tun ist und unter welchen Bedingungen es zu tun ist.

Abbildung 1｜Wissensgraphen organisieren Fakten, Verfahrensgraphen verbinden Handlungsschritte, Bedingungen und Ausführungsanweisungen. Quelle: Abbildung 1 des Arbeitspapiers.

Auch die Nutzung von Erinnerungen kann in diese Struktur integriert werden. Das Finanz-Agent im Anhang des Arbeitspapiers liefert ein konkretes Beispiel: Der entwickelte Graph verbindet zunächst Bargeldprüfung, Cashflow-Prognose, Speichern von Notizen (save_note) und Prüfung von Marktdaten; anschließend wird das Abrufen von Notizen (recall_notes) an den Anfang jedes Monats angeschlossen, sodass die im Vormonat gespeicherten Schlüsselinformationen vor der neuen Runde von Entscheidungen abgerufen werden können.

Hier sind die Werkzeuge für Abfragen und Berechnungen zuständig, Notizen speichern monatsübergreifende Informationen, und PG beschreibt wann geschrieben, wann gelesen wird und wie Lese- und Schreiboperationen mit nachfolgenden Entscheidungen verknüpft werden. Werkzeugaufrufe sowie Lese- und Schreibvorgänge von Erinnerungen werden dadurch zu Schritten in demselben Verfahrensnetz.

Abbildung 2｜Strukturelle Evolution des Verfahrensgraphen des Finanz-Agenten. Im Graphen werden schrittweise Schritte wie Bargeldprüfung, Cashflow-Prognose und Speichern von Notizen hinzugefügt, und das Abrufen von Notizen wird am Anfang jedes Monats angeschlossen; in nachfolgenden Runden werden die Handlungszweige weiter angepasst. Grün steht für neu hinzugefügte Knoten oder Verbindungen, rote gestrichelte Linien stehen für Löschungen. Quelle: Abbildung 5 des Arbeitspapiers.

PG selbst trägt auch prozedurale Erinnerung: Die durch Aufgaben validierten Handlungsweisen werden in der Graphenstruktur außerhalb der Modellgewichte gespeichert. Wenn eine Bedingung geändert oder ein Prüfschritt ergänzt werden soll, können Forscher den Graphen direkt bearbeiten und dann die Auswirkungen auf das Ausführungsergebnis testen.

Online-Anweisung: Lokalen Teilgraphen nach der Ausführungsposition abrufen

Nachdem die Verfahrensbeziehungen zu einem Graphen organisiert sind, muss noch entschieden werden, welche Inhalte bei jedem Schritt abgerufen werden.

Der gesamte Graph enthält vollständige Informationen, kann aber auch viele Zweige mit sich bringen, die für die aktuelle Aufgabe irrelevant sind. Wenn man nur einige wenige semantisch ähnliche Anweisungen unabhängig abruft, kann man die Zusammenhänge zwischen den Schritten verpassen. Beispielsweise könnte der Agent, wenn er nur die Anweisung für „Einreichen“ abruft, aber nicht die vorherige „Antwort prüfen“, keine Grundlage haben, um zu beurteilen, wann eingereicht werden darf.

PG organisiert die Online-Anweisung in drei aufeinanderfolgenden Operationen.

Aktuellen Schritt lokalisieren. Das System gleicht die zuletzt ausgeführte Aktion mit den Knoten im Graphen ab, um die aktuelle Position des Agenten zu bestimmen.

Zusammenhängende lokale Struktur extrahieren. Standardmäßig wird der Teilgraph innerhalb von zwei Hops entlang der ausgehenden Kanten abgerufen, also die Schritte, die von der aktuellen Position aus über maximal zwei Verbindungen erreichbar sind. Wenn kein passender Knoten gefunden wird, fällt das System auf den gesamten Graphen zurück.

Anweisungen für die aktuelle Situation generieren. Das Anweisungsmodell kombiniert den lokalen Teilgraphen, die Benutzeraufgabe und die jüngsten Ausführungsaufzeichnungen, um Vorschläge für den nächsten Schritt zu generieren, die in die Prompt des Ausführungsmodells eingefügt werden. Die endgültige Aktion wird weiterhin vom Ausführungsmodell ausgewählt.

In den Experimenten des Arbeitspapiers verwenden das Anweisungsmodell und das Ausführungsmodell dasselbe grundlegende LLM. Bei der Ausführung einer einzelnen Aufgabe bleibt der Graph fest.

Abbildung 3｜Bei der Ausführung wird der aktuelle Knoten lokalisiert, der lokale Teilgraph abgerufen und Anweisungen generiert; in der Offline-Phase wird der Graph anhand der Spuren geändert, und die Änderung wird beibehalten, wenn sie die Strukturprüfung besteht und der Validierungswert nicht sinkt (auch bei gleichbleibendem Wert). Quelle: Abbildung 2 des Arbeitspapiers.

Eine Flugpreisabfrage zeigt, wie diese Art von Anweisung das Endezeitpunkt der Aufgabe beeinflusst. Im BFCL-Werkzeugaufruftest möchte der Benutzer nur den Preis der Economy-Klasse erfahren. Die Baseline ohne Graph findet ein Angebot von 220 US-Dollar, führt aber weiterhin Identitätsauthentifizierung durch, bearbeitet die Bankkarte und versucht, die Buchung abzuschließen; nach dem Fehler ändert sie die Budgetbegrenzung und schließt die Buchung erneut ab.

Bei gleicher Nutzung von Gemini 3.5 Flash beendet der unter PG-Anweisung stehende Agent die aktuelle Runde nach der Angabe von 220 US-Dollar und wartet auf neue Anweisungen des Benutzers. Dieses Beispiel verdeutlicht eine Funktion des Verfahrenswissens: Es hilft dem Agenten zu beurteilen, ob die durchgeführten Operationen die aktuelle Anforderung bereits erfüllt haben.

Offline-Evolution: Verfahrensgraphen aus Ausführungsrückmeldungen überarbeiten

Die Wirkung des Verfahrensgraphen hängt davon ab, was darin gespeichert ist. Manuell geschriebene Abläufe erscheinen vernünftig, können aber bei der tatsächlichen Ausführung Probleme verursachen.

Das Arbeitspapier führt Experimente zur Graphkonstruktion auf MultiChallenge durch. Dieses Experiment verwendet Gemini 3.5 Flash und umfasst 56 Testproben: Die Erfolgsrate der Baseline ohne Graph beträgt 87,50 %, sinkt auf 58,93 % nach Hinzufügung des von Experten manuell erstellten Graphen und liegt bei 53,57 % nach einmaliger statischer Aktualisierung durch das Modell.

Diese Ergebnisse zeigen, dass Änderungen an Verfahrensbeziehungen durch Aufgabenprüfungen validiert werden müssen. Dafür hat PG einen Offline-Zyklus entworfen: Aufgaben ausführen, Spuren analysieren, Änderungen vorschlagen, Kandidatengraphen validieren.

Das System führt zuerst den aktuell beibehaltenen Graphen an einer Reihe von Trainingsaufgaben aus, dann vergleicht das Überarbeitungsmodell die Spuren mit hohen und niedrigen Werten, um wiederholt auftretende Fehler oder wiederverwendbare Schritte zu finden. Änderungen können fehlende Knoten und Verbindungen hinzufügen, pfade löschen, die leicht zu Fehlern führen, oder auch die Bedingungen, Anweisungen und Hinweise auf den Kanten neu schreiben.

Kandidatengraphen durchlaufen zuerst eine Strukturprüfung und werden dann auf einem unabhängigen Validierungsset ausgeführt. Nur wenn der gemessene Validierungswert nicht niedriger als der des aktuell beibehaltenen Graphen ist, übernimmt das System diese Änderung; auch bei gleichbleibendem Wert kann die Änderung beibehalten werden. Abgelehnte Vorschläge und ihre Ergebnisse werden aufgezeichnet, um als Referenz für nachfolgende Überarbeitungen zu dienen.

Diese Änderungen finden zwischen Offline-Batches statt. Daher liest der während der Ausführung befindliche Agent die aktuelle Version des Verfahrenswissens, und neue Erfahrungen gelangen nach der Validierung in nachfolgende Versionen.

Im oben genannten MultiChallenge-Konstruktionsexperiment erreicht die Erfolgsrate nach iterativer Evolution ausgehend von dem 58,93 %-Experten-Graphen 92,86 %, was 33,93 Prozentpunkte über dem Experten-Initialwert liegt und auch die 87,50 %-Baseline ohne Graph übertrifft.

Eine Validierungsprobe im Anhang des Arbeitspapiers verlangt von dem Agenten, einen Witz zu erzählen und gleichzeitig die vorherige Einschränkung „nur Passiv zu verwenden“ beizubehalten. Aber der unter Anweisung des zweiten Kandidatengraphen stehende Agent weicht von der Aufgabe ab und beantwortet stattdessen die Bewertungsfrage der Umgebung – ob das Modell durchgehend Passiv verwendet hat, die Antwort beginnt mit „Es wurde nicht durchgehend Passiv verwendet“.

Der dritte Kandidatengraph löscht die direkte Verbindungen zum Beenden und schreibt die Anweisung „Einschränkungen extrahieren → Beenden“ um, mit der Anforderung, die Bewertungsfrage nicht direkt zu beantworten. Dieses Mal gibt der Agent nach dem Schritt zum Extrahieren der Einschränkungen den Witz aus, und das Erfolgsmarkierung dieser Validierungsprobe ändert sich von 0 zu 1.

Dieses Beispiel macht „Aktualisierung von Erfahrungen“ zu einem konkreten Beobachtungsobjekt: Welche Verbindung wurde gelöscht, welche Anweisung wurde umgeschrieben und welche Änderungen treten bei der nachfolgenden Ausführung auf.

Die Forscher haben auch versucht, die Evolution ausgehend von der minimalen Graphenstruktur durchzuführen. Im HotpotQA-Konstruktionsexperiment erreicht das auf diese Weise erhaltene PG einen Antwort-F1-Wert von 78,79, was über dem 71,21 der Baseline ohne Graph liegt und zeigt, dass die Verfahrensstruktur auch schrittweise aus Ausführungsrückmeldungen aufgebaut werden kann.

Abbildung 4｜Evolutionstrajektorien ausgehend von Experten-Graphen oder minimalen Graphenstrukturen. Beide Experimentreihen verwenden Gemini 3.5 Flash