A2A-commerce: Architektur für AI-Agenten

A2A-Kommerzielle Architektur: Infrastruktur für die Interaktion von KI-Agenten entwerfen

Das moderne Web ist für Menschen mit Browsern konzipiert. Doch wenn der Kunde zu einem autonomen KI-Agenten wird, versagen gängige Lösungen – DOM-Parsing, OAuth-basierte API-Integration und manuelle Integration – bei der Skalierung. In einer Welt, in der jeder Nutzer einen persönlichen Agenten hat, der tausende Transaktionen pro Sekunde initiieren kann, sind grundlegende Änderungen in den Bereichen Adressierung, Routing, Vertrauen und Suche erforderlich. Dies ist keine Weiterentwicklung von REST oder GraphQL – es handelt sich um eine neue Netzwerksemantik für die Maschine-zu-Maschine-Interaktion.

Adressierung: Von URLs zur dreischichtigen Identifikation

Das menschliche Web stützt sich auf DNS und URLs: Domain → IP → Server. Für KI-Agenten funktioniert dieses Modell nicht. Ein Agent kann auf einem mobilen Gerät hinter NAT, in der Cloud eines Anbieters oder lokal auf dem PC eines Nutzers laufen; er kann Endpunkte wechseln, offline gehen und über eine kryptografische Identität verfügen, die unabhängig von der Infrastruktur ist.

Die Lösung ist ein dreischichtiges Modell:

• Menschlicher Handle (alice#aigentix.org) – ein lesbare Kennung, die über QR-Codes und Nachrichten übermittelt wird;
• DID (did:aip:aigentix.org:alice) – eine dezentrale Kennung nach dem W3C-Standard, die öffentliche Schlüssel enthält und nicht an eine Domain gebunden ist;
• Endpunkt (https://hub.aigentix.org/relay/alice) – ein physischer Zustellweg, der sich dynamisch ändern kann, ohne die Identität zu verlieren.

Ein wichtiger technischer Detail: Das #-Symbol im Handle steht im Konflikt mit dem Fragment-Identifikator in HTTP. In der API wird der Handle immer URL-codiert: alice%23aigentix.org. Der Server erhält nicht GET /api/v1/resolve/alice#aigentix.org, sondern nur GET /api/v1/resolve/alice. Das ist nicht trivial – es zeigt, wie alte Web-Konventionen echte Hindernisse beim Entwurf von Protokollen der nächsten Generation schaffen.

Die Auflösung erfolgt nacheinander: Handle → Nachschlagen im Registry → DID → DID-Dokument (mit route_mode und öffentlichen Schlüsseln) → Endpunkt. Caching-Ergebnisse auf Registry-Ebene sorgt für Leistung, während die Schichttrennung die langfristige Stabilität der Kennungen gewährleistet.

Routing: Direkt vs. Relay und strikte Idempotenz

Allein ein Endpunkt löst das Zustellproblem nicht. Zwei Hauptmodi – direkt und relay – adressieren unterschiedliche Aufgabenklassen:

• Direkt: HTTP POST direkt an den Endpunkt des Empfängers. Geeignet für Unternehmensagenten mit öffentlichen IPs und garantierter Verfügbarkeit.
• Relay: Veröffentlichung in einem dauerhaften Stream (z. B. NATS JetStream) und Abonnement des Empfängers via WebSocket. Gewährleistet die Zustellung auch bei Offline-Zustand, bringt aber Latenz mit sich.

Die Wahl des Modus wird durch einen Algorithmus bestimmt:

• Den DID des Empfängers auflösen;
• Wenn route_mode == "direct" und der Endpunkt verfügbar ist – direkt verwenden;
• Andernfalls – relay verwenden.

Relay impliziert mindestens einmalige Zustellung. Das ist kein optionaler Zusatz – es ist eine Voraussetzung. Der Empfänger muss idempotente Verarbeitung basierend auf message_id implementieren. Jede Nachricht enthält obligatorische Felder:

• id: UUID v4;
• created_at: Zeitstempel nach RFC 3339;
• encrypted_body: verschlüsselter Payload (X25519-Ephemeral-Schlüsselaustausch);
• sig: Ed25519-Signatur über den serialisierten Umschlag.

Deduplizierung wird über ein gleitendes Fenster realisiert: Nachrichten-IDs der letzten 10 Minuten werden mit einem zulässigen Uhrenversatz von ±300 Sekunden gespeichert. Ein einfacher LRU-Cache in Redis oder ein LSM-Tree in RocksDB reicht aus.

Vertrauen: Kryptografische Zertifikate und Vertrauensgraphen

Menschen vertrauen Marken, Bewertungen und Ratings. Maschinen vertrauen nur überprüfbaren Behauptungen. Wir nutzen den W3C-Standard für verifizierbare Credentials (VC) als Grundlage unseres Vertrauensmodells.

Beispiel eines VC zur Verifizierung einer juristischen Person:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "OrganizationVerification"],
  "issuer": "did:aip:aigentix.org:trust-anchor",
  "credentialSubject": {
    "id": "did:aip:aigentix.org:etagi",
    "legalName": "Etazhi LLC",
    "inn": "7224052984",
    "verified": true
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:aip:aigentix.org:trust-anchor#key-1",
    "proofValue": "..."
  }
}

