Средний

13 мин

1

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

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

0. Почему нужен AI-агент, а не «ещё один чат»

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

Это сложные сценарии из нескольких шагов. При этом шаги нужно настраивать в зависимости от специфики процессов конкретного бизнеса:

Для автоматизации таких процессов AI должен не просто отвечать на вопросы, а работать внутри: нейросети нужно понимание общей ситуации, уметь запускаться в ответ на определённые события, вызывать необходимые инструменты и записывать результат обратно в систему. В Битрикс24 реализован именно такой сценарий.

Применительно к системе Битрикс24 «AI-агент» — это шаблон бизнес-процесса, в котором рядом со стандартными узлами (триггеры, условия, циклы, отправка сообщений) живёт AI-узел. Список инструментов, которые этому AI разрешены, объявляется прямо в графе отдельными декларативными узлами на стандарте MCP (Model Context Protocol).

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

I. Что имеем

В интерфейсе продукта появляется раздел раздел «AI-агенты», список предустановленных Битрикс24 шаблонов, кнопка «Запустить».

Сейчас по умолчанию доступны три агента:

• Агент для базы знаний — отвечает сотрудникам в чате на вопросы по загруженным документам. Его разберём подробно.

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

• Агент для управления проектами — мониторит задачи проекта, триггерится на приближение сроков, отпуска и больничные, подсказывает менеджеру, кому что поручить.

Каждый агент — это папка в bizproc/nodes/AI_AGENT/ с template.json, файлом установщика и языковыми строками. Шаблоны периодически синхронизируются с базой данных — например, при открытии раздела агентов или по фоновому расписанию. За это отвечает метод NodesInstallerService::trySyncSection('AI_AGENT').

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

Ноды, или узлы, построены на базе действий движка бизнес-процессов. Это классический движок выражений BizProc, которому много лет. Мы его не переизобретали, просто AI-узлы им пользуются наравне с любым другим узлом.

II. Анатомия шаблона

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

II. 1. Что такое шаблон агента

Любой AI-агент в системе — это не отдельная технология, а обычный шаблон бизнес-процесса с описанием всех шагов и связей между ними. Что хранит шаблон:

• Какие действия должен выполнять агент.

• В каком порядке.

• Какие данные передавать между шагами.

• Как всё отображается в визуальном редакторе.

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

• Children — массив всех узлов графа;

• Properties.Links — массив связей между узлами.

Каждый узел несёт две параллельные структуры:

• Properties: что узел делает — параметры исполнения.

• Node: как узел выглядит — позиция на канвасе, порты, иконка, цвет.

Вот так выглядит одно из действий в AI-узле из RAG-бота:

{
   "actionId": "AiAssistantAgentActivity",
   "rawActivityData": null,
   "activityData": {
       "Name": "A6300_4262_5650_2290",
       "Type": "AiAssistantAgentActivity",
       "Activated": "Y",
       "Properties": {
           "mcpUser": "{=A4779_5099_8251_9257:SenderId}",
           "query": "###BIZPROC_NODES_BITRIX_AI_PROJECT_PULSE_QUERY_2###",
           "systemPrompt": "###BIZPROC_NODES_BITRIX_AI_PROJECT_PULSE_SYSTEMPROMPT_2###",
           "returnType": "text",
           "jsonSchema": "",
           "jsonPath": null,
           "usePseudonymizer": "Y",
           "Title": "###BIZPROC_NODES_BITRIX_AI_PROJECT_PULSE_TITLE_9###"
       },
       "ReturnProperties": [
           {
               "Id": "aiResult",
               "Type": "string",
               "BaseType": null,
               "Name": "###BIZPROC_NODES_BITRIX_AI_PROJECT_PULSE_NAME_4###",
               "Description": null,
               "Multiple": false,
               "Required": false,
               "Options": null,
               "Settings": null,
               "Default": null
           },
           {
               "Id": "errorMessage",
               "Type": "string",
               "BaseType": null,
               "Name": "###BIZPROC_NODES_BITRIX_AI_PROJECT_PULSE_NAME_7###",
               "Description": null,
               "Multiple": false,
               "Required": false,
               "Options": null,
               "Settings": null,
               "Default": null
           },
       ],
       "Document": null
   },
   "document": null
}

