Mistral открыла Managed Agents для фоновых задач

Mistral 5 ноября представила Managed Agents в публичном предварительном доступе. Разработчик описывает модель, инструкции и инструменты агента на Python, затем выбирает, где выполняется его код. При развёртывании в Studio задача может продолжаться в фоне, переживать остановку процесса клиента и приостанавливаться, пока человек подтверждает действие. Журнал релизов Mistral от 5 ноября.

Как устроено выполнение

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

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

Три способа запуска одного агента

Выбор места запуска влияет на то, к каким ресурсам сможет обратиться код инструмента. Свой исполнитель полезен, когда инструмент должен работать рядом с внутренним сервисом. В этом режиме облачный слой Mistral по-прежнему хранит сессии и обслуживает вызовы модели. Для управляемого варианта документация описывает сборку проекта из Git. Режимы запуска.

Как работает пауза для человека

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

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

По текущей документации подтверждение ожидается один час. Если ответа нет, вызов пропускается, а модель получает результат о том, что согласование не состоялось. У развёрнутой сессии есть отдельные пределы времени: по умолчанию 24 часа от первого запуска и четыре часа простоя. Если задача требует ответа на следующий рабочий день, учитывайте отдельно окно согласования и срок жизни сессии. Подтверждения · Сроки жизни сессии.

Что означает восстановление после сбоя

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

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

Что разработчик увидит в Studio

В журнале релизов от 5 ноября отдельно описана трассировка. Развёрнутый агент отправляет в Studio сведения о шагах агента, запросах к модели и вызовах инструментов. Mistral указывает, что данные проходят фильтрацию на исполнителе перед отправкой. Отдельную запись трассировки можно перенести в набор данных для оценки. Описание трассировки Managed Agents.

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

Где применить Managed Agents

Подход подходит для задач, где модель выбирает следующий шаг, а выполнение дольше одного HTTP-запроса. Например, агент может собрать материалы, обнаружить пробелы, запросить уточнение и завершить отчёт после ответа. Для заранее заданной последовательности с фиксированными переходами Mistral предлагает Workflows. Для одного запроса к модели подойдёт обычный Chat Completions API. Сценарии применения в документации Mistral.

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