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

Лид: Бум AI-оркестраторов (Paperclip, CrewAI, LangGraph) выглядит как момент, когда индустрия наконец созрела до правильных абстракций. Я смотрю на это иначе. Мы наблюдаем расцвет фреймворков ровно в тот момент, когда сама идея прикладного фреймворка начинает терять смысл. Для сеньора с опытом написать своё стало дешевле, чем интегрировать чужое. Ниже - анатомия того, что происходит, и два тезиса о том, куда это движется.

Что такое агент на самом деле

Когда говорят «AI-агент», чаще всего имеют в виду две разные вещи, и их полезно разделять с самого начала.

Первое - интерактивные CLI-агенты для разработки. Claude Code, Codex CLI. Запустил в терминале, поработал, вышел. Коротко живут, оптимизированы под одну задачу за запуск, фокус на коде и инструментах разработчика.

Второе - автономные агенты-демоны. OpenClaw Питера Штайнбергера, один из самых быстрорастущих репозиториев последних месяцев. Работают 24/7, подключены к мессенджерам или очередям событий, имеют постоянную память между сессиями, heartbeat-планировщик. Это не про «помогать писать код», это про «жить на сервере и реагировать на мир».

Cursor стоит отдельно: это IDE со встроенным агентом. Форма другая, но под капотом там тот же цикл.

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

Event loop. Сердце любого агента - это цикл. Принять запрос, подумать, вызвать инструмент, получить результат, снова подумать, решить что делать дальше. Цикл крутится, пока LLM не скажет «я закончил» или пока не упрётся в лимит шагов. Claude Code делает ровно это. Codex делает ровно это. OpenClaw делает ровно это, только цикл у него не завершается выходом, а переходит в ожидание следующего события. Вся разница между агентами - в том, как они оптимизируют этот цикл: как обрабатывают ошибки инструментов, как решают когда остановиться, как балансируют скорость и стоимость.

Скиллы. Набор готовых паттернов, которые агент может достать из ящика. В Claude Code и OpenClaw это файлы SKILL.md, один и тот же формат, кстати. В других системах - шаблоны промптов, предопределённые цепочки действий, библиотеки команд. Скилл - это способ не переоткрывать то, как надо, например, создавать презентацию в PowerPoint или чинить Docker-образ. Концентрированный опыт предыдущих запусков, сжатый в инструкцию.

MCP и инструменты. То, чем агент может воздействовать на мир. Файловая система, терминал, браузер, API внешних сервисов - всё это приходит через инструменты. Model Context Protocol стандартизировал способ подключения инструментов к LLM: теперь один и тот же сервер может обслуживать Claude, GPT, Gemini. До MCP каждый агент имел свой зоопарк интеграций, после - рынок инструментов стал общим.

Планирование. Способность разбить задачу на шаги до того, как начать её выполнять. Простые агенты планируют на лету, по ходу цикла. Более продвинутые - сначала строят план, потом идут по нему, периодически пересматривая. Разница в качестве планирования между агентами - это сочетание двух вещей: модели, которая думает, и обвязки, которая заставляет её думать правильно. Claude Code даёт Opus больше простора для размышлений перед действием, чем более простые обвязки. Это не столько про то, что Opus умнее, сколько про то, что агент умеет этим воспользоваться.

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

Анатомия агента: пять компонентов

Когда понимаешь эту анатомию, становится ясно: под капотом Claude Code, Codex и OpenClaw прячется примерно одна и та же конструкция. LLM в цикле, инструменты через MCP, скиллы в файлах, память в файловой системе или базе. Они отличаются форм-фактором (CLI против демона), качеством реализации и моделью, на которой работают. Но идейно это один класс объектов.

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

Откуда взялись оркестраторы

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

Это реальные проблемы. Люди начали писать обвязки. Обвязки превратились в фреймворки. Фреймворки получили имена и звёзды на GitHub. Так появилась отдельная ниша - оркестраторы.

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

Первые - системы, которые оркестрируют чужих внешних агентов. Paperclip - самый заметный представитель. Он не создаёт агентов, а управляет ими: запускает Claude Code, OpenClaw, Codex, даёт им задачи, контролирует бюджеты, собирает аудит. Создатель проекта под ником @dotta сам описывает боль, которую Paperclip решает: он держал по двадцать-тридцать открытых окон Claude Code и к понедельнику уже не помнил, что каждое из них делало.

Вторые - фреймворки, в которых вы пишете агентов с нуля. CrewAI, LangGraph, AutoGen. Это библиотеки для разработчиков, а не control plane. Они дают примитивы (агент, задача, поток), из которых вы собираете свою систему.

