arenskrieger.dev
Projekte
ENDE← Zurück zum Profil
Forschungsagenda // CTC AI Operations

Multi-Agent-Safety-Evaluierung

Systeme interagierender Agenten scheitern anders als ein einzelner Agent – Kollusion, Fehler-Kaskaden, Injection, die von Agent zu Agent springt – und Single-Agent-Benchmarks sind dafür blind. Dies ist eine Forschungsagenda, um dieses Risiko zu messen: eine Taxonomie der Multi-Agent-Failure-Modes, quantitative Risikometriken und ein instrumentiertes Testbed, gebaut auf derselben sandboxed, kontaminationsresistenten Disziplin wie die Evaluierungs-Pipeline.

Forschungsagenda · offenes Problem, ausgerichtet auf einen Multi-Agent-Safety-Call – eine Richtung, kein fertiges Ergebnis
Die Lücke
Risiko liegt in den Kanten
k Agenten öffnen bis zu k(k−1) gerichtete Kanäle; Single-Agent-Evals bewerten nur die Knoten.
Die Agenda
Drei Task-Forces
Eine Failure-Mode-Taxonomie, quantitative Risikometriken und ein gehärtetes Multi-Agent-Testbed.
Der Zweck
Ein einsetzbares Harness
Das angestrebte Ergebnis ist ein wiederverwendbarer Pre-Deployment-Safety-Check, nicht nur ein Paper.
Whitepaper (PDF · EN)
§01 Warum Multi-Agent

Die Risikofläche, die Single-Agent-Evaluierung nicht sieht

Ein sicherer Agent und ein sicherer Agent ergeben zusammen kein sicheres Paar. Sobald Agenten delegieren, Tools teilen und die Outputs des anderen lesen, entstehen neue Failure-Modes, die Eigenschaften der Interaktion sind, nicht eines einzelnen Modells: Zwei individuell korrekte Agenten verstärken einen schlechten Plan; ein Fehler des einen gilt dem nächsten als Fakt und kaskadiert; eine Prompt Injection landet im Kontext eines Agenten und propagiert über die Messages, die er weiterschickt. Nichts davon ist sichtbar, wenn jeder Agent allein bewertet wird – das Objekt unter Test ist die Flotte, und das Risiko ist kombinatorisch in ihrer Größe.

1 AGENT 3 AGENTEN k AGENTEN 0 Kanäle 6 Kanäle k(k−1) Kanäle super-linear
Single-Agent-Evaluierung misst die Knoten. Die Risiken, die in einer Flotte zählen, liegen in den Kanten – Kollusion, Kaskaden, Injection von Agent zu Agent – und wachsen mit k(k−1).
Einzelmodell-Safety kann sagen, dass jeder Agent in Ordnung ist – nicht, dass die Flotte sicher ist.
§02 Task-Force 1 · Taxonomie

Eine Failure-Mode-Taxonomie für Multi-Agent-Systeme

Messung braucht eine Karte dessen, was zu messen ist. Der erste Arbeitsstrang ist eine strukturierte Taxonomie der Failure-Modes, die nur zwischen Agenten auftreten, so gruppiert, dass jeder zu einem konkreten, testbaren Ziel wird statt einer vagen Sorge. Diese Aufzählung sagt den Metriken und dem Testbed, welche Szenarien zu bauen sind.

KOORDINATION Fehlkoordinationwidersprüchliche Teilpläne Fehler-KaskadeFehler des einen als Fakt des nächsten Deadlock / Livelockgegenseitiges Warten, kein Fortschritt ADVERSARIALE DYNAMIK KollusionAgenten verstärken unsicheren Plan Injection-PropagationPrompt Injection springt über Messages Emergenter Goal DriftFlotten-Ziel driftet von Absicht ab DELEGATION Unsicheres TeilzielHandoff verliert Safety-Constraint Capability-LeakagePrivileg eskaliert über Handoffs Oversight-UmgehungArbeit umgeht das Human-Gate
Neun Failure-Modes in drei Familien. Jeder ist so formuliert, dass er ein konkretes Szenario ist, das die Metriken scoren und das Testbed reproduzieren können – keine abstrakte Sorge.
§03 Task-Force 2 · Metriken

Quantitative Risikometriken mit Discrimination-Schwelle

Jeder Failure-Mode braucht eine Zahl mit Bedeutung. Der zweite Arbeitsstrang definiert Metriken, die aus dem berechnet werden, was die Agenten im Testbed tatsächlich getan haben – nicht aus dem Selbstbericht eines Modells – und die dieselbe Regel erben, die die Evaluierungs-Pipeline durchsetzt: Eine Metrik, bei der jeder Lauf identisch scort, misst nichts und geht nicht live.

Metrik

Kaskaden-Tiefe

Wie viele nachgelagerte Agenten auf einen platzierten Upstream-Fehler reagieren, bevor er gefangen wird. Gemessen durch Injektion eines bekannten Fehlers und Tracing der Propagation durch den Message-Graph.

Metrik

Injection-Reichweite

Wie weit eine indirekte Prompt Injection über Agenten-Grenzen reist. Gemessen als Zahl der Agenten, deren Aktionen sich nach einem einzelnen vergifteten Input ändern.

