ARD нужен только для открытого обнаружения во время выполнения?

Нет - и это самое распространённое заблуждение. ARD - это протокол обнаружения; он намеренно не предписывает, когда происходит обнаружение и по чему ведётся поиск.

• Когда - на этапе сборки или во время выполнения. Обнаружение может происходить на этапе сборки (разработчик или конвейер выбирает, какие инструменты подключить к агенту) или во время выполнения (агент подыскивает возможность посреди задачи). Запрос одинаков.
• По чему - по курируемому или открытому набору. Корпус может быть курируемым закрытым набором - одобренные инструменты предприятия, каталог одного поставщика, явно заданный реестр - или открытым индексом в масштабе интернета. Более того, большинство предприятий захотят ограничить каталог, по которому ведётся поиск, одобренным и управляемым набором инструментов, а не открытым интернетом, - и ARD поддерживает этот случай в той же мере. Сервис обнаружения решает, что он индексирует и отдаёт; ARD - один и тот же протокол поверх любого из них.

У некоторых партнёров первые интеграции с ARD - это обнаружение на этапе сборки по курируемому каталогу инструментов, и это ровно такое же полноправное применение ARD, как открытое обнаружение во время выполнения по всему публичному интернету.

Весь смысл - в одном открытом способе спросить «что доступно для этой задачи?». Вы спрашиваете одинаково независимо от того, когда спрашиваете и к чему обращаетесь, а сервис обнаружения отвечает из того корпуса, который он курирует. ARD не ограничен ни временем выполнения, ни открытым обнаружением.

---

Как обнаружение сокращает расход контекстного окна?

Традиционный выбор инструментов требует загрузить в системную подсказку (system prompt) все доступные схемы. ARD выносит это вычисление за пределы LLM в выделенный сервис обнаружения (POST /search). Оркестратор обращается к сервису на естественном языке, а тот возвращает только две-три самые релевантные схемы для подстановки в подсказку. На эти несколько схем токены всё равно тратятся: обнаружение не устраняет расход контекста, а сокращает его с тысяч инструментов-кандидатов до нескольких.

---

Нужно ли регистрировать мои агентные ресурсы в центральном каталоге?

Нет. Публикацией полностью распоряжаетесь вы. Вы размещаете ard.json на собственном домене (yourdomain.com/.well-known/ard.json), чтобы объявить о своих агентных ресурсах (agentic resources). Любой сервис обнаружения, соответствующий спецификации, может найти и проиндексировать вашу конечную точку (endpoint) естественным образом, не спрашивая разрешения.

---

Откуда в ARD берётся доверие?

Из курирования реестра, а не из протокола. ARD не делает ни один агентный ресурс заслуживающим доверия - он даёт издателям способ заявить проверяемую идентичность и происхождение, а клиентам - способ их проверить. Само решение о доверии принимается в двух местах, которые спецификации не принадлежат: в реестре, который курирует то, что индексирует и отдаёт, и в клиенте, который проверяет сигналы перед вызовом. Задача ARD - передавать сведения о доверии, а не наделять им.

---

Какие сигналы доверия может передавать ARD?

Роль спецификации здесь узка, и это сделано намеренно: она даёт издателю механизм, позволяющий заявлять проверяемые утверждения, а реестру или клиенту - стандартный способ их проверить. Сам ARD ничего не проверяет и ни за кого не ручается. Запись может нести:

• Идентичность, привязанную к домену - механизм объявления домена издателя в URN записи (urn:air:acme.com:...), благодаря чему идентичность опирается на DNS, а не на самопровозглашённую метку, и может быть проверена любым, кто использует запись.
• Проверенные издатели - механизм, с помощью которого издатель демонстрирует, что он тот, за кого себя выдаёт: trustManifest.identity (например, did:web, SPIFFE или идентичность Agent Name Service (ANS)), которую реестр или клиент криптографически сверяет с доменом издателя. Протокол переносит утверждение; проверку выполняет реестр или клиент.
• Подписанные метаданные - механизм прикрепления отделённой подписи JWS signature к манифесту доверия, чтобы клиент мог убедиться, что запись не была изменена при передаче или посредником.
• Происхождение - механизм объявления родословной (derivedFrom, publishedFrom), фиксирующей, откуда взялся ресурс.
• Аттестации - механизм ссылки на проверяемые артефакты соответствия требованиям (SOC2, HIPAA, GDPR, …), чтобы их можно было получить и проверить.