Третьи - отдельная ветка - генераторы софта. ChatDev, MetaGPT. Они не оркестрируют живых агентов и не дают библиотек для сборки. Они имитируют работу софтверной компании через фиксированные SOP, чтобы сгенерировать код по ТЗ. Метафора «компании» там только на уровне ролей в промпте.

Если разложить по философии, получится четыре школы плюс генераторы.

Школа «Компания». Paperclip. Агенты как сотрудники с ролями, бюджетами, отчётностью. Оркестратор одновременно HR, финдир и диспетчер. Ключевые идеи: heartbeat scheduling (агент просыпается по расписанию), atomic task checkout (никто не берёт одну задачу дважды), бюджеты с автоматическим throttling, аудит каждого действия. Главная особенность - управляет внешними агентами, а не порождает своих. 57 тысяч звёзд за семь недель после запуска 4 марта 2026, это не дутый ажиотаж, это ответ на накопленную боль людей, у которых уже реально запущены несколько Claude Code одновременно.

Школа «Команда». CrewAI. Агенты получают роли, делегируют друг другу задачи, но без бюрократии. В open-source-ядре нет ни бюджетов, ни оргструктуры, ни встроенного аудита (всё это есть в платной CrewAI Enterprise, но ядро про другое). Это библиотека, не control plane. Барьер входа один из самых низких среди оркестраторов. Почти 48 тысяч звёзд заслужены: если нужен прототип мульти-агентной команды, CrewAI быстрее всего. Проект стартовал в январе 2024, за полгода набрал 150 корпоративных клиентов, включая Oracle, и в октябре того же года закрыл Series A на 18 миллионов.

Школа «Граф». LangGraph. Агенты как узлы в направленном графе состояний, рёбра как переходы. Максимум контроля над потоком, поддержка долгоживущих workflows с контрольными точками, human-in-the-loop в ключевых узлах. Скучное позиционирование, но самая очевидная продакшн-трекция: Uber использует LangGraph для масштабных миграций кода и генерации юнит-тестов, LinkedIn построил на нём SQL Bot и AI-рекрутера, Klarna - ассистента для 85 миллионов пользователей (сокращение времени разрешения запросов на 80%), Elastic - security-ассистента для threat detection. Когда команда приходит из энтерпрайза и ей нужна предсказуемость, выбирают чаще всего именно это.

Школа «Разговор». AutoGen, AgentScope. Агенты общаются друг с другом в формате многосторонних диалогов. Подходит для задач, где важен консенсус: дебаты, ревью, исследования. Но здесь важный сигнал. В октябре 2025 Microsoft объединил AutoGen и Semantic Kernel в единый Microsoft Agent Framework, релиз 1.0 GA вышел 3 апреля 2026. AutoGen получает только maintenance-обновления, новые фичи идут в объединённый фреймворк. Это маркер: школа была модной в 2023 и 2024, сейчас индустрия от чисто-диалоговой парадигмы уходит.

Отдельно, генераторы. ChatDev, MetaGPT. Академические проекты 2023 года, которые первыми сформулировали метафору «софтверной компании из агентов». Но сравнивать их с Paperclip напрямую некорректно: они не управляют работающими агентами, а выполняют фиксированный пайплайн для генерации кода. Исторически предшественники идеи. Функционально другой класс объектов.

Слои экосистемы: control plane, исполнители, библиотеки, генераторы

Стрелки здесь - это отношение «кто чем занимается», а не «кто от кого зависит». Paperclip управляет готовыми исполнителями. Библиотеки дают примитивы, из которых вы собираете собственного исполнителя. Генераторы живут в своём углу и делают свою задачу.

Эти слои не взаимоисключающие. Теоретически можно собрать стек, где Paperclip управляет агентом, которого вы написали на CrewAI, и который под капотом дёргает Claude Code как сабпроцесс. Вопрос только - нужно ли.

Короткое сравнение

Критерий Paperclip CrewAI LangGraph AutoGen / MS Agent
Тип Control plane Library Library Library
Метафора Компания Ролевая команда Граф состояний Разговор
Управляет внешними агентами Да Нет Нет Нет
UI из коробки Да Нет Нет Нет
Бюджеты Встроены Только в Enterprise Нет Нет
Heartbeat / scheduling Да Нет В LangGraph Platform Нет
Human-in-the-loop Да Ограниченно Нативно Да
MCP Через подключаемых агентов Через адаптер Нативно Нативно (1.0)
Продакшн-трекция Ранняя (с марта 2026) Высокая Очень высокая Консолидация под MS Agent

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

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

А теперь - почему это всё не туда

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

