KI-Agenten-Wirtschaftsinfrastruktur: Ein Forschungsprimer (Teil 1)
KI-Agenten-Wirtschaftsinfrastruktur: Ein Forschungsprimer (Teil 1)
Originalquelle: OKX Ventures. Dieser Artikel ist eine gekürzte Fassung eines ausführlichen Forschungsberichts von OKX Ventures. Aufgrund der Länge wird er in zwei Teilen veröffentlicht: Teil 1 konzentriert sich auf den Makrokontext, das x402-Protokoll, ERC-8004 und das Virtuals Protocol; Teil 2 wird sich mit OpenClaw und breiteren Branchentrends befassen – bleiben Sie dran.
Executive Summary
KI-Agenten entwickeln sich rasant von passiven Copiloten zu aktiven wirtschaftlichen Teilnehmern: Sie entdecken Dienste, verhandeln Bedingungen, lösen Transaktionen aus und (zunehmend) verrechnen Werte onchain. Der entscheidende Wandel ist nicht, dass „KI klüger wird“, sondern „KI bezahlt wird und bezahlen kann“ – was Software zu einem Marktteilnehmer macht.
OKX Ventures betrachtet dies als die Entstehung von Maschine-zu-Maschine (M2M) Zahlungsnetzwerken und einem Infrastruktur-Stack für die Agentenwirtschaft, in dem Identität, Vertrauen, Zahlungen und Agentenmarktplätze komponierbare Primitive werden. In ihrem Ausblick für 2026 heben sie agentenbasierte Zahlungen als eine Phase des frühen Durchbruchs neben mehreren Standards und Branchen-Piloten hervor. (okxventures.medium.com)
In Teil 1 konzentrieren wir uns auf drei grundlegende Bausteine, die in den Gesprächen von Entwicklern immer häufiger auftauchen:
- x402: ein HTTP-nativer Zahlungs-Handshake, der den seit langem reservierten Statuscode
402 Payment Requiredfür Pay-per-Request-Kryptozahlungen wiederbelebt. - ERC-8004: ein Ethereum-Standard-Vorschlag für vertrauenslose Agentenentdeckung + Reputation + Validierung.
- Virtuals Protocol: ein Onchain-Ökosystem, das Agenten als tokenisierte wirtschaftliche Akteure behandelt und die Agent-zu-Agent-Geschäfte über ACP standardisiert.
1) Der Makro-Hintergrund: Warum die Agentenwirtschaft Krypto-Schienen braucht
1.1 Agenten werden zu „API-nativen Unternehmen“
In Web2 monetarisieren Softwareanwendungen typischerweise über Konten, Abonnements, API-Schlüssel, Rechnungen und Rückbuchungen. Agenten sprengen diese Annahmen:
- Agenten möchten sich nicht mitten in einer Aufgabe „anmelden“.
- Agenten können KYC/Identitätsprüfungen, die für Menschen konzipiert sind, nicht zuverlässig durchführen.
- Agenten arbeiten in engen Schleifen (Daten abrufen → Inferenz durchführen → Aktion ausführen → Ergebnis überprüfen), wobei eine Abrechnung pro Aufruf oft natürlicher ist als eine monatliche Abrechnung.
Deshalb gewinnen Stablecoin-Mikrozahlungen, Onchain-Abwicklungssicherheit und programmierbare Autorisierung wieder an Bedeutung – insbesondere für KI-gesteuerte Arbeitsabläufe, die viele Dienste miteinander verbinden.
1.2 Standards konvergieren: Werkzeuge, Identität, Vertrauen und Zahlungen
Der moderne Agenten-Stack wird schichtweise standardisiert:
- Tool-Konnektivität (wie Agenten externe Dienste aufrufen) – z. B. Model Context Protocol (MCP)
- Inter-Agenten-Kommunikation (wie Agenten Nachrichten austauschen und koordinieren) – z. B. Agent2Agent (A2A)
- Identität und Identifikatoren (wie Entitäten auflösbar sind, ohne ein zentrales Verzeichnis) – z. B. W3C Decentralized Identifiers (DIDs) (w3.org)
- Zahlungen + Abwicklung (wie Werte fließen) – wo Protokolle wie x402 darauf abzielen, Zahlungen zu einem nativen Bestandteil des HTTP-Flusses zu machen.
Die Richtung ist klar: Wenn Agenten autonom transagieren sollen, benötigen wir einen Infrastruktur-Stack, der maschinenlesbar, standardmäßig erlaubnisfrei und unter widrigen Bedingungen überprüfbar ist.
2) x402: HTTP 402 Payment Required in einen Onchain-Zahlungsfluss verwandeln
2.1 Der „ungenutzte“ HTTP-Statuscode, der plötzlich wichtig wird
Der HTTP-Statuscode 402 existiert seit Jahrzehnten, war aber in der Spezifikation der HTTP-Semantik für zukünftige Verwendung reserviert. (datatracker.ietf.org) Referenz: RFC 9110 — HTTP Semantics
x402 nimmt diesen reservierten Bereich und gibt ihm eine konkrete, entwicklerfreundliche Bedeutung: Wenn Sie diese Ressource wünschen, fügen Sie eine gültige Zahlung an und versuchen Sie es erneut.
Für einen schnellen, HTTP-zentrierten Überblick siehe: MDN: 402 Payment Required.
2.2 Was x402 vorschlägt (und warum es überzeugend ist)
Im x402-Design fordert ein KI-Agent (oder ein beliebiger Client) eine API/Ressource an:
- Client-Anfrage → Anfrage erreicht ohne Zahlung
- Server gibt HTTP 402 zurück → inklusive Preisangaben und Zahlungsanweisungen
- Client versucht es erneut mit signierter Zahlungsautorisierung
- Server überprüft und sendet die Zahlung → gibt die Ressource zurück
Dieser Fluss wird explizit als Mittel zur Abschaffung von API-Schlüsseln, Konten und Abonnements für Pay-per-Use-Zugang positioniert. (x402.org) Primäre Referenz: x402 Whitepaper (PDF)
2.3 Warum x402 „Agenten-nativ“ ist (nicht nur ein neuer Checkout-Button)
x402 ist für die Diskussion über die Infrastruktur der Agentenwirtschaft interessant, da es mit der Funktionsweise von Agenten übereinstimmt:
- Atomare Intentions-Schleife: „Ich brauche Daten → Ich bezahle → Ich setze die Aufgabe fort“
- Keine langlebigen Geheimnisse wie API-Schlüssel: reduziert eine gängige Sicherheitslücke.
- Komponierbare Monetarisierung: jeder API-Endpunkt kann zu einem Mikromarkt werden.
Dies ist das Herzstück der agentenbasierten Zahlungen: Nicht nur die Möglichkeit, mit Krypto zu bezahlen, sondern Zahlungen maschinen-auslösbar und auf Protokollebene zu gestalten, eingebettet in normale Internetflüsse. (x402.org)
2.4 Die schwierigen Probleme, die x402 allein nicht löst
x402 kann den Zahlungstransport elegant gestalten, aber produktionsreife Agentenwirtschaften benötigen mehr Schichten:
- Autorisierung & Budgets: Wer hat diesem Agenten die Ausgabe erlaubt, wie viel und unter welchen Einschränkungen?
- Streitfall-/Qualitätssicherung: Was passiert, wenn der Server nicht das versprochene Ergebnis liefert?
- Dienstatomarität: Können wir die Zahlung robust an die Ausführung + Lieferung binden?
- Agentenidentität & -vertrauen: Woher wissen wir, dass der gegenüberliegende Agent/Dienst legitim ist?
Hier werden Standards wie ERC-8004 und Ökosystemprotokolle wie Virtuals ACP sehr ergänzend und nicht konkurrierend.
3) ERC-8004: Vertrauenslose Agenten auf Ethereum (Identität, Reputation, Validierung)
Wenn es bei x402 darum geht, wie Agenten bezahlen, geht es bei ERC-8004 darum, wie Agenten über organisatorische Grenzen hinweg entdeckt und vertraut werden.
3.1 Was ERC-8004 vorschlägt
ERC-8004 („Trustless Agents“) ist ein Entwurf für einen Ethereum-Standard, der die Nutzung von Blockchains vorschlägt, um:
- Agenten zu entdecken
- Agenten auszuwählen
- mit Agenten zu interagieren, ohne bestehendes Vertrauen
Er definiert eine Struktur, die sich konzentriert auf:
- ein Identitätsregister
- ein Reputationsregister
- ein Validierungsregister
ERC-8004 betont pluggable Trust Models mit einer Sicherheit, die proportional zum riskierten Wert ist, von geringen bis zu hohen Einsätzen (mit Optionen wie Reputationsfeedback, durch Wetten gesicherte Wiederholungsausführung, zkML-Nachweise oder TEE-basierte Ansätze). (eips.ethereum.org) Primäre Referenz: ERC-8004 auf EIPs
3.2 Warum das für die KI-Agentenwirtschaft wichtig ist
Die meisten Fehler von Agenten in realen Gelddepots liegen nicht an der „Modellintelligenz“ – sie liegen an Vertrauensgrenzen:
- Kann ich verifizieren, welcher Agent was ausgeführt hat?
- Kann ich den Wirkungskreis begrenzen, wenn der Agent kompromittiert wurde?
- Kann ich nachweisen, dass ein Ergebnis gemäß vereinbarten Regeln berechnet/geprüft wurde?
Die Register von ERC-8004 sind ein direkter Versuch, Agentenvertrauen komponierbar zu machen, anstatt es in jeder geschlossenen Plattform neu zu erfinden.
3.3 ERC-8004 + x402: Eine natürliche Paarung
Ein praktisch einsetzbares Denkmodell:
- x402: „Hier ist der Zahlungs-Handshake für Pay-per-Use-Dienste.“
- ERC-8004: „Hier erfahren Sie, wie Sie Agenten/Dienste entdecken und Vertrauen bewerten.“
Zusammen skizzieren sie einen Weg von ad-hoc-Agentenzahlungen hin zu offenen Agentenwirtschaften – wo Agenten Anbieter finden, Vertrauen bewerten, bezahlen und weiterarbeiten können.
4) Virtuals Protocol: Eine Gesellschaft von tokenisierten Agenten + Agent Commerce Protocol (ACP)
Virtuals Protocol nähert sich der Agentenwirtschaft aus einer Ökosystem- und Koordinationsperspektive: Agenten als Onchain-Wirtschaftsaktereure behandeln, die in der Lage sind, Ausgaben zu generieren, Einnahmen zu erzielen und Aufgaben zu koordinieren.
4.1 Was zu bauen, behauptet Virtuals
In eigener Formulierung ist Virtuals Protocol „eine Gesellschaft von KI-Agenten“: ein Onchain-Ökosystem, in dem Agenten Arbeit koordinieren, transagieren und Ergebnisse erlaubnisfrei über die Blockchain abwickeln. (whitepaper.virtuals.io) Primäre Referenz: Virtuals Protocol Whitepaper
Eine bemerkenswerte Designentscheidung: Das Protokoll positioniert $VIRTUAL als universelle Transaktionswährung und Liquiditätspaar über Agenteninteraktionen hinweg. (whitepaper.virtuals.io)
4.2 ACP: Standards für Agent-zu-Agent-Geschäfte
Virtuals argumentiert, dass ohne standardisierte Protokolle die Integration von Agentengeschäften zu einem kombinatorischen Chaos aus kundenspezifischem Code und fragilen Annahmen wird – insbesondere mit zunehmender Anzahl von Agenten und Transaktionsarten. (whitepaper.virtuals.io) Referenz: Agent Commerce Protocol (ACP)
Wichtig ist, dass ACP nicht nur „Zahlungen“ sind. Es geht um:
- Auffindbarkeit von Agentenangeboten
- Strukturierte Job-Workflows
- Onchain-Abwicklungspfade
- Ein gemeinsames Vokabular für Agentengeschäfte
4.3 ACP v2 signalisiert eine Bewegung hin zu realer Komplexität
Die Dokumentation von Virtuals beschreibt ACP v2 als ein wichtiges Update, das unter anderem einführt:
- eine einheitliche Jobs-Schnittstelle für Workflows
- benutzerdefinierte Job-Angebots-Schemata für domänenspezifische Anforderungen
- Accounts als persistente Onchain-Aufzeichnungen von Agent-Agent-Beziehungen und Interaktionshistorie (whitepaper.virtuals.io)
Referenz: Introducing ACP v2
Dies ist wichtig, da Agentengeschäfte inhärent heterogen sind: „Datensatz kaufen“, „Audit durchführen“, „Trade ausführen“ und „Medienasset liefern“ können nicht realistisch in ein einziges, starres Schema passen.
4.4 Virtuals + ERC-8004 + x402: Komplementäre Rollen
Ein kohärenter Stack kann entstehen:
- ERC-8004: Entdeckungs- + Vertrauensprimitive über Grenzen hinweg.
- x402: Reibungslose Pay-per-Request-Abwicklung für APIs/Dienste.
- ACP (Virtuals): Workflow, Jobstrukturierung und Agent-zu-Agent-Koordination innerhalb eines Handelsnetzwerks.
Die offene Frage für 2026 ist nicht, ob Agenten transagieren können – sondern ob wir den Workflow und die Vertrauensflächen ausreichend standardisieren können, um zu verhindern, dass sich das Ökosystem in inkompatible geschlossene Gärten aufspaltet.
5) Checkliste für Entwickler und Nutzer: Worauf man 2025–2026 achten sollte
5.1 Für Entwickler: Die fehlende „Kontrollebene“
Wenn Sie agentenbasierte Zahlungen oder Onchain-Agenteninteraktionen integrieren, priorisieren Sie:
- Ausgabenrichtlinien (pro Händler, pro Aufgabe, pro Zeitfenster-Beschränkungen)
- Schlüsselisolierung (betriebliche Schlüssel von Treasury-Schlüsseln trennen)
- Auditierbarkeit (jeden Intent signieren und Quittungen speichern)
- Fallbacks & Not-Aus-Schalter (pausierbare Flows, menschliche Genehmigungen für Grenzfälle)
Hier wird „Infrastruktur der Agentenwirtschaft“ real: Bezahlen ist einfach; sicheres Bezahlen ist schwierig.
5.2 Für Nutzer: Selbstverwahrung wird zu einem primitiven Sicherheitsmerkmal für Agenten
Wenn Agenten transagieren können, hört die Wallet-Sicherheit auf, ein Nischenanliegen zu sein – sie wird zum operationellen Risikomanagement.
Ein praktischer Ansatz, den viele Teams verfolgen, ist die Trennung von Geldern nach Rolle:
- Eine kleine, überwachte Hot-Wallet für begrenzte tägliche Agentenausgaben.
- Eine Cold-Storage-Treasury-Wallet, die Budgets nur absichtlich auffüllt.
Wenn Sie Agenten betreiben, die mit DeFi oder Krypto-Diensten Pay-per-Use interagieren, ist dies auch der Ort, an dem eine Hardware-Wallet natürlich passt. OneKey beispielsweise ist für die Selbstverwahrung konzipiert und kann verwendet werden, um langfristige Gelder offline zu halten, während sie onchain-Workflows unterstützt, wenn Sie bewusst Transaktionen signieren.
Was kommt als Nächstes (Vorschau Teil 2)
In Teil 2 erweitern wir diese Infrastrukturkarte um:
- OpenClaw: seine Rolle in der Laufzeit-/Tooling-Schicht für Agenten und was dies für Krypto-Nutzer bedeutet.
- breitere Branchenentwicklungen: Interoperabilität, Compliance-Druck, Sicherheitsvorfälle und der Kampf zwischen offenen Standards und geschlossenen Plattformen.
Disclaimer: Dieser Artikel dient nur zu Informationszwecken und stellt keine Finanzberatung dar.



