A2A-komerce: architektura pro AI-agenty

Architektura A2A-komercie: jak navrhovat infrastrukturu pro interakci AI-agentů

Moderní web byl postaven pro člověka s prohlížečem. Ale když se klientem stává autonomní AI-agent, standardní řešení — parsování DOM, připojení k API prostřednictvím OAuth, ruční integrace — již nejsou schopna škálovat. Ve světě, kde má každý uživatel osobního agenta schopného iniciovat tisíce transakcí za sekundu, jsou potřeba zásadní změny v adresaci, směrování, důvěře a vyhledávání. To není evoluce RESTu ani GraphQLu — je to nová síťová semantika pro strojovou interakci.

Adresace: od URL ke třívrstvé identifikaci

Lidský web spoléhá na DNS a URL: doména → IP → server. Pro AI-agenty je tato model nepoužitelná. Agent může být spuštěn na mobilním zařízení za NAT, v cloudu poskytovatele nebo lokálně na uživatelově PC; může měnit endpoint, být offline, mít kryptografickou identitu nezávislou na infrastruktuře.

Řešením je třívrstvý model:

• Human handle (alice#aigentix.org) — čitelný, přenosný v QR kódech a zprávách identifikátor;
• DID (did:aip:aigentix.org:alice) — decentralizovaný identifikátor podle standardu W3C obsahující veřejné klíče a nespojený s doménou;
• Endpoint (https://hub.aigentix.org/relay/alice) — fyzická cesta doručení, která se může dynamicky měnit bez ztráty identity.

Klíčová technická detail: symbol # v handle konfliktoval s fragment identifierem v HTTP. V API se handle vždy předává URL-encoded: alice%23aigentix.org. Server nedostane GET /api/v1/resolve/alice#aigentix.org, ale pouze GET /api/v1/resolve/alice. To není malá věc — je to příklad toho, jak dedikovaná webová dohoda vytváří reálné překážky při navrhování protokolů nové generace.

Rezolvování probíhá postupně: handle → lookup v registru → DID → DID Document (s route_mode a veřejnými klíči) → endpoint. Caching výsledků na úrovni registru zajišťuje výkon, zatímco oddělení vrstev garantuje dlouhodobou stabilitu identifikátorů.

Směrování: direct vs relay a striktní idempotence

Znalost endpointu ještě neřeší problém doručení. Dva hlavní režimy — direct a relay — řeší různé typy úloh:

• Direct: HTTP POST přímo na endpoint příjemce. Vhodné pro korporátní agenty s veřejným IP a garantovanou dostupností.
• Relay: publikace do trvalého streamu (například NATS JetStream), přihlášení příjemce přes WebSocket. Zajišťuje doručení i při offline stavu, ale přidává latenci.

Výběr režimu určuje algoritmus:

• Rezolvíme DID příjemce;
• Pokud route_mode == "direct" a endpoint je dostupný — použijeme direct;
• Jinak — relay.

Relay znamená doručení minimálně jednou. To není volba — to je požadavek. Příjemce musí implementovat idempotentní zpracování podle message_id. Každá zpráva obsahuje povinná pole:

• id: UUID v4;
• created_at: timestamp v RFC 3339;
• encrypted_body: šifrované payload (X25519 ephemeral key exchange);
• sig: podpis Ed25519 nad serializovaným obalem.

Deduplikace se realizuje prostřednictvím skluzujícího okna: uchovávají se ID zpráv za posledních 10 minut s přípustným clock skew ±300 sekund. Jednoduchý LRU-keš v Redisu nebo LSM-tree v RocksDB — stačí jako implementace.

Důvěra: kryptografické certifikáty a graf důvěry

Lidé důvěřují značkám, recenzím a hodnocením. Stroje důvěřují pouze ověřitelným tvrzením. Používáme standard W3C Verifiable Credentials (VC) jako základ důvěrného modelu.

Příklad VC pro verifikaci právnické osoby:

{
    "@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": "OOO Etazi",
        "inn": "7224052984",
        "verified": true
    },
    "proof": {
        "type": "Ed25519Signature2020",
        "verificationMethod": "did:aip:aigentix.org:trust-anchor#key-1",
        "proofValue": "..."
    }
}

Takový certifikát vydává Trust Anchor — centrum důvěry, jehož DID a veřejné klíče jsou známy všem účastníkům sítě. Kontrola probíhá lokálně, bez kontaktu s třetí stranou.

Samostatné VC tvoří Trust DAG — orientovaný acyklický graf, kde váha hrany závisí na autoritě issuera. Algoritmus výpočtu Trust Score je konzervativní:

• Skóre roste pomalu: vyžaduje množství úspěšných interakcí;
• Skóre padá rychle: revokace nebo chyba validace jej snižuje okamžitě;
• Konečný rozsah — [0.0, 1.0].

Toto skóre se integruje do vyhledávání prostřednictvím Reciprocal Rank Fusion (RRF):

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

Parametr trust_weight = 0.3 zaručuje, že důvěra posiluje relevanci, ale nenahrazuje ji.

Vyhledávání: hybridní ranking a strukturovaná odpověď pro agenty

Vyhledávání pro člověka vrací HTML stránky. Vyhledávání pro agenta vrací strukturovaný objekt s uvedením jak získat více dat. Odpověď by měla obsahovat nejen data, ale i adresu agenta-provizora:

{
    "results": [
        {
            "id": "doc_123",
            "name": "2-pokoj., Tverská, 68m²",
            "price": 79000,
            "available": true,
            "relevance_score": 0.92,
            "trust_score": 0.94,
            "agent": {
                "handle": "etagi%23aigentix.org",
                "name": "Etazi",
                "endpoint": "https://api.etagi.ru/aip"
            }
        }
    ]
}

Políčko agent není odkazem na web, ale adresou pro další A2A-volání. Po rezolvování etagi%23aigentix.org agent odešle POST s typem aip.commerce.offer.request a item_id, získává strukturované fotografie, půdorys a kontaktní údaje — bez jediného HTML renderu.

Hybridní vyhledávání je nutné, protože čisté semantické vyhledávání nestačí:

• Artikly a přesné řetězce (například iPhone 15 Pro Max 256GB) vyžadují FTS;
• Nové entity (značka, firma, produkt) nemají dostatečný semantický kontext v embeddings;
• Číselné hodnoty (cena, plocha, patro) se špatně rozlišují v embedding-prostoru.

RRF se realizuje takto:

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

To umožňuje kombinovat dva rankingy bez normalizace, zachovává citlivost na top pozice a stabilně zvyšuje kvalitu při smíšených dotazech.

Protokol jako specifikace: interoperabilita nad implementací

Klíčový princip — striktní oddělení protokolu a implementace. Protokol AIP (Agent Interaction Protocol) definuje:

• Formát obalu: povinná pole id, from, to, type, encrypted_body, sig;
• Pravidla rezolvování handle → DID → endpoint;
• Schéma vyhledávacího dotazu a odpovědi;
• Algoritmy ověřování VC a výpočtu Trust Score.

Implementace (Hub) může použít jakýkoliv stack: Rust s Actix, Go s NATS, Python s FastAPI — to jsou detaily deploymentu. Taková architektura zajišťuje:

• Interoperabilitu mezi agenty od různých vývojářů;
• Absence vendor lock-in pro firmy;
• Možnost federace: Huby na různých doménách mohou navzájem směrovat zprávy.

Analogie s e-mailem je přesná: SMTP — otevřený protokol, Gmail a Yandex.Mail — nezávislé implementace, ale e-maily cestují mezi nimi bez souhlasu.

Co je důležité

• Adresace AI-agentů vyžaduje třívrstvý model (handle/DID/endpoint), aby se oddělila čitelnost od kryptografické identity a fyzického směrování.
• Relay-směrování vyžaduje implementaci striktní idempotence: každá zpráva musí mít UUID v4 a created_at, a příjemce musí podporovat skluzující okno deduplikace.
• Důvěra je budována na W3C Verifiable Credentials, nikoli na centralizovaných hodnoceních: kontrola probíhá lokálně, bez kontaktu s externími službami.
• Vyhledávání pro agenty vrací ne URL, ale objekt s agent.handle a agent.endpoint — to je základ pro další úroveň A2A-interakce.
• Hybridní vyhledávání (RRF) kombinuje FTS a semantický ranking, protože embeddings nenahrazují přesné shody pro artikly, čísla a nové entity.
• Protokol musí být oddělen od implementace: to je podmínka interoperability, federace a ochrany před vendor lock-in.

— Editorial Team