Объясню, почему. И сразу оговорю границу: не всё ПО устареет, у устаревания есть предсказуемая логика.

Любой оркестратор - это код, который описывает, как должны взаимодействовать части системы. Этот код пишется заранее, один раз, и потом годами обрастает фичами. Архитектор садится, проектирует org chart, выбирает паттерн (supervisor, graph, pipeline), кодирует его. Получается фреймворк. Фреймворк стабилен. Фреймворк предсказуем. Фреймворк - это всегда про то, что правила игры зафиксированы до начала игры.

И вот тут начинается интересное. Правила игры перестают быть фиксированными.

Где граница

Сначала честно: не всякий статический код растворится. Нужно развести два слоя.

Первый слой - инфраструктура. Postgres, Kubernetes, Redis, Kafka, Linux. Это не «фреймворк, который можно переписать». Это накопленный за десятилетия слой, который отвечает за корректность под нагрузкой, консистентность, отказоустойчивость, безопасность на уровне ядра. Переписывать это никто не будет, потому что стоимость ошибки несоизмеримо выше стоимости зависимости. Тут LLM-генерация не конкурирует, она генерирует работу поверх этой инфраструктуры, а не вместо неё.

Второй слой - прикладные фреймворки и сервисы с UI. То, что стоит ближе к пользователю, несёт в себе конкретные решения про UX и воркфлоу, живёт на подписке. Вот здесь всё меняется.

Раньше, чтобы нарисовать архитектурную диаграмму, нужен был Miro или Lucidchart. За это платили. Без этого инструмента компании не могли работать: в нём хранились все артефакты, все процессы были завязаны на конкретные шаблоны. Сейчас человек, который когда-то работал в Miro и знает, чего он хочет, открывает LLM и говорит: мне нужен контекст-мэппер с drag-and-drop, экспорт в PNG, поддержка mermaid-схем. Через час у него прототип. Через пару недель - рабочий инструмент, заточенный под конкретные задачи, без мусора из продакт-версии. Не замена Miro для команды из пятидесяти человек, а ровно то, что нужно ему одному. Подписка больше не нужна. Сингулярность началась.

Это происходит не где-то в будущем. Это происходит сейчас. План-диаграммы, command-модели, контекст-мэпперы, простые CRM, таск-трекеры, внутренние порталы, лёгкие базы под конкретную задачу - софт, за который раньше платили годами, теперь генерируется за один запрос. Не потому, что этот софт плохой. А потому, что стоимость генерации кастомной замены упала до нуля.

Что с этим делать архитектору

Агентные фреймворки - не Miro и не Postgres. Они где-то посередине. Написать свой CrewAI сложнее, чем кажется: там не только цикл по ролям, там ещё memory backend, tool routing, error recovery, telemetry. Написать свой Paperclip - вообще серьёзная инфраструктура с persistence, конкурентным доступом, биллингом, UI, аудитом. Это не генерируется одним запросом.

Но тезис тут не в том, что «за вечер напишу свою CrewAI». Тезис в другом.

Когда у тебя есть реальная задача и реальный контекст (свой рабочий флоу, свои интеграции, свой масштаб), чужой фреймворк приносит с собой чужие предположения. Его абстракции выстроены под гипотетического среднего пользователя, а не под тебя. Ты платишь за гибкость, которой не пользуешься. Ты борешься с ограничениями, которые не имеют отношения к твоей задаче. Ты читаешь чужой исходник, чтобы понять, почему твой сценарий ломается о чью-то design decision, принятую полгода назад на другом митинге.

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

Я сам прошёл этот путь. Когда появились первые фреймворки для мульти-агентных систем, я посмотрел на них, оценил, и решил не использовать. Написал свою инфраструктуру: проект называется Jarvis. Это не очередной оркестратор с ролями и графами. Первичная задача Jarvis - самоэволюция. Он разрабатывался пятью нейросетями в связке, у него есть ядро (kernel), которое отвечает за стабильность контура, и обвязка, которая это ядро постепенно улучшает. Помимо собственной эволюции Jarvis пишет инструменты и скиллы для агентов, которыми он управляет, адаптируя их под конкретные классы задач. А дальше следит за этими инструментами и скиллами в работе: валидирует, улучшает или удаляет то, что перестало быть полезным. Не потому, что чужие фреймворки плохие, а потому, что ни один из них не ставил перед собой такую задачу в ядре.

Тезис первый: оркестраторы - переходный этап

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

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

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

