Сначала выберите минимальный контракт

Раз MCP и A2A закрывают разные границы, первый инженерный вопрос - не "какой протокол взять", а "какой самый маленький контракт сохранит нужную мне независимость". Прямой API, MCP и A2A стоят на разных ступенях цены и гибкости, и переплата здесь так же вредна, как недоделка: лишний протокол добавляет discovery, версионирование и поверхность атаки, которые придётся обслуживать.

Ориентироваться удобно по характеру задачи. Прямой API уместен, когда сервис известен и вы контролируете обе стороны: контракт стабилен, discovery не нужен, обычный REST, gRPC или вызов библиотеки проще и надёжнее. MCP нужен там, где AI-host должен обнаружить и безопасно использовать инструменты, ресурсы и шаблоны от разных поставщиков, которые вы не писали. A2A появляется, когда удалённая сторона сама планирует длительную работу, может запросить дополнительный ввод и возвращает artifacts - то есть когда вы отдаёте не вызов, а цель.

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

Сигнал · Direct API · MCP · A2A

• Единица контракта - Endpoint или функция; Tool, resource, prompt; Message, task, artifact
• Discovery - OpenAPI/документация; */list; Agent Card
• Долгая работа - Проектируете сами; Обычно request; tasks доступны расширением; Базовая модель протокола
• Внутренности исполнителя - Часто известны; Capability скрывает реализацию; Agent намеренно opaque
• Типичный риск - Самописная несовместимость; Слишком мощный tool; Неуправляемая делегация

Каждая строка таблицы - это не абстракция, а вопрос, который стоит задать про конкретную интеграцию. Единица контракта показывает, чем вы обмениваетесь: функцией, capability или задачей. Discovery - как другая сторона узнаёт, что вы умеете. Модель долгой работы - кто отвечает за состояние, если ответ не мгновенный. А колонка риска напоминает, что у каждого уровня своя типичная ошибка: у прямого API - самописная несовместимость, у MCP - слишком мощный tool, у A2A - неуправляемая делегация.

Чтобы прочувствовать выбор на своих вводных, прогоните задачу через конструктор - он спросит про сторону, discovery и длительность и подскажет минимальный уместный контракт.

И короткий тест, который почти всегда расставляет всё по местам.

Практический эвристический тест. Если вы хотите назвать удалённую функцию, её аргументы и результат - смотрите в сторону MCP или обычного API. Если вы формулируете цель и принимаете независимый ход работы - смотрите в сторону A2A.

Выбрали контракт - дальше начинается реализация. И начнём мы её не с SDK, а с того, что реально идёт по проводу: с самого сообщения.