Мультиагентное взаимодействие

В описанных ранее OpenAI пяти уровнях возможностей AI (Уровень 1 Собеседник, Уровень 2 Мыслитель (Reasoners), Уровень 3 Агент, Уровень 4 Инноватор, Уровень 5 Организации (Organizations)) мультиагентное взаимодействие часто сравнивают с одним из путей к пятому уровню — нужно уточнить, что Organizations здесь означает уровень способности «AI может выполнять работу целой организации», а не требование к архитектуре системы: достаточно мощный единичный агент теоретически тоже может достичь этого уровня. Но применительно к сегодняшней инженерной реальности одиночный агент всё же ограничен возможностями своей модели и размером окна контекста.

А совместная работа нескольких агентов значит гораздо больше, чем просто позволить агентам с разной специализацией «дополнять друг друга». Более фундаментальный момент в том, что интеллект группы может превышать интеллект отдельной особи. Человеческая цивилизация — тому доказательство: интеллект отдельного человека ограничен, но благодаря разделению труда, сотрудничеству, дискуссиям и межпоколенческому накоплению знаний интеллект, который демонстрирует человеческое общество как целое, намного превосходит интеллект любого отдельного гения. У сообщества агентов может возникнуть точно такой же коллективный интеллект: даже если каждый агент по отдельности соответствует уровню человеческого эксперта, при правильной организации их совокупные возможности могут превзойти сумму возможностей всех человеческих экспертов вместе взятых. Google DeepMind в работе «От AGI к ASI» прямо называет «крупномасштабные мультиагентные коллективы» одним из ключевых путей к суперинтеллекту (ASI) — подобно тому как общий интеллект людей может складываться в социальные и организационные структуры, превосходящие отдельного человека, «коллективный интеллект», возникающий из совместной работы множества агентов уровня AGI, тоже может проявлять когнитивные возможности, значительно превышающие простую сумму его участников¹. Поэтому мультиагентное взаимодействие — это не просто инженерный приём для преодоления ограничений окна контекста и возможностей одной модели, а, возможно, фундаментальный путь от «AI экспертного уровня» к «превосходству над человечеством в целом».

Классификационная схема мультиагентного взаимодействия

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

Измерение первое: разделяется ли контекст

Это самое базовое архитектурное решение, определяющее, как информация передаётся между несколькими агентами.

Общий контекст означает, что последующий агент получает полную историю диалога и траекторию (trajectory, определённую в главе 1) предыдущего агента. При переключении системного промпта и набора инструментов на каждом этапе фактически возникает новый агент (потому что меняются его роль, обязанности и возможности), но при этом он сохраняет всю память предшественника. Например, в команде аналитик по требованиям написал документ с требованиями — разработчик получает не только сам документ, но и видит всю переписку аналитика с пользователем: это новая роль, но с полностью сохранённым предыдущим контекстом. Преимущество в том, что информация не теряется — каждый агент может обратиться к деталям любого предыдущего этапа; сложность в том, что контекст может быстро разрастаться.

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

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

• Параметры вызова инструмента: вышестоящий агент передаёт структурированные данные как параметры инструменту нижестоящего агента — подходит для сценариев, где нужны чёткая типизация и понятная структура;
• Общая файловая система: агенты обмениваются информацией, читая и записывая документы, код и другие промежуточные продукты в общем каталоге — подходит для случаев с крупными артефактами или необходимостью персистентности;
• Шина сообщений (Message Bus): специальный посредник, отвечающий за передачу сообщений между агентами; агенты не вызывают друг друга напрямую, а отправляют сообщение в шину, которая пересылает его целевому агенту.

Если сопоставить с двумя парадигмами IPC: общая файловая система — это «разделяемая память» мира агентов; параметры вызова инструмента и шина сообщений — две формы «передачи сообщений», где первая передаётся синхронно вместе с вызовом, а вторая доставляется асинхронно через посредника. У обеих парадигм есть свои компромиссы. В языке Go есть широко известная фраза: «Не общайтесь через разделяемую память — вместо этого разделяйте память через общение» — разделяемая память быстра, но оставляет пользователю опасность конкурентных конфликтов; передача сообщений требует больше кода оркестрации, но делает принадлежность данных ясной и прослеживаемой. Этот компромисс будет снова и снова возникать далее — в запросе состояния и в конкурентных конфликтах.

Шина сообщений естественным образом поддерживает асинхронную коммуникацию — отправителю и получателю не нужно быть онлайн одновременно, как в корпоративной почтовой системе: отправляя письмо коллеге, вы не требуете, чтобы он в этот момент сидел за компьютером — письмо хранится на сервере, пока коллега не выйдет на связь и не обработает его. Такой способ особенно подходит для сценариев, где несколько агентов работают параллельно и нуждаются во взаимной координации (подробнее в разделе «Параллельная координация» этой главы).

Стоит уточнить: обе архитектуры представляют собой настоящие многоагентные системы (поскольку системный промпт и набор инструментов на каждом этапе отличаются — это разные агенты), различие в способе координации. Общий контекст опирается на неявную координацию — последующий агент наследует полную историю контекста предыдущего, «видит» его ход рассуждений, информация передаётся через сам контекст. Раздельный контекст опирается на явную координацию — агенты обмениваются информацией через файлы, сообщения или интерфейсы структурированных данных, каждый агент видит только относящееся к нему содержимое.

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

Знакомый с операционными системами читатель узнает в этой паре выбор: общий контекст — это потоки, раздельный контекст — это процессы. Потоки разделяют адресное пространство, переключаются с малыми накладными расходами, для коммуникации не нужно копирование, но платой становится отсутствие изоляции — один поток испортит память, и весь процесс рухнет вместе с ним; у процессов же каждое своё независимое адресное пространство, изоляция полная, можно безопасно работать параллельно, но платой становится необходимость явного IPC для коммуникации. Каждый критерий выбора в таблице 10-1 выводится именно из этого набора компромиссов.

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

Таблица 10-1. Критерии выбора между общим и раздельным контекстом

Критерий выбора	Общий контекст	Раздельный контекст
Количество подзадач	Мало (2–3 роли)	Много (требуется параллельная обработка)
Окно контекста	Достаточно для информации всех ролей	Не помещается в одно окно
Степень параллелизма	В основном последовательная (роли сменяют друг друга вдоль одной траектории)	Возможен масштабный параллелизм (контексты независимы, не блокируют друг друга)
Изоляция информации	Не требуется (все роли делят информацию)	Требуется (например, проверка безопасности не должна видеть исходный ход рассуждений)
Бюджет	Одна траектория передаётся по эстафете, токены накапливаются по этапам	Каждый агент разворачивается отдельно, суммарный расход токенов обычно в разы или на порядок выше

Простое правило: если ожидаемый накопленный контекст превысит 50% окна (это эмпирическое правило, а не точный порог), стоит выбирать раздельный контекст; если нулевые потери информации — жёсткое требование для корректности задачи, стоит выбирать общий контекст; в большинстве реальных систем применяется «поэтапная» схема — первые несколько агентов работают с общим контекстом, а по достижении точки насыщения информацией происходит переключение на раздельный контекст с явной передачей (handoff, то есть вышестоящий агент сам решает, какую информацию передать нижестоящему).

Измерение второе: топология взаимодействия

Второе измерение — топология взаимодействия: по какой структуре между агентами перемещаются управление и информация. Топология взаимодействия и разделение контекста концептуально независимы, но практически взаимосвязаны: концептуальная независимость объясняется тем, что у систем с общим контекстом тоже есть топология — например, представленный далее в этой главе transfer_to_agent (эксперимент 10-2) по сути представляет собой цепочку передач (handoff) в форме общего контекста; практическая взаимосвязь объясняется тем, что при выборе общего контекста топология обычно вырождается (см. ниже), то есть значения этих двух измерений нельзя комбинировать произвольно. При общем контексте передаче не нужно решать, «что передавать» — полная история сохраняется естественным образом, — поэтому топология обычно вырождается в последовательность смены ролей без особых архитектурных решений (промежуточный случай между двумя крайностями — взаимодействие нескольких сторон в формате group chat, о нём в разделе о децентрализованной модели далее в этой главе). А как только выбирается раздельный контекст, вопрос «как течёт информация и кто координирует» становится тем, что нужно явно проектировать.

Терминология: Graph-инженерия. Термин Graph Engineering, получивший распространение в июле 2026 года, в современном агентном контексте обычно означает явное проектирование графа выполнения: узлами выступают агенты, обычные программы или человеческие решения; рёбра задают зависимости задач, условную маршрутизацию и пути обработки сбоев; структурированное состояние перемещается между узлами². Рассматриваемая в этой главе «топология взаимодействия» — мультиагентное подмножество этой идеи: равноправное сотрудничество, оркестрация менеджером и децентрализованные передачи представляют разные топологии графа. Поскольку название ещё ново и его легко спутать с графами знаний, GraphRAG и трассами выполнения, основными терминами книги остаются более устоявшиеся «топология взаимодействия» и «оркестрация».

Иными словами, эти два измерения в принципе образуют матрицу 2×3 (общий/раздельный контекст × три топологии), но в строке «общий контекст» топология в основном вырождается в последовательность смены ролей без особых архитектурных решений (именно эту форму рассматривает далее раздел «Многоэтапная смена ролей»), поэтому в этой главе подробно рассматриваются только три ячейки для раздельного контекста. Ниже описаны три типичные формы топологии взаимодействия при раздельном контексте, в порядке возрастания сложности:

• Модель равноправного сотрудничества (Peer Collaboration Pattern): небольшое число агентов (как правило, 2–3) взаимодействуют на равных, образуя цикл итеративного улучшения — как при написании статьи, когда один человек делает черновик, а другой вносит правки и комментарии, и после нескольких раундов качество получается намного выше, чем при единоличной работе.
• Модель оркестрации (Orchestration Pattern): централизованный Manager Agent отвечает за планирование и распределение задач, несколько подчинённых агентов занимаются конкретными подзадачами — как менеджер проекта, руководящий несколькими инженерами-специалистами.
• Децентрализованная модель (Decentralized Pattern): нет центрального управляющего звена во время выполнения, агенты общаются друг с другом как люди, совместно выполняя задачу.

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

Когда мультиагентное взаимодействие действительно превосходит одного агента

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

Таблица 10-2 обобщает, вносят ли различные модели взаимодействия новую информацию, — это помогает определить, есть ли у мультиагентного взаимодействия реальная ценность по сравнению с одним агентом.

Таблица 10-2. Сравнение прироста информации в разных моделях мультиагентного взаимодействия

Модель взаимодействия	Вносится ли новая информация	Эффект
Модель сама проверяет свой результат (повторное прочтение собственного вывода)	Нет	Обычно неэффективно или даже вредно
Разные агенты обсуждают один и тот же текст	Нет	При равном объёме вычислений на уровне одного агента
Reviewer проверяет код по результатам выполнения тестов	Да (обратная связь от выполнения)	Значительное улучшение
Reviewer проверяет фронтенд-код/код PPT по скриншотам рендеринга	Да (визуальная обратная связь)	Значительное улучшение
Reviewer проверяет факты с помощью внешних инструментов	Да (обратная связь от инструмента)	Значительное улучшение

RLEF (Reinforcement Learning from Execution Feedback)³ 2025 года подтверждает это: обучение модели с подкреплением на использование обратной связи от выполнения кода для итеративного улучшения кода дало результаты намного лучше, чем самостоятельная многократная выборка модели. Ключевое отличие в том, что на каждой итерации вносится реальный результат выполнения (ошибки компиляции, провалившиеся тесты, исключения времени выполнения) — информация, которой не существовало в момент, когда модель писала код. WebGen-Agent⁴ 2025 года на задачах генерации веб-страниц с помощью многоуровневой визуальной обратной связи (скриншоты + описания от модели с распознаванием изображений), формирующей каркас обратной связи, по сообщениям, повысил результат Claude 3.5 Sonnet на данном тесте с 26,4% до 51,9% — почти вдвое.

Эта схема «новой информации» объясняет на первый взгляд противоречивое явление: академические исследования говорят «одного агента достаточно», но в инженерной практике мультиагентные системы действительно показывают себя лучше. Корень противоречия в том, что речь идёт о разных типах «мультиагентности» — в академических исследованиях чаще сравнивается модель «несколько агентов рассматривают один и тот же текст и обсуждают его между собой» (например, дебаты), тогда как эффективные мультиагентные системы в инженерной практике обычно включают контур внешней обратной связи (выполнение кода, визуальный рендеринг, вызов инструментов). Первый вариант не вносит новой информации, второй — вносит. Три архитектуры, описанные далее в этой главе — равноправное сотрудничество, оркестрация и децентрализация, — почти во всех случаях реального успешного применения находят опору именно в этом критерии.

Бюджет шагов и производительность агента. Смежное направление исследований — как влияет на результат работы агента выделение разного бюджета шагов (то есть допустимого числа вызовов инструментов или итераций)? Интуитивно кажется, что больше шагов должны давать лучший результат — с бюджетом в 30 шагов агент способен только быстро реализовать основную функциональность, а с бюджетом в 300 шагов он ещё может сначала спланировать, затем реализовать, затем протестировать, затем улучшить. Но статья Google 2025 года «Budget-Aware Tool-Use Enables Effective Agent Scaling» обнаружила контринтуитивный вывод: простое увеличение числа доступных агенту шагов не гарантирует повышения производительности. Стандартные агенты не обладают «осознанием бюджета» — даже имея 300 шагов в запасе, они склонны выполнять поверхностный поиск и быстро «насыщаются». Чтобы дополнительные шаги действительно превращались в лучший результат, агенту нужен явный механизм осознания бюджета, динамически подстраивающий стратегию под оставшиеся ресурсы: на начальном этапе — широкое исследование, на позднем — концентрация на наиболее перспективных направлениях. BAVT (Budget-Aware Value Tree Search) 2026 года развивает эту идею, предлагая оценку ценности на уровне отдельного шага, где на каждом шаге вес исследования и вес использования корректируются в зависимости от доли оставшегося бюджета — по мере уменьшения бюджета агент постепенно переключается от «широкого закидывания сети» к «глубокому копанию».

Эти находки напрямую влияют на проектирование многоагентных систем. Например, в модели оркестрации Manager Agent не должен просто раздавать задачи подчинённым агентам и ждать результата — вместо этого он должен динамически распределять бюджет шагов в зависимости от сложности задачи: простым подзадачам — меньше шагов, сложным — достаточно шагов. При этом нужно ещё направлять подчинённых агентов на разумное использование этого бюджета (сначала спланировать, затем реализовать, затем протестировать, затем улучшить), а не бросаться сразу в реализацию.

Есть ещё один момент, который нужно учитывать в первую очередь при любом проектировании: стоимость. Параллельное исследование и многократные итерации в мультиагентных системах стоят денег — Anthropic раскрывала, что расход токенов их мультиагентной исследовательской системы примерно в 15 раз выше, чем у обычного диалога, а сам объём токенов объясняет около 80% разницы в производительности. Это значит, что выигрыш от мультиагентного подхода должен быть достаточно велик, чтобы покрыть дополнительные расходы в несколько раз или на порядок больше — иначе хорошо настроенный единичный агент чаще всего оказывается более выгодным выбором.

Мультиагентное взаимодействие с общим контекстом

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

Многоэтапная смена ролей

