Мы долго ждали идеальный искусственный интеллект, который сам разберет почту, закроет тикеты и заменит половину отдела. Но реальность оказалась суровее: модели по-прежнему галлюцинируют, автономные агенты при любой возможности норовят выполнить команду на удаление системы, а на смену восторгам от параметров огромных LLM пришла жесткая инженерная дисциплина. Встречайте эпоху stateful-агентов и инфраструктурных костылей.
В этом интервью мы поговорили с Chief AI ArchitectАндреем Носовымо феномене OpenClaw, который набрал популярность на GitHub быстрее, чем Linux. Мы честно обсудили, как обуздать недетерминированный хаос с помощью Kafka и Pydantic-схем, зачем нужен трейсинг естественного языка, в каких случаях подход Human-in-the-Loop спасает жизни.
Видео интервью можнопосмотреть по ссылке, а задать вопросы спикеру и обсудить - в телеграм-каналеAi4Devв котором уже 5 000 разработчиков.
«OpenClaw ударил в самое сердце»
За три месяца OpenClaw набрал 250 тысяч звезд на GitHub — это больше, чем Linux за все свои годы. При этом только за февраль в проекте закрыли более 40 уязвимостей. Это нормальная цена за скорость разработки, или мы наблюдаем системную проблему, когда агентные фреймворки выходят в свет без базовой инженерной безопасности?
OpenClaw, естественно, отразил все ожидания рынка от недетерминированных систем. С вероятностными моделями всегда было сложно: трудно продать бизнесу то, что со временем будет деградировать и дрифтовать. Вы продали систему сегодня, она отвечает одним образом, а завтра — совершенно иначе, и никаких гарантий стабильности нет. Именно поэтому все всегда стремились обуздать вероятностные системы с помощью классической инженерной обвязки. И здесь OpenClaw попал в самое сердце.
Не скажу, что это самая устойчивая или надежная инфраструктура, но они идеально угадали с ожиданиями. Настолько идеально, что если уж мы говорим о противопоставлении с таким гигантом, как OpenAI, то последние буквально на второй месяц наняли создателя OpenClaw, и сейчас он работает у них. Поэтому противостояния между этими стартапами уже нет — они объединили усилия.
К чему это приведет? Очевидно, что инфраструктурная обвязка продолжит развиваться. Именно на нее бизнес делает ставку, и именно к ней привязываются метрики. Вспомним 2025 год: это было время появления фреймворков для оценки и тестирования, таких как Ragas, DeepEval и Arize Phoenix. Они позволили хоть как-то держать LLM в узде с помощью подхода LLM-as-a-Judge. Для подтюнивания промптов появился DSPy, а для адаптивного редтиминга — свои фреймворки, вроде DeepNote.
Но сейчас на сцену выходят решения на базе DAG, и stateless-системы постепенно становятся stateful. Это значит, что простые цепочки вызовов мы меняем на распределенную обвязку. Появляются агенты, и мы учимся управлять ими за счет обычных детерминированных систем.
OpenClaw пошел еще дальше. Он предложил не только обвязку, но и кучу различных коннекторов. Понятно, что под капотом это обычный SDK, который инженеры и так постоянно пишут для унификации разработки, снижения количества багов и технического долга. Так вот, OpenClaw ударил в самое сердце: он не только дал бизнесу детерминированную надежду, но и пообещал разработчикам избавить их от техдолга.
А ты веришь в перспективность OpenClaw? Говоришь так, будто сомневаешься, что он долго проживет.
История здесь такая: под OpenClaw нет фундаментальной инженерии. Это инженерия коннекторов и связок. Скорее всего, со временем он уступит место более серьезным архитектурным решениям — шинам событий и прочим вещам, которые действительно выдерживают большие нагрузки в продакшене. Вспомним, на чем написан OpenClaw: это TypeScript. Естественно, куча его клонов сейчас переписывается на более надежные языки, чтобы повысить стабильность и масштабируемость. Так что OpenClaw — это мощная «ласточка», которая пробивает тоннель, но в итоге уступит место фундаментальным технологиям.
Так стал ли OpenClaw безопасным? И вообще, насколько безопасно давать агентам такую свободу? Раньше мы боялись случайно слить информацию в обычные чат-модели, а теперь фактически позволяем ИИ самостоятельно выполнять довольно сложные и глубокие задачи.
Давайте вспомним 2025 год, когда тема безопасности только начала всерьез развиваться на системном уровне. Появились регламенты, такие как OWASP Top 10 для LLM и агентов. Само осознание того, что нейросети требуют специфической защиты, — довольно свежее веяние.
Методы защиты здесь общие для всех. Был бы у нас не OpenClaw, а прямое хождение по API в Claude, мы бы имели ровно те же проблемы. Базовый метод защиты — это закрытая песочница, обеспечивающая строгую изоляцию. Второй метод — кодирование и декодирование входящих потоков. Третий — изоляция внешних интерфейсов, которые могут жить как отдельные микросервисы.
Что касается безопасности OpenClaw: почему крупнейший банк страны, Сбер, еще в начале февраля развернул его у себя в контуре и стал использовать в open-source, если всё так плохо? Потому что они использовали изолированные песочницы. Более того, в марте Сбер стал единственным обладателем сертификатов безопасности уровня 99,9% на системы с OpenClaw.
Это обычная инженерная система, которую нужно защищать. Просто когда разработчики выпустили ее в релиз, они не озаботились защитой по умолчанию. Естественно, хорошие взломщики быстро нашли уязвимости, сделали на этом огромный черный пиар, и на этом всё.
Неделю назад на Хабре вышластатьяс кейсом, где три агента заменили отдел из пяти человек с конкретными метриками пилота. И автор написал: «Инструменты важнее параметров. Агент с доступом к 1С и почте полезнее модели на 100 миллиардов параметров без интеграции». Вы согласны с тем, что модели действительно стали просто расходным материалом?
На текущий момент модели являются не исполнителями, а декораторами. Они отвечают за форму ответа, а не за его содержание. В этом ключевое отличие.
Как работает обычная декодерная генеративная модель? Она просто предсказывает следующий токен, следующее слово. Она нанизывает слова одно за другим, создавая такую длинную нить из вероятностно предугаданных «бусин». Но эта вероятность нестабильна: каждый раз мы нанизываем эти «бусины» немного по-разному.
Поэтому назвать модели «расходным материалом» у меня просто не поднимается язык. Это прекрасный декоратор, помогающий доносить информацию до людей на их языке. Всегда идет борьба между формой и содержанием. За содержание бьются в критичных отраслях — медицине, юриспруденции, финансах — где искажение фактов ведет к прямым потерям. А там, где важна именно форма, декоратор выходит на первый план. В первую очередь генеративные модели сейчас активно влияют на искусство, кинематограф, музыку, театр и литературу.
Разработка программного обеспечения вроде бы не относится ни к музыке, ни к кино, но на эту область искусственный интеллект тоже активно влияет. Впрочем, я хочу немного поправиться: многие эксперты вообще не считают современные модели настоящим искусственным интеллектом. Нас много раз поправляли, что сейчас мы имеем дело не с ИИ, а с ИИИ — имитацией искусственного интеллекта.
Это правда. Просто потому, что форма сама по себе содержания не имеет. Вернее, ее содержание жестко ограничено данными до определенного года обучения. Тот же Gemini, выпущенный совсем недавно, оперирует знаниями только до начала 2025 года. Это содержание, замкнутое в историческом контексте, а не реальное мышление.
Что касается написания кода — здесь отдельная история. Код начал активно развиваться как формальный язык примерно с 1970-х годов. Промоутером всей этой концепции был Ноам Хомский — лингвист, который работал с формой языка и заложил основы генеративной грамматики и теории формальных языков (спикер, вероятно, имеет в виду иерархию Хомского и ее влияние на создание языков программирования, -прим.ред). Так начали появляться языки программирования один за другим. Грамматика — это, по сути, формальное представление языка. И в итоге всё сводится к тому, что код — это тоже структура, которую можно успешно генерировать, работая исключительно с формой.
В архитектуре OpenClaw выделяют пять компонентов: шлюз, мозг, память, навыки и «сердцебиение» (heartbeat). По сути, это классическая микросервисная архитектура, но «мозгом» в ней выступает языковая модель, которая принимает недетерминированные решения. Как вообще проектировать систему, где центральный узел по определению непредсказуем?
Звучит, возможно, пугающе, но на самом деле всё очень просто. Пути валидации никто не отменял. Если ваш «мозг» отрабатывает не так, как нужно, у вас есть контрольные точки.
Например, Pydantic-схемы, в которые закладываются жесткие форматы нужного или ненужного вывода. Если модель отвечает некорректно, применяется паттерн retry — мы просто просим ее сгенерировать ответ заново, в другой форме. И пока мы не добьемся строгого соответствия схеме, процесс дальше не пойдет.
Второй способ — это подход Human-in-the-Loop (HITL), участие человека в цикле. Это фундаментальный принцип, без которого ИИ сегодня превращается в опасную или бесполезную болванку. По сути, это финальное одобрение действий. ИИ выполняет цепочку задач, но конечное решение — нажать кнопку «Одобрить» или «Отклонить» — остается за человеком.
Почему эта неказистая схема, где нужно постоянно держать руку на пульсе, стала стандартом в отрасли? Потому что эксклюзивным обладателем контекста «здесь и сейчас» является только человек. Представьте медицинскую систему: она обоснованно принимает решение об операции. Прошли миллионы проверок (retry), все документы соответствуют схемам. Но вдруг в моменте приходят свежие анализы с противопоказаниями, и операцию нужно срочно отложить. У системы этих данных еще нет. В таком случае только ручное нажатие кнопки человеком спасет пациенту жизнь.
«Модели приходили к радикальным выводам — вплоть до уничтожения человечества»
Но почему нельзя автоматизировать и этот момент? Входящий документ с новыми анализами попадает в систему, и она всё пересчитывает. Зачем нужен человек, который просто сидит и ждет экстренной ситуации? Почему мы всё еще цепляемся за Human-in-the-Loop? Ведь все инвесторы Кремниевой долины стремятся к обратному: исключить дорогостоящего человека из процесса и добиться полной автоматизации. В чем проблема отпустить систему в свободное плавание?
Проблема в том, что если ИИ начнет принимать решения абсолютно автономно, он может прийти к выводу, что человек в этой системе не нужен вообще. И такие решения выкинут нас не только из бизнес-процессов, но и, грубо говоря, из этого мира.
Подобное уже случалось в ранних экспериментах Microsoft: когда моделям давали полную свободу саморазвития, они, опираясь на холодную логику, приходили к радикальным выводам — вплоть до уничтожения человечества. И это не сценарий «Терминатора». Дело в том, что история людей — это не строгая логическая цепочка. Наша жизнь завязана на эмоциональном интеллекте, иррациональных поступках и моментальном контексте. Всё это абсолютно не стыкуется с жесткой логикой выводов ИИ, который обучался на исторических паттернах, не всегда релевантных текущей секунде.
Нам невыгодно отпускать искусственный интеллект в свободное плавание. Human-in-the-Loop — это ведь не просто тупое нажатие кнопки. Это переход человека на стратегический уровень мышления. Оператор начинает оперировать совершенно другими абстракциями, удерживая в голове глобальную картину. Это как переход от механического забивания гвоздя к пониманию архитектуры всего дома.
Я могу ошибаться, но мне кажется, что рынок так позитивно воспринял OpenClaw именно потому, что фреймворк дал больше степеней свободы. Люди ставили агентов на отдельные серверы, те сами проверяли почту, выполняли какие-то задачи и просто присылали уведомления. Все мечтают о собственном аналоге Джарвиса из «Железного человека» — системе, которая делает всё сама. И когда появился OpenClaw, многие решили: вот он, долгожданный шаг к полностью автономной модели! А ты говоришь, что всё должно работать только под наблюдением, в защищенном периметре и с «кнопкой контроля».
Если отвечать с конца: при полной автономности человека в этой системе просто не останется. А если вспомнить Джарвиса из «Железного человека» — помните, как Тони Старк включал и выключал его, когда ему было нужно? У него всегда была эта условная кнопка. Да, мы можем регулировать степень свободы агента: отпускать «поводок» подлиннее или натягивать покороче, чтобы испытывать максимальный комфорт и делегировать рутину. Но контроль всё равно должен быть: не интеллект управляет нами, а мы — интеллектом.
Такова человеческая природа. На мой взгляд, ИИ нельзя отпускать в свободное плавание никогда, в этом нет никакого практического смысла. Задумайтесь: а какая вообще финальная цель в том, чтобы отпустить систему на 100%?
Цель — скорость в критических ситуациях. Например, проведение операций, скрининг медицинских параметров. Там, где счет идет на секунды, машина справится очевидно быстрее. Разве мы не можем отдать на откуп ИИ хотя бы эту сферу? Внедрить OpenClaw в госпиталь, позволить роботам самостоятельно делать операции.
В этой цепочке всегда должен стоять человек. По одной простой причине: возвращаясь к примеру с операцией, врач может обладать критически важным сторонним контекстом. Например, он знает, что через минуту в здании планово отключат свет. У ИИ такой информации нет. И человек, обладая полнотой картины, примет более адекватное и безопасное решение.
Что касается скорости: мы сейчас переживаем кратное ускорение процессов во всех сферах. Я, например, уже не мыслю свою работу без нейросетей. Те сложные задачи, на которые раньше уходила неделя, я сейчас решаю за 15 минут. Но всё это — при наличии кнопок контроля, валидации и надежной инженерной обвязки! Иначе решения, сгенерированные машиной без верификации, просто не убедят конечного пользователя или бизнес.
Наверное, мы сейчас перешли от технологий к философии. Я абсолютно не ретроград, технологии — это моя стихия. Но я твердо уверен: мощный ИИ без кнопки контроля в руках человека — это большая ядерная бомба с самовзрывателем.
В одной из статей на Хабре автор описывает правильный подход к архитектуре: агент работает не на вашей локальной машине, а изолированно, в контейнере на сервере. Если ему нужно отправить письмо, он обращается к отдельному микросервису, где хранятся настоящие учетные данные. Насколько это реализуемо в среднестатистической компании, где на 50 разработчиков приходится всего один DevOps?
Это совсем не сложно! Сейчас это работает по принципу аренды автомобиля, или даже проще. Существуют облачные платформы, предоставляющие всё это как готовый сервис. Вы платите абонентскую плату и пользуетесь системой так же просто, как Алисой от Яндекса. У вас есть изолированная песочница, свой собственный ИИ на базе OpenClaw, и никаких инфраструктурных проблем.
Причем вы можете гибко настраивать аутентификацию. Например, платформа Composio предлагает тысячи готовых интеграций, которые надежно закрывают уязвимости с математической точностью. Никакой «дата-пойзонинг» (data poisoning) или промпт-инъекции до ваших внутренних систем просто не доберутся. Оплачивая такой сервис, который хостится, допустим, на AWS за 50 долларов в месяц, вы экономите ресурсы целого отдела DevOps. Это работает как надежная страховка, которая сразу и целиком покрывает все ваши риски безопасности.
Можно ли сказать, что минимальная обвязка агента должна полностью блокировать доступ к файлам, где хранятся токены и ключи? И почему Cloud Code позволяет такой доступ в режиме skip permission?
Я здесь придерживаюсь философии платформы Red Hat AI. Они делают специальный API-шлюз Quadrant, не путать с векторной базой Qdrant, в котором заложена масса дополнительных политик, интегрирующих проверку по JWT-токену. Как работает проверка по JWT-токену? Вы, как пользователь, всегда отправляете дополнительный токен, и только после этого получаете различные права и доступы. Этот доступ регулируется прямо на уровне API-шлюза. Даже если вы очень сильно захотите с кем-то поделиться своими данными, на уровне шлюза будет стоять Open Policy Agent, который заблокирует это действие. Я бы с удовольствием показал в коде, как это функционирует, потому что работает это действительно забавно. Ты вроде сделал всё, чтобы сломать защиту и отдать свои собственные данные даром, а этот агент на выходе тебя останавливает. Получается, что тебя охраняют сами агенты.
«Моя рекомендация — всегда смотреть в сторону атомарности»
Агент для выполнения одной задачи может вызвать десятки инструментов. Каждый такой вызов — это обращение к языковой модели, которая выдает результат на естественном языке. Классический трейсинг заточен под структурированные данные. Как построить наблюдаемость для системы, где половина данных — это свободный текст?
Это классный вопрос. Если вы строите систему трейсинга, допустим, на базе OpenTelemetry, то всё обстоит именно так, как вы перечислили. Но для современных систем, причем не только агентных, но и GenAI в целом, существует несколько профильных фреймворков для распределенного трейсинга. Они позволяют отслеживать отдельные трейсы по каждому агенту, объединять промпты и фиксить ошибки. Их на самом деле много. Есть Langfuse — это отличный бесплатный open-source инструмент. Далее можно назвать Arize Phoenix, который работает с кэшем в памяти. Также есть LangSmith, но он преимущественно платный, это надстройка над платформой LangChain, позволяющая работать в связке достаточно нативно. За счет этих платформ вы можете выстраивать трейсинг в виде определенных деревьев. Парсить эти деревья вручную уже не нужно, они выстраиваются автоматически и подсвечивают узлы по заданным вами метрикам. Вы сразу видите, где происходит просадка производительности, где появляются странные, возможно инъектированные, данные, или где ответ не проходит валидацию по Pydantic-схеме. Таким образом, на уровне фреймворка вы контролируете не только поток трейсов, но и сам промптинг, а также Guardrails, выставленные на входе и на выходе. Но самое главное — вы контролируете дата-дрифт. Любая модель начинает деградировать с момента своего старта. Инструменты трейсинга позволяют вам постоянно подтюнивать систему, держать ее в тонусе, чтобы этот дата-дрифт не происходил хаотично, и поддерживать модель на заданном уровне качества.
Смотрите, если мы берем агентный трейсинг, то каждая итерация агента логируется с привязкой к уникальному идентификатору сессии. Этот лог объединяет изначальный промпт, внутренний монолог агента в режиме thinking, параметры вызова внешнего API и ответ самого инструмента. Это покрывает абсолютно всё, что присутствует у агента в данный момент. Если таких инструментов несколько, данные приходят просто в виде вложенного JSON. Разбирая сам трейс на этом уровне, мы уже можем получать определенные инсайты по каждому из инструментов и выверять отдельные метрики. Плюс-минус так это и работает. Единственное ограничение заключается в том, что у одного агента на сегодняшний день может быть много инструментов, но в распределенной системе так лучше не делать. Обычно используется жесткая привязка: один агент — один инструмент. Система еще способна неплохо справиться с конфигурацией, где на одного агента приходится множество инструментов, так как чисто математически усложнение получается небольшим. Но как только мы начинаем применять геометрическую прогрессию, одновременно наращивая число недетерминированных агентов и их инструментов, контролировать это становится вычислительно очень дорого. Поэтому моя рекомендация — всегда смотреть в сторону атомарности. Ее гораздо удобнее и дешевле отслеживать и контролировать.
Можно ли использовать в государственных органах агентов, работающих на национальных LLM, если они вдруг могут выдать инструкцию удалить всё? Поможет ли обвязка в таких ситуациях?
Команда удалить всё — это классическая промпт-инъекция. От подобных угроз обычно защищаются на входе и на выходе. Даже если на входе мы не распознали саму инъекцию и пропустили опасный запрос в модель, то на выходе мы обязательно сможем отловить его с помощью как минимум трех ступеней защиты. Допустим, система пытается выполнить команду rm -rf. На первом рубеже, базовом Guardrail, мы можем поймать это просто обычной регуляркой. Если отловить регулярным выражением не удалось, в дело вступает семантический фильтр. С его помощью мы оцениваем смысловую близость и понимаем, что пришло нечто, похожее на деструктивную команду, даже если злоумышленник замаскировал синтаксис. Если и семантика не сработала, существует третий рубеж — это отдельная контролирующая LLM, которая оценивает ответ уже по прагматике. Таким образом, мы прогоняем данные через разные фильтры. На практике это выглядит забавно, и я бы тоже хотел показать это в коде. Иногда разработчики путают слои местами и ставят Guardrail на базе большой LLM на первое место. Поскольку модель вероятностная, она может время от времени пропускать опасный запрос. В этот момент кажется, что защита пробита и всё пропало, но последующие детерминированные фильтры сдерживают этот поток и блокируют действие.
А что если агент ошибся, и бизнес потерял деньги. Регулятор или руководство требует показать, почему система приняла такое решение. Является ли цепочка рассуждений модели, так называемый chain of thought, реальным объяснением, или это просто иллюзия? Вообще, можно ли провести честный разбор полетов для языковой модели, и если да, то как это сделать?
Вспомните статью исследователей из Apple от 20 июня 2025 года. В своих экспериментах они наголову разбили концепцию ризонинга у DeepSeek. Они прямо заявили, что это маркетинговая обвязка, не имеющая ничего общего с реальным мышлением. У модели есть стохастическая природа: она просто генерирует следующий токен, а всё остальное — исключительно маркетинг. Как же тогда вообще говорить об объяснимости модели, если это одно из главных требований к ИИ-системам? Здесь всё решается довольно просто с помощью различных типов метрик, за которые отвечают фреймворки вроде DeepEval, Ragas или того же Arize. Вы берете Golden Dataset, который служит бенчмарком для сравнения с эталонным ответом, и привязываете к нему ряд метрик. Объяснимость ответа складывается именно из этих показателей. Если вам нужно понять, почему система приняла конкретное решение, вы просто смотрите на эти метрики. К ним относятся faithfulness, определяющая уровень достоверности и отсутствие галлюцинаций, context precision для оценки точности извлечения контекста, context relevance, отражающая релевантность контексту, а также точность по отношению к целевому запросу. За счет этих математических метрик и формируется реальная объяснительная сила. В дальнейшем эту информацию можно преобразовать в готовый текст. Подчеркиваю: именно сгенерировать форму ответа-объяснения.
На Хабре мы нашли статью, где автор пишет, что если в один сервер встроить слишком много агентов, теряется контроль, и удачная инъекция в промпт разносит всю систему. Он предлагает использовать движки бизнес-процессов, вроде Camunda, для маршрутизации между агентами. Есть ли смысл скрещивать классические движки процессов с агентными системами? Или это попытка натянуть вчерашние паттерны на завтрашнюю архитектуру?
Нет, это нужно рассматривать не совсем с такой точки зрения. Вообще подход на сто процентов верный. Но то, как он объяснен, действительно звучит так, будто кто-то кого-то натягивает. Здесь история немного о другом. У всех есть желание, чтобы генеративный искусственный интеллект работал эффективно, но при этом был максимально объяснимым, чтобы мы могли ему доверять. Вероятностные системы недетерминированы, они постоянно изменяются, и это не дает нужной объяснимости. А что ее дает? Классическая разработка, где есть микросервисы и шины событий. Это обвязки, которые прошли огонь и воду и уже работают детерминированно и надежно. И что мы делаем, чтобы добавить модели эту маленькую изюминку детерминированности? Как раз то, что сделал OpenClaw. Мы строим инженерную обвязку из уже сложившихся паттернов. Я еще осенью говорил о том, что взаимодействие агентов через шину событий и атомарность всех выполняемых ими действий несомненно ведут к росту точности. Так оно и происходит. Сегодня наиболее точные системы работают именно через шину событий. Мы можем посадить на ту же Kafka до тысячи агентов, и она их выдержит. Более того, контекст при этом не будет теряться благодаря персистентности: мы «завешиваем» событие, и пока оно не будет выполнено, агенты работают как солдатики. Один упал — второй встал на его место и делает задачу. При этом мы не теряем динамичности системы: если какой-нибудь агент сломался и больше не отвечает, его просто заменяет другой.
В марте 2025 года вышла стабильная версия протокола межагентного взаимодействия от Google — A2A, который теперь поддерживают больше 50 компаний и курирует Linux Foundation. Есть также протокол от Anthropic для связи агентов с инструментами. Мы движемся к единому стандарту или к очередным войнам форматов, как это было с контейнерными оркестраторами десять лет назад?
Различные протоколы, такие как A2A или MCP, выступают в роли прослоек для унификации. В архитектуре это называется фитнес-функциями. Это то, что дает системе гибкость. К таким функциям могут относиться, например, различные роутеры, помогающие избежать ситуации vendor lock-in. Они позволяют автоматически переключаться между несколькими моделями: если одна модель не отвечает, запрос уходит ко второй, и путем такого перебора мы достигаем нужной реакции. Протоколы тоже являются фитнес-функцией, но немного иного плана. Они обеспечивают унификацию обращения к определенным сервисам и подключение инструментов, используемых нашими агентами. Если бы протоколы были разными, нам бы приходилось каждый раз писать интеграции с нуля. Что это значит для языковой модели? Представьте, что модель имеет закрытое признаковое пространство — она обучена, например, на данных до 2025 года. В ней лежат все спецификации языка Python, предназначенные для оптимизации производительности моделей на инференсе. Но сегодня на первое место вышел язык Rust, а его в базах старых моделей нет, или во всяком случае не так много, как Python. Что в таком случае будет генерировать модель? Конечно же, она превратится в бредогенератор, а мы будем жаловаться на ее качество. Так вот, возвращаясь к фитнес-функциям: задача единых протоколов — создать буфер и сдерживать хаос за счет гибкости обращения к инструментам, пока модель не дообучится. Но здесь есть и оборотная сторона. При использовании в продакшене каждый протокол, будь то MCP или A2A, добавляет задержки — latency. Для решений, работающих в real-time, задержки в три-пять секунд, которые может давать MCP, критичны. Представьте, что вы говорите по телефону, а собеседник отвечает вам с пятисекундной паузой.
Обвязка с механизмами проверки ведь сильно замедлит отзывчивость агента. Или здесь есть какой-то компромисс?
Давайте пройдемся по обвязкам и посмотрим, какими они бывают. Например, существует обвязка со скраббингом — это анонимизация данных, когда вы навешиваете теги, чтобы модели было понятно, с каким объектом она имеет дело, но при этом полностью скрываете реальную информацию. Вместо «Иван Иванович» вы вешаете тег «Person». Не просто маскируете, а именно тегируете. Так вот, подобная операция на объеме до миллиона токенов выполняется за миллисекунды. Да, это latency, но в пределах допустимого. А вот если мы внедряем шифрование на уровне поисковых машин, типа AES-256, оно дает более значимую задержку, порой перешагивающую за одну секунду. И это правда: защищая систему, вы неизбежно немного теряете во времени. Но эти потери — капля в море по сравнению с тем, сколько времени агенты теряют при взаимодействии с MCP, при ретраях, при построении индексов и прочих операциях. Эта капелька добавляет задержку, но она весьма незначительна.
«Всё всегда упирается не в технологии, а в качество описания бизнеса”
Классическая обвязка — это всегда ограничители: фильтры, проверки, откаты. Но агент, который на каждом шагу спрашивает разрешение, по сути, тот же чат-бот, только дороже. На Хабре один из авторов конкретно написал, что цель заключается не в стопроцентной автоматизации, а в сокращении рутины до 20%. Зачем тогда городить сложную агентную архитектуру, если задача — просто убрать рутину? Может, хватит обычного сценарного автоматизатора без языковой модели внутри?
Вопрос абсолютно законный. Давайте проведем четкую границу между агентом и чат-ботом. Чат-бот — это stateless-система, которая часто валится на промежуточных этапах. Если она не смогла ответить, процесс зависает, либо в лучшем случае начинается с самого начала. Попробуйте хоть раз дойти до конца сложного сценария с банковским чат-ботом. В продакшене такие системы зачастую больше калечат бизнес-процессы, чем лечат их. Именно поэтому эра классических чат-ботов потихонечку клонится к закату, пользоваться ими крайне неудобно. Агенты же — это stateful-машины. Они во что бы то ни стало стремятся выполнить запланированное действие, используя для этого самые разные инструменты и способы. В этом их ключевое отличие. Да, сегодня они еще несовершенны, но они уже перешагнули порог stateless-архитектуры. Второй момент касается самой автоматизации. Автоматизация — это разговор не про искусственный интеллект, а про бизнес-уровень. Представим бабушку Лену, которая сидит на проходной и ставит галочки каждому вошедшему человеку. У нее есть фиксированный список людей, карандаш в правой руке и расчерченные квадратики на бумаге. Этот процесс полностью детерминирован, и мы можем автоматизировать его на все 100%. Но ситуация меняется, когда количество людей на проходной становится непредсказуемым, когда пропадают квадратики, а баба Лена забывает дома карандаш. Система становится недетерминированной. И именно эти хаотичные факторы снижают возможный уровень автоматизации до тех самых 20%, просто потому, что бизнес-процессы плохо регламентированы. Как только они будут описаны лучше, уровень автоматизации возрастет.
Протокол A2A решает проблему совместимости между агентами разных вендоров. Протоколы вроде MCP решают проблему подключения агентов к внешним сервисам. Но ни один протокол не решает главного: как гарантировать, что агент не выйдет за рамки дозволенного в промежутке между проверками? Обвязка контролирует вход и выход. А что происходит внутри черного ящика модели? Кто отвечает за этот зазор? Разве не Guardrails?
Guardrails — это дополнительный фреймворк, который как раз и вешается на входе и на выходе. Визуально это можно представить как защитные заслонки. Если у нас есть водопроводная труба, ее основная функция — обеспечивать максимальную пропускную способность. Зачем ставить дополнительные вентили прямо внутри трубы? Вентили монтируются на концах, по ситуации. Именно поэтому системы безопасности не относятся к функционалу протоколов MCP или A2A. Это совершенно другие технологии, тут работает чистая логика.
Получается, обвязка — это по сути костыль, которым мы пытаемся сделать детерминированным то, что детерминированным быть не может по своей природе. Есть ли предел, после которого наращивание обвязки становится дороже, чем просто нанять живого человека?
Всё всегда упирается не в технологии, а в качество описания бизнеса. Если у вас плохо регламентирован процесс, это гарантированно убьет ваш ROI — показатель возврата инвестиций. Именно поэтому перед стартом проекта ведется так много переговоров: мы пытаемся описать процесс, установить ограничения, прописать все риски. Это создает страховки, позволяющие делать проекты прибыльными. На текущий момент на рынке действительно очень много плохо описанных проектов с высокими рисками потери ROI. Но это проблема не искусственного интеллекта и не фреймворков вроде OpenClaw. Проблема кроется в том, что мы пытаемся прикрыть модными технологиями собственное нежелание наводить порядок. Зачем нам исключать человека из цепочки, если он даже свои текущие процессы описать не в состоянии? Наведение порядка — это его прямая стратегическая задача. Как только бизнес научится регламентировать свои шаги, автоматизация придет в него гораздо быстрее и эффективнее.
Андрей, вся эта индустрия обвязок лично для меня выглядит как бизнес, построенный исключительно на несовершенстве текущих моделей. Если завтра выйдет идеальная модель, которая не галлюцинирует, не поддается инъекциям и кристально точно следует инструкциям — такой абсолютный Джарвис — то 90% рынка обвязок схлопнется за одну ночь. Получается, люди, продающие обвязку, экономически заинтересованы в том, чтобы модели оставались ненадежными. Как архитектор, проектирующий такие системы, вы строите будущее или, мягко говоря, зарабатываете на чужих недостатках?
Думаю, на вторую часть вопроса вам бы никто честно не ответил. На самом деле я живу настоящим. За серьезной архитектурой ко мне приходят заказчики, созревшие для решений, которые должны бесперебойно проработать от трех до пяти лет. Без такого горизонта планирования архитектура, как правило, не требуется: достаточно собрать быстрый PoC, который всех порадует и затем благополучно упадет в самый неожиданный момент. Когда поступают вводные требования, архитектор понимает, какая инфраструктура потребуется, и выбирает платформу для инференса. Если это on-premise решение, приходится выбирать между более простым vLLM или сложным в настройке, но исключительно гибким и надежным Triton для высоких нагрузок. Стек подбирается в зависимости от ресурсов команды. Усилия инженеров — это часы, а часы — это деньги заказчика. Поэтому здесь нет противоречий или умышленного торможения прогресса. Я выступаю исключительно за адекватность. Если человек приходит ко мне ранней весной, когда всё только оттаяло, и говорит, что ему нужна обувь, я не стану предлагать ему босоножки от Versace. Я предложу резиновые сапоги.
Можно ли назвать 2026 год годом построения обвязок как самостоятельного продукта?
Я бы назвал этот год годом агентов, а обвязки — это уже вторичная история. Чтобы агенты работали как единый механизм, в индустрии появляется термин «устойчивая инфраструктура». Скажу честно: с архитектурной точки зрения сейчас прикрыты далеко не все тылы. Агенты дырявые, и все мы видим, как это работает на практике. Но самое интересное заключается в том, что мы знаем эти уязвимости и постепенно находим для них решения. Я веду канал «AI Надзор» в Telegram, где как раз описываю перебор этих решений. Я приношу реальные кейсы с проектов и делюсь рабочими гипотезами, которые позволяют более или менее успешно закрывать эти дыры в безопасности.
Андрей, обвязка — это признание поражения? Мы взяли модель, которая галлюцинирует, врет, забывает контекст, и вместо того, чтобы починить ее саму, обложили ее костылями. Фильтры на входе, валидаторы на выходе, сторожевые таймеры, песочницы, механизмы отката — это все равно что поставить пьяного хирурга к операционному столу и приставить к нему трех трезвых медсестер с правом в любой момент выхватить скальпель. Отсюда вопрос: мы выстраиваем строгую инженерную дисциплину или просто занимаемся высокотехнологичным самообманом?
Позвольте мне докрутить аллегорию, у нее есть отличное продолжение. Да, мы поставили пьяного хирурга, но мы поставили его в глухой деревне, где врачей отродясь не было. И пусть лучше лечит пьяный хирург под присмотром, чем трезвый электрик или ветеринар.
Но разве не имеет смысла направить все усилия на развитие самих моделей, а не на строительство лесов вокруг них?
Безусловно имеет, но разработка фундаментальных моделей — это невероятно дорого. Тот электрик, о котором я упомянул, — это реальный контекст, в котором мы сейчас находимся. Инженерные решения должны приниматься адекватно текущей реальности, а не абстрактному идеалу, который еще не наступил. Создать безупречную модель прямо сейчас очень сложно и долго, технологии пока не позволяют делать это дешево. Тем не менее, архитектуры развиваются: появляются гибриды вроде RNN плюс трансформер, такие как Mamba или Hyena. Мы уже начинаем работать с контекстным окном в миллионы токенов. Еще три года назад, в 2023-м, это казалось немыслимым — пришлось бы застроить серверами все столицы мира, чтобы получить такие мощности на чистой трансформерной архитектуре тех лет. Сама технология фундаментальна, ее никто умышленно не тормозит, просто финальное решение еще не изобретено.
Порекомендуйте, пожалуйста, источники для погружения в тему построения агентных систем.
Что касается источников, для меня номером один является платформа DeepLearning.AI от Эндрю Ына. Практически все выдающиеся ИИ-инженеры и основатели стартапов, прошедшие через Y Combinator, побывали на этой платформе и оставили там свои вводные курсы. Вы можете не просто послушать теорию, но и потрогать технологии руками прямо в предоставленных блокнотах с кодом. Это дорогого стоит. Второй отличный источник — материалы Стэнфордского университета, они регулярно публикуют честные и глубокие разборы работающих технологий. Из российских ресурсов могу смело рекомендовать Школу анализа данных (ШАД), курсы от OTUS и СберУниверситет, где очень плотно работают с практикой и реальными платформенными решениями. В эту тему нужно погружаться комплексно. Не верьте, если вам скажут: «Прочитай вот эту книжку, и будешь всё знать». Вам придется изучить большой объем смежных дисциплин, чтобы понимать, почему ваши агенты демонстрируют именно такое поведение, и какую систему — stateful или stateless — лучше применить в конкретном случае.
Последняя уязвимость в LiteLLM ярко демонстрирует слабость текущих агентных фреймворков. Каким образом можно выстроить механизм защиты от подобных уязвимостей в цепочке поставок?
Недавняя уязвимость, связанная с LiteLLM, на самом деле находилась на уровне самого языка Python. Взломали не LiteLLM, взломали один из компонентов Python. Сам фреймворк прекрасно себя чувствует. Я сегодня утром специально проверял — всё работает штатно, никаких критических уязвимостей там нет. Проблема касалась одной из старых, замороженных версий. Фреймворки, занимающиеся роутингом, являются высокоуровневыми абстракциями, их практически нечем ломать. Ломается всегда что-то конкретное и низкоуровневое, например, методы в стандартных библиотеках языка. Поэтому всегда советую смотреть вглубь новостей, а не судить по заголовкам.
