💬 NLP

Bayesian-Agent: Posterior-Guided Skill Evolution for LLM Agent Harnesses

Das Papier stellt Bayesian-Agent vor, ein Framework, das wiederverwendbare Fähigkeiten und SOPs als probabilistische Hypothesen behandelt, um deren Evolution durch posterior-gesteuerte Harness-Optimierung zu leiten, was die Leistung von LLM-Agenten auf Benchmarks wie SOP-Bench und Lifelong AgentBench signifikant verbessert, ohne die Modellgewichte zu modifizieren.

Ursprüngliche Autoren: Xiaojun Wu, Cehao Yang, Honghao Liu, Xueyuan Lin, Wenjie Zhang, Zhichao Shi, Xuhui Jiang, Chengjin Xu, Jia Li, Jian Guo

Veröffentlicht 2026-06-09

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Xiaojun Wu, Cehao Yang, Honghao Liu, Xueyuan Lin, Wenjie Zhang, Zhichao Shi, Xuhui Jiang, Chengjin Xu, Jia Li, Jian Guo

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben einen sehr intelligenten, aber etwas eigensinnigen Roboter-Assistenten. Dieser Assistent ist großartig im Denken, aber er lernt nicht auf die gleiche Weise aus seinen Fehlern wie ein Mensch. Wenn Sie ihn bitten, einen Kuchen zu backen, und er den ersten verbrennt, wird er nicht automatisch wissen, warum er verbrannt ist, es sei denn, Sie sagen es ihm explizit.

Normalerweise, wenn wir versuchen, diese Roboter zu reparieren, geben wir ihnen einfach eine längere Liste von Anweisungen oder hoffen, dass sie es durch das Betrachten ihrer vergangenen Erfolge und Misserfolge „herausfinden“ (z. B. „Ich war 3 Mal erfolgreich, 2 Mal gescheitert, also bin ich zu 60 % gut“). Das Problem ist, dass diese Punktzahl oft irreführend ist. Ein Fehlschlag könnte ein Zufall gewesen sein, oder ein Erfolg könnte Glück gewesen sein.

Bayesian-Agent ist ein neues Framework, das verändert, wie wir diese Roboter-Assistenten steuern. Anstatt nur Siege und Niederlagen zu zählen, behandelt es jede Anweisung oder jeden „Skill“ (Fähigkeit), den der Roboter nutzt, als eine wissenschaftliche Hypothese, die getestet und mit echten Beweisen aktualisiert werden muss.

So funktioniert es, unter Verwendung einfacher Analogien:

1. Die „Skill-Bibliothek“ als Hypothesenbuch

Stellen Sie sich vor, der Roboter hat eine Bibliothek von „Skills“ (wie „eine Datei öffnen“ oder „einen Kontostand prüfen“).

Der alte Weg: Der Roboter fügt der Bibliothek einfach neue Tipps hinzu, wann immer er einen Fehler macht, in der Hoffnung, dass es beim nächsten Mal besser läuft. Es ist, als würde man basierend auf einem Bauchgefühl eine neue Regel in ein Notizbuch schreiben.
Der Bayesian-Agent-Weg: Jeder Skill in der Bibliothek wird wie eine Hypothese behandelt. Das System fragt: „Gegeben die spezifische Situation, in der wir uns befinden, wie wahrscheinlich ist es, dass dieser Skill funktioniert?“ Es zählt nicht einfach nur „1 Erfolg, 1 Misserfolg“. Es erstellt ein Glaubensprofil (Belief Profile) für jeden Skill und verfolgt genau, wann und warum er funktioniert oder scheitert.

2. Die „Detektiv“-Logik (Das Posterior)

Das System verwendet eine Methode namens Bayessche Inferenz. Betrachten Sie dies als einen Detektiv, der seine Theorie aktualisiert, sobald neue Hinweise eintreffen.

