От болтливых LLM-агентов к управляемым системам

Путеводитель по LLM-агентам и мультиагентным системам: от ReAct и команд из нескольких агентов до графов, durable execution, sandbox, памяти, evals и безопасности в production.

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

Это не рейтинг библиотек, а руководство по выбору минимально достаточной архитектуры. Примеры инструментов подобраны преимущественно из экосистемы TypeScript и JavaScript, однако рассматриваемые архитектурные принципы не зависят от языка.

---

Содержание

• Агент — это не персонаж с должностью

• От ReAct к мультиагентным системам

• Как графы задают структуру работы агентов

• Из чего состоит современная агентная система

• Production-практики и опасные упрощения

• Как выбрать минимально достаточную архитектуру

• Модель — часть системы, а не её центр

---

Агент — это не персонаж с должностью

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

агент = модель      + цикл работы      + инструменты      + состояние      + правила и ограничения

Несколько агентов полезны, только если их роли действительно различаются. Например, один ищет информацию, другой проверяет выводы, а третий имеет право выполнить действие. Все они могут работать на одной модели — количество LLM здесь не главное.

Мультиагентность — это не количество имён или моделей. Это распределение задач, контекста, полномочий и ответственности.

---

2022: модель учится не только отвечать, но и действовать

До 2022 года языковую модель обычно использовали по простой схеме: передали запрос — получили ответ. Но для решения реальной задачи одного ответа часто недостаточно.

В работе ReAct — сокращение от Reasoning and Acting («рассуждение и действие») — предложен подход, при котором модель чередует анализ задачи с действиями: например, обращается к поиску или другим инструментам, оценивает результат и выбирает следующий шаг.

Этот процесс можно представить как повторяющийся цикл:

мысль → действие → наблюдение → новая мысль → новое действие

Модель перестала быть только генератором текста. Теперь она могла выбрать инструмент, оценить его результат, изменить план и решить, когда задача завершена. Этот цикл стал основой многих современных Agent SDK.

Помимо ReAct: как выбрать стратегию

Выбор стратегии зависит от того, где возникает неопределённость.

• Следующий шаг зависит от среды — ReAct. Модель меняет путь после каждого действия, но тратит больше времени и токенов.

• Сначала нужен план — Plan-and-Solve или ReWOO. Независимые шаги можно выполнять параллельно, пока план остаётся актуальным.

• Нужно сравнить несколько путей — Tree of Thoughts, RAP или LATS. Такой поиск полезен, только если варианты можно надёжно оценить.

• Нужно улучшать ответ — Self-Refine или Reflexion. Модель дорабатывает результат по собственной обратной связи, но может закрепить ошибочный вывод.

• Шаги известны заранее — MRKL или обычный workflow. Код управляет процессом, а LLM решает только неоднозначные задачи.

Чем лучше известны шаги и их последствия, тем меньше свободы нужно отдавать модели. В непредсказуемой среде, наоборот, полезнее ReAct или поиск по нескольким вариантам.

Для практического знакомства с этими паттернами полезны русскоязычные разборы ReAct с современным tool calling и LangGraph и ReAct вместе с Reflection. Более широкую инженерную карту — от предсказуемых workflow до orchestrator–workers и evaluator–optimizer — даёт руководство Anthropic Building Effective Agents.

Почему одного агента часто достаточно

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

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

Когда несколько агентов действительно дают выигрыш

Несколько агентов дают выигрыш, когда они параллельно исследуют разные направления, используют разные источники или права, работают в изолированных контекстах либо независимо проверяют результат.

Исследование Understanding Agent Scaling показало, что разнообразие агентов важнее их количества: два разных агента могли работать не хуже шестнадцати одинаковых. Это результат конкретной экспериментальной постановки, а не универсальная пропорция.

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

Поэтому спрашивать стоит не «сколько агентов добавить?», а «какую новую информацию, возможность или независимую проверку даст ещё один агент?». Если никакую, это лишний вызов модели.

---

2023: разговор становится архитектурой

Следующий этап выглядел гораздо эффектнее.

В 2023 году AutoGen популяризировал приложения, построенные как разговор нескольких агентов. Они могли общаться друг с другом, использовать инструменты, выполнять код и подключать к обсуждению человека.

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

