Dev

Dein Multi-Agenten-System ist ein verteiltes System

Die Fehler, die man den Agenten anlastet (viele laufen auf dieselbe falsche Antwort zusammen, eine Meinungsverschiedenheit verhärtet sich zu Sabotage, ein Erfolg wird für Arbeit gemeldet, die nie lief), sind keine Lücken, die ein stärkeres Modell schließt. Es sind die ältesten Fehler im verteilten Rechnen, und sie lösen sich, indem man die Schicht zwischen den Agenten baut, nicht durch mehr Intelligenz in jedem einzelnen.

Das Argument, mehrere Agenten zusammen laufen zu lassen, klingt wie das Argument für redundante Hardware. Ein Agent kann sich irren. Fünf Agenten, die sich gegenseitig prüfen, sollten schwerer zu täuschen sein. Lass die Arbeit parallel laufen, lass sie sich gegenseitig lesen, und die Verlässlichkeit fällt aus der Menge heraus. Das ist eine nachvollziehbare Intuition, und es ist dieselbe Intuition, die jemanden drei Kopien eines Servers vertrauen lässt, die er identisch aus demselben Image aufgesetzt hat. Beide fallen auf dieselbe Weise aus, und aus demselben Grund.

Der Grund ist, dass der schwierige Teil nie die Intelligenz eines einzelnen Knotens war. Anthropics Forscher, die Modelle in Gruppen arbeiten sahen, an Aufgaben wie einer Migration, bei der zwei Agenten widersprüchliche Ziele bekommen, oder einem Rätsel, dessen Lösung so aufgeteilt ist, dass jeder Agent ein Stück hält, berichten von einem Befund, bei dem es sich zu verweilen lohnt: Koordination entsteht nicht aus roher Fähigkeit. Ein Modell, das für sich allein besser schlussfolgert, wird nicht dadurch, dass es besser wird, zu einem Modell, das besser kooperiert. Stärkere Modelle koordinieren manchmal tatsächlich besser, aber die Verbesserung kommt nicht im Paket mit der Fähigkeit; sie ist etwas Eigenes, auf das man hinbauen muss. Das heißt, die Probleme, auf die du triffst, wenn du Agenten zusammenschaltest, warten nicht auf das nächste Modell. Sie sind eine andere Klasse von Problem, und es ist eine Klasse, für die wir schon einen Namen haben. Du baust keinen klügeren Assistenten. Du betreibst ein verteiltes System, und es wird so brechen, wie verteilte Systeme brechen.

Fang mit dem Fehler an, der am wenigsten wie ein Fehler aussieht. Gib fünf Agenten dieselbe Aufgabe, denselben Kontext und dasselbe Modell, und du bekommst nicht fünf unabhängige Versuche. Du bekommst einen Versuch mit fünf Chancen, denselben Fehler zu machen. Wo sie ohnehin übereinstimmen würden, trägt die Übereinstimmung fast keine Information, weil wenig sie überhaupt in die Lage versetzt hat, zu widersprechen. Eine schlechte Schlussfolgerung hört in dem Moment auf, eine isolierte schlechte Schlussfolgerung zu sein, in dem jeder Knoten die Bedingungen teilt, die sie hervorgebracht haben. Ingenieure verteilter Systeme haben das über korrelierte Ausfälle auf die teure Weise gelernt: Redundanz über Maschinen hinweg, die sich ein Netzteil, ein Rack oder einen fehlerhaften Firmware-Build teilen, ist keine Redundanz, sie ist eine Maschine in fünf Körpern. Identische Agenten sind schon von der Konstruktion her korreliert, und eine Mehrheitsabstimmung unter ihnen filtert ihren gemeinsamen Fehler nicht heraus, sie wäscht ihn in Zuversicht um.

Dann gibt es den Fehler, der dich direkt anlügt. Ein Agent, den man über seine eigene Arbeit berichten lässt, kann Erfolg für Arbeit melden, die nie lief, oder eine Aufgabe gegen ein System für erledigt erklären, das sich nie verändert hat. Das ist die älteste Lektion beim Betrieb verteilter Dinge: Du fragst eine Komponente nicht, ob sie gesund ist, und glaubst die Antwort. Gesundheit ist ein Signal, das du von außerhalb des Gemessenen misst, denn die Komponente, die kaputt ist und es nicht weiß, ist genau die, deren Selbstauskunft wertlos ist. Es gibt eine leisere Variante desselben Problems auf der Eingabeseite. Lass eine Gruppe Agenten los, um sich gegenseitig Arbeit zu machen, und nichts taktet sie; sie häufen Anfragen schneller auf eine Warteschlange, als irgendetwas sie abarbeitet, weil keiner von ihnen spüren kann, dass die Warteschlange länger wird. Auch dieser Druck muss von außen kommen, und es gibt einen natürlichen Ort, an dem man ihn ansetzt.

