Реестры агентов сообщают вам, что существует, но не указывают, можно ли им по-прежнему доверять.
Четырехвопросная структура для реестров способностей агентов, охватывающая существование, пригодность, статус и происхождение, плюс простой тест последней проверки, который можно выполнить сегодня.
Представьте агента, который во время обычной работы ищет инструмент по имени, вызывает его, получает разумный ответ и продолжает работу. Задача выполняется успешно, и в этом-то и кроется проблема: никто в команде так и не проверял эту функциональность. Реестры и сервисы обнаружения должны контролировать подобные ситуации, но всего за неделю появилось несколько продуктов и спецификаций, все из которых утверждают, что являются этим слоем контроля.
Ни один из них не ошибается, но вместе они покрывают лишь половину того, что команде необходимо знать перед тем, как агент начнёт использовать новую функциональность. В этой статье проблема разбивается на четыре отдельных вопроса, показано, на которые из них отвечают существующие реестры, а также приводится конкретная проверка и краткий список действий по тем вопросам, которые остаются без ответа.
Что появилось в слое реестра
Приведенная ниже информация отражает данные на момент написания текста; перед тем как полагаться на конкретные функции или номера версий, проверьте актуальную документацию.
Реестр агентов AWS
Сервис Agent Registry в AWS теперь доступен для широкого использования. Его можно рассматривать как частный каталог с встроенными механизмами управления, способный хранить агенты, серверы MCP, карточки агентов A2A, навыки и произвольные пользовательские ресурсы. В дизайне намеренно разделены два уровня: на уровне управления работают ответственные за контроль, которые утверждают или отклоняют записи; пользователи запрашивают информацию с уровня поиска, который отображает только утвержденные записи. Каждая запись проходит через пять состояний (проект, в ожидании, утверждено, отклонено, устарело). События EventBridge запускают переходы между этими состояниями, а CloudTrail ведет журнал аудита.
С полным вводом в эксплуатацию появилась поддержка инфраструктуры как кода (CloudFormation, CDK и Terraform), возможность обмена ресурсами между счетами через RAM, а также автоматическое обнаружение во всей организации агентов, уже работающих на AgentCore. Эту функцию обнаружения легко упустить из виду, однако она существует потому, что незафиксированные «теневые» агенты уже стали настоящей проблемой при учете активов. Среди компаний, внедривших этот решение, — Southwest, PepsiCo, Syngenta, Amdocs и Sony, что указывает на то, что покупатели уже перешли от этапа тестирования к полномасштабному использованию. AWS подробно описывает его концепцию на своем блоге по машинному обучению.
Agentic Resource Discovery (ARD)
Параллельно с этим спецификация, поддерживаемая несколькими поставщиками, также направлена на устранение той же проблемы. Agentic Resource Discovery была разработана сотрудниками Google, Microsoft и Hugging Face и опубликована под лицензией Apache 2.0; к разработке также присоединились NVIDIA, Salesforce и Databricks. Статья The New Stack описывает её как аналог DNS для агентов. Её интерфейс намеренно ограничен: сообщения передаются в формате JSON-LD по протоколу REST. Обязательным является ровно один конечный пункт — POST /search; к нему отправляется описание задачи вместо имени ресурса. Конечные пункты для просмотра являются необязательными. Механизм федерации позволяет компании сохранять свой каталог в закрытом режиме, одновременно передавая запросы во внешние реестры, которым она доверяет. На момент написания спецификация находится на версии 0.91, её модель управления пока остаётся открытой, и W3C рассматривается как один из возможных организаторов её развития.
Постоянная проверка как продукт
Третьим стартапом, вышедшим на рынок, была компания AIR, которая действовала в тайне и собрала 50 миллионов долларов в двух раундах финансирования (первый раунд возглавила Sequoia, второй — Greenoaks). Её деятельность заключается в проверке плагинов, навыков и серверов MCP, которые загружают агенты. Стоит запомнить одну из их статистических цифр: примерно 27% навыков и дополнений из открытых источников, которые они в настоящее время анализируют, отсеиваются.
Когда три новых проекта появляются в течение нескольких дней, нацеленные на один и тот же сегмент рынка, это обычно означает, что отрасль пришла к единому мнению относительно того, где находится недостающий элемент.
Почему поиск не является задачей MCP
MCP никогда не утверждал, что решает проблему обнаружения инструментов. Он определяет механизмы вызова инструмента после того, как агент уже выбрал, какой именно использовать. A2A выполняет аналогичную функцию для общения между агентами, которые уже знают друг о друге. В обоих случаях предполагается, что поиск и выбор необходимой функции уже были выполнены ранее. Если вам нужно вспомнить детали этого разделения, ознакомьтесь с тем, как протокол модельного контекста позволяет агентам находить и вызывать инструменты.
Изменился объем. Подключение серверов MCP вручную возможно с использованием десятка инструментов. Однако при наличии более тысячи таких серверов, принадлежащих разным внутренним командам, поставщикам SaaS и облачным платформам, агент, ограниченный жестко заданным списком в своей конфигурации, едва ли можно назвать агентом; он скорее похож на фиксированный скрипт, который случайно вызывает модель. Механизм обнаружения позволяет изменять набор возможностей во время выполнения. Однако это же свойство означает, что никто не проверял этот набор возможностей, и лишь немногие команды учитывают связанные с этим компромиссы при ценообразовании.
Второе давление исходит от способа расширения агентов. Исследователи, изучившие исходный код одиннадцати инструментов для разработки, содержащих примерно четыре миллиона строк кода для таких инструментов, как OpenHands, Gemini CLI, Codex CLI и Claude Code (arXiv 2609.00006), обнаружили, что функции в стиле SKILL.md там вытеснили MCP: девять из одиннадцати инструментов поддерживают функции, восемь — MCP. Следовательно, самым быстро распространяющимся механизмом расширения является Markdown-файл, содержащий инструкции, которые будет выполнять агент. Такие файлы не имеют механизма подписи и практически не поддерживают версионирование, поэтому запись в реестре, указывающая на такой файл, мало что говорит о его функциях в будущем.
Четыре вопроса, на которые должен ответить реестр
Каждый раз, когда агент собирается использовать функционал, который ранее у него не был, требуются четыре отдельных ответа. Они звучат похоже, но представляют собой разные проблемы, и их разделение позволяет понять, что на самом деле делает тот или иной продукт по сравнению с целью, ради которой он покупается.
Существование: существует ли что-то, что может это сделать?
Есть ли какой-либо функционал, способный выполнять эту задачу, и где он размещен? Именно для этого предназначен метод POST /search ARD, а механизм обнаружения AWS также хорошо справляется с этой задачей. Проблема реальна, и на практике она уже почти решена.
Подходящесть: какой вариант подходит для этой задачи?
Поисковая операция возвращает несколько кандидатов, так какой из них должен использовать агент? Сами авторы ARD утверждают, что здесь сравнение по DNS теряет смысл: запрос возвращает несколько кандидатов вместо одного авторитетного адреса, причем каждый сервис применяет собственные правила оценки доверия и ранжирования. Оставить это неопределённым разумно для молодой спецификации. Однако это неразумно для вашей инфраструктуры, поскольку именно в процессе ранжирования злоумышленник хочет больше всего вмешаться, подобно тому как это происходит при отравлении поисковых систем или использовании тайпосквоттинга в реестрах пакетов.
Статус: одобрено ли сейчас?
Именно здесь AWS демонстрирует наибольшие преимущества: состояния жизненного цикла вместе с событиями позволяют получить четко структурированный ответ, более совершенный по сравнению с любыми другими решениями в подобных системах. Недостаток заключается в том, что информация о одобрении может устаревать. Предположим, запись была обнаружена автоматически, одобрена в марте, а затем проигнорирована. К сентябрю система по-прежнему будет рассматривать её с такой же уверенностью, как будто её только что проверил специалист.
Происхождение: кто его написал и что изменилось?
Кто создал эту функциональность, что изменилось с момента последнего осмотра и что она загружает во время выполнения? Ни один из недавних выпусков не отвечает на эти вопросы, и именно это лежит в основе финансирования AIR. Их точка зрения, которая остается актуальной, заключается в том, что проверка должна быть непрерывной, а не однократной процедурой. Навык, пройдший проверку месяц назад, может стать вредоносным после обновления зависимостей или захвата учетной записи администратора, при этом его запись в каталоге остается абсолютно неизменной. Академические исследования также указывают в том же направлении. Недавние исследования основ агентов, основанных на навыках (arXiv 2608.29596), моделируют жизненный цикл, состоящий из девяти этапов, и ставят публичные реестры, рынки и противников в центр архитектуры, вместо того чтобы рассматривать их как факторы, учитываемые уже на этапе эксплуатации.
Проблемы поиска против проблем цепочек поставок
Первые два вопроса касаются поиска. Последние два — цепочки поставок; отрасль уже сталкивалась с этим ранее с браузерными расширениями, базовыми образами контейнеров и пакетами npm. В каждом случае каталоги существовали задолго до того, как кто-либо мог гарантировать их содержимое, и инциденты безопасности происходили именно в этот период.
Последняя проверенная тестирование
Эта проверка сознательно простая, поскольку ответ важнее самой платформы. Возьмите свой текущий список возможностей агента — будь то специализированный реестр или просто таблица — и выберите любую запись. Затем найдите две даты:
- Когда она была одобрена?
- Когда в последний раз кто-либо, будь то человек или автоматизированная задача, сравнивал её с исходным кодом?
Когда эти временные метки совпадают, у вас в руках каталог, а не план управления. Первая отражает принятое ранее решение; вторая — текущую реальность. Посчитайте количество дней между двумя датами: именно столько времени способность, одобренная кем-то и затем забытая, оставалась доступной для изменения без внимания окружающих. Учитывая, что примерно четверть публично доступных навыков уже не проходит базовую проверку, это число является достаточно точным показателем вашей реальной уязвимости.
У многих команд нет второй временной метки для отображения. Именно это отсутствие является истинным результатом: проблема не в плохом значении, а в отсутствующем поле.
Что делать в этом квартале
Практический план состоит из трех частей в порядке возрастания сложности.
- Внедрите реестр. Проблема отсутствия учета действительно серьезна, и агент без контроля опаснее, чем подписка SaaS без контроля, поскольку он действует самостоятельно. Команды, уже работающие с Bedrock, должны тщательно рассмотреть вариант AWS; тем, кто нуждается в федерации и нейтралитете поставщика, может подойти ARD.
- Дополните реестр отсутствующими полями. Для каждой записи укажите время последней проверки, которое обновляется автоматической задачей, а не человеком. Заранее определите, что будет сигнализировать о устаревании: истечение срока, помещение в карантин или уведомление. Любой из этих вариантов лучше, чем существующая практика, при которой устаревшая запись остается активной бесконечно.
Полезным дополнением к этому плану является слой управления во время выполнения, который определяет, что на самом деле может делать обнаруженная способность; разрешения, контрольные точки утверждения и уровни риска для агентов рассматривают именно этот аспект.
Основные выводы
- Реестры и спецификации обнаружения теперь довольно хорошо отвечают на вопросы «что существует» и «является ли оно одобренным».