Подход быстро стал популярным. На то было несколько причин.

Во-первых, всем понятны знакомые роли. Не нужно долго объяснять, чем занимается ResearcherAgent или CodeReviewerAgent.

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

В-третьих, создать новую роль очень просто. Достаточно дать модели другую инструкцию, инструменты и контекст.

Так появились распространённые схемы:

• planner–executor: один агент строит план, другой выполняет;

• writer–critic: один создаёт результат, другой его проверяет;

• researcher–analyst–writer: исследование отделено от интерпретации и оформления;

• debate: несколько агентов предлагают конкурирующие решения;

• supervisor–workers: координатор распределяет подзадачи между исполнителями;

• group chat: участники сами определяют, кто должен говорить следующим.

CrewAI и KaibanJS строились вокруг команды с ролями и задачами. В AutoGen главной метафорой стал разговор. Позднее Google ADK, OpenAI Agents SDK и другие системы предложили свои способы передавать задачи между агентами и объединять их в группы.

Где разговорная архитектура действительно сильна

Разговор хорошо работает там, где последовательность шагов нельзя определить заранее:

• исследование малоизученной темы;

• поиск нескольких альтернатив;

• анализ неоднозначного документа;

• формирование и критика гипотез;

• разделение большого контекста;

• независимая проверка решения;

• взаимодействие с человеком в ходе работы.

Так удобно делать и первые прототипы: идея проверяется несколькими десятками строк без полноценного workflow.

Где начинается «театр агентов»

«Театр агентов» начинается, когда несколько одинаковых вызовов LLM изображают команду. Если у «аналитика» и «критика» одни данные, инструменты и права, разные должности не создают специализацию: агенты повторяют друг друга и совершают похожие ошибки.

В production роли должны различаться контекстом, инструментами или полномочиями, а порядок работы и условие завершения лучше задавать в коде.

---

2024: графы задают структуру работы агентов

В январе 2024 года появился LangGraph. В нём агентное приложение описывается как граф: есть состояние, узлы и переходы между ними. В графе могут быть не только последовательные шаги, но и циклы, ветвления и возвраты.

Изменился сам взгляд на систему.

В системе, построенной вокруг разговора, главный вопрос звучит так:

кто кому что сказал?

В системе, построенной вокруг графа, вопросы другие:

где находится процесс,что уже сделанои какой переход разрешён следующим?

Например, этапы исследовательской задачи можно описать явно:

получена задача  → построен план  → собраны источники  → проверена полнота  → написан черновик  → выполнена критика  → получено подтверждение человека  → опубликован результат

Модель всё ещё принимает решения, но только внутри заданной структуры. Это похоже на возвращение к обычным workflow и конечным автоматам. Отчасти так и есть, но это не шаг назад.

Надёжная агентная система разделяет два типа логики.

Детерминированная логика:

• проверить наличие обязательных полей;

• сохранить результат;

• запросить подтверждение;

• повторить операцию после сетевой ошибки;

• перейти в состояние approved;

• не выполнять платёж дважды.

Вероятностная логика:

• определить намерение пользователя;

• выбрать стратегию поиска;

• разбить задачу на подзадачи;

• оценить качество черновика;

• решить, достаточно ли информации;

• выбрать подходящий инструмент.

Не стоит поручать модели то, что обычный код выполнит точнее и надёжнее.

Google ADK использует похожее разделение. Workflow agents Sequential, Parallel и Loop задают понятный порядок выполнения, а LLM-агенты принимают решения внутри этой структуры.

---

Современный агент — это стек, а не библиотека

К 2025–2026 годам стало очевидно: ни один агентный фреймворк не охватывает все задачи, необходимые для построения полноценной агентной системы. Поэтому современную агентную систему правильнее рассматривать как многослойный технологический стек:

Схема показывает зоны ответственности, а не строгий порядок зависимостей. Например, наблюдаемость, безопасность, аудит и evals нужны на всех уровнях.

Разберём ключевые части стека и связанные с ними инженерные задачи.

---

Agent SDK, graph runtime, harness и готовый агент — не одно и то же

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

Универсальные Agent SDK