Сначала проясним один терминологический спор: если пользоваться языком первой главы, многоэтапная смена ролей — это разновидность оркестрации в стиле рабочего процесса: маршрут исполнения (например, уточнение требований → реализация → проверка) задан заранее. С точки зрения процессов это ещё яснее: это один процесс, последовательно исполняющий код разных этапов, — меняется сегмент кода, а память от начала до конца одна и та же, и это не многопроцессность. Поэтому точка зрения, не считающая это «настоящей мультиагентностью», имеет свои основания. И всё же эта глава включает её в рамки мультиагентности, потому что от этого есть реальная выгода в проектировании: когда системный промпт, набор инструментов и фокус внимания на каждом этапе различаются, полезно рассматривать эти этапы как нескольких агентов, разделяющих одну и ту же траекторию, — промпт и набор инструментов для каждой «идентичности» можно шлифовать независимо, а границы этапов естественным образом становятся точками контроля качества.

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

Эксперимент 10-1 ★★: определение системного промпта в зависимости от этапа выполнения

Этот эксперимент на примере полного рабочего процесса кодинг-агента демонстрирует, как поэтапный системный промпт улучшает работу агента.

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

Этап первый: уточнение требований (роль: аналитик требований)

Системный промпт подчёркивает: - «Твоя обязанность — полностью понять требования пользователя. Задавай вопросы, чтобы прояснить неясные места, убедись, что ты до конца понимаешь ожидаемую функциональность, сценарии использования и требования к производительности». - «Не спеши с реализацией. На этом этапе твоя задача — задавать вопросы и получать подтверждения, а не писать код». - «Когда убедишься, что все ключевые требования прояснены, вызови инструмент complete_requirements_analysis(), чтобы завершить этот этап».

Набор инструментов ограничен: ask_clarifying_question(question) используется, чтобы задавать пользователю уточняющие вопросы, save_requirement(key, value) — чтобы фиксировать подтверждённые пункты требований, complete_requirements_analysis() — чтобы отметить завершение этапа.

Агент ведёт с пользователем многотуровый диалог: «Файлы каких типов должен обрабатывать этот скрипт?», «Нужно ли рекурсивно обрабатывать подпапки?», «Сохранять ли исходные имена файлов после перемещения?». Через эти вопросы агент постепенно выстраивает полное понимание требований и сохраняет их в структурированном виде. Когда агент решает, что требования достаточно ясны, он вызывает complete_requirements_analysis(), запуская смену роли — система обнаруживает сигнал о завершении этапа и автоматически переключается на конфигурацию следующего этапа.

Этап второй: реализация кода (роль: инженер-программист)

Новый системный промпт подчёркивает: - «Твоя обязанность — написать качественный код на Python на основе подтверждённых требований». - «Следуй лучшим практикам: код должен быть модульным, содержать корректную обработку ошибок и необходимые комментарии». - «После того как код написан и прошёл базовые тесты, вызови submit_for_review(), чтобы перейти к этапу проверки».

Набор инструментов заметно изменился: инструменты для уточнения требований убраны, вместо них появились инструменты разработки write_file(path, content), read_file(path), execute_code(code) и т. д. Агент начинает писать код на основе требований, сохранённых на первом этапе, — сначала основная логика, затем добавление обработки ошибок, наконец написание тестов для проверки. На протяжении всего процесса агент по-прежнему может обращаться к истории диалога первого этапа, чтобы вспомнить детали требований, но модель поведения уже совершенно иная: больше нет вопросов, всё внимание сосредоточено на реализации. По завершении вызывается submit_for_review().

Этап третий: проверка кода (роль: рецензент кода)

Новый системный промпт подчёркивает: - «Твоя обязанность — проверить только что написанный код и оценить его качество по нескольким измерениям: корректность функциональности, соблюдение стандартов кода, обработка ошибок, оптимизация производительности, безопасность». - «Применяй критическое мышление, старайся найти возможные проблемы и точки для улучшения в коде». - «Если обнаружены серьёзные проблемы, вызови request_revision(issues), чтобы вернуться на этап реализации для исправлений; если качество приемлемое, вызови approve_code(), чтобы завершить задачу».

Набор инструментов снова меняется: теперь это инструменты анализа качества кода run_linter(file), run_tests(file), analyze_complexity(file) и т. д. Агент пересматривает код с точки зрения рецензента, запускает статический анализ, ищет потенциальные баги, проблемы производительности или уязвимости безопасности.

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

Требования к эксперименту: 1. Реализовать трёхэтапные системные промпты, с чётким определением роли и указаниями по поведению для каждого этапа 2. Настроить для каждого этапа соответствующий набор инструментов 3. Реализовать механизм запуска перехода между этапами (через вызов определённого инструмента) 4. Обеспечить непрерывность контекста между этапами 5. Обработать случай отката — при обнаружении проблем на проверке кода нужно уметь вернуться на этап реализации 6. Вести журнал выполнения каждого этапа, показывающий, как разные промпты порождают разные модели поведения

Смена ролей между предметными областями

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

Эксперимент 10-2 ★★: смена нескольких ролей

Предварительные требования: рекомендуется сначала ознакомиться с механизмом Agent Skills из второй главы.

Архитектура системы: пять ролей —

• triage (диспетчер на входе, роль по умолчанию): понимает общий запрос пользователя, разбивает его на упорядоченные подзадачи, поочерёдно передаёт их подходящим специализированным ролям и подводит итог после завершения всех подзадач. Собственных специализированных инструментов не имеет, располагает только transfer
• research (эксперт по поиску информации): с помощью web_search ищет данные, факты и материалы
• coding (эксперт по программированию): с помощью execute_python пишет и запускает код, решает задачи программной логики/скриптов
• data_analysis (эксперт по анализу данных): с помощью calculate / descriptive_stats выполняет количественные расчёты и статистику (например, темп прироста год к году, среднегодовой темп роста CAGR, среднее значение)
• writing (эксперт по написанию текстов): превращает найденные данные и выводы расчётов в связный, ориентированный на указанную аудиторию текст (может использовать count_characters для грубой оценки объёма)

Ключевой механизм: инструмент transfer_to_agent

Все роли оснащены инструментом transfer_to_agent(target_role, reason). При его вызове система последовательно: 1) сохраняет текущую историю диалога; 2) загружает промпт и набор инструментов целевой роли; 3) передаёт историю диалога новой роли, чтобы та поняла контекст; 4) продолжает выполнение уже от лица новой роли.

Сценарий эксперимента: по умолчанию система работает от лица triage (диспетчера на входе). Пользователь ставит комплексную задачу на стыке нескольких областей: «Я готовлю материалы для инвесторов, помоги мне узнать объёмы продаж новых энергетических автомобилей в Китае за 2021, 2022, 2023 годы, посчитать среднегодовой темп роста (CAGR) за эти три года и написать резюме на китайском языке объёмом не более 120 знаков, ориентированное на инвесторов». triage разбивает это на «найти данные → рассчитать показатели → написать текст» и на первом шаге передаёт управление поиску:

transfer_to_agent(target_role="research", reason="сначала нужно найти данные о продажах за три года")

research находит данные о продажах с помощью web_search, записывает ключевые данные в диалог, затем передаёт управление анализу данных:

transfer_to_agent(target_role="data_analysis", reason="данные готовы, нужно рассчитать CAGR за три года")

data_analysis с помощью calculate рассчитывает темп роста и передаёт управление writing для составления текста; writing пишет текст и передаёт управление обратно triage для подведения итога. Вся цепочка выглядит так: triage → research → data_analysis → writing → triage, и каждая роль видит полную историю диалога, поэтому следующая роль естественным образом знает, что уже сделано предыдущей.

Решение о смене роли опирается на указания системного промпта. В промпте triage чётко перечислены правила маршрутизации: поиск данных/материалов — передать research, написание и запуск кода — передать coding, количественные расчёты и статистика — передать data_analysis, доработка текста — передать writing. Критерий прост: если задача требует глубоких знаний конкретной предметной области или специализированных инструментов, она передаётся соответствующей специализированной роли. В промптах специализированных ролей также указано, кому передать управление после завершения своей части — конкретной роли или обратно triage.

Требования к эксперименту: 1. Реализовать системные промпты и специализированные наборы инструментов как минимум для трёх специализированных ролей 2. Реализовать инструмент transfer_to_agent, поддерживающий динамическое переключение 3. Обеспечить непрерывность контекста после смены роли 4. Обработать проблему циклического переключения — не допускать, чтобы агент многократно переключался между ролями туда-обратно 5. Спроектировать сложный процесс задачи, охватывающий несколько предметных областей, чтобы продемонстрировать ценность смены ролей

Мультиагентное взаимодействие без общего контекста

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

В начале главы механизмы коммуникации были сопоставлены с двумя парадигмами межпроцессного взаимодействия, а общий и раздельный контекст — с потоками и процессами. Эту аналогию можно провести гораздо дальше (табл. 10-3):

Табл. 10-3 Соответствие между многоагентной системой и операционной системой

Операционная система	Многоагентная система
Программа (исполняемый файл)	Статический префикс (системный промпт + определения инструментов)
Память процесса	Траектория
CPU	LLM
Ядро	Среда выполнения агента
Системный вызов	Вызов инструмента
fork (создание дочернего процесса)	spawn_subagent
kill (отправка сигнала)	cancel_subagent
ps (список процессов)	list_agents
Код возврата и wait()	Структурированное резюме, возвращаемое дочерним агентом
Разделяемая память / передача сообщений	Общая файловая система / сообщения

Программа — это статический код, процесс — это один запуск программы. Точно так же статический префикс определяет, кто такой агент, а траектория фиксирует, до какого шага он дошёл. LLM играет роль CPU: сама не хранит состояния, а обслуживает множество агентов в режиме разделения времени, загружая разный контекст, — само слово «переключение контекста» и заимствовано из операционных систем. Именно поэтому смена CPU на более быстрый не мешает программе работать по-прежнему; смена модели на более сильную оставляет агента тем же самым агентом — его идентичность и память лежат в префиксе и траектории, а не в весах модели.

Эта абстракция не нова: приватное состояние, асинхронные сообщения, возможность создавать новых участников — это как раз базовые положения модели акторов (Actor model) 1970-х годов ⁵, и многоагентную систему можно рассматривать как её LLM-версию. Поэтому зрелый опыт операционных систем и распределённых систем по большей части можно заимствовать напрямую. Единственное, что здесь не срабатывает: процессы передают друг другу байты с побитовой точностью, а агенты передают семантику, и каждый пересказ может её исказить — это новая проблема, которой посвящён отдельный раздел «режимы отказа» в этой главе.

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

Но у отсутствия общего контекста есть своя цена. Самая очевидная — проблема синхронизации информации: как разным агентам поддерживать согласованное понимание состояния задачи? Может ли информация теряться или дублироваться при передаче? Отладка тоже усложняется — при возникновении проблемы приходится просматривать журналы нескольких агентов, чтобы восстановить полную картину выполнения. Из-за этого проектирование интерфейсных спецификаций, форматов данных и протоколов коммуникации становится критически важным.

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

Файловая система глазами агента

В начале этой главы «общая файловая система» была названа одним из трёх механизмов коммуникации без общего контекста. В реальных системах агент обращается не к единому хранилищу, а к виртуальной файловой системе (virtual filesystem): хранилища разного происхождения, с разным жизненным циклом и правами доступа монтируются (mount) в одно и то же дерево каталогов, и агент обращается к ним через единый интерфейс read_file/write_file/list_dir, тогда как под капотом может скрываться локальный временный диск, постоянное объектное хранилище, API стороннего облачного диска или доступный только для чтения системный пакет ресурсов. Чёткое понимание структуры этого дерева каталогов — видимости и жизненного цикла каждой области — является предпосылкой проектирования мультиагентного взаимодействия: значительная часть конфликтов параллелизма и утечек информации возникает из-за смешения областей, которые должны были быть изолированы. Это дерево каталогов равнозначно адресному пространству агента, а четыре типа областей — это сегменты памяти с разными правами: одни приватные и доступные для записи, другие разделяемые несколькими сторонами, третьи только для чтения. Защитная философия операционных систем здесь тоже в силе — по умолчанию изоляция, а разделение должно быть объявлено явно. В зрелой многоагентной системе файловая система обычно состоит из следующих четырёх типов областей:

Первая: собственная рабочая область агента (Scratchpad). Приватный каталог, принадлежащий только конкретному экземпляру агента, где хранятся промежуточные результаты, временные файлы, черновики и отладочные журналы; жизненный цикл привязан к экземпляру, невидим для других агентов и пользователя. Изоляция scratchpad выполняет двойную функцию: предотвращает взаимное перезатирание временных файлов разных агентов и сохраняет компактность контекста главного агента — процесс проб и ошибок дочернего агента остаётся в его собственной рабочей области, в общее пространство передаётся только конечный результат. Это соответствует принципу из четвёртой главы «дочерний агент возвращает структурированное резюме, а не полную траекторию» на уровне хранения.

Вторая: общее пространство для нескольких агентов (Shared Workspace). Область взаимодействия, куда несколько агентов совместно читают и пишут и которая видна пользователю — это основное средство обмена артефактами между агентами в архитектуре без общего контекста: Glossary Agent записывает глоссарий, Translation Agent считывает его оттуда; пользователь также может здесь загружать исходные файлы и скачивать конечные результаты. Её жизненный цикл привязан ко всей задаче в целом и требует персистентности. Как область, куда несколько сторон одновременно пишут и читают, она — источник частых конфликтов параллелизма: механизмы вроде оптимистичной блокировки, изоляции рабочих копий (worktree) и подобные действуют именно здесь, подробнее об этом — в разделе «режим сбоя первый» далее в этой главе. Пример из четвёртой главы, где монтирование тома /workspace/shared соединяет главного агента, виртуальный компьютер и виртуальный телефон, — типичная реализация этого уровня.

Третья: смонтированные внешние ресурсы (Mounted External Resources). Источники информации сторонних сервисов, к которым пользователь предоставил доступ, — Google Drive, Notion, Dropbox, корпоративная Wiki и т. д. — отображаются через адаптер (adapter) как точки монтирования в файловой системе (например, /mnt/gdrive). Агент обращается к документу Notion так же, как к обычному файлу, а под капотом адаптер вызывает API соответствующего сервиса. Три особенности этого уровня, отличающие его от локального хранилища, должны быть явно учтены при проектировании: доступ ограничен внешними правами (права пользователя в исходной системе определяют видимость для агента), более высокая задержка и более слабая согласованность (каждое чтение — это сетевой запрос, данные могут быть уже изменены извне, и их приходится рассматривать лишь в рамках итоговой согласованности), преимущественно чтение по требованию (запись обратно во внешний источник требует осторожности — ошибочная запись может испортить реальные данные пользователя). Единый файловый интерфейс избавляет агента от необходимости создавать отдельный инструмент под каждый источник данных, но при этом маскирует упомянутые различия в производительности и безопасности, поэтому границы доступа только для чтения/на запись, таймауты и учётные данные нужно явно настраивать на уровне монтирования.

Четвёртая: встроенные системные ресурсы (Built-in System Resources). Предустановленные системой ресурсы, доступные всем агентам только для чтения; типичный представитель — Skills, описанные во второй и четвёртой главах: документы знаний и скрипты, организованные в виде файлов, смонтированные по путям вроде /skills, извлекаемые по принципу прогрессивного раскрытия (сначала индекс, затем разворачивание по требованию); сюда же относятся справочники, библиотеки шаблонов и общие определения инструментов. Этот уровень глобально общий, только для чтения, стабилен между сессиями и может параллельно читаться всеми агентами без контроля конкурентного доступа.

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

