Methodik: Multi-Agent-Forschung nachvollziehbar prüfen

Wie überprüft AgentenCode Multi-Agent-Aussagen?

Die Multi-Agent-Intelligence-Methodik trennt fünf prüfbare Ebenen: die Originalquelle, den konkreten Claim, den getesteten oder dokumentierten Scope, den Review-Status und die spätere Änderungshistorie. Eine Herstellerbeschreibung kann belegen, dass ein Framework ein Muster dokumentiert. Eine peer-reviewte Studie kann belegen, dass unter bestimmten Versuchsbedingungen ein Ergebnis berichtet wurde. Keine dieser Quellen ist automatisch eine unabhängige AgentenCode-Eigenmessung. Die Datenbasis und Quellenregeln sind in einem maschinenlesbaren Forschungsregister beschrieben.

Evidenzhierarchie und Herkunft

Review-Status ist davon unabhängig: reviewed, pending, conflicting oder insufficient_evidence. Ein Peer-Review-Paper kann zitiert sein und trotzdem für eine ganz andere Behauptung keinen ausreichenden Beleg liefern. „Reviewed“ bezieht sich auf die nachvollziehbar geprüfte Aussage, nicht auf eine Zertifizierung des Systems.

Für prüfbare Ja-/Nein-Eigenschaften gelten die Werte yes, no, unknown und not_applicable. Unknown bedeutet weder No noch Yes. Ein negatives Produktmerkmal wird nur berichtet, wenn die relevante Primärquelle es für den dokumentierten Scope ausdrücklich bestätigt. Bestimmte Sicherheits- und Datenschutzangaben erfordern neben Produktname und Region oft den Tarif, Integrationstyp und Laufzeitkontext.

Forschungsdatenmodell: fünf Kernobjekte

1. Source: stabiler source_id, Original-URL/DOI, Herausgeber, Art, Veröffentlichungs-/Abrufdatum, Lizenzstatus und soweit tatsächlich verfügbar ein Hash der abgerufenen Originalbytes.
2. BenchmarkStudy: study_id, Forschungsfrage, Aufgabe, Datensatzversion, Evaluationsdesign, Vergleichsgruppe und zentrale Einschränkungen.
3. EvaluationResult: result_id, study_id, Modell-/Architekturscope, Metrik plus Einheit, Wert, Unsicherheit, Status und Belegfundstelle. Bei fehlender verlässlicher quantitativer Extraktion gibt es keine erfundenen Score-Zahlen.
4. ArchitecturePattern: definierter Kontrollfluss, Nachrichtenschema, Zustand, typische Fehler und geeignete Testfragen.
5. EvidenceLink: Verknüpfung eines einzelnen Claims zu Quelle, Fundstelle, Prüfung, Scope und gegebenenfalls historischer Änderung.

Im öffentlichen Datensatz sind die ersten verifizierten Forschungsquellen und qualitativen Aussagen abgelegt. Er ist kein Komplettimport fremder Forschungsdateien. Die separate Graphprojektion nutzt nur ausdrücklich dokumentierte Beziehungen – kein rückwärts geschlossenes „Framework X unterstützt Y, also auch Agent Z“.

Prüfprozess von der Quelle zum Claim

1. Primärquelle identifizieren. Für Studien wird bevorzugt das offizielle Publikationsarchiv mit DOI gelesen, für Implementierungsfunktionen die offizielle Dokumentation, für Protokolle die versionierte Spezifikation. Repositorien werden als Code-/Reproduktionsmaterial geführt, nicht als Ersatz für begutachtete Messungen.

2. Genaue Fundstelle erfassen. Titel, Abschnitt, Seiten oder stabiler Fragmentlink gehören zur Aussage. Bei MultiAgentBench beziehen sich die Aussagen zu Graph und kognitiver Planung auf das Studiensetting der ACL-2025-Arbeit. Sie erlauben keinen allgemeinen Schluss auf die sieben bei AgentenCode dokumentierten KI-Ökosysteme.

3. Aussage typisieren. Ist sie eine veröffentlichte Messung, eine technische Dokumentation, eine Interpretation oder ein offener Kandidat? Die Eingabe verification=pending darf nicht als voll geprüfter Fakt auf der Vergleichsseite erscheinen.

4. Scope vollständig halten. Aufgabenfamilie, Anzahl Agenten, Topologie, Modellversion, Datensatz, Toolrechte und verfügbare Details der Umgebung sind zu nennen. Was die Originalquelle nicht belegt, bleibt offen.

5. Konflikte sichtbar dokumentieren. Bei widersprechenden Primärquellen werden beide referenziert. Ältere Ergebnisse werden nicht überschrieben, nur weil neue Modelle oder Spezifikationen erscheinen. Quellenänderung oder Redirect ist zuerst ein Monitoring-Hinweis, kein neues Produktevent.

