Перейти к содержанию

Релиз 0.12.4

Дата выхода: 28 октября 2026.

Релиз 0.12.4 — про расширяемость и работу с данными. Появились пакеты расширений и плагины, память агентов, движок пайплайнов в статусе preview, фоновая работа и рабочие копии репозитория. Добавлены мультимодальный ввод, внешние доступы и слой полномочий, раздельное развёртывание с исполнителем и хранение состояния в SQL.

Что входит в релиз

В заметки включены все изменения после версии 0.11.3 — линия 0.12.0–0.12.4 выходит одним релизом. Полный список коммитов и исправлений — в релизах репозитория (зеркало GitVerse: gitverse.ru/itphx/synth/releases).

Расширяемость: пакеты и плагины

  • Пакет расширения. Один пакет ставит в инстанс сразу всё, что нужно сценарию: агентов-роли, скиллы, MCP-серверы и пайплайны. Установка идёт одной операцией, по шагам — скиллы, MCP, агенты, пайплайны, правила маршрутизации.
  • Подтверждение администратором. Новый пакет получает статус «ждёт подтверждения»: до нажатия «Подтвердить установку» в инстансе ничего не меняется, а в диалоге перечислено, что именно будет добавлено.
  • Снятие пакета. Кнопка «Удалить» убирает пакет вместе с поставленными артефактами — агентами, скиллами, MCP-серверами, пайплайнами и порождёнными правилами маршрутизации.
  • Плагины. Код расширения встраивается в три готовых места: блоки системного промпта, фильтры вызовов к LLM и инструменты агента. Инструмент плагина проходит через тот же слой прав, что и встроенный.
  • Модель доверия и сканер. У плагина есть уровень доверия (встроенный, проверенный, доверенный, сообщества), вердикт статического сканера и карантин до подтверждения администратором. Действия плагинов пишутся в журнал.
  • Разделы настроек. «Аддоны» показывают установленные пакеты и пайплайны инстанса, «Плагины» — установленные плагины, журнал и политику слоя.

Подробнее — Плагины. Исполнение кода плагинов по умолчанию выключено: включение требует настройки инстанса и перезапуска.

Память агентов

  • Портал памяти в ядре. Факты с источником, индексы, статус готовности и граф связей доступны в интерфейсе и по HTTP API; CLI synth memory даёт status, list, index, rebuild и drop.
  • Вкладка «Память». Правая панель показывает, что попало в контекст последнего хода (блоки фактов и recall), сколько активных фактов и индексов видит сессия, и позволяет выключить память для проекта — данные при этом сохраняются.
  • Индексы с областью. Индекс области «Проект» виден только своему проекту, индекс области «Инстанс» — всем сессиям инстанса. Общий индекс не отключается: это ресурс инстанса.
  • Консолидация и граф. Дубли фактов сливаются, у факта остаются версия, уверенность и источник — видно, откуда утверждение пришло и чем заменено.
  • Автоматизация. Три системных шаблона (извлечение фактов из сессии, слияние дублей, переиндексация проекта) готовятся в пайплайн проекта и запускаются вручную или по расписанию.
  • Локальные эмбеддинги. Рекомендуемый режим — Ollama на своём хосте: корпус не уходит внешнему провайдеру.

При индексации нет обфускации

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

Подробнее — Память агентов.

Пайплайны (preview)

  • Второй движок. Пайплайн — спецификация из шагов и переходов между ними. Прогон идёт по опубликованной версии, в фоне, с журналом выполнения.
  • Редактор. Визуальный режим с палитрой шагов и инспектором плюс режим JSON; переходы задаются условиями (равно, не равно, в списке, существует, больше, меньше).
  • Четыре вида шагов. Агентский шаг, скриптовый, шаг с инструментом и шаг с человеком — последний останавливает прогон до решения.
  • Черновик и версия. «Сохранить черновик», «Проверить», «Опубликовать»: прогон возможен только по опубликованной версии, и у пайплайна не больше одного активного прогона.
  • Прогоны и артефакты. Журнал по шагам, «Одобрить»/«Отклонить» с комментарием, отмена прогона и артефакты до 50 МиБ на файл.
  • Шаблоны и расписания. Шаблоны инстанса (включая шаблоны памяти) копируются в проект как черновик, а в расписаниях появилась цель «Пайплайн» — запуск по cron без создания сессии.