Это не метафора. Это инженерная задача. Нужна система, которая:

  • Пишет свой код под свои задачи, а не использует готовый.
  • Оценивает, работает ли то, что получилось, через валидаторы или консенсус нескольких моделей.
  • Улучшает себя на основе собственных логов и результатов.
  • Выбрасывает то, что перестало быть нужным, без миграций и deprecation-циклов.
  • Адаптируется к изменениям окружения (новые модели, новые инструменты, новые запросы) без переписывания человеком.

Это направление активно развивается: HyperAgent (Phan et al., 2024) демонстрирует мульти-агентную координацию с ролями Planner/Navigator/Code Editor/Executor для software engineering, EvoAgentX - open-source фреймворк для автоэволюции agentic workflows.

Jarvis - моя попытка в этом направлении. Ядро стабильно, всё остальное - код, инструменты, скиллы, правила работы с агентами - он пересматривает через консенсус нескольких моделей. Пишет себя, создаёт скиллы, создаёт агентов. То, что перестаёт работать, удаляется без deprecation-циклов. То, что работает, закрепляется.

Это не прод и не энтерпрайз-система, это личная инфраструктура. Но она показывает, что подход реализуем не только в академических демо вроде Darwin Gödel Machine (Sakana AI + UBC, май 2025, который через дарвинский отбор проб архитектур поднял SWE-bench с 20% до 50%), но и в повседневной работающей системе.

Практический совет: смотрите на Paperclip, CrewAI, LangGraph. Разбирайте их. Читайте, как они решают проблемы координации, памяти, governance. Это ценный материал. Но не тащите их целиком в свои системы, не надейтесь, что они решат ваши задачи в исходном виде. Смотрите на паттерны, не на код.

Архитектурные паттерны долгоживущие. Heartbeat scheduling, atomic checkout, budget throttling, persistent state across sessions - да, это паттерны, которые Paperclip сделал заметными, но сама идея каждого из них встречается везде, от классических job-очередей до распределённых систем. Реализации временны. Их имеет смысл иметь под рукой как референс, но не как зависимость.

Тезис второй: для сеньоров сингулярность уже случилась

Это второй и, может быть, более практический тезис.

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

Сейчас сеньор с опытом в enterprise, у которого за плечами пять-шесть-десять лет разработки, делает это иначе. Он не ищет готовое. Он открывает LLM, описывает, что ему нужно, получает каркас, правит, дополняет, интегрирует. К вечеру у него работающий инструмент, заточенный под его реальный контур, без чужих предположений и без подписки. Не «идеальный продукт», а «ровно то, что мне сейчас нужно, без лишнего».

Это не инженерная новость. Это изменение экономики. Сингулярность для сеньора случилась на уровне прикладных тулов: контекст-мэпперы, внутренние дашборды, простые CRM, таск-трекеры - софт, который раньше покупали годами, теперь пишется за день. На уровне инфраструктурных фреймворков (свой Paperclip, свой LangGraph) сингулярность ещё не случилась, но вектор тот же: то, на что раньше уходил месяц, теперь уходит неделя. Уравнение начало переворачиваться.

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

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

Что делать практически

Если вы собираете агентную систему для своих задач прямо сейчас:

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

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

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

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

Вместо заключения

Я начал эту статью с того, что бум оркестраторов выглядит как созревание индустрии. Закончу я её тем же утверждением, но прочитанным в обратную сторону. Созревание индустрии всегда выглядит как расцвет абстракций, которые на следующем витке становятся лишними. jQuery был вершиной прикладного JS-фреймворка ровно перед тем, как нижний слой (браузеры) стандартизировал API и поглотил функциональность библиотеки. Paperclip, CrewAI и LangGraph - очередной слой абстракции, который нижний слой (LLM) поглотит, когда модели научатся собирать координацию под конкретную задачу сами.

Если вы строите сейчас - стройте так, чтобы вас не жалко было выбросить через два года. Это честнее, чем делать вид, что вы выбираете абстракцию на десятилетие.

Литература и источники

Агенты и инструментарий

Оркестраторы

Продакшн-кейсы и индустриальные сигналы

Генераторы софта

Self-evolving systems (академический контекст)

  • Darwin Gödel Machine (Sakana AI + UBC, май 2025) - самомодифицирующийся агент-кодер, поднял SWE-bench с 20% до 50% - sakana.ai/dgm
  • HyperAgent (Phan et al., 2024) - мульти-агентная система для software engineering с ролями Planner/Navigator/Code Editor/Executor - arxiv.org/abs/2409.16299
  • EvoAgentX - open-source фреймворк для автоэволюции agentic workflows - github.com/EvoAgentX/EvoAgentX
  • Обзор "A Comprehensive Survey of Self-Evolving AI Agents" и кураторский репозиторий - github.com/EvoAgentX/Awesome-Self-Evolving-Agents