Process Forge — фреймворк для создания AI-процессов

На новогодних каникулах 2026 в одном из чатов Joomla-сообщества коллега по цеху поделился промптом для ИИ-агента и результатом этого промпта. За неделю до этого он впервые попробовал Gemini CLI. Я до этого ИИ пользовался только в веб версиях и в целом меня это устраивало. Увидев простыню текста, запрос в CLI и простыню ответа первое, что меня охватило: "Я НЕ ХОЧУ вот это всё изучать! Опять что-то новое, надоело...".

Потом были стадии проб и ошибок, попыток использовать готовые пакеты community skills с гитхаба с ролевым внушением "ты супер-пупер мега-бэкенд-Joomla разработчик с 40-летним опытом, сделай мне красиво". Где-то в середине этого полугодия я стал формализовать свои процессы (а это не только разработка, но и SEO, аналитика, бизнес-аналитика, проработка и выстраивание процессов и т.д., но в итоге это, как правило, или связано с или ведёт к сайту на Joomla). Формализация привела к моему пониманию некоторых базисов, которые общие для всех процессов. Об этом чуть ниже.

Теперь я хочу представить на суд уважаемой публике свои наработки по фреймворку для создания формализованных процессов работы для ИИ-агентов - Process Forge (GitHub).

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

Отправные точки

Для того, чтобы ответить на вопросы «зачем всё это?» и «почему так?» я дам несколько исходных точек, которые нащупал в основном опытным путём за эти полгода и от которых я отталкивался при создании Process Forge. Некоторые из этих выводов позже получали своё подтверждение в находках других людей, которых я наблюдал по статьям или постам в соц.сетях:

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

2. ИИ-агенту для нормальной работы нужно дать всё то, что дают человеку для работы: знания и инструменты, готовые шаблоны для переиспользования.

3. ИИ-агенту нужно дать определенную свободу, но в рамках заданного коридора, указанного вектора.

4. Нельзя быть привязанным к какой-либо экосистеме ИИ-провайдера, должна быть возможность «переключить мозги» (не должно быть агентки .codex, .claude и т.д., должно быть что-то нейтральное, хотя сами агенты стараются привязать вас к своей экосистеме).

5. Вся память проектов и процессы должны быть структурированы в файлах.

6. Вы сами прежде всего должны понимать ЧТО происходит, КАК и ЗАЧЕМ. Без этого хаоса в вашей жизни с ИИ будет только больше.

Когда мы работаем с ИИ-агентами и вообще с ИИ мы ожидаем, что нам сделают работу быстро и хорошо, ведь это Искусственный, етить его, Интеллект. Но это оказалось не так. Вместо лопаты тебе дали турбо-экскаватор, который говорит вам: "Я пашу поле, у меня отвалилось колесо, я быстро исправлю это временным фолбеком и поставлю с одной стороны гусеницу". И с этим ещё нужно научиться работать и знать где и как его правильно применять. Сразу оговорюсь, что почти всё написанное здесь - результаты собственной эвристики и поэтому сугубо субъективно. Лишь спустя несколько месяцев я познакомился с AI Factory (ссылка раз, ссылка два (Хабр)) и GSD Core, но было уже поздно, так как вовсю работал с собственным инструментом. Возможно, что существуют и другие подобные инструменты.

Концепции Process Forge

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

Процесс вместо чата

После 2-х месяцев работы в режиме чата и с готовыми пакетами community skills с гитхаба с ролевым внушением «ты супер-пупер мега-бэкенд-Joomla-разработчик с 40-летним опытом, сделай мне красиво» беглый поиск и обсуждение с ИИ собственных сомнений по поводу всего этого привели к тому, что нужно выстраивать процесс разработки (сначала только её).

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

Мой запрос был сразу на процесс, поэтому после нескольких дней обсуждений у меня выстроился artefact based development flow. Это набор папок и файлов, в котором описаны правила работы с проектами. Они описывали стадии рабочего процесса, которым я пользовался и который улучшал на протяжении 3-х месяцев, создавая библиотеки, плагины, компоненты для Joomla. Со стадиями в целом можно познакомиться под катом. В измененном виде он вошёл Process Forge как один из «коробочных» процессов.

Подключение знаний к ИИ-процессу

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

• исходный код актуальных версий,