Preview

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

Подробнее — Пайплайны и Расписания.

Фоновая работа

  • Что можно увести в фон. Фоновый саб-агент работает в отдельной дочерней сессии, фоновая шелл-команда пишет вывод в лог. Агент запускает их сам, вы — из интерфейса.
  • Вкладка «Процессы». Единый реестр фоновой работы: фильтр по виду, тумблер «Только текущая сессия», остановка, удаление, открытие дочерней сессии и просмотр лога процесса.
  • Перевод идущего прогона в фон. У работающего саб-агента и у запущенной команды есть кнопка «В фон», а ctrl+b переводит в фон все блокирующие прогоны активной сессии. Перевод односторонний — вернуть прогон в диалог нельзя.
  • Лимиты. На одну сессию — два фоновых саб-агента и пять процессов, до десяти записей в реестре; вложенность — один уровень; лог процесса — до 10 МиБ.
  • Уведомления. Старт и завершение фонового прогона отмечаются тостом и плашкой в ленте; терминальные записи живут семь дней.
  • Реестр для агента. Агент видит свои и дочерние прогоны и читает лог инструментами, не открывая интерфейс.

Подробнее — Фоновая работа.

Диалог: вопрос и вмешательство

  • Вопрос с вариантами. Агент посреди хода задаёт от одного до пяти вопросов (до восьми вариантов и свой ответ) и ждёт: ход приостановлен, док висит над композером.
  • Проверка перед отправкой. Ответы собираются по шагам, сворачиваются в компактную панель и проверяются перед отправкой — видно, на что ответа нет.
  • Таймаут. По умолчанию вопрос ждёт, пока на него ответят; срок можно задать отдельно — от пяти минут, с обратным отсчётом в доке.
  • «Вмешаться». Тумблер в композере отправляет сообщение в текущий ход на ближайшей границе шага, не дожидаясь конца генерации; в ленте такое сообщение помечено «Вмешательство в ход».
  • Ограничения. До пяти вмешательств на ход; вмешательство не расширяет права — в режиме плана сообщение тоже идёт под план.
  • «Стоп» — это другое. Кнопка остановки отменяет ход целиком, а не вбрасывает сообщение.

Подробнее — Сессии и проекты.

Рабочие копии репозитория

  • Инвентарь в проекте. Вкладка «Проект» → раздел «Worktree'ы» показывает вторичные рабочие копии репозитория: ветку, привязку к сессии, наличие изменений и состояние каталога.
  • Своя копия на сессию. Сессию можно привязать к worktree — тогда её рабочий каталог берётся из копии, а не из каталога проекта; выбор — в блоке «Рабочий каталог» вкладки «Сессия», привязка видна бейджем в шапке.
  • Создание. В диалоге «Новый worktree» поля можно оставить пустыми — ветку и имя каталога подберёт сервер; занятую ветку вторым worktree не взять.
  • Удаление с подтверждением. Удалить копию, занятую живой сессией, нельзя; грязная копия требует второго подтверждения.
  • Общий репозиторий. У копий общий .git: refs, hooks и stash одни на всех; ignored-файлы (например, .env) в новую копию не копируются — нужен скрипт подготовки проекта.
  • Не граница безопасности. Worktree разделяет рабочие каталоги, а не права: общий .git остаётся общим.

Подробнее — Рабочие копии репозитория.