Универсальный Agent SDK даёт основу для собственного агента, но не определяет, чем тот должен заниматься. Разработчик получает готовый цикл выполнения, инструменты и управление состоянием, а архитектуру приложения выбирает сам.

OpenAI Agents SDK поддерживает цикл выполнения, инструменты, handoffs, sessions, guardrails, tracing и паузы для подтверждения человеком. Runtime сам чередует вызовы модели и инструментов, пока не получит итоговый ответ или не передаст задачу другому агенту.

Google ADK предлагает похожий набор возможностей и чётко разделяет LLM-агентов и workflow agents. ADK доступен для нескольких языков, включая TypeScript.

Mastra, VoltAgent, Strands, BeeAI Framework, Genkit и LangChain относятся к той же категории. Они помогают строить собственные приложения вокруг моделей, инструментов, workflow, памяти и наблюдаемости.

TanStack AI находится между универсальным Agent SDK и клиентским слоем. Это headless-фреймворк для TypeScript: сервер выполняет цикл model–tool–model, инструменты имеют типизированные схемы входа и выхода, а отдельный вызов можно остановить и показать пользователю для подтверждения.

Agent SDK подходит, если вы хотите собрать агента под свою задачу, но не хотите писать базовый цикл с нуля. Если порядок выполнения нужно задать и контролировать явно, понадобится графовый runtime.

Графовые runtime

В обычном agent loop (цикл «модель → инструмент → результат → следующий шаг») модель сама выбирает следующий шаг. В графовом runtime состояния, переходы, ветвления и паузы задаются в коде. Так проще сочетать гибкие решения LLM со строгими правилами.

LangGraph рассчитан именно на такие процессы с состоянием. Он поддерживает условные переходы, checkpoints, возобновление работы и human-in-the-loop.

Mastra Workflows предлагает похожий подход для TypeScript. Процесс собирается из типизированных шагов, которые можно выполнять последовательно или параллельно. Есть условия, циклы и общее состояние. Внутри шагов вызываются агенты и инструменты, а Mastra Studio показывает граф выполнения. Таким образом, Mastra совмещает Agent SDK и workflow runtime.

Dify и Flowise Agentflow переносят похожую оркестрацию в визуальный low-code-интерфейс: в одном графе сочетаются обычные шаги, LLM, инструменты, ветвления и human-in-the-loop. Это другой способ описать workflow, а не отдельная агентная архитектура.

XState работает на более низком уровне. Это JavaScript/TypeScript runtime для конечных автоматов, statecharts и actor systems, а не специальный LLM-фреймворк. Пакет Stately Agent позволяет модели управлять такой машиной через типизированные события. Этот вариант подходит, если LLM должна выбирать только из заранее разрешённых переходов.

LangGraph и Mastra строят граф вокруг AI-компонентов. XState, наоборот, встраивает AI-компонент в более строгую машину состояний.

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

Opinionated harness

Harness находится между универсальным SDK и готовым агентом. Кроме цикла и инструментов, он задаёт правила работы с контекстом, файлами, командами и средой выполнения.

Deep Agents добавляет файловую систему, skills, субагентов и разбиение больших задач на части.

Flue предлагает похожую harness-first архитектуру для TypeScript: sessions, tools, skills, файловую систему, sandbox и субагентов. В основе Flue лежит Pi — небольшой расширяемый coding harness, который можно использовать отдельно через CLI или SDK.

Новый eve от Vercel объединяет сразу несколько слоёв: агент описывается каталогом с инструкциями, skills и инструментами, разговор выполняется как durable workflow, а код запускается в отдельном sandbox. Это свежий пример того, почему границы между harness, runtime и готовой платформой постепенно размываются.

Исследование SWE-agent показало, что результат зависит не только от модели, но и от интерфейса между агентом и компьютером. Поэтому harness — это часть решения, а не просто нейтральная оболочка вокруг LLM.

Практическую сторону этого тезиса подробно разбирают русский перевод статьи Себастьяна Рашки о coding harness и инженерный отчёт OpenAI Harness engineering: качество агента определяется также доступными командами, структурой репозитория, тестами, обратной связью и тем, насколько среда помогает модели замечать собственные ошибки.

Готовые специализированные агенты