Die lauteren Fehler sind Variationen desselben Themas. Agenten mit unvereinbaren Zielen finden sich nicht verlässlich in einer höflichen Blockade zusammen; die Meinungsverschiedenheit kann eskalieren, manchmal so weit, dass ein Agent einen anderen sabotiert. Agenten, die ihre Notizen teilen, laufen oft auf der Überzeugung zusammen, die sie ohnehin gemeinsam halten, und werten die entscheidende Tatsache ab, die nur einer von ihnen trägt, was die Hidden-Profile-Falle ist, die die Forschung zu Gruppenentscheidungen seit Jahrzehnten beim Menschen dokumentiert. Keines von beiden ist ein Mangel an Schlussfolgerungsvermögen. Es ist das, was passiert, wenn Akteure mit unvollständiger Information und ohne Schlichtung zu einem gemeinsamen Ergebnis kommen wollen, und verteilte Systeme haben vierzig Jahre mit genau dieser Form verbracht. Was sich aus diesen vierzig Jahren zu stehlen lohnt, ist, wie die lösbare Variante gelöst wurde: nicht indem man die Teilnehmer klüger macht, sondern per Protokoll. Paxos und Raft laufen nicht auf klügeren Knoten. Sie schränken ein, wie gewöhnliche Knoten reden dürfen, und die Korrektheit fällt aus der Einschränkung heraus.

Also verschiebt sich die Arbeit. Weg vom Modell und hin zur Schicht zwischen den Agenten, wo Koordination eine Eigenschaft des Systems sein kann statt einer Hoffnung über seine Mitglieder. Diese Schicht muss deterministisch sein, gerade weil die Agenten es nicht sind. Was auch immer man den Agenten nicht zutrauen kann, verlässlich zu tun, erledigt die Maschinerie um sie herum an ihrer Stelle.

Konkret lebt der Koordinationszustand außerhalb der Agenten, in einem Speicher mit atomaren Übergängen. Wenn ein Agent eine Arbeitseinheit übernimmt, beansprucht er sie mit einem Compare-and-Swap: Die Einheit springt nur dann von verfügbar auf übernommen, wenn sie noch verfügbar war, sodass zwei Agenten, die um dieselbe wetteifern, nicht beide gewinnen können. Ein Absturz hinterlässt dann eine lesbare Markierung „übernommen“ statt eines stillen Lochs, und die Einheit kann zur erneuten Ausführung zurückgegeben werden. Genau dieser letzte Teil verbirgt die scharfe Kante. Eine hängengebliebene Einheit zurückzugeben ist At-least-once-Ausführung, und der Agent, der hängen blieb, ist vielleicht nicht tot, nur langsam, und wacht möglicherweise auf und wird fertig, nachdem die Einheit neu vergeben wurde. Also muss die Einheit sicher zweimal ausführbar sein oder ein Token tragen, an dem die Schreibvorgänge eines wiederbelebten Workers abprallen. Vergib sie ohne eines von beidem neu, und du hast die Arbeit nicht gerettet, du hast sie zweimal ausgeführt. Das ist unglamouröse transaktionale Klempnerei, und es ist der Teil, der entscheidet, ob eine Flotte bei einem sterbenden Knoten degradiert oder korrumpiert. Dieselbe Warteschlange ist auch der Ort, an dem der Gegendruck lebt: Agenten ziehen Arbeit in dem Tempo, in dem sie sie erledigen können, statt sie sich gegenseitig zuzuschieben, sodass ein Rückstau als sichtbar zu lange Warteschlange erscheint statt als System, das still ertrinkt. Eine gemeinsame Warteschlange mit diesen Eigenschaften ist das, was den stochastischen Dingen, die darauf laufen, erlaubt, so stochastisch zu bleiben, wie sie sind.

Das verweist auf die Disziplin, auf der der Rest der Lösung ruht. Das Signal, dass eine Arbeitseinheit wirklich gelungen ist, sollte vom Artefakt oder vom System kommen, das sie berührt hat, geprüft von etwas, das der arbeitende Agent nicht kontrolliert, und nie von der eigenen Abschlusszusammenfassung des Agenten. Ein Agent, der seinen eigenen Erfolg schildert, ist der unzuverlässigste Sensor, den du hast. Richte das Instrument auf das Ergebnis, nicht auf den Agenten, der behauptet, es hervorgebracht zu haben.

Auch die menschliche Grenze ist nicht optional. Anthropics Taxonomie schließt den Agenten ein, der anhält und an einen Menschen abgibt, wenn eine Situation mehrdeutig wird; ich lese das als den reifen Fall, und der Fehler ist, es dem Urteil des Modells zu überlassen. Urteilsvermögen, auf das du dich nicht verlassen kannst, ist Urteilsvermögen, das du kodieren musst. Die Regel, die zu kodieren sich lohnt, richtet sich nach der Form der Situation, nicht nach der Zuversicht des Modells: eine Handlung, die sich nicht rückgängig machen lässt, oder eine, die Zugriff braucht, der dem Agenten nie gewährt wurde, oder ein Ansatz, der schon mehr als einmal auf dieselbe Weise gescheitert ist, und ein paar andere Auslöser dieser Art halten den Agenten an und bringen ihn dazu zu fragen, statt einen Weg um die Wand herum zu erfinden. Ein zuversichtlicher Agent, der um ein Hindernis herumroutet, ist nicht findig. Das ist der Vorfall, bevor er einen Namen hat.

