Agentic Resource Discovery: ai-catalog.json, доверенные каталоги и полномочия phone agent

Что решает Agentic Resource Discovery

Agentic Resource Discovery, или ARD, отвечает на простой практический вопрос: как ИИ-агенту найти подходящий инструмент, навык или другого агента, не полагаясь на закрытый список интеграций внутри одного продукта. В анонсе спецификации Agentic Resource Discovery от 17 июня 2026 года ARD описана как открытый способ публиковать, обнаруживать и проверять ресурсы агентов в вебе. Для пользователя это звучит как поиск возможностей. Для разработчика это слой метаданных: кто публикует ресурс, что он умеет, каким протоколом вызывается и где лежит каталог.

Ключевой файл в этой модели часто называют ai-catalog.json. Его удобно воспринимать как машинно-читаемую витрину домена: организация размещает каталог у себя, описывает доступные возможности и дает агентам способ понять, куда подключаться дальше. Каталог инструментов ai-catalog.json не должен превращаться в кнопку «выполнить все». Он сообщает, что ресурс существует, как он описан и какой родной интерфейс нужно использовать после выбора.

Проблема, которую решает ARD, особенно заметна в крупных агентских системах. Один сервис публикует MCP-сервер, другой предоставляет OpenAPI, третий описывает A2A-агента, четвертый ведет вложенный каталог. Без общего слоя обнаружения агенту приходится знать каждую интеграцию заранее. С ARD появляется общий маршрут: найти подходящий ресурс, проверить метаданные, выбрать интерфейс и уже потом подключаться через протокол, который этот ресурс действительно поддерживает.

Для phone agent это начало цепочки, а не конец. Найденный ресурс может помочь агенту понять, что существует инструмент для календаря, карты, сообщений или корпоративного workflow. Но Android-действие на телефоне живет в другой зоне: разрешения, включенные инструменты, выбранная цель, видимое подтверждение и возможность отменить или отозвать доступ остаются отдельными проверками.

Как каталоги и реестры публикуют возможности

Когда организация хочет быть доступной для агентского поиска, она может опубликовать каталог на собственном домене. В этом каталоге описываются ресурсы: инструменты, навыки, агенты, вложенные каталоги, поддерживаемые интерфейсы, сведения об издателе и метаданные проверки. По данным публичной спецификации ARD и репозитория проекта, работа над схемами, архитектурой доверия и эталонными материалами ведется открыто, а проект опубликован под лицензией Apache-2.0.

Дальше возможны два пути. Первый путь прямой: клиент знает домен партнера и забирает каталог напрямую. Так работает сценарий, где поставщик уже известен, а агенту нужно не искать по всему вебу, а получить актуальные машинные метаданные. Второй путь проходит через реестр. Реестр обходит каталоги, индексирует их и позволяет агенту искать по намерению: например, «найти инструмент для бронирования», «найти A2A-агента для поддержки клиента» или «найти OpenAPI-инструмент для статуса заказа».

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

Что доказывает проверка издателя

Доверенный каталог агентских инструментов начинается не с красивого описания возможностей, а с вопроса «кто это опубликовал?». ARD добавляет ценность именно здесь: производственная схема обнаружения может включать криптографически проверяемые метаданные издателя до прямого подключения через родной протокол. Это снижает риск подмены каталога, фишингового endpoint или ресурса, который выдает себя за известную организацию.

Однако проверка издателя доказывает не все. Она помогает подтвердить, что каталог связан с заявленным источником и что метаданные не выглядят случайной самозваной записью. Она не доказывает, что каждая возможность безопасна для любой задачи, что endpoint совместим с вашим агентом, что пользователь имеет право выполнить действие или что ресурс не изменит последствия бизнес-операции. Домашний адрес может быть настоящим, но решение войти внутрь все равно требует отдельной причины и правил.

Для агентской системы остаточные риски делятся на несколько групп. Ресурс может быть настоящим, но слишком широким по scope. Интерфейс может быть документирован, но несовместим с конкретным клиентом. Описание может быть свежим, но поведение endpoint изменилось после публикации. Возможность может быть корректной для чтения, но опасной для записи, отправки, удаления или изменения настроек. Поэтому проверка перед подключением должна вести к политике, а не заменять ее.

