Документация / Возможности / Процессы, ИИ-агенты и рабочие места

Процессы, ИИ-агенты и рабочие места

Редакция 24 сентября 2026, дополнена 9 ноября 2026

Для владельца процессаДля администратораДо выбора платформы и при сборке автоматизации

Заявка, договор или обращение часто проходят несколько шагов и по нескольку дней ждут, пока их одобрят сотрудники. Платформа ведет такую работу от начала до итога, останавливается там, где решать должен сотрудник, и помнит, на каком шаге остановилась, даже после сбоя сервера. Эта страница о том, как платформа ведет такую работу, на каких экранах работают сотрудники и как ИИ-агент обращается к системам компании (например, читает карточку клиента).

7. Исполнение процессов и агентных маршрутов

Долгий процесс продолжается после сбоя сервера и не доходит до итога в обход согласования

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

Как устроен долгий процесс

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

• Согласования. Сотрудник берет дело в работу и выбирает исход согласования (например, «Подтвердить» или «Вернуть на доработку»), а до этого процесс стоит и ждет. Если по правилам автоматизации дело проходит согласование без сотрудника (например, оценка кредитной заявки выше порога), в журнале шагов все равно остается запись о согласовании.
• Таймеры. Таймер отсчитывает срок согласования и паузы между повторами шага. Когда срок согласования истекает, платформа помечает согласование просроченным. Само согласование при этом не проходит и не отменяется.
• Компенсации. Компенсация - это шаг, который отменяет уже сделанное действие (например, удаляет запись, которую процесс раньше создал во внешней системе). Если процесс завершается с ошибкой или его отменили, платформа запускает компенсации всех успешно выполненных шагов, у которых компенсация задана, в обратном порядке.
• ИИ-агенты. ИИ-агент работает в пределах бюджета шага. Бюджет шага - это наибольшее число ходов ИИ-агента (ход - это выбор и выполнение одного действия) и наибольшее время работы, которые задал автор автоматизации. Если бюджет исчерпан, а ИИ-агент не закончил работу, платформа создает согласование, которое проходит только через сотрудника. Сотрудник выбирает, запустить ИИ-агента заново или остановить его. После остановки процесс идет по пути, который маршрут задает для ошибки, а если такого пути нет, завершается с ошибкой.
• Координация подзадач (подробнее в следующем разделе).

Шаг, который завершился ошибкой, платформа повторяет в обоих режимах. Для каждого шага задано, сколько раз и с какими паузами его повторять, а в коротком режиме повторы идут только в пределах времени, отведенного на весь маршрут. После ошибки, которую повтор не исправит (например, запрета доступа), платформа шаг не повторяет. Когда повторы кончились, дело идет по пути, который маршрут задает для ошибки. Если такого пути нет, работа по делу завершается с ошибкой. В режиме долгого процесса перед этим платформа запускает компенсации, если они заданы.

Кроме того, маршрут может разделиться на ветви, заданные заранее, и потом снова собраться в одну ветвь.

Как ведущий шаг делит работу по делу на подзадачи

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

1. Ведущий шаг маршрута (например, обращение к языковой модели) составляет список подзадач.
2. Платформа записывает список в журнал шагов до начала первой подзадачи. Если процесс прервется, после перезапуска платформа возьмет тот же список из журнала шагов и не будет составлять его заново.
3. Для каждой подзадачи из списка платформа запускает один и тот же шаг, который выбрал автор автоматизации (например, шаг ИИ-агента). Подзадачи идут строго одна за другой.
4. Платформа собирает итог из результатов подзадач в порядке списка.

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

В редакторе маршрутов этот механизм называется шагом «Для каждого». В одной автоматизации допускается один такой шаг. Его настройки и границы разобраны на странице видов шагов и их полей.

Что автор автоматизации задает в маршруте долгого процесса

Для каждого шага автор автоматизации задает следующие значения:

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

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

Для каждого согласования автор автоматизации задает следующие значения:

• Очередь (список, из которого сотрудники берут дела на согласование).
• Порог, при котором дело может пройти согласование без сотрудника.
• Срок согласования в часах.
• Варианты исхода (например, «Подтвердить» или «Вернуть на доработку») и то, нужен ли к исходу комментарий.
• Основание согласования (правило компании или требование регулятора).

Порог согласования компания может менять на экране «Настройка автоматизации» в пределах, которые задал автор автоматизации. Если основание согласования - это правило компании, порог можно настроить так, что без сотрудника будут проходить все дела. Если основание - это требование регулятора, допустимые значения порога не позволяют пропустить без сотрудника все дела, и отключить такое согласование на экране настройки нельзя. В обоих случаях согласование остается в маршруте, и о каждом деле, которое прошло согласование без сотрудника, в журнале шагов остается запись согласования. Как собрать такой маршрут, разобрано на страницах «ИИ-агент с нуля» и «Виды шагов и их поля».