Мультимодальный ввод

  • Что можно приложить. Изображения, PDF, аудио и видео: кнопка прикрепления, drag&drop и вставка из буфера, чипы с превью, именем и размером, повтор при ошибке загрузки.
  • Три пути доставки. Модель принимает модальность — вложение уходит как есть; не принимает — работает вспомогательная модель семейства, а в диалог идёт текстовое описание; обработки нет — файл отбрасывается в attachments/ рабочего каталога и агент видит путь.
  • Лимиты по умолчанию. 25 МиБ на файл, 10 файлов в сообщении, 1 ГиБ на сессию; осиротевшие вложения хранятся 30 дней.
  • Админ-раздел «Мультимодальный ввод». Мастер-выключатель, набор модальностей, модели по модальностям, лимиты, белый список типов и поведение при отбросе; изменения применяются сразу.
  • Внешние зависимости. Аудио транскодируется в wav, а если модель не принимает видео нативно — из ролика берётся до пяти кадров; для этого нужен ffmpeg. Без него вложение просто отбрасывается.
  • Приватность. Метаданные (EXIF, IPTC, XMP и текстовые чанки PNG) срезаются только при отправке провайдеру; в API и в рабочем каталоге остаётся оригинал. Модель сессии при этом не меняется.

Подробнее — Мультимодальный ввод.

Внешние доступы и полномочия

  • «Доступы». Сохранённая OAuth-авторизация к внешнему сервису: код авторизации с PKCE или код устройства. В интерфейсе видна только маска секрета — сам токен не отдаётся никому.
  • Управление доступом. «Переавторизовать», «Привязать к коннектору», «Отозвать»; отзыв необратим, а истёкший refresh требует явной переавторизации.
  • Без секретов в коннекторах. Заголовки авторизации открытым текстом в MCP-коннекторе запрещены — только через доступ; секрет клиента провайдера хранится в переменной окружения или файле секретов.
  • Права на доступ. Своим доступом распоряжается владелец, доступом проекта — участник с правом изменения содержимого, инстансным — ADMIN и LEAD.
  • Полномочия. Право выражается грантом «действие × цель» с эффектом «Разрешить», «Спросить» или «Запретить». Слой только сужает решения прав инструментов и не расширяет их.
  • Режимы слоя. «Выключен», «Только журнал» (решение считается и пишется, но не применяется — удобно для миграции) и «Принуждение»; включается конфигом, политика читается при старте. «Спросить» не снимается режимом YOLO.
  • Раздел «Полномочия». Только чтение: режим, политика инстанса, роли с грантами и источником, привязки агентов.

Подробнее — Внешние доступы и Полномочия.

Развёртывание: исполнитель и образы

  • Две топологии одной конфигурации. inline — команды исполняются в процессе сервера (all-in-one), remote — сервер остаётся тонким управляющим слоем, а shell, git и поиск идут в отдельных контейнерах-исполнителях. Переключатель — параметр запуска, смена только перезапуском.
  • Общий рабочий том. Исполнителю и серверу нужен один и тот же каталог workspace с доступом ReadWriteMany; если подходящего класса хранилища нет, подключается свой claim.
  • Доверие и сеть. Токен между сервером и исполнителем берётся из Secret и не хранится в конфиге; сетевую политику можно сузить до «вход только от управляющего слоя, выход только DNS».
  • Flavor-образы. От тонкого slim без инструментов до core, dev, devops, browser с браузерной автоматизацией и full со всем набором. Сокет Docker не монтируется ни в одном варианте.
  • Совместимость протокола. Протокол исполнителя — версия 5, она добавляет вложения в результатах MCP-вызовов. Исполнитель старого протокола продолжает работать: результат приходит текстом, вызов не падает.
  • Локальные сценарии. В docker compose появились профили all-in-one и split — второй поднимает тонкий сервер, исполнитель, интерфейс и общий том; профиль postgres включается отдельно и сочетается с любым из них.

Подробнее — Docker, Kubernetes / Helm и Конфигурация.

Хранение состояния в SQL

  • Что переехало в PostgreSQL. Пакеты расширений, скиллы, проектный контекст и прежний контур пайплайнов теперь живут в базе — как сессии, проекты и настройки. Файловое хранилище остаётся рабочим по умолчанию.
  • Что осталось на томе. Бинарные объекты — вложения, артефакты прогонов, содержимое скиллов, логи процессов — остаются файлами, в базе только ссылки. Учёт ссылок не даёт удалить объект, который ещё нужен.
  • Сборка мусора. Осиротевшие вложения удаляются по сроку (по умолчанию 30 дней), общий уборщик работает и для staging-загрузок.
  • Деградированный режим. Если база недоступна, инстанс поднимается на файловом фоллбеке строго на чтение: диагностика работает, изменения отвечают отказом, доступ — администратору. Возврат — только перезапуском.
  • Чего не делать. Данные фоллбека нельзя копировать в базу вручную: после восстановления базы инстанс возвращается к ней, а ручная копия создаёт расхождение. Для режима базы рекомендуется остановка вместо фоллбека.
  • Бэкап. synth backup снимает каталог данных и предупреждает, что базы в архиве нет: полный бэкап — дамп базы плюс архив тома с бинарными объектами.

