MCP и A2A стандартизируют разные границы

Прежде чем писать хоть строку кода, стоит развести два протокола по смыслу - потому что дальше вся книга про то, где проходит граница каждого. MCP подключает AI-приложение к возможностям и данным: модель внутри host обнаруживает у сервера tools, resources и prompts и вызывает конкретную возможность. A2A связывает независимые агентные приложения как равноправные сервисы: один агент читает Agent Card другого, согласует форматы данных, отправляет Message и наблюдает жизненный цикл Task до готового Artifact. Разные вопросы, разные единицы контракта - и потому это не выбор "или-или", а два уровня одной архитектуры.

Проще всего увидеть их вместе на сквозном примере книги. Release Coordinator просит Release Review Agent проверить релиз web-portal@2.4.0. Между двумя агентами действует A2A: координатор не знает, как устроен ревьюер, он лишь формулирует цель и ждёт результат. А внутри ревьюера работает MCP-host, который читает runbook, получает снимок CI и вызывает детерминированную проверку через MCP-серверы. Один запрос проходит через обе границы по очереди.

Стрелки читаются слева направо и показывают, как две границы стыкуются в одном сценарии. Снаружи координатор общается с агентом языком A2A - Message заводит Task, статус идёт от submitted к working, в конце появляется Artifact. Внутри, пока Task в состоянии working, тот же агент говорит языком MCP - выполняет discovery доступных возможностей и делает адресные вызовы к серверам. Ни один из уровней не подменяет другой: A2A переносит делегацию, MCP переносит доступ к возможностям.

Если свернуть это в одну фразу, разница запоминается так.

Короткая формула. MCP даёт агенту руки и источники. A2A даёт организации способ передавать работу между самостоятельными агентами.

Именно поэтому выбор нельзя делать по маркетинговому слову. Название "agent" на кнопке или "AI" в описании сервиса ничего не решает - решает характер границы.

Не определяйте выбор по слову "AI". Если удалённый сервис - это обычная детерминированная функция, A2A ему не нужен. Если локальная capability называется "agent", это ещё не делает её A2A-сервисом.

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