Чего долгий процесс не делает

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

8. Рабочие места

Кто работает на каждом рабочем месте

Рабочие места на платформе следующие:

• Рабочее место контролера. Контролер - это сотрудник, который согласует дела (например, подтверждает кредитную заявку или возвращает ее на доработку).
• Рабочее место оператора. Оператор - это сотрудник, который ведет дела автоматизации (например, заводит и ищет заявки, задает вопросы ИИ-ассистенту и следит за ходом процессов).
• Журнал аудитора. Аудитор - это сотрудник службы безопасности или внутреннего аудита компании, который смотрит, как на платформе принимались решения по делам. Журнал аудитора - это экран, на котором аудитор читает журнал аудита (запись событий для службы безопасности, в которую можно только дописывать).

Рабочие места служат только сотрудникам компании.

Как контролер согласует дело на одном экране

Контролер видит на одном экране все, что нужно для согласования, и там же выбирает исход. В карточке дела собраны следующие сведения:

• Проект решения по делу (например, предложение одобрить заявку), который подготовила автоматизация.
• Объяснение проекта решения (текст и факторы, которые повлияли на оценку дела, например на оценку кредитной заявки).
• Доказательства (документы, на которых основан проект решения, вместе с исходными файлами).
• История прошлых кругов согласования (каждый возврат на доработку и повторная подача).
• Ссылка на трассы дела.

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

Как оператор ведет дела автоматизации

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

Как аудитор проверяет решения по делам

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

• Лента событий аудита (кто, когда и что сделал на платформе).
• Карточка события с подробностями.
• Переход от события к трассам дела.
• Выгрузка событий в файл (в формате CSV для таблиц и JSONL для систем анализа журналов).
• Обоснование соответствия (документы автоматизации для проверяющих о том, как автоматизация выполняет обязательные требования).

События журнала аудита на этом экране отбираются по периоду, автоматизации, процессу, типу события, сотруднику и объекту события (например, делу или документу).

Что автор автоматизации задает на рабочих местах

Автор автоматизации задает следующие элементы рабочих мест:

• Очереди согласования и их названия на экране.
• Колонки в списке дел очереди.
• Подписи кнопок исхода (например, «Подтвердить», «Вернуть на доработку» и «Отклонить»).
• Экраны рабочего места оператора.

Роль аудитора на платформе есть всегда. Роли контролера и оператора создает автоматизация, а какие сотрудники их получают, компания задает на экране «Настройка автоматизации». Сводка очередей на рабочем месте контролера показывает, сколько дел за период в очереди всего, сколько просрочено, сколько взято в работу и сколько прошло без сотрудника.

Чего рабочие места не делают

• Согласовать несколько дел одним действием нельзя, чтобы контролер открывал и проверял каждое дело отдельно.
• Право читать дело открывает все поля дела. Скрыть от сотрудника с этим правом отдельное поле нельзя.
• В журнале аудита хранятся только замаскированные данные (персональные данные, которые нашло маскирование, в нем заменены метками).
• Платформа не запрещает печать и копирование с экрана рабочего места. Все, что сотрудник видит на экране, он может распечатать или скопировать.

Как эти экраны выглядят, показано на странице «Экраны кабинета» (кабинет - это веб-интерфейс платформы для сотрудников и администратора).

10. Реестр инструментов агента

Реестр совпадает с тем, что ИИ-агенты могут вызвать

Реестр инструментов - это перечень всех действий, которые ИИ-агенты и ИИ-ассистенты могут выполнять в системах компании, вместе с правами на вызов и журналом вызовов. Записи в реестр платформа берет из самих автоматизаций. Поэтому каждый инструмент, записанный в автоматизации, есть в реестре, а инструмент, которого нет в реестре, платформа не вызывает.

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

Какие сведения об инструменте записаны в реестре

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

• Название и описание действия.
• Какие ИИ-ассистенты и ИИ-агенты могут вызывать инструмент.
• Для каких случаев инструмент предназначен.
• Как инструмент вызывается и к какой системе обращается.
• Ограничения, правила вызова и права, которые нужны для вызова.
• Версия инструмента.

Где администратор видит реестр инструментов

Экрана каталога действий (в платформе он называется реестром инструментов, это перечень действий, которые ИИ-агент может выполнять во внешних системах) в кабинете нет. Реестр отдается программным интерфейсом платформы по запросу GET /api/core/v1/blueprints/tool-registry. Ответ получают платформенный администратор и аудитор, а рядовым сотрудникам и службам платформы реестр не выдается. Реестр составлен из автоматизаций, версии которых сейчас активны. Вручную его не заполняют и не правят. Запись появляется, когда автоматизация объявляет инструмент, и остается, пока версия автоматизации активна. Если автоматизация объявила инструмент, которого нет в контракте подключения, запись в реестре есть, но помечена как не входящая в контракт, и платформа такой инструмент не вызовет. Для двух встроенных инструментов, поиска по документам и разбора документа, версия в реестре не указана.