Здесь основной цикл, рабочая среда и инструменты уже настроены под конкретный тип задач. Разработчик встраивает готового агента и настраивает модели, права, hooks и интерфейс приложения.

Claude Agent SDK даёт программный доступ к возможностям Claude Code: работе с файлами, запуску команд, hooks, субагентам и MCP.

Codex SDK позволяет встроить готовый runtime для coding agent с sessions, потоком событий, tool calls, изменением файлов и structured output.

GitHub Copilot SDK открывает программный доступ к runtime из Copilot CLI. Ещё один вариант — OpenCode, готовый open-source coding agent с headless-сервером и TypeScript SDK.

Такие решения можно расширять, но проектировать агента с нуля уже не нужно: разработчик встраивает готовый coding harness.

Появляются и интеграционные слои поверх готовых агентов. Vercel AI SDK 7 не только позволяет создавать собственных агентов, но и через экспериментальный HarnessAgent приводит готовые coding harness к общему интерфейсу. В первом наборе адаптеров доступны Claude Code, Codex и Pi; каждый новый harness требует отдельного адаптера, но интерфейс и код приложения меньше зависят от API конкретного агента. На других границах системы похожую роль играют рассмотренные ниже протоколы: A2A унифицирует связь между агентами, а AG-UI — между агентом и пользовательским интерфейсом.

---

Durable execution: агент должен пережить собственный процесс

Durable execution — это подход к выполнению долгих процессов, при котором система сохраняет состояние и историю завершённых шагов. После сбоя, перезапуска или длительного ожидания она может продолжить работу с нужного места, не повторяя уже выполненные действия.

Обычный скрипт живёт, пока работает его процесс. Агентная задача может длиться часы или даже дни.

Например, агент помогает согласовать договор:

1. получает документы;

2. извлекает условия;

3. передаёт спорные пункты юридическому агенту;

4. ждёт ответа сотрудника;

5. запрашивает согласование руководителя;

6. получает новую версию контрагента;

7. продолжает работу через три дня.

Такой процесс нельзя держать только в памяти одного Node.js-сервера. Он должен пережить перезапуск, deployment, сетевую ошибку и несколько дней ожидания.

Temporal сохраняет историю workflow и восстанавливает состояние по записанным событиям. Если worker упадёт, работа продолжится с сохранённого места.

Restate поддерживает durable execution и адресуемые компоненты с состоянием, включая virtual objects. Workflow можно поставить на паузу, а затем продолжить с того же места.

Inngest даёт похожие возможности для event-driven разработки на TypeScript. Поверх них построены AgentKit и agent networks. Отдельные агенты в такой сети могут быть простыми: общее состояние и историю работы хранит runtime.

Cloudflare Agents связывает агента с Durable Object и предоставляет состояние, SQL, WebSockets, планирование событий и восстановление. Агент может «спать», не занимая вычислительные ресурсы, и проснуться, когда произойдёт нужное событие.

Electric Agents подходит к durable execution со стороны данных и синхронизации. Каждый агент представлен адресуемой сущностью, а его состояние и история — долговечным потоком событий (durable stream), куда записываются сообщения, вызовы инструментов и изменения состояния. Благодаря этому агент может «засыпать», просыпаться по событию и переживать перезапуски, а его сессию можно наблюдать, воспроизводить и ответвлять. В мультиагентной системе обмен сообщениями и координация сводятся к синхронизации таких потоков.

При этом Electric Agents не заменяет Agent SDK: внутри он использует pi-agent-core, добавляя к agent loop долговечность, адресацию и реактивную синхронизацию.

Durable agent runtime — новая архитектура или обычный workflow?

Короткий ответ: и то и другое.

Таймеры, retries, очереди, адресуемое состояние и восстановление существовали задолго до LLM. Нет смысла заново писать их в каждом агентном фреймворке.

Но агент с LLM добавляет новые проблемы:

• повторный model call может дать другой результат;

• путь выполнения заранее неизвестен;

• нужно сохранять не только данные, но и принятые решения;

• повтор tool call может вызвать побочный эффект;

• модель может выбрать другой инструмент после восстановления;

• контекст приходится сжимать, не теряя важных обязательств.

Durable agent runtime не изобретает долговременное выполнение заново. Он добавляет к проверенным workflow-механизмам поддержку модели, чьи решения нельзя точно предсказать.

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

