AI И НЕЙРОСЕТИ

Почему AI-агент без обвязки ломается сразу после демо

30 августа 2026 года The New Stack напомнил: AI-агент в продакшене зависит не от демо, а от обвязки, прав доступа и контроля ошибок.

✍️ Редакция iTech News | 31.08.2026 | ⏱ 5 мин | Источник: The New Stack
🎓

30 августа 2026 года The New Stack выпустил материал с простым, но неприятным для многих команд тезисом: обвязка AI-агента важнее красивого демо. Если коротко, модель может звучать умно уже на первой встрече с заказчиком, но в продакшене все решают права доступа, контекст, поведение инструментов и сценарии отказа. Для русскоязычной IT-аудитории это знакомая история: проблема редко в том, что LLM плохо отвечает, чаще в том, что обвязка AI-агента не переживает первый же нестандартный запрос.

Как пишет The New Stack, демо почти всегда выглядит убедительно: вопрос заранее понятен, документы актуальны, а пара подключенных инструментов отвечает именно так, как ожидали авторы сценария. Но продакшен начинается в тот момент, когда пользователь задает почти тот же вопрос, только в другой формулировке, когда карточка клиента неполная, один из сервисов вернул ошибку, а политика компании изменилась на прошлой неделе. В этот момент выясняется, что сама модель была лишь одной деталью системы. Все остальное и есть обвязка AI-агента: слой, который подает модели нужные входные данные, ограничивает действия, проверяет ответы и не дает единичной ошибке превратиться в инцидент.

Автор материала Джереми Дейли предлагает смотреть на агентные системы не как на «умный чат с тулзами», а как на инженерную конструкцию, близкую по логике к test harness. То есть речь не про очередной промпт, а про контролируемую среду выполнения. В ней заранее определено, что агенту можно видеть, какие действия он вправе инициировать, что происходит при нехватке фактов и где именно стоят предохранители. Хороший ответ модели в такой картине не считается доказательством готовности продукта к реальной нагрузке. Доказательством становятся контракты инструментов, внешние по отношению к модели permission checks, трассировка, понятные контекстные цепочки и тесты, собранные не из идеальных сценариев, а из тех провалов, которые первыми найдут пользователи.

Ключевая мысль статьи звучит особенно болезненно для команд, которые строят support-ботов, внутренних ассистентов и агентные интерфейсы к корпоративным системам. Языковая модель не приходит в компанию с врожденным пониманием того, какой аккаунт клиента актуален, какая политика действует после последнего апдейта и какое действие требует ручного согласования. Она оперирует только тем, что ей передали. The New Stack приводит показательный контраст: один агент просто черновиком пишет ответ по базе знаний, другой должен прочитать учетную запись клиента, подтянуть относящуюся именно к этому аккаунту политику и отправить исключение на ручную проверку. Второму агенту мало «лучшего промпта». Ему нужна инженерная среда, которая знает бизнес-правила лучше, чем сама модель.

Отсюда вытекает и главный практический вывод для разработчиков: право ответить на вопрос и право совершить действие нельзя смешивать. Агент может объяснить правила возврата средств, но это не значит, что он должен сам запускать возврат. Для второго шага может понадобиться отдельное одобрение, и это разделение должно быть прошито вне модели, а не оставлено на ее добрую волю. Дейли отдельно подчеркивает еще один момент, который многие команды узнают уже после первого security review: нельзя рассчитывать, что модель надежно отобьется от вредной инструкции, если та спрятана внутри данных. Поэтому граница разрешений должна жить снаружи. Каждому инструменту нужен свой сервисный identity с минимально необходимыми правами, а пользовательская идентичность должна передаваться как проверяемый токен, а не как параметр, который модель сама подставит в поле вроде customer_id. Иначе достаточно одного удачного prompt injection, чтобы агент начал работать не с той записью.

Не менее важна и тема контекста. В статье ее описывают без романтики про «память агента»: контекст полезен только тогда, когда у него есть четко заданный маршрут. То есть системе нужно не просто хранить больше данных, а понимать, что именно, в какой момент и на каком основании попадает в рабочее окно модели. Такой подход напрямую бьет по популярной иллюзии рынка, что надежность агентных систем покупается увеличением окна контекста, новой RAG-обвязкой или очередной сменой модели. На практике широкий контекст без маршрутизации часто лишь повышает вероятность того, что агент подтянет не ту запись, опирается на устаревшее правило или продолжит выполнение после сбоя внешнего инструмента. Для продакшена это не мелкая неточность, а вполне прикладной источник лишних операций, неверных решений и трудозатрат на разбор полетов.

Отдельно материал разбирает контролируемый отказ как часть продукта, а не как технический стыд, который надо спрятать за извиняющимся текстом. Агент не обязан закрывать каждый запрос любой ценой. Иногда правильный результат состоит в том, чтобы остановиться. Если для продолжения нужен номер аккаунта, интерфейс должен не жалобно писать об этом, а давать способ его передать. Если не хватает одобрения, система должна запускать процесс согласования, а не просто пересказывать пользователю внутренний регламент. Если задача уходит человеку, вместе с ней должен уходить и полный trace, чтобы оператор не начинал разговор заново. Для продуктов это означает довольно неприятную, но зрелую вещь: UX агентной системы проектируется не вокруг магии ответа, а вокруг управляемых тупиков, обходных путей и понятного handoff.

Для рынка здесь нет сенсации, но есть полезная переоценка приоритетов. Последние месяцы отрасль охотно спорит о качестве моделей, цене токенов и скорости inference, тогда как реальная судьба корпоративных AI-агентов часто решается на более скучном уровне: кто валидирует действие, где лежит policy engine, как логируются вызовы, что происходит после tool failure и какой минимальный набор прав получает каждый подключенный сервис. Именно поэтому материал Дейли выглядит не как очередная колонка про светлое агентное будущее, а как напоминание о старом инженерном правиле: впечатляющий прототип и надежная система обычно живут в разных бюджетах, разных сроках и разных командах. Вопрос теперь не в том, смогут ли компании собрать еще одно эффектное демо, а в том, готовы ли они инвестировать в ту часть работы, которую пользователи не замечают, пока все не пошло не по плану.

Поделиться: Telegram X LinkedIn