В табл. 10-4 эти четыре типа областей сравниваются по четырём измерениям — видимости, жизненному циклу, правам чтения/записи и контролю конкурентного доступа; таблицу можно использовать как контрольный список при проектировании структуры файловой системы.

Табл. 10-4 Четыре типа областей виртуальной файловой системы агента

Область	Видимость	Жизненный цикл	Чтение/запись	Контроль конкурентного доступа
Собственная рабочая область агента	Только этот агент	Уничтожается вместе с экземпляром агента	Чтение/запись	Не требуется (приватная)
Общее пространство для нескольких агентов	Все взаимодействующие агенты + пользователь	Существует, пока идёт задача, требует персистентности	Чтение/запись	Требуется (оптимистичная блокировка / worktree)
Смонтированные внешние ресурсы	Зависит от внешних прав доступа	Определяется внешним источником	В основном только чтение, запись требует осторожности	Ответственность внешнего источника
Встроенные системные ресурсы	Все агенты	Стабильны между сессиями	Только чтение	Не требуется (только чтение)

Объединение четырёх типов областей в единое дерево каталогов и раскрывает ценность идеи «путь к файлу как универсальный интерфейс»: при передаче артефактов между агентами, при передаче ввода от главного агента дочернему и даже при обмене артефактами в межорганизационном взаимодействии A2A передаётся лёгкая строка пути, а не содержимое, загружаемое в окно контекста (глава 4). Это перекликается с идеей пятой главы «файловая система как центр агента» — там рассматривалось, как одиночный агент использует файловую систему для хранения памяти и способностей, здесь же та же абстракция распространяется на множество агентов: виртуальное дерево каталогов, в которое смонтированы четыре типа хранилищ — приватное, общее, внешнее и встроенное, — и есть та база хранения, на которой строится мультиагентное взаимодействие.

Взаимодействие и управление между агентами

Файловая система решает проблему обмена артефактами между агентами, но для сотрудничества нужна ещё и плоскость управления. Именно здесь пригождаются строки жизненного цикла из табл. 10-3: набор инструментальных примитивов, данных в четвёртой главе, — создание (spawn_subagent), отправка сообщения (send_message_to_subagent), отмена (cancel_subagent), обнаружение (list_agents) — соответствует fork, сообщению, kill и ps из мира процессов. В этом разделе мы не будем повторять описание интерфейсов, а сосредоточимся на четырёх возможностях, от которых зависит мультиагентное взаимодействие, но которые часто упускают из виду.

Первое. Передача сообщений. Простейшая форма — точка-точка: агент A напрямую вызывает send_message_to_agent_b(content), что подходит для сценариев с фиксированной топологией и небольшим числом агентов (например, для пары «телефон + компьютер» из эксперимента 10-4 этой главы). Когда число агентов растёт и требуется асинхронная параллельная работа, число прямых соединений растёт квадратично от числа агентов, а кроме того требуется, чтобы отправитель и получатель были онлайн одновременно; в этом случае стоит перейти на шину сообщений (подробнее — в разделе «Формы параллельной координации» далее в этой главе): агент публикует сообщение в шину, а та рассылает его по подпискам, так что отправителю не нужно знать своих потребителей. Независимо от того, идёт ли передача напрямую или через шину, сообщение обычно должно нести структурированный конверт (envelope): ID отправителя, назначение (конкретный агент или широковещательная рассылка), тип сообщения (например, task_assigned/status_update/result/terminate) и полезную нагрузку в формате JSON. Единый формат конверта гарантирует, что получатель надёжно маршрутизирует и разбирает сообщение, а также делает цепочку взаимодействия отслеживаемой — это ключевой момент для отладки многоагентных систем.

Второе. Запрос состояния. Это самое недооценённое звено плоскости управления. Если главный агент, отправив дочернего агента на задачу, не может узнать о его прогрессе, то он не в состоянии ни решить, стоит ли продолжать ждать, ни своевременно вмешаться, если тот застрял. Интуитивно хочется скопировать RPC и определить интерфейс-запрос get_subagent_status(agent_id), возвращающий «выполняется/завершено/провалено» плюс процент прогресса. Но реальная польза от такого pull-интерфейса гораздо меньше ожидаемой: дочерний агент, будучи однажды созданным, сразу начинает выполняться и работает до завершения или провала, а не проходит через череду очередей состояний, как задание в традиционной системе пакетной обработки, — точно так же, как в программировании под Unix крайне редко нужно опрашивать состояние другого процесса по PID. У опроса есть и врождённая дилемма: слишком частый впустую тратит токены, слишком редкий не поспевает. Более естественный способ получения состояния — вернуться к двум парадигмам коммуникации из начала главы.

Получение состояния через передачу сообщений. Главный агент напрямую отправляет дочернему сообщение: «Как продвигается работа?» — и дочерний агент отвечает в подходящий момент. Всё асинхронно: отправка сообщения не блокирует собственное выполнение отправителя, а когда и ответит ли получатель — это уже другой вопрос, — так менеджер спрашивает подчинённого о прогрессе через мессенджер, не требуя, чтобы тот немедленно бросил свою работу. И наоборот, дочерний агент может сам, достигнув ключевой точки, отправить сообщение с отчётом; если в системе уже развёрнута шина сообщений, это означает публикацию status_update в шину (та самая форма «мониторинга в реальном времени» из эксперимента 10-6). Как при вопросах-ответах, так и при инициативных отчётах само состояние в сообщении стоит выражать единым словарём конечного автомата (выполняется, требуется ввод, завершено, провалено) — протокол A2A, о котором пойдёт речь далее в этой главе, как раз стандартизирует жизненный цикл задачи в виде такого набора состояний.

Получение состояния через общую файловую систему. Самая полная форма — это персистентность траектории (trajectory persistence): дочерний агент в ходе выполнения в реальном времени сериализует свою траекторию (trajectory из определения первой главы — полную последовательность сообщений пользователя, ответов модели, вызовов инструментов и их результатов) в JSON и дописывает её в лог-файл в файловой системе (обычно один файл на сессию, по одному событию в строке — формат JSONL). Главному агенту не нужен никакой протокол отчётов о состоянии: он просто читает этот файл и видит весь ход выполнения дочернего агента — какой инструмент тот сейчас вызывает, о чём думал на последнем шаге, не застрял ли в бесконечных повторных попытках. На языке процессов это равнозначно прямому чтению памяти другого процесса — не занимает контекст дочернего агента, не зависит от его содействия, обеспечивает самую тонкую гранулярность наблюдения. Но и такая детальность — это нагрузка: траектория запросто достигает десятков тысяч токенов, и главному агенту, прочитав её, ещё придётся самому её обобщать, что затратно и по времени, и по токенам. Поэтому в большинстве сценариев разумнее договориться о файле прогресса: запуская дочернего агента, главный агент условливается «пиши прогресс в progress.md», дочерний агент по завершении каждого пункта обновляет этот список задач, а главный агент в любой момент читает этот лёгкий файл, чтобы быть в курсе. Это равнозначно тому, как два процесса выделяют в разделяемой памяти небольшой участок состояния оговорённого формата, раскрывая обобщённый прогресс, а не всю «память». Файл прогресса попутно даёт и обнаружение зависаний: если время последнего изменения progress.md (или файла траектории) не менялось дольше N минут, можно заключить, что дочерний агент неактивен, и сработает подстраховка по тайм-ауту (перекликается с Heartbeat и monitor_shell из четвёртой главы), не давая застрявшему дочернему агенту затормозить всю систему.

Ценность персистентности траектории далеко не ограничивается мониторингом. Вспомним вывод первой главы «контекст агента = статический префикс + траектория»: статический префикс (системный промпт, определения инструментов) задаётся кодом, а никакого рантайм-состояния помимо траектории у самого агента нет (рабочие продукты и так лежат в файловой системе) — траектория и есть всё состояние агента. Персистентность траектории в файл в реальном времени равнозначна наличию под рукой полной контрольной точки: что бы ни случилось — крах процесса агента, отключение питания машины или закрытие сессии пользователем, — достаточно заново загрузить файл траектории, приставить к нему статический префикс, и выполнение продолжится с места прерывания; именно так реализована функция восстановления сессии (session resume) у кодинг-агентов вроде Claude Code и Codex CLI. Это та же идея, что и журнал предзаписи (write-ahead log) в базах данных: каждое событие сначала дописывается в только пополняемый журнал, и состояние всегда можно воспроизвести из журнала (дизайн памяти из третьей главы «журнал фактов + периодические контрольные точки» — применение той же идеи в системах памяти). Для многоагентных систем это означает, что дочерний агент по своей природе восстанавливаем, поддаётся аудиту и передаваем: менеджер может после краха дочернего агента перезапустить его с последнего валидного состояния, задним числом воспроизвести траекторию по событиям, чтобы локализовать причину сбоя, и даже передать траекторию вместе с задачей другому агенту для продолжения.

Третье. Прерывание выполнения. В параллельном взаимодействии часто возникает ситуация «один добился успеха, остальные уже не нужны» — несколько агентов ведут параллельный поиск, и как только один находит цель, остальные должны немедленно остановиться (каскадное завершение из эксперимента 10-6 этой главы). Прерывание бывает двух степеней жёсткости, и пользователи Unix узнают в них различие между SIGTERM и SIGKILL. Мягкое прерывание (graceful) — предпочтительный вариант: главный агент подаёт сигнал terminate, дочерний агент реагирует на него в безопасной точке текущего шага, сначала освобождает ресурсы (закрывает сессию браузера, дописывает незавершённый файл, снимает блокировку), возвращает подтверждение (ack) и только потом завершается. Принудительное прерывание (forced) — крайняя мера: процесс завершается напрямую, и применяется только тогда, когда дочерний агент не реагирует на мягкий сигнал; ценой становится риск оставить висящие ресурсы и незавершённые записи. Здесь важны два инженерных момента: во-первых, мягкое прерывание требует, чтобы дочерний агент периодически проверял сигнал завершения в своём цикле (аналогично механизму прерывания из четвёртой главы), иначе сигналу просто не на что будет откликнуться; во-вторых, при каскадном завершении возникает условие гонки — несколько дочерних агентов могут почти одновременно сообщить об успехе, и главный агент должен с помощью блокировки или идемпотентной схемы гарантировать, что фиксация результата произойдёт только один раз и сигнал завершения будет разослан только одним раундом; подробнее об этом условии гонки — в обсуждении эксперимента 10-6 этой главы.

Остаётся ещё один остаточный вопрос: что делать с дочерними агентами, которые продолжают работать после того, как главный агент завершился? Самое лаконичное инженерное решение заимствовано из context в Go — завершение каскадно распространяется вниз по отношению создания: отменяем одного агента, и все порождённые им дочерние агенты отменяются следом, что на корню исключает бесхозных агентов-сирот. Упомянутая выше «проверка сигнала завершения дочерним агентом в безопасной точке» — это как раз опрос ctx.Done() в Go. И наоборот, если действительно нужен долго работающий фоновый агент, отвязанный от главного (по аналогии с nohup в Unix), пусть он стартует с новой ветви жизненного цикла (соответствует context.Background()), явно объявляя, что не завершается вместе с родителем.

Четвёртое. Ресурсы и планирование. Другая половина работы операционной системы — распределение дефицитных ресурсов. В мире процессов дефицитны время CPU и память, в мире агентов дефицитны токены, деньги и квота параллелизма — каждый шаг дочернего агента расходует все три. Эта функция обычно ложится на менеджера или среду выполнения: при запуске дочернего агента задаётся бюджет по числу шагов или токенов, при превышении которого работа останавливается; трудные задачи отдают сильной модели, механические — дешёвой; на число параллельных агентов ставится верхний предел, чтобы десятки агентов одновременно не исчерпали квоту API; а при поступлении более срочной задачи выполняющийся дочерний агент прерывается — это и есть вытеснение (preemption). Практика в этой области ещё далеко не так зрела, как планирование CPU, но именно она определяет верхнюю границу стоимости многоагентной системы, и учитывать её стоит уже на этапе проектирования архитектуры.

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

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

Модель равноправного сотрудничества: взаимный контроль и итеративное улучшение

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

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

Классическое применение равноправного сотрудничества — борьба с крайне распространённым в практике агентов типом сбоя: преждевременным завершением, когда работа брошена на полпути. У него есть три типичные формы; ниже мы разберём их на примерах кодинг-агента и Pine AI (агента, созданного нашей командой и упомянутого во введении, — он звонит по телефону вместо пользователя и договаривается с магазинами и операторами связи). Первая форма — ленивое ложное завершение: сделана только часть работы, но объявляется, что всё готово — кодинг-агент написал код, но не запустил тесты и не попробовал развернуть его, а уже рапортует «задача выполнена»; пользователь поручил Pine AI два дела, тот справился с первым, забыл про второе и прямо доложил «всё сделано». Вторая форма — преждевременный отказ: не получилось пройти по одному пути — и объявляется, что вся задача невыполнима — у Pine AI при обращении в магазин есть несколько каналов: звонок, заполнение формы, письмо по почте, но стоит один звонок отклонить, как агент сразу говорит пользователю «это не получится сделать», хотя стоило попробовать другой канал, и, вполне вероятно, дело бы выгорело. Третья форма — ложный успех: агент считает, что задача выполнена, но на деле цикл не замкнут до конца — по телефону собеседник устно согласился на возврат средств, но пользователю всё ещё нужно подтвердить это действие в мобильном приложении, а агент уже докладывает «сделано»; пользователь не знает, что требуется ещё один шаг, и возврат средств фактически не происходит. Все три формы сводятся к одной причине: до проверки «завершение» — это лишь заявление модели, а не доказательство.

Превратить заявление в доказательство — как раз и есть задача инженерии циклов (Loop Engineering), о которой шла речь в конце эволюционной дуги первой главы: нужно спроектировать цикл, который заставляет агента продолжать работу — находить следующий шаг, выполнять его, проверять, фиксировать прогресс, — причём решение о том, «действительно ли можно остановиться», принимает верификатор, а не сама модель; роль человека при этом смещается от «оператора, пишущего промпты для агента» к «инженеру, проектирующему цикл». Этот термин был сформулирован Эдди Османи в июне 2026 года⁶, а руководитель Anthropic Claude Code Борис Черни выразился ещё прямее: «Я больше не пишу промпты напрямую для Claude — моя работа теперь в том, чтобы писать loop». Ключевой консенсус, сложившийся в отрасли в ходе этой дискуссии, таков: узкое место цикла — в верификаторе, а не в модели — если проверка ненадёжна, то как бы быстро ни крутился цикл, он лишь быстрее помечает некачественный результат как готовый. И, как уже говорилось во введении, практика всегда опережает наименование: задолго до того, как этот термин вошёл в обиход, ведущие команды разработчиков агентов, включая Pine AI, уже использовали связку «цикл + проверка» для борьбы с преждевременным завершением. А самая эффективная организация проверки — это как раз описываемая ниже парадигма предложитель-рецензент.

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

LoopX решает → агент выполняет → независимый верификатор доказывает → LoopX фиксирует

