18 октября 2026 года вышла новая версия ProcessForge 1.2.0 - открытого фреймворка для организации и выполнения процессов с участием ИИ-агентов (писал ранее о нём на е здесь). Этот релиз прежде всего посвящён оптимизации внутренних механизмов PF, повышению надёжности длительных процессов и устранению проблем, выявленных при практической работе с несколькими ИИ-агентами.

Оптимизация работы с большими объёмами данных

В мультиагентном режиме Forge / Factory ProcessForge даёт возможность запускать отдельные самостоятельные сессии ИИ-агентов (workers). Каждый исполнитель получает своё назначение (Assignment), капсулу контекста (Capsule) с необходимыми знаниями и инструкциями, а также ограниченную область ответственности (Scope). Это даёт возможность нескольким агентам функционировать параллельно над разными частями проекта, не мешая друг другу.

В процессе длительной работы с исполнителями, запускаемыми через командную оболочку (shell workers), стартовали накапливаться большие объёмы журналов, событий и истории выполнения задач. Обнаружилась задача: некоторые операции PF повторно читали и разбирали информация, которые не имели прямого отношения к текущей работе. По мере увеличения истории это создавало ненужную нагрузку.

В версии 1.2.0 переработаны сразу несколько механизмов.

1. Переход журналов событий на SQLite

Ранее для хранения событий проекта и хуков использовались журналы NDJSON. При большом объёме истории отдельные операции требовали повторного чтения записей. Теперь события проекта и исходные события хуков (raw hooks) хранятся в двух локальных базах SQLite с индексами. Это позволяет быстро находить необходимые записи, проверять уникальность событий и обрабатывать новые данные без постоянного просмотра всей накопленной истории.

Одновременно PF не требует отдельного сервера базы данных. Журналы вывода shell workers, телеметрия и стенограммы сессий остаются самостоятельными файлами.

2. Ускорение выбора текущей работы (Work)

В PF работа определяется конкретными Run (запуском процесса), Assignment (назначением) и связанным контекстом. Раньше даже при точном указании нужного задания система в некоторых случаях просматривала всю историю Run и Assignment проекта. Теперь, если идентификаторы однозначно подтверждены, PF сразу обращается к выбранной работе, не перебирая остальные задания.

На синтетическом проекте с 400 Run и 800 Assignment количество чтений для такого выбора сократилось с 1202 до 4, а время операции — примерно с 3,2 секунды до 5–6 миллисекунд.

3. Повторное использование разбора YAML

ProcessForge использует YAML для описания процессов, заданий, настроек и других структурированных данных. Теперь повторное чтение неизменившихся документов может применять ранее выполненный разбор, сохранённый в памяти процесса. Одновременно PF проверяет актуальное содержимое файлов. Если документ изменился, система разбирает его заново. Проверки прав доступа и целостности контекста не отключаются.

Улучшено восстановление после сбоев исполнителей

В мультиагентном режиме за выполнением задач внешними исполнителями следит Process Execution Inspector. Он отслеживает состояние запущенных процессов, их сигналы активности (heartbeat), завершение и результаты. После выполнения задания Inspector собирает предусмотренные артефакты через алгоритм collect. При длительной работе возможны ситуации, когда исполнитель завершился, но сбор результатов не удался.

Ранее устойчивые ошибки автоматического сбора могли приводить к повторению заведомо неуспешной операции. Теперь PF различает временные ошибки, при которых повтор имеет смысл, и устойчивые отказы, требующие отдельного восстановления. Уже собранные результаты сохраняются в истории. Состояние выполнения задания и работоспособность PF app-server отображаются отдельно. Это помогает не потерять результаты длительной работы агента из-за проблемы на этапе их обработки.

Безопасное продолжение работы в новой сессии

Ещё одна особенность длительных ИИ-процессов — необходимость продолжить работу после завершения сессии агента. В ProcessForge предусмотрен механизм Continuation. Он позволяет возобновить конкретную Work, сохранив привязку к Run, Assignment, капсуле контекста и выбранному процессу. При продолжении система повторно проверяет состояние работы, её разрешения и актуальность контекста. Новая сессия не получает права самостоятельно заменить назначение, расширить Scope или выбрать другую задачу только потому, что прежний контекст разговора ей недоступен.

