A2A-komercja: architektura dla agentów AI

Architektura A2A-komercji: jak projektować infrastrukturę dla interakcji agentów sztucznej inteligencji

Współczesny internet został stworzony z myślą o człowieku i jego przeglądarce. Jednak gdy klientem staje się autonomiczny agent sztucznej inteligencji, standardowe rozwiązania — takie jak parsowanie DOM, integracja z API za pomocą OAuth czy ręczna integracja — przestają być skalowalne. W świecie, w którym każdy użytkownik posiada osobisty agent zdolny inicjować tysiące transakcji na sekundę, konieczne są fundamentalne zmiany w adresacji, routingu, zaufaniu i wyszukiwaniu. To nie jest ewolucja REST ani GraphQL — to nowa semantyka sieciowa dla maszynowej interakcji.

Adresacja: od URL do trójwarstwowej identyfikacji

Internet przeznaczony dla ludzi opiera się na DNS i URL: domena → IP → serwer. Dla agentów sztucznej inteligencji ten model nie jest stosowny. Agent może działać na urządzeniu mobilnym pod NAT-em, w chmurze dostawcy lub lokalnie na komputerze użytkownika; może zmieniać punkt końcowy, być offline, a także posiadać kryptograficzną identyfikację niezależną od infrastruktury.

Rozwiązaniem jest trójwarstwowy model:

