Основные понятия и модель

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

На какие вопросы отвечает раздел

• Какую ответственность берёт Conveyor и какую оставляет разработчику?
• Как устроены Запуски, состояние и результаты выполнения шагов от исполнителей?
• Как в процессе применяются изменения графа без перезапуска платформы?
• Какие правила действуют в ходе Запуска?

Процедурная память

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

Оркестрация как главный артефакт

Главным отличием Конвейера от популярных систем оркестрации является его подход к исполнению задач. Система берет на себя крайне малый объем непосредственно исполняемых внутри операций, предоставляя конечному пользователю возможность расширения за счет плагинов. Conveyor берет на себя управление исполняемыми процессами, наблюдаемость, предоставление результатов, MCP-интеграцию и Воркспейс-панели для конечного пользователя, однако само исполнение конкретных задач, как правило, находится за его границами. Исключения в данном случае - это исполнители, модифицирующие граф (циклы, условия, ветвления) и работа с примитивами (строки, числа, время и тп)

Процесс оркестрации:

• Граф процесса создаётся в редакторе. Когда вы запускаете процесс, платформа строит снимок графа и управляет Запуском до завершения.
• Каждый шаг: исполнитель возвращает результат (в том числе ошибку), платформа записывает его в БД вместе со статусом узла.
• Бизнес-логика, повторные попытки и обработка ошибок остаются в исполнителях (плагинах).
• Платформа отвечает за переходы, контракты и Трассировку Запуска. Вычисления внутри шага выполняет исполнитель.

Модель процесса

Процесс — это граф шагов, который вы собираете в редакторе: узлы, связи между ними и контракты входа/выхода на каждом шаге. Редактор описывает логику. Когда процесс запускают, платформа берёт актуальную версию графа и строит по ней снимок для Запуска.

Запуск (run) — одно прохождение процесса по такому снимку от старта до завершения или ошибки. Каждый новый старт процесса создаёт отдельный Запуск по актуальному снимку. Уже идущие Запуски продолжают по своему снимку.

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

Запуск движется только вперёд: он проходит снимок графа последовательно, платформа управляет переходами и записывает результаты выполнения шагов, которые вернули исполнители. Так формируется Трассировка Запуска: статусы узлов и события Запуска.

Глоссарий

• Процесс — описанный граф шагов (диаграмма в редакторе).
• Шаг (step) — единица процесса с контрактом входа/выхода.
• Исполнитель (executor) — ваш код или плагин, выполняющий логику шага.
• Контракт шага — описание входов/выходов исполнителя, которые гарантированы его автором.
• Запуск (run) — одно прохождение процесса по снимку графа от старта до завершения или ошибки.
• Плагин — изолированная интеграция или бизнес-логика вне ядра.
• Ядро (orchestrator) — платформа, управляющая переходами по снимку графа.
• Трассировка Запуска — статусы узлов, результаты выполнения шагов и события Запуска.
• Результаты выполнения шагов — ответ исполнителя платформе: выходные данные, ошибку или иной итог; вместе со статусом узла входят в Трассировку Запуска.
• История Запусков — раздел редактора: список прошлых Запусков процесса и их Трассировка Запуска.
• Журнал аудита — действия пользователей в интерфейсе (создание, изменение и удаление ресурсов).

Принципы проектирования и их следствия

Живое изменение процесса

Граф меняется в редакторе без перезапуска платформы - время от принятия решения об изменениях до самих изменений минимально, однако требует внимательности.

Статус исполнения в базе данных

Состояние и результаты всех исполнителей конкретного Запуска хранятся в БД - это дает полный доступ к аудиту каждого процесса - когда выполнился, что происходило внутри, чем завершился.

Процесс как сервис

Каждый процесс выделяется, сопровождается и подключается отдельно, как самостоятельный сервис в вашей архитектуре. У процесса есть свои API/MCP-эндпоинты, он может выступать как источник данных или предоставлять собственный UI для запуска.

Плагины и ядро

Ядро оркестратора занимается исполнением графа и остается минимальным. Здесь нет тысяч исполнителей "из коробки", но удобный SDK позволяет писать собственные интеграции за минуты.

Модель исполнения

Следствия архитектуры из раздела выше:

• Запуск иммутабелен: каждый Запуск проходит снимок графа от старта до завершения. Зафиксированные результаты выполнения шагов не переписываются. Это основа Трассировки Запуска. Состояние всех узлов Запуска хранится в БД.
• Полный результат шага фиксирован: Исполнитель может отправлять частичные результаты своего исполнения как статус, однако при получении всех необходимых выходов результат фиксируется, последующие попытки дописать или изменить состояние трактуются как ошибка.
• Процесс изменяется на лету: вы обновляете граф (через UI или API). Новые Запуски идут по актуальной версии, платформа продолжает работать без перезапуска.

Дальше

• Архитектура: как принципы реализованы внутри.