Почему ИИ-агентам для управления проектами нужны общие правила. агентное ПО.. агентное ПО. Управление проектами.
Почему ИИ-агентам для управления проектами нужны общие правила - 1

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

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

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

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

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

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

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

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

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

У нас были:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • сигнал,

  • гипотеза,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • обучение,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не как к канону. Как к приглашению в спор.

 

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

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

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

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

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

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

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

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

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

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

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

Автор: YVKim

Источник