• снапшоты (локальные копии) официальной документации,

• статьи о разработке ваши или чужие,

• ваши заметки с рецептами решения той или иной задачи

• ссылки на сайты

Я работаю с Joomla, поэтому в моём загашнике лежит:

• исходный код ядра Joomla нескольких веток,

• исходный код основных расширений для Joomla, с которыми я работаю регулярно (JoomShopping, RadicalMart и т.д.)

• копии официальных документаций под web fullstack:

  • manual.joomla.org

  • HTML / CSS / JS / PHP

  • документации некоторых фреймворков

• Мои статьи и некоторые статьи моих коллег по цеху

• Документации различных API, которые я дополняю уже дампами реальных ответов (если это REST)

И так далее. Да, я в курсе, что существует Context7 (сервис и MCP для машинной документации), но насколько помню, он стал лимитировать запросы в какой-то момент и, ожидаемо, ввёл тарифные планы с пакетами запросов.

В целом, разговор об этом разделе статьи находится в плоскости on-Premise и SaaS: либо делаем сами под себя, но ручками; либо это делает кто-то за вас, но за денежку. Я пока что сторонник вы уже поняли чего )) Но, естественным образом при таком подходе вы берёте (или ваш ИИ-агент) на себя обязательство следить за обновлениями знаний.

Подключение инструментов, MCP и шаблонов

Шаблоны

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

Но, это может быть не только код: фрагменты дизайна, фрагменты видео (футажи) и т.д. - с чем ваш агент работает.

Инструменты и MCP

Под инструментами я понимаю то, чем ИИ агент может пользоваться на вашем устройстве. Для разработчика это могут быть git, GitHub CLI, запуски пайплайнов, линтеры, фиксеры, упаковщики/сборщики, тестовые стенды локальные и удалённые. Для SEO \ GEO специалиста это могут быть утилитки для автоматического доступа к различным API сервисов (API Яндекса для вордстата и сбора данных с SERP), Screaming Frog CLI и т.д. и т.п. Предположу, что в условном видео-продакшне тоже есть свои подобные инструменты.

И самое главное, что инструмент должен быть настроен глобально на рабочей машине так, чтобы его могли использовать разные проекты одинаково: один экземпляр сборщика используется во всех 80 плагинах, которые вы пишете.

MCP в данном случае предстаёт таким же инструментом, просто доступным по Model Context Protocol. Это могут быть Playwright / Chrome Dev Tools / Firefox Dev Tools для работ с задачами, требующими браузера. Это может быть MCP IDE Php Storm (в моём случае), Serena для символьного анализа кода и т.д.

Я обратил внимание, что при работе с кодом через MCP IDE меньше возникает проблем с кодировками файлов и правами доступа к файловой системе. Также через MCP агент может получать больше информации из инспекций, запускать тесты. Но он так же может и запускать шелл-команды через консоль PHP Storm, хотя у него есть прямой доступ к консоли - ловите его вовремя, чтоб ерундой не занимался.

Снова процессы

В контексте работы с Joomla и расширениями для неё я стараюсь работать по полному инженерному процессу: обсуждается требуемый функционал, планируем реализацию, собственно пишем код, тесты e2e, финализация и сборка пакета, выпуск релиза по semver. Дальше подкатывают пост-релизные задачи: обновить или написать с нуля документацию на двух языках, скриншоты на двух языках, видео на одном языке, выложить анонсы о новых версиях с описанием на 15+ платформах...

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

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

Часто некоторые мысли, информация ходят вокруг нас долго, по нескольку раз попадаясь на глаза, прежде чем мы их заметим и осознаем. В данном случае стало складываться понимание, что меня в работе окружают процессы разной сложности. Логично стало подняться на уровень вверх над кодингом и выделить универсальную сущность процесса, где может быть разное количество стадий, артефактов между ними, взаимосвязи и т.д. Так стал появляться Process Forge.

Сейчас в нём есть внутренние процессы, процессы «из коробки» и есть возможность создавать собственные процессы. Процессы могут ветвиться, родительский процесс может ожидать результатов дочернего процесса и затем продолжать работу.

Платформы и специализации

Платформы

Сущность платформы позволяет объединить пакеты знаний Process Forge в подключаемые пакеты, описать в них среду исполнения, шаблоны, требуемые инструменты. Когда вы начинаете делать «новый плагин для Joomla 6+, который...» - агент понимает о какой платформе идёт речь и подключит в контекст проекта не только Joomla-знания, но и знания php, html, css, js, нужный пакет проверок, правила code style, упаковщик расширений Phing.

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

Специализации

Если наш агент пишет код для Joomla - ему нужны знания для написания кода. Но если он выкладывает статью или работает с модулями на сайте в админке - ему не нужны знания PHP, JS и архитектура Joomla-расширений. Ему нужны знания об админке, о REST API для более быстрой работы, может потребоваться базовый HTML и знание CSS-фреймворка сайта вашего проекта, правила обработки картинок, правила расположения медиа-контента на сайте (что и в какую папку класть) и т.д. Поэтому появились специализации, которые объединяют знания, нужные для конкретной специализации.

Смысл этой сущности в том, что бэкенд может работать с Joomla, а может с Laravel, а может с Django и Python. Платформы дают прикладные знания о языке, архитектуре и инструментах. Специализации дают общий абстрактный контекст: паттерны, подходы, принципы. Также специализации могут подключать и свои знания, инструменты, шаблоны, MCP и т.д.

Каскадное вычисление контекста проекта

В Process Forge контекст не хранится в одном большом промпте или скиле, а вычисляется каскадно из нескольких уровней по аналогии с мержем массивов/объектов: каждый следующий уровень наследует данные предыдущих и уточняет их для конкретной ситуации.

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

Если обобщить, логика вычисления контекста следующая:

• Рабочее пространство 

• Компания / организация 

• Направление (SEO, разработка, контент...)

• Платформа (Joomla, Wordpress, Symfony...)

• Специализация (бэк, фронт, фуллстак, контент., SEO...)

• Проект

• Процесс (Разработка ПО / SEO-аудит / ...)

• Задача и текущий этап

• Роль и профиль агента (в мультиагентном режиме)

Каждый следующий источник контекста накладывается поверх уже собранного. Результатом этой работы становится снапшот контекста проекта (YAML для машин, MD для людей), где указывается:

• platform_contracts / platform_stack — выбранные и доступные контракты платформ

• resolved_parameters — итоговые параметры после наследования и переопределений

• parameter_resolution — источники параметров, происхождение и конфликты

• resolved_context — результат специализаций, ресурсов, инструментов, mcp, шаблонов

• resolved — итоговые пакеты знаний / ресурсов / шаблонов / инструментов / процессов

• capabilities — required/optional возможности и их статус

• conflicts — конфликты специализаций и параметров

• snapshot.health.status — итоговое состояние: pass, warn или blocked

• freshness / context_policy — политика и состояние свежести

И некоторая другая информация.

Для конкретной задачи и в мультиагентном режиме собираются ещё более конкретные снапшоты-капсулы, которые передаются агенту вместе с его assignment / process / stage / task-слоями в виде машиночитаемых файлов.

Общий механизм обратной связи - Evolve

Evolve в Process Forge собирает полезные выводы, которые появились во время работы над задачей: что стоит запомнить, улучшить, проверить или перенести в общий опыт. Он не меняет правила и знания автоматически, а сначала оформляет такие находки как предложения с понятной областью применения: только для этого проекта, для рабочего пространства, для пакета, платформы или ядра. Затем эти предложения можно проверить, отобрать и уже осознанно включить в общие материалы или обновления.

Когда предложение превращается в обновлённый пакет знаний, шаблон, правило или другой общий материал, оно распространяется через обычный механизм обновлений Process Forge. Проект видит доступное обновление, может подготовить его, проверить, применить и после этого пересобрать свой контекст уже с новой версией общего знания.

Версионирование

Как для самой Process Forge, так и для её сущностей заложена возможность версионирования. Поскольку всё находится в виде файлов, отдельных пакетов - вы можете их постепенно улучшать и дополнять. Соответственно, вы можете иметь свой сервер обновлений для всех составных частей вашего рабочего места: ядра Process Forge, отдельно - процессов и платформ, отдельно - пакетов знаний и шаблонов. Например, сделали вы правки процесса после evolve с нескольких машин - выпускаете новую версию процесса. Сделали вы новые инструкции по работе с кодом? - Выпускаете code_instructions_v.1.1.0 и все ваши рабочие машины получают новый пакет знаний. После этого воркеры на местах уже обновят контексты проектов и смогут работать с новыми знаниями.