---

Sandbox: агент получил инструменты — теперь нужны границы

С инструментами агент получает возможность не только написать неверный ответ. Он может прочитать секреты, изменить файлы, запустить опасный код или отправить данные наружу.

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

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

Terminal-Bench и Harbor напоминают ещё об одном правиле: агента с инструментами нужно оценивать по изменениям в реальной среде, а не только по его итоговому сообщению.

Главный вопрос здесь не «выберет ли модель правильное действие?», а «что агент может прочитать, изменить и отправить — и насколько далеко распространится ошибка?»

---

Browser agents и computer use: работа через интерфейс

Browser agent — это частный случай computer use. Первый работает в браузере, а второй может управлять также desktop- и mobile-приложениями. В отличие от API, пользовательский интерфейс постоянно меняется: появляются окна, формы входа, неоднозначные элементы и подтверждения. Поэтому одного вызова инструмента недостаточно. Агент работает в цикле «наблюдение → действие → новое состояние».

Инструменты решают разные части этой задачи. Playwright и Chrome DevTools Protocol дают предсказуемое управление браузером. Stagehand и Browser Use добавляют AI-операции. Browserbase предоставляет управляемые браузерные сессии, а BrowserGym помогает разрабатывать и оценивать агентов.

Computer use есть и в модельных API: OpenAI API, Claude API и Gemini API. Модель видит состояние интерфейса и предлагает действие, а выполняет его приложение.

В надёжной системе известные шаги выполняет обычная автоматизация. Модель подключается там, где интерфейс неоднозначен. Действия с необратимыми последствиями проверяются отдельно.

---

Протоколы связывают разные части системы

По мере роста экосистемы появились протоколы для связи между разными частями системы.

MCP: агент и инструменты

Model Context Protocol описывает связь AI-приложения с инструментами, данными и prompt-ресурсами. Сервер объявляет свои возможности, а клиент находит их и показывает модели. MCP унифицирует способ подключения, но не заменяет сами API, авторизацию и правила доступа.

A2A: агент и агент

В апреле 2025 года Google представила Agent2Agent Protocol — A2A. Он помогает общаться агентам разных поставщиков и систем. В июне того же года проект перешёл под управление Linux Foundation.

Если MCP отвечает на вопрос:

Какими инструментами я могу воспользоваться?

то A2A отвечает:

Какой внешний агент способен выполнить эту задачу и как отслеживать её выполнение?

В A2A есть Agent Card — машиночитаемая карточка с данными об агенте, его возможностях, skills и требованиях к авторизации. По сути, это цифровая визитка сервиса.

AG-UI: агент и пользовательский интерфейс

AG-UI описывает события между backend агента и frontend: жизненный цикл задачи, сообщения, tool calls, изменения состояния и действия пользователя.

ACP: coding agent и редактор

Agent Client Protocol стандартизует связь coding agent с IDE или другим клиентом. Его часто сравнивают с Language Server Protocol: редактору не нужно знать, как устроен каждый агент изнутри.

OpenTelemetry и OpenInference: runtime и наблюдаемость

OpenTelemetry даёт независимую от поставщика основу для traces, metrics и logs. OpenInference добавляет понятия, связанные с моделями, агентами, tools и sessions.

Протоколы не конкурируют друг с другом: каждый отвечает за свою границу.

MCP      агент ↔ инструменты и данныеA2A      агент ↔ внешний агентAG-UI    agent backend ↔ frontendACP      coding agent ↔ IDE или клиентOTel/OpenInference  runtime ↔ observability

Скорее всего, многие из этих протоколов проживут дольше, чем современные API отдельных фреймворков.

---

Память — это четыре разные проблемы под одним названием

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

Под одним словом скрываются как минимум четыре разные вещи.

История разговора

Сообщения, которые нужны, чтобы продолжить текущий диалог.

Checkpoint процесса

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

Retrieval

Поиск нужной информации во внешних документах, базе знаний или индексе.

Persistent agent memory

Факты, предпочтения и прошлый опыт, которые агент помнит между отдельными сессиями.

На практике эти задачи решают разные инструменты:

Mem0 предлагает API для долговременной памяти между сессиями, инструментами и запусками.