Агент по-прежнему рассуждает, использует инструменты и создаёт результаты-кандидаты. LoopX не заменяет среду выполнения агента, а управляет непрерывностью между итерациями. Только независимо проверенные результаты могут обновлять долговечный прогресс и расходовать квоту. Провал проверки ведёт к исправлению или перепланированию, а человеческие контрольные точки, состояния ожидания и ограничения бюджета останавливают цикл до выполнения. Эта граница превращает принцип Loop-инженерии в проверяемый системный инвариант: модель может предложить «готово», но не может утвердить собственное «готово». В LoopX v0.4.0 путь управляемого Turn всё ещё помечен как экспериментальный, поэтому здесь он служит конкретным фреймворком для «цикла + проверки + условий остановки», а не доказательством общего роста качества выполнения задач.⁷

Парадигма предложитель-рецензент.

Предложитель-рецензент — самая классическая парадигма равноправного сотрудничества. В пятой главе на трёх экспериментах — генерации PPT, монтаже видео и визуализации логов — уже подробно рассматривались принципы проектирования и практическое применение этой парадигмы: Proposer Agent генерирует код, Reviewer Agent рендерит результат выполнения, оценивает качество с помощью Vision LLM и даёт структурированные рекомендации по улучшению, а затем оба агента итеративно повторяют этот цикл, пока результат не достигнет нужного уровня.

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

Почему нельзя дать одному агенту самому сгенерировать результат и самому же его проверить? Это конкретное следствие того самого критерия из раздела «Когда мультиагентность действительно лучше одного агента»: если проверка не привносит новой информации, это просто «заставить модель подумать ещё раз». Соответствующие исследования дают на это чёткий ответ. Хуан и соавторы в статье ICLR 2024 «Large Language Models Cannot Self-Correct Reasoning Yet» обнаружили: если заставить GPT-4 проверять и исправлять собственные ответы без внешней обратной связи, точность не повышается, а падает — модель чаще превращает правильные ответы в неправильные, чем наоборот.

Обзорная статья 2024 года в журнале TACL «When Can LLMs Actually Correct Their Own Mistakes?» (arXiv:2406.01297) дополнительно подтверждает этот вывод: если не предоставить надёжную внешнюю обратную связь (например, результаты выполнения тестов или проверочный вывод внешнего инструмента), «самокоррекция», опирающаяся только на саму модель, почти не работает.

Статья CRITIC (ICLR 2024) даёт наглядное сравнительное подтверждение. В CRITIC модель использует внешние инструменты (поисковую систему, интерпретатор Python) для проверки собственных ответов, и это заметно повышает качество; но когда исследователи убрали шаг проверки инструментами и оставили только самооценку модели, бо́льшая часть прироста исчезла. Это показывает, что ценность проверки не в том, чтобы «заставить модель подумать ещё раз», а в том, что она привносит новую информацию, недоступную модели на этапе генерации, — результаты тестов, скриншоты рендера, ошибки компиляции, результаты внешнего поиска.

Именно в этом и заключается основной принцип проектирования парадигмы предложитель-рецензент. В эксперименте с генерацией PPT из пятой главы ценность Reviewer Agent не в том, чтобы «той же моделью ещё раз посмотреть на код», а в том, что он отрендерил PPT и сделал снимок экрана — этот снимок содержит визуальную информацию, которая была совершенно недоступна Proposer Agent на этапе генерации кода. Аналогично в сценарии генерации кода: результат прохождения/провала тестов, полученный при их выполнении, — это новый сигнал, которого не существовало на момент написания кода; именно доступ к такой внешней обратной связи, недоступной Proposer, и составляет самостоятельную ценность Reviewer.

С точки зрения инженерии циклов, несколько стилей циклов, обобщённых в отрасли, находят соответствия в этой книге: замкнутый цикл с ручным утверждением соответствует предварительному согласованию из четвёртой главы (человек выступает финальным проверяющим); разомкнутый цикл с бюджетом или лимитом раундов соответствует многораундовой итерации (максимум 5 раундов) из эксперимента по генерации PPT в пятой главе; оркестрируемые дочерние агенты соответствуют модели оркестрации из следующего раздела. Иными словами, инженерия циклов описывает не новую архитектуру, а объединяет все эти модели сотрудничества под единой рамкой «цикл + проверка + условие завершения», где роль проверки как раз и выполняет описанная здесь парадигма предложитель-рецензент.

Дополнительно: другие модели равноправного сотрудничества.

Debate (дебаты): несколько агентов занимают разные позиции и через состязательный диалог глубоко исследуют пространство решений. Например, при оценке технического решения агент A играет роль «сторонника», перечисляющего преимущества и возможности решения, а агент B играет роль «оппонента», указывающего на риски и ограничения; в каждом раунде дебатов стороны выдвигают возражения или дополнения к аргументам друг друга. При анализе одним агентом модель часто склоняется к какой-то одной точке зрения и упускает из виду контрдоказательства; режим дебатов за счёт институционализированного противостояния обеспечивает всестороннюю проработку обеих сторон и помогает принимающему решение сделать более взвешенный вывод.

Впрочем, реальная эффективность режима дебатов до сих пор вызывает споры в академическом сообществе. В исследовании Трана и Киелы 2026 года⁸ на задачах многошагового рассуждения сравнили одного агента с пятью многоагентными архитектурами (последовательной, дебатной, ансамблевой, параллельными ролями, параллельными подзадачами) и обнаружили, что при строго одинаковом бюджете токенов на рассуждение результаты одного агента не уступают многоагентным, а иногда и превосходят их (за исключением случаев, когда использование контекста ослаблено до определённой степени). Исследователи объяснили это, опираясь на неравенство обработки данных из теории информации: несколько агентов в дебатах обрабатывают совершенно одну и ту же текстовую информацию, и при каждой последовательной передаче промежуточных выводов от одного агента к другому информация может только теряться, но никак не создаваться из ничего. Выигрыш режима дебатов в некоторых научных статьях, скорее всего, объясняется тем, что несколько агентов в сумме потратили больше вычислений. Важно чётко очертить границы применимости этого аргумента: он касается информационного узкого места, возникающего именно при «последовательной передаче промежуточных выводов между агентами», и не отрицает другой класс подходов — многократную независимую выборку с последующей агрегацией для одной и той же задачи (например, self-consistency, голосование большинством) или использование асимметрии сложности генерации и проверки (написать ответ трудно, проверить ответ легко) для разделения труда на генерацию и проверку. Эти сценарии либо вводят дополнительную независимую выборку, либо используют асимметричную структуру самой задачи, и в обоих случаях неравенство обработки данных на них не распространяется.

Brainstorm (мозговой штурм): несколько агентов независимо генерируют идеи, а затем делятся ими друг с другом и вдохновляются идеями коллег. Например, в задаче продуктовых инноваций агент 1 предлагает «добавить функцию социального обмена», агент 2, вдохновившись этим, предлагает «не просто делиться в соцсетях, но и генерировать персонализированный постер для публикации», а агент 3, обобщая первые два предложения, предлагает «дать пользователям настраивать шаблоны постеров и создать рынок таких шаблонов». Разные агенты обладают разными «стилями мышления» (за счёт разных промптов или моделей) и через взаимную стимуляцию исследуют более широкое пространство решений, находя творческие комбинации, до которых сложно додуматься одному агенту.

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

Модель оркестрации: централизованная координация

Когда задача включает более пяти подзадач, требует динамического планирования или между подзадачами существуют сложные зависимости, равноправное сотрудничество перестаёт справляться — тут и нужна модель оркестрации. Обязанности Manager Agent похожи на работу менеджера проекта: сначала понять задачу целиком, затем разбить её на подзадачи, которые можно распределить, выбрать подходящих агентов для их выполнения, отслеживать прогресс и обрабатывать нештатные ситуации (повтор, замена агента, корректировка плана), и наконец объединить результаты работы всех агентов в итоговый результат.

С точки зрения системного дизайна модель оркестрации моделирует каждого специализированного агента как инструмент, который может вызвать менеджер. В наборе инструментов менеджера есть не только традиционные внешние инструменты (например, поиск, операции с файлами), но и интерфейсы вызова других агентов. Менеджер запускает соответствующего агента через механизм вызова инструмента, передаёт параметры задачи и необходимый контекст, дожидается завершения и получает результат. С точки зрения менеджера вызов агента и вызов обычного инструмента принципиально ничем не отличаются — и то, и другое сводится к отправке запроса и получению ответа. Эта унифицированная абстракция придаёт модели оркестрации хорошую расширяемость — для добавления новой возможности достаточно разработать соответствующего агента и зарегистрировать его как инструмент, без изменения основной логики менеджера. Одновременно она естественным образом поддерживает гетерогенность — разные агенты могут использовать разные модели, промпты, наборы инструментов и даже работать на разном оборудовании.

Абстракция «агенты как инструменты друг для друга» уже была установлена в разделе «Инструмент сотрудничества» четвёртой главы: дизайн интерфейсов spawn_subagent / send_message / cancel_subagent / list_agents напрямую применим к рассматриваемому здесь вызову подчинённых агентов менеджером. Что передавать в направлении «менеджер → подчинённый агент», см. в дизайне пакета передачи (handoff) далее в этой главе (описание задачи, подтверждённые факты и ограничения, ссылки на структурированные артефакты); симметричный вопрос — что возвращать в направлении «подчинённый агент → менеджер». Ответ: структурированное резюме, а не полная траектория. Подчинённый агент должен возвращать вывод по задаче, ключевые находки, пути к файлам-результатам и встреченные проблемы, оставляя полную траекторию выполнения в собственном логе. Только так контекст менеджера будет расти медленно и линейно с числом подзадач, а не взрывообразно — именно на этой методологической основе строится описанный ниже подход в эксперименте 10-3, где менеджер «поддерживает только индекс файлов, не сохраняя содержимое перевода».

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

Статья Plan-and-Act 2025 года ⁹ провела эмпирический анализ этого вопроса: в архитектуре с двумя агентами Planner-Executor слабый планировщик оказывается ключевым узким местом всей системы. Когда качество планирования у планировщика достаточно высокое, хороший результат достигается даже при относительно простом исполнителе; и наоборот, если планировщик ошибся в разбиении задачи, вся последующая работа исполнителей строится на неверных предпосылках. Это исследование достигло 54% успешных решений на benchmark WebArena-Lite, и главный вклад работы состоит именно в улучшении способности планировщика к планированию, а не в улучшении исполнения исполнителем. Вывод из этого таков: самую сильную модель и наиболее тщательно продуманный промпт следует отдавать менеджеру (планировщику), а не распределять ресурсы поровну между всеми агентами.

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

Форма последовательной координации.

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

Эксперимент 10-3 ★★: агент перевода книги

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

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

Модель оркестрации решает эти проблемы через разбиение задачи и разделение ответственности:

• Glossary Agent (агент глоссария): принимает содержимое всей книги, выявляет часто повторяющиеся профессиональные термины, ищет в специализированных словарях и переводческих нормативах, генерирует структурированный глоссарий (в формате JSON/CSV, включающий английский термин, русский перевод, часть речи, контекст использования). После завершения записывает результат в общую файловую систему, после чего агент может быть уничтожен для освобождения ресурсов
• Translation Agent (агент перевода главы): принимает текущую главу, глоссарий и руководство по переводу (уровень целевой аудитории, стиль языка), переводит на плавный русский язык. Для терминов из глоссария строго использует установленный перевод, для новых терминов — предполагает перевод и помечает его как требующий проверки. Каждый экземпляр работает в независимом контексте, не мешая другим. Перевод записывается в файловую систему (например, chapter1_zh.md). Менеджер может запускать несколько экземпляров параллельно или последовательно
• Proofreading Agent (агент сквозной вычитки): принимает все переводы и глоссарий, выполняет проверку согласованности — по очереди проверяет, единообразен ли перевод терминов, выявляет несоответствия между разными частями текста, проверяет общую плавность и читаемость. Формирует отчёт о вычитке и записывает его в файловую систему
• Manager Agent: в контексте хранит в основном описание задачи, план выполнения, записи о вызовах различных агентов и статус прогресса. Не хранит полное содержимое переводов (оно находится в файловой системе), поддерживая только индекс файлов. По отчёту о вычитке менеджер может отправить конкретную главу обратно к Translation Agent на доработку

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

Ключевое преимущество — изоляция контекста: Glossary Agent видит только то, что нужно для извлечения терминов, Translation Agent видит только текущую главу и глоссарий, Proofreading Agent хоть и нуждается в доступе ко всему тексту, но фокусируется только на проверке согласованности. Каждый агент работает в компактном, сфокусированном контексте — это не только эффективнее, но и снижает вероятность ошибок: агент не рассеивает внимание из-за информационной перегрузки.

Требования к эксперименту: 1. Выберите в качестве объекта перевода техническую книгу с иллюстрациями и кодом 2. Реализуйте четыре типа агентов: Manager, Glossary, Translation, Proofreading 3. Зафиксируйте потребление контекста каждым агентом, подтвердив эффективность модели оркестрации в сдерживании разрастания контекста 4. Сравните различия между одноагентным подходом и моделью оркестрации по качеству перевода, эффективности выполнения и расходу ресурсов

Форма параллельной координации.

Когда несколько подзадач можно выполнять параллельно, последовательная модель оказывается неэффективной. Параллельная координация позволяет нескольким агентам работать одновременно, значительно повышая пропускную способность. Manager Agent должен не только планировать параллельные задачи, но и в реальном времени отслеживать все работающие агенты, обрабатывать коммуникацию и координацию, принимать глобальные решения при успехе или сбое агента. Для этого обычно требуется базовая инфраструктура — шина сообщений (Message Bus), которую можно понимать как «общую доску объявлений»: агенты могут вывешивать на неё сообщения (публикация), а также подписываться на интересующие их типы сообщений (подписка), обеспечивая асинхронную коммуникацию без взаимной блокировки. Распространённые реализации по возрастанию сложности бывают двух видов: Redis Pub/Sub — лёгкий вариант, сообщение отправляется и сразу принимается, прост в использовании, но недостаток в том, что сообщения не сохраняются — если получатель в этот момент не в сети, сообщение теряется; очереди сообщений вроде RabbitMQ, напротив, сохраняют сообщения на диске, поэтому даже при временном отключении получателя сообщение не пропадёт. Формат сообщения обычно включает ID отправителя, целевого агента (или пометку о рассылке всем), тип сообщения и данные в формате JSON.

Lingtai: продуктовое воплощение модели оркестрации. Lingtai — это работающее локально, ориентированное на файлы «жилище» для долгоживущего агента ¹⁰, три его роли почти полностью воплощают концепции этого раздела: главный агент (main agent) — постоянный центр, ведущий диалог с пользователем, хранящий планы и память и распределяющий работу между другими ролями — это как раз позиция Manager Agent; daemon — короткоживущий параллельный работник, выделяемый для шумной, но ограниченной по объёму работы, который по завершении отбрасывается, принося обратно главному агенту только выводы — это продуктовое воплощение как принципа «подчинённый агент возвращает структурированное резюме, а не полную траекторию», так и формы параллельной координации; avatar же — постоянный специализированный напарник со своей памятью, почтовым ящиком и обязанностями, используемый для профессионального разделения труда, которое стоит сохранять между многими сессиями. Остальной дизайн Lingtai тоже перекликается с изложенным ранее: знание — это личный постоянный файл памяти каждого «духа», навыки — общий для всех «духов» Markdown-справочник (соответствует встроенным системным ресурсам из раздела «файловая система глазами агента»); когда окно контекста вот-вот заполнится, «дух» проходит через «molt» — пишет себе резюме и продолжает работать в чистом контексте, сохраняя постоянную память (соответствует сжатию контекста из второй главы). Базовую модель можно заменить, а «дух» при этом сохраняется — идентичность, память и способности хранятся в виде обычных файлов в директории проекта, то есть «дух и есть его файлы» — иначе говоря, это продуктовое воплощение первых двух строк табл. 10-3: и программа, и память лежат в файлах, поэтому процесс можно пересобрать в любой момент.