6. Redaktioneller Review und Freigabe. Vor öffentlichem Resultatvergleich müssen Bedeutung und Einheit der Metrik, Vergleichsgruppe, Stichprobe, Nutzungsrecht und Abhängigkeiten geprüft sein. Ohne diese Gates bleibt die Messreihe aus der automatischen Vergleichsansicht ausgeschlossen.

Vergleichbarkeit und Unsicherheit

Ein Benchmarkwert lässt sich nur dann als direkter Scorevergleich neben einen anderen Wert stellen, wenn Aufgabe, Datensatzversion, Metrikdefinition, Testzeitraum, Modell-/Systemkonfiguration und erlaubtes Budget kompatibel sind. Unterschiedliche Erfolgsmaßstäbe, abweichende Tool-Sets und veränderte Prompts sind mögliche Confounder. Wichtig sind außerdem Run-Anzahl, Varianz, Signifikanzmethodik und Ausschlüsse. Nicht dokumentierte Unsicherheitswerte sind unbekannt, nicht null.

Die MultiAgentBench-Veröffentlichung und die AgentBench-Implementierung untersuchen unterschiedliche Schwerpunkte. Daher zeigt AgentenCode bewusst kein gemeinsames Gesamtranking. Das ist kein Mangel an Visualisierung, sondern eine wissenschaftliche Qualitätsregel.

Lizenzen, Zitate und Weiterverwendung

Die ACL Anthology weist für Materialien seit 2016 grundsätzlich CC BY 4.0 aus; einzelne eingebundene Bestandteile können eigene Rechte haben. Das MARBLE-Repository führt eine MIT-Lizenz für seinen Code. Das erlaubt nicht automatisch, Resultatdateien, fremde Testdaten oder Abbildungen ohne separate Rechteprüfung zu übernehmen. Für externe Quellen gelten daher Attribution, kurze eigene Einordnung und direkte Primärlinks. Vor einem automatischen Import werden Maschinenzugang, API-Limits, Lizenztexte und Revisionsstabilität separat überprüft.

Die Forschungseinträge speichern ein tatsächliches Quellenprüfdatum. Wo ein SHA-256-Hash vollständiger externer Originalbytes nicht vorliegt, steht ausdrücklich null mit Grund; es wird kein selbst erzeugter Ersatz-Fingerprint als angeblicher Original-Hash ausgegeben.

AgentenGraph, AgentenWache und Änderungsverlauf

In Version 1 wird die neue Forschungsgraph-Ebene separat und mit expliziten Belegen ausgeliefert. Beispielsweise kann der dokumentierte Microsoft-Agent-Framework-Scope einem Orchestrierungsmuster zugeordnet werden. Das bedeutet nicht, dass sämtliche Microsoft-Copilots dasselbe Pattern unterstützen. Die bestehende AgentenGraph-Relationstabelle bleibt unverändert.

Für AgentenWache führen wir Quellenkandidaten für DOI, Dokumentation, Spezifikation und relevante Repository-Releases. Sie werden nicht heimlich als laufende Jobs dargestellt. Ein produktiver Monitor muss dieselbe Source Registry, Rate-Limits, Änderungsfilter und Review-Queue nutzen. Die bisherigen täglichen Läufe einschließlich News, Evidence und Changelog werden nicht verändert. Bei späterer Freigabe dürfen Monitoring-Diffs erst nach menschlicher oder kontrollierter inhaltlicher Verifikation als Fakten übernommen werden.

Was für eigene Messungen fehlen würde

Eine echte AgentenCode-Messkampagne erfordert ein registriertes Evaluierungsprotokoll: genaue Aufgabe, öffentlich erlaubte Datennutzung, Baseline, Modell- und Toolrevision, gleiches Budget, Seeds, Ausführungsumgebung, Sicherheitsgrenzen, archivierte Traces, Kosten und statistische Auswertung. Erst nach echten Läufen dürften Ergebnisdatensätze den Status agentencode_measured erhalten. In dieser Version existieren keine solchen Messungen. Die Benchmarks bleiben externe Forschungsreferenzen.

Korrekturen und Aktualität

Wesentliche redaktionelle Korrekturen erfordern eine dokumentierte Änderung des tatsächlich betroffenen Inhalts und seines URL-spezifischen lastmod. Ein bloßer Tageslauf führt nicht zu einer neuen Leistungsbehauptung. Die bestehenden öffentlichen Agenten-History-Daten werden nicht um angebliche Produktänderungen ergänzt, wenn lediglich dieser neue Forschungsbereich erstellt wird. Die allgemeine Methodik und die History erklären den übrigen Plattformbestand.