Практика. MCP для инструментов, A2A для агентов¶

Очень многие команды слишком рано смешивают две разные задачи:

• как подключать инструменты и внешние системы;
• как организовывать взаимодействие между несколькими агентами.

Из-за этого MCP и A2A начинают восприниматься как взаимозаменяемые штуки. На деле это разные уровни архитектуры.

1. Короткое правило¶

Если совсем коротко:

• MCP нужен, когда агенту надо работать с инструментами, ресурсами и адаптерами;
• A2A нужен, когда нескольким агентам надо обмениваться задачами, контекстом и результатами.

То есть один протокол отвечает в первую очередь за работу агента с инструментами, а другой за взаимодействие между агентами.¹²

2. Когда тебе почти точно нужен MCP¶

MCP полезен, если у тебя есть одна или несколько внешних возможностей, которые нужно подключать системно:

• поиск по документам;
• CRM;
• helpdesk;
• внутренние API;
• файловые ресурсы;
• базы знаний;
• песочница выполнения.

В такой ситуации главная задача не “построить общество агентов”, а:

• стандартизировать контракты возможностей;
• отделить адаптеры от ядра среды исполнения;
• упростить проверки политик;
• централизовать журналирование, авторизацию и изоляцию.

Именно здесь MCP ложится естественно.

3. Когда тебе действительно нужен A2A¶

A2A имеет смысл, когда у тебя уже есть не просто набор инструментов, а реально разные агенты с отдельной ответственностью:

• координатор;
• исследователь;
• аналитик;
• исполнитель;
• агент доменной области.

И они должны:

• передавать друг другу задачи;
• делегировать выполнение;
• обмениваться статусом;
• возвращать результат не как результат вызова инструмента, а как результат работы другого агента.

То есть A2A появляется не там, где нужен “еще один адаптер”, а там, где в системе уже есть отдельные границы агентных ролей.

3.1. A2A требует управления, а не только протокола передачи управления¶

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

Минимальный контракт управления для A2A должен фиксировать:

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

Хорошая проверка звучит просто: если после инцидента нельзя восстановить, какой агент кому делегировал задачу, по какой политике и с какой областью действия, A2A-контур еще не готов к рабочей эксплуатации.

Расширенный контракт доверия для передачи управления A2A должен быть еще конкретнее:

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

Такой контракт делает A2A не просто транспортом между агентами, а управляемым графом взаимодействия. Без него многоагентная система выглядит распределенной, но расследуется как черный ящик.

Проверяемый артефакт доверия и делегирования для A2A может выглядеть так:

a2a_trust_delegation:
  remote_agent_id: incident.coordinator.v2
  remote_agent_owner: sre-platform
  trust_tier: constrained_internal
  allowed_tasks:
    - collect_incident_context
    - draft_status_update
  forbidden_tasks:
    - customer_notification_without_approval
    - production_change_without_gate
  delegation_depth: 1
  context_sharing_policy: minimal_relevant_context_only
  memory_sharing_policy: no_profile_memory_write
  tool_access_via_remote_agent: incident_read_tools_only
  approval_propagation: original_approval_constraints_apply
  audit_correlation_id: trace_id:a2a_handoff_id
  failure_attribution: initiator_executor_policy_tool_external
  revocation_policy: revoke_on_policy_drift_or_owner_change

Такой артефакт нужно проверять против конкретных режимов отказа A2A: отмывания делегирования, чрезмерного раскрытия контекста, подмены удаленного агента, неограниченных цепочек делегирования, конфликтующих действий, потери подотчетности и межагентного внедрения инструкций.

4. Типовая ошибка: строить многоагентную систему слишком рано¶

На практике путаница обычно выглядит так:

1. У команды есть одна среда выполнения.
2. К нему надо подключить три системы.
3. Вместо контрактов возможностей команда начинает проектировать многоагентную оркестрацию.

Это почти всегда лишняя сложность.

Если в системе пока нет реальных причин для разделения ответственности между агентами, то:

• инструменты лучше подключать через MCP;
• оркестрацию лучше держать внутри одной среды выполнения;
• многоагентную координацию лучше не тащить раньше времени.

Хорошее практическое правило: если сущность не принимает собственных решений и не несет собственной операционной роли, это, скорее всего, еще не агент, а возможность.

4.1. Исследования многоагентной надежности пока скорее усиливают скепсис¶

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

Поэтому практический вывод здесь такой:

• исследования не говорят “строить больше агентов”;
• исследования говорят “если уже строишь многоагентную систему, то делай контракты, циклы проверки и диагностируемые передачи управления”;
• рабочее правило все еще остается таким: сначала одноагентная схема.

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

4.2. Согласие нескольких агентов не равно независимой проверке¶

Даже если несколько агентов пришли к похожему выводу, это еще не доказывает, что система получила независимый сигнал проверки.

Проблемы здесь типовые:

• агенты видят один и тот же загрязненный контекст;
• траектории рассуждения слишком похожи;
• агент-координатор подталкивает нижестоящих агентов к ожидаемому ответу;
• согласие выглядит убедительно, но опирается на одно и то же неверное допущение.

Поэтому согласие нескольких агентов полезно трактовать как сигнал, а не как доказательство корректности.

5. Таблица решений¶

6. Как это выглядит в зрелой архитектуре¶

В зрелой платформе эти вещи обычно не конкурируют, а живут на разных слоях.

flowchart LR
    A["Координирующий агент"] --> B["Передача управления A2A"]
    B --> C["Специализированный агент"]
    A --> D["MCP-клиент"]
    C --> E["MCP-клиент"]
    D --> F["Сервер инструментов / ресурсов"]
    E --> G["Сервер инструментов / ресурсов"]

Нормальная логика такая:

• Агент работает с инструментами через MCP;
• агент работает с другим агентом через A2A;
• политики и аудит должны покрывать оба направления.

7. Когда A2A лучше не использовать¶

Есть несколько красных флагов:

• ты хочешь использовать второй агент просто как “обертку над API”;
• второй агент не имеет собственного контура политик;
• у него нет отдельной операционной идентичности;
• его проще описать как контракт возможностей;
• параллелизм и специализация не дают явной пользы.

Во всех этих случаях лучше остаться на MCP или даже на обычном слое шлюза и адаптеров.

8. Минимальный кодовый эскиз¶

Ниже очень короткий набросок, который показывает различие мышления:

def call_tool_via_mcp(tool_name: str, payload: dict) -> dict:
    return {"kind": "tool_result", "tool": tool_name, "payload": payload}


def delegate_via_a2a(agent_name: str, task: dict) -> dict:
    return {"kind": "agent_result", "agent": agent_name, "task": task}

Смысл тут не в коде как таковом, а в типе взаимодействия:

• вызов инструмента возвращает результат возможности;
• передача управления A2A возвращает результат работы другого агента.

Это разные правила работы, и их полезно не смешивать.

9. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

• Мне нужен новый агент или просто новая возможность?
• У сущности есть собственная роль, контур политик и жизненный цикл?
• Это проблема делегирования или интеграции?
• Могу ли я объяснить, почему здесь недостаточно MCP?
• Не строю ли я многоагентную топологию раньше, чем мне это реально нужно?

Если на эти вопросы трудно ответить, почти всегда безопаснее сначала выбрать MCP, а не A2A.

10. Что делать дальше¶

• Часть IV. Инструменты и выполнение
• Глава 9. Песочница выполнения и MCP как интеграционный контракт
• Глава 10. Идемпотентность, повторы, лимиты запросов и границы отката
• Исследовательский фронтир: память, наблюдаемость и надежность многоагентных систем
• Источники