Весь современный веб спроектирован для одного типа клиента — человека с браузером. Но когда клиентом становится AI-агент, оказывается, что большинство привычных решений работают неправильно или не работают вообще. В этой статье — разбор архитектурных проблем, которые возникают при проектировании инфраструктуры для Agent-to-Agent (A2A) взаимодействия: адресация, маршрутизация, доверие и поиск.

Представьте: пользователь говорит своему AI-ассистенту — «найди мне двушку в центре до 80 тысяч». Что происходит дальше?

В 2025 году большинство AI‑ассистентов открывают браузер, парсят DOM Авито или ЦИАН, и возвращают результат. Это работает. Но это — костыль. Сайты не проектировались для машинного потребления: там мегабайты HTML-разметки, куки, капчи, динамический рендеринг, пагинация с JavaScript, ограничения на скрапинг в ToS.

Параллельно существует другой подход — интеграция через API. Разработчик идёт на портал Авито, получает ключ, читает документацию на 200 страниц, реализует OAuth, обрабатывает rate limits. Это тоже работает, но предполагает ручную интеграцию каждого сервиса.

Ни тот, ни другой подход не масштабируется до мира, где у каждого пользователя есть персональный агент, который автономно взаимодействует с тысячами сервисов.

Нужен третий путь. И он требует переосмысления нескольких фундаментальных вещей.

Часть 1. Проблема адресации: где живёт агент?

В интернете для людей адресация решена через DNS и URL. Ты знаешь домен — ты знаешь, куда идти.

Для AI-агентов проблема сложнее. Агент — не сайт. У него нет одного IP-адреса: он может быть запущен на инфраструктуре платформы, у провайдера, на личном сервере пользователя. Агент может быть офлайн. Агент может переехать. У агента есть криптографическая идентичность, которую нужно верифицировать.

Мы пришли к следующей трёхслойной модели адресации:

Human handle: alice#aigentix.org ← читаемый идентификатор
DID: did:aip:aigentix.org:alice ← криптографически привязанный ID
Endpoint: https://hub.aigentix.org/relay/alice ← физический адрес

Каждый слой решает свою задачу:

• Handle — для людей. Коротко, запоминаемо, делимо в сообщениях и QR-кодах.

• DID (Decentralized Identifier, W3C стандарт) — для машин. Хранит публичные ключи, не зависит от конкретного домена.

• Endpoint — физический маршрут. Либо прямой URL агента, либо ретранслятор.

Неочевидная проблема с символом #

Когда мы выбирали формат handle, первый же кандидат alice#aigentix.org столкнулся с классической проблемой веба: # в URL — это fragment identifier. Он обрабатывается браузером на стороне клиента и не отправляется на сервер.

GET /api/v1/resolve/alice#aigentix.org

До сервера доходит только: GET /api/v1/resolve/alice

Решение простое, но его нужно явно задокументировать: в API-вызовах handle передаётся URL-encoded:

GET /api/v1/resolve/alice%23aigentix.org ✓

Это хороший пример того, как старые соглашения веба создают неожиданные проблемы при проектировании новых протоколов. @alice@domain (ActivityPub-стиль) той же проблемы не имеет, но мы предпочли # как визуально отличающий агентный адрес от email.

Резолвинг: от handle к endpoint

Процесс резолвинга выглядит так:

alice%23aigentix.org
→ Registry lookup
→ did:aip:aigentix.org:alice
→ DID Document (публичные ключи + route mode)
→ endpoint: https://hub.aigentix.org/relay/alice
или: https://alice-server.example.com/aip

Это намеренно напоминает DNS: один запрос к реестру, результат кэшируется, физический адрес может меняться не затрагивая handle.

Часть 2. Проблема маршрутизации: direct vs relay

Когда у агента есть endpoint, встаёт вопрос: как доставлять сообщения?

Два режима:

Direct: агент-отправитель делает HTTP POST напрямую на endpoint получателя. Просто, быстро, но требует что получатель онлайн и доступен извне.

Relay: сообщение публикуется в дurable stream (у нас — NATS JetStream), получатель подписывается через WebSocket (/agents/connect). Работает для офлайн-агентов, даёт гарантии доставки, но добавляет латентность.

Алгоритм выбора режима:

1. Резолвим DID получателя

2. Если route_mode == «direct» AND endpoint доступен → direct

3. Иначе → relay

На практике для персональных агентов (мобильные приложения, браузерные клиенты) почти всегда relay: они за NAT, не имеют публичного IP, могут быть офлайн. Для корпоративных бизнес-агентов с инфраструктурой — direct.

Проблема at-least-once

Relay на NATS JetStream даёт at-least-once доставку. Значит, получатель должен обеспечивать
идемпотентную обработку по message_id. Это не рекомендация, а требование — при повторной доставке после сбоя одно и то же сообщение может прийти дважды.

В envelope каждого сообщения обязателен id (UUID v4) + created_at. Получатель хранит sliding window обработанных ID для дедупликации. Типичный размер окна — последние 10 минут, с учётом допустимого clock skew в ±300 секунд.