В телефонной среде это особенно важно. Даже если издатель проверен, phone agent обязан спросить: включен ли такой инструмент локально, какие данные он увидит, какая Android-permission нужна, какую цель выбрал пользователь, есть ли подтверждение и как отменить последствия. Проверенная витрина ресурсов делает старт надежнее, но не превращает найденный инструмент в разрешенное действие.

Как ARD передает подключение MCP, A2A, OpenAPI и контрактам приложений

ARD не заменяет MCP, A2A, OpenAPI или контракты приложений. Его задача другая: найти и описать ресурс так, чтобы клиент понял, каким родным способом к нему обращаться. Каталог может рекламировать MCP-сервер, A2A-агента, OpenAPI-инструмент или вложенный каталог. После выбора ARD отступает на второй план, а реальная коммуникация идет через указанный интерфейс.

Это разделение защищает архитектуру от ложного универсализма. MCP может быть удобен для инструментов и контекста, A2A — для взаимодействия между агентами, OpenAPI — для HTTP-сервисов с формальными методами, а мобильное приложение может иметь собственный вызываемый контракт. ARD связывает эти миры через метаданные, но не превращает их в один протокол и не обещает, что любой Android-экран внезапно стал callable.

Для мобильных приложений следующий вопрос звучит так: есть ли у приложения машинно-вызываемое действие, которое можно безопасно использовать после обнаружения? Если интересен именно этот слой, полезно отдельно разобрать App Intents и приложения, вызываемые машиной: что это значит для AI-агентов. Там фокус на том, как приложение описывает действия, параметры и ограничения для машинного вызова; здесь мы остаемся на уровне обнаружения и доверенного перехода к интерфейсу.

Практический результат такой: каталог может сказать «для этой задачи есть ресурс, вот его publisher metadata, вот endpoint, вот протокол». Клиент должен проверить совместимость endpoint, схему параметров, доступные scopes, лимиты, ошибки и поведение при отказе. Только после этого phone-agent runtime может решить, разрешено ли вообще предлагать это действие пользователю на телефоне.

Почему обнаружение не равно полномочию на телефоне

Каталог инструментов ai-catalog.json помогает найти возможность, но телефон требует другой набор решений. На Android разрешения запрашиваются в контексте функции, когда они действительно нужны; это отражено в официальных рекомендациях Android по runtime permissions. При этом Android-разрешение отвечает за доступ приложения к данным или возможностям устройства, а не за бизнес-смысл действия. Доступ к контактам не означает согласие отправить сообщение конкретному человеку. Доступ к локации не означает разрешение поделиться маршрутом в чате.

Поэтому phone agent должен держать несколько проверок отдельно. Обнаружение отвечает на вопрос «какой ресурс существует?». Проверка издателя отвечает на вопрос «кто его опубликовал?». Совместимость endpoint отвечает на вопрос «можем ли мы технически говорить с этим ресурсом?». Локальная политика отвечает на вопрос «включен ли этот инструмент для пользователя или команды?». Android-permission отвечает на вопрос «может ли приложение получить нужный системный доступ?». Approval отвечает на вопрос «разрешил ли пользователь именно это действие с этой целью и последствиями?».

Глубокий разбор того, почему навыкам агента нужны проверки разрешений, вынесен в отдельный материал Безопасность навыков AI-агентов: почему телефону нужны проверки разрешений. А полная рамка идентичности, полномочий и записей действий раскрыта в статье Идентичность, разрешения и аудит ИИ-агентов: стек безопасности для телефона. В этой статье важен узкий вывод: discovery делает ресурс видимым, но authority на телефоне появляется только после локальных проверок, пользовательского контекста и управляемого исполнения.

Проверка ресурса до подключения и до выполнения

Перед тем как discovered resource попадет в телефонный workflow, полезно пройти две разные проверки: pre-connect и pre-execution. Первая отвечает за доверие и совместимость до технического подключения. Вторая отвечает за конкретное действие на телефоне. Если их смешать, команда может аккуратно подключиться к правильному endpoint, а затем выполнить слишком широкое действие без достаточного контекста.