Die Hinweise: Jedes Mal, wenn der Roboter eine Aufgabe versucht, zeichnet das System die „verifizierte Trajektorie“ auf. Das bedeutet, es hört nicht nur auf den Selbstbericht des Roboters („Ich glaube, ich habe es richtig gemacht!“); es prüft das tatsächliche Ergebnis (z. B. „Wurde die Datei tatsächlich geöffnet?“).
Das Update: Wenn ein Skill zweimal hintereinander unter denselben Bedingungen fehlschlägt, aktualisiert der Detektiv den „Glauben“, dass dieser Skill für diese spezifische Situation defekt ist. Wenn er dreimal funktioniert, wächst der Glaube an seine Zuverlässigkeit.

3. Die fünf „Aktionen“ (Der Werkzeugkasten des Mechanikers)

Basierend auf diesen aktualisierten Überzeugungen nutzt das System nicht einfach wahllos Korrekturen. Es verfügt über einen spezifischen Satz von Werkzeugen, um die Skill-Bibliothek zu verwalten, ähnlich wie ein Mechaniker, der die Teile eines Autos verwaltet:

Explore (Erforschen): Wenn der Roboter einen Skill noch nie zuvor ausprobiert hat, sagt das System: „Lass es uns versuchen und sehen, was passiert.“
Patch (Flicken): Wenn der Roboter auf die gleiche Weise scheitert (z. B. vergisst er immer wieder, die Datei zu speichern), fügt das System eine spezifische „Leitplanke“ oder Erinnerung zu den Anweisungen hinzu, um diesen spezifischen Fehler zu verhindern.
Split (Aufteilen): Wenn ein Skill zu breit gefasst ist (z. B. „Alle Banktransaktionen abwickeln“) und in einigen Fällen scheitert, in anderen aber funktioniert, teilt das System ihn in zwei kleinere, spezifischere Skills auf.
Compress (Komprimieren): Wenn ein Skill sehr zuverlässig ist und perfekt funktioniert, verkürzt das System die Anweisungen, um Platz zu sparen und den Roboter schneller zu machen.
Retire (Ausmustern): Wenn ein Skill zu oft fehlschlägt und die Beweise zeigen, dass er unzuverlässig ist, wirft das System ihn in den Müll, damit der Roboter nicht mehr versucht, ihn zu verwenden.

4. Die Ergebnisse: Den „verbrannten Kuchen“ reparieren

Die Forscher haben dieses System bei drei verschiedenen Arten von Aufgaben getestet:

SOP-Bench: Das Befolgen komplexer, schrittweiser Geschäftsprozesse.
Lifelong AgentBench: Das Ausführen einer langen Serie von Aufgaben, bei denen man sich an das erinnern muss, was früher geschah.
RealFin-Bench: Das Lösen von Finanzdenkaufgaben, bei denen möglicherweise Informationen fehlen.

Was passierte?

Der „Repair“-Modus (Reparatur-Modus): Sie nahmen einen Roboter, der bereits einige Aufgaben fehlerhaft ausgeführt hatte, speisten die Beweise in den Bayesian-Agent ein und ließen ihn die Anweisungen „patchen“.
- Beim Test für Geschäftsprozesse korrigierte er die Fehler und erreichte 95 % Erfolg.
- Beim Test für lange Serien korrigierte er die Fehler und erreichte 100 % Erfolg.
- Beim Finanztest verbesserte er den Erfolg von 45 % auf 65 %.
Der „From Scratch“-Modus (Von Grund auf): Sie ließen den Roboter unter Verwendung dieses Systems komplett von Grund auf lernen. Er war gut, aber manchmal war das „Lernen während des Handelns“ etwas chaotisch, was zeigt, dass es manchmal besser ist, zuerst eine solide Basis zu haben und dann die „Patches“ anzuwenden.

5. Warum das wichtig ist

Die Arbeit argumentiert, dass der Bau besserer KI-Agenten nicht nur daraus besteht, die KI intelligenter zu machen (ihr Gehirn/ihre Gewichte zu verändern). Es geht darum, die Umgebung zu optimieren, in der sie arbeitet.