Организация работы в Process Forge

Удивительным образом всё это становится похожим на структуры, выстроенные в человеческих компаниях и организациях. Я предполагаю, что человек-оператор не должен знать слеш-команды, а должен лишь живой речью направлять агентов. Поэтому документации в Process Forge 2 - для людей и для агентов.

Для начала работы свою машину нужно настроить:

1. Установить дистрибутив ProcessForge (распаковать архив в свою агентку)

2. Запустить пошаговую настройку рабочего места с участием человека (есть авто-режим, но на свой страх и риск)

3. Настроить константы путей и корневые каталоги.

4. Указать корни путей для знаний, локальной документации.

5. Зарегистрировать инструменты и серверы MCP (MCP servers).

6. Создать или импортировать пакеты знаний.

7. Создать реестр переиспользуемых шаблонов.

8. Создать платформы из уже готовых ресурсов

9. Создать специализации

10. Подключить проект(ы) к рабочему месту.

11. Создать собственные процессы, если процессов из коробки недостаточно.

12. Начать работать

Да, это потребует времени на настройку машины. Но это масштабируемо и в целом себя показало неплохо.

В Process Forge предполагается 2 основных режима работы: режим гаража и режим кузницы.

Режим гаража (1-1-1-1)

Это режим, где

• один оператор-человек,

• одна основная агентская сессия (окно консоли),

• один проект

• один активный процесс/запуск (process/run).

Основной агент выполняет работу, запускает проверки, ведёт артефакты и завершает её или передаёт на следующий этап или процесс.

Мы открываем консоль / чат с агентом, говорим «погрузись в проект по .pf. Расскажи что сделано, на чём остановились?» и продолжаем работу в рамках одного проекта. Физически при этом у вас могут быть открыты 2-3 независимых проекта, каждый из которых работает в режиме гаража. И в этом гараже у вас есть помощник, который использует ваши инструменты, пользуется вашими знаниями и использует ваши платформы, работает по вашим шаблонам.

Режим Кузницы / Фабрики

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

Ваш основной агент становится оркестратором, который получает вводные данные, выбирает процесс, назначает (assignments) с помощью капсул контекста (capsules), затем запускает сессии агентов (полноценных или субагентов) и координирует их, следит чтобы агенты не мешали друг другу. Затем собирает их результаты и интегрирует итог через передачи результата (handoffs) и проверки (reviews).

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

Агент директор - это роль уровня рабочего места для организованной координации нескольких агентских сессий, процессов или проектов. Он нужен не в гаражном режиме, а там, где есть handoff’ы, ожидание подходящего исполнителя, ошибки, параллельная работа нескольких оркестраторов или необходимость явно передать ответственность. Проектные агенты и оркестраторы могут (относить заявления директору) отправлять сигналы в директорский inbox: например, что задача заблокирована, нужен другой исполнитель, возникла ошибка или требуется решение оператора. Из таких сообщений формируются cases, которые директор учитывает при очередном координационном проходе.

При этом в текущей реализации ProcessForge директор — не постоянно работающий самостоятельный LLM-агент. В модели PF он описан как агентская роль, но исполняется как CLI-слой координации: он проверяет очередь передач, доступность агентов, leases и состояние открытых дел, но сам не выполняет задачи и не запускает агентов. В будущем эту роль можно развить в полноценного AI-агента, который будет рассуждать о приоритетах и сложных маршрутах, но сейчас это детерминированный механизм управления координацией рабочего места.

Журнал вахтёра. Для того, чтобы агентам было комфортно работать на рабочем месте Process Forge заведён "журнал вахтёра", где отмечаются "пришедшие на работу" агенты. В нём видно кто заходил в процесс, что увидел, что сделал, где остановился и какие риски оставил следующему участнику.

Журнал помогает быстро восстановить ход работы без поиска по всем файлам и сообщениям. Это важно, потому что работа может переходить между агентами, задачами и запусками, а журнал удерживает непрерывность контекста. И это не отдельный агент, это CLI инструмент, поэтому токены тут мы не тратим.

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

Итого

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