Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 1)
Ранас Мукминов
Оркестрация ИИ-агентов. Claude Opus 4.7
Об авторе
Книга написана практикующим инженером, который проектирует и эксплуатирует системы из многих
автономных агентов в реальной инфраструктуре. За этим опытом стоит простое наблюдение: как только
агентов становится больше одного, главным предметом инженерии перестаёт быть отдельный агент и
становится то, что между ними, — распределение работы, передача контекста, согласование изменений,
изоляция отказов и надзор. Эта книга — о том, что между агентами.
Материал обобщает практику не как набор приёмов, а как инженерную дисциплину, опирающуюся на
теорию распределённых систем и применимую к любой модели и любой агентной оболочке. Там, где разные
инструменты ведут себя по-разному, это оговаривается явно; где принцип общий, он формулируется
независимо от продукта.
Автономный агент — уже не генератор текста, а система, замыкающая контур: наблюдение, план,
действие, проверка, коррекция. Этому посвящена отдельная книга. Но у одного агента есть жёсткие
пределы: объём контекста, который он удерживает; глубина специализации, которую можно вложить в
один системный промпт; и принципиальная последовательность его работы — один агент делает шаги
один за другим. Когда задача перерастает эти пределы, возникает соблазн запустить много агентов.
Здесь и начинается оркестрация. И здесь же совершается главная ошибка: мультиагентную систему
строят так, будто это просто «агент, умноженный на N». Но как только исполнителей становится
несколько, система приобретает все свойства распределённой системы — и все её трудности.
Появляются вопросы, которых у одного агента не было вовсе: как разбить работу, чтобы её можно
было вести параллельно; как передать одному агенту то, что знает другой; что делать, когда двое
изменили один и тот же файл; кто отвечает за результат, собранный из частей; что происходит,
когда один из агентов завис или начал вести себя странно.
Эта книга исходит из тезиса: **оркестрация ИИ-агентов — это проектирование распределённой системы,
узлы которой недетерминированы, дороги и могут ошибаться правдоподобно**. К ней применимы законы
распределённых систем — согласованность, консенсус, отказоустойчивость, наблюдаемость, — но с
поправками на природу агентов. Игнорировать эти законы означает строить рой, который красиво
работает на демонстрации и разваливается на первом нетипичном случае.
Второй сквозной тезис книги: координация всегда стоит. Разбить задачу между десятью агентами
не значит ускорить её в десять раз. Нужно потратить работу на декомпозицию, на передачу контекста
между исполнителями, на согласование их результатов, на разрешение конфликтов и на сборку итога.
Эта работа — координационный налог, и он растёт с числом агентов. Оркестрация оправдана только
там, где выгода от разбиения превышает этот налог. Значительная часть книги посвящена тому, как
оценить обе стороны этого баланса и не платить налог там, где одного агента было бы достаточно.
Оркестрация в этой книге измеряется не числом агентов, а тем, как между ними распределены четыре
вещи: работа, контекст, состояние и ответственность. Система, где десять агентов независимо
решают одну задачу и кто-то выбирает лучший ответ, и система, где десять специализированных
агентов передают друг другу части одной большой задачи, — это две принципиально разные
архитектуры с разными отказами и разной стоимостью. Книга даёт язык, чтобы их различать и
проектировать осознанно.
Книга построена снизу вверх. Часть I вводит понятие оркестрации и критерий её оправданности.
Часть II — каталог архитектурных топологий. Части III–IV — роли агентов и их коммуникация.
Части V–VI — как разбить работу и как согласовать результаты. Часть VII — контекст, состояние и
память роя. Часть VIII — параллелизм и масштабирование. Часть IX — эмерджентность и качество
коллективного решения. Часть X — надёжность и отказоустойчивость. Часть XI — наблюдаемость и
отладка. Часть XII — безопасность роя как новой поверхности атаки. Часть XIII — место человека
над роем. Часть XIV — эксплуатация, экономика и обозримое будущее.
Сквозная модель уровней — топология, роли, коммуникация, декомпозиция, координация, состояние,
надёжность, наблюдаемость, безопасность, человек — проходит через все части. Если очередной приём
кажется отдельным трюком, почти всегда он оказывается следствием одного из этих уровней.
Книга продолжает «Автономных ИИ-программистов»: там предметом был отдельный агент как система,
здесь — система из агентов. Читать первую книгу необязательно, но полезно: понятия автономного
контура, контекста, инструментов, песочницы и верификации используются здесь как основа.
Глава 1. Почему один агент упирается в потолок
Прежде чем строить систему из многих агентов, нужно понять, что именно ломается в одном. Иначе мультиагентность превращается в попытку лечить симптом, не зная диагноза: рой, собранный без ясного понимания, какой предел он обходит, наследует исходную проблему в усиленном виде и добавляет к ней координационный налог. Эта глава разбирает три предела одиночного агента — контекст, специализацию и последовательность — как инженерные ограничения с измеримыми failure modes, а не как абстрактные неудобства. Каждый из них имеет свою точку насыщения, свой характерный отказ и свой способ обхода через распределение работы. И только когда обход через одного агента перестаёт работать, переход к системе становится обоснованным, а не модным.
Важно сразу зафиксировать рамку. Одиночный автономный агент — замкнутый контур наблюдения, плана, действия, проверки и коррекции — был предметом отдельной дисциплины и отдельной книги. Здесь он не пересматривается, а берётся как данность: предполагается, что агент уже умеет пользоваться инструментами, работать в песочнице, проверять собственный результат и восстанавливаться после ошибки шага. Вопрос этой главы уже: что мешает такому, в остальном исправному, агенту масштабироваться на задачу, превышающую его естественные границы. Ответ не в качестве модели. Самая способная модель поколения 2026 года — Opus 4.7, GPT-5.x, Gemini 3.x — упирается в те же три предела; разница лишь в том, где проходит точка насыщения. Пределы структурные, а не качественные, и потому их нельзя устранить выбором более сильной модели — только перераспределением работы.
Контекстное окно — единственный канал, через который агент видит задачу. В него помещается всё: системный промпт, история диалога, прочитанные файлы, результаты вызовов инструментов, промежуточные рассуждения. Это окно конечно. К 2026 году рабочие окна моделей измеряются сотнями тысяч токенов, а у части моделей — порядка миллиона и более. На фоне типичной задачи это кажется почти безграничным, и в этом ложном ощущении кроется первая ловушка. Окно — не склад, в который можно сложить всё и достать по требованию. Это рабочая память, которой агент пользуется на каждом шаге, и у неё есть свойства, которые при росте объёма работают против агента.
Первое свойство — стоимость. Стоимость одного шага агента растёт с объёмом контекста, который он несёт. Каждый новый вызов модели заново обрабатывает значительную часть накопленного окна. Если агент за длинную сессию набрал контекст в сотни тысяч токенов, то каждый последующий шаг оплачивает этот объём — даже когда для текущего действия релевантны лишь несколько строк. Кэширование префикса смягчает, но не отменяет это: кэш помогает, пока начало контекста стабильно, и обесценивается, как только в середину истории попадает новая информация и хвост приходится пересчитывать. Экономика одного агента на длинной задаче — это экономика монотонно дорожающих шагов.
Второе свойство — деградация качества с заполнением окна. Способность модели одинаково надёжно использовать информацию в любой позиции окна не гарантирована. Эмпирически наблюдается, что факты в начале и в конце контекста учитываются увереннее, чем погребённые в середине длинной истории; точные характеристики зависят от модели и здесь не приводятся, но сам эффект — порядковый, а не маргинальный, и его нужно закладывать в проект. Чем полнее окно, тем выше риск, что критичная деталь, прочитанная пятьсот шагов назад, фактически выпала из рабочего внимания агента, хотя формально всё ещё присутствует в истории. Это не отказ памяти в человеческом смысле — это неравномерность доступа к собственному контексту.
Полезно различать две способности, которые большое окно обеспечивает по-разному. Первая — извлечение: найти и процитировать конкретный факт, лежащий где-то в окне. На этой задаче длинный контекст работает относительно неплохо, и ровно она лежит в основе демонстраций про «миллион токенов». Вторая — рассуждение поверх всего объёма сразу: удерживать в активном внимании множество разнесённых по окну фактов и согласованно опираться на них при выборе действия. Эта вторая способность деградирует с заполнением окна гораздо раньше первой. Агент, способный по запросу процитировать решение из начала сессии, не означает агента, который сам, без напоминания, учтёт это решение на шаге, где оно релевантно. Демонстрация извлечения создаёт ложную уверенность в рассуждении, и разрыв между ними — одна из главных ловушек проектирования вокруг больших окон.