Используйте A2A для независимого исполнителя
A2A строится на допущении, которое отличает его от всего, что мы делали до сих пор: удалённый агент может быть opaque. Клиент знает объявленные skills, режимы данных и протокольные операции, но не получает его prompt, инструменты, память или внутренний план. Контракт строится вокруг цели и результата, а не вокруг вызова функции.
Чтобы почувствовать разницу, полезно поставить три вещи рядом. RPC-сервис просит "сделай функцию": метод и точная форма результата известны, сервер не выбирает заметный путь. MCP-сервер даёт capability: host сам оркеструет вызовы и обычно владеет model loop. A2A-агент получает "реши задачу": исполнитель сам планирует, может работать долго, запросить ввод и создать несколько artifacts. Это восходящая лестница независимости - и A2A стоит на её вершине.
Поэтому контракт A2A-агента формулируется продуктово, а не технически.
goal: оценить готовность известного release snapshot
input: text/plain message с service@semver
output: text/markdown + application/json
states: submitted → working → completed
interrupt: input_required, если release reference отсутствует
terminal errors: failed, rejected, canceled
internal tools/memory/model: не раскрываются клиентуПочему opaque - это не недостаток, а фича? Потому что команда-владелец агента может менять модель, MCP-серверы, prompts и workflow, сохраняя Agent Card и семантический контракт. Клиент интегрируется с задачей, а не с внутренним tool graph - и потому не ломается при каждом рефакторинге исполнителя. Именно это делает агентов по-настоящему независимыми сервисами.
Opaque не означает неподконтрольный. Нужны identity, authorization, объявленные capabilities, trace context, task retention, SLO и договорённость об artifacts. Скрывается реализация, а не ответственность.
Первое, что публикует такой агент и первое, что читает клиент, - это его Agent Card. С неё и начнём.