Плагин возможностей MCP-сервера ProcessForge

В версии 1.2.0 существенно расширен набор инструментов, доступных ИИ-агентам через MCP. Раньше MCP-сервер PF позволял преимущественно получать контекст проекта, искать знания, разрабатывать Work и управлять этапами процесса. Для многих операций, особенно связанных с запуском других ИИ-агентов, раньше приходилось обращаться к консольным командам PF.

Управление исполнителями (Workers)

В мультиагентном режиме Forge / Factory оркестратор распределяет работу между отдельными самостоятельными сессиями ИИ-агентов. Каждый исполнитель получает ограниченное назначение (Assignment), подготовленный входной контекст и собственную область ответственности (Scope).

Для управления исполнителями через MCP добавлены четыре инструмента:

• pf.worker.prepare — подготовить входные данные, контекст и ограничения для исполнителя.

• pf.worker.start — запустить исполнителя через выбранный зарегистрированный драйвер (Runtime Driver). Запуск асинхронный: оркестратор сразу получает управление обратно.

• pf.worker.status — проверить состояние выполнения, включая возможность согласования состояния и сбора завершённых результатов.

• pf.worker.collect — собрать результаты работы исполнителя, проверить отчёт, контрольные суммы и сведения о попытках выполнения.

При подготовке и запуске можно дополнительно указать модель (model) и уровень мышления (reasoning_effort).

Итак, оркестратор может управлять жизненным циклом исполнителей через MCP, не вызывая вручную команды в CLI.

При этом сохраняются ограничения PF: исполнитель запускается только через зарегистрированный драйвер агента, с конкретным Assignment и закреплённым контекстом. 

Продолжение работы между сессиями

Добавлены инструменты pf.continuation.status, pf.continuation.create и pf.continuation.resume. Они позволяют находить ранее начатую работу, создавать точку продолжения и возобновлять её в другой сессии ИИ-агента. При этом сохраняются конкретные Run, Assignment, закреплённый процедура и неизменяемый контекст. Новая сессия не получает права произвольно выбирать другое задание или расширять зону ответственности.

Поиск знаний в пределах Work

Новые pf.work.search и pf.work.resolve позволяют искать и получать ресурсы, разрешённые конкретному назначению. В отличие от общего pf.search, который работает с ресурсами проектного контекста, эти инструменты дополнительно учитывают закреплённые за Work разрешения и ограничения текущего этапа процесса.

Обнаружение доступных команд

Добавлены pf.actions.list и pf.actions.describe. Благодаря им  агент может самостоятельно узнать, какие команды CLI и инструменты MCP поддерживаются установленной версией ProcessForge, какие параметры они принимают и какие из них обязательны.

• pf.actions.list рассказывает о том, какие действия существуют в установленной версии PF, как называются и для чего предназначены. Можно фильтровать каталог.

• pf.actions.describe описывает точные параметры выбранного действия: обязательные поля, типы, допустимые значения, ограничения и заявленные побочные эффекты.

Для работы с драйверами добавлены pf.runtime_driver.list и pf.runtime_driver.describe. Они позволяют узнать, какие драйверы в PF зарегистрированы и доступны, не раскрывая их внутренние команды запуска и переменные окружения. Инструменты помогают ИИ агенту-оркестратору выбрать механизм исполнения Work. Драйвер задаёт, как PF передаёт подготовленную работу исполнителю, даёт возможность не угадывать способ запуска, пути, команды и аргументы. При отсутствии данных агент нередко лез изучать исходник исполняемого файла, чтобы найти эти подробности. Теперь работа стала удобнее.

Управление сессией и запись сообщений

Добавлены pf.session.heartbeat для продления регистрации существующей сессии в Agent Ledger ("журнал вахтёра" рабочего места PF) и pf.chat.record для записи сообщения агента в блог собственной сессии. Равным образом появился pf.work.cancel для возможности отмены назначения агенту. Все изменяющие состояние инструменты сохраняют проверки полномочий. Для соответствующих операций требуется явное apply: true.

Зачем всё это сделано?

Цель - предоставить ИИ-агентам единый программный оболочку для работы с ProcessForge. Теперь оркестратор может через MCP получать контекст, управлять Work, запускать исполнителей, следить за их состоянием, собирать результаты и продолжать работу между сессиями.

При этом сами исполнители не обязаны подключать MCP-сервер PF: они могут работать автономно с заранее вычисленным и подготовленным контекстом и передавать результаты через предусмотренный контракт. Это уменьшает зависимость от консольных команд и конкретной среды исполнения, сохраняя контроль PF над процессами, полномочиями и результатами.

Упорядочены инструкции входа ИИ-агентов в проект

Основной точкой входа в инициатива стал корневой AGENTS.md. Он содержит обязательный контракт работы агента с ProcessForge: как получить контекст, выбрать или продолжить Work, соблюдать область ответственности (Scope) и проходить этапы процесса. При длительной работе возникает задача: ИИ-агенты склонны дописывать в AGENTS.md новые правила, выводы и инструкции. Постепенно файл разрастается, а разные ИИ-клиенты имеют собственные ограничения на объём загружаемых инструкций. В результате часть правил может оказаться за пределами доступного объёма и не попасть в контекст модели.

В PF 1.2.0 добавлен алгоритм контроля объёма стартовых инструкций (Instruction Accounting).

Обязательный контракт PF ограничен 4096 байтами. Дополнительно система умеет проверять объём всего файла и цепочки подключаемых инструкций с учётом явно заданных ограничений конкретного ИИ-клиента. Если обнаружен риск обрезания обязательных инструкций, PF блокирует соответствующее изменение. Если настроен режим предупреждения — говорит о превышении.

При этом PF не сокращает и не переписывает пользовательские инструкции автоматически.

Для разных ИИ-клиентов предусмотрены отдельные профили диагностики. Они позволяют оценивать, какие файлы должны загружаться и укладываются ли они в известные ограничения. Фактическая доставка инструкций модели требует отдельной проверки. Проблема механизма — не допустить ситуации, когда в связи с накопления инструкций агент перестаёт получать обязательные правила работы с проектом. Это проверки при подготовке, изменении и диагностике точки входа, а не непрерывное фоновое наблюдение за файлом. Лимит в 4096 байт относится к управляемому контракту PF, а не ко всему AGENTS.md.

При этом подготовленные исполнители могут начинать работу с уже переданными инструкциями и капсулой, не подключая собственный PF MCP и не создавая повторно Work. Это позволяет уменьшить объём лишнего контекста и сохранить разграничение ответственности между оркестратором и исполнителями.

Управление временными файлами

Временные файлы проекта теперь следует размещать в .pf/tmp/, выделяя отдельные каталоги исполнителям. Для необязательного PF app-server добавлены настраиваемые уведомления о давно не изменявшихся временных файлах. PF не удаляет их автоматически: такие файлы могут всё ещё использоваться исполнителями.

Итого

От ИИ не уже не уйти. Модели умнеют и стремятся вобрать в себя самое лучшее, а заодно подсадить вас на свою экосистему (что в общем и целом ожидаемо).

ProcessForge будет развиваться как независимый от конкретной ИИ-модели и SaaS каркас. Вы можете переключить "электронные мозги" одни на другие и продолжить функционировать.

В простом режиме Garage (режим 1-1-1-1 - один человек - один инициатива - один агент - один запуск) один агент может работать с проектом без запуска PF app-server. Вся история проекта, история принятых решений хранится в проектной папке .pf.

В режиме Forge / Factory можно организовать параллельную работу нескольких исполнителей с отдельными контекстами, назначениями, контролем доступа к ресурсам, проверкой результатов и передачей работы между сессиями. Вся "бухгалтерия проекта" продолжает храниться в проектной папке .pf, но для корректной организации рабочего процесса нужен совокупный процесс - pf-app-server. Для режима гаража он опционален. 

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

Процесс обновления: при переходе с предыдущей версии необходимо сохранить состояние проектов и выполнить отдельную миграцию старых журналов событий (скажите агенту использовать предложенный инструмент миграции). 

Буда так же рад критике и советам.