Хабр Курсы для менеджеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 14
Самое интересное здесь даже не «AI-холдинг», а момент, когда автор фактически заново изобретает нормальную инженерную организацию — только вместо людей у нас агенты 😄
Отдельные роли, ограниченные полномочия, контракты между этапами, ревью, бюджеты, эскалация, регресс после изменения роли — чем дальше читаешь, тем сильнее ощущение: поздравляю, мы снова пришли к разделению ответственности, CI/CD и менеджменту, просто теперь это всё ещё и токены ест.
Но мысль про то, что контекст и состояние должны жить вне промпта, мне очень близка. Кажется, именно на этом сейчас чаще всего ломаются красивые демки с «командой агентов»: пока всё хранится в огромной переписке, это не организация, а очень дорогой групповой чат.
Да, знакомые инженерные принципы здесь вполне сознательно 🙂 Мне интересно, как перенести их на агентов: отделить постоянную память от контекста запуска, задать границы полномочий и сделать роли отдельно проверяемыми. А следующий вопрос — можно ли делегировать системе формирование команд под новые направления и управление ими. Именно это я пробую на уровне MVP. «Очень дорогой групповой чат» — точное описание того, чего хочется избежать
Не столько изобретает, сколько приходит туда же, куда проектные институты пришли лет девяносто назад. Я в таком работаю и однажды не удержался: разложил шесть маленьких локальных моделей (1–2B) по схеме бюро Альберта Кана. Дисциплины, внутридисциплинарная проверка, междисциплинарная, нормоконтроль. И замерил, что из всей этой оргструктуры реально несёт нагрузку.
Оказалось, только деление на дисциплины. Самая слабая из работающих моделей от него выросла с 0,175 до 0,700, а весь «рой» поверх лучшей одиночной модели добавил +0,05. Делить работу доверил скрипту: LLM-планировщик в соседнем прогоне справлялся в 22% случаев.
Так что ревью и эскалация — да, но ревью должно быть тупой детерминированной проверкой. Модель-проверяльщик у меня отвергала заведомо правильный эталон в 76,8% случаев.
Отличная статья, как раз ai разделят ьан этапы разработки и выдавать роли, здравая идея, для создания целостного не багованного продукта, я также в разработке этим занимаюсь.
P.S. престарелые хейтеры программисты, обходите статью стороной, а то сейчас начнетсья, вайбкодинг, вайбокдинг
AI-холдинг
Суть холдинга в том, что одна структура владеет долями в других.
В статье у моделей долей нет. У них есть бюджет токенов, возможности MCP/tools и срок жизни агентного цикла.
Это не уставный капитал, а командировочные с лимитом на кофе. Единственный бенефициар в схеме человек, который выдает мандат и потом получает счет за токены.
Так мультиагентную систему на моей памяти еще никто не оскорблял. Не нужно натягивать сову на глобус.
Да, юридически это не холдинг. Я использую термин как организационную метафору: общий центр создаёт направления, распределяет между ними ресурсы и контролирует результат. Стоило обозначить это явно. Предмет статьи — такая архитектура управления агентами, а не воспроизведение отношений собственности.
Уже 9 месяцев пилю аналог AI fabric, по методологии SDLC. Даже название проекта рабочее такое же:) Стэк: golang, redis, pgsql. Взаимодействие между агентами через json контракты. Всем управляет оркестратор. Но пока кровь и слезы. Тестовые проекты доводит до финала 1 раз из 3х. Тоже самое у Сбера с их HG SDLC. На уровень выше, конвеер ai, управляющий условной организацией пока даже не сиотрю.
Спасибо, что поделились, особенно цифрой 1 из 3. У меня фиксированный flow для автотестов тоже появился именно из-за сложностей с выполнением задачи целиком и в первое время доходило всего 1 из 10, но шлифовка довела до 9 из 10. А уровень холдинга пока на стадии MVP и проработки, его пользу ещё предстоит проверить.
Интересно, что чаще мешает довести проект до конца: ошибки реализации или сбои координации — потеря контекста между этапами, нарушение контрактов, циклы доработок? Какие проекты вы используете для проверки?
Мне кажется, порог перехода от workflow к «холдингу» лучше считать не числом агентов, а числом независимых решений, которые верхний уровень действительно принимает и потом проверяет. Если он только переупаковывает статусы, это дорогой слой отчётности.
Я бы для MVP зафиксировал один портфельный цикл: два направления, общий бюджет, заранее заданное правило остановки, конфликт за ресурс и последующая проверка, улучшил ли управляющий слой accepted throughput или лишь добавил координацию. Какие решения текущий MVP уже принимает сам, а какие пока остаются у вас?
Согласен: число агентов само по себе ничего не доказывает. Цикл с двумя направлениями и конфликтом за общий бюджет — хорошая проверка пользы управляющего уровня.
Сейчас AI-организация уже самостоятельно распределяет выделенный ей бюджет между задачами. На уровне холдинга MVP пока занимается поиском перспективных решений. Запуск и остановка направлений, перераспределение бюджета между ними пока остаются за мной.
В ближайший месяц планирую подключить API поставщика инфраструктуры, чтобы агенты через подготовленные Ansible-плейбуки могли разворачивать сервер и настраивать проект по выбранному шаблону. Само по себе это, конечно, ещё не подтверждает пользу портфельного управления.
Пока выбираю: создавать AI-организацию сразу под новый проект, как в сценарии статьи, или сначала вести его силами холдинга и выделять организацию после проверки успешности. Например, дать эксперименту до трёх месяцев с заранее заданными критериями. Второй вариант предполагаю дешевле на старте, но это нужно измерить.
Поэтому предложенное сравнение при общем ограниченном бюджете мне подходит: смотреть на принятый результат, стоимость координации и число моих вмешательств. Полного автономного портфельного цикла пока нет.
Спасибо за статью. Многое в целевой архитектуре уже заложено. Предлагаю рассмотреть через ось — обратимы ли последствия ошибки.
Проверка. Вы перечисляете защиты: другая модель, инструментальная проверка, человек на критичных решениях. Обратимость и задаёт, что считать критичным. Мнение другой роли, даже на другой модели, — это второе мнение; его достаточно там, где ошибку можно откатить или она не значима для организации. Перед необратимым действием или дорогой ошибкой нужно основание вне агентов: инструментальная проверка или человек.
Необратимые действия. Capabilities у вас уже есть — для необратимых действий их можно дополнить предусловием, которое проверяет слой исполнения, а не роль. Например, ответ клиенты направляется, только если все данные в ответе принадлежат этому клиенту. Агент по-прежнему свободно интерпретирует задачу, но необратимый шаг проходит только при подтверждённом факте.
Цена автономности. Вы пишете, что дополнительный уровень управления оправдан, только если польза покрывает расходы. Сейчас в расходах только внутренняя цена: координация, время, управляемость. Нужна вторая ось — сколько можно потерять от ошибки и можно ли это вернуть.
Спасибо, ось обратимости действительно стоит добавить. Особенно полезно разделение между проверкой результата другой ролью и допуском к действию: второе мнение может повысить качество, но само по себе не должно расширять полномочия агента.
Предусловия на уровне исполнения хорошо дополняют capabilities. Например, право отправлять сообщения клиентам ещё не означает право отправить любые данные любому адресату. Принадлежность данных клиенту должна проверяться отдельно, причём при невозможности подтвердить условие отправка должна блокироваться.
В оценку цены автономности тоже согласен добавить возможный ущерб и стоимость восстановления. Я бы учитывал вместе обратимость, масштаб последствий и возможность обнаружить ошибку: даже обратимое действие может оказаться дорогим, если последствия заметили слишком поздно. Это делает критерии автономности существенно конкретнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От одного агента к AI-холдингу: масштабирование автономных AI-систем