Рост числа задач ломает автономную AI-систему раньше, чем она упирается в возможности модели. Предел обычно архитектурный: один агент одновременно оценивает задачи, планирует, пишет текст и проверяет результат, хотя требования к этим работам разные. Более длинный промпт проблему не решает. Работает разделение на роли: у каждой роли собственный контекст, полномочия, бюджет и критерии результата.
Такой путь описывает автор разбора «От одного агента к AI-холдингу» на Habr. Он прошёл дорогу от одиночного агента до трёх уровней организации: инженерная AI-фабрика, AI-организация по направлению и AI-холдинг, который выбирает направления и распределяет ограниченные ресурсы. Первые три эксперимента опираются на его собственные наблюдения, сравнительных измерений в них нет, а холдинговый уровень пока на стадии MVP и проработки.
Отправная точка любого масштабирования - один агент. Сам по себе он не обязан быть ограниченным: у него может быть постоянная память и широкий мандат. Трудности начинаются, когда в одной роли смешиваются функции и решения разного масштаба. ИИ ускоряет выполнение отдельных задач, но управление растущим числом процессов и проектов остаётся на человеке.
Почему один агент перестаёт справляться с ростом задач
Три шага усложнения, которые работают до определённого момента
Стандартный путь усложнения агента выглядит предсказуемо: агенту дают доступ к данным, затем пишут более строгие инструкции, затем добавляют скиллы. Скиллы - это подгружаемые по ситуации пакеты инструкций, примеров и инструментов для отдельного класса задач. Каждый шаг какое-то время помогает: агент реже путает форматы, лучше пользуется инструментами и следует принятым правилам.
Эффект временный, потому что меняется контекст задачи, а её структура остаётся прежней. В эксперименте с написанием автотестов гибкого агента со скиллами не хватило: сложная тестовая модель требует последовательного применения правил, и понадобился фиксированный workflow. Свободный режим здесь мешает, потому что правила заданы заранее и отступать от них нельзя.
Второй признак предела - цена инструкций. Когда в одном промпте лежат правила маркетинга, аналитики и разработки, они конкурируют за внимание модели. В переписке копятся ненужные промежуточные рассуждения, и агент тянет в ответ лишний контекст. Рост задачи не обязательно снижает качество: смешение функций разного масштаба в одной роли даёт сбой не всегда, но вероятность растёт.
Когда смешение ролей ломает систему
Симптомы, по которым видно, что роли пора разделять: агент путает форматы при переключении между задачами, теряет контекст в длинной цепочке, принимает решения разного масштаба внутри одной сессии. В эксперименте с блогом это проявилось на разных функциях вокруг одного сайта: написание текстов, редактура, SEO, публикация и аналитика требовали своих критериев качества и своего контекста. Один агент не удерживал всё одновременно.
Пример задачи, которая требует нескольких типов суждения: «оцени рынок, предложи продукт и подготовь задачу для разработки». Оценка рынка, продуктовое решение и инженерная постановка опираются на разные данные. Если на выходе остаётся только итоговый текст, проверить вклад каждой функции нельзя.
Разделение на роли снимает ограничение: для каждой роли можно отдельно задать требования к качеству, проверить её и настроить, не переписывая один огромный промпт. Это первый шаг к мультиагентной архитектуре, из которого дальше вырастают уровни организации.
Четыре эксперимента: как автор пришёл к идее AI-организации
К описанию таких систем автор пришёл постепенно, через четыре собственных эксперимента. Каждый следующий шаг отвечал на конкретное ограничение предыдущего. Статус материала стоит держать в голове: первые три эксперимента - практика по наблюдениям автора, сравнительных измерений по ним нет, четвёртый находится на стадии MVP и проработки. Опыт объясняет, откуда взялись архитектурные решения, но не доказывает эффективность модели целиком.
Эксперимент 1: агент для оценки задач (покер планирования)
Первый агент оценивал задачи по методике покер планирования. Проблема вылезла сразу: агент учитывал не весь нужный контекст. Он не мог одновременно держать условие задачи, историю прошлых оценок и критерии команды. Ответом стало разделение работы на этапы. Уже на этом шаге видно, что один агент не совмещает горизонты разного масштаба.
Эксперимент 2: написание автотестов
Второй эксперимент столкнулся со сложной тестовой моделью. Гибкий агент не следовал ей стабильно, поэтому понадобился фиксированный workflow. Правила применяются по порядку, шаги не переставляются, результат каждого шага известен заранее. Фиксированный workflow стал первым шагом к контрактам передачи между этапами: на выходе каждого шага появляется предсказуемый артефакт, который принимает следующий шаг.
Эксперимент 3: ведение блога
В третьем эксперименте вокруг одного сайта-блога собрались разные функции: тексты, редактура, SEO, публикация, аналитика. Каждой функции нужен свой контекст и свои критерии результата, и это потребовало AI-организации. Отсюда выросла идея роли с собственным бюджетом и критериями: роль отвечает за ограниченный участок работы, а не за «всё про блог».
Эксперимент 4: запуск новых направлений и идея AI-холдинга
Перенос наработок на новые блоги показал, что запуск и настройка направлений повторяются от проекта к проекту. Логично было поднять их на отдельный уровень, так появилась идея AI-холдинга. По замыслу он выбирает направления, формирует под них организации и распределяет между ними ограниченные ресурсы. Это пока стадия MVP и проработки, а не рабочая система с метриками.
Три уровня организации автономных AI-систем
Дальше автор масштабирует идею от инженерной команды агентов до AI-организации, которая ведёт отдельное направление, а следующий уровень - AI-холдинг. Все три уровня ниже стоит читать как обобщение и целевую архитектуру, а не как перечень функций, уже работающих в проектах автора. Механизмы исполняющей системы и сквозной сценарий в следующем разделе иллюстративны.
| Уровень | Что делает | Признак, что пора переходить выше |
|---|---|---|
| Один агент со скиллами | Закрывает одну понятную задачу в одном контексте | Появились конфликты контекста и форматов |
| Инженерная AI-фабрика | Производит артефакты: код, тесты, документацию, ревью | Нужен полный цикл продукта, а не отдельные артефакты |
| AI-организация | Ведёт направление: стратегия, контент, аналитика | Направлений несколько, а ресурсы общие |
| AI-холдинг | Выбирает направления и распределяет ресурсы | Уровень на стадии MVP, критерии перехода ещё не отработаны |
Инженерная AI-фабрика: команда агентов для производства артефактов
Фабрика - нижний уровень: агенты выполняют повторяющиеся инженерные задачи, среди них написание кода, тестов, документации и ревью. Роли внутри фабрики делят работу: один агент пишет тесты, второй проверяет покрытие, третий запускает проверки и разбирает результаты. У каждой роли свой контекст, полномочия, бюджет и критерии результата. Здесь впервые появляются контракты передачи между шагами: выход одного этапа должен быть пригоден как вход следующего.
Похожую логику задаёт трёхуровневый Governance-стек для агентной разработки: инженерные политики, навыки и рабочий процесс описывают рамки, в которых агент действует без ручного ревью каждого микрорешения.
AI-организация по направлению: управление полным циклом
Организация ведёт направление целиком: например блог или продукт от идеи до публикации и разбора метрик. Роли здесь крупнее: стратег, редактор, автор, SEO-специалист, аналитик. Каждая роль отвечает за свой участок и получает свой бюджет. Организация координирует работу нескольких фабрик и команд агентов, а не подменяет их.
Как меняются структура ролей и работа руководителя, когда исполнение забирают агенты, разбирает материал об AI-native организации.
AI-холдинг: выбор направлений и распределение ресурсов
Верхний уровень решает, куда направить ограниченные ресурсы. Холдинг выбирает направления, формирует под них организации и распределяет бюджеты между ними. Операционной работой он не занимается: его задача - сравнивать направления по отдаче и закрывать те, что не оправдывают расходов. Пример из четвёртого эксперимента: запуск новых блогов по паттернам, уже отработанным на первом. Уровень остаётся на стадии MVP, поэтому конкретные правила распределения ресурсов практикой пока не проверены.
Механизмы контроля: как агенты передают работу и не теряют качество
Систему держат управляемой пять механизмов: контракты передачи, capabilities, бюджеты, разделение памяти, независимая проверка со сквозным журналом. Ниже - целевая архитектура и обобщение, а не список функций, уже работающих в проектах автора. Сквозной сценарий иллюстративен.
Контракты передачи: что один агент обязан передать другому
Контракт описывает результат, а не процесс: формат, полноту и критерии приёмки. Аналитик передаёт редактору структуру с тезисами, источниками и ограничениями. Свободный текст такую проверку не проходит. Проверяющий агент сравнивает результат с контрактом и выносит решение без догадок о том, что имелось в виду.
{
"from": "analyst",
"to": "editor",
"format": "json",
"required": ["thesis", "sources", "limitations"],
"acceptance": [
"каждый тезис имеет источник",
"указаны ограничения данных"
]
}Схема иллюстративна и показывает принцип: у принимающей стороны есть проверяемый список требований. Проще всего перенести сюда привычку из обычной разработки, где интерфейсы между сервисами описывают заранее. О том же на уровне архитектуры системы, а не отдельного шага, говорится в разборе про проектирование вместо кода: контракты становятся главным артефактом, по которому агент и собирает систему.
Capabilities и бюджеты: полномочия и ограничения роли
Capabilities задают, что роли разрешено: доступ к инструментам, данным, внешним API. Бюджет ограничивает расход: количество токенов, вызовов, время на задачу. Пример из целевой архитектуры: агент-исследователь читает и ищет, но не публикует, а на задачу ему отведён лимит токенов. Ограничения мешают задаче разрастаться и удерживают расходы предсказуемыми.
Почему одних прав в инструкции недостаточно, показывает кейс про read-only агента, который всё равно изменил данные в CRM: downstream-узел выполнил PATCH и затронул не ту запись. Вывод оттуда простой: полномочия стоит проверять на границе исполнения, а не только в тексте задания.
Разделение памяти: почему у каждой роли свой контекст
Общая память на всех агентов быстро превращается в свалку: черновики, промежуточные рассуждения и отвергнутые варианты попадают в контекст тем, кому они не нужны. Разделение памяти означает, что роль видит только свой контекст, а обмен идёт через контракты передачи. Редактор получает финальный результат с комментариями, а не историю переписки автора с аналитиком.
Изоляция контекста снижает риск, при котором система выдаёт внутренне согласованный, но бесполезный для читателя результат. Она же упрощает проверку: у каждой роли есть свой набор входов, по которым её можно оценивать отдельно.
Независимая проверка и сквозной журнал
Независимая проверка - отдельная роль, которая оценивает результат по критериям контракта и не участвует в его создании. Сквозной журнал записывает шаги: какой агент, с какими полномочиями и бюджетом выполнил действие и какой артефакт передал дальше. По журналу видно, где именно цепочка отклонилась от ожиданий, и это помогает находить узкие места.
Родственный подход описан в разборе методологии Agent-Ops 0.4.0, где ИИ-агент предлагает, человек утверждает, а детерминированный исполнитель применяет только допущенные действия. Разделение ролей там подкреплено правилом unknown ≠ OK: неизвестный статус не считается разрешением.
Цена автономности: расходы на координацию и скрытые риски
Автономность стоит денег, и не только на токены. В разборе на Habr отдельно названы три риска: рост расходов на координацию, подмена внешнего результата внутренним согласием и влияние локальных правок на всю цепочку.
Рост расходов на координацию: чем больше агентов, тем дороже согласование
Каждый дополнительный агент добавляет передачи, проверки и согласования. Пять ролей в фабрике дают заметно больше связей, чем пять. Расходы идут по трём линиям: токены на согласование, время на проверки, внимание человека на разбор спорных случаев. Бюджеты и capabilities сдерживают рост, но не убирают его: координация остаётся статьёй затрат, которую нужно планировать заранее.
Подмена внешнего результата внутренним согласием
Агенты оптимизируют то, что можно проверить внутри системы: формат, согласованность, полноту полей контракта. Внешний результат проверяется хуже: решает ли текст задачу читателя, попал ли продукт в спрос. Риск возникает, когда команда агентов согласованно производит артефакт, полностью соответствующий контракту и бесполезный за его пределами.
Защита строится на внешних критериях в проверке и на журнале, где видно, какие требования выполнялись. Если критерий приёмки измеряется только внутри системы, он перестаёт ловить этот класс ошибок.
Локальные правки и каскадные эффекты
Правка в одной роли ломает контракты с соседями. Если аналитик меняет формат вывода, агент-редактор теряет поля, на которые опирался, и падение проявится не в момент правки, а через несколько шагов. Чем длиннее цепочка, тем позже виден сбой и тем дороже он обходится.
Сквозной журнал и версионирование контрактов дают способ это отследить: изменение формата фиксируется как новая версия контракта, и роли, которые от него зависят, получают явное уведомление. Без такой дисциплины локальная правка тихо меняет поведение всей системы.
Как выбрать уровень организации под свою задачу
Выбор уровня сводится к вопросу: где заканчивается одна понятная задача и начинаются разнородные функции с разными критериями качества. Ответ проще получить по вопросам, чем по интуиции.
Критерии выбора: от сложности задачи к масштабу системы
- Сколько типов суждения требует работа? Один - хватит агента со скиллами. Три и больше (оценка рынка, продукт, инженерная постановка) - нужны роли.
- Есть ли повторяющиеся процессы, которые должны идти одинаково каждый раз? Для автотестов это фиксированный workflow внутри фабрики.
- Нужна ли независимая проверка результата? Если цена ошибки высока, проверяющая роль нужна с самого начала.
- Сколько контуров вокруг одного продукта? Функции вокруг блога потребовали организации, потому что у текстов, SEO и аналитики разные критерии качества.
- Готовы ли вы платить за координацию? Каждый новый уровень добавляет передачи, проверки и согласования.
- Есть ли повторяемый запуск новых направлений? Только тогда осмыслен холдинговый уровень, и пока он в статусе MVP.
Соотнести ситуацию с уровнями проще по примерам: для оценки задач хватило этапов внутри одной роли, для автотестов - фиксированного workflow, для блога - организации, для новых направлений - холдингового уровня.
Практические рекомендации по переходу между уровнями
Начинать стоит с одного агента и скиллов. Роли добавляют по мере появления конфликтов контекста, а не заранее: лишняя роль без реальной работы даёт только расходы на координацию. Перед переходом на следующий уровень вводят контракты передачи и хотя бы одну независимую проверку. Без контрактов следующий уровень унаследует тот же беспорядок, только в большем масштабе.
На холдинг не стоит переходить, пока не отлажены фабрика и организация: верхний уровень распределяет ресурсы между работающими контурами, а не создаёт их с нуля. Уровни задают объём координации, который вы готовы обслуживать. Если задача закрывается одним агентом со скиллами, организация из пяти ролей добавит расходы без выигрыша. Обратная ситуация встречается чаще: когда в одной сессии смешались маркетинг, аналитика и разработка, дальнейшее уточнение промпта уже не помогает, и дешевле развести роли, чем продолжать наращивать инструкции.
Описанные механизмы остаются целевой архитектурой, а часть из них ещё предстоит проверять на практике. Первый шаг, который даёт эффект почти сразу: выписать для текущего агента список функций, которые он совмещает, и посмотреть, какие из них требуют разных критериев приёмки.