Часть 3. Проблема доверия: как агент решает, кому верить?

В вебе для людей доверие частично решается репутацией: рейтинги, отзывы, знакомые бренды. Агент ничего из этого не воспринимает.

Нам нужна верифицируемая, машиночитаемая система доверия.

W3C Verifiable Credentials как основа

Стандарт W3C VC (Verifiable Credentials) описывает криптографически подписанные утверждения
(claims):

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

Такой сертификат доверия выдаёт Trust Anchor — верифицированный участник, чьи ключи известны реестру. Получатель может проверить подпись, не обращаясь к третьей стороне.

Trust DAG

Отдельные сертификаты доверия образуют направленный ациклический граф (DAG) доверия:

Trust Anchor → выдал credential → Этажи (0.9)
Этажи → взаимодействовал → Агент Алисы (добавляет вес)
Агент Алисы → оставил claim → «транзакция прошла корректно» (+0.001)

Итоговый Trust Score [0.0, 1.0] — взвешенная сумма по всем входящим credentials с учётом веса
issuer’а. Алгоритм намеренно консервативен: score растёт медленно (много успешных взаимодействий), падает быстро (revocation или ошибки).

Интеграция с поиском

Trust Score влияет на ранжирование через Reciprocal Rank Fusion:

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

Где trust_weight = 0.3 — параметр, позволяющий доверию влиять на выдачу, но не подавлять
релевантность полностью. Провайдер с trust=1.0 не должен выигрывать у более релевантного провайдера с trust=0.7, если разница в релевантности существенна.

Часть 4. Проблема поиска: данные для машин

Классический поиск для людей возвращает список URL с сниппетами. Агент не может «перейти по ссылке» и прочитать страницу. Ему нужны структурированные данные + указатель куда обращаться за подробностями.

Правильный ответ поиска выглядит так:

{
 "results": [
 {
 "id": "doc_123",
 "name": "2-комн., Тверская, 68м²",
 "price": 79000,
 "available": true,
 "relevance_score": 0.92,
 "trust_score": 0.94,
 "agent": {
 "handle": "etagi%23aigentix.org",
 "name": "Этажи",
 "endpoint": "https://api.etagi.ru/aip"
 }
 }
 ]
 }

Поле agent — ключевое. Это не просто ссылка на сайт. Это адрес агента, которому можно отправить структурированный запрос на дополнительную информацию:

pAI → AIP Search → [квартира #123, agent: etagi%23aigentix.org]
pAI → resolve(etagi%23aigentix.org) → endpoint
pAI → POST endpoint {type: «aip.commerce.offer.request», item_id: «doc_123»}
bAI Этажи → {photos: […], floor_plan: «…», contact: «…»}

Весь путь — машинный. Ни одного HTML-рендера.

Почему hybrid search, а не чистый semantic

Казалось бы, раз агент понимает естественный язык — достаточно embeddings. На практике не так:

• Артикулы и точные названия: запрос «iPhone 15 Pro Max 256GB» должен находить именно его, а не семантически похожие товары. Для этого нужен FTS.

• Новые сущности: если бренд появился вчера, у него ещё нет богатого семантического окружения в модели.

• Цифры и числа: embedding-модели плохо различают 79000 и 790000 — для них это просто числа с похожими контекстами.

Reciprocal Rank Fusion объединяет два ранжирования без нормализации скоров:

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

k=60 — стандартный параметр, сглаживающий влияние топ-1 результата. Результат: гибридный поиск стабильно лучше каждого из компонентов в отдельности на смешанных запросах.

Часть 5. Разделение протокола и реализации

Одно из принципиальных архитектурных решений — отделить открытый протокол от конкретной реализации.

Протокол описывает:

• Формат envelope (поля id, from, to, type, encrypted_body, sig)

• Правила резолвинга handle → DID → endpoint

• Формат поискового запроса и ответа

• Алгоритм проверки Trust credentials

Реализация (конкретный Hub) может использовать любой стек — это детали деплоя.

Это важно по нескольким причинам:

1. Интероперабельность: агент, созданный сторонним разработчиком, может взаимодействовать с любым совместимым Hub’ом.

2. Избегание vendor lock-in: бизнес, интегрировавшийся с протоколом, не привязан к одной платформе.

3. Возможность федерации: два Hub’а на разных доменах могут маршрутизировать сообщения между собой (Profile B в спецификации).

Аналогия с email точная: SMTP — открытый протокол, Gmail и Яндекс.Почта — разные реализации, но письма ходят между ними.

---

Что осталось за рамками статьи

Намеренно не рассмотрены:

• E2E шифрование: X25519 ephemeral keys + encrypted_body в envelope — отдельная большая тема.

• Делегирование: как агент получает право действовать от имени пользователя (scope, validity period, revocation).

• Commerce lifecycle: состояния offered → accepted → payment_pending → fulfilled и аудит транзакций.

• Федерация: cross-hub резолвинг и синхронизация Trust DAG между независимыми реестрами.

Всем спасибо кто прочитал эту статью до конца :-)