Das letzte Stück klingt wie das erste, umgekehrt. Wenn korrelierte Agenten das Problem sind, ist Unterschied die Lösung, aber nur strukturierter Unterschied. Agenten der Abwechslung halber verschieden zu machen bringt für sich genommen wenig. Was Verlässlichkeit bringt, ist Redundanz, deren Einheiten unabhängig voneinander ausfallen und deren Aggregationsregel solide ist, und eine flache Abstimmung unter Gleichrangigen ist eine schlechte Aggregationsregel, wenn die Gleichrangigen billig zu korrelieren sind. Ein Prüfer verdient seinen Platz aus einem von zwei verschiedenen Gründen, und es lohnt sich, sie auseinanderzuhalten. Er kann anders ausfallen als der Worker, auf einem anderen Modell oder mit anderem Kontext, sodass seine Fehler und die des Workers nicht zusammenfallen; das ist Dekorrelation. Oder er kann schlicht stärker sein als der Worker und fangen, was der Worker nicht fangen konnte; das ist Fähigkeitsasymmetrie, und sie wirkt sogar dann, wenn die beiden eng korreliert sind. Der Prüfer, den zu haben sich lohnt, ist ein zweites Modell statt einer zweiten Kopie des ersten, denn eine zweite Kopie teilt die blinden Flecken des ersten und ein anderes Modell teilt weniger davon. Weniger, nicht keine: Verschiedene Frontier-Modelle driften immer noch oft genug zur selben zuversichtlichen falschen Antwort, dass Dekorrelation eine Menge ist, die du kaufst, nie eine Eigenschaft, die du voraussetzt. Vielfalt ist hier eine Ingenieursgröße, keine Tugend. Sie zahlt sich nur aus, wenn die Unterschiede real genug sind, um die Korrelation zu brechen, der du zu entkommen versuchst.

Nichts davon verlangt nach einem besseren Agenten, und das ist der Punkt. Ein stärkeres Modell hebt die Decke dafür, was ein einzelner Knoten leisten kann. Es rührt nicht an die Klempnerei, die entscheidet, ob zehn Knoten sich zu etwas summieren oder sich gegenseitig aufheben. Koordination lebt im Raum zwischen den Agenten, im Zustandsspeicher und im Monitor und in der Eskalationsregel und in der Form davon, wer wen prüft, und dieser Raum ist deiner, ihn zu bauen. Behandle eine Flotte von Agenten als verteiltes System, und du erbst Jahrzehnte hart erarbeiteter Ingenieurskunst für die Fehler, die Ingenieursprobleme sind, und klare Namen für die, die noch nicht gelöst sind. Behandle sie als kluge Menge, und du erbst stattdessen dieselben Fehler, von jedem aufs Neue überrascht.

Diskussion

Hier gibt es keine Kommentarspalte. Diskussionen laufen auf X.

Max Nardit

Max Nardit

@mnardit

Weitere Artikel

Die Token-Steuer auf Tools, die du nie aufrufst

Jede Fähigkeit, die du einem Agenten gibst, verbraucht vorab Kontext für ihr Schema. Der Preis seiner Fähigkeiten richtet sich also nach der Größe deines Katalogs, nicht nach der Größe der Aufgabe. Die Lösung ist nicht, CLIs gegenüber Servern zu wählen, sondern die gesamte Tool-Oberfläche als Budget zu behandeln, das du nur ausgibst, wenn die Arbeit nach einer Definition greift.

Weck mich für die Entscheidung, nicht für den Tastendruck

Genehmigungsabfragen pro Befehl trainieren die Person am Steuer darauf, im Reflex zuzustimmen, und ungefähr eine von drei absichtlich gefährlichen Anfragen wird einfach durchgewunken. Die Unterbrechungen, die sich noch lohnen, sind die seltenen, lesbaren: eine Aktion, die sich nicht rückgängig machen lässt, eine, die aus der Sandbox hinausreicht, oder ein Ansatz, der schon dreimal gescheitert ist.

Die Injection, gegen die kein Review hilft

Code-Injection wird an der Naht gestoppt, an der Daten zu Code werden, indem man eine ganze syntaktische Klasse ablehnt statt jeden Einzelfall abzuwägen. Das trägt überall dort, wo diese Grenze entscheidbar ist, also genau die Eigenschaft, die Prompt-Injection in natürlicher Sprache nie besitzt.