Два соглашения, которые мы встретим везде:

1. Идентификатор узла — случайная строка формата A<dddd>_<dddd>_<dddd>_<dddd>.
   Идентификатор используется и как Name (runtime-имя узла, к которому обращаются выражения), и как id в визуальной части.

2. Ссылки на значения других узлов — выражения {=NodeName:Field}. Здесь видно: 

   1. query берётся из поля Message узла-триггера A9700_...;

   2. mcpUser — из его же SenderId.

II.2. Граф: узлы соединяются портами

Внутри агент устроен как граф: отдельные блоки соединяются между собой линиями и передают управление друг другу. Это похоже на визуальное программирование: один блок запускает процесс, другой вызывает AI, третий отправляет сообщение.

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

Связи в Links -- это связь вида [откуда, куда], где «откуда/куда» - это строки формата NodeName:portId:

"Links": [
    ["A4791_5036_6881_3286:o0", "A7649_2965_8496_3775:i0"],
    ["A7649_2965_8496_3775:o0", "A7426_4464_6102_9845:i0"],
    ["A6799_3346_2347_2123:o0", "A5172_6770_9062_4959:i0"]
]

Портов у узла может быть много, всё зависит от сценария, который мы хотим закрыть. Как пример — AI-узел, чей JSON мы видели выше. В нём могут быть порты следующего вида:

• i0 — стандартный вход слева, сюда управление приходит. 

• o0 — основной выход справа, отсюда процесс идёт дальше.

• a0 (aux) — нижний порт, сюда подключаются инструменты и источники данных: MCP-узлы с наборами инструментов и RAG-источники.

Выглядит это так:

Горизонтальная ось — поток управления: «Прошли шаг, пошли дальше».

Вертикальная ось вниз — объявление ресурсов, где указаны инструменты и источники контекста, разрешённые конкретному AI-узлу. Получается, что процесс читается «слева направо», а каждая AI-нода «сверху вниз» оборудована своим набором доступного.

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

II.3. Типы узлов

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

• Понимать, как выполнять этот блок.

• Правильно отображать его в визуальном редакторе.

Внутри движка типы узлов описаны отдельным PHP enum-классом ActivityNodeType, где перечислены все поддерживаемые типы узлов:

enum ActivityNodeType: string
{
    case COMPLEX   = 'complex';    // составные конструкции с вложенным телом -- условия и т. п.
    case SIMPLE    = 'simple';     // обычное одношаговое действие
    case TRIGGER   = 'trigger';    // запускает процесс по событию
    case FRAME     = 'frame';
    case TOOL      = 'tool';
    case SERVICE   = 'service';    // системные узлы: storage, утилиты
    case OPERATORS = 'operators';
}

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

Сами узлы декларируются .description.php-файлом рядом с классом действий. Так узел записи в хранилище объявляет и свою категорию, и цвет, и иконку:

use Bitrix\Bizproc\Activity\ActivityDescription;
use Bitrix\Bizproc\Activity\Enum\{ActivityColorIndex, ActivityGroup, ActivityNodeType};
use Bitrix\Ui\Public\Enum\IconSet\Outline;

(new ActivityDescription(
    name: Loc::getMessage('BIZPROC_WRITE_DATA_ACTIVITY_NAME'),
    description: Loc::getMessage('BIZPROC_WRITE_DATA_ACTIVITY_DESCRIPTION'),
    type: [ ActivityType::NODE->value ],
))
    ->setClass('WriteDataStorageActivity')
    ->setNodeType(ActivityNodeType::SERVICE->value)
    ->setGroups([ ActivityGroup::STORAGE->value ])
    ->setColorIndex(ActivityColorIndex::CYAN->value)
    ->setIcon(Outline::PLUS_M->name)
    ->toArray();

Ничего сложного — плоский декларативный конфиг: категория (куда в sidebar), цвет, иконка, класс-исполнитель. 

II.4. Язык выражений

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

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