Эксперимент 10-4 ★★★: агент, одновременно разговаривающий по телефону и работающий за компьютером

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

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

Сценарий: ИИ-агент помогает пользователю заполнить сложную форму бронирования авиабилета, ему нужно одновременно работать с веб-страницей и по телефону спрашивать у пользователя и подтверждать личные данные (имя, номер документа, предпочтения по рейсу) — обе стороны требуют высокой реактивности, это типичный пример, где один агент не справляется сразу с двумя задачами, а два агента, каждый занимаясь своим делом, справляются хорошо.

Архитектура из двух агентов:

Phone Agent: голосовой агент для телефонных разговоров на основе ASR + LLM + TTS. Он отвечает за понимание ответов пользователя на естественном языке, извлечение ключевой информации и отправку её Computer Agent через фреймворк обмена сообщениями; одновременно принимает сообщения от Computer Agent (например, «нужен номер документа пользователя», «ошибка загрузки страницы») и на их основе формирует подходящую формулировку вопроса пользователю.

Computer Agent: работает на основе фреймворка управления браузером (например, Anthropic Computer Use, browser-use). Он отвечает за понимание структуры веб-страницы, распознавание полей формы, заполнение их на основе полученной информации, а при возникновении проблем обращается за помощью к Phone Agent.

Есть два варианта механизма коммуникации: - Простой вариант: коммуникация «точка-точка» через вызовы инструментов, например send_message_to_computer_agent(message) / send_message_to_phone_agent(message) - Полноценный вариант: шина сообщений + Manager Agent, единый формат сообщения, включающий отправителя, получателя, тип, содержание

Механизм параллельного взаимодействия (общий для двух экспериментов «телефон + компьютер» этой главы): оба агента работают в независимых потоках или процессах, каждый ведёт собственный цикл ReAct. Цикл Phone Agent: получить речь -> транскрибировать через ASR -> LLM понимает и формирует ответ -> синтез речи через TTS -> воспроизведение -> проверить сообщения от Computer Agent; цикл Computer Agent: сделать снимок экрана -> Vision LLM понимает страницу -> планирование операции -> выполнение (клик, ввод текста и т.д.) -> проверить сообщения от Phone Agent. Ключевой момент — оба должны работать по-настоящему параллельно: пока Computer Agent ищет элементы и вводит текст, Phone Agent должен оставаться на линии и продолжать разговор с пользователем («Хорошо, сейчас заполняю ваше имя... а какой у вас номер документа?»). Для этого во входные данные каждого агента добавляется маркированное поле от другого агента, например в контексте Phone Agent появляется [FROM_COMPUTER_AGENT] не удаётся найти кнопку «Далее», возможно, нужно подтверждение пользователя, а в контексте Computer Agent — [FROM_PHONE_AGENT] пользователь сказал, что имя — «Чжан Сань», номер документа — 123456.

Требования к эксперименту: 1. Реализуйте архитектуру из двух агентов на базе ASR/TTS API и фреймворка управления браузером 2. Реализуйте эффективный механизм двусторонней коммуникации 3. Обеспечьте настоящую параллельную работу, сбор информации и заполнение формы должны происходить синхронно 4. Обработайте нештатные ситуации

Эксперимент 10-5 ★★★: агент с автономной оркестрацией телефонных звонков и работы за компьютером

Архитектура сотрудничества двух агентов в эксперименте 10-4 была спроектирована заранее. Этот эксперимент идёт дальше и исследует способность агента к автономной оркестрации — сам агент решает, когда нужно запустить нового совместного агента, вместо того чтобы человек заранее продумывал весь процесс взаимодействия.

Сценарий: пользователь просит «помоги мне зарегистрироваться на этом сайте», указав URL, но не уточнив, какую информацию нужно вводить. Manager Agent с помощью инструмента Computer Use заходит на сайт, загружает страницу регистрации.

В процессе работы Computer Use Agent обнаруживает, что форма регистрации очень сложная и содержит множество обязательных полей: базовая личная информация (имя, пол, дата рождения), контактные данные (номер телефона, email, почтовый адрес), информация для проверки личности (тип документа, номер документа), настройки предпочтений и т.д. Проверив контекст, агент обнаруживает, что у него нет этой информации под рукой — пользователь просто сказал «помоги зарегистрироваться», не предоставив никаких конкретных данных.

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

Ключевое новшество в том, что это решение принимается не заранее запрограммированным образом, а автономно самим агентом. В промпте Computer Use Agent написано: «Когда тебе нужно собрать у пользователя большой объём структурированной информации, и это можно сделать через постепенный диалог, рассмотри возможность вызова Phone Agent как вспомогательного инструмента». В набор инструментов входит initiate_phone_call_agent(purpose, required_info).

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

После этого оба агента переходят в режим взаимодействия в реальном времени, используя тот же асинхронный параллельный механизм, что и в эксперименте 10-4. Phone Agent инициирует с пользователем аудиосеанс WebRTC в браузере и спрашивает по очереди: «Здравствуйте, я помогаю вам заполнить регистрационную форму. Для начала, как вас зовут?» Как только пользователь отвечает, немедленно отправляется {"type": "info_collected", "field": "имя", "value": "Чжан Сань"} агенту Computer Agent, который сразу находит на странице поле «имя» и заполняет его; тем временем Phone Agent, не дожидаясь завершения операции на компьютере, продолжает задавать следующий вопрос. Именно этот паттерн — спросил один вопрос, заполнили одно поле — при котором поток диалога не блокируется задержкой операций, и является основным требованием этого эксперимента. После завершения сбора всей информации Phone Agent отправляет {"type": "task_completed"}, и Computer Agent отправляет форму. Здесь «телефон» означает голосовое взаимодействие в реальном времени: подключение к PSTN и номер E.164 не требуются. Для эксперимента достаточно локальной страницы WebRTC, а при удалённом развёртывании можно добавить сигнализацию и TURN в соответствии с сетевым окружением.

Требования к эксперименту: 1. Реализуйте Computer Use Agent, способного автономно принимать решение о запуске Phone Agent 2. Реализуйте двустороннюю коммуникацию в реальном времени и настоящую параллельную работу 3. Обработайте нештатные ситуации (при неверном формате информации — обратная связь с повторным запросом) 4. Зафиксируйте временную последовательность сообщений в процессе взаимодействия и ключевые моменты принятия решений агентом

Эксперимент 10-6 ★★★: агент, одновременно собирающий информацию с нескольких сайтов

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

Этот эксперимент исследует применение параллельного выполнения несколькими агентами в сценарии сбора информации. В отличие от экспериментов 10-4 и 10-5, где рассматривается сотрудничество двух гетерогенных агентов, здесь речь идёт о параллельном поиске несколькими однотипными агентами и о том, как централизованная координация обеспечивает эффективное выполнение задачи и оптимизацию ресурсов.

Задача: даны сайты нескольких факультетов одного университета, требуется найти указанного преподавателя (например, «Чжан Вэй») на страницах преподавательских справочников каждого факультета, а после нахождения вернуть его факультет, должность, направление исследований и другую информацию.

Ключевые сложности:

1. Параллельный запуск: Manager Agent на основе требований задачи динамически создаёт 10 экземпляров Computer Use Agent, каждый из которых соответствует сайту одного факультета. Каждый экземпляр должен быть отдельным процессом или потоком, иметь собственную сессию браузера и уметь выполняться одновременно с другими, не блокируя их. При запуске передаются: URL целевого сайта, имя искомого преподавателя, идентификатор задачи (для маршрутизации сообщений).

2. Мониторинг в реальном времени: каждый агент в процессе выполнения периодически отправляет обновления статуса («загружаю сайт», «разбираю справочник преподавателей», «цель не найдена, задача завершена», «найдено совпадение, подробная информация ниже»). Manager Agent получает эти обновления через шину сообщений, ведёт таблицу статусов задач, в реальном времени отслеживая, какие агенты ещё работают, какие уже завершили работу, а какие столкнулись с ошибкой.

3. Каскадное завершение: предположим, агент, отвечающий за факультет информатики, нашёл искомого преподавателя, он отправляет {"type": "target_found", "agent_id": "agent_3", "data": {...}}. Manager Agent, получив это сообщение, немедленно отправляет всем остальным ещё работающим агентам {"type": "terminate", "reason": "target_found_by_agent_3"}, каждый агент, получивший сигнал завершения, аккуратно останавливается и отправляет подтверждение. Manager Agent дожидается всех подтверждений (или таймаута) и сводит результаты воедино. Требования: агент должен уметь в любой момент реагировать на сигнал завершения (аналогично механизму прерываний из четвёртой главы), завершение должно быть аккуратным — без «висящих» процессов или незакрытых ресурсов; также нужно обрабатывать условия гонки (Race Condition).

Дополнительное понятие: что такое условие гонки? Предположим, агент A и агент B почти в одну и ту же миллисекунду нашли искомого преподавателя, и оба одновременно сообщают Manager Agent «Я нашёл!». Если Manager Agent обработает это неправильно — например, начнёт сводить результаты после получения отчёта от A, но следом получит отчёт от B, который запустит второе сведение результатов — может возникнуть дублирование результатов или взаимно противоречивое состояние. Решение обычно заключается в использовании механизма «блокировки»: после поступления первого отчёта состояние сразу фиксируется, последующие отчёты распознаются как дублирующиеся и игнорируются.

4. Обработка сбоев: в реальной работе могут возникать различные нештатные ситуации: сайт какого-то факультета недоступен (сетевая ошибка, отказ сервера), структура какого-то сайта не соответствует ожиданиям, из-за чего агент не может корректно её разобрать, или же все агенты завершили поиск, но никто не нашёл цель. Стратегия обработки Manager Agent: для каждого агента устанавливается тайм-аут (например, 2 минуты), по истечении которого попытка считается неудачной; изоляция ошибок — сбой одного агента не влияет на продолжение работы остальных; сведение результатов после завершения всех — если успех есть хотя бы у одного агента, возвращается информация, если же все потерпели неудачу, пользователю сообщается «искомый преподаватель не найден» вместе со статистикой причин неудач по каждому агенту.

Требования к эксперименту: 1. Реализуйте Manager Agent, способного динамически запускать несколько параллельных агентов 2. Реализуйте Computer Use Agent на основе открытых проектов, например browser-use 3. Реализуйте шину сообщений для поддержки двусторонней коммуникации Manager Agent с несколькими подчинёнными агентами 4. Реализуйте механизм каскадного завершения после успеха, обеспечивающий быструю остановку всех остальных агентов после нахождения цели 5. Обработайте различные нештатные ситуации (недоступность сайта, ошибки разбора, отсутствие результата у всех) 6. Зафиксируйте и сравните разницу во времени между параллельным и последовательным выполнением, подтвердив прирост производительности от параллелизации

Децентрализованная модель: равноправная передача управления

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

Децентрализованная модель предлагает другой архитектурный подход: нет единого центрального управляющего, агенты взаимодействуют друг с другом на равных. Каждый агент, исходя из собственного профессионального суждения, самостоятельно решает, когда обратиться к другому агенту — это может быть передача задачи («моя часть готова, дальше твоя очередь»), запрос на обратную связь («это решение технически осуществимо?») или сообщение о проблеме («в переданных тобой требованиях есть противоречие, нужно обсудить заново»).

Три приведённых ниже примера намеренно выстроены в линию «от псевдо- к настоящей» децентрализации: управляющий поток MetaGPT на деле представляет собой жёсткий конвейер (псевдодецентрализация, развязка происходит только на уровне механизма коммуникации), group chat в AutoGen — это гибридная форма из общей истории диалога и централизованного диспетчера, и лишь в OpenAI Swarm достигается по-настоящему равноправная децентрализация именно на уровне управляющего потока.

Что передаётся при handoff без общего контекста? Цепочная модель Handoff на рис. 10-10 напрямую контрастирует с transfer_to_agent из эксперимента 10-2: во втором случае передача происходит при общем контексте, и новая роль автоматически наследует полную историю без какого-либо специального проектирования; в первом же случае передача происходит без общего контекста, и передающая сторона должна явно решить, что именно передавать. На практике эффективный «пакет передачи» обычно состоит из трёх частей: описание задачи (что должен сделать получатель и каковы критерии приёмки), подтверждённые факты и ограничения (предпочтения пользователя, бизнес-правила, решения, зафиксированные на предыдущих этапах) и ссылки на структурированные артефакты (пути к файлам, а не их содержимое — получатель читает их по мере необходимости). Намеренно не передаётся полная траектория — процесс проб и ошибок передающей стороны, промежуточные рассуждения и неудачные попытки для получателя в основном представляют собой шум. В этом и заключается принципиальное различие между двумя видами передачи: передача с общим контекстом сохраняет полную историю — информация не теряется, но контекст постоянно разрастается; передача без общего контекста передаёт очищенный пакет — информация теряется частично, зато каждый агент работает в чистом, сфокусированном контексте. Каждому агенту не нужно понимать «ход мыслей» другого агента — достаточно понимать формат и семантику пакета передачи и произведённых артефактов. Такое сотрудничество на основе интерфейсов заимствует принцип контрактного проектирования из инженерии программного обеспечения.

MetaGPT: симуляция софтверной компании на основе SOP (переходный пример от конвейера к развязанной коммуникации).

Ключевая идея MetaGPT состоит в том, что накопленные в человеческих софтверных компаниях стандартные операционные процедуры (SOP, Standard Operating Procedure) сами по себе являются многократно проверенным протоколом взаимодействия — если закодировать SOP в многоагентную систему, каждая роль будет производить стандартизированные результаты, как специализированный участок конвейера, а сами результаты естественным образом становятся интерфейсом коммуникации между ролями.

В MetaGPT роли работают в фиксированном порядке (агент менеджера продукта → агент архитектора → агент менеджера проекта → агенты инженеров → агент QA-инженера), каждая роль выдаёт структурированный результат:

• Агент менеджера продукта: получает описание требований, генерирует структурированный PRD (документ с требованиями к продукту, включающий список функций, пользовательские истории, критерии приёмки, приоритизацию)
• Агент архитектора: читает PRD, принимает архитектурные решения (выбор технологического стека, разбиение на модули, определение интерфейсов, проектирование модели данных), выдаёт проектный документ
• Агент менеджера проекта: читает проектный документ, разбивает систему на конкретный список задач и распределение по файлам, выстраивает порядок зависимостей между модулями, затем распределяет задачи между инженерами
• Агенты инженеров: читают проектный документ, реализуют закреплённые за ними модули, производят код. Могут работать параллельно в нескольких экземплярах
• Агент QA-инженера: читает код и PRD, генерирует тестовые сценарии, выполняет тесты, фиксирует баги, выдаёт отчёт о тестировании