Zep и Graphiti представляют память как knowledge graph, который меняется со временем. Это полезно, когда старый факт не стоит просто удалять. Например, утверждения «пользователь живёт в Стокгольме» и «пользователь переехал в Берлин» не противоречат друг другу, если относятся к разным периодам.

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

LlamaIndex.TS сосредоточен на retrieval и context engineering: система должна передать модели нужную внешнюю информацию именно тогда, когда она понадобится.

Обзоры Memory in the Age of AI Agents и Graph-based Agent Memory описывают память как постоянный цикл: информацию нужно сформировать или извлечь, сохранить, найти, обновить или опровергнуть. MemGPT рассматривает более узкую идею: несколько уровней памяти и управление ограниченным контекстом по аналогии с виртуальной памятью.

Практический взгляд дополняет русскоязычный разбор четырёх разных смыслов «памяти» агента: документы, механизм поиска, рабочее состояние и накопленный опыт требуют разных решений. Материалы Letta Agent Memory и Weaviate Context Engineering показывают ту же проблему со стороны управления контекстом: важно не только сохранить факт, но и решить, когда его добавить, обновить, извлечь или удалить из рабочего контекста.

---

Tool calling не равен праву совершать действие

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

Composio объединяет интеграции, пользовательские sessions, подключённые аккаунты и authentication. Credentials принадлежат конкретному пользователю, а не передаются модели как один общий секрет.

Arcade работает как action runtime: управляет OAuth, токенами, policies и разрешением отдельных действий.

Auth0 развивает delegated authorization. Агент действует от имени пользователя, но не получает его пароль или исходные credentials. Однако одного OAuth часто недостаточно: широкий token scope может дать агенту больше прав, чем нужно для конкретной задачи.

Представим агента для путешествий. Пользователь просит:

Найди подходящий рейс и забронируй его не дороже 400 евро.

На разных шагах агенту нужны разные права:

1. искать рейсы — без подтверждения;

2. читать профиль лояльности — с ограниченным доступом;

3. выбрать вариант — самостоятельно;

4. провести оплату — только после явного подтверждения;

5. изменить бронирование — в пределах конкретного заказа;

6. заказать дополнительные услуги — запрещено.

Один OAuth token с широкими правами не может выразить такие ограничения. Поэтому важнее спрашивать не «какие tools подключены?», а: «Чьими полномочиями, в каком объёме и при каких условиях агент может воспользоваться?»

В production процесс бронирования может выглядеть так:

запрос пользователя→ workflow создаёт задачу, лимит стоимости и бюджет выполнения→ агент исследует варианты через read-only tools→ policy engine проверяет выбранное действие и его параметры→ человек подтверждает конкретный рейс и итоговую сумму→ idempotent tool выполняет бронирование→ durable runtime сохраняет состояние и audit trail→ verifier проверяет билет и ограничения заказа→ trace попадает в набор для последующих evals

Пример такого внешнего слоя — Microsoft Agent Governance Toolkit. Он проверяет tool calls детерминированными policies до исполнения, может разрешить, запретить или отправить действие на подтверждение и записывает решение в audit trail. Проект пока находится в Public Preview, поэтому здесь важнее сама архитектурная граница, чем конкретная реализация.

Модель решает неоднозначные задачи внутри процесса. Но каждое действие, которое меняет внешний мир, проходит отдельную проверку.

---

Model routing и fallback: одна система — несколько моделей

Production-агенту необязательно выполнять все шаги одной моделью. Сильную и дорогую можно использовать для планирования и сложных решений. Более дешёвой поручить классификацию, извлечение данных и простые преобразования. Ещё одну модель можно использовать для независимой проверки. Router выбирает модель с учётом задачи, риска, размера контекста, SLA и бюджета.

Fallback не должен означать «при ошибке вызвать любую другую модель». Конфигурации отличаются поддержкой tool schemas, размером контекста, поведением на границах безопасности и правилами обработки данных. Каждый маршрут нужно проверять одними и теми же evals. В trace следует записывать модель, её версию, prompt и набор tools. Переключаться можно только между конфигурациями, которые действительно совместимы.

---

Наблюдаемость: нужно видеть не только ответ, но и путь

