ProcessForge 1.2.0 ускоряет работу с большими проектами и расширяет MCP-интерфейс
18 октября 2026 года вышла версия 1.2.0 открытого фреймворка ProcessForge, предназначенного для организации процессов с участием ИИ-агентов. Основное внимание в релизе уделили производительности, надёжности длительных сценариев и управлению несколькими исполнителями.
ProcessForge поддерживает два основных режима работы. В Garage один агент взаимодействует с одним проектом и запуском, а история и решения хранятся в каталоге .pf. В режимах Forge и Factory несколько агентов могут параллельно выполнять отдельные назначения с собственными контекстами и ограничениями. За координацию, контроль результатов и передачу задач отвечает общий PF app-server.
Оптимизация работы с историей проекта
В мультиагентных сценариях постепенно накапливаются журналы событий, история запусков и результаты работы shell workers. Ранее часть операций повторно читала и разбирала большие объёмы данных, даже если они не относились к текущей задаче. В версии 1.2.0 события проекта и исходные события хуков перенесли из NDJSON-журналов в две локальные базы SQLite с индексами. Это позволяет быстрее находить записи, проверять уникальность событий и обрабатывать новые данные без просмотра всей истории. Отдельная база данных-сервер для этого не требуется: логи shell workers, телеметрия и стенограммы сессий по-прежнему хранятся в файлах.
Ускорен и выбор текущей работы. Если Run и Assignment однозначно определены, ProcessForge теперь сразу обращается к нужному объекту, а не перебирает историю проекта. На синтетическом проекте с 400 Run и 800 Assignment число чтений сократилось с 1202 до 4, а время операции — примерно с 3,2 секунды до 5–6 миллисекунд.
Ещё одно изменение касается YAML-конфигураций. Если документ не менялся, ProcessForge может повторно использовать результат его разбора, сохранённый в памяти процесса. Перед этим система проверяет актуальное содержимое файла, поэтому после изменения YAML выполняется новый разбор. Проверки прав доступа и целостности контекста сохраняются.
Надёжность исполнителей и продолжение работы
В состав ProcessForge входит Process Execution Inspector — компонент, который отслеживает состояние процессов, heartbeat, завершение исполнителей и их результаты. После выполнения задания Inspector собирает артефакты через механизм collect. В новой версии временные ошибки отделяются от устойчивых отказов: первые можно повторить, а для вторых требуется отдельное восстановление. Уже собранные данные сохраняются в истории, а состояние задания и работоспособность PF app-server отображаются раздельно. Это снижает риск потери результатов из-за сбоя на этапе обработки.
Для длительных процессов сохранён механизм Continuation. Он позволяет возобновить конкретную Work в новой сессии, сохранив связь с Run, Assignment, закреплённым процессом и контекстом. При продолжении PF заново проверяет состояние работы, разрешения и актуальность контекста. Новая сессия не может самостоятельно заменить назначение, выбрать другую задачу или расширить Scope.
Новые инструменты MCP
В ProcessForge 1.2.0 существенно расширили MCP-сервер. Оркестратор теперь может управлять жизненным циклом исполнителей без ручного вызова CLI-команд. Инструмент pf.worker.prepare подготавливает входные данные, контекст и ограничения, pf.worker.start запускает агента через зарегистрированный Runtime Driver, pf.worker.status показывает состояние выполнения, а pf.worker.collect собирает результаты и проверяет отчёт, контрольные суммы и сведения о попытках. При подготовке и запуске можно указать модель и уровень мышления reasoning_effort.
Для работы между сессиями добавлены pf.continuation.status, pf.continuation.create и pf.continuation.resume. Инструменты pf.work.search и pf.work.resolve ищут ресурсы с учётом разрешений конкретной Work и ограничений текущего этапа процесса. Через pf.actions.list и pf.actions.describe агент может узнать доступные в установленной версии команды, их параметры и ограничения. Сведения о зарегистрированных драйверах предоставляют pf.runtime_driver.list и pf.runtime_driver.describe, не раскрывая внутренние команды запуска и переменные окружения.
Также появились pf.session.heartbeat для продления регистрации сессии в Agent Ledger, pf.chat.record для записи сообщений агента и pf.work.cancel для отмены назначения. Все инструменты, изменяющие состояние системы, сохраняют проверки полномочий и требуют явного параметра apply: true. При этом исполнители могут работать с заранее подготовленной капсулой контекста и не подключать собственный PF MCP.
Контроль инструкций и временных файлов
Корневой файл AGENTS.md стал основной точкой входа агента в проект. В нём описываются правила получения контекста, выбора или продолжения Work, соблюдения Scope и прохождения этапов процесса. Чтобы накопление инструкций не привело к выпадению обязательных правил из контекста модели, в релизе появился механизм Instruction Accounting.
Обязательный контракт ProcessForge ограничен 4096 байтами. Система также умеет проверять объём всего AGENTS.md и цепочки подключаемых инструкций с учётом ограничений конкретного ИИ-клиента. При риске обрезания обязательных правил изменение можно заблокировать либо получить предупреждение. PF не сокращает пользовательские инструкции автоматически, а профили диагностики помогают оценить, какие файлы должны загружаться и укладываются ли они в известные ограничения клиента.
Временные файлы проекта рекомендуется размещать в .pf/tmp/, используя отдельные каталоги для исполнителей. Для PF app-server добавили настраиваемые уведомления о давно не изменявшихся временных файлах. Автоматического удаления нет, поскольку такие данные могут оставаться нужными работающим агентам.
Обновление до версии 1.2.0 требует сохранить состояние проектов и отдельно мигрировать старые журналы событий с помощью предложенного инструмента. В целом релиз направлен на то, чтобы ProcessForge оставался независимым от конкретной модели или SaaS-платформы, сохраняя производительность, контроль доступа и управляемость по мере роста числа задач и накопленной истории.
