MCP vs. A2A: что нужно стандартизировать до подключения AI-агентов

Подключить AI-агента к одной бизнес-системе относительно просто.

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

Одна команда создаёт кастомный коннектор к Salesforce. Другая строит отдельную интеграцию для SharePoint. Вендор развёртывает собственного агента с широким API-доступом. Второй агент начинает делегировать задачи первому. Вскоре никто не может ясно объяснить: какой агент имеет доступ к каким данным; кто авторизовал каждое действие; какая система владеет конечным результатом; как повторяются неудавшиеся задачи; может ли одно и то же действие выполниться дважды; и как можно откатить некорректное изменение.

MCP и A2A решают части этой проблемы.

Но не все её части.

MCP может стандартизировать, как AI-приложение получает доступ к инструментам, ресурсам и повторно используемым промптам. A2A может стандартизировать, как независимые агенты обнаруживают друг друга, делегируют работу, обмениваются информацией и управляют задачами. Ни один из протоколов не определяет ваш бизнес-процесс, политику авторизации, владение данными, правила согласования или модель ответственности.

Протокол - это инфраструктура.

Операционная модель - по-прежнему ваша ответственность.

Используйте два протокола для разных отношений:

Официальная архитектура MCP определяет хосты, клиенты и серверы, где серверы предоставляют инструменты, ресурсы и промпты через общий протокол. A2A предназначен для сотрудничества между независимыми и потенциально непрозрачными агентами без требования раскрывать их внутреннюю память, реализацию или инструменты. (Model Context Protocol)

Они дополняют друг друга:

MCP оснащает агента. A2A подключает этого агента к другим агентам.

Но стандартизация коммуникации не делает подключённую систему корректной, безопасной или экономически обоснованной.

Что на самом деле меняет MCP

До MCP каждому AI-приложению обычно требовалась кастомная интеграция для каждой внешней возможности: один коннектор для CRM; другой для репозитория документов; другой для базы данных; другой для внутреннего сервиса; и ещё один для тикет-системы.

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

MCP вводит общий протокол, через который сервер может предоставить три основные категории: Инструменты - исполняемые операции; Ресурсы - контекстные данные, которые приложение может читать; и Промпты - повторно используемые шаблоны взаимодействия.

Это может сократить объём интеграционного кода, специфичного для приложения, и упростить обнаружение и повторное использование возможностей. Протокол, однако, явно фокусируется на обмене контекстом и доступе к возможностям; он не определяет бизнес-логику AI-приложения или то, как приложение должно управлять этими возможностями. (Model Context Protocol)

На практике

Агент по операциям с выручкой может использовать отдельные MCP-серверы для поиска аккаунтов в CRM; чтения утверждённой документации по продажам; получения правил ценообразования; создания черновика задачи; и запроса обновления pipeline.

Агенту не нужен уникальный дизайн интеграции для каждой возможности. Он взаимодействует через общий интерфейс.

Это ценно.

Но это создаёт новый вопрос:

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

MCP стандартизирует подключение. Он не определяет модель разрешений.

Что на самом деле меняет A2A

A2A решает другую проблему.

У предприятия может быть несколько специализированных агентов: агент по исследованию продаж; агент по ценообразованию; агент по проверке соответствия; агент по поддержке клиентов; и агент по управлению проектами.

Эти агенты могут быть созданы разными командами, использовать разные фреймворки или работать на разных вендорских платформах.

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

Протокол разработан так, чтобы агент мог сотрудничать, не раскрывая свои внутренние рассуждения, память или детали реализации. (A2A Protocol)

На практике

Агент по продажам получает запрос:

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

Агент по продажам может использовать MCP для получения аккаунта и возможности из CRM; делегировать проверку ценообразования агенту по ценам через A2A; получить структурированный артефакт ценообразования; делегировать проверку политик другому агенту; объединить утверждённые результаты; подготовить черновик предложения; и запросить согласование человека перед любой внешней коммуникацией.

Здесь MCP и A2A решают разные слои интеграции.

User or business event
        ↓
Orchestrating agent
        ├── MCP → CRM tools and data
        ├── MCP → document repository
        ├── A2A → pricing agent
        │           └── MCP → pricing system
        └── A2A → policy-review agent
                    └── MCP → approved policy sources

Архитектура интероперабельна.

Но она ещё не управляема.

Что протоколы оставляют нерешённым

Большинство планов внедрения упускают это различие.

MCP и A2A не определяют автоматически следующее.

Бизнес-смысл

Инструмент может предоставить операцию с именем:

update_opportunity_stage

Протокол не определяет: что означает каждая стадия pipeline; документированы ли критерии входа и выхода; кто владеет возможностью; является ли изменение финансово значимым; и должен ли менеджер его утвердить.

A standardized tool can still execute a poorly defined business process. The distinction between AI agents and automation matters here: the more autonomy a system has, the more clearly the underlying process must be defined before any protocol connects it to production data.

Подотчётность

Если Агент A делегирует работу Агенту B, кто отвечает за некорректный результат?

Возможные ответы включают бизнес-владельца Агента A; продуктового владельца Агента B; команду платформы; сотрудника, инициировавшего задачу; и вендора, управляющего удалённым агентом.