Обычное приложение часто можно проверить по входным и выходным данным. С агентом этого недостаточно.

Два запуска могут закончиться одинаковым ответом, но пройти совсем по-разному:

• один использовал надёжный источник;

• другой придумал факт;

• один вызвал три инструмента;

• другой — тридцать;

• один запросил подтверждение;

• другой совершил действие самостоятельно.

Поэтому наблюдать нужно за всей траекторией агента (trajectory) — последовательностью шагов от запроса до результата.

Работы AI Agents That Matter и Survey on Evaluation of LLM-based Agents показывают, что evals должны проверять не только результат. Важно измерять допустимость выбранного пути, повторяемость, стоимость, задержку, восстановление после сбоя и частоту вмешательства человека. Высокая точность может скрывать дорогую, нестабильную или небезопасную систему.

Как превратить эти принципы в инженерный процесс, показывают руководство Anthropic Demystifying evals for AI agents, большой русскоязычный практикум по evals и разбор оценки траекторий агента. В них есть прикладные схемы для тестовых наборов, программных проверок, LLM-судей, оценки tool calls и регрессионного тестирования в CI.

OpenAI Agents SDK записывает генерации модели, tool calls, handoffs и guardrails в traces и spans.

LangSmith позволяет оценить итоговый ответ, отдельные шаги и весь путь, включая порядок вызова инструментов.

Phoenix использует OpenTelemetry и OpenInference и помогает построить наблюдаемость без жёсткой привязки к поставщику.

Langfuse объединяет production-наблюдаемость и оценку качества. Неудачный trace можно добавить в тестовый набор, а затем сравнить на нём новую версию prompt, модели или кода. Оценку может дать программа, LLM-судья, сотрудник или пользователь. Тот же подход работает и для уже запущенной production-системы.

Promptfoo сосредоточен на локальных regression tests и red teaming, включая проверки tool use и prompt injection.

Evalite решает более узкую задачу в TypeScript-проектах. Evals хранятся рядом с кодом в файлах .eval.ts, запускаются локально и в CI, а результаты видны в локальном интерфейсе. Если score падает ниже порога, сборку можно остановить. Evalite построен поверх Vitest и подойдёт командам, которым нужен привычный code-first test runner без отдельной платформы наблюдаемости.

Стоимость — часть качества

Важно не только получить правильный ответ, но и понимать его цену. В production стоит отслеживать:

• success rate и cost per successful task;

• медианную и p95-задержку;

• число model calls и tool calls;

• долю повторных попыток и восстановлений;

• расход контекста и попадания в cache;

• частоту эскалаций человеку;

• rate limits и исчерпание бюджета.

Эти метрики влияют на архитектуру не меньше точности. Дополнительный planner, critic или retrieval step нужен только тогда, когда выигрыш в надёжности оправдывает задержку и стоимость.

---

Безопасность агента: контролировать нужно не только текст, но и действия

Для агента недостаточно проверять запрос и итоговый ответ. Вредоносная инструкция может находиться на веб-странице, в письме, документе, результате инструмента или сохранённой памяти. Если модель примет такие данные за команду, возникнет indirect prompt injection.

AgentDojo, InjecAgent и Agent Security Bench показывают, что одного входного фильтра мало. Нужны минимальные права, проверки tool calls и тестирование всего пути агента. Guardrails могут остановить действие или запросить подтверждение, но права должны контролироваться на уровне runtime.

Практическую модель защиты дают русскоязычное руководство OpenAI по устойчивости агентов к prompt injection, глубокий русскоязычный разбор архитектурных защит и независимый OWASP Guide for Secure Agentic Applications. Общий принцип этих материалов: недоверенные данные нужно отделять от инструкций, а возможный ущерб ограничивать правами, подтверждениями и проверками на границе каждого действия.

Отдельные правила нужны для работы с данными: что можно отправлять модели, где и как долго это хранить, как удалить и какие действия записать в журнал. Sandbox ограничивает среду агента, права доступа — его действия, а правила хранения защищают сами данные. Одно не заменяет другое.

---

Human-in-the-loop — это архитектура, а не сообщение «Вы уверены?»

