Границы и управление для LLM-агентов в production

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

Устойчивую систему стоит строить вокруг простого принципа: модель принимает решения внутри явно очерченного участка, а внешние границы процесса задаёт детерминированный runtime. Тогда агент получает свободу для работы с неоднозначностью, а команда сохраняет контроль над стоимостью, безопасностью и последствиями вызовов инструментов.

Начните с минимальной схемы

Не каждой задаче нужен автономный цикл «модель — инструмент — результат». Если все шаги известны, достаточно обычного workflow с типизированными входами и выходами. Когда неоднозначность возникает в одном месте, её часто закрывает один вызов модели со структурированным результатом. Небольшое исследование можно поручить единственному агенту с ограниченным набором tools, лимитами времени и числа шагов.

Графовый runtime нужен, когда порядок действий, ветвления, паузы и состояние должны быть определены в коде. Он хорошо сочетается с LLM: модель выбирает вариант в разрешённой точке графа, а переходы и проверки остаются предсказуемыми. LangGraph и Mastra Workflows строят процессы вокруг состояний, условных переходов, checkpoints и этапов, которые можно запускать последовательно либо параллельно. XState подходит для ещё более строгих сценариев, где модель отправляет только заранее разрешённые типизированные события.

Мультиагентная схема оправдана, когда участники действительно различаются контекстом, доступными инструментами, моделями или правами. Практичный паттерн — supervisor–worker: координатор распределяет независимые части задачи, изолирует контексты, следит за бюджетом и собирает результат. Для известных правил маршрутизации координатором может быть обычный код, а не ещё одна LLM.

Разделите граф процесса и долговечное выполнение

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

Это различие заметно в задачах, которые длятся дни. Агент может получить документы, передать спорные пункты специалисту, дождаться согласования, принять новую версию файла и продолжить с сохранённой точки. Состояние нельзя держать только в памяти Node.js-процесса. Нужны сохранённая история, идентификаторы операций и возможность безопасно восстановить выполнение.

Temporal сохраняет историю workflow и восстанавливает её по событиям. Restate, Inngest и Cloudflare Agents предлагают похожие механизмы для долгих процессов. Выбор конкретного runtime вторичен по отношению к контракту: каждый шаг должен иметь понятное состояние, а вызовы, меняющие внешний мир, — защиту от повторной отправки.

Для операций с последствиями применяйте idempotency keys, дедупликацию, журнал завершённых действий и compensating actions там, где отмена возможна. Повторный поиск или чтение обычно безопасны. Повторное письмо, pull request либо списание денег требуют отдельного контроля. Агент может предложить повтор, но решение о его допустимости должен принимать runtime.

Инструмент не равен разрешению

Подключённый tool означает техническую возможность выполнить действие. Он не даёт модели право действовать от имени пользователя без ограничений. Полномочия должны быть минимальными, ограниченными конкретной задачей и проверяемыми перед каждым чувствительным вызовом.

Полезная последовательность выглядит так: workflow создаёт задачу и её ограничения; агент работает с read-only инструментами; policy layer проверяет параметры выбранного действия; пользователь подтверждает конкретную необратимую операцию; runtime выполняет её с идемпотентным ключом и сохраняет audit trail; отдельный проверяющий шаг убеждается, что результат соответствует условиям.

OAuth решает передачу учётных данных, но широкого token scope недостаточно для детальной политики. У одной задачи могут быть разные уровни доступа: поиск разрешён сразу, чтение профиля ограничено, оплата требует явного подтверждения, а дополнительные услуги запрещены. Такие правила должны жить вне prompt и проверяться детерминированно.

Sandbox ограничивает радиус ошибки

Агент с инструментами способен читать файлы, запускать код, работать с сетью и передавать данные наружу. Отдельная папка, subprocess или Git worktree полезны для организации работы, но не образуют полноценную защитную границу. Sandbox изолирует процесс и файловую систему, ограничивает сеть, ресурсы и время жизни сессии.

Среды E2B, Daytona, Vercel Sandbox и Cloudflare Sandbox реализуют этот подход по-разному. Общая цель одинакова: отдельное окружение для сессии, минимум постоянных секретов и контролируемый исходящий трафик. Чем шире набор доступных агенту действий, тем важнее изоляция.

Те же правила применимы к browser agents. Браузерный интерфейс постоянно меняется, поэтому работа строится циклом «наблюдение — действие — новое состояние». Известные шаги полезно выполнять детерминированной автоматизацией через Playwright или CDP. Модель стоит подключать к неоднозначным местам, а подтверждение оставлять обязательным для действий с необратимыми последствиями.

Наблюдаемость должна показывать траекторию

Итоговый текст агента не рассказывает, каким путём он получен. Два запуска могут дать одинаковый ответ, но один использует надёжный источник и три вызова tools, а другой — десятки вызовов, опасную операцию или вымышленный факт. Поэтому production-система должна записывать траекторию: модель и её версию, prompt, доступные tools, вызовы, переходы, результаты проверок и решения policy layer.

OpenTelemetry формирует независимую основу для traces, metrics и logs, а OpenInference добавляет понятия моделей, агентов и инструментов. LangSmith, Langfuse и Phoenix помогают анализировать запуски и превращать неудачные trace в наборы регрессионных проверок. Оценивать следует не только ответ, но и допустимость пути, повторяемость, стоимость, задержку, устойчивость к сбоям и необходимость вмешательства человека.

Полезные метрики включают success rate, стоимость успешной задачи, медианную и p95-задержку, число model и tool calls, долю повторных попыток, расход контекста, rate limits и частоту эскалаций. Дополнительный planner, critic или retrieval-этап имеет смысл только тогда, когда улучшение надёжности оправдывает их цену и задержку.

Память состоит из нескольких разных задач

За словом «память» скрываются как минимум четыре слоя: история текущего диалога, checkpoint процесса, retrieval по внешним данным и долговременные факты между сессиями. У них разные требования к хранению, обновлению и удалению. Векторная база решает только часть вопроса и не заменяет состояние workflow или политику работы с пользовательскими данными.

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

Практический чек-лист

Перед запуском агента в production зафиксируйте минимальный набор решений:

определите, где достаточно обычного workflow, а где нужна LLM;
задайте типизированные контракты для tools и результатов модели;
сохраните состояние долгих процессов и идемпотентность внешних действий;
предоставьте минимальные права и policy-проверку для каждого действия;
изолируйте выполнение кода и ограничьте сеть в sandbox;
добавьте traces, метрики и регрессионные evals с первой версии;
предусмотрите понятную точку human-in-the-loop для необратимых операций.

Модель становится сильным компонентом системы, когда её возможности дополняют привычную инженерию. Workflow хранит состояние, sandbox ограничивает среду, authorization определяет права, observability показывает путь выполнения, а LLM работает с задачами, где нужен выбор и понимание неструктурированных данных.