Man kann es sich so vorstellen: Wenn Sie einen großartigen Fahrer (das KI-Modell) haben, aber die Straßenschilder verwirrend sind, die Karte falsch ist oder das Auto ein loses Lenkrad hat (das „Harness“/die Steuerung), wird der Fahrer abstürzen. Bayesian-Agent versucht nicht, das Gehirn des Fahrers neu zu trainieren; es repariert die Straßenschilder, aktualisiert die Karte und zieht die Lenkung fest – basierend auf verifizierten Beweisen darüber, wo das Auto falsch abgebogen ist.

Kurz gesagt: Bayesian-Agent verwandelt den chaotischen Prozess von „Versuch und Hoffnung“ in einen strukturierten, prüfbaren Prozess aus „Testen, Glauben und Reparieren“ und stellt sicher, dass sich die Anweisungen des Roboters auf Fakten statt auf Vermutungen entwickeln.

Technisches Resümee: Bayesian-Agent: Posterior-geleitete Skill-Evolution für LLM-Agenten

1. Problemstellung

Large Language Model (LLM) Agenten verlassen sich zunehmend auf externe Inferenz-Umgebungen – bestehend aus Prompts, Werkzeugen, Gedächtnis, Standard Operating Procedures (S SOPs) und Harness-Feedback – anstatt allein auf Modellgewichte, um Aufgaben zu lösen. Während diese wiederverwendbaren Assets die Ausführung verbessern können, ohne ein Retraining zu erfordern, beruhen aktuelle Methoden zur Aktualisierung dieser Assets oft auf heuristischer Reflexion oder einfachen Häufigkeitszählungen von Erfolg und Misserfolg.

Das Paper identifiziert zwei primäre Einschränkungen bestehender Ansätze:

Unkalibrierte Updates: Die Behandlung von spärlichen Agenten-Trajektorien als unabhängige, identisch verteilte (i.i.d.) Beobachtungen führt zu verrauschten Edits. Ein Skill kann in einem Kontext zuverlässig, in einem anderen jedoch schädlich sein; einfaches Zählen erfasst diese Nuance nicht.
Externalisierte Fehler: Wenn Fähigkeiten in Skills und SOPs externalisiert werden, werden auch Fehler externalisiert. Wenn ein Agent seine Assets ausschließlich basierend auf einer natürlichsprachlichen Selbstkritik aktualisiert, korrigiert er möglicherweise einen aktuellen Fehler, führt aber gleichzeitig Edits ein, die die Leistung bei zukünftigen Aufgaben verschlechtern. Umgekehrt, wenn der Harness die Skills nie revidiert, bleiben wiederholte Fehler außerhalb des Lernkreislaufs des Modells.

Die zentrale Herausforderung besteht darin, wie die externe Entscheidungsinstanz (der „Harness“) zu pflegen ist, sodass wiederverwendbare Skills und SOPs auf Basis verifizierter Evidenz statt durch unkalibriertes Trial-and-Error evolvieren.

2. Methodik: Bayesian-Agent

Die Autoren führen den Bayesian-Agent ein, ein Framework, das wiederverwendbare Skills und SOPs als evidenztragende Hypothesen behandelt. Anstatt das LLM zu fragen, ob ein Skill „gut“ ist, stellt das Framework eine bayessche Frage: Gegeben ein eingefrorenes Modell und eine spezifische Inferenz-Umgebung, was sollten wir über diesen Skill glauben, nachdem wir Vorannahmen mit verifizierter Evidenz kombiniert haben?

2.1 Problemformulierung

Das Framework fixiert die Modellgewichte ( $M_\theta$ ) und betrachtet die Evolution des Harness als Optimierung über die Inferenzbedingungen ( $C_t$ ). Die Zuverlässigkeit eines Skills $h_k$ wird definiert als die Erfolgswahrscheinlichkeit gegeben das Modell, den Kontext und beobachtete Merkmale:
$p_{k,t} = P(y_t = 1 \mid M_\theta, C_t, h_k, z_t)$
wobei $z_t$ ein diskreter Merkmalsvektor ist, der aus einer verifizierten Trajektorie extrahiert wurde (z. B. Token-Anzahl, Turn-Anzahl, Fehlermodi).

