# FAQ > Частые вопросы об Agentic Resource Discovery: когда происходит обнаружение, нужен ли центральный каталог, откуда берётся доверие и проверяется ли безопасность. Страница: https://agenticresourcediscovery.ru/faq/ Оригинал на английском: https://agenticresourcediscovery.org/faq/ Указатель сайта: https://agenticresourcediscovery.ru/llms.txt ## 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](https://github.com/ards-project/docs/issues).