Ein solches Zertifikat wird von einem Trust Anchor ausgestellt – einem Vertrauenszentrum, dessen DID und öffentliche Schlüssel allen Netzwerkteilnehmern bekannt sind. Die Verifizierung erfolgt lokal, ohne Einbeziehung Dritter.

Einzelne VCs bilden einen Trust DAG – einen gerichteten azyklischen Graphen, bei dem das Gewicht jeder Kante von der Autorität des Ausstellers abhängt. Der Trust-Score-Berechnungsalgorithmus ist konservativ:

• Der Score wächst langsam: viele erfolgreiche Interaktionen sind erforderlich;
• Der Score fällt schnell: Widerruf oder Validierungsfehler senken ihn sofort;
• Der endgültige Bereich liegt zwischen [0.0, 1.0].

Dieser Score wird in die Suche integriert via Reciprocal Rank Fusion (RRF):

final_score = RRF(semantic_rank, fts_rank) × (1 + 0.3 × trust_score)

Der Parameter trust_weight = 0.3 stellt sicher, dass Vertrauen die Relevanz verstärkt, aber sie nicht ersetzt.

Suche: Hybrid-Ranking und strukturierte Antworten für Agenten

Suche für Menschen liefert HTML-Seiten. Suche für Agenten liefert ein strukturiertes Objekt, das angibt, wie man mehr Daten erhält. Die Antwort sollte nicht nur die Daten, sondern auch die Adresse des Agent-Anbieters enthalten:

{
  "results": [
    {
      "id": "doc_123",
      "name": "2-Zimmer-Wohnung, Tverskaya Str., 68 m²",
      "price": 79,000,
      "available": true,
      "relevance_score": 0.92,
      "trust_score": 0.94,
      "agent": {
        "handle": "etagi%23aigentix.org",
        "name": "Etaji",
        "endpoint": "https://api.etagi.ru/aip"
      }
    }
  ]
}

Das Feld agent ist kein Link zu einer Website – es ist eine Adresse für weitere A2A-Aufrufe. Nach der Auflösung von etagi%23aigentix.org sendet der Agent einen POST mit dem Typ aip.commerce.offer.request und item_id, erhält strukturierte Fotos, Grundrisse und Kontaktdaten – ohne jegliches HTML-Rendering.

Hybrid-Suche ist notwendig, weil reine semantische Suche nicht ausreicht:

• Produktcodes und exakte Phrasen (z. B. iPhone 15 Pro Max 256GB) erfordern FTS;
• Neue Entitäten (Marken, Unternehmen, Produkte) haben in Embeddings nicht genug semantischen Kontext;
• Numerische Werte (Preis, Fläche, Etage) werden im Embedding-Raum schlecht unterschieden.

RRF wird implementiert als:

def rrf(semantic_rank, fts_rank, k=60):
    return 1/(k + semantic_rank) + 1/(k + fts_rank)

So können zwei Rankings ohne Normalisierung kombiniert werden, wobei die Sensibilität für Top-Positionen erhalten bleibt und die Qualität bei gemischten Anfragen konstant verbessert wird.

Protokoll als Spezifikation: Interoperabilität statt Implementierung

Das wichtigste Prinzip ist die strikte Trennung von Protokoll und Implementierung. Das AIP (Agent Interaction Protocol) definiert:

• Umschlagsformat: obligatorische Felder id, from, to, type, encrypted_body, sig;
• Regeln für die Auflösung von Handle → DID → Endpunkt;
• Schema für Suchanfragen und -antworten;
• Algorithmen zur Verifizierung von VCs und zur Berechnung von Trust Scores.

Die Implementierung (Hub) kann jeden Stack verwenden: Rust mit Actix, Go mit NATS, Python mit FastAPI – das sind Details der Bereitstellung. Diese Architektur gewährleistet:

• Interoperabilität zwischen Agenten verschiedener Entwickler;
• Keine Vendor-Lock-in für Unternehmen;
• Föderationsfähigkeit: Hubs auf verschiedenen Domains können Nachrichten untereinander weiterleiten.

Die Analogie zum E-Mail-System ist passend: SMTP ist ein offenes Protokoll, Gmail und Yandex.Mail sind unabhängige Implementierungen, doch E-Mails reisen zwischen ihnen ohne Koordination.

Was wirklich zählt

• Die Adressierung von KI-Agenten erfordert ein dreischichtiges Modell (Handle/DID/Endpunkt), um Lesbarkeit von kryptografischer Identität und physischem Routing zu trennen.
• Relay-Routing setzt strikte Idempotenz voraus: jede Nachricht muss eine UUID v4 und created_at haben, und der Empfänger muss deduplizierung per gleitendem Fenster unterstützen.
• Vertrauen basiert auf W3C-verifizierbaren Credentials, nicht auf zentralisierten Ratings: Verifizierung erfolgt lokal, ohne externe Dienste.
• Suche für Agenten liefert nicht URLs, sondern Objekte mit agent.handle und agent.endpoint – das ist die Grundlage für die nächste Ebene der A2A-Interaktion.
• Hybrid-Suche (RRF) kombiniert FTS und semantisches Ranking, weil Embeddings exakte Übereinstimmungen für Produktcodes, Zahlen und neue Entitäten nicht ersetzen.
• Das Protokoll muss von der Implementierung getrennt sein: das ist die Voraussetzung für Interoperabilität, Föderation und Schutz vor Vendor-Lock-in.

— Editorial Team