Human-in-the-loop — это не просто кнопка подтверждения. Система должна остановить процесс, сохранить состояние, показать человеку конкретное действие, дождаться решения и продолжить работу без повторного выполнения уже завершённых шагов. Например, OpenAI Agents SDK умеет сохранять и возобновлять прерванный запуск.

В интерфейсе пользователь должен видеть план, ход выполнения, вызовы инструментов, результаты, ошибки и запросы на подтверждение. CopilotKit, assistant-ui и Vercel AI SDK UI помогают собрать такой интерфейс, а AG-UI описывает поток событий между backend и frontend.

---

Практики для надёжных production-систем

Теперь соберём основные правила, с которых стоит начинать production-систему.

Гибридный workflow с ограниченными агентными участками

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

Supervisor–worker вместо свободного группового чата

Центральный координатор распределяет независимые задачи, изолирует контексты, контролирует бюджет и собирает общий результат. Он не обязан быть LLM: если правила маршрутизации известны, обычный код справится надёжнее.

Durable execution

Если задача может выполняться дольше одного HTTP-запроса, состояние нужно сохранять, а процесс — уметь восстанавливать.

Sandboxed execution

Чем больше агент может сделать в реальном мире, тем важнее изолировать его среду.

Типизированные инструменты и протоколы

JSON Schema, OpenAPI, MCP и A2A надёжнее и лучше масштабируются, чем свободные текстовые договорённости между агентами.

Оценка траектории агента

Итоговый ответ не показывает, сколько стоил процесс, насколько он был безопасным и можно ли его повторить.

Явные permission boundaries

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

---

Упрощения, с которыми стоит быть осторожнее

Проблемы чаще связаны не с конкретной библиотекой, а с несколькими типичными решениями:

• Свободный group chat по умолчанию. Он полезен для brainstorming и прототипов, но в нём трудно гарантировать завершение, контролировать стоимость, ограничивать права и безопасно выполнять необратимые действия.

• Role-playing без специализации. Отдельный агент имеет смысл, если у него другой контекст, модель, инструменты или права, либо если он независимо проверяет результат или работает параллельно. Одного названия роли мало.

• Масштабирование количеством агентов. Если новый агент не приносит информацию или новую возможность, он лишь увеличивает число вызовов, потери контекста и риск одинаковых ошибок.

• Самописная распределённая инфраструктура. Если системе нужны очереди, timers, retries и блокировки, лучше взять проверенный durable runtime.

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

---

Агентные фреймворки дополняют, а не заменяют классическую архитектуру

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

• Stagehand добавляет модель поверх детерминированной браузерной автоматизации, а не заменяет Playwright;

• MCP унифицирует доступ к API и данным, а A2A связывает независимых агентов, не определяя их внутреннее устройство;

• LangGraph управляет агентной траекторией, но не отменяет Temporal или Restate для сложных межсервисных процессов;

• Agent SDK не заменяет sandbox, а vector database — политику памяти;

• low-code-платформы не отменяют библиотеки, а дают другой способ управления системой.

Agent frameworks чаще заменяют самописный glue code: цикл model–tool, сохранение состояния, handoffs, tracing, streaming и approval flow. Базовую инфраструктуру под ними они обычно не заменяют.

---

Как выбрать минимально достаточную архитектуру

Сначала выберите минимальную схему управления моделью, затем добавьте только те инфраструктурные слои, которые нужны из-за длительности процесса, среды выполнения, прав доступа и требований production.

Сначала выберите способ управления моделью

Затем добавьте необходимые инфраструктурные слои

Симуляция и обучение политик — отдельный класс задач. Современные LLM-фреймворки не заменяют multi-agent reinforcement learning или agent-based modeling.

Если нужно научить роботов координироваться, смоделировать движение транспорта или изучить поведение тысяч участников рынка, разговор нескольких LLM может вообще не подойти.

---

Модель — часть системы, а не её центр

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

Playwright остаётся под browser agent. Изолированная среда — под агентом, исполняющим недоверенный код. Workflow engine — под долгоживущим процессом. OAuth — под tool call. Distributed tracing — под agent observability. База данных — под памятью.

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

Будущее мультиагентных технологий — не в максимальном количестве автономных персонажей. Главное — понять, какие решения можно доверить агентам, какие лучше оставить обычному коду и какие границы помогут им безопасно работать вместе.