A2A Task Lifecycle

Словарь протокола

Четыре объекта, из которых собирается любое взаимодействие:

• Task — единица работы с уникальным ID. То, что один агент поручает другому. Хранит своё состояние.
• Message — одно сообщение в диалоге между клиентом и исполнителем. Имеет роль (user или agent) и состоит из частей.
• Part — наименьшая единица контента: TextPart, FilePart (байты или ссылка), DataPart (структурные данные, например формы).
• Artifact — результат задачи, собранный из частей. Неизменяемый: после создания не редактируется. Одна задача может вернуть несколько артефактов, а при стриминге части дописываются по мере готовности.

Разделение на Message и Artifact важнее, чем кажется: переписка и результат живут отдельно, поэтому результат можно забрать и передать дальше, не таща за собой всю историю диалога.

Состояния задачи

Отличие rejected от failed — не формальность. Первое означает, что исполнитель посмотрел на задачу и сказал «это не ко мне», второе — что взялся и сломался. Реакция клиента разная: в первом случае искать другого исполнителя, во втором ретраить или эскалировать.

Состояние input-required превращает протокол из «выстрелил и жди» в переговорный: многошаговое взаимодействие с уточнениями укладывается в одну задачу, а не в цепочку из нескольких.

Рядом стоит auth-required — механизм In-Task Authorization (§7.6). Исполнитель, упёршийся в нехватку прав, не падает с ошибкой, а перекладывает получение авторизации на клиента и ждёт. Практически это значит, что запрос доступа к чужой системе — штатная ветка сценария, а не сбой. В материалах до версии 1.0 этого состояния нет, поэтому в старых разборах перечисляют семь состояний вместо восьми.

Как приходят обновления

Два механизма, и выбор между ними — архитектурное решение:

• Streaming (SSE) — исполнитель шлёт события по мере продвижения: обновления статуса и дописываемые части артефакта. Клиент подписывается методом SendStreamingMessage (REST-биндинг POST /message:stream) и не опрашивает сервер. Имя tasks/sendSubscribe из ранних версий устарело: в 1.0 операции переименованы в SendMessage и SendStreamingMessage.
• Push-уведомления — исполнитель сам стучится на вебхук клиента. Годится, когда задача долгая и держать соединение бессмысленно.

Транспорт под этим — JSON-RPC 2.0 поверх обычного HTTP, то есть ничего экзотического: метод, параметры, идентификатор для корреляции.

Чем это похоже на чекпоинты

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

Связано с

• Agent2Agent Protocol — протокол целиком
• Agent Card — как выбирается исполнитель до постановки задачи
• LangGraph Checkpointers — аналогия между статусами задачи и чекпоинтами графа
• Human in the Loop — состояние input-required как штатная точка входа человека

Открытые вопросы

• кто хранит лог задач при долгих взаимодействиях и как долго — протокол оставляет это на договорённость сторон
• что считать корректной реакцией на failed у чужого агента: ретрай, смена исполнителя или эскалация
• сколько держать задачу в auth-required, если клиент не приносит авторизацию — тайм-аут или бессрочное ожидание