Протокол транспортирует задачу. Он не назначает управленческую ответственность.

Корпоративная идентификация

Аутентификация доказывает, что система или пользователь предоставили валидную идентификацию.

Авторизация определяет, что эта идентификация может делать.

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

Удалённый агент не должен наследовать широкие привилегии только потому, что с ним связался доверенный оркестратор.

Политика согласования

Протокол может передавать запрос на согласование.

Он не может определить, какие действия должны требовать согласования.

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

Качество данных

MCP может упростить доступ к неточным данным CRM.

A2A может упростить распространение итоговой ошибки несколькими агентами.

Ни один из протоколов не решает: дублирование записей; конфликтующие политики; устаревшие документы; отсутствие ответственных; неопределённые метрики; и некорректные правила источника истины.

Ожидания уровня сервиса

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

Юнит-экономика

Интероперабельность может увеличить число взаимодействий агентов.

Один бизнес-запрос может вызвать: несколько вызовов модели; множественные операции извлечения; задачи удалённых агентов; повторные попытки; вызовы валидации; и человеческую проверку.

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

Что предприятию всё ещё нужно стандартизировать

Перед подключением продакшен-агентов определите архитектуру по восьми слоям.

Skipping the upper layers and starting with servers, SDKs, and protocols creates integration without control. Our guide to evaluating an AI agent before production provides a structured approach to building the evidence and acceptance criteria that should exist before any agent architecture goes live.

Безопасность MCP: инструмент - часть границы доверия

MCP-сервер - не просто нейтральный коннектор.

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

Текущие рекомендации OWASP по безопасности MCP включают: доступ с минимальными привилегиями; раздельные и ограниченные учётные данные; валидацию входов и выходов инструментов; изоляцию серверов; подтверждение деструктивных или чувствительных действий; централизованное логирование; проверку источников и зависимостей серверов; и защиту от изменений определений инструментов. (OWASP Cheat Sheet Series)

Рискованный дизайн

Один MCP-сервер получает: полное администрирование CRM; доступ к общему диску; разрешение на отправку писем; учётные данные биллинга; и неограниченный сетевой доступ.

Затем агенту через промпт говорят "использовать это ответственно".

Промпт выступает основной границей безопасности.

Этого недостаточно.

Более безопасный дизайн

Возможности разделены: crm.read_account; crm.create_update_draft; crm.apply_approved_update; email.create_draft; email.send_approved_draft; и billing.read_invoice_status.

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

Модели разрешено выбирать среди безопасных возможностей.

Ей не даётся неограниченная власть с просьбой саморегулироваться.

Безопасность A2A: делегирование не должно расширять полномочия

Мультиагентная архитектура вводит транзитивность доверия.

Агенту A разрешено выполнять задачу.

Агент A вызывает Агента B.

Агент B вызывает инструмент или другого агента.

Распространённое, но опасное допущение:

Раз Агенту A доверяют, всему, что он делегирует, тоже следует доверять.

Это может расширить привилегии за пределы полномочий исходного пользователя.

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

Каждый нижестоящий участник должен оставаться внутри исходной границы доверия.

Предотвращение дублирующего и необратимого выполнения

Агентские системы часто работают через асинхронную инфраструктуру.

Сообщения могут повторяться. Соединения могут обрываться после успешного выполнения операции. Клиент может не знать, завершилось ли удалённое действие.

Это создаёт критическую проблему:

Повторная попытка задачи может повторить бизнес-действие.

Для операций чтения это может быть безвредно.

Для возвратов, заказов, сообщений клиентам, изменений доступа или обновлений CRM это может создать существенный инцидент.

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

Статус "агент завершил" недостаточен.

Система должна знать, какая бизнес-операция завершена.

API, webhook, MCP или A2A?

Не каждая интеграция должна использовать новейший протокол.

Практическое правило

Используйте наименее сложную архитектуру, удовлетворяющую требованиям.

Webhook не устарел, потому что существует MCP.

Прямой API не уступает, потому что существует A2A.

Второй агент не должен создаваться лишь для того, чтобы система выглядела более агентной.

Чек-лист корпоративного внедрения

Перед разрешением трафика MCP или A2A в продакшене подтвердите:

К чему сводится решение

Стратегический вопрос шире, чем:

Стоит ли нам внедрить MCP или A2A?

Лучшая последовательность: какой бизнес-процесс мы меняем? Требует ли он доступа агента к инструментам, сотрудничества с другими агентами или и то, и другое? Какова минимальная архитектура, способная это решить? Какие границы доверия архитектура пересечёт? Какие контроли остаются за пределами протокола? Как компания докажет, что новый дизайн безопаснее или экономичнее текущего процесса?

MCP и A2A могут снизить непоследовательность интеграций.

Они также могут упростить подключение неясного процесса к большему числу систем с большей скоростью.

Стандартизируйте процесс, ответственность, идентификацию, разрешения, согласования и модель аудита до стандартизации коммуникационного слоя.

Fill System Консалтинг по AI и автоматизации процессов охватывает проектирование архитектуры агентов - от картирования процессов и границ доверия до идентификации, разрешений и продакшен-контролей - до подключения протоколов к рабочим системам.

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