Как платформа проверяет право на вызов инструмента

Перед каждым вызовом платформа проверяет роль того, от чьего имени идет вызов, а также автоматизацию, маршрут и шаг, из которых идет вызов. Какие роли могут вызывать инструмент, записано в правилах доступа автоматизации, которые задает автор автоматизации. Какие сотрудники получают эти роли, компания задает на экране «Настройка автоматизации», привязывая к ролям группы сотрудников (подробнее на странице «Доступ и роли»).

Что записывается о вызове инструмента

Журнал вызовов ведется в трассах автоматизаций, и о вызове в нем записаны следующие сведения:

• Процесс и шаг, из которого вызван инструмент.
• Кто вызвал инструмент.
• Какой инструмент вызван.
• Параметры вызова.
• Результат вызова.
• Время и длительность вызова.

На экране журнала вызовов вызовы отбираются по тому, кто вызвал, по инструменту, по процессу и по времени. Параметры и результат вызова сотрудник видит, только если его права допускают класс данных, к которому относятся эти сведения (например, персональные данные показываются только тем, кому они разрешены).

Как администратор открывает журнал вызовов

Журнал вызовов открывается на экране просмотра трасс (записей хода запусков). В меню кабинета ссылки на него нет, поэтому в браузере вводят адрес платформы и добавляют к нему /zhurnal-vyzovov. Тот же журнал в машиночитаемом виде (JSON, формат записи данных для программ) отдает адрес /zhurnal-vyzovov.json, вход нужен тот же. Экран открывается сотруднику, который вошел в кабинет и которому выдана роль trace-viewer. Невошедшего экран отправляет на вход. Вошедшему без роли он отвечает сообщением «Нет права на просмотр трасс». Как выдать роль, описано на странице «Доступ и роли».

Над таблицей стоит форма отбора с полями «с» и «по» (по умолчанию последние сутки), «кто», «инструмент» и «процесс». В таблице по каждому вызову показаны:

• Время вызова.
• Условное обозначение вызвавшего вместо имени. Если вызов сделала служба платформы, рядом стоит пометка «служба».
• Инструмент.
• Процесс и шаг маршрута.
• Длительность в миллисекундах.
• Исход.
• Параметры и результат.
• Ссылка на трассу вызова.

Исход показан как ok, ошибка, исход не записан или отказ с кодом причины. Отказ означает, что платформа не пустила вызов до обращения к системе, например инструмент не объявлен или проверка прав вызов не разрешила. Вызов, который состоялся и завершился сбоем, показан как ошибка. Экран показывает ограниченное число последних записей. Когда записей больше, он пишет «Показаны N последних записей - это не все вызовы интервала». Тогда сузьте интервал или отбор.

Параметры и результат записываются в трассу после маскирования, персональные данные в них заменены метками. Секретные поля из контракта подключения, например ключ доступа, заменяются пометкой еще до маскирования. Если маскирование недоступно, запись о вызове остается, но без параметров и результата. Каждому полю платформа присваивает класс данных по контракту подключения. Поле видно, только если у сотрудника есть право на каждый класс этого поля. Иначе на месте значения стоит пометка «скрыто: нет права на класс» с перечнем недостающих классов. Если у поля класс не объявлен, оно скрыто от всех, какие бы роли ни были выданы, с пометкой «скрыто: класс не объявлен». У вызова без параметров и результата экран пишет «содержимого в записи нет». Если канал записи усек длинное значение, под ним стоит пометка «[усечено каналом: текст неполный]».

Список записей (кто, когда, какой инструмент, исход) видит любой сотрудник с ролью trace-viewer, и разделить его по подразделениям нельзя. Права на классы данных определяют только то, видно ли содержимое. Трассу можно выгрузить файлом только с отдельной ролью trace-exporter, а содержимое вызовов инструментов в таком файле скрыто при любых ролях.

Что платформа делает, если вызов нельзя проверить или записать

• Инструмент, которого нет в реестре, платформа не вызывает.
• Если программа проверки прав (часть платформы) недоступна, платформа не выполняет вызов.
• Если запись в трассу недоступна, платформа все равно выполняет вызов, в том числе вызов инструмента, который меняет данные во внешней системе. Запись о таком вызове теряется, и в журнале вызовов ее не будет. Платформа считает число потерянных записей трассы, но пометки «вызов прошел без записи» не ставит.
• Запрещенный вызов попадает в журнал вызовов вместе с причиной запрета.

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