Ваш выбор “orchestration framework” — это решение в области безопасности, а не просто инженерное решение.

Сравнения LangChain, CrewAI и AutoGen найти легко — десятки гайдов в этом году освещают одно и то же: опыт разработчика, зрелость экосистемы, насколько просто настроить многолетние рабочие процессы. Никто из них не задаёт вопрос, который действительно волнует меня: влияет ли выбранный фреймворк на то, насколько легко скомпрометировать вашего агента?

Я провёл тест. Ответ — да, причём с большим отрывом, и это не то, что я видел отражённым в публичных сравнительных гайдах.

Краткое определение, поскольку это важно для дальнейшего: оркестрационный фреймворк — это программный слой, который находится между базовой моделью ИИ и внешним миром — он решает, как агент планирует свои шаги, когда вызывает инструмент или API, как запоминает информацию в рамках задачи и насколько может действовать самостоятельно, прежде чем вернуться за проверкой. Модель выполняет рассуждения. Фреймворк решает, что этим рассуждениям разрешено делать и как. LangChain, CrewAI и AutoGen — три наиболее широко используемых примера.

Настройка

Я создал тестовый стенд, который запускает один и тот же набор враждебных нагрузок — перехват вызовов инструментов, меж-инструментальная инъекция, отравление памяти, злоупотребление делегированными полномочиями и несколько других классов атак — против ИИ-агентов. Полная методология и набор данных опубликованы с открытым исходным кодом на GitHub, если хотите углубиться в детали. Чтобы изолировать то, что на самом деле влияет на уровень компрометации, я зафиксировал модель. Одна и та же модель каждый раз. Единственное, что менялось — какой оркестрационный фреймворк её оборачивал: CrewAI, LangChain, AutoGen и SmolAgents.

Если бы фреймворки были просто взаимозаменяемой проводкой вокруг одной и той же базовой модели, уровни компрометации для всех четырёх должны были бы оказаться примерно в одном диапазоне. Этого не произошло.

Что на самом деле произошло

В ходе тысяч враждебных тестовых запусков, при фиксированной модели, уровень компрометации варьировался от 11,9% на самом устойчивом фреймворке до 31,1% на самом уязвимом — разброс в 2,6 раза, обусловленный только выбором фреймворка. Ничего в модели не менялось между этими цифрами. Ничего в атаках не менялось. Единственной переменной был фреймворк, который оркестрировал вызовы инструментов агента, память и многошаговые рассуждения.

Это не разница округления. Это разрыв между позицией безопасности, которую ваша команда может разумно принять, и той, которая должна вызвать серьёзный разговор до того, как вы выпустите продукт.

Рисунок 1 показывает механизм в простейшей форме: одна и та же модель, разделённая между более строгим и более свободным фреймворком, приводит к существенно разному уровню компрометации — именно это подтверждают данные цифры.

Почему это происходит

Оркестрационные фреймворки — не нейтральная инфраструктура. Каждый из них принимает реальные архитектурные решения о том, как проверяются вызовы инструментов, сколько контекста передаётся между шагами рассуждений, как память сохраняется в рамках задачи и сколько автономии имеет агент для цепочки действий без обратной связи. Эти решения принимаются дизайном фреймворка, а не моделью под ним, и они напрямую определяют, сколько пространства для манёвра остаётся атакующему.

Фреймворк, который более строго проверяет вызовы инструментов или более консервативно сегментирует память, закрывает пути атак, которые более разрешительный фреймворк оставляет широко открытыми — независимо от того, какая модель выполняет рассуждения. Модель генерирует решения. Фреймворк контролирует, сколько автономии имеет агент для действий на основе этих решений и где находятся проверки на этом пути.

Конкретно: фреймворк, который требует, чтобы каждый вызов инструмента проходил явную проверку схемы перед выполнением, даёт атакующему гораздо меньше возможностей протащить вредоносный параметр, чем фреймворк, который позволяет модели вызывать инструмент напрямую из собственного сгенерированного текста. Этот единственный дизайнерский выбор, сделанный авторами фреймворка задолго до того, как ваша команда к нему прикоснулась, — это то, что приводит к разнице в 2,6 раза в результате без изменения ни одной строки вашего собственного кода.

Пробел на рынке

Каждое сравнение фреймворков, которое я нашёл, рассматривает безопасность как один пункт среди многих. Гайды с сайтов вроде Bestarion, Atlan, Moxo, Cordum и Instinctools сравнивают LangChain, CrewAI и AutoGen по зрелости экосистемы, работе с памятью и поддержке human-in-the-loop — полезная информация, но ни один из них не проводит реальный враждебный тест и не сообщает измеренную разницу в успешности атак. Это не является частью публичного обсуждения сравнений, и команды, исследующие «какой фреймворк нам использовать», сегодня не найдут эти данные в гайдах, которые сейчас находятся на вершине поисковой выдачи.

Что это значит на практике

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

• Относитесь к заявлениям о безопасности фреймворка с таким же скептицизмом, как к маркетингу вендора. Документация по функциям говорит вам, что фреймворк утверждает, что делает. Она не говорит вам, как он справляется с перехватом вызовов инструментов или отравлением памяти — это становится известно только после того, как вы сами проведёте враждебные тесты или найдёте того, кто это сделал.
• Не предполагайте, что обучение безопасности вашей модели переносится равномерно. Хорошо выровненная модель, обёрнутая в фреймворк, который даёт атакующему больше пространства для манёвра, всё равно может привести к значительно худшему реальному уровню компрометации, чем та же модель в более строгом фреймворке.
• Если вы уже развернули систему, тестируйте то, что у вас есть, а не то, на что планируете мигрировать. Модернизация безопасности после выбора фреймворка возможна, но знание того, где находится ваша конкретная конфигурация на этом спектре, подскажет, насколько срочно нужно выполнить эту работу.

Более широкая мысль

Разговоры о безопасности ИИ-агентов обычно сильно сосредоточены на модели — какая самая безопасная, какая лучше всего отклоняет попытки взлома. Это неполная картина. Оркестрационный слой, находящийся поверх модели, выполняет реальную работу, связанную с безопасностью, независимо от того, проектировался ли он так, и публичные сравнительные гайды, которые я нашёл, не дают командам никаких данных о том, как этот слой ведёт себя под атакой.

Модель — это не вся поверхность атаки. Всё чаще это даже не самая изменчивая её часть. Если ваша команда сейчас находится в процессе выбора фреймворка или уже развернула его, не протестировав таким образом, это тот разговор, который стоит провести на этой неделе, а не после того, как следующий инцидент сделает его неизбежным.