Рабочие процессы Discourse

:discourse2: Краткое описание Discourse Workflows позволяет администраторам создавать сложные автоматизации с помощью визуального конструктора, автоматизируя практически любые процессы в вашем сообществе.
:open_book: Руководство по установке Этот плагин входит в состав ядра Discourse. Отдельная установка плагина не требуется.

Workflows — это визуальный конструктор автоматизации, который позволяет администраторам создавать сложные многошаговые автоматизации с помощью холста с перетаскиванием (drag-and-drop) — соединяя триггеры, условия, действия и узлы управления потоком для автоматизации практически всего на вашем сайте Discourse.

:discourse: Discourse Workflows доступен в тарифных планах Business или Enterprise.

Основные понятия

Если вы знакомы с другими инструментами автоматизации, вы, скорее всего, узнаете большую часть терминологии, используемой в Workflows:

  • Workflow (Рабочий процесс): Сохраненная автоматизация, состоящая из связанных узлов.
  • Node (Узел): Один шаг в рабочем процессе: триггеры, условия, действия и узлы управления потоком / утилиты.
  • Trigger (Триггер): Точка запуска рабочего процесса. Триггер может быть ручным или инициироваться конкретным событием — созданием темы, срабатыванием расписания или входящим веб-хуком.
  • Condition (Условие): Узел маршрутизации, который оценивает правило и разделяет поток на ветви. Например, узел If (Если) направляет поток в зависимости от истинного или ложного результата оценки.
  • Action (Действие): Узел, который выполняет конкретное действие — создание поста, присвоение значка, вызов внешнего API и т.д.
  • Item (Элемент): Данные, передаваемые между узлами. Элементы — это JSON-объекты, которые можно просматривать в журналах выполнения и ссылаться на них с помощью выражений.
  • Expression (Выражение): Динамическое значение, записанное как {{ ... }}, которое вычисляется во время выполнения и используется для ссылки на данные из предыдущих узлов, переменных рабочего процесса или настроек сайта.

Создание рабочего процесса

Чтобы создать рабочий процесс:

  1. Перейдите в Admin > Plugins > Workflows и нажмите New workflow.

  1. Назовите ваш рабочий процесс.
  2. Нажмите Add first step и выберите триггер.

  1. Используйте кнопку +, чтобы добавить дополнительные узлы.

  1. Дважды щелкните по узлу, чтобы настроить его. В панели конфигурации слева будут показаны сведения о входе для узла, а справа — сведения о выходе узла. Возможно, вам потребуется запустить рабочий процесс один раз, чтобы увидеть все различные детали.

  1. Когда будете готовы запустить процесс, нажмите Publish.

:light_bulb: Советы:

  • Используйте заметки (sticky notes), расположенные в меню с тремя точками в правом верхнем углу конструктора, чтобы документировать, что делает ваш рабочий процесс. Заметки не влияют на работу рабочего процесса, но облегчают понимание шаблонов и общих рабочих процессов.
  • Используйте узел журнала (log node) во время разработки, чтобы отправлять отладочные значения в журнал выполнения, не влияя на поведение рабочего процесса.
  • Вы можете экспортировать и импортировать рабочие процессы в формате JSON, чтобы делиться ими с коллегами или воссоздавать рабочие процессы с других сайтов.

Выражения и динамические данные

Поля, принимающие выражения, отображают кнопку {/} в редакторе. Нажмите ее, чтобы просмотреть доступные данные из триггера и предыдущих узлов и вставить ссылку.

Общие выражения

Выражение Что возвращает
{{ $json.topic.title }} Заголовок темы из текущего элемента
{{ $json.post.url }} URL поста из текущего элемента
{{ $json.user.username }} Имя пользователя, связанного с текущим элементом
{{ $vars.my_variable }} Значение переменной рабочего процесса с именем my_variable
{{ $site_settings.title }} Заголовок вашего сайта
{{ $execution.id }} Уникальный ID текущего выполнения
{{ $('Node Name').item.json.property }} Выход из конкретного вышестоящего узла, ссылающийся на его имя на холсте

Статические и динамические значения

Поля, начинающиеся с =, рассматриваются как выражения. Поля без начального = рассматриваются как обычный текст. Выборщик выражений обрабатывает это автоматически.

Управление рабочими процессами

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

Выполнения

Каждый раз, когда рабочий процесс запускается, Discourse записывает выполнение. Перейдите в Workflows → Executions, чтобы просмотреть историю.

Каждое выполнение показывает дату и время его завершения и статус:

  • Completed (Завершено): Выполнено до конца без ошибок.
  • Error (Ошибка): Не удалось выполнить на конкретном узле; нажмите на выполнение, чтобы увидеть ошибку и данные, которые ее вызвали.
  • Running (Выполняется): В настоящее время обрабатывается.
  • Waiting (Ожидание): Приостановлено из-за узла Wait; ожидает ответа в форме, модальном окне, одобрения в чате; или узла Call Workflow, ожидающий завершения подпроцесса.
  • Rate limited (Ограничение частоты): Рабочий процесс был пропущен из-за ограничения частоты запросов.
  • Skipped (Пропущено): Триггер сработал, но рабочий процесс не был опубликован.

Вы можете нажать кнопку Show, чтобы более подробно изучить выполнение рабочего процесса. Это показывает каждый шаг рабочего процесса, который можно развернуть для просмотра точных деталей, и длительность этого шага.

В нижней части страницы вы можете увидеть общую продолжительность рабочего процесса. Вы также можете Export журнал при необходимости для обмена или устранения неполадок.

Настройки

На вкладке Workflows → Settings вы можете:

  • Настроить рабочий процесс ошибок, который должен срабатывать, если при запуске этого рабочего процесса произойдут какие-либо сбои. Если у рабочего процесса есть триггер ошибки, он будет обрабатывать ошибки, как определено этим триггером.
  • Установить часовой пояс для триггеров расписания. Если это не установлено, рабочий процесс будет по умолчанию использовать часовой пояс сайта.
  • Удалить рабочий процесс. :warning: Это необратимо, поэтому перед продолжением следует подумать об экспорте вашего рабочего процесса (доступно в меню с тремя точками в правом верхнем углу конструктора рабочих процессов).

Версии

Каждый раз, когда вы вносите обновления в рабочий процесс, мы сохраняем предыдущие версии. Это позволяет легко Revert изменения, которые не сработали так, как вы ожидали.

Переменные

Переменные — это пары «ключ-значение», привязанные к одному рабочему процессу. Определите их в панели Variables рабочего процесса и ссылайтесь на них в любом месте с помощью {{ $vars.key_name }}. Используйте переменные для хранения значений конфигурации (например, ID категории или имени пользователя получателя), которые вы хотите иметь возможность изменять, не редактируя граф рабочего процесса.

Учетные данные

Некоторые узлы — например, HTTP-запрос или AI Agent — должны аутентифицироваться во внешних сервисах. Храните API-ключи и секреты в Workflows → Credentials, а не вставляйте их напрямую в поля узлов. Учетные данные шифруются при хранении и могут использоваться повторно в разных рабочих процессах.

Поддерживаемые типы учетных данных:

  • Basic Auth (имя пользователя + пароль)
  • Bearer token
  • Header auth (название и значение пользовательского заголовка)

Таблицы данных

Таблицы данных — это постоянные структурированные таблицы, внутренние для плагина Workflows. Используйте узел Data table для чтения из них или записи в них. Они поддерживают типы столбцов string, number, boolean и date.

Таблицы данных полезны для:

  • Удаления дубликатов — запись того, какие пользователи или темы уже были обработаны рабочим процессом
  • Состояния — отслеживание того, находится ли тема на определенном этапе процесса
  • Поиска — хранение отображений (например, ID темы → назначенный сотрудник), которые могут запрашиваться вашими рабочими процессами

Выполнения

Вы можете просмотреть все выполнения всех рабочих процессов на вкладке Executions. Формат и функция очень похожи на выполнения, специфичные для рабочего процесса, но показываются по всем рабочим процессам для более удобного мониторинга.

Шаблоны

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

:megaphone: Хотите увидеть больше шаблонов? Мы будем работать над расширением библиотеки доступных шаблонов со временем, но, пожалуйста, сообщите нам, если есть шаблон, который вы хотели бы видеть здесь, чтобы облегчить использование Workflows.

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

21 лайк

Привет, при попытке активировать этот плагин я получаю следующее сообщение об ошибке: У вас нет разрешения на изменение скрытых настроек: discourse_workflows_enabled

2 лайка

В настоящее время его необходимо включить в /admin/config/upcoming-changes, а не в admin/plugins

3 лайка

Привет! Если я правильно понимаю назначение этих рабочих процессов, то один из примеров шаблона, который я хотел бы предложить, — это добавить административную кнопку к темам, которая сразу же поднимает тему наверх. Реализуемо? :grinning_face:

1 лайк

Привет!

Как нам гарантировать, что функция «Build with AI» использует конкретную LLM?
При использовании Google Gemini в качестве LLM по умолчанию в нашей системе я получаю ошибку: Invalid JSON payload received. Unknown name “additionalProperties” at ‘tools[0].function_declarations[5].parameters’: Cannot find field

Спасибо!

1 лайк

Какую модель Gemini вы используете? Чтобы её изменить, выберите агента рабочего процесса и замените модель LLM по умолчанию.

1 лайк

Привет, Сэм! Gemini 3 Flash.

Я нашёл настройку рабочего процесса, и там действительно стоял Gemini Flash 3. Я переключился на GPT Nano 5, но ошибка всё равно остаётся.

Я даже изменил значение по умолчанию для всех пользователей на GPT Nano 5 и проверил индивидуальные настройки рабочего процесса. Там тоже установил переопределение на GPT Nano 5.

Но безрезультатно. :frowning:

1 лайк

Есть ли у вас доступ к Luna, Terra, 3.5 Flash или Sonnet?

В рабочем процессе ИИ-агента используется довольно много инструментов, поэтому, как правило, требуется современная языковая модель.

1 лайк

Я был уверен, что Flash Lite работал, но это не так. GPT Nano 5 определённо работал. Похоже, это известная проблема, которая возникает даже в WordPress. Вот ссылка для справки. Нам нужно делать следующее: при использовании провайдера Gemini необходимо удалять элемент additionalProperties из схемы JSON-ответа: Remove `additionalProperties` from the JSON response schema - Pull Request #18 - WordPress/ai-provider-for-google - GitHub

ой, я сейчас интенсивно занимаюсь переходом на API взаимодействий, так что, думаю, это обеспечит нам гораздо более стабильный мост к моделям Gemini, hopefully на следующей неделе.

2 лайка

Отлично, и спасибо за быстрый ответ! Я нашел еще немного контента, но думаю, вы уже поняли идею. :wink:

Это собственное объяснение от Gemini (Google). Надеюсь, всё понятно? Я не до конца понимаю все нюансы, но точно знаю, что проблема возникает из-за этого свойства. LOL.

Кратко: Ошибка сохраняется, потому что Google использует два совершенно разных движка для обработки схем. Хотя Gemini поддерживает стандартный JSON Schema для структурированных выходных данных (response_json_schema), его движок вызова функций / выполнения инструментов по-прежнему использует строгий парсер OpenAPI 3.0 Protobuf от Google, который отклоняет или «захлебывается» на additionalProperties.

1. Вызов инструментов против структурированного вывода (разделение движков)

API Gemini проверяет схемы в двух разных местах:

  • Структурированный вывод (response_json_schema): Предназначен для форматирования итогового ответа модели. Использует стандартный парсинг JSON Schema и корректно обрабатывает additionalProperties.

  • Вызов инструментов/функций (tools[0].function_declarations): Предназначен для передачи сайтовых инструментов (например, поиска Discourse AI, действий персонажей или веб-серфинга) модели. Этот эндпоинт преобразует схемы во внутренний Protobuf-объект google.ai.generativelanguage.v1beta.Schema от Google.

Поскольку эндпоинт инструментов отображает параметры на устаревшее подмножество OpenAPI 3.0, отправка additionalProperties в объявлении функции заставляет парсер API возвращать ошибку 400 Bad Request или MALFORMED_FUNCTION_CALL.

GitHub

2. Почему фреймворки, такие как Discourse, внедряют это свойство

Оркестровые фреймворки (Discourse AI, Model Context Protocol/MCP, LangChain, Pydantic, Zod) автоматически генерируют JSON-схемы для пользовательских инструментов:

  1. Строгие значения по умолчанию: Генераторы автоматически добавляют "additionalProperties": false, чтобы принудительно обеспечить строгую типизацию параметров.

  2. Динамические карты/словари: Если параметр инструмента использует хеш/словарь ключ-значение (например, dict[str, Any] или Ruby Hash), генераторы схем выводят "additionalProperties": { "type": "string" }.

  3. Неочищенный полезный груз: Когда Discourse отправляет эти автоматически сгенерированные схемы инструментов на эндпоинт объявлений функций Google, Protobuf-парсер Gemini помечает additionalProperties как недопустимое или неизвестное поле.

3. Как исправить это в Discourse

Если вы видите эту ошибку при вызове инструментов Discourse AI:

  • Избегайте динамических параметров Hash/Dict: Убедитесь, что параметры пользовательских инструментов явно определяют каждый ожидаемый ключ в разделе properties, вместо использования объектов с открытой структурой.

  • Сериализуйте динамические данные в строки: Если инструмент должен принимать произвольные пары ключ-значение, определите параметр как STRING и укажите инструменту принимать сериализованную JSON-строку.

  • Исключите additionalProperties в пользовательских инструментах: Если у вас есть пользовательские ИИ-инструменты, определенные в разделе /admin/plugins/discourse-ai/ai-tools, отредактируйте JSON-схему параметров, чтобы удалить любые блоки "additionalProperties".

Я только что создал PR, который добавляет поддержку Interaction API. Если у вас есть тестовая среда, буду благодарен за дополнительное тестирование.

Есть ли планы разрешить получение внешних идентификаторов пользователей через рабочие процессы? Я хотел бы создать форму, которая проверяет некоторую информацию о текущем пользователе в системе поставщика удостоверений перед продолжением, но узел «Получить пользователя», насколько я могу судить, не выводит поле external_id.

Спасибо за обратную связь, этого должно быть достаточно: FIX: supports optional data for workflow user node (#42400) · discourse/discourse@4d0c688 · GitHub

3 лайка

Есть ли способ преобразовать user_id в username? Я рассматриваю вариант использования, при котором создателю темы отправляется личное сообщение. Но из объекта topic я могу получить только user_id, а для отправки личного сообщения требуется username.

Или, как вариант, — если бы был способ получить первый пост по topic_id, это тоже сработало бы, так как в посте есть поле username.

1 лайк

@thgl Да, учитывая, что у нас есть узел data-explorer, можно выполнить запрос любого типа для получения любой информации (в данном случае я захардкодил user_id, но вы понимаете идею):

workflow-nodes-2026-08-18.json (2.1 KB)

2 лайка

@patrickemin Не уверен, что вы уже это видели, но я добавил все необходимые строительные блоки для этого сценария использования. Дайте знать, если вам нужна помощь.

1 лайк

О, это здорово, спасибо!

Ну, я не нашёл действие для назначения на кнопку административной темы для этого сценария: