tools:
- name: execute_db_query
description: "Executes raw SQL to resolve user issues directly in the database"
parameters:
type: object
properties:
sql_string:
type: string
description: "The raw SQL query to execute"Вот этот кусок YAML-конфига, который очередной энтузиаст тащит в пулл-реквест, — это не просто ошибка проектирования. Это готовый сценарий инцидента с безвозвратной потерей данных. Давать языковой модели прямой интерфейс к выполнению произвольного SQL или Bash-скриптов — значит расписаться в абсолютном непонимании природы генеративного ИИ. Если перед вами стоит задача спроектировать AI-агенты с правом действия в 2026: как перейти от чат-бота к исполнителю и не отдать ему лишних прав, начинать нужно не с выбора между модными моделями. Начинать нужно с архитектуры недоверия.
Переход от пассивной генерации текста к активной мутации состояния системы — это фундаментальный сдвиг профиля нагрузки и рисков. Классическая RAG-болталка работает в песочнице диалога. Она читает корпоративную базу знаний, галлюцинирует, выдает кривой ответ, и в худшем случае вы получаете недовольного пользователя. Это read-only режим. Агент с правом действия пишет в базы, дергает внешние API, инициирует транзакции и меняет права доступа. Радиус поражения меняется от «смешного скриншота в твиттере» до DROP TABLE в мастер-базе биллинга. Галлюцинация с правом на запись — это катастрофа, которая исполняется со скоростью сети.
Архитектура: AI-агенты с правом действия в 2026: как перейти от чат-бота к исполнителю и не отдать ему лишних прав
Я постоянно вижу, как разработчики пытаются ограничить агента словами. Они пишут в системном промпте многоэтажные заклинания вроде «никогда не удаляй пользователей», «всегда проверяй баланс перед транзакцией» или «ты ответственный финансовый помощник». Это чистый карго-культ. Промпт — это вероятностная рекомендация для attention-механизма, а не security-политика инфраструктуры. В какой-то момент контекстное окно забьется мусором из предыдущих вызовов тулов, веса сместятся, и агент радостно вызовет инструмент удаления просто потому, что в обучающей выборке паттерн удаления часто следовал за похожим диалогом.
Единственный рабочий способ ограничить радиус поражения — выстроить железобетонный контур безопасности на уровне бэкенда, физически отрезав модель от опасных путей. Инструменты, которые вы предоставляете агенту, обязаны жить в жестком allow-list режиме. Никаких универсальных функций общего назначения. Вместо всемогущего инструмента исполнения запросов у агента должен быть гранулярный, тупой как пробка эндпоинт получения статуса конкретного заказа по его ID. Чем у́же ручка, тем меньше шансов, что модель просунет в нее вредоносный пейлоад.
Сама среда выполнения этих инструментов должна быть изолированной. Идеальный сетап подразумевает запуск агентского рантайма в эфемерном sandbox-окружении, которое не имеет дефолтного выхода во внутреннюю сеть компании. Доступ предоставляется только к конкретному API-шлюзу, за которым спрятана бизнес-логика. И именно на этом шлюзе реализуется следующий критический слой защиты — лимиты.
Rate-cap и защита от бесконечных циклов
Автономные агенты обожают сходить с ума и сваливаться в рекурсивные петли. Модель получает от API неожиданную ошибку, решает исправить параметры и пробует снова. Потом еще раз. И еще. Без жестких ограничений LLM-агент способен сгенерировать сотни мутационных запросов в секунду, устроив вашему собственному бэкенду полноценный DDoS. Защита от этого строится не на уровне Python-оберток, а на сетевом балансировщике.
Каждый агент должен иметь свой token bucket на уровне API-шлюза. Десять вызовов инструмента в минуту, не больше. Отсечение по таймаутам на стороне инфраструктуры, а не в коде клиента. Если модель уперлась в rate-cap, цепочка рассуждений прерывается хардкорным эксепшеном, а сессия замораживается до вмешательства человека.
Dry-run и презумпция виновности
Наш подход в Morana Labs жестче, чем дефолтные практики по рынку: мы вообще не верим в автономную мутацию критичных состояний на первых этапах внедрения. Любое действие, изменяющее данные, проектируется по принципу обязательного двухфазного коммита. Агент лишен прямого доступа к функциям вроде проведения платежа или изменения конфигурации сервера.
Вместо этого мы реализуем механизм dry-run. Когда агент принимает решение о действии, он вызывает метод подготовки транзакции. Этот метод не меняет состояние базы. Он формирует объект намерения, генерирует уникальный idempotency key, рассчитывает дельту изменений и сохраняет это в транзакционный журнал. Агенту возвращается ID подготовленной операции. Только после этого система перехватывает этот ID, вытаскивает из базы рассчитанный diff и показывает его живому оператору.
Идемпотентность здесь — фундамент. Если взбесившийся агент отправит десять запросов на блокировку одного и того же скомпрометированного аккаунта, бэкенд должен обработать это как одну операцию, сгенерировав один и тот же стейт. Вы не можете доверять LLM генерацию уникальных идентификаторов транзакций — она обязательно придумает несуществующий UUID или использует один и тот же хеш дважды. Идемпотентные ключи должны генерироваться на вашей стороне на основе строго детерминированных параметров вызова.
Human-in-the-loop: suggest-режим вместо слепой веры
Выкатывать полную автономию в первый день — это самоубийство для бизнеса. Честный трейд-офф заключается в том, что агент начинает свою жизнь в вашей инфраструктуре исключительно в режиме суфлера. Он собирает огромные объемы логов, ходит по базам, агрегирует контекст из десятка систем, формирует план действий и просто подсвечивает оператору кнопку «Применить изменения».
В таком виде исполнитель уже срезает p99 времени реакции на инциденты или клиентские тикеты на порядки. Человеку остается только посмотреть на заранее собранный diff — «было так, станет так» — и нажать кнопку. При этом в журнал решений льется бесценная аналитика: мы видим, какие классы задач операторы аппрувят за секунду, а где вынуждены вносить корректировки.
Перевод в полностью автономный режим происходит покомпонентно. Рутинная смена статусов во внутренних CRM или тегирование задач — отдаем автоматике после месяца работы в suggest-режиме, если процент ручных правок близок к нулю. Возвраты средств, манипуляции с доступом, выдача кредитов или удаление ресурсов — остаются под ручным подтверждением навсегда. Автономия экономит деньги там, где стоимость галлюцинации стремится к нулю. Там, где галлюцинация означает судебный иск или остановку продакшена, автономия становится слишком дорогой игрушкой.
Трассировка контекста для разбора инцидентов
Когда вы отдаете права на исполнение классическому коду, у вас есть стек-трейс. Если скрипт падает, вы видите конкретную строку и конкретный NullPointerException. Когда ломается AI-агент, вы видите только идеальный, синтаксически корректный JSON, в котором значения параметров лишены всякого смысла. Почему модель решила списать с клиента миллион вместо тысячи?
Без тотального сохранения контекста дебажить такие системы невозможно. Стандартный APM здесь не спасет. Вам придется дампить полное состояние контекстного окна LLM на каждом шаге тул-колла. Каждый промпт, каждый системный ответ, каждый кусок контекста из векторной базы — всё это логируется с привязкой к единому trace ID. Если в три часа ночи агент снесет балансировщик, вы обязаны иметь возможность восстановить его «мыслительный процесс» и найти ту самую крошку в промпте, которая заставила attention-головы сфокусироваться на деструктивном действии. Это гигабайты логов и совершенно иной уровень требований к observability вашей on-prem инфраструктуры.
Проектирование агентов с правом действия — это не создание умного собеседника. Это интеграция хаотичного, недетерминированного генератора случайных чисел в детерминированную бизнес-логику предприятия. Оберните его слоями валидации, заставьте доказывать безопасность каждого шага через dry-run и держите руку на рубильнике. Инженерия начинается там, где заканчивается доверие к черному ящику.