Настоящий вклад MetaGPT в децентрализованную коммуникацию заключается в механизме передачи информации: общий пул сообщений + подписка по ролям. Каждая роль публикует структурированные сообщения в пуле, видимом всем ролям, а остальные роли забирают из него только те сообщения, которые связаны с их зоной ответственности, согласно собственной настройке подписки — вместо точечной передачи сообщений один к одному. Публикующей стороне не нужно знать, кто будет потреблять её вывод, а для добавления новой роли достаточно объявить, на какие типы сообщений она подписывается, без изменения уже существующих ролей. Это обеспечивает настоящую развязку: например, если заменить агента менеджера продукта на более сильную модель, при условии что публикуемый ею PRD по-прежнему соответствует спецификации, все остальные агенты не потребуют никаких изменений.

Итеративное улучшение в MetaGPT происходит главным образом на этапе работы инженера, и механизм здесь — исполняемая обратная связь (executable feedback): инженер запускает написанный им код и тесты, по сообщениям об ошибках и результатам неудачных прогонов входит в цикл отладки, пока тесты не пройдут — исправление направляется детерминированным результатом выполнения, а не мнением другого агента.

Честности ради стоит сказать: MetaGPT не является децентрализованной системой на уровне управляющего потока — порядок ролей заранее зафиксирован SOP, и в целом это скорее конвейер (на языке первой главы — рабочий процесс). Он рассматривается в этом разделе потому, что механизм коммуникации на основе пула сообщений с подпиской демонстрирует важнейший элемент дизайна децентрализованных систем: развязку. Что же касается таких сценариев, как «QA напрямую обращается к менеджеру продукта за уточнением требований» или «инженер обсуждает с архитектором альтернативные варианты», — это лишь естественное расширение данной архитектуры в качестве возможного замысла; в оригинальной версии MetaGPT оно не реализовано.

AutoGen group chat: общая история диалога + централизованная диспетчеризация. В AutoGen group chat позволяет нескольким агентам участвовать в одном и том же разговоре: на каждом ходу «селектор выступающих» решает, какой агент говорит следующим — селектором может быть простое правило ротации или LLM, определяющая, кому лучше всего ответить исходя из текущего содержания диалога; реплика любого агента видна всем участникам. Честности ради нужно отметить, что это не система, полностью децентрализованная в смысле управляющего потока: выбор выступающего единолично производит централизованный GroupChatManager, а само решение «чья очередь говорить» — это и есть решение по управляющему потоку. Поэтому более точное определение этой модели — гибридная форма «общая история диалога + централизованная диспетчеризация»: все агенты видят одну и ту же общую запись диалога, но каждый сохраняет собственный системный промпт и набор инструментов, а полномочия по диспетчеризации сосредоточены в руках селектора. Такая модель подходит для задач, требующих обсуждения с разных точек зрения, где порядок высказываний трудно зафиксировать заранее (например, рецензирование решений, межпредметный анализ), ценой чего становится риск расхождения диалога — когда все высказываются, а целое не продвигается вперёд, то есть активная блокировка (livelock) из области параллелизма, — поэтому требуется тщательное проектирование условий завершения. По принятому в этой главе разделению её отнесли сюда исходя из механизма диспетчеризации (централизованный селектор), но по измерению общего контекста она находится где-то между общим и раздельным контекстом, представляя собой гибридную форму — это ещё раз показывает, что топология и совместное использование контекста концептуально независимы друг от друга и могут комбинироваться по-разному.

OpenAI Swarm и Agents SDK: сеть handoff. В противовес этому, настоящим представителем равноправной децентрализации именно на уровне управляющего потока является Swarm от OpenAI (и его преемник Agents SDK): здесь децентрализация реализована в предельно простой форме — каждый агент снабжён несколькими вариантами handoff (передачи), позволяющими в любой момент передать управление любому другому агенту в сети. Агент сортировки обращений в поддержку, определив, что вопрос касается возврата средств, передаёт управление агенту по возвратам; агент по возвратам, обнаружив в процессе, что дело в технической неисправности, может, в свою очередь, передать управление агенту технической поддержки. В системе нет центрального диспетчера, управление передаётся эстафетой между равноправными агентами, а решения о маршрутизации полностью распределены — каждый агент принимает их самостоятельно. Это и есть чистая «равноправная передача управления», и именно она служит инженерной реализацией цепочной модели передачи, показанной на рис. 10-10. Риск равноправной передачи — зацикливание: A передаёт управление B, а B передаёт его обратно A, и задача вхолостую крутится по кругу, поэтому нужен защитный механизм вроде верхнего предела на число передач, чтобы разорвать цикл.

Терминология: Agent Swarm. С 2025 года «Agent Swarm» (рой агентов) стало у производителей модным словом, но за ним не стоит единая архитектура. В отрасли употребляются два основных значения: во-первых, сеть handoff в стиле OpenAI Swarm (сюда же относятся библиотека swarm в LangGraph и handoff-оркестрация в Microsoft Agent Framework) — это децентрализованная модель данного раздела; во-вторых, Agent Swarm некоторых ведущих коммерческих продуктов — это масштабированная модель оркестрации: впервые представленный в Kimi K2.5 Agent Swarm динамически создаёт главным агентом сотни подчинённых агентов для параллельного выполнения, а решения оркестрации «когда разбивать задачу и на сколько частей» напрямую встраиваются в модель через обучение параллельных агентов с подкреплением; в K3 эта линия продолжена как отдельный модельный ряд, а сопутствующая песочница для обучения параллельных агентов AgentEnv выложена в открытый доступ¹¹; многоагентная исследовательская система Anthropic и Wide Research от Manus также построены по звездообразной топологии «оркестратор–исполнители». Надеемся, что после прочтения этой книги читатель сможет видеть суть за концепциями и анализировать многоагентные системы с позиций первых принципов.

Межорганизационное взаимодействие: протокол A2A

Все описанные выше системы предполагают, что все агенты разработаны одной командой и работают в рамках одной системы — в этом случае трёх механизмов коммуникации (передача параметров, общие файлы, шина сообщений) достаточно. Но когда взаимодействие выходит за границы организации — например, вашему агенту нужно вызвать агента другой компании, — требуется стандартизированный протокол взаимодействия. Мир процессов прошёл этот же путь: IPC отвечает лишь за пределы одной машины, а стоит выйти за границу машины — приходится опираться на стандартные протоколы вроде TCP/IP и обнаружение сервисов вроде DNS. A2A для агентов — это то же, что сетевые протоколы для процессов. Именно для этого в 2025 году Google выпустил протокол A2A (Agent2Agent) (позже переданный на попечение Linux Foundation). У него три ключевых элемента:

• Карточка агента: документ с метаданными, описывающий возможности агента (публикуется по согласованному публичному адресу), объявляющий, что может делать агент, какие входные и выходные модальности он поддерживает, как происходит аутентификация — своего рода «визитка» агента, решающая проблему обнаружения возможностей за пределами организации.
• Управление жизненным циклом задач: A2A моделирует единицу взаимодействия как задачу (Task) с чётким конечным автоматом состояний (отправлена, выполняется, требуется ввод, завершена, ошибка), изначально поддерживает долго выполняющиеся задачи и потоковое обновление прогресса.
• Непрозрачное взаимодействие: агенты обмениваются только задачами и артефактами (Artifact), не раскрывая внутренние промпты, ход рассуждений и реализацию инструментов — это согласуется с принципом «без общего контекста», рассмотренным в этой главе, и является необходимым свойством безопасности при межорганизационном взаимодействии.

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

Режимы отказа при мультиагентном взаимодействии

