От одного агента к системе специализированных агентов

Для локальной задачи достаточно одного AI-агента: он получает контекст, выполняет операцию и возвращает результат. Когда задача включает несколько этапов и инструментов, её можно разделить между несколькими агентами.

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

• спецификация → реализация → проверка → исправление → повторная проверка.

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

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

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

Как устроена оркестрация

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

Каждый агент работает в собственном контексте и получает определённую зону ответственности. Например:

• планировщик формирует структуру задачи;
• агент разработки реализует компонент;
• тестовый агент проверяет результат;
• отдельный агент может анализировать конкретный тип ошибки.

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

1. задача разбивается на этапы;
2. для каждого этапа определяется агент и необходимый ему контекст;
3. результат передаётся следующему этапу или отправляется на проверку;
4. после завершения процесса разработчик проводит финальное ревью.

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

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

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

Паттерны оркестрации AI-агентов

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

1) Pipeline: последовательный конвейер

Pipeline — паттерн, при котором несколько AI-агентов выполняют последовательные этапы одной задачи: результат одного агента становится входными данными для следующего. Например:

• планирование → реализация → проверка.

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

2) Critic Loop: цикл критической оценки

Critic Loop разделяет генерацию и проверку:

• генерация → оценка → исправление → повторная оценка.

Один агент выполняет задачу, другой анализирует результат и формирует замечания. После этого исходный результат дорабатывается.

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

3) Divide & Conquer: декомпозиция задачи

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

Например, разработка сервиса может быть разделена на API, бизнес-логику, тесты и документацию. Каждый агент получает собственную часть задачи, после чего результаты объединяются в единое решение.

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

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

4) Router Pattern: маршрутизация задач

Router анализирует входящий запрос и направляет его подходящему агенту.

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

5) Planning Pattern: планирование

Сначала отдельный агент формирует план выполнения задачи, затем другие агенты реализуют его этапы.

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

6) Tool Use Pattern: внешние инструменты

Агент получает доступ к внешнему инструменту и использует его в рамках задачи.

Это могут быть API, базы данных, среда выполнения кода, браузер, Figma или другие системы. В таком сценарии агент генерирует результат и выполняет действия через подключённые инструменты.

7) Multi-agent Collaboration: взаимодействие агентов

Несколько агентов работают над одной задачей и обмениваются результатами.

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

На практике один процесс может сочетать несколько паттернов одновременно. Например, планирование может запускать последовательный Pipeline, отдельные части задачи выполняться параллельно, а критические этапы проходить через Critic Loop.

Инструменты для мультиагентных систем

Для построения таких систем используют фреймворки и инструменты для разработки ПО:

• LangGraph — графовая оркестрация с поддержкой циклов, состояний и памяти;
• Microsoft AutoGen — взаимодействие агентов через диалог и совместное выполнение задач;
• CrewAI — модель взаимодействия агентов с ролями и задачами;
• n8n — workflow-оркестратор, который можно использовать как основу для мультиагентных процессов;
• Codex — среда разработки с поддержкой субагентов.

Инструмент выбирают исходя из структуры процесса. Например, LangGraph подходит для графов с циклами и состояниями, CrewAI — для сценариев с явно заданными ролями, n8n — для workflow с большим количеством внешних интеграций.

Практика: разработка компонента с субагентами в OpenAI Codex

OpenAI Codex поддерживает работу с субагентами. Для каждого из них можно задать модель, профиль разрешений, sandbox, MCP-серверы и skills.

MCP (Model Context Protocol) связывает модель с внешними ресурсами и инструментами. В процессе разработки это могут быть браузер, Figma, документация проекта или другие подключённые системы.

Конфигурация субагентов

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

• model — модель;
• model_reasoning_effort — уровень рассуждений;
• sandbox_mode — режим изоляции;
• mcp_servers — подключённые MCP-серверы;
• skills.config — конфигурация skills.

Codex идентифицирует кастомного агента по полю name. Имя файла субагента соответствует этому значению как соглашение конфигурации.

nickname_candidates задаёт возможные псевдонимы для интерфейса. Они полезны, когда один агент запущен в нескольких экземплярах и их требуется различать. Идентификация при этом выполняется по name.

Настройки проекта можно определить в .codex/config.toml. Например:

[agents] max_threads = 6, max_depth = 1

max_threads задаёт максимальное число параллельных потоков субагентов, а max_depth — глубину вложенности их вызовов.

Для каждого субагента отдельно определяются модель, уровень рассуждений, права доступа к файлам, skills и MCP-серверы. Например, агенту, который только анализирует код, можно предоставить доступ на чтение, а инструмент, необходимый для внесения изменений, подключить только к агенту разработки.

Набор инструментов зависит от задачи. Браузерный MCP-сервер можно заменить на MCP-сервер Playwright, а поведение агента дополнительно определить через отдельный skill.

Сценарий разработки компонента

Рассмотрим разработку блока по макету в Figma. К проекту подключены:

• MCP-сервер Figma;
• MCP с документацией проекта и правилами текущего стека;
• набор skills для специализированных агентов.

