Action-Based Workflow Engine — архитектурный паттерн, в котором возможности системы оформлены как отдельные действия с явным контрактом, а оркестратор решает, когда и в какой последовательности их запускать. Такой подход помогает контролировать сложные автоматизации и агентов с искусственным интеллектом (AI-агентов): каждое действие можно проверять, ограничивать и переиспользовать независимо от общего сценария.

Содержание

  1. Целевая архитектура
  2. Контракт действия
  3. Как работает оркестратор
  4. Последовательное, условное и параллельное выполнение
  5. Эталонный шаблон на TypeScript
  6. Пример прикладного пайплайна
  7. Чеклист быстрой проверки
  8. Когда паттерн оправдан

Целевая архитектура

Система состоит из четырёх частей:

  • реестр действий хранит доступные операции и их контракты;
  • оркестратор выбирает следующий шаг по задаче и текущему состоянию;
  • исполнитель проверяет входные данные, ограничения и разрешения, затем вызывает обработчик;
  • состояние выполнения хранит результаты, ошибки и завершённые шаги.
flowchart LR
    T[Задача] --> O[Оркестратор]
    O --> R[Реестр действий]
    R --> E[Исполнитель]
    E --> X[Внешняя система или функция]
    X --> S[Результат и состояние]
    S --> O
    O --> F[Завершение]

В документации n8n об узле AI Agent указано, что к узлу подключают чат-модель и один или несколько инструментов, а агент определяет, какие инструменты вызвать для выполнения задачи. Для собственного исполнителя это означает, что модель может выбирать маршрут, но технические границы остаются у системы: разрешённые действия, проверка параметров, лимит шагов, тайм-ауты и правила завершения.

Контракт действия

Минимальный контракт удобно строить из следующих полей:

ПолеНазначение
nameСтабильный уникальный идентификатор действия
descriptionОднозначное описание назначения для оркестратора или модели
inputSchemaТипы, обязательность и ограничения входных параметров
handlerКод, выполняющий операцию

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

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

Идемпотентное действие при повторном вызове с теми же параметрами не создаёт нежелательного дополнительного эффекта. Это особенно важно для записей: повтор после сетевой ошибки не должен создавать вторую страницу или дважды отправлять сообщение. Описание действия должно называть эффект, обязательные параметры и условия применения. Формулировка «работает с сообщениями» слишком расплывчата.

Как работает оркестратор

Базовый цикл:

  1. получает задачу и исходное состояние;
  2. определяет допустимые действия для текущего этапа;
  3. выбирает одно действие или безопасную группу независимых действий;
  4. проверяет параметры по схеме и правилам доступа;
  5. запускает обработчик;
  6. сохраняет результат или структурированную ошибку;
  7. проверяет условие завершения и при необходимости запускает следующий шаг.

Явно задайте границы:

  • максимальное число шагов и общее время;
  • ограничение параллелизма;
  • максимальное число повторов;
  • правило остановки после критической ошибки;
  • конечное состояние, по которому задача считается выполненной.

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

Последовательное, условное и параллельное выполнение

Последовательная цепочка

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

read_source → classify_content → write_draft → create_page

Условная ветка

Маршрут зависит от результата проверки. Условие лучше выражать структурированным статусом или кодом ошибки:

parse_source
  ├─ success → classify_content
  └─ retryable_error → retry_with_backoff

Параллельная группа

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

По состоянию на 8 сентября 2026 года документация n8n о порядке выполнения указывает: в рабочих процессах, созданных начиная с n8n 1.0, каждая ветвь выполняется целиком до запуска следующей. Порядок определяется положением ветвей на холсте: сначала идёт верхняя, а при одинаковой высоте левая. Настройка рабочего процесса позволяет изменить этот порядок. Поэтому наличие нескольких ветвей в n8n само по себе не означает параллельное выполнение.

В документации GitHub Actions, проверенной 8 сентября 2026 года, независимые задания (jobs) могут выполняться параллельно; needs задаёт зависимости между ними, а jobs.<job_id>.strategy.max-parallel ограничивает число одновременно выполняемых элементов матричного запуска (matrix). Эти механизмы полезны как ориентир, но семантику собственного исполнителя нужно определить отдельно.

Эталонный шаблон на TypeScript

Ниже архитектурный шаблон. pageClient обозначает адаптер к конкретной системе.

type ActionContext = {
  signal: AbortSignal;
  executionId: string;
};

type Action<I, O> = {
  name: string;
  description: string;
  timeoutMs: number;
  idempotent: boolean;
  validate: (input: unknown) => I;
  handler: (input: I, context: ActionContext) => Promise<O>;
};

type ReadPageInput = { pageId: string };
type ReadPageOutput = { title: string; content: string };

const readPage: Action<ReadPageInput, ReadPageOutput> = {
  name: "read_page",
  description: "Reads one page by its identifier.",
  timeoutMs: 10_000,
  idempotent: true,

  validate(input) {
    if (
      typeof input !== "object" ||
      input === null ||
      !("pageId" in input) ||
      typeof input.pageId !== "string"
    ) {
      throw new Error("pageId must be a string");
    }
    return { pageId: input.pageId };
  },

  async handler({ pageId }, context) {
    return pageClient.read({ pageId, signal: context.signal });
  }
};

const actions = new Map<string, Action<unknown, unknown>>([
  [readPage.name, readPage as Action<unknown, unknown>]
]);

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

Пример прикладного пайплайна

Контент-агент может обрабатывать входящую задачу так:

read_inbox_card
  → check_status
  → set_status_processing
  → read_source
  → classify_content
  → write_draft
  → create_page
  → link_result
  → set_status_done

Критичные правила:

  • check_status завершается до смены статуса;
  • create_page использует идемпотентный ключ или проверку дубля;
  • link_result запускается только после подтверждённого создания страницы;
  • финальный статус устанавливается после проверки результата;
  • ошибка хранится с идентификатором шага и признаком возможности повтора.

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

Чеклист быстрой проверки

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

Когда паттерн оправдан

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

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

Официальные источники

Проверено 8 сентября 2026 года.

Материал основан на официальной документации и архитектурном анализе.

Следующий шаг

Для практического продолжения темы агентных процессов можно прочитать «ИИ-агент как новый сотрудник: сначала онбординг, потом работа».

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov