Stack Overflow предлагает проектировать детерминированные ИИ-агенты так, чтобы языковая модель не управляла бизнес-процессом напрямую. LLM должна сформировать предложение, а применять его вправе только отдельный слой обычного, тестируемого кода — после нужных проверок и, при необходимости, одобрения человека.
Такой подход описан в первом материале Stack Overflow Blog о зрелости LLM-систем в продакшене. Авторы называют его «слоем детерминизма»: фундаментом, без которого бессмысленно переходить к оценкам качества, маршрутизации по уверенности и другим надстройкам. Для команд, внедряющих ИИ в финансы, медицину, инфраструктуру или внутренние корпоративные процессы, мысль довольно приземлённая: агент не должен получать право «разобраться по ходу дела» там, где цена ошибки выше красивой демо-записи.
Главное правило авторов: агент предлагает, но не действует. В их модели метод, который формирует решение, не меняет состояние системы и не вызывает побочные эффекты. На вход он получает контекст, на выходе возвращает структурированное предложение: идентификатор решения, разрешённую операцию, параметры предполагаемого действия, оценку уверенности, маршрут обработки, обоснование и набор свидетельств. Отдельный компонент применяет это предложение к бизнес-системе. Именно он остаётся единственным местом, где разрешено что-то менять: переводить деньги, обновлять запись, отправлять запрос или запускать операцию.
Разделение кажется скучным ровно до первого инцидента. Если модель неверно поняла инструкцию или получила вредоносный ввод, она сможет выдать плохое предложение, но не совершить плохое действие. Его остановит правило, проверка или оператор. Заодно такой контракт упрощает тестирование: при фиксированном контексте и подставном шлюзе к модели разработчик проверяет, что агент возвращает тот же результат и не трогает внешний мир. Не нужно мокать базу данных, биллинг и десяток интеграций ради проверки логики одного решения.
Вторая опора схемы — фиксированный граф обработки вместо свободного цикла ReAct, где модель сама выбирает следующий шаг, вызывает инструменты и повторяет попытки. В исследовательской или поисковой задаче такая автономность полезна. В прикладном процессе она создаёт непредсказуемые маршруты, стоимость и задержки. Stack Overflow предлагает заранее описать последовательность узлов: вход и привязка личности, предварительная проверка, загрузка нужного контекста, единственный вызов LLM, защита её вывода, детерминированная верификация, выборочная проверка вторым механизмом, расчёт уверенности, маршрутизация, подготовка предложения, запись памяти и добавление записи в неизменяемый журнал.
В этой схеме почти все этапы общие для разных сценариев. Для новой возможности команде не нужно строить нового автономного «сотрудника»: достаточно реализовать специфичные для задачи предварительную проверку, LLM-решение, верификацию и формирование предложения, а остальные узлы переиспользовать. Каждый узел получает и возвращает одно типизированное состояние. В нём отдельно хранятся входные данные, контекст, сырой ответ модели, результаты защитных и бизнес-проверок, уверенность, выбранный маршрут и итоговое предложение. Такой формат делает путь решения читаемым: контрольный поток находится в графе, а не в цепочке импровизаций модели.
Особое внимание авторы уделяют выходу модели. Свободный текст вроде «вероятно, одобрить, но можно и эскалировать» немедленно превращает последующий код в ещё одну задачу по пониманию языка. Вместо этого LLM должна возвращать данные в заранее заданной схеме и только из разрешённого набора вариантов. Затем детерминированный код проверяет, что решение входит в допустимый список, соответствует схеме и не нарушает бизнес-инварианты. Иными словами, структурированный вывод — не косметика для API, а граница между вероятностным рассуждением и исполняемым процессом.
Маршрут обработки тоже не следует оставлять на усмотрение самой модели. Она может указать уверенность и предложить вариант, но итоговое правило определяет система: выполнить автоматически, рекомендовать проверку человеком, потребовать её или отклонить запрос. Для высокорисковых решений авторы добавляют выборочную вторую оценку. Важна не магическая точность «судьи», а то, что все сигналы складываются в понятную процедуру, которую можно менять, тестировать и разбирать после инцидента.
Для разработчиков детерминированные ИИ-агенты означают более прозаичную, но полезную работу: типы, схемы, журналирование, проверки и явные права доступа вместо бесконечной настройки промпта. Для руководителей это способ обсуждать внедрение LLM не в категориях «доверяем ли мы модели», а в категориях допустимого радиуса ошибки. Следующий неудобный вопрос для рынка звучит так: сколько агентных продуктов готовы отказаться от эффектной автономности, когда заказчик попросит показать не демонстрацию, а воспроизводимый след каждого решения?