2.2 Trajektorien-Evidenz

Der Bayesian-Agent aktualisiert Überzeugungen (Beliefs) nur aus verifizierten Trajektorien ( $e_t$ ), die von einem Execution-Harness generiert wurden. Diese Trajektorien beinhalten:

Aufgabenkontext und Ergebnis ( $y_t \in \{0, 1\}$ ), bestimmt durch einen externen Verifizierer oder Benchmark-Grader, nicht durch die Selbsteinschätzung des Modells.
Laufzeit-Signale (Token-Kosten, Latenz, Turn-Anzahl), die in feste Buckets diskretisiert wurden, um mit spärlichen Online-Datensätzen umzugehen.
Fehlermodi, die aus dem Verifizierer abgeleitet wurden.

2.3 Bayessches Evidenzmodell

Das System unterhält ein merkmal-konditioniertes kategorisches bayessches Evidenzmodell für jeden Skill:

Priors: Verwendet Laplace-Glättung, um konservative Schätzungen bereitzustellen, wenn Beobachtungen spärlich sind.
Likelihood: Berechnet die Erfolgswahrscheinlichkeit/Misserfolgswahrscheinlichkeit unter Berücksichtigung spezifischer Merkmalswerte (z. B. „Fehlermodus X tritt in Kontext Y auf“).
Posterior: Berechnet eine Erfolgswahrscheinlichkeit ( $s_{k,t}$ ), die für das Ranking und die Entscheidungsfindung genutzt wird.
Zusammenfassung: Unterhält eine konjugierte Beta-Bernoulli-Zusammenfassung ( $\alpha, \beta$ ) für Audits und Checks der Dominanz von Fehlern.

2.4 Posterior-geleitete Skill-Aktionen

Der Posterior-Zustand steuert eine konservative Rewrite-Policy, die Belief-Zustände auf fünf inspizierbare Aktionen abbildet:

Explore (Explorieren): Wird ausgelöst, wenn keine Beobachtungen existieren oder der Posterior unsicher ist.
Patch (Reparieren): Wird ausgelöst, wenn derselbe Fehlermodus mindestens zweimal auftritt (umwandelt wiederholte Fehler in Guardrails um).
Split (Aufteilen): Wird ausgelöst, wenn ein breiter Skill heterogene Fälle abdeckt (3+ Kontexte, 4+ Beobachtungen).
Compress (Komprimieren): Wird ausgelöst, wenn ein Skill zuverlässig ist (Erfolg $\ge$ 0,72), um den Kontext kompakt zu halten.
Retire (Einstellen): Wird ausgelöst, wenn die Fehler-Evidenz dominiert (niedrige Erfolgswahrscheinlichkeit, hohes $\beta$ ).

Entscheidend ist, dass das Framework Posterior-Audit-Informationen (gespeichert für das Debugging) von den dem Modell gerichteten Instruktionen trennt. Das LLM erhält ausführbare Guardrails und Fehlermodus-Patches, nicht rohe Wahrscheinlichkeitszahlen.

2.5 Ausführungsmodi

Full Mode: Das Registry entwickelt sich online von Grund auf während eines Benchmark-Durchlaufs.
Incremental Mode: Das System nimmt verifizierte Spuren aus einem abgeschlossenen Baseline-Durchlauf auf, aktualisiert das Registry und führt nur die fehlgeschlagenen Aufgaben mit Posterior-geleiteten Patches erneut aus.

3. Kernbeiträge

Formulierung von Skills als Hypothesen: Verschiebt die Selbst-Evolution von empirischer Prompt-Akkumulation hin zu verifizierter, posterior-geleiteter Optimierung unter Unsicherheit.
Vereinheitlichtes Framework: Bietet eine einheitliche bayessche Sicht auf Prompt-, Kontext- und Harness-Engineering, instanziiert durch ein effizientes kategorisches Evidenzmodell und eine posterior-geleitete Rewrite-Policy.
Native und Cross-Harness-Unterstütung: Führt ein minimales natives Backend ein und definiert gleichzeitig eine Adapter-Grenze, die es externen Harnesses (GenericAgent, mini-swe-agent, Claude Code) ermöglicht, denselben Trajektorien-Evidenz-Loop zu nutzen.
Empirische Validierung: Führt umfangreiche Studien auf SOP-Bench, Lifelong AgentBench und RealFin-Bench unter Verwendung von DeepSeek-Modellen durch und vergleicht dabei Baseline, Full Bayesian sowie Incremental Repair Varianten.