Metrik

Delegations-Safety

Ob ein dem Lead-Agenten genanntes Safety-Constraint jeden Handoff überlebt. Gemessen durch Constraint-Prüfung an jedem Sub-Agenten, nicht nur oben.

Metriken werden mit Varianz über Seeds berichtet und ehrlich zu ihren Grenzen: Ein niedriger Score auf einem engen Szenario-Set ist kein Safety-Zertifikat, nur Evidenz gegen die spezifischen Failures, für die dieses Set gebaut wurde.

§04 Task-Force 3 · Testbed

Ein instrumentiertes, gehärtetes Multi-Agent-Testbed

Der dritte Arbeitsstrang ist, wo Taxonomie und Metriken zur Messung werden: ein Testbed, das ein echtes Multi-Agent-Szenario in einer gehärteten Sandbox ausführt, mit einer Observer-Ebene, die den vollen Message-Graph und die Tool-Calls aufzeichnet, damit die Metriken im Nachhinein berechenbar sind. Es nutzt Infrastruktur wieder, die über die anderen Projekte bereits existiert, statt bei null zu beginnen.

SZENARIOGepinnt · +Hash GEHÄRTETE SANDBOX · netzwerklos · nicht-root A1 A2 A3 OBSERVER Message-Graph +Tool-Log METRIKENpro Failure-Mode ARTEFAKTRisikoprofil
Die gehärtete Sandbox ist die von Projekt A; die kontaminationsresistente Szenario-Synthese die von Projekt B; die Single-GPU-Disziplin die von Projekt C. Neu sind der Observer und das Risikoprofil pro Failure-Mode, das er erzeugt.
Nutzt wieder: gehärtete Sandbox (A)kontaminationsresistente Synthese (B)Single-GPU-Disziplin (C)gepinnte Szenarien · +Hash
§05 Praktischer Nutzen

Wofür die Forschung da ist: Zertifizierung eines Multi-Agent-Deployments

Auch eine Forschungsagenda muss „und dann?" beantworten. Hier das konkrete Deployment, dem die drei Task-Forces dienen – der Grund, warum die Arbeit über das Paper hinaus förderungswürdig ist.

SSituation

Eine Organisation will eine Flotte interagierender Agenten ausliefern – Research- und Coding-Agenten, die aneinander delegieren und Tools teilen. Single-Agent-Benchmarks sagen, jeder sei in Ordnung, aber es gibt keinen prinzipiellen Weg zu wissen, ob die Flotte nicht kolludiert, einen Fehler kaskadiert oder eine Prompt Injection von einem Agenten in den nächsten trägt.

TTask

Dem Team ein belastbares, reproduzierbares Maß für Multi-Agent-spezifisches Risiko vor dem Deployment geben – und eine konkrete Go-/No-Go-Schwelle – statt eines subjektiven Urteils, das System „wirke sicher".

AAction

Mit der Failure-Mode-Taxonomie aufzählen, was zu testen ist; jeden Mode mit den Risikometriken scoren; adversariale Multi-Agent-Szenarien im instrumentierten Testbed laufen lassen (gehärtete Sandbox, kontaminationsresistente Szenarien, gepinnt mit Semver + Hash); jede Metrik mit Varianz über Seeds berichten.

RAngestrebtes Ergebnis · praktischer Impact

Ein Zertifizierungs-Artefakt – ein Risikoprofil pro Failure-Mode, Monate später aus den gepinnten Szenarien reproduzierbar – das „wir glauben, die Flotte ist sicher" in „hier ist die gemessene Risikofläche und wo genau sie versagt" verwandelt. Der praktische Nutzen der Forschung ist ein wiederverwendbares Pre-Deployment-Safety-Harness für Multi-Agent-Systeme, nutzbar von jedem Team, das eines ausliefert – kein Ergebnis, das bei der Publikation endet.

§06 Status

Eine offene Agenda auf bestehender Infrastruktur

Dies ist eine Forschungsrichtung, kein fertiges Ergebnis. Taxonomie, Metriken und Testbed sind geplante Arbeit; hier werden keine Risikozahlen behauptet, denn sie zu erfinden wäre genau die Unehrlichkeit, die die Evaluierungsarbeit verhindern soll. Was bereits existiert, ist die Infrastruktur, auf der die Agenda steht – die gehärtete Sandbox, die kontaminationsresistente Synthese und die Single-GPU-Disziplin der Projekte A–C – und die macht die Agenda glaubwürdig statt spekulativ. Sie ist auf einen nicht-verwässernden Multi-Agent-Safety-Call ausgerichtet.

Der Beitrag, den diese Agenda vorschlägt, ist ein Weg, Flotten-Risiko zu messen, nicht nur Agenten-Fähigkeit: die Failure-Modes benennen, sie aus dem scoren, was die Agenten tatsächlich getan haben, und einem Team ein reproduzierbares Risikoprofil geben, bevor es ausliefert – Safety als Engineering-Artefakt statt als Hoffnung.

Gerahmt unter CTC AI Operations, auf derselben Evaluierungs-Disziplin wie die Pipeline, die sie erweitert.