Задача передаётся оркестратору:

• «Пусть planner прочитает макет с помощью Figma MCP и передаст информацию frontend, frontend реализует компоненты, tester проверит результат».

Оркестратор запускает планировщик. Тот анализирует макет и формирует данные для реализации. На их основе запускается агент разработки, который реализует компонент.

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

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

• «Выясните причину, по которой модальное окно не открывается при клике на кнопку в header. Пусть browser_debugger воспроизведёт ошибку, code_mapper отследит ответственный участок кода, а ui_fixer внедрит минимальное исправление. В конце browser_debugger сделает скриншот в папку artifacts».

Здесь каждый агент получает отдельную функцию:

• browser_debugger воспроизводит сценарий и фиксирует результат;
• code_mapper определяет участок кода, связанный с проблемой;
• ui_fixer вносит изменение;
• после исправления browser_debugger повторяет проверку и сохраняет артефакт.

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

После завершения процесса оркестратор останавливает запущенные субагенты. Итоговый код проходит ревью разработчика и передаётся в обычный процесс тестирования проекта.

После исправления багов тестировщик снова проходит по блоку и проверяет правки. Когда багов больше нет, оркестратор останавливает все запущенные субагенты.

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

Безопасность и изоляция

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

В конфигурации можно ограничить доступ к файлам, определить доступные MCP-серверы и задать режим sandbox. Для задач, где требуется дополнительный уровень изоляции, агенты запускаются в Dev Containers — контейнерах разработки.

Для сценариев с повышенными требованиями к изоляции используются отдельные виртуальные или физические машины.

Такой подход позволяет разделить среду выполнения агента и основную систему, а также контролировать доступ к:

• API-ключам и токенам;
• SSH-данным;
• файловой системе;
• зависимостям;
• сетевым ресурсам.

Изоляция в этом случае становится частью архитектуры мультиагентной системы наряду с маршрутизацией задач и контрактами между агентами.

Как определить количество агентов

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

• Количество агентов. Каждая новая роль добавляет собственный контекст и интерфейс взаимодействия. Агентов выделяют там, где отдельная ответственность даёт архитектурное преимущество.
• Latency. Последовательные вызовы увеличивают время выполнения. Вложенные вызовы, когда один субагент запускает другого, добавляют ещё один уровень задержки.
• Стоимость. Каждый вызов LLM расходует токены. Параллельные агенты увеличивают общий объём вычислений, поэтому бюджет учитывается на уровне архитектуры.
• Отладка. Распределённый процесс требует трассировки действий и результатов каждого агента. Чем больше взаимодействий, тем больше данных нужно учитывать при поиске причины ошибки.

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

Когда мультиагентная архитектура не нужна

Несколько агентов не всегда лучше одного. Если задача:

• выполняется в одном контексте;
• не требует разных инструментов;
• не предполагает независимой проверки;
• не содержит независимых этапов;
• не требует разных уровней доступа,

то отдельная оркестрация может быть избыточной.

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

Мультиагентную архитектуру имеет смысл вводить там, где специализация действительно упрощает процесс, повышает контролируемость или позволяет эффективно распараллелить независимые этапы.

Где проходит граница автоматизации

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

• результат работы недетерминирован;
• качество зависит от контекста и инструментов;
• сложные процессы требуют проверки промежуточных результатов.

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

Пять принципов проектирования

При построении мультиагентной системы можно использовать пять принципов.

1. Одна ответственность — один агент. Роль и зона ответственности агента определяются конкретной задачей.
2. Планирование отдельно от выполнения. Координирующий агент формирует последовательность действий, рабочие агенты выполняют отдельные этапы.
3. Проверка встроена в процесс. Для критических этапов заранее определяются механизмы валидации: тестовый агент, Critic Loop или автоматические проверки.
4. Сложные зависимости находятся на уровне оркестрации. Логика отдельного агента остаётся локальной, а взаимодействие между этапами описывается общей системой.
5. Между агентами существуют явные контракты. Формат входных и выходных данных определяется заранее, например через типизированные схемы.

Эти принципы задают границы системы и упрощают её развитие по мере роста количества задач и инструментов.

Частые вопросы

• Чем оркестрация отличается от одного AI-агента?

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

• Что такое мультиагентная система?

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

• Когда имеет смысл использовать несколько агентов?

Когда процесс состоит из независимых или последовательных этапов, которые можно разделить по ответственности, контексту, инструментам или набору прав доступа.

• Нужен ли отдельный оркестратор?

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

• Можно ли использовать субагентов без специализированного фреймворка?

Да. В Codex субагенты можно конфигурировать непосредственно на уровне проекта, задавая их модели, права доступа, skills и MCP-серверы.

• Какие недостатки есть у мультиагентной архитектуры?

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

• Кто отвечает за код, созданный AI?

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

Что меняет оркестрация AI-агентов

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

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

Команда Only проектирует и разрабатывает цифровые продукты под задачи бизнеса: анализирует процессы, выбирает архитектуру и выстраивает автоматизацию.