Обновление контрольных точек рабочего процесса Python до версии 1.13.0

Agent Framework 1.13.0 содержит незначительные критические изменения в Python выполнении рабочего процесса. Большинство приложений не требуют изменений. Изменения влияют на приложения, зависящие от точных чисел суперстепов или итерации, заданных max_iterations на границе конвергенции, проверки исходного идентификатора источника сообщения или допущения о размещении контрольных точек и заказе.

Основные сведения

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

Изменения в поведении

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

Important

Эти изменения не влияют на контрольные точки, созданные до версии 1.13.0. Существующие контрольные точки остаются поддерживаемыми и по-прежнему могут быть восстановлены после обновления.

Изменения, которые могут потребовать действия

Area	До 1.13.0	В версии 1.13.0 и более поздних версий	Влияние на пользователей
Запуск исполнителя	Начальный исполнитель выполнялся перед циклом суперстепа.	Входные данные помещается в очередь для начального исполнителя, который выполняется в первом суперстепе.	Каждый свежий запуск выдает один дополнительный superstep_started и superstep_completed событие.
Число итераций	Итерация 1 представляла первый суперстеп после запуска исполнителя.	Итерация 1 запускает начальный исполнитель. Позже рабочие сдвиги по одной итерации.	Рабочий процесс, который ранее требовал $N$ итерации, теперь требуется $N + 1$.
Источник входного сообщения	Первоначальное сообщение было идентификатором исходного кода "Workflow"жесткого кода.	Начальное сообщение доставляется через внутренний край начального исполнителя и имеет идентификатор INTERNAL_SOURCE_ID(start_executor.id)источника.	Код, который считывает или фильтрует исходный идентификатор источника сообщения, должен использовать новое значение.

Улучшения воспроизведения

Area	До 1.13.0	В версии 1.13.0 и более поздних версий	Улучшение
Начальная контрольная точка	Контрольная точка итерации-0 была создана после запуска исполнителя. Он захватывал выходные сообщения исполнителя и обновлял состояние, но не исходные входные данные.	Контрольная точка входа создается перед superstep 1. Он записывает исходные входные данные в очередь для начального исполнителя.	Восстановление контрольной точки записи воспроизводит полный запуск, включая исполнителя запуска.
Контрольная точка ответа	Ответ на событие запроса был доставлен без записи в контрольной точке.	Контрольная точка входа ответа создается после доставки ответа и перед выполнением его суперстеп.	Восстановление контрольной точки ввода ответа воспроизводит продолжение, которое использует ответ.

Обновление обработки событий superstep

Теперь новый рабочий процесс создает еще одну пару событий суперстепа, так как начальный исполнитель выполняется в superstep 1:

• superstep_started С iteration == 1
• superstep_completed С iteration == 1

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

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

Проверьте максимальное ограничение итерации

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

from agent_framework import WorkflowBuilder

workflow = WorkflowBuilder(
    start_executor=start_executor,
    max_iterations=previous_max_iterations + 1,
).build()

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

Обновление проверок источника исходного сообщения

Если начальный исполнитель использует исходный идентификатор исходного сообщения, замените жестко закодированное "Workflow" значение исходным идентификатором внутреннего края исполнителя.

До 1.13.0:

is_workflow_input = ctx.source_executor_ids != ["Workflow"]

В версии 1.13.0 и более поздних версий:

from agent_framework import INTERNAL_SOURCE_ID

is_workflow_input = ctx.source_executor_ids != [INTERNAL_SOURCE_ID(self.id)]

INTERNAL_SOURCE_ID(executor_id) в настоящее время возвращается "internal:<executor_id>". Используйте вспомогательный элемент вместо создания этой строки, чтобы код следует формату исходного идентификатора платформы.

Обновление обработки контрольных точек

Начальные входные контрольные точки

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

После каждого завершения замены платформа продолжает создавать контрольную точку. Для выполнения с $N$ supersteps, ожидайте $N + 1$ контрольных точек: контрольная точка входа, за которой следует одна контрольная точка для каждого завершенного суперстепа.

Проверьте код, предполагающий, что контрольная точка итерации-0 содержит состояние, созданное начальным исполнителем. Это состояние теперь отображается в контрольной точке, созданной после superstep 1.

Контрольные точки ответа запроса

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

Контрольная точка ввода ответа совпадает iteration_count с предыдущей контрольной точкой, содержащей ожидающий запрос. Это отдельная контрольная точка, previous_checkpoint_id которая указывает на то, что контрольная точка ожидания запроса.

Important

Не гарантируется, что он iteration_count будет уникальным в журнале контрольных точек для человека в цикле. Выполните цепочку previous_checkpoint_id , чтобы определить порядок контрольных точек. Если вам нужна последняя контрольная точка, используйте API хранилища контрольных точек вместо выбора самого большого iteration_count.

Контрольный список миграции

• Обновите утверждения и потребители событий, которые зависят от точных счетчиков суперстеп или итерации.
• Увеличьте max_iterations только один для рабочих процессов, которые достигли предыдущего ограничения.
• Замените начальные проверки "Workflow" исходного идентификатора INTERNAL_SOURCE_ID(start_executor.id)на .
• Итерация-0 рассматривается как контрольная точка перед выполнением входной точки.
• Упорядочить контрольные точки в цикле по происхождению, а не предполагать iteration_count уникальность.
• Убедитесь, что повторная запись и контрольная точка ответа создают ожидаемые выходные данные и побочные эффекты.

Сведения о реализации см. в разделе "Разрешить полную воспроизведение контрольных точек рабочего процесса".