AWS Agent Registry в этой статье рассматривается как единый корпоративный каталог AI-агентов, MCP-серверов и skills. Такой каталог должен отвечать на практические вопросы: что делает ресурс, кто за него отвечает, где он работает, какие данные видит, кому разрешено подключение и когда его проверяли.
Проблема появляется, когда несколько команд параллельно создают агентов для похожих задач, подключают собственные MCP-серверы и хранят инструкции к skills в разных репозиториях. В результате разработчик тратит время на поиск, администратор не видит полный набор интеграций, а служба безопасности не может быстро определить владельца и уровень риска конкретного компонента.
В доступном контексте нет официальной спецификации AWS Agent Registry. Поэтому Governance Plane, Discovery Plane, публикация через CLI или API, approval workflow, семантический поиск из IDE и интеграция с Amazon Quick ниже описаны как целевая архитектурная модель и практические сценарии, которые нужно сверить с актуальной документацией AWS перед публикацией фактологических утверждений о продукте.
AWS Agent Registry: короткий ответ, что это и зачем нужен
AWS Agent Registry можно понимать как корпоративный каталог эксплуатационных сведений об агентных ресурсах. Он связывает технический компонент с владельцем, политиками доступа, версией, окружением, документацией и жизненным циклом.
Для enterprise-среды этого набора сведений достаточно, чтобы решить четыре задачи: найти уже существующий ресурс, сравнить его с похожими решениями, понять ограничения перед подключением и направить запрос на разрешенный доступ. Registry не должна автоматически открывать endpoint или выдавать права к данным. Поиск, допуск и авторизация остаются разными операциями.
Почему список ссылок и внутренняя wiki перестают работать
Внутренняя wiki хорошо подходит для вводной документации, но быстро теряет актуальность при частых изменениях. Ссылка может вести на устаревшую версию, репозиторий может сменить владельца, а описание агента может не отражать новые инструменты и разрешения.
Представим типичный сценарий. Команда поддержки создала агента, который ищет статус заявки в CRM. Команда автоматизации параллельно написала MCP-сервер для той же CRM. Третья команда подключила внешний skill для подготовки ответа клиенту. Все три решения могут работать, но в общей базе не видно, какие функции пересекаются, кто отвечает за безопасность и какой компонент разрешен для production.
Репозиторий кода отвечает на вопрос о том, где лежит исходный код. Он не всегда отвечает на вопросы о владельце сервиса, сроке следующей проверки, классе обрабатываемых данных, SLA, совместимости и правилах использования. Registry должна хранить именно эти эксплуатационные и governance-метаданные.
Связка каталога с платформенными процессами помогает контролировать накопление AI-пилотов и повторяющихся интеграций. Практический подход к такой платформе разобран в статье о платформенной организации корпоративного GenAI.
Что попадает в такой каталог
У трех типов ресурсов разные задачи, поэтому их карточки нельзя описывать одной короткой строкой.
| Ресурс | Что делает | Какие сведения нужны для выбора |
|---|---|---|
| AI-агент | Самостоятельно выполняет задачу, вызывает модели и инструменты, может поддерживать состояние диалога | Назначение, входы и выходы, используемая модель, инструменты, источники данных, права, ограничения и окружение |
| MCP-сервер | Предоставляет агенту инструменты, ресурсы или шаблоны через протокол MCP | Список инструментов, параметры вызовов, типы данных, сетевые требования, секреты, доступные системы и владелец |
| Skill | Добавляет агенту инструкцию, процедуру или специализированную способность | Условия применения, поддерживаемые агенты, требуемые инструменты, ограничения, версия и результат выполнения |
Минимальная полезная карточка должна показывать назначение ресурса обычным языком, его технический идентификатор, владельца, актуальную версию, статус и порядок подключения. Для компонентов, которые работают с корпоративными данными, добавляются классы информации и требуемые разрешения.
Governance Plane и Discovery Plane: два разных контура одной registry
Каталог с полнотекстовым поиском решает лишь часть задачи. Enterprise-система должна одновременно управлять ресурсами и помогать их находить. Эти функции удобно разделять на Governance Plane и Discovery Plane.
| Контур | Главный вопрос | Типичные данные и действия |
|---|---|---|
| Governance Plane | Можно ли публиковать, видеть и использовать ресурс | Владелец, статус, версии, группы доступа, approval workflow, аудит, сроки пересмотра и отзыв публикации |
| Discovery Plane | Как найти подходящий ресурс для конкретной задачи | Поиск по назначению, домену, инструментам, совместимости, уровню риска и описанию входов и выходов |
Governance Plane: кто может публиковать и использовать ресурс
Governance Plane хранит правила, которые превращают запись в управляемый объект. У ресурса должен быть технический владелец, команда сопровождения и ответственное лицо за security review. Для критичных агентов нужны понятные сроки пересмотра, журнал изменений и процедура экстренного ограничения доступа.
Запись в каталоге не заменяет контроль фактического вызова. Если MCP-сервер обращается к CRM, права на CRM должны проверяться отдельным механизмом. Если агент запускает код, sandbox и сетевые политики должны ограничивать его окружение. Если skill передает данные во внешний сервис, это должно быть видно в карточке и покрываться отдельным правилом.
Полезная модель разделяет как минимум четыре статуса доступа:
- ресурс можно найти и запросить к нему доступ;
- ресурс можно использовать конкретной группе;
- ресурс разрешен для определенного окружения, например staging;
- ресурс ограничен, отозван или ожидает повторной проверки.
Такой подход связывает каталог с IAM, сетевыми политиками, секрет-хранилищами и аудитом. Сам Registry не должен превращаться в еще один изолированный список разрешений.
Discovery Plane: как найти подходящий ресурс по задаче
Разработчик обычно ищет не конкретное имя, а решение проблемы. Запрос может звучать так: «найти MCP для чтения статусов заказов без доступа к персональным данным» или «подобрать агента для анализа производственных инцидентов в AWS-аккаунте команды».
Discovery Plane должен учитывать смысл запроса и структурированные поля. Поиск можно строить по названию, домену, входным и выходным данным, списку инструментов, требованиям к окружению, уровню риска и совместимым версиям. Семантический поиск помогает сопоставлять разные формулировки, но его качество зависит от полноты метаданных.
Семантический поиск из IDE выглядит логичным сценарием: разработчик описывает задачу рядом с кодом, получает карточки разрешенных ресурсов и сразу видит способ подключения. Поддержка такого сценария именно в AWS Agent Registry не подтверждена доступными материалами, поэтому его следует считать целевым вариантом, а не готовой функцией.
Почему эти контуры нельзя полностью слить
У ресурса есть три разных свойства:
- Discoverability, его можно найти в каталоге.
- Eligibility, пользователь или проект соответствует условиям использования.
- Authorization, конкретный вызов разрешен политикой доступа.
Например, разработчик видит MCP-сервер для финансовой отчетности и читает его документацию. Это не означает, что его команда имеет право вызывать endpoint или получать данные о зарплатах. Карточка помогает принять решение, eligibility проверяет соответствие условиям, а authorization контролирует реальную операцию.
Жизненный цикл ресурса: от публикации до вывода из эксплуатации
Каталог приносит пользу, когда каждая запись проходит управляемую последовательность. Создание карточки без проверки дает видимость, но не дает доверия.
Публикация через CLI или API
Целевая схема предполагает, что автор регистрирует агента, MCP-сервер или skill из CI/CD либо через внутренний портал. Машинно-читаемые метаданные должны формироваться рядом с исходным кодом и версией артефакта, чтобы публикация оставалась воспроизводимой.
В manifest можно заложить поля resource_id, resource_type, owner_team, version, environment, data_classes, required_permissions, external_calls, risk_level и review_due. Названия приведены как пример схемы, а не как подтвержденный набор параметров AWS.
Процесс регистрации должен отклонять карточку без владельца, версии, описания входов и выходов, перечня внешних вызовов или даты следующего review. Такая проверка на входе дешевле ручной уборки каталога через несколько месяцев.
Approval workflow и ответственность владельца
Черновая запись не должна сразу становиться разрешенным корпоративным компонентом. Для разных рисков нужен разный маршрут согласования.
- Автор описывает ресурс, его назначение, зависимости и ограничения.
- Технический владелец проверяет сборку, версию, тесты, мониторинг и план поддержки.
- Security reviewer проверяет права, внешние вызовы, обработку данных, секреты и журналирование.
- Curator оценивает описание, теги, дубликаты и соответствие общей схеме.
- Ответственный администратор публикует ресурс для выбранных групп и окружений.
Для агента, который читает общедоступную базу знаний, такой маршрут может быть коротким. Для MCP, который изменяет записи в ERP, потребуются более строгие проверки, отдельные тестовые данные и подтверждение модели полномочий.
Версии, deprecation и архив
Версия карточки должна быть связана с версией самого ресурса. Обновление prompt, набора инструментов, схемы входных данных или разрешений может изменить поведение агента, даже если его название осталось прежним.
Статусы active, deprecated, restricted и archived подходят как концептуальная модель. Их наличие и точные названия в AWS нужно подтвердить отдельно.
При переходе в deprecated новые проекты не подключают ресурс без явного исключения, а существующим потребителям показывают замену и конечную дату поддержки. Restricted ограничивает использование после инцидента или изменения политики. Archived убирает ресурс из обычного поиска, сохраняя историю для аудита.
Полный жизненный цикл выглядит так: создание, регистрация, заполнение метаданных, техническая проверка, security review, публикация, версионирование, периодический пересмотр, ограничение доступа и архивирование.
Как AWS Agent Registry меняет работу разных команд
Ценность каталога видна через ежедневные действия людей, а не через количество карточек. Разработчику нужен быстрый выбор, администратору нужен контроль, куратору нужна чистота данных.
Разработчик: найти и подключить уже одобренный компонент
Разработчик формулирует задачу, получает несколько кандидатов и сравнивает их по владельцу, версии, совместимости, правам и уровню риска. Например, для агента поддержки можно выбрать MCP с операциями только чтения вместо сервера с правом изменять заказы.
После выбора пользователь получает инструкцию подключения, требуемые группы доступа и контакт владельца. Если доступ закрыт, Registry должна объяснить причину и маршрут запроса, а не оставлять пользователя с ошибкой без контекста.
Повторное использование сокращает параллельную разработку, но не отменяет проверку. Агент, одобренный для одной команды и набора данных, может не подходить другому проекту из-за иной модели угроз или требований к региону хранения.
Администратор: управлять политиками и видимостью
Администратор задает области видимости, связывает ресурсы с группами и окружениями, отслеживает действия пользователей и реагирует на изменения риска. Для AWS-среды сюда добавляются организационные аккаунты, роли IAM, границы VPC, журналы вызовов и правила работы с секретами.
Каталог может показывать, что MCP существует в production, но право его вызвать должно проверяться в месте фактического запроса. Этот принцип защищает от распространенной ошибки, когда внутреннее описание случайно превращают в универсальный пропуск к данным.
Curator: поддерживать качество каталога
Куратор, или curator, проверяет, что карточка понятна человеку и пригодна для автоматического поиска. Он ищет дубликаты, неполные теги, просроченные даты review, неработающие ссылки на документацию и расхождения между описанием и фактическим набором инструментов.
Для каждой записи нужен владелец, который получает уведомление перед сроком пересмотра. Карточку стоит ограничить или удалить из поиска, если команда закрыла сервис, не отвечает за ресурс, перестала поддерживать версию или не может подтвердить заявленные права.
Нейробаза и корпоративная система управления знаниями могут дополнить Registry описаниями процессов, но не заменяют реестр ответственности и доступа. Практические вопросы построения такой базы разобраны в руководстве по управлению знаниями для AI-команд.
IDE и бизнес-инструменты: от поиска к использованию
Наиболее удобный сценарий предполагает, что пользователь ищет агентные ресурсы там, где уже работает. IDE может показывать подходящие MCP и skills рядом с проектом, а бизнес-инструмент может предлагать разрешенные агенты для анализа данных.
Для Amazon Quick такой сценарий особенно интересен, если каталог связывается с семантикой данных, описаниями таблиц и правилами доступа. AI-Manual отдельно разбирал Agentic Catalog Experience в Amazon Quick. Связь этой функции с AWS Agent Registry требует подтверждения по официальной документации, как и точное название интеграции.
Даже при наличии встроенного поиска интерфейс должен показывать статус, владельца, разрешения и дату проверки. Кнопка подключения без этих сведений ускоряет действие, но ухудшает контроль.
Единый каталог против дублирования и shadow AI
Отсутствие общей видимости создает две связанные проблемы. Команды повторяют уже сделанную работу, а пользователи подключают внешние или локальные инструменты без обязательной проверки.
Как обнаруживать дубликаты агентов и MCP-серверов
Одинаковое название мало что говорит. Два агента с именем «Помощник поддержки» могут использовать разные модели, иметь разные источники данных и обладать разными полномочиями.
Для сравнения нужны единые поля:
- бизнес-задача и домен;
- входные и выходные данные;
- модели и инструменты, которые вызывает ресурс;
- операции только чтения или операции изменения;
- уровень конфиденциальности данных;
- владелец, окружение и статус поддержки;
- ограничения, SLA и совместимые версии.
Семантическое сопоставление может найти два ресурса для похожих задач, а структурированные поля помогут проверить реальное пересечение. Финальное решение должен принимать владелец домена или платформенная команда, поскольку автоматическое совпадение не доказывает взаимозаменяемость.
Почему shadow AI не исчезает от одного поиска
Shadow AI возникает, когда официальный путь к нужному инструменту слишком медленный, непонятный или ограничительный. Сотрудник подключает внешний сервис, запускает локальный прототип или передает рабочие данные в непроверенный MCP, потому что так быстрее закрыть задачу.
Registry снижает риск при наличии четырех условий: понятная процедура публикации, быстрый discovery, разграничение доступа и регулярный аудит фактических подключений. Нужна и ответственность руководителей сервисов, которые должны знать, какие агенты и интеграции работают в их подразделении.
Каталог без обязательной регистрации shadow AI не устраняет. Он дает точку учета, но не видит ресурс, который сознательно работает вне корпоративных правил.
Как измерять пользу registry
Число карточек мало говорит о качестве. Для оценки результата за квартал можно считать следующие показатели:
- доля ресурсов с назначенным владельцем;
- доля карточек с актуальным review и заполненными полями риска;
- медианное время поиска подходящего компонента;
- число найденных дубликатов и доля проектов, которые выбрали существующий ресурс;
- количество устаревших записей, переведенных в deprecated или archived;
- число интеграций без разрешения и инцидентов, связанных с неправильным доступом.
Полезно фиксировать базовые значения до запуска каталога и сравнивать их с результатами через один или два квартала. Иначе организация рискует измерять активность кураторов вместо реального сокращения времени поиска и числа неконтролируемых подключений.
Метаданные и границы доступа: что нельзя открывать всему предприятию
Хорошая карточка дает достаточно информации для выбора, но не раскрывает внутреннюю архитектуру сверх необходимого. Поля должны иметь собственный уровень видимости, а доступ к ним должен следовать модели RBAC и правилам IAM.
Минимальная схема карточки агента, MCP или skill
| Поле | Зачем нужно |
|---|---|
| Уникальный идентификатор и тип | Позволяют отличать версии, агента, MCP-сервер и skill в автоматизированных процессах |
| Назначение и домен | Помогают искать ресурс по бизнес-задаче и техническому контексту |
| Владелец и команда | Дают контакт для вопросов, инцидентов и пересмотра |
| Версия и окружение | Показывают, какой артефакт работает в development, staging или production |
| Входы и выходы | Позволяют оценить совместимость и риск передачи данных |
| Источники данных и инструменты | Показывают, к каким системам обращается ресурс и какие операции выполняет |
| Требуемые разрешения | Помогают сопоставить компонент с ролями, группами и политиками доступа |
| Внешние вызовы | Фиксируют передачу данных за пределы разрешенного контура |
| Уровень риска и SLA | Задают интенсивность проверки и ожидания по доступности |
| Документация, статус и дата review | Показывают, можно ли использовать ресурс и насколько актуальна карточка |
Какие сведения должны быть ограничены
В общую карточку нельзя помещать токены, пароли, приватные ключи, секреты CI/CD и содержимое секрет-хранилищ. Их место в специализированных системах управления секретами.
Ограниченной видимостью должны обладать private endpoints, внутренние маршруты, подробные схемы чувствительных баз, персональные данные, названия закрытых проектов и инструкции, которые могут расширить доступ пользователя. Для поиска часто достаточно указать класс данных, домен и требуемую роль.
Практично разделить поля на три уровня:
- Общекорпоративные, название, назначение, тип, владелец, статус, совместимость и контакт.
- Ограниченные, конкретные источники, внутренние зависимости, расширенные разрешения, параметры окружения и сведения о рисках.
- Секретные, ключи, токены, персональные данные и содержимое защищенных систем.
Такое разделение не отменяет IAM, сетевые ограничения, DLP и аудит. Registry описывает условия использования, а защитные системы контролируют саму операцию.
Качество данных важнее количества записей
Карточка без владельца превращает любой инцидент в поиск ответственного. Карточка без даты review создает ложное ощущение актуальности. Карточка без ограничений приводит к неправильному подключению даже тогда, когда сам ресурс работает корректно.
Плохо заполненные метаданные вредят семантическому поиску: система подбирает ресурс по общим словам, но не видит различие между чтением данных и их изменением. Пользователь получает ложное совпадение, команда безопасности получает новый ручной запрос, а доверие к каталогу падает.
Ограничения AWS Agent Registry и вопросы запуска
Единый каталог подходит не каждой организации в одинаковом виде. Перед запуском нужно оценить структуру подразделений, требования к конфиденциальности, количество окружений и способность владельцев регулярно обновлять записи.
Когда достаточно одной registry
Один каталог оправдан, если компания использует общую модель метаданных, централизованные требования безопасности и единые правила именования. Такой вариант проще для поиска, аудита и поддержки интеграций с IDE или внутренними порталами.
Единая точка discovery не означает единые права. В одном каталоге могут сосуществовать общедоступные внутренние skills, ресурсы конкретного подразделения и карточки, видимые только security-команде.
Для первого этапа достаточно выбрать один домен, например поддержку или внутреннюю аналитику, описать обязательные поля, назначить кураторов и измерить время поиска. Масштабировать схему стоит после проверки качества карточек и процесса review.
Когда нужны несколько каталогов или федерация
Разделение оправдано, когда подразделения работают с разными регионами, нормативными требованиями, уровнями конфиденциальности или изолированными AWS-аккаунтами. Отдельный каталог может понадобиться для закрытого контура, в котором даже факт существования ресурса нельзя показывать всем сотрудникам.
Федерация соединяет несколько каталогов через общие идентификаторы, правила синхронизации и модель доверия. Пользователь видит доступные ему результаты поиска, а карточка хранит ссылку на авторитетный каталог владельца. Для такой схемы заранее определяют, какой статус считается главным, кто разрешает конфликт версий и как отзываются права между контурами.
Федерация повышает операционные расходы. Появляются задержки синхронизации, дубликаты идентификаторов и вопросы кросс-доменного поиска. Если эти правила не описать заранее, несколько каталогов лишь перенесут исходную проблему на другой уровень.
Что может пойти не так при запуске
- Команды заполняют карточки вручную, и данные расходятся уже после первой версии.
- Владелец отвечает за код, но никто не отвечает за актуальность описания и срок review.
- Подразделения используют несовместимые схемы метаданных и одинаковые идентификаторы.
- Поиск показывает deprecated-ресурсы рядом с разрешенными production-компонентами.
- Сотрудники видят private endpoints, схемы данных или названия закрытых систем.
- Согласование длится дольше создания нового локального прототипа, поэтому команды обходят процесс.
- Описание обещает одну операцию, а фактический MCP-сервер предоставляет более широкие права.
Перед запуском проверьте пять вещей: обязательные поля, владельцев, автоматическую регистрацию из CI/CD, правила видимости и процедуру удаления или ограничения. Конкретные CLI-команды, API, статусы approval workflow, семантический поиск и интеграцию с Amazon Quick нужно подтвердить по актуальной документации AWS. Доступные материалы не дают основания выдавать эти возможности за официальную спецификацию Agent Registry.
Итог: registry полезна только как часть платформенной дисциплины
AWS Agent Registry имеет смысл рассматривать как связку discovery, ownership, governance и lifecycle management. Ее задача состоит в том, чтобы команда быстро находила подходящий AI-агент, MCP-сервер или skill, видела ограничения и получала разрешенный доступ.
Ценность каталога определяется не числом карточек. Нужны актуальные владельцы, единая схема метаданных, проверяемые права, понятные статусы и регулярный аудит. Без этих процессов Registry превращается в еще одну wiki с устаревшими ссылками.
Для небольшой организации достаточно единого каталога с несколькими уровнями видимости. Крупной компании может потребоваться федерация по регионам, бизнес-единицам или закрытым контурам. В обоих случаях сначала нужно подтвердить фактические возможности AWS Agent Registry по официальной документации, а затем связать каталог с IAM, CI/CD, журналами вызовов и процессом security review.