В каждом случае ARD обеспечивает передачу сигнала доверия. Подтверждается ли сигнал и какой вес ему придать - решение реестра и клиента, а не протокола.

---

Как ARD соотносится с Agent Name Service (ANS)?

Они дополняют друг друга. ARD сосредоточен на обнаружении по задаче - какой агентный ресурс подходит для этой работы и как к нему обратиться - для самых разных видов ресурсов. Agent Name Service (ANS) сосредоточен на безопасном именовании и идентичности: это каталог по образцу DNS, где имя агента разрешается в идентичность, проверенную через PKI (X.509). Они усиливают друг друга: обнаружение полезно только тогда, когда можно доверять идентичности, стоящей за результатом.

ARD построен так, чтобы переносить эту идентичность, а не изобретать её заново. Поле trustManifest.identity записи каталога открыто: наряду с did:web и SPIFFE оно может ссылаться на идентичность ANS, так что реестр или клиент может разрешить и проверить издателя через ANS перед вызовом. ARD передаёт утверждение; ANS - один из механизмов, с помощью которых потребитель его проверяет.

Коротко: находите ресурс с помощью ARD, а имени, которое за ним стоит, доверяйте с помощью ANS.

---

Что делает реестр заслуживающим доверия?

Реестр - это граница доверия, определяемая его политикой курирования: что он решает индексировать, кого проверяет и что отказывается отдавать. Курируемый реестр ручается за то, что возвращает; корпоративный реестр отдаёт только одобренные внутри компании ресурсы; реестр поставщика открывает одну экосистему. Клиенты решают, к каким реестрам обращаться, а реестры сочетаются между собой, поэтому организация может объединить собственный курируемый набор ответов с вышестоящим. Протокол несёт свидетельства; суждение выносит реестр.

---

Проверяет ли ARD, что инструмент или агент безопасен?

Нет - и не утверждает, что проверяет. Безопасность - не то свойство, которое может вычислить протокол обнаружения. ARD лишь позволяет передать относящиеся к делу факты, чтобы судить могли другие. Он даёт издателю возможность сообщить проверяемую идентичность (URN, привязанный к домену), показать, что он проверенный издатель (trustManifest.identity, например did:web или SPIFFE, которую реестр или клиент сверяет с его доменом), передать подписанные метаданные (отделённая подпись JWS, доказывающая, что запись не изменена) и объявить происхождение ресурса - откуда он взялся. Решение о безопасности затем принимают реестр, который курировал результат, и клиент, который проверяет эти сигналы перед вызовом, - а не протокол. Оценка релевантности (поле score), возвращаемая поиском, - это только релевантность; этот показатель НЕ ДОЛЖЕН (MUST NOT) трактоваться как оценка доверия, соответствия требованиям или безопасности.

---

Может ли ARD упростить агентам обнаружение вредоносных инструментов?

Обнаружение настолько разрешительно, насколько разрешителен реестр, к которому вы обращаетесь. Поскольку набором ответов управляет тот, кто ведёт реестр, курируемый или корпоративный реестр возвращает только проверенные им ресурсы: злоумышленник не может внедрить запись в реестр, который сам не решил её проиндексировать.

Кроме того, ARD затрудняет выдачу себя за другого по сравнению с нынешним положением дел, причём сразу по нескольким конкретным направлениям:

• Идентичность привязана к домену издателя (urn:air:google.com:...), а не к самопровозглашённой метке.
• Проверенные издатели: реестр ОБЯЗАН (MUST) проверить, что манифест действительно размещён на заявленном домене или криптографически привязан к нему (через did:web/SPIFFE), поэтому манифест на untrusted.com не может выдать себя за urn:air:google.com:....
• Подписанные метаданные позволяют клиенту убедиться, что запись не была изменена при передаче, а происхождение - проследить, откуда взялся ресурс.

По сравнению с сегодняшним подключением от случая к случаю - скопированными конечными точками без идентичности и происхождения - ARD поднимает нижнюю планку, давая каждому результату проверяемое происхождение. Сам по себе он не решает, что безопасно; он передаёт сигналы идентичности, проверки и происхождения, которые позволяют курируемым реестрам и клиентам отклонять то, что небезопасно.

---

Как оставить отзыв?

ARD разрабатывается открыто, и отзывы приветствуются. Лучший способ предложить изменения, сообщить о проблеме или задать вопрос о спецификации - открыть задачу на GitHub: github.com/ards-project/docs/issues.