Распространённое утверждение и его проблема
Производители агентных платформ обещают «готового enterprise-агента из коробки»: студия для настройки, библиотека коннекторов, встроенные гардрейлы. Подтекст — выбери платформу правильно, и переносимость, безопасность и контроль приложатся автоматически. Это упрощение. Переносимость — не свойство платформы, а свойство архитектуры, которую вы строите поверх платформы. Если границы между слоями проведены небрежно, даже самая «открытая» экосистема незаметно утянет в lock-in бизнес-логику, которая должна была остаться вашей.
Опорная для этого разбора референс-архитектура, которую описывает инженер, последовательно собиравший одного и того же агента для обработки расхождений по счетам на пяти разных платформах, формулирует эту мысль прямо: прежде чем выбирать вендора, нужно нарисовать картинку из пяти слоёв — и только потом смотреть, какая платформа закрывает какие клетки.
Пять слоёв одного запроса
Если читать архитектуру сверху вниз, так же, как движется сам запрос, получается следующая последовательность.
Канал — это место, где работа появляется и где люди реагируют: очередь исключений в AP-отделе, почта, Teams или Slack, инбокс согласующего. Этот слой почти всегда уже существует в компании и целиком зависит от того, какими инструментами коммуникации она пользуется — агент должен встроиться в него, а не заменить.
Агенты — слой, где языковая модель рассуждает, планирует и вызывает инструменты. Здесь у каждой платформы свой рантайм со своим названием, и именно этот слой чаще всего ощущается как «лицо» платформы.
Инструменты — набор чётко описанных функций с одинаковыми входами, выходами и именованными ошибками, которые агент вызывает для выполнения задачи.
Процессные API — бизнес-правила: допуски, проверка дублей, правила проводки и, что важнее всего, проверка одобрения. Это ваш код на той интеграционной платформе, которой компания уже пользуется.
Системы записи — ERP с её счетами, заказами и накладными, мастер поставщиков, движок워크флоу. Они существуют независимо от выбора агентной платформы и должны оставаться скучными и стабильными.
Поверх этих пяти слоёв идут четыре сквозные заботы: gateway с белыми списками инструментов и детекцией персональных данных, идентичность для каждого агента с минимальными привилегиями, наблюдаемость в виде единого трейса через все слои и, отдельно, механизм одобрения человеком.
Что отдать стандарту, что оставить вендору
Главная практическая польза такого разреза — не в красоте схемы, а в том, что он сразу показывает, какие компоненты можно считать переносимым активом компании, а какие неизбежно останутся привязаны к конкретному поставщику.
| Слой / зона | Что происходит | Переносимый элемент | Вендорская часть |
|---|---|---|---|
| Канал | Приём запроса, уведомление человека | Бизнес-процесс и UX взаимодействия | Конкретный мессенджер, очередь, инбокс |
| Агент | Рассуждение модели, выбор действия | Контракты инструментов, agent card | Рантайм, студия, оркестратор конкретной платформы |
| Инструменты | Вызов функций с определёнными входами/выходами | Протокол MCP, спецификация инструмента | Хостинг и реализация MCP-сервера у вендора |
| Процессные API | Бизнес-правила, проверка одобрения | Код правил, approval_id как контракт | — (это ваш код, здесь lock-in минимален) |
| Системы записи | ERP, мастер-данные, workflow-движок | Сами данные и бизнес-смысл | Конкретная ERP-система (но это выбор, сделанный раньше) |
| Сквозное: Gateway, Identity | Allow-листы, минимальные привилегии | Политика least privilege, delegation envelope | Конкретный механизм идентичности (Entra, IAM, платформенный) |
| Сквозное: Observability | Трейс через все слои | Семантика трейсов, OpenTelemetry-конвенции | Дашборды и хранилище трейсов конкретного вендора |
Из таблицы видно закономерность: инвестиции имеет смысл делать в контракты инструментов, agent cards и конвенции трейсинга как в многоразовые активы, а рантайм, реестр агентов, политики gateway, интеграцию идентичности и инструменты оценки — считать заменяемыми. Это не значит, что их выбор неважен — это значит, что их замена не должна требовать переписывания бизнес-логики.
Где на самом деле стоит точка контроля одобрения
Самая частая инженерная ошибка в этой архитектуре — смешивать запрос на одобрение с его исполнением. Запрос на одобрение проходит через workflow-слой, но принуждение к нему должно происходить в процессном API, а не в промпте и не в рантайме агента. Агент может вызвать функцию запроса одобрения, которая создаёт задачу для человека; когда человек соглашается, workflow возвращает идентификатор одобрения, и только после этого функция проводки или уведомления поставщика сработает. Если агент введён в заблуждение странным счётом, пропустил шаг или просто ошибся, проводка завершится ошибкой «одобрение отсутствует» — и никакой промпт это не изменит, потому что проверка находится не в промпте.
Эта деталь не техническая мелочь — это единственное архитектурное решение, которое делает всё остальное безопасным. Из него прямо следует практическое следствие: модель, агента или даже саму платформу можно поменять, не перепроверяя заново сам контроль, потому что контроль не переехал вместе с ними.
Более широкий взгляд на эту проблему дают разборы zero trust для корпоративных агентов: модель никогда не должна сама решать, авторизована ли она — её вывод является запросом на авторизацию, а не самой авторизацией. Агенту нужна отдельная рабочая идентичность, сессионно ограниченное делегирование от человека, и каждое обращение к инструменту должно проходить через точку принудительного применения политики вне модели. Это ровно та же логика, что и approval_id в процессном API: граница безопасности проходит в коде и в процессе, а не в тексте инструкции для модели.
MCP и A2A — не конкуренты, а разные этажи
Здесь стоит явно развести два стандарта, которые в маркетинговых материалах нередко сваливают в одну корзину. MCP описывает вызов инструмента агентом — это уровень «агент-к-инструменту»: модель обращается к функции с определёнными входами и выходами. A2A решает другую задачу — это уровень «агент-к-агенту»: как один агент обнаруживает другого, аутентифицируется перед ним и делегирует ему работу, включая состояния задачи и передачу контекста.
Разница становится не абстрактной, а практической в сценарии, где запрашивающий действие и подтверждающий его — разные идентичности с разными правами. В разборе отката неудачного деплоя через связку двух агентов это показано пошагово: агент мониторинга с правом только на чтение обнаруживает проблему и запрашивает откат, но не может выполнить его сам; агент-«держатель» полномочий получает подписанную карточку агента запрашивающей стороны, переводит задачу в состояние «требуется проверка», дожидается подтверждения — человеческого или политического — и только затем выполняет откат через собственный MCP-вызов. A2A здесь не заменяет MCP, а работает слоем выше него: A2A управляет рукопожатием между двумя агентами, решающими, должен ли вообще произойти вызов, а MCP управляет самим вызовом, когда он уже авторизован.
Отсюда следует практичный критерий: если в системе пока только один агент общается с человеком-подтверждающим через обычный UI, A2A не добавляет ценности — всё покрывает MCP плюс существующий интерфейс. Протокол агент-к-агенту начинает окупаться в тот момент, когда согласующей стороной становится не человек, а отдельный агент-политика, агент-гейткипер или оркестрирующий агент, делегирующий работу специализированному. Пытаться внедрить A2A заранее, «на всякий случай», — это инфраструктура для проблемы координации, которой ещё не существует.
Как читать всё это в терминах потока запроса
Если собрать слои и точку контроля в одну последовательность, получается следующая картина.
flowchart LR
A[Канал: очередь, почта, чат] --> B[Агент: рассуждение, выбор действия]
B --> C[Инструмент через MCP]
C --> D[Процессный API: бизнес-правила]
D --> E{Есть approval_id?}
E -- нет --> F[Запрос одобрения человеку]
F --> D
E -- да --> G[Система записи: ERP]
Ключевая деталь схемы — не линейность, а то, что развилка находится не на уровне агента и не на уровне модели, а внутри процессного API, уже после того, как инструмент был вызван.
Что это значит на практике
Ни один из описанных стандартов нельзя считать полностью зрелым и застывшим во всех реализациях: даже у наблюдаемости через OpenTelemetry семантические конвенции для генеративных сценариев — имена спанов вроде вызова агента или выполнения инструмента — пока находятся в статусе разработки, и атрибуты между релизами могут меняться. Это не повод отказываться от стандартов, но повод не строить на них хрупкие дашборды, которые нельзя будет обновить.
Перенос такой архитектуры между платформами с разной моделью идентичности и разными политиками gateway всё равно потребует заметной инженерной работы — смены интеграций, перенастройки наблюдаемости, повторной проверки политик доступа. Но если контракт инструмента описан через MCP, карточка агента — через A2A, а проверка одобрения живёт в процессном API, а не в промпте, перенос агента между платформами становится работой, а не переписыванием с нуля.
Именно в этом и заключается настоящий вопрос, который стоит задать до выбора вендора: не «какая платформа лучше», а «какие границы ответственности я провожу между тем, что останется моим, и тем, что станет платформенным». Платформа, которая выигрывает в сравнительной таблице функций, но размывает эту границу, в итоге привязывает крепче, чем кажется на демонстрации.