Подробнее — Конфигурация и CLI.

Исправления и мелочи

  • Сообщения из мессенджеров. Голосовое, фото или файл без текста приходят в диалог понятным маркером, а не служебной структурой; аудио и медиа без подписи доходят до модели так же, как обычные вложения.
  • Звук внутри видео. Если модель принимает видео, но не принимает аудио, дорожка извлекается из ролика и распознаётся вспомогательной моделью — расшифровка идёт в диалог текстом рядом с самим видео.
  • Поддержка форматов — из каталога. Какие вложения принимает модель, определяется по каталогу провайдера, а не по префиксу имени модели: PDF у OpenAI-совместимых провайдеров и Anthropic больше не отбрасываются по ошибке.
  • Живые события в интерфейсе. Миниатюра вложения в отправленном сообщении и статусы фоновых прогонов обновляются без перезагрузки страницы.
  • Контекст. Отключение одной реплики в контексте убирает весь её ход целиком, а не половину; поток и финальное сообщение одинаково показывают «Размышления».
  • Права на чтение. Проверка доступа к сессиям и проектам приведена к одной матрице: чтение не даёт права на изменение, участник проекта читает сессии проекта, администратор и ведущий видят всё.
  • Фон и рабочие копии. Идентификатор фонового процесса теперь сохраняется и в базе, а у рабочих копий исправлены идентификатор в ответе инструмента, действие в событии и гонка при привязке сессии.
  • Плагины и мелочи. Подтверждение установки пакета учитывается при активации, фингерпринт индекса памяти считается по фактической модели эмбеддингов; в интерфейсе настроек, текстах ошибок и локализации — мелкие правки.

Как обновиться

Перед обновлением

  • PostgreSQL. Если инстанс работает на базе, сначала сделайте дамп базы и резервную копию тома: synth backup снимает каталог данных, но базы в архиве нет. Полный бэкап — дамп плюс архив тома.
  • Схема данных. После обновления выполните synth migrate --yes, если инстанс сообщает о несоответствии схемы; повторный прогон безопасен.
  • Remote-режим. Обновляйте сервер и исполнителей согласованно: протокол исполнителя — версия 5. Старый исполнитель деградирует безопасно — отдаёт текстовый результат вместо вложений, но новые возможности вложений в MCP-результатах не появятся.

Порядок зависит от способа установки:

npm install -g @itphx/synth@latest
synth --version

docker pull gitverse.ru/itphx/synth:0.12.4
docker rm -f synth
# затем запустите контейнер заново

Тома с данными не затрагиваются — история и настройки сохраняются. Если используется PostgreSQL, обновите и её контейнер по вашему регламенту.

helm upgrade synth synth/synth -f my-values.yaml --namespace synth

Данные backend хранятся на PVC и переживают обновление. В split-режиме образ исполнителя обновляется тем же релизом: не оставляйте сервер и исполнителей на разных версиях дольше, чем нужно.

Обновление — не synth update (команда обращается к npm-реестру), а замена бандля: остановить сервис, распаковать новую версию, выполнить synth migrate --yes, запустить и проверить.

Проверка после обновления

Убедитесь, что инстанс отвечает на /ready, интерфейс открывается без ошибок, а разделы «Аддоны» и «Плагины» показывают ожидаемое состояние. Если включён мультимодальный ввод, проверьте, что вспомогательные модели по модальностям выбраны и доступны.

Подробнее — FAQ, Docker, Kubernetes / Helm и Эксплуатация (офлайн).

Что дальше