Оркестрация ИИ-агентов: работа вне чата

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

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

Моя позиция: у повторяющейся работы должен быть жизненный цикл с понятным пользователю состоянием.

Что такое оркестрация ИИ-агентов?

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

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

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

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

Почему ИИ-агенты выходят за пределы чата?

Два сентябрьских анонса показывают, куда движется отрасль. 10 сентября 2026 года Atlassian описала циклы работы агентов в Jira: они находят подходящие задачи, передают их на выполнение и открывают pull request для проверки. Циклы были доступны в закрытом раннем доступе, а не всем пользователям. Решение о выпуске остаётся у человека. Анонс Atlassian

24 сентября LangChain выпустила LangSmith Trajectories, хронологическое представление сообщений и действий в сеансе агента. Оно помогает проверяющему прочитать ход работы, которая занимает несколько обменов сообщениями и вызовов инструментов. Анонс LangChain

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

Как ИИ-процесс по расписанию выбирает правильный период?

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

Представь закрытие месяца с запуском 3 октября. Проверять нужно период с 1 по 30 сентября. Даже аккуратная проверка первых дней октября отвечала бы на другой вопрос. Поэтому наши процессы закрытия и сверки по расписанию закрепляют за запуском предыдущий календарный месяц.

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

Пользователь явно включает расписание. Карточка показывает следующий запуск и позволяет изменить или остановить расписание. Доступ к этой возможности зависит от тарифа. Старый процесс, который ждёт человека, нельзя считать успешным запуском нового периода. Эту разницу сохраняет оркестрация; модели не приходится угадывать её по истории разговора.

Что должно происходить, когда ИИ-агенту нужен ответ?

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

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

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

Мы также завершаем определённые проверочные шаги, если за период в Norman не поступили транзакции, выставленные счета или входящие документы. В снимке уже было несколько шагов с таким результатом. Это означает отсутствие доступных для проверки записей, а не отсутствие деятельности у бизнеса. Например, всё ещё может требоваться подключение банка. Более общую разницу между ожиданием и ошибкой разбирает статья о долгоживущих ИИ-агентах.

Как должен восстанавливаться прерванный ИИ-процесс?

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

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

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

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

Как понять, что агент выполнил?

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

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

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

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

Что проверить перед делегированием повторяющейся работы?

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

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

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

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