Я на Хабре недавно, но уже успел заметить две вещи:

  • Во-первых, здесь довольно быстро устают от хайпа вокруг искусственного интеллекта и минусуют статьи, в которых пишут про ИИ без негативного опыта его применения.

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

… а текст ниже заходит сразу на обе эти территории...

И всё же рискну.

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

Мы проложили в открытый доступ два PDF:

При этом концепция – документ для обсуждения проектным сообществом. И это, пожалуй, лучшая формулировка того, как к ней и стоит относиться. Не как к канону. Как к приглашению в спор.

С чего всё началось?

Всё началось не с теории и не с попытки придумать ещё один красивый термин.

С начала 2026 года мы довольно плотно обкатывали агентов в нескольких ролях проектной команды.

У нас были:

  • агент администрирования проекта,

  • агент мониторинга коммуникаций,

  • агент планирования проекта.

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

Сначала мы гоняли всё это в своих проектах: в консалтинге и внедрении ПО. Потом попробовали те же идеи в строительных проектах. Надо признать, что опыт оказался одновременно очень вдохновляющим и очень отрезвляющим.

Удивило нас примерно следующее.

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

  • непрерывно смотреть в несколько источников,

  • замечать слабые сигналы,

  • собирать статус,

  • напоминать,

  • подсвечивать расхождения,

  • пересчитывать сценарии.

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

Но разочарование было не меньше.

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

И вот в этот момент стало понятно, что проблема вообще не в том, какая LLM лучше и какие промпты писать.

Проблема в другом. Что делать, когда в проекте появляется новый участник, который не просто отвечает на вопросы, а начинает влиять на информационную картину, из которой люди потом принимают решения?

Где заканчивается инструмент и начинается агент?

Это, пожалуй, была главная развилка.

Пока ИИ просто выполняет поручение по запросу: написать текст, собрать таблицу, посчитать вариант плана, проверить формулировку - это полезный инструмент. Но по логике AgPM система считается агентом, когда ей делегируют управленческую функцию. Она сама решает, что показать человеку, как важное, и работает регулярно или непрерывно без нового запроса на каждый цикл.

Иными словами, агент не просто отвечает, а формирует вашу картину проекта. А это уже совсем другой уровень управленческого риска.

Зачем нам вообще понадобился ещё один манифест?

Потому что классическое управление проектами эту ситуацию описывает не до конца.

И PMBoK, и ISO 21502, и PRINCE2, и другие привычные рамки по-прежнему остаются полезными. В AgPM нет идеи всё это выбросить и начать жизнь с нуля. Наоборот, речь идёт не о замене классического проектного управления, а о том, чтобы добавить в него нового участника проектной системы - ИИ-агента.

То есть это не новая религия вместо старой, а попытка ответить на вопрос о том, какие правила нужны, чтобы рядом с формальной системой управления не выросла вторая, теневая и неуправляемая.

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

  • Кто отвечает за последствия рекомендации агента?

  • В какой момент сигнал становится фактом?

  • Можно ли считать вывод агента основанием для изменения плана?

  • Что делать, если два агента спорят друг с другом?

  • И как не принять зелёный дашборд за реальное здоровье проекта?

Что в этих документах кажется мне действительно полезным?

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

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

Во-вторых, очень полезной мне кажется сама логика жизненного цикла проектной информации.

  • Сигнал - это ещё не факт.

  • Факт - ещё не официальный статус.

  • Статус - ещё не изменение базового плана.

В концепции это разложено по шести стадиям:

  • сигнал,

  • гипотеза,

  • подтверждённый факт,

  • утверждённый статус,

  • запрос на изменение

  • и изменение базового плана.

Для практики это важнее любой красивой AI-терминологии.

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

  • агентное целеполагание,

  • объяснимость,

  • подотчётность,

  • возможность отмены,

  • безопасная деградация,

  • пропорциональность.

Особенно близки мне последние две.

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

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

В-четвёртых, четыре области практик:

  • целеполагание,

  • реализация,

  • обучение,

  • интеграция.

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

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

Что меня в этой истории до сих пор смущает?

Скажу прямо. Сырого здесь ещё много.

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

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

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

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

Где это всё может дать реальную пользу?

Лучше всего смысл подхода виден не в принципах, а в сценариях.

В концепции есть очень приземлённые примеры:

  • агент раньше замечает, что подрядчик скрывает отставание,

  • быстрее пересчитывает варианты после изменения объёма,

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

  • помогает новому РП быстрее войти в проект,

  • автоматически отслеживает критичные изменения у партнёра.

Есть и антисценарии: ложный сигнал, перегрузка рамкой, оптимизация не той функции.

Собственно, наши пилоты и подтолкнули нас примерно к тем же выводам.

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

С этим они не справляются. И, думаю, ещё долго не будут.

Зачем я пишу об этом именно сюда?

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

Поэтому мой призыв очень простой.

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

Особенно интересны возражения по четырём точкам:

  • где проходит граница между инструментом и агентом,

  • нужна ли для этого вообще отдельная дисциплина,

  • насколько реалистична модель зрелости

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

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

Где скачать документы?

Сайт проекта: https://agenticpm.pro/. И выше прямые ссылки.

На сайте доступны два документа: «Манифест» и «Концепция v1.0».

Комментарии (4)


  1. ivan_dot_ai
    29.04.2026 04:59

    Написано, вроде, разумно. Но зачем так сложно? Ведь есть же уже куча процессных фреймворков. По-моему агент (даже если он про управление) - это просто "экзоскилет" уже существующего члена команды проекта. Какие могут быть правила для экзоскилета?


    1. YVKim Автор
      29.04.2026 04:59

      Это, собственно, один из главных вопросов.

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

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

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

      Что агенту вообще разрешено трогать? Что он может менять автоматически, а что только через review? Кто отвечает за уязвимость, если агент написал код убедительно, но плохо? Достаточно ли того, что тесты зелёные? Можно ли ему доверять миграции, рефакторинг, изменения в критических для безопасности местах? Нужен ли лог его действий? Нужен ли rollback по умолчанию?

      То есть как только агент начинает не подсказывать, а действовать внутри процесса, правила почему-то становятся совершенно естественной темой. С управлением проектами, на мой взгляд, происходит ровно то же самое. Если агент просто помогает РП оформить протокол, собрать статус, напомнить о дедлайне и делает это всегда по одной и той же цепочке - это действительно экзоскелет. Но если он уже сам мониторит коммуникации, сам выделяет «важное», сам формирует сводную картину проекта, сам предлагает, что эскалировать, а что считать рабочим отклонением - это уже не просто усилитель. Это участник контура управления, пусть и без формальной ответственности.

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

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


      1. ivan_dot_ai
        29.04.2026 04:59

        Возможно вы правы. Со второго раза чтение концепции уже не так сложно дается. Но я все равно не смог осилить до конца. Впрочем я и pmbook тоже не с первого раза осилил )


        1. Ytoo
          29.04.2026 04:59

          Доброго времени. Мне ,концепцию читать было более интересно, чем манифест.

          Манифест скорее для первого прикосновения к теме. Концепция - чтобы понять о чем собственно речь.

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

          Но в целом, интересно. Захотелось прокомментировать несколько разделов и обсудить с авторами или просто заинтересованными людьми