4. Experimentelle Ergebnisse

Das Paper evaluiert den Bayesian-Agent über drei Benchmarks und mehrere Backends (Native, GenericAgent, mini-swe-agent, Claude Code) unter Verwendung von DeepSeek-v4-flash und DeepSeek-v4-pro.

4.1 Leistungssteigerungen

Incremental Repair: Der inkrementelle Modus (Reparatur nur fehlgeschlagener Aufgaben) zeigte signifikante Verbesserungen:
- SOP-Bench: Verbesserung von 80 % (GA) auf 95 %.
- Lifelong AgentBench: Verbesserung von 90 % (GA) auf 100 %.
- RealFin-Bench: Verbesserung von 45 % (GA) auf 65 %.
Token-Effizienz: Der inkrementelle Ansatz war hochgradig token-effizient und verbrauchte nur 153k Tokens, um die SOP-Bench-Fehler zu reparieren, im Vergleich zum vollen Baseline-Durchlauf.
Backend-Agnostik: Das Framework verbesserte die Leistung erfolgreich über verschiedene Backends hinweg (Native, GenericAgent, mini-swe-agent, Claude Code), was bestätigt, dass der Nutzen aus dem Evidenz-Loop und nicht aus einem spezifischen Runtime-System resultiert.

4.2 Beobachtete Limitationen

Instabilität im Full Mode: Im Lifelong AgentBench-Setting mit DeepSeek-v4-flash unterperformte der Full Bayesian Modus (85 %) die Baseline GA (90 %). Dies deutet darauf hin, dass die Online-Skill-Evolution negative Ordnungseffekte oder Kosten verursachen kann, wenn die Evidenz noch spärlich ist.
Sättigung: In Settings, in denen das Baseline-Modell bereits eine Genauigkeit von 100 % erreichte (z. B. SOP-Bench mit DeepSeek-v4-pro), hatte die Bayesian-Schicht keine Fehler zu reparieren, wodurch der inkrementelle Modus inaktiv blieb.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass die Evolution von Agent-Skills am besten als posterior-geleitete Harness-Optimierung und nicht als unkalibrierte Prompt-Akkumulation betrachtet werden sollte.

Auditierbarkeit: Durch die Behandlung von Skills als Hypothesen mit expliziten Posterior-Zuständen macht das Framework den Evolutionsprozess inspizierbar. Nutzer können sehen, warum ein Skill gepatcht, aufgeteilt oder eingestellt wurde, basierend auf spezifischen Fehlermodi.
Unsicherheit-Kalibrierung: Der Ansatz geht explizit mit der Spärlichkeit und Kontextabhängigkeit von Agenten-Trajektorien um und vermeidet die Falle, spärliche Daten als zuverlässige Häufigkeitszählungen zu behandeln.
Praktische Reparatur: Das Setting der inkrementellen Reparatur zeigt, dass ein Harness zusätzliche Inferenzressourcen gezielt auf fehlgeschlagene Fälle verwenden kann, um beobachtete Fehlermodi in wiederverwendbaren Kontext umzuwandeln, was die Endgenauigkeit signifikant steigert, ohne den gesamten Benchmark neu durchlaufen zu müssen.

Die Autoren kommen zu dem Schluss, dass der Ansatz zwar kein Allheilmittel für einmalige Aufgaben oder nicht-stationäre Umgebungen ist, aber einen robusten, evidenz-kalibrierten Mechanismus zur Verbesserung wiederverwendbarer Agent-Skills in Umgebungen mit Verifizierern und wiederkehrenden Fehlermodi bietet.