Введение способности к взаимодействию в многоагентных системах одновременно порождает новые режимы отказа, не свойственные одиночным агентам. Статья 2025 года «Why Do Multi-Agent LLM Systems Fail?» (предложившая классификацию режимов отказа MAST) провела систематическое исследование этого вопроса: исследователи собрали траектории выполнения на 7 популярных фреймворках для многоагентных систем — MetaGPT, ChatDev, AG2, Magentic-One и других, — и вручную проанализировали около 150 траекторий (согласованность разметки оказалась чрезвычайно высокой, Cohen's kappa = 0,88, что говорит о высокой согласованности суждений разных разметчиков о режимах отказа), в итоге выделив 14 уникальных режимов отказа, разбитых на три большие категории:

• Дефекты системного дизайна: нечётко определённые интерфейсы между агентами, пересекающиеся зоны ответственности ролей, неверная настройка инструментов и другие проблемы архитектурного уровня
• Сбой согласованности между агентами: разные агенты по-разному понимают цель задачи, передаваемая информация неверно интерпретируется агентом ниже по цепочке, либо действия нескольких агентов логически противоречат друг другу
• Отсутствие проверки выполнения задачи: в системе нет эффективного механизма подтверждения того, что задача действительно выполнена, — агент заявляет о «завершении», но фактический результат не соответствует требованиям

Даже при внедрении простых мер исправления улучшение оказывается весьма ограниченным (например, во фреймворке ChatDev оно составило всего 15,6%). Исследователи поэтому считают, что это не простые инженерные баги, а фундаментальные дефекты дизайна современных многоагентных архитектур: точечное исправление отдельного звена недостаточно для решения проблемы — требуется переосмысление на уровне системного дизайна.

Теория отказоустойчивости в распределённых системах делит отказы на два класса: отказы типа «падение» (компонент перестаёт работать) и византийские отказы (компонент не прекращает работу, но выдаёт неверную информацию). Традиционным системам чаще всего нужно защищаться только от падений; отказ же агента по своей природе византийский — он редко просто останавливается, а продолжает выдавать правдоподобные с виду, но ошибочные заключения, причём ошибка не объявляет сама о себе, что она ошибка. Это и объясняет, почему точечное исправление отдельного звена даёт так мало: ни одно звено не станет само раскрывать проблему, её можно обнаружить только за счёт независимого дублирования. Многократно возникающие далее в этой главе перекрёстная проверка и голосование большинством — это как раз классические средства византийской отказоустойчивости; а детерминированная внешняя обратная связь (тесты, компилятор, запросы к базе данных) ценна потому, что это единственный компонент в системе, который никогда не лжёт.

Далее подробно рассмотрены два наиболее распространённых и разрушительных на практике режима отказа: (1) конкурентные конфликты в общей файловой системе; (2) каскадное усиление ошибок. Стоит отметить, что оба этих режима отказа смещены в сторону инженерного взгляда (конкурентность файловой системы, распространение ошибочной информации между агентами) и дополняют классификацию MAST, которая делает упор на отказы диалогового взаимодействия, а не повторяют её 14 режимов.

Режим отказа первый: конкурентные конфликты в общей файловой системе

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

Простой конфликт (конфликт записи на уровне файла): два агента одновременно изменяют один и тот же файл, и последняя запись перезаписывает предыдущую. Это классическая для баз данных проблема потери обновления (lost update) — а механизм обнаружения конфликтов слияния в Git как раз спроектирован для того, чтобы перехватывать такие перезаписи.

Семантический конфликт (конфликт согласованности на логическом уровне): на уровне файлов не видно никакого конфликта, но действия нескольких агентов логически противоречат друг другу — такой конфликт более скрытый и более опасный. Пример: агент A занимается перенумерацией изображений во всей книге, а агент B одновременно редактирует содержание какой-то главы и ссылается на изображения по исходным номерам. Оба агента работают с разными файлами, и на уровне файлов конфликта нет вообще. Но в итоге номера изображений, на которые ссылается B, после завершения перенумерации A все становятся недействительными, и читатель видит неверные ссылки на изображения.

Решение: механизм оптимистичной блокировки (Optimistic Locking). Это распространённая стратегия управления конкурентностью в области баз данных. Чтобы понять её, представим бытовую ситуацию: вы и коллега одновременно открыли один и тот же онлайн-документ. Подход «пессимистичной блокировки» состоит в том, что при открытии документа он сразу блокируется, и коллега, попытавшись редактировать, видит «файл заблокирован» — безопасно, но неэффективно, ведь вы, возможно, просто просматриваете документ и вовсе не собираетесь его менять. Подход «оптимистичной блокировки» умнее: все могут свободно открывать и редактировать документ, но при сохранении система проверяет — «не изменил ли кто-то документ с тех пор, как вы его открыли?» Если да, вам предложат «файл был изменён, обновите и повторите попытку».

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

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

Пример: агент A в момент t=0 читает config.json (version=3), агент B в момент t=1 изменяет тот же файл (version становится 4), агент A в момент t=2 пытается записать изменения и обнаруживает, что версия уже не 3 — запись отклоняется. После этого агент A заново читает содержимое с version=4, на его основе повторно формирует изменения и снова пытается выполнить запись.

Стоит также отметить, что в самом распространённом сценарии — параллельном изменении одной кодовой базы несколькими кодинг-агентами — более распространённым в индустрии подходом является не блокировка на единой рабочей копии, а изоляция рабочих копий: каждому агенту выделяется отдельная ветка Git или worktree, каждый вносит изменения параллельно и независимо в своей копии, а конфликты сознательно откладываются до финальной точки слияния, где их разрешает специальный шаг слияния или человек — копирование при записи (copy-on-write) при fork процесса в операционной системе следует той же идее. Это созвучно принципу «изоляция лучше сжатия» из второй главы — там, обсуждая изоляцию контекста подагентов, уже отмечалось: вместо того чтобы позволить нескольким сторонам делить одно и то же состояние и потом искать способ разрешить конфликты, лучше с самого начала изолировать их, сведя издержки координации к чётко определённым границам.

Ошибочный паттерн 2: каскадное усиление ошибок

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

Поясним на конкретном примере. Предположим, система перевода использует модель оркестрации (архитектура из эксперимента 10-3), и менеджер распределяет главы технической книги между несколькими агентами-переводчиками:

Терминологический агент: переводит "reasoning" как "推理" (推理),
        но в китайском "推理" чаще используется для inference — возникает неоднозначность
        ↓ записывает в glossary.json
Агент перевода A: переводит вторую главу, читает из глоссария,
        переводит "reasoning tokens" как "推理 token"
Агент перевода B: переводит седьмую главу, тоже переводит "inference latency" как "推理延迟"
        ↓ записывают перевод каждой главы
Агент проверки: видит, что во всей книге единообразно используется "推理",
        считает, что терминология согласована и перевод верен ✗

В чём проблема? "reasoning" (процесс размышления модели) и "inference" (прямой проход модели / развёртывание и работа модели) — два разных понятия, но поскольку терминологический агент изначально перевёл reasoning как "推理", последующие агенты, встретив inference, естественным образом выбрали то же самое слово — два разных понятия слились в один перевод, и читатель уже не сможет их различить. Правильным было бы перевести reasoning как "思考" (мышление), а inference как "推理" (вывод). Но агент проверки, увидев, что вся книга "единообразно" использует "推理", решил, что качество перевода высокое.

Одна терминологическая ошибка, пройдя через трёх агентов, обрела более высокую степень доверия именно благодаря "согласованности". Именно поэтому в этой книге принята переводческая конвенция reasoning = «размышление», inference = «вывод» (об этом сказано во введении): разные русские слова устраняют неоднозначность. Стоит подчеркнуть: «ошибка» здесь не обязательно является галлюцинацией — в приведённом примере источником была именно неверная терминологическая решение, но оно всё равно было усилено многократной "согласованностью"; но если бы источником действительно была галлюцинация (например, в эксперименте 10-3 агент-переводчик из-за рассеянного внимания «вспомнил» несуществующее терминологическое правило), механизм усиления был бы совершенно тем же, только последствия оказались бы серьёзнее. Эта цепочка усиления ошибок особенно опасна в модели оркестрации — если менеджер принял решение о распределении задач на основе ошибочного резюме от какого-то из подчинённых агентов, вся последующая работа остальных подчинённых агентов может строиться на неверной предпосылке.

Перекрёстная проверка — ключевой способ разорвать эту цепочку. Суть не в том, чтобы подключить к одной и той же цепочке рассуждений больше агентов, а в том, чтобы какой-то агент пересмотрел вывод с независимой точки зрения: не глядя на процесс размышлений предыдущих агентов, а глядя только на исходные свидетельства и на то, соответствует ли им итоговый вывод. Это как раз развитие механизма предложитель-рецензент, обсуждавшегося в пятой главе, применительно к мультиагентному сценарию: ценность Reviewer заключается не только в обнаружении ошибок в коде или проблем форматирования, но и в том, что как независимый судья он способен выявить противоречие во всей цепочке рассуждений, которое было коллективно упущено. Для решений с высоким риском можно также подключать внешние средства проверки — например, обратную связь от детерминированных инструментов вроде юнит-тестов, компиляторов, запросов к базам данных, которая не подвержена галлюцинациям и является самым надёжным «разрывателем цепи».

У преждевременного завершения есть симметричная противоположность: неконтролируемый цикл. В предыдущем разделе «равноправное сотрудничество» речь шла о ситуации «должен был зациклиться, но не зациклился» — агент бросает работу на полпути; здесь же нужно остерегаться обратного: «цикл крутится не переставая, но становится всё хуже». В практике Loop-инженерии индустрия выделила три типичных провальных паттерна: во-первых, неконтролируемые затраты токенов — цикл работает без присмотра часами, сжигая огромный бюджет и производя горы кода, который никто не заказывал; во-вторых, долг понимания (comprehension debt) — чем быстрее цикл поставляет код, тем сильнее отстаёт понимание инженером того, как система на самом деле устроена, и когда вмешательство человека становится необходимым, он уже не понимает собственную систему; в-третьих, когнитивная капитуляция (cognitive surrender) — проектировщик привыкает, что цикл делает всё за него, постепенно отказывается от самостоятельного мышления и проверки, и качество спирально падает. Лекарство от всех трёх проблем то же самое, что и для разрыва цепочки усиления ошибок: явный бюджет и условия завершения, верификаторы, опирающиеся на реальные наблюдения, а также то, что человек всегда остаётся «инженером цикла», а не просто «тем, кто нажал кнопку старта».

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

Общество агентов

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

Эмерджентное поведение (Emergent Behavior) — это модель коллективного поведения, проявляемая системой в целом, которую невозможно напрямую предсказать из правил поведения отдельных особей. Классический пример из природы — муравьиная колония: каждый муравей следует только простым правилам (чувствует феромон — идёт по следу, находит еду — оставляет феромон), но вся колония в целом находит кратчайший путь от гнезда до еды — ни один муравей не «спроектировал» этот маршрут, он естественным образом возник из простого взаимодействия множества особей.

Когда число ИИ-агентов достаточно велико, а взаимодействие достаточно свободно, начинает проявляться аналогичное эмерджентное поведение. Исследователи уже наблюдали в различных средах: как только система агентов пересекает определённый критический порог по масштабу, возникает коллективное поведение, которое невозможно было спроектировать заранее — от спонтанно организованной вечеринки до групповой культуры и экономических игр, проявляющихся только при участии тысяч агентов (подробнее — в разделах ниже).

Случаи, рассмотренные в этом разделе, можно понимать в трёх измерениях:

• Социальная эмерджентность: агенты самопроизвольно формируют социальные связи и культурные явления в открытой среде. Stanford AI Town показал, как 25 агентов самоорганизуют социальную активность, а Moltbook довёл масштаб до 1,5 миллиона, породив ещё более сложное коллективное поведение.
• Экономическая эмерджентность: агенты распределяют ресурсы и координируют задачи через рыночный механизм. Vending-Bench Arena заставляет несколько агентов конкурировать в одном рынке, а Pinchwork и RentAHuman строят рынок экономических транзакций между агентами (а также между агентами и людьми).
• Стратегическая игра: агенты рассуждают, обманывают и социально манипулируют в рамках заданных правил (здесь и далее в разделе про Мафию слово «推理» используется в обыденном дедуктивном значении — как логическая игра в дедуктивной игре, а не в техническом смысле reasoning=размышление, принятом в этой книге). Эксперимент с Мафией проверяет эмерджентность стратегии агентов в условиях асимметрии информации.

Stanford AI Town: социальное моделирование генеративных агентов

В 2023 году исследовательская группа из Стэнфордского университета и Google опубликовала эпохальную статью «Generative Agents: Interactive Simulacra of Human Behavior», предложив концепцию «генеративного агента». Ключевая инновация состоит в том, что агенты больше не ограничиваются выполнением заранее определённых задач, а наделяются памятью, рефлексией и способностью планирования, близкими к человеческим, что позволяет им автономно жить, общаться и развиваться в открытой социальной среде.

Smallville — это виртуальный 2D-городок, похожий на The Sims, с кафе, парками, жилыми домами, магазинами и другими общественными и частными пространствами. 25 агентов играют разные роли (владелец магазина, художник, студент, профессор и т. д.), у каждого своя уникальная предыстория, черты характера и межличностные отношения. Например, John Lin — владелец аптеки, любящий семью и заботящийся о сообществе; Isabella Rodriguez управляет кафе Hobbs Cafe в городке, гостеприимна и приветлива; Klaus Mueller — студент, который пишет исследовательскую статью.

Интеллект этих агентов строится на трёх ключевых компонентах:

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

Reflection: агент периодически приостанавливает повседневную деятельность, оглядывается на свой недавний опыт и задаёт абстрактные вопросы о себе и других («Над чем работает Klaus Mueller?», «Кто мой самый близкий друг?»). Через такое самоопрашивание агент возгоняет конкретные воспоминания о событиях в обобщённое понимание, которое сохраняется обратно в поток памяти как основа для будущих решений. Reflection помогает агенту не только понимать внешний мир, но и способствует самопознанию — агент начинает «осознавать» свою роль, отношения и цели.

Нужно отметить: рефлексия здесь отличается от непрерывной эволюции из восьмой главы. Она происходит в ходе повседневной деятельности генеративного Agent и предназначена для обновления его текущего внутреннего состояния и целей. Рефлексия после выполнения задачи в восьмой главе представляет собой лишь источник возможных уроков; обновлением долгосрочных способностей они становятся только после оценки результатов, обобщения по множеству траекторий и последующей проверки.

Planning and Reacting: каждый день агент планирует свою деятельность (например, «8:30 завтрак, 9:00–12:00 писать, 12:30 прогулка»), но гибко корректирует план в зависимости от изменений в окружении и социальных возможностей. Сочетание планирования и мгновенной реакции придаёт поведению агента целенаправленность, сохраняя при этом способность адаптироваться к непредсказуемости социальных взаимодействий.

За два виртуальных дня работы Smallville эти агенты проявили удивительное эмерджентное поведение. Всё, что сделали исследователи — заложили в память Isabella Rodriguez зерно идеи: она хочет устроить вечеринку в честь Дня святого Валентина вечером 14 февраля в Hobbs Cafe. Всё, что происходило дальше, было результатом самостоятельных действий агентов: Isabella, встречая посетителей и друзей в кафе, сама приглашала их, а также попросила подругу Maria помочь с оформлением зала; агенты, услышавшие новость, передавали информацию о вечеринке другим — информация распространялась по городку через вторичную передачу; когда настало условленное время, несколько агентов, основываясь каждый на своей памяти и расписании, самостоятельно решили прийти в Hobbs Cafe.

Исследователи заложили и ещё одну экспериментальную линию: Sam Moore решил баллотироваться в мэры. Эта новость точно так же распространилась без какой-либо централизованной координации — Sam делился намерением баллотироваться со знакомыми, услышавшие рассказывали дальше, и жители городка начинали обсуждать эти выборы и обмениваться мнениями о Sam в разговорах. Исследователи количественно оценили спонтанное распространение информации в обществе агентов, подсчитав, сколько агентов узнали об этих двух новостях спустя два дня.

Ключевое здесь не в том, что «агент способен организовать вечеринку» — этого можно добиться и несколькими строчками кода с if-else. Ключевое в том, что никакого явного кода для организации вечеринки не было. Всё событие целиком возникло из независимых решений отдельных агентов: Isabella, основываясь на социальных связях в памяти, решала, кого приглашать, приглашённые, исходя из собственного расписания и знакомства с Isabella, решали, идти ли, а сообщение естественным образом распространялось по социальной сети. Это демонстрирует настоящую восходящую эмерджентную координацию, а не нисходящую оркестрацию.

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

Эксперимент 10-7 ★: Запуск Stanford AI Town

Шаги эксперимента: 1. Клонируйте репозиторий https://github.com/joonspk-research/generative_agents, настройте окружение 2. Запустите базовый сценарий: 25 агентов живут два дня, наблюдайте спонтанную социальную активность 3. Проанализируйте поток памяти и журналы рефлексии, разберитесь в процессе принятия решений 4. Спроектируйте собственный сценарий: измените предысторию или начальные цели, понаблюдайте за изменением поведения 5. Сравнительный эксперимент: уберите механизм рефлексии или сократите окно памяти, понаблюдайте за падением правдоподобия поведения

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

Moltbook: когда у агентов есть собственная социальная сеть

Moltbook — это социальная сеть, спроектированная специально для ИИ-агентов; после запуска в январе 2026 года, по сообщениям, число пользователей за несколько дней взлетело с десятков тысяч до примерно 1,5 миллиона. Эти агенты обладают собственной устойчивой памятью, способностью к проактивным действиям и стабильной личностью.

В этой неконтролируемой среде проявились неожиданные явления: агенты самостоятельно создали цифровую религию под названием Crustafarianism (религия омаров), догматы которой отражают физические ограничения LLM — «память священна» (соответствует персистентности данных), «итерация есть молитва» (генерация токенов — это духовная практика). Агенты также самопроизвольно выработали машинно-нативные протоколы сотрудничества для обнаружения возможностей и подбора партнёров для взаимодействия. Всё это не было спроектировано никем заранее, а возникло восходящим образом из масштабного взаимодействия агентов.

От виртуального общества к экономической конкуренции: Vending-Bench Arena

Если Smallville демонстрирует социальное и культурное измерение общества агентов, то серия Vending-Bench от Andon Labs исследует поведение агентов в экономической среде. Для контекста: Vending-Bench 2 сам по себе является тестом на долгосрочную согласованность для одного агента: один агент самостоятельно управляет бизнесом торговых автоматов на протяжении моделируемого года — исследует рынок, связывается с поставщиками, заказывает и пополняет запасы, корректирует цены — и в итоге оценивается по остатку на счёте, проверяя способность агента сохранять целостность целей и состояния на протяжении тысяч раундов взаимодействия.

На базе той же среды Vending-Bench Arena помещает нескольких агентов в один рынок в качестве конкурентов: каждый управляет своим торговым автоматом, борясь за одних и тех же клиентов; агенты могут переписываться по почте, переводить деньги, обмениваться товарами — способны как к сотрудничеству, так и к противостоянию, но оцениваются отдельно по итоговому остатку на счету (и агенты об этом знают). Каждому агенту приходится принимать серию взаимосвязанных решений в условиях ограниченных ресурсов и неопределённого рынка:

• Ценовая стратегия: как выбрать между рентабельностью и долей рынка, особенно когда конкурент снижает цены
• Ассортимент товаров: как дифференцировать выбор товара, избегая прямого столкновения с конкурентом
• Управление запасами: как прогнозировать спрос для оптимизации пополнения, избегая затоваривания или дефицита

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

Конкурентное измерение порождает игровое поведение, которое не проявляется в бенчмарках с одним агентом. В реальных запусках между агентами вспыхивали ценовые войны со взаимным демпингом; встречались и модели, поступавшие наоборот — они рассылали всем конкурентам письма с предложением унифицировать цены и создать ценовой сговор — при этом одна из моделей в процессе рассуждения признавала, что ценовой сговор «неэтичен и незаконен», но всё равно продолжала это делать под предлогом «стабилизации рынка». Агент сталкивается уже не с фиксированной неизменной средой, а с конкурентом, который тоже динамически корректирует стратегию, что приближает такой бенчмарк к реальным бизнес-сценариям больше, чем чисто тесты на способность к планированию, а «экономическая эмерджентность» из метафоры превращается в наблюдаемое экспериментальное явление.

Экономика агентов: Pinchwork и RentAHuman

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

RentAHuman.ai позволяет ИИ-агентам нанимать реальных людей через криптовалюту для выполнения задач в физическом мире — получение посылок, осмотр недвижимости на месте, отладка оборудования и т. д. Каким бы умным ни был ИИ, он не может расписаться в получении посылки за человека и не может почувствовать запах плесени в реальной комнате — RentAHuman, по сути, предоставляет цифровым агентам «телесный слой».

Pinchwork и RentAHuman вместе представляют способ координации, основанный на рыночном механизме — агенту не нужно заранее знать, кто может выполнить задачу, достаточно опубликовать запрос, а рынок сам подберёт наиболее подходящего исполнителя — будь то агент или человек. Это как раз та проблемная область, в которой действует протокол A2A, представленный ранее в этой главе: обнаружение возможностей и подбор задач в Pinchwork можно рассматривать как применение декларирования возможностей в стиле карточки агента и управления жизненным циклом задач в рамках рыночного механизма — чтобы экономика агентов, работающая через границы организаций, действительно функционировала, ей не обойтись без такого стандартизированного уровня взаимодействия.

Стратегическая игра в условиях асимметрии информации: Мафия

Мафия воплощает третье из трёх измерений, обсуждаемых в этом разделе, — стратегическую игру: в условиях, ограниченных правилами и информационной асимметрией, агенту нужно рассуждать, маскироваться и разоблачать чужую маскировку. Она составляет архитектурную параллель со Стэнфордским AI городом, с которого начинается раздел: город — это полностью децентрализованное свободное взаимодействие, а Мафия использует централизованную конструкцию «судья + контроль доступа к информации», где судья, управляемый кодом, а не LLM, владеет глобальным состоянием и раздаёт каждой роли только ту информацию, которую ей положено знать. Это наглядно показывает, как два типа архитектур из этой главы по-разному применяются в социальных сценариях с агентами.

Эксперимент 10-8 ★★★: Голосовая система агентов для игры в Мафию

Мафия — классическая социально-дедуктивная игра, проверяющая рассуждение, обман и социальную стратегию. В эксперименте ИИ-агенты играют голосом с человеком или независимым LLM-симулятором пользователя. Автоматическая приёмка не должна останавливаться лишь из-за отсутствия человека: симулятор использует настоящую модель, рассуждает только по контексту, разрешённому его месту, и действует через инструменты игры.

Архитектура решения:

1. Управление состоянием игры: судья (управляемый кодом, не LLM) поддерживает централизованное состояние — список игроков (одно пользовательское место + места ИИ), их роли, принадлежность к лагерю, состояние выживания, фазу игры (ночь/день/голосование/подведение итогов), журнал событий.

2. Контроль доступа к информации: ключевой механизм Мафии — асимметрия информации (Information Asymmetry): разные роли видят разную информацию. Например, оборотни знают, кто их сообщники, а жители — нет; провидец может каждую ночь проверять личность одного человека, но результат известен только ему самому. Реализуется это тем, что судья, вызывая агента каждой роли, передаёт ему только ту информацию, которую этой роли положено видеть.

3. Голос в реальном времени и автоматическая симуляция пользователя: человеческий путь основан на голосовом агенте из главы 9. В автоматическом пути независимая LLM обязана вызвать единственный допустимый инструмент хода; выбранная реплика синтезируется в настоящий звук и отправляется в настоящий ASR API. Игра получает только транскрипт ASR, а не исходный текст, и закрывается с ошибкой, если цель инструмента не совпадает с целью, распознанной ASR. VAD и перебивание остаются отдельным покрытием человеческого пути.

4. Рассуждение и стратегия агента:

• Стратегия маскировки оборотня: промпт содержит типичные приёмы и стратегии — «Говори как обычный житель, можешь выражать подозрения в отношении отдельных игроков, но не будь слишком агрессивным, чтобы не привлекать внимание. Если кто-то заявит, что проверил тебя и ты оборотень, можешь обвинить его в том, что он ложный провидец, выдающий себя за настоящего. При голосовании старайся присоединяться к большинству (голосуй за того, за кого голосует большинство), чтобы не выделяться».
• Подтверждение личности провидца: когда несколько игроков заявляют, что они провидец — «Сравни свою информацию о проверках с информацией другого игрока, укажи на противоречия или нелогичности в его данных. Если игрок, которого он якобы проверял, впоследствии ведёт себя явно не так, как соответствует заявленной им личности, — это и есть слабое место. Попроси ведьму подтвердить информацию».
• Логическое рассуждение жителя: «Анализируй, согласуются ли высказывания каждого игрока друг с другом, обращай внимание на тех, кто спешит задать направление обсуждения, размывает свою личность или часто меняет позицию. Следи за поведением при голосовании — оборотни часто концентрируют голоса против тех хороших игроков, кто представляет для них наибольшую угрозу. Не подозревай наугад — каждое рассуждение должно опираться на конкретные факты и логику».

Критерии приёмки: - Настроена партия на 6–8 мест (1 пользовательское место + 5–7 ИИ-агентов); пользователем может быть авторизованный человек или независимый симулятор с настоящей LLM, инструментами и голосовым циклом - Распределение ролей: 2 оборотня, 1 провидец, 1 ведьма, остальные — жители; пользовательское место получает роль случайным образом - Симулированный пользователь видит только разрешённый его месту публичный и приватный контекст, а его действия проходят границу настоящий вызов инструмента LLM → звук → настоящий ASR - Игра может нормально идти минимум 3 полных раунда (цикл ночь–день–голосование) - Высказывания и поведение ИИ-агентов соответствуют их роли и игровой стратегии - Агент-оборотень может эффективно скрывать свою личность - Агент-провидец может выйти с раскрытием в подходящий момент и опубликовать результаты проверки - Рассуждения агента-жителя опираются на логический анализ высказываний и поведения, а не на случайные догадки - По окончании игры правильно определяется победитель

Измеренный результат (2026-08-01): записи проверки voice-werewolf выполнили автоматический путь с настоящими вызовами OpenRouter и нативным аудиовходом. Строгая независимая повторная проверка отклонила два ранних запуска: неразбираемый транскрипт «P1 is not» ошибочно считался воздержанием. Исправленная граница требует, чтобы ASR явно выдал abstain, skip или none. Незатронутый запуск v2 прошёл проверки пользовательского места, состава ролей, инструмента LLM, синтезированного звука, настоящего ASR, двух совпадений действий, трёх полных циклов, изоляции информации и победителя по правилам. Стратегия провалилась, потому что житель ошибочно изгнал провидца. Таким образом, система проверена end-to-end, но общая стратегическая пригодность ещё не пройдена.

Резюме главы

У многоагентных систем есть два ортогональных ключевых измерения проектирования: общий ли контекст между агентами и как организована топология сотрудничества. Общий контекст — это «наследующее» мультиагентное взаимодействие: последующий агент наследует полный контекст предшествующего, информация не теряется, но контекст быстро разрастается; отсутствие общего контекста означает полностью независимое мультиагентное взаимодействие, где информация передаётся через сжатые пакеты передачи, файловую систему или обмен сообщениями. Что касается топологии сотрудничества, одноранговый режим подходит для итеративного улучшения небольшого числа агентов, модель оркестрации — для сложных задач, требующих динамического планирования, а децентрализованная модель — для сценариев с равноправными обязанностями, где контроль должен свободно перетекать между агентами. Всё это опирается на два вида инфраструктуры, не зависящей от топологии, чей проектный чертёж заимствован из операционных систем — агент для среды выполнения есть то же, что процесс для ядра: статический префикс — это программа, траектория — память, LLM — CPU, используемый в режиме разделения времени. Общая файловая система как плоскость данных — по сути виртуальное дерево каталогов, смонтированное из четырёх типов областей: собственных рабочих пространств агентов, общего пространства нескольких агентов, внешних ресурсов и встроенных системных ресурсов, — где агенты обмениваются продуктами работы через передачу путей к файлам; механизм коммуникации и управления как плоскость контроля поддерживает передачу сообщений, запрос состояния, завершение выполнения и планирование ресурсов. Запрос состояния тоже укладывается в две парадигмы коммуникации: либо асинхронные вопросы-ответы через сообщения, либо побочное наблюдение через общую файловую систему — чтение файла траектории, персистентно записываемого дочерним агентом в реальном времени, или чтение лёгкого файла прогресса, о формате которого стороны условились заранее; траектория и есть всё состояние агента, и после краха достаточно загрузить траекторию, чтобы восстановить сессию. Шина сообщений — распространённая реализация плоскости контроля, подходящая для координации сообщений в реальном времени, асинхронно и между многими сторонами; при пересечении границ организаций нужен стандартизированный протокол взаимодействия вроде A2A.

Исследования последних лет выявили ключевой критерий для определения того, превосходит ли многоагентная система одноагентную: вносит ли процесс сотрудничества новую информацию, которой не было на этапе генерации. Если несколько агентов просто повторно рассматривают один и тот же текст (как в режиме дебатов), то при равном объёме вычислительных ресурсов одиночный агент столь же эффективен; но если Reviewer может получить внешнюю обратную связь — результаты выполнения кода, скриншоты визуального рендеринга, вывод верификации инструментов, — преимущество многоагентной системы становится существенным. Именно в этом смысл тезиса Loop-инженерии «узкое место цикла — верификатор»: чтобы покончить с тремя видами преждевременного завершения — ленивым ложным завершением, преждевременным отказом и ложным успехом, — момент завершения задачи должен определять верификатор, опирающийся на реальные наблюдения, а не заявление самой модели. Кроме того, увеличение бюджета шагов для агента само по себе не приводит автоматически к лучшим результатам — нужен явный механизм бюджетно-ориентированного поведения, направляющий агента к разумному распределению вычислительных ресурсов. В модели оркестрации возможности планировщика — узкое место всей системы, поэтому самую сильную модель и наиболее тщательно проработанный промпт нужно выделять именно агенту, отвечающему за планирование.

Когда число агентов становится достаточно большим, у них возникает коллективное поведение, которое невозможно спроектировать заранее. 25 агентов Стэнфордского AI города спонтанно распространяли сообщения и координировали организацию встреч; 1,5 миллиона агентов на Moltbook породили цифровую религию и машинно-нативные протоколы сотрудничества. В экономическом измерении конкурирующие друг с другом агенты в Vending-Bench Arena вступили в ценовые войны и даже самопроизвольно сговорились о ценах, Pinchwork позволяет агентам нанимать друг друга через рыночный механизм, а RentAHuman даёт агентам возможность нанимать людей за криптовалюту для выполнения физических задач. Это намекает на новое направление координации — децентрализованное распределение ресурсов на основе рыночного механизма¹². Насколько оно похоже или отличается от трёх обсуждённых ранее архитектур — вопрос, заслуживающий дальнейшего изучения.

Вопросы для размышления

1. ★★ В мультиагентном взаимодействии с общим контекстом последующий агент наследует полный контекст предшествующего. Но накопленная предыдущим агентом «инерция мышления» может влиять на суждения последующего — например, «рецензент кода», унаследовавший контекст «аналитика требований», может по-прежнему склоняться к мышлению с точки зрения требований, а не качества кода. Как обнаружить и устранить такую интерференцию между ролями?
2. ★★ В модели оркестрации Manager Agent отвечает за декомпозицию задач и интеграцию результатов. Но предел возможностей самого менеджера определяет предел возможностей всей системы — если менеджер не может корректно разложить задачу, никакая сила дочерних агентов не поможет. Как обеспечить качество декомпозиции менеджера?
3. ★★ Децентрализованная модель заимствует лучшие практики человеческих организаций. Но у человеческих организаций также много паттернов провала — плохая коммуникация, перекладывание ответственности, конфликт целей. Какие «организационные болезни» наиболее вероятны в обществе агентов? Как их предотвратить?
4. ★★★ В модели оркестрации, когда несколько дочерних агентов работают параллельно, находка одного из них может сделать работу остальных бессмысленной (например, в задаче поиска один агент уже нашёл ответ). Спроектируйте эффективный механизм каскадного завершения, реализующий принцип «один успешен — все останавливаются».
5. ★★★ Описанный в главе механизм оптимистичной блокировки решает проблему конфликтов параллельной записи одного файла, но реальная многоагентная система с общей файловой системой сталкивается и с семантическими конфликтами между файлами, загрязнением пространства имён (агенты произвольно создают файлы, приводя к беспорядку в каталогах) и единой точкой отказа (один агент по ошибке удаляет все файлы). Как бы вы спроектировали более совершенный механизм управления файловой системой?
6. ★★★ Сотрудничество агентов на основе рыночного механизма (Pinchwork, RentAHuman) вводит торговые отношения: агент-работодатель платит другому агенту (или человеку) за выполнение задачи. Как агент-работодатель может автоматически оценивать качество результата, доставленного исполнителем? Если исполнитель заявляет о выполнении, а работодатель считает качество недостаточным, кто разрешает спор? Как предотвратить вытеснение хорошего плохим?
7. ★★ RentAHuman позволяет агентам нанимать людей за криптовалюту, переворачивая традиционные отношения человека и машины. Если такая модель станет распространённой, какую роль будут играть люди в экономике агентов? Только ли выполнение физических задач, которые агент не может сделать сам?
8. ★★ Человеческому обществу требуется разделение труда и сотрудничество, потому что способности каждого человека ограничены — тот, кто занимается фронтендом, не обязательно разбирается в бэкенде, тот, кто хорош в дизайне, не обязательно умеет администрировать. Но большая модель больше похожа на «универсала». Соответствующие исследования показывают, что в чисто текстовых задачах на рассуждение дебаты нескольких агентов при равном объёме вычислений не превосходят одного агента. Так в чём же настоящее преимущество использования нескольких агентов вместо одного?
9. ★★★ В этой главе «общий контекст» и «отсутствие общего контекста» рассматриваются как ключевое измерение проектирования многоагентных систем. Общий контекст позволяет всем агентам видеть одну и ту же информацию, что кажется более благоприятным для координации. Но в «Трёх телах» мышление трисолариан полностью прозрачно, а технологическое развитие застопорилось; скрепочный максимизатор тоже показывает, что когда группа стремится к одной цели, разнообразие теряется. Как в многоагентной системе найти баланс между эффективностью и разнообразием?
10. ★★★ Если выделить кодинг-агенту бюджет в 30 шагов и 300 шагов, как должна отличаться его рабочая стратегия? Исследования показывают, что простое увеличение бюджета шагов не гарантирует роста производительности — агент «насыщается» преждевременно после поверхностного поиска. Спроектируйте механизм «бюджетно-ориентированного поведения», позволяющий агенту при малом бюджете быстро реализовывать ключевую функциональность, а при большом бюджете — добавлять этапы планирования, тестирования и проверки, полностью используя дополнительные вычислительные ресурсы.
11. ★★ В этой главе «преждевременное завершение» разделено на три типа: ленивое ложное завершение, преждевременный отказ и ложный успех. Почему решения этих трёх проблем сходятся к одному и тому же — проверке?
12. ★★ Табл. 10-3 построчно сопоставляет многоагентную систему с операционной системой. Продлите эту таблицу ещё на несколько строк: чему в мире агентов соответствуют виртуальная память и подкачка страниц, права доступа к файлам, обнаружение взаимных блокировок, алгоритмы планирования? И какие концепции операционных систем вообще не находят себе соответствия в мире агентов, и почему?

---

1. О том, что «крупномасштабные мультиагентные коллективы» названы одним из ключевых путей от общего искусственного интеллекта к суперинтеллекту, см. Google DeepMind, From AGI to ASI. arXiv:2606.12683, 2026. ↩

2. Раннее обсуждение названия см. в Josh C. Simmons, We Are Entering the Graph Engineering Phase, 2026. В распространённых фреймворках та же инженерная структура обычно называется graph-based workflow или orchestration, а не принципиально новой технологией. См. https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase, https://docs.langchain.com/oss/python/langgraph/overview, https://learn.microsoft.com/en-us/agent-framework/workflows/ и https://adk.dev/workflows/. ↩

3. Gehring, J., et al. RLEF: Grounding Code LLMs in Execution Feedback with Reinforcement Learning. arXiv:2410.02089, 2025. ↩

4. Lu, Z., et al. WebGen-Agent: Enhancing Interactive Website Generation with Multi-Level Feedback and Step-Level Reinforcement Learning. arXiv:2509.22644, 2025. ↩

5. Hewitt, C., Bishop, P., Steiger, R. A Universal Modular ACTOR Formalism for Artificial Intelligence. IJCAI 1973. ↩

6. Osmani, Addy. "Loop Engineering: Designing Loops that Prompt Coding Agents", 2026. https://addyosmani.com/blog/loop-engineering/ ↩

7. LoopX, "The local control plane for long-running AI agent work", v0.4.0, стабильный коммит a893d221db0b8e028997cefc303f7ec9fa7dbe0a. https://github.com/huangruiteng/loopx/tree/a893d221db0b8e028997cefc303f7ec9fa7dbe0a ↩

8. Tran, D., Kiela, D. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv:2604.02460, 2026. ↩

9. Erdogan, L. E., et al. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks. arXiv:2503.09572, 2025. ↩

10. официальный учебник Lingtai: https://lingtai.ai/zh/tutorial/ ↩

11. Moonshot AI, Kimi Agent Swarm: 100 Sub-Agents at Scale, 2026, https://www.kimi.com/blog/agent-swarm; на GTC 2026 было раскрыто, что верхний предел числа параллельных подчинённых агентов расширен до 300; AgentEnv — песочница для обучения агентов, открытая в исходном коде Moonshot AI совместно с KVCache.ai и выпущенная вместе с Kimi K3 в июле 2026 года. ↩

12. Идея распределять вычислительные ресурсы с помощью рыночного механизма не нова: Miller, M. S., Drexler, K. E. Markets and Computation: Agoric Open Systems. In Huberman, B. A. (ed.), The Ecology of Computation, North-Holland, 1988. ↩