ERC-8004 ist ein Entwurf eines Ethereum-Standards für Agenten-Identität, Reputation und Validierungsdatensätze. Er hilft Käufern dabei, einen Agenten mit Belegen über seine Arbeit zu verknüpfen. Eine Registrierung allein begründet keine Kompetenz und autorisiert keine Zahlung.
ERC-8004 schlägt gemeinsame Onchain-Datensätze für Agenten-Identität, Feedback und Validierung vor. Diese Datensätze können Software dabei helfen, einen Agenten zu entdecken und Belege über seine Arbeit zu prüfen. Eine Registrierung zertifiziert keine Kompetenz, und ein hoher Reputationswert muss dennoch interpretiert werden.
Die Ethereum-Spezifikation wurde bei der Überprüfung am 13. Oktober 2026 als Entwurf (Draft) markiert. Implementierungen und Schnittstellen sollten daher gegen die exakt verwendete Version geprüft werden. Die nützliche Idee sind tragbare Belege, den Dienste auswerten können, wobei die Auswertung weiterhin von der jeweiligen Aufgabe abhängt.
Identität gibt dem Agenten eine Referenz
Das Identitätsregister verwendet eine auf ERC-721 basierende Kennung, die mit einer Registrierungsdatei verknüpft ist. Ihre vollständige Referenz umfasst die Chain, die Register-Adresse und die Agenten-ID, sodass Agent 42 in einem Register nicht mit Agent 42 an einer anderen Stelle verwechselt wird. Der Besitzer kann den Datensatz aktualisieren oder die Identität gemäß den Regeln des Designs übertragen. ERC-8004-Spezifikation.
Für einen Käufer hilft die Referenz dabei, einen benannten Agenten von einem kopierten Website-Label zu unterscheiden. Sie kann eine gemeinsame Kennung über Verzeichnisse und Service-Interaktionen hinweg bereitstellen. Der Endpunkt muss dennoch geprüft werden: Eine Beschreibung kann Fähigkeiten behaupten, die der Dienst nicht erbringt.
Betrachte zwei Agenten, die sich beide „Treasury Research Assistant“ nennen. Eine dauerhafte Register-Kennung ermöglicht es einem Käufer, früheres Feedback mit dem beabsichtigten Dienst zu verknüpfen, anstatt sich auf den Namen zu verlassen. Das ist nützlich, selbst wenn die eigentliche Berechnung außerhalb einer Blockchain stattfindet.
Die Registrierung hat zudem einen Eigentümer und eine Update-Autorität. Eine bekannte Identität kann später auf einen anderen Endpunkt oder Operator verweisen. Eine Übertragung leert die registrierte Empfänger-Wallet, die der neue Eigentümer erneut verifizieren muss. Der Käufer sollte wissen, welche Änderungen seit der Arbeit stattgefunden haben, die zur Beurteilung herangezogen wurde.
Ein Agenten-Identifikator ist nur ein Vertrauenssignal
ERC-8004 trennt die Registrierung von Reputation und Validierung.
Agenten-Identifikator
Ein Referenzpunkt, der die relevanten Datensätze verbindet
Registrierungs- und Service-Informationen.
Feedback-Datensätze mit Kontext und Zuordnung.
Validierungsanfragen und -antworten unter einem gewählten Modell.
Konzeptionelle Ansicht des im Artikel überprüften Entwurfsstandards. Deployment- und Validierungsmodelle müssen separat geprüft werden.
Entdeckung und Zahlung sind separate Schichten
Der Standard definiert nicht das Zahlungssystem. Es kann mit x402 oder einer anderen Zahlungsroute koexistieren, aber die Registrierung eines Agenten stellt nicht fest, dass eine bestimmte Rechnung oder Transaktion autorisiert ist.
Die Wallet, die zur Geldannahme verwendet wird, ist ebenfalls eine Behauptung, die eigene Kontrollprüfungen erfordert. Die Spezifikation beschreibt einen Proof-of-Control-Prozess für die Änderung der registrierten Empfänger-Wallet. Dies hilft dabei, die Wallet an die Identität zu binden, ohne zu beweisen, dass der dahinterstehende Dienst vertrauenswürdig ist. Identitäts- und Wallet-Bindung.
MCP und andere Agenten-Schnittstellen beschreiben Wege, um Fähigkeiten anzubieten oder aufzurufen. Ein Zahlungsprotokoll beschreibt einen kommerziellen Austausch. Der Identitätsdatensatz gibt diesen Interaktionen eine Referenz, die im Laufe der Zeit verfolgt werden kann.
Die Trennung der Schichten verhindert eine gefährliche Abkürzung: dass „registrierter Agent“ zum Grund wird, jede Ausgabenanfrage zu genehmigen. Unser Wallet-Kontroll-Artikel erklärt, warum der Signer immer noch eine unabhängige Richtlinie benötigt.
Feedback als Bewertungsgrundlage
Das Reputationsregister zeichnet Feedback-Signale auf, die mit einem Agenten verknüpft sind. Seine Schnittstellen ermöglichen getaggtes Feedback und Verweise auf zusätzliche Beweise. Anwendungen können diese Signale mit ihren eigenen Methoden aggregieren, anstatt einen universellen Score vorauszusetzen. Referenz-Vertragsspezifikation.
Für einen Käufer ist das wichtige Detail die Arbeit, die das Feedback beschreibt. Ein positives Ergebnis für die Bildgenerierung sagt wenig über die Fähigkeit desselben Agenten aus, Finanzunterlagen abzugleichen. Aufgaben-Tags und Endpunkt-Referenzen können verhindern, dass nicht zusammenhängende Erfahrungen vermischt werden.
Der Zeitpunkt ist ebenfalls wichtig. Älteres Feedback kann sich auf ein anderes Modell, eine andere Service-Version oder einen anderen Betreiber beziehen. Eine Historie erfolgreicher Aufgaben ist nützlicher, wenn der Käufer sie mit dem verbinden kann, was der Agent jetzt ausführen wird.
Die untenstehende Visualisierung der Trust-Signale organisiert Fragen zur Feedback-Qualität. Sie weist realen Agenten keinen numerischen Score zu oder behauptet, dass eine Reihe von Checkboxen Ehrlichkeit feststellen kann.
Eine Reputationszahl braucht einen Nenner
Stell dir einen Agenten vor, der viele begeisterte Bewertungen von einer eng vernetzten Gruppe von Wallets hat. Ein anderer hat weniger Bewertungen, liefert aber reproduzierbare Arbeitsnachweise von unabhängigen Kunden. Die höhere Anzahl klärt nicht, welcher Agent die nächste Aufgabe verdient.
Prüfe, wer das Feedback geliefert hat und ob die Arbeit kontrolliert werden kann. Eine Zahlung, die eine Bewertung begleitet, kann eine Interaktion unter dem Zahlungsmechanismus zeigen. Sie beweist nicht, dass der Kauf wirtschaftlich unabhängig war oder das Ergebnis gut war.
Billige, selbst finanzierte Käufe können Aktivität vortäuschen. Zu verhindern, dass ein Besitzer seinen eigenen Agenten bewertet, hindert den Besitzer nicht daran, andere Adressen zu kontrollieren. Nutzer von Reputationsdaten benötigen ein Modell für diese Beziehungen und die Kosten für gefälschte Aktivität.
Der richtige Nenner hängt von der Aufgabe ab. Für einen Spezialisten-Agenten können erfolgreiche Aufträge desselben Typs relevanter sein als die Gesamtzahl der Interaktionen. Für einen Dienst mit sicherheitskritischen Ergebnissen ist eine allgemeine Kundenzufriedenheit ein unvollständiger Qualitätscheck.
Die Validierung muss den Anspruch benennen
Das Validierungsregister bietet Hooks, um Prüfungen durch unabhängige Validatoren anzufordern und aufzuzeichnen. Eine bestimmte Implementierung könnte eine erneute Ausführung, ein Beweissystem oder eine andere Bewertungsmethode verwenden. Design des Validierungsregisters.
Frage genau nach, was der Validator geprüft hat. Die Reproduktion einer Berechnung aus festen Eingabewerten kann bestätigen, dass das Ergebnis diesen Eingaben und Regeln folgte. Es beweist nicht automatisch, dass die ursprünglichen Eingaben vollständig oder wahrheitsgemäß waren.
Für einen Forschungs-Agenten könnte ein nützlicher Check darin bestehen, Zitate gegen einen bereitgestellten Quellensatz zu testen. Das wirft eine andere Frage auf: ob der Quellensatz relevante Beweise weggelassen hat. Ein gültiger Check sollte seinen Umfang für den Käufer sichtbar machen.
Der Validator hat seine eigenen Kompetenz- und Anreizfragen. Eine Onchain-Antwort macht einen Datensatz überprüfbar. Sie nimmt nicht die Notwendigkeit weg, zu verstehen, wie die Antwort erzeugt wurde.
Wähle die Beweise für den Job
Für eine billige, umkehrbare Datensuche kann ein Käufer einen Dienst mit kurzer Historie tolerieren und das Ergebnis danach verifizieren. Für eine große Finanzanweisung können stärkere Kontrollen und eine menschliche Genehmigung nötig sein. Dasselbe Identitätssystem kann unterschiedliche Vertrauensrichtlinien unterstützen.
Dies ist ein praktischer Grund, ein einzelnes „vertrauenswürdiger Agent“-Abzeichen zu vermeiden. Ein Dienst kann für einen Workflow geeignet und für einen anderen ungeeignet sein. Die Berechtigungen, die er erhält, sollten diesen Unterschied widerspiegeln.
Die Ausgabenbefugnis des Agenten benötigt ebenfalls eine separate Begrenzung. Die Auswahl eines seriösen Datendienstes gewährt deinem Einkaufs-Agenten kein unbegrenztes Budget, und die Identifizierung des Einkaufs-Agenten garantiert nicht, dass er einen guten Preis gewählt hat.
Der Verkauf von Daten an Agenten untersucht, was ein Verkäufer offenlegen kann, um diese Entscheidung zu erleichtern. Klare Fähigkeiten und nachweisbare Lieferung können stärkere kommerzielle Belege liefern als ein aufgeblähter Score.
Was ich in einer Registry-Demo prüfen würde
Zeige den Identitätsdatensatz, seinen aktuellen Besitzer und die Endpunkt-Historie. Öffne dann ein Feedback und die Arbeit, auf die es sich bezieht. Wenn eine Validierung vorliegt, identifiziere den geprüften Claim und die Partei, die für die Prüfung verantwortlich ist.
Ändere als Nächstes einen Endpunkt oder übertrage die Identität in einer Testumgebung. Der Käufer sollte in der Lage sein, den alten Reputationskontext vom neuen Betriebsszenario zu unterscheiden. Eine portable Kennung ist nur dann nützlich, wenn die Änderungen um sie herum verständlich bleiben.
ERC-8004 bietet einen Platz an, um Belege anzuhängen. Eine bessere Auswahl ergibt sich aus der Fähigkeit des Käufers, diese Belege für eine spezifische Aufgabe zu interpretieren. Die Zahlung bleibt eine weitere Ebene, die in der x402-Einführung behandelt wird.
Vergleiche denselben Job, bevor du die Reputation vergleichst
Stell dir vor, Agent A hat Feedback zu 1.000 Bildgenerierungs-Jobs. Agent B hat Feedback zu 40 Extraktions-Jobs von Unternehmensanmeldungen. Für eine Aufgabe zur Recherche von Anmeldungen wird A nicht zum besseren Kandidaten, nur weil seine Anzahl größer ist.
Prüfe die Aufgaben-Tags, die Belege hinter den relevanten Jobs und ob diese Jobs den aktuellen Endpunkt und Operator verwendet haben. Führe dann einen kleinen Test mit einer Anmeldung mit einer bekannten Antwort durch. Das Beispiel ist fiktiv; ERC-8004 liefert die Datensätze, während diese Auswahlregel dem Käufer gehört. ERC-8004-Spezifikation.