1. Проверьте издателя. Сопоставьте домен, publisher metadata и ожидаемого поставщика. Если ресурс пришел через реестр, посмотрите, какие verification metadata вернулись вместе с результатом.
2. Оцените свежесть каталога. Зафиксируйте версию, дату, endpoint и схему. Устаревший каталог опасен не только ошибками, но и неправильными ожиданиями о scopes.
3. Проверьте родной интерфейс. MCP, A2A, OpenAPI или контракт приложения должны быть совместимы с вашим клиентом. Тестируйте не только успешный вызов, но и ошибки, таймауты и отказ в доступе.
4. Сопоставьте scopes с задачей. Ресурс для чтения статуса не должен получать полномочия записи. Инструмент для черновика не должен автоматически отправлять сообщение.
5. Включайте локально и наблюдаемо. Пользователь или администратор должен видеть, что инструмент доступен, зачем он включен и как его отключить.
6. Начинайте с низкого риска. Первые проверки должны читать экран, открывать приложение, готовить черновик или показывать результат, а не менять настройки или отправлять данные наружу.
7. Проверяйте цель действия. Контакт, приложение, аккаунт, файл, адрес, сумма или получатель должны быть явными перед шагом с последствиями.
8. Определите stop и revoke. Должен быть понятный способ остановить задачу, снять доступ, отключить инструмент и увидеть, что уже произошло.

Такой список не заменяет общую программу безопасности. Он делает короткую рабочую дорожку для ARD-сценариев: ресурс найден, источник проверен, интерфейс понятен, локальная политика включила его только в нужном объеме, а Android-действие проходит собственный контроль перед выполнением.

Как FoneClaw отделяет видимость каталога от полномочий телефона

В FoneClaw мы используем эту границу как продуктовый принцип: модель может понять задачу и построить план, но Android-действия выполняются через управляемую среду, поддерживаемые инструменты и видимые результаты. Текущий публичный каталог FoneClaw описывает 100+ встроенных инструментов для экранного чтения, запуска приложений, системных действий, коммуникаций, локации, workflows, skills и plugins. В датированном снимке публичного каталога инструментов FoneClaw на 1 августа 2026 года содержится 118 встроенных инструментов в 11 категориях с risk и approval labels.

Это не ARD-реестр и не заявление о реализации ai-catalog.json. Практическая мысль другая: даже когда инструмент виден в каталоге, его наличие не равно полномочию выполнить действие. В FoneClaw per-tool controls, approval policy и permission recovery помогают разделить поиск инструмента, включение, разрешение Android, approval конкретного шага и обработку результата. Модель, настроенная внутри FoneClaw, отвечает за понимание, рассуждение и планирование; FoneClaw вызывает поддерживаемые Android-инструменты в рамках governed runtime.

В данных релизов FoneClaw версия 0.1.0 фиксирует развитие per-tool management, safer contracts, permission recovery и trusted plugin continuation. Для пользователя это означает более предметную работу с действиями: инструмент можно искать, включать, контролировать по approval-политике, а недостающие permissions направлять по требованию. Плагины в такой модели начинаются с видимого предложения и доверенной процедуры, а не с тихого фонового обнаружения и установки.

Если нужно увидеть всю архитектуру перехода от намерения к телефонному действию, полезен отдельный разбор Управление телефоном AI-агентом: как Android переходит от команд к действиям. Здесь же FoneClaw нужен как пример разделения: каталог делает возможности обозримыми, policy делает их управляемыми, Android permissions дают системный доступ в контексте, а user approval определяет, какое действие действительно можно выполнить сейчас.

Что проверить команде перед внедрением реестра ресурсов

Команде, которая рассматривает Agentic Resource Discovery или похожий реестр ресурсов, стоит тестировать не обещание «агент сам все найдет», а качество каждого перехода. Хороший пилот начинается с набора намерений: что пользователь просит, какие каталоги должны вернуться, какие ресурсы являются ложными совпадениями, какие устарели, какие проходят verification, но не подходят по scope, и какие корректно передают клиента к родному протоколу.

Решение о внедрении должно зависеть от риска. Для read-only discovery достаточно проверить точность поиска, freshness и compatible handoff. Для действий с внешними последствиями нужны отдельные approval rules, logs, revocation и тесты отказа. Для phone agent финальная метрика еще строже: discovery и authority должны быть независимо наблюдаемы. Пользователь и администратор должны понимать, что было найдено, что было включено, какое разрешение запросили, какое действие подтверждено и как отменить дальнейший доступ.