Представьте, что вы скачали приложение на телефон, затем установили его на планшет, а потом оно появилось в каком-то маркетплейсе под немного другим названием. Это одно и то же приложение, но с точки зрения большинства систем учёта – это три разных объекта. Примерно та же проблема сейчас существует в мире ИИ-агентов, и она становится всё острее по мере того, как агенты начинают использоваться не сами по себе, а в связке с десятками подключаемых модулей – так называемых навыков (skills) или плагинов.
Что вообще такое навык агента?
Если ИИ-агент – это автономная система, которая выполняет задачи и принимает решения, то навык – это конкретная функция, которую он может вызвать. Поиск в интернете, отправка письма, получение данных о погоде, бронирование встречи – всё это отдельные навыки. Агент как бы «подключает» их к себе, чтобы расширить свои возможности.
Звучит удобно. Но возникает вопрос: как система понимает, что именно этому навыку можно доверять? И как она определяет, что навык из одного источника – это то же самое, что навык из другого источника, просто упакованный иначе?
Сейчас – почти никак. И это серьёзная брешь в инфраструктуре.
Имена – плохие идентификаторы
Логичный первый ответ: ну давайте идентифицировать навыки по названию. «Навык поиска» везде называется «навыком поиска» – в чём проблема?
Проблема в том, что имена нестабильны и легко подделываются. Один разработчик может назвать свой навык так же, как называется популярный доверенный модуль, – случайно или намеренно. Названия меняются при обновлениях, при переносе на другую платформу, при публикации в маркетплейсе. Два одинаково названных навыка могут делать совершенно разные вещи. И наоборот – один и тот же навык может встречаться под разными именами в разных экосистемах.
Проще говоря, имя – это этикетка на упаковке, а не описание содержимого.
Что предлагают исследователи
Исследователи из Gen Digital предложили подход, который они называют «отпечатком навыка» (skill fingerprint). Идея в том, чтобы идентифицировать навык не по его имени или месту хранения, а по тому, что он реально делает – по его содержимому.
Если коротко: берётся смысловое описание навыка (что он принимает на вход, что возвращает, какую функцию выполняет), и на основе этого описания формируется уникальный числовой «слепок». Этот слепок остаётся стабильным, даже если навык переименовали, перенесли на другую платформу или переупаковали. Изменилась суть – изменился отпечаток. Суть та же – отпечаток тот же.
Технически это реализуется через так называемые векторные представления текста – способ превратить смысл описания в числа, с которыми можно работать математически. Но детали реализации здесь не главное. Важна сама идея: идентичность навыка определяется его функцией, а не его именем или адресом.
Зачем это нужно на практике?
Допустим, агент работает в корпоративной среде и использует набор одобренных навыков. Кто-то подключает к нему новый модуль – с виду безобидный, с похожим названием. Без системы идентификации агент не имеет надёжного способа проверить, тот ли это навык, которому был выдан доступ, или нечто другое, замаскированное под него.
С отпечатком – другая история. Система может сравнить функциональный слепок нового навыка с теми, что уже есть в доверенном реестре, и понять: это дубликат известного модуля, это вариация с изменёнными деталями, или это что-то принципиально новое, требующее проверки.
Это полезно сразу в нескольких сценариях:
- Безопасность. Злоумышленники могут создавать навыки, которые имитируют доверенные, – примерно как фишинговые сайты имитируют настоящие. Отпечаток по содержимому делает такую подмену заметной.
- Управление версиями. Если навык обновился (изменилось поведение или интерфейс), это будет отражено в изменении отпечатка. Можно отслеживать, что именно поменялось и насколько критично.
- Переносимость между платформами. Один и тот же навык, опубликованный в разных маркетплейсах или экосистемах, можно будет однозначно идентифицировать как один и тот же объект – без ручной сверки документации.
- Аудит и соответствие требованиям. Организации, которые должны контролировать, какие инструменты используют их ИИ-системы, получают механизм для этого контроля.
Почему это важно именно сейчас
Экосистема ИИ-агентов развивается стремительно. Ещё недавно агент был, по сути, отдельным инструментом с фиксированными возможностями. Сейчас всё больше систем строится по модульному принципу: агент плюс набор подключаемых навыков, которые можно менять, обновлять, брать из разных источников.
Это очень удобно с точки зрения гибкости. Но инфраструктура доверия за этим не успевает. Нет стандартного способа сказать: «этот навык – именно тот, которому я доверяю, а не его двойник». Нет реестра, который работал бы поверх платформ. Нет механизма, который позволял бы системе самостоятельно распознавать знакомый навык в новой упаковке.
Отпечаток навыка – это попытка создать такой механизм. Не надстройку над конкретной платформой, а универсальный способ говорить об идентичности функции вне зависимости от того, где и как она упакована.
Открытые вопросы
Подход интересный, но вопросы остаются.
Во-первых, насколько стабильны такие отпечатки при незначительных изменениях описания? Если разработчик переформулировал документацию к навыку, не меняя его функцию, – система должна понять, что это всё ещё тот же навык. Это нетривиальная задача.
Во-вторых, кто ведёт реестр? Отпечаток сам по себе – это инструмент сравнения, но для полноценной системы доверия нужна ещё инфраструктура: кто-то должен собирать, верифицировать и хранить эти отпечатки. И здесь возникают вопросы централизации, управления и доверия уже к самому реестру.
В-третьих, описание навыка можно намеренно составить так, чтобы оно было похоже на описание другого навыка, и получить похожий отпечаток. Это потенциальный вектор для более изощрённых атак, который тоже нужно учитывать.
Наконец, для того чтобы система заработала на практике, нужно, чтобы разработчики платформ и маркетплейсов её приняли. Без широкого распространения даже хорошо продуманный стандарт остаётся академическим упражнением.
Но само направление мысли – дать навыкам агентов стабильную, содержательную идентичность – выглядит как то, без чего зрелая экосистема агентных систем обойтись не сможет. Рано или поздно этот вопрос придётся решать. Хорошо, что его уже начали формулировать.