• Human handle (alice#aigentix.org) — czytelny, przekazywany w kodach QR i wiadomościach identyfikator;
• DID (did:aip:aigentix.org:alice) — zdecentralizowany identyfikator zgodny ze standardem W3C, zawierający klucze publiczne i niezwiązany z domeną;
• Endpoint (https://hub.aigentix.org/relay/alice) — fizyczną drogę dostawy, która może dynamicznie się zmieniać bez utraty identyfikacji.

Kluczowym technicznym detałem jest to, że symbol # w handle konfliktuje z fragment identifier w HTTP. W API handle zawsze przekazywany jest URL-encoded: alice%23aigentix.org. Serwer nie otrzymuje GET /api/v1/resolve/alice#aigentix.org, tylko GET /api/v1/resolve/alice. To nie jest drobiazg — to przykład tego, jak dziedziczne umowy w internecie tworzą realne przeszkody przy projektowaniu protokołów nowej generacji.

Rozwiązywanie odbywa się sekwencyjnie: handle → lookup w rejestrze → DID → dokument DID (z modelem trasy i kluczami publicznymi) → endpoint. Caching wyników na poziomie rejestru zapewnia wydajność, a rozdzielenie warstw gwarantuje długoterminową stabilność identyfikatorów.

Routowanie: direct vs relay i ścisła idempotencja

Posiadanie endpointu jeszcze nie rozwiązuje problemu dostawy. Dwa główne tryby — direct i relay — rozwiązują różne kategorie zadań:

• Direct: HTTP POST bezpośrednio na punkt końcowy odbiorcy. Nadaje się dla korporacyjnych agentów z publicznym adresem IP i gwarantowaną dostępnością.
• Relay: publikacja w trwałym strumieniu (np. NATS JetStream), subskrypcja odbiorcy przez WebSocket. Zapewnia dostawę nawet w przypadku offline, ale dodaje latencję.

Wybór trybu zależy od algorytmu:

• Rozwiązuje DID odbiorcy;
• Jeśli route_mode == "direct" i endpoint jest dostępny — używamy direct;
• W innym przypadku — relay.

Relay zakłada dostawę co najmniej raz. To nie jest opcja — to wymóg. Odbiorca musi implementować idempotentną obsługę według message_id. Każda wiadomość zawiera obowiązkowe pola:

• id: UUID v4;
• created_at: timestamp w RFC 3339;
• encrypted_body: szyfrowane dane (wzajemna wymiana kluczy X25519);
• sig: podpis Ed25519 nad serializowanym kopertą.

Dedykuplikacja realizowana jest poprzez okno przesuwne: przechowywane są ID wiadomości z ostatnich 10 minut z dopuszczalnym odchyleniem czasowym ±300 sekund. Prosty LRU-cache w Redis lub LSM-tree w RocksDB — wystarczające rozwiązanie.

Zaufanie: certyfikaty kryptograficzne i graf zaufania

Ludzie ufają markom, opiniami i rankingom. Maszyny ufają tylko sprawdzonym twierdzeniom. Wykorzystujemy standard W3C Verifiable Credentials (VC) jako podstawę modelu zaufania.

Przykład VC do weryfikacji osoby prawnej:

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

Taki certyfikat wydaje Trust Anchor — centrum zaufania, którego DID i klucze publiczne są znane wszystkim uczestnikom sieci. Weryfikacja odbywa się lokalnie, bez kontaktu z zewnętrznymi stronami.

Poszczególne VC tworzą Trust DAG — skierowany graf acykliczny, gdzie waga krawędzi zależy od autorytetu emitenta. Algorytm obliczania wyniku zaufania jest konserwatywny:

• Skala rośnie powoli: wymagane jest wiele udanych interakcji;
• Skala spada szybko: unieważnienie lub błąd w walidacji natychmiast ją obniża;
• Ostateczny zakres — [0.0, 1.0].

Ten wynik integruje się z wyszukiwaniem poprzez Reciprocal Rank Fusion (RRF):

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

Parametr trust_weight = 0.3 gwarantuje, że zaufanie wzmacnia relewantność, ale nie zastępuje jej.

Wyszukiwanie: hybrydowe rankowanie i strukturyzowana odpowiedź dla agentów

Wyszukiwanie dla człowieka zwraca strony HTML. Wyszukiwanie dla agenta zwraca strukturyzowaną odpowiedź z informacją o tym, jak uzyskać więcej danych. Odpowiedź powinna zawierać nie tylko dane, ale również adres agenta-dostawcy:

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

Pole agent nie jest linkiem do strony, lecz adresem do kolejnego wywołania A2A. Po rozwiązywaniu etagi%23aigentix.org agent wysyła POST z typem aip.commerce.offer.request i item_id, otrzymując strukturyzowane zdjęcia, plan piętra i dane kontaktowe — bez żadnego renderowania HTML.

Hybrydowe wyszukiwanie jest niezbędne, ponieważ czyste wyszukiwanie semantyczne nie wystarcza:

• Artykuły i dokładne frazy (np. iPhone 15 Pro Max 256GB) wymagają FTS;
• Nowe istoty (marka, firma, produkt) nie mają wystarczającego kontekstu semantycznego w embeddings;
• Liczbowe wartości (cena, powierzchnia, piętro) słabo różnią się w przestrzeni embedding.

RRF realizowany jest jako:

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

To pozwala połączyć dwa rodzaje rankingu bez normalizacji, zachowując wrażliwość na top pozycje i stabilnie poprawiając jakość przy mieszanych zapytaniach.

Protokół jako specyfikacja: interoperacyjność ważniejsza niż implementacja

Kluczową zasadą jest ścisłe oddzielenie protokołu od implementacji. Protokół AIP (Agent Interaction Protocol) określa:

• Format koperty: obowiązkowe pola id, from, to, type, encrypted_body, sig;
• Zasady rozwiązywania handle → DID → endpoint;
• Schemat zapytania i odpowiedzi w wyszukiwaniu;
• Algorytmy weryfikacji VC i obliczania wyniku zaufania.

Implementacja (Hub) może korzystać z dowolnego technologicznego stacka: Rust z Actix, Go z NATS, Python z FastAPI — to szczegóły deploju. Taka architektura zapewnia:

• Interoperacyjność między agentami różnych developerów;
• Brak lock-inu dostawców dla firm;
• Możliwość federacji: Hub-y na różnych domenach mogą przekierowywać wiadomości między sobą.

Analogia z e-mailem jest precyzyjna: SMTP — otwarty protokół, Gmail i Yandex.Mail — niezależne implementacje, ale listy przekazują się między nimi bez konieczności uzgodnienia.

Co jest ważne

• Adresacja agentów sztucznej inteligencji wymaga trójwarstwowego modelu (handle/DID/endpoint), aby oddzielić czytelność od kryptograficznej identyfikacji i fizycznej drogi dostawy.
• Routowanie relay nakłada obowiązek implementacji ścisłej idempotencji: każda wiadomość musi mieć UUID v4 i created_at, a odbiorca — wspierać deduplikację w oknie przesuwnym.
• Zaufanie buduje się na W3C Verifiable Credentials, a nie na centralizowanych rankingach: weryfikacja odbywa się lokalnie, bez kontaktu z zewnętrznymi usługami.
• Wyszukiwanie dla agentów zwraca nie URL, ale obiekt z agent.handle i agent.endpoint — to podstawa dla następnego etapu interakcji A2A.
• Hybrydowe wyszukiwanie (RRF) łączy FTS i rankowanie semantyczne, ponieważ embeddings nie zastępują dokładnych pasujących dla artykułów, liczb i nowych istot.
• Protokół musi być oddzielony od implementacji: to warunek interoperacyjności, federacji i ochrony przed lock-inem dostawców.

— Editorial Team