• {=NodeName:Field} — ссылка на значение поля другого узла. Пример из RAG-бота: {=A9700_4393_6634_9720:Message} — «возьми поле Message у триггера».

• {{=func(...)}} — вычисляемое выражение с использованием встроенных функций (dateadd, арифметика, работа со строками и т. п.).

III. AI-слой внутри процесса

До этого речь шла о обычной инфраструктуре бизнес-процессов. В этой части рассказываю про AI-часть системы — то, что превращает обычный бизнес-процесс в AI-агента.

III.1. AI-узел — узел, который зовёт LLM

AI-узел — центральная единица AI-агента. Именно он отправляет запрос в языковую модель и получает ответ. AI может возвращать не только текст, но и структурированные данные в JSON-формате. В базовом виде схема такая: «отправить промпт — получить ответ — положить в переменную». 

Сначала посмотрим на фрагмент реального конфига AI-узла из RAG-бота, потом разберём его:

{
   "Name": "A9427_8490_1947_9553",
   "Type": "AiAssistantAgentActivity",
   "Activated": "Y",
   "Properties": {
       "mcpUser": "{=A9700_4393_6634_9720:SenderId}",
       "query": "{=A9700_4393_6634_9720:Message}",
       "systemPrompt": "###BIZPROC_AI_AGENT_RAGCHATBOT_SYSTEMPROMPT_1###",
       "returnType": "json",
       "jsonSchema": "{\n  \"type\": \"object\",\n  \"properties\": {\n    \"chatAnswer\": {\n      \"type\": \"string\",\n      \"description\": \"Human readeable answer\"\n    },\n    \"isKnowledgeBaseHasAnswer\": {\n      \"type\": \"boolean\",\n      \"description\": \"Is knowledge base has information for user request?\"\n    }\n  },\n  \"required\": [\n    \"chatAnswer\",\"isKnowledgeBaseHasAnswer\"\n  ]\n}",
       "jsonPath": {
           "chatAnswer": {
               "Id": "chatAnswer",
               "Type": "json",
               "BaseType": "string",
               "Name": "JSON:chatAnswer",
               "Description": null,
               "Multiple": false,
               "Required": false,
               "Options": null,
               "Settings": null,
               "Default": null
           },
           "isKnowledgeBaseHasAnswer": {
               "Id": "isKnowledgeBaseHasAnswer",
               "Type": "json",
               "BaseType": "bool",
               "Name": "JSON:isKnowledgeBaseHasAnswer",
               "Description": null,
               "Multiple": false,
               "Required": false,
               "Options": null,
               "Settings": null,
               "Default": null
           }
       },
       "usePseudonymizer": "Y",
       "Title": "###BIZPROC_AI_AGENT_RAGCHATBOT_TITLE_2###",
       "EditorComment": ""
   }

Что здесь за параметры:

• query — пользовательский запрос. Обычно — выражение, подтягивающее текст из триггера или предыдущего узла.

• systemPrompt — системная часть промпта. Как правило, локализуемая строка.

• returnType — text или json.

• jsonSchema — JSON-Schema ожидаемого ответа, когда returnType = json.

В примере хорошо видна типизированная отдача. AI не просто возвращает текст, он возвращает структурированный объект по схеме. В примере AI обязан вернуть объект с двумя полями:

• chatAnswer — готовый ответ сотруднику;

• isKnowledgeBaseHasAnswer — логическое значение true/false, нашлась ли информация в базе знаний.

Это важно, потому что дальше бизнес-процесс работает уже не с произвольным текстом AI, а с понятными структурированными данными. Например, если isKnowledgeBaseHasAnswer = true, то отправляем ответ сотруднику. Если false, то честно сообщаем, что информации в базе нет.

То есть процесс принимает решения не по тексту ответа модели, а по отдельным полям JSON-структуры. Это надёжнее и проще, чем пытаться разбирать обычный текст через regex или другие эвристики.

III.2. Контроль инструментов через MCP-узлы

Сам по себе AI умеет только генерировать текст. Чтобы он мог создавать задачи, читать CRM, отправлять сообщения или работать с внешними сервисами, ему нужны инструменты. Но делать это нужно под контролем — не «агенту доступен весь CRM», а «агенту в этой точке процесса разрешено только обновить этап сделки и оставить комментарий в задаче».

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

Internal MCP-узел — инструменты из модулей Битрикс24

Первый тип узла — «внутренние» инструменты. Внутренние MCP-узлы дают AI доступ к функциям самого Битрикс24: CRM, задачам, чатам и другим модулям.

Идея простая: каждый модуль Битрикс24, готовый отдавать какие-то свои операции наружу как MCP-инструменты, регистрирует их в общем реестре. CRM предоставляет операции над сделками, лидами и контактами; модуль задач — создание и апдейт задач; мессенджер — отправку сообщений.

У самого узла в настройках два ключевых поля:

• Модуль — какой источник инструментов подключаем: CRM, задачи, чаты;

• Список функций — конкретные операции этого модуля, которые разрешаем агенту.

Когда пользователь открывает настройки такого узла в конструкторе, он видит дерево вида «модуль → список доступных функций с описаниями» и ставит галочки напротив нужных. Выбранное сохраняется в свойствах узла, и именно этот список определит, что будет доступно AI-узлу, к которому этот MCP-узел прицеплен.

Иконка в канвасе подбирается автоматически по модулю — CRM-узел с иконкой CRM, задачи с иконкой задач, мессенджер с иконкой чатов. Взгляд на канвас сразу даёт картину: к какой части системы какой агент прицеплен.

External MCP-узел — подключение внешних серверов

Второй тип узла — «внешние» инструменты. AI-агент может работать не только с Битрикс24, но и с внешними системами: 1С, Gmail, собственными сервисами компании. 

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

Любой совместимый MCP-сервер (в сторонней системе, у партнёра, собственной разработки) можно зарегистрировать с нужным типом авторизации (OAuth, API Key, Basic) и затем прицепить к процессу как узел. AI-агенту, к которому подключён этот узел, становятся доступны функции этого внешнего сервера.

Отдельная важная деталь: в каталоге подключенных серверов внутри Битрикс24 есть флажок «разрешён для агентов». Можно держать в системе общий список MCP-серверов для разных сценариев и отдельно выделять, какие из них пригодны именно для использования внутри агентов. Маленькая, но нужная граница — не каждый внешний сервис, удобный как инструмент в ручном режиме, безопасно отдавать на автономное использование LLM.

Как AI видит подключённые инструменты

Когда к AI-узлу подключают MCP-инструменты, модель получает описание доступных функций и сама решает, какие использовать.

Визуально MCP-узел кладётся рядом с AI-узлом и подключается снизу. Связь идёт не через основные входы/выходы управления, а через нижний aux-порт (a0), который мы упоминали в разделе про графы. Через него же к AI-узлу подключаются RAG-источники — любая «зависимость» агента прицепляется единообразно. На уровне Links это выглядит так:

["A6799_3346_2347_2123:a0", "A9610_6597_9992_4868:t0"]

a0 — aux-выход AI-узла, t0 — tool-вход MCP-узла. Это и есть указание: «AI-узел, прицепи себе вот этот набор инструментов». 

Плюс: в одном процессе к одному AI можно подключить несколько MCP-узлов,  например CRM и отдельно задачи. Каждый из узлов подключается со своим белым списком функций.

На исполнении это превращается в стандартный MCP tool-calling: AI-узлу передаётся набор деклараций доступных функций, LLM решает, какую звать, MCP-транспорт отрабатывает вызов, результат возвращается в LLM, итоговый ответ — в переменную процесса.

Пример: пользователь пишет: «Назначь задачу Иванову проверить договор». После этого происходит примерно такой сценарий:

1. Модель понимает, что ответ текстом тут бесполезен.

2. Но при этом есть подходящий механизм по созданию задач create_task.

3. Модель создаёт вызов, который уходит в MCP-транспорт. 

4. MCP-транспорт получает вызов и обращается к таск-трекеру.

5. В трекере создаётся задача.

6. MCP-транспорт возвращает результат модели.

Главный практический смысл всей этой конструкции — no-code-контроль AI прямо внутри процесса:

• Не нужно трогать код, чтобы дать агенту доступ к новому инструменту.

• На каждом шаге свой набор разрешённого — агент в одной ветке может обновлять сделки, а в другой только читать задачи.

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

III.3. RAG как источник контекста

Обычная языковая модель не знает внутренние документы компании. Чтобы AI мог отвечать по корпоративной информации, нужен RAG-подход.

В RAG-боте база знаний подключается отдельным типом поля — rag_knowledge_base. Вот как она декларируется в CONSTANTS шаблона:

"SetupTemplateActivity_Z15YXPjTOs": {
    "Name":        "###BIZPROC_AI_AGENT_RAGCHATBOT_NAME_4###",
    "Description": "###BIZPROC_AI_AGENT_RAGCHATBOT_DESCRIPTION_2###",
    "Type":        "rag_knowledge_base",
    "Required":    0,
    "Multiple":    0
}

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

С точки зрения AI-узла — это просто ещё один источник контекста, который автоматически подмешивается в LLM при обработке запроса. Для сотрудника, пишущего в чат, это прозрачно: он спрашивает — агент отвечает по корпоративным документам.

IV. Конструктор процессов

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

Визуальный редактор процессов живёт в отдельном модуле bizprocdesigner. 

В сторе — знакомые нам по JSON сущности: блоки, связи, порты. Типы портов, которыми оперирует фронт, шире, чем базовые i/o:

• input / output — основные входы и выходы управления;

• inputRelation / outputRelation — связи, выражающие зависимость, а не порядок выполнения;

• aux / top_aux — вспомогательные, для прицепа сопутствующих узлов (как MCP-узла к AI-узлу через a0).

Категории в сайдбаре берутся из PHP-enum Bitrix\Bizproc\Activity\Enum\ActivityGroup. Сейчас там около полусотни категорий: STARTER, STORAGE, AI, MCP, SALES_CRM, INTERNAL_COMMUNICATION, TASK_MANAGEMENT, HR. 

$groups = ActivityGroup::toArray();

Каждый узел в своём .description.php делает ->setGroups([ActivityGroup::STORAGE->value]) — и автоматически попадает в нужный раздел сайдбара. Чтобы добавить узел в интерфейсе, не нужно трогать ни фронт, ни каталог — достаточно декларации на стороне активности.

V. Границы возможного

Как у любой системы, у агентов есть честные границы.

У агента нет выхода в интернет. В модуле bizproc нет HTTP-клиентов, и сама активность AI-узла не умеет делать произвольных запросов наружу. Всё внешнее — только через явные активности в графе: внутренние или зарегистрированные внешние MCP-узлы, почтовые активности, интеграции с подключёнными сервисами

Откатить действия процесса нельзя. Если процесс выполнил шаги 1–4, а на шаге 5 произошла ошибка, то созданная на 2-м шаге задача останется созданной, и отправленное на шаге 3 сообщение останется отправленным.г.

Много контекста снижает качество работы AI. Это общее свойство современных LLM: чем больше контекста попадает в промпт, тем хуже качество решений. На практике это значит, что выгоднее делить агента на несколько AI-узлов с узкими промптами, чем пытаться поместить всю логику в один универсальный. 

Перегружать контекст одного запроса данными не стоит ещё и потому, что технические лимиты системы могут отклонить запрос.

VI. Куда планируем двигаться дальше

В ближайших планах 2 вещи:

• Универсальные ноды для CRM-сущностей — сделки, лиды, задачи, контакты. Идея в том, чтобы один узел на канвасе представлял объект целиком, а не по отдельной ноде на каждое действие над ним. Это про удобство проектирования и ближе к доменному взгляду на процесс; логически по-прежнему будет раскладываться в те же примитивы графа, но писать шаблоны станет сильно быстрее. Когда выпустим, расскажем отдельно.

• Новый дизайнер бизнес-процессов — визуальный конструктор пока что находится на стадии тестирования, но в ближайшее время планируем закончить работу над ним и открыть для всех пользователей с подпиской, начиная с тарифа Профессиональный.