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

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

Инженерные усилия сместились от размера самих моделей к проектированию протоколов. Три спецификации направлены на решение проблемы взаимосвязи: MCP (Протокол контекста модели), A2A (От агента к агенту) и ACP (Протокол коммуникации агентов). Вместе они определяют, как модель получает доступ к инструментам, как один агент взаимодействует с другим и сколько агентов могут совместно выполнять задачи, не впадая в хаос.

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

Почему простой модели нужны протоколы

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

В первых решениях модели подключались непосредственно к REST-API с помощью отдельных коннекторов. Для ассистента по борьбе с мошенничеством требовался специальный код для API основного банковского обслуживания, ещё больше кода — для CRM, и ещё больше — для систем управления делами. Небольшие проекты справлялись с этим. Однако более крупные сталкивались с тремя проблемами:

• Ничто не могло быть использовано повторно. Инструмент для взаимодействия с банковскими системами у команды по борьбе с мошенничеством был бесполезен для команды, занимающейся кредитами, хотя обеим группам требовались одинаковые данные транзакций, поэтому каждый проект приходилось начинать с нуля.
• Состояние терялось между запросами. API по своей конструкции являются безсостоянийными. Аналитик, который сначала получил данные транзакций клиента, а затем спросил о чем-то необычном в этих данных, обнаружил, что простая интеграция с API не сохраняет связи между двумя запросами, если только инженеры не создадут ручной слой памяти.
• Разрешения добавлялись в спешке. Каждая банковская операция требует проверки разрешений и создания записи для аудиторов. Младший аналитик по борьбе с мошенничеством может просматривать историю транзакций, но не может утвердить отмену перевода. Индивидуальная настройка каждого API затрудняла соблюдение таких тонких правил и усложняла их демонстрацию аудитору.

Протокол однократно регулирует исполнение контракта. Банкам не нужно создавать собственные методы для вызова механизма обнаружения мошенничества, поскольку MCP предоставляет единый интерфейс. Командам также не требуется разрабатывать собственные способы передачи дел от агента по борьбе с мошенничеством агенту по соблюдению правил, поскольку A2A предоставляет другой механизм. HTTP сделал это для сетевых приложений, а SQL — для баз данных: единый общий язык, позволяющий независимо созданным системам взаимодействовать друг с другом.

Пять этапов проектирования

Проектирование систем прошло пять этапов как в банковской сфере, так и в других областях.

1. Простой LLM. Модель отвечает исключительно на основе данных обучения. Она может объяснить, что такое KYC, но не может сказать, соответствует ли профиль конкретного клиента правилам KYC банка, поскольку никогда не видит записи этого клиента.
2. Генерация с использованием дополнительных данных. Модель подключается к хранилищу документов, такому как руководство по соблюдению норм и предыдущие регуляторные рекомендации, благодаря чему ответы основаны на актуальном, закрытом контенте, специфичном для организации, а не на общих знаниях, полученных в процессе обучения.
3. Агенты. Модель может не только извлекать информацию, но и выполнять действия. Теперь ассистент по вопросам соблюдения норм может цитировать правила KYC и проверять соответствие документов клиента этим правилам, выявляя любые несоответствия.
4. Многопроцессные системы. Когда один агент одновременно занимается обнаружением мошенничества, оценкой кредитоспособности и общением с клиентами, он становится ненадежным и трудным в управлении. Работа распределяется между специалистами — агентом по борьбе с мошенничеством, агентом по кредитованию и агентом по общению с клиентами, каждый из которых является экспертом в своей узкой области.
5. Протоколы. Когда появляется множество агентов и систем, возникает необходимость в стандартном способе их взаимного обнаружения, обмена контекстом и безопасной коммуникации. MCP, A2A и ACP отвечают на эту потребность.

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

Вызов инструментов — слой, лежащий в основе MCP

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

Механизм довольно прост. Для каждого доступного инструмента разработчик создаёт JSON Schema с именем, описанием и параметрами определённого типа, после чего отправляет его в модель вместе с запросом. Когда модель приходит к выводу, что требуется инструмент, она ничего не выполняет. Её выводом является структурированный JSON-объект с именем инструмента и аргументами, после чего приложение, обрабатывающее запрос, выполняет соответствующую функцию и возвращает результат модели. Схема для банковских операций выглядит следующим образом:

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

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

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

МCP подробнее

MCP появился от компании Anthropic в конце 2024 года как открытый стандарт для связи ИИ-приложений с внешними системами. Можно представить себе универсальный адаптер. Ранее для подключения банковского ассистента к основной банковской системе, модулю обнаружения мошенничества и CRM требовалось три несовместимых интеграционных решения. Теперь любой клиент, соответствующий стандарту MCP, может взаимодействовать с любым сервером, соответствующим этому стандарту, так же как любое USB-устройство подходит к любому USB-порту.

Арифметика M умноженное на N

Основная проблема носит комбинаторный характер. Подключение M инструментов к N приложениям приводит к формированию матрицы, которая становится неконтролируемой по мере увеличения обоих показателей. Банку с пятью внутренними системами и четырьмя ассистентами (для борьбы с мошенничеством, кредитования, обслуживания клиентов и соблюдения нормативов) потребовалось бы до двадцати специальных соединителей. Стандартный протокол сокращает это количество до пяти плюс четыре, поскольку каждая система и каждый ассистент реализуют стандарт MCP лишь один раз.

Три роли

• Хост: приложение ИИ, которое фактически видит пользователь, например интерфейс помощника аналитика по борьбе с мошенничеством.
• Клиент: компонент внутри хоста, который управляет одним подключением к серверу MCP и обрабатывает коммуникацию на уровне протокола.
• Сервер: сторона, предоставляющая возможности, то есть данные или действия. Банк может запустить один сервер перед системой основного банкинга, другой — перед механизмом обнаружения мошенничества и третий — перед хранилищем документов; каждый из них обслуживается командой, ответственной за соответствующую систему.

Три примитива, которые может предложить сервер

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

Инструменты выполняют определённые действия, такие как замораживание части счёта или отправка заявки сотруднику, ответственному за соблюдение правил. Подобно запросам типа POST они изменяют состояние, из-за чего требуют наибольшей степени утверждения человеком в банке.

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

Отбор примеров, анализ и передача

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

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

Формат передачи данных — JSON-RPC 2.0, передаваемый через один из двух распространенных протоколов. Stdio подходит для сервера, работающего на собственном компьютере клиента. HTTP с Server-Sent Events или потоковый HTTP подходят для удаленного сервера. Доступ к серверу центрального банкинга, находящемуся в центре обработки данных и за фаерволом, осуществляется через удаленный HTTP с соответствующей аутентификацией, а не через Stdio.

Безопасность

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

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

Как выглядит развертывание MCP

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

Пример расследования мошенничества показывает путь выполнения запроса:

1. Аналитик хочет получить информацию обо всех транзакциях стоимостью свыше десяти тысяч долларов, совершенных клиентом за последние тридцать дней, а также проверить, изменился ли недавно «отпечаток устройства».
2. LLM хоста определяет, что требуются два вызова инструментов, и указывает клиенту выполнить функцию get_transactions на сервере системы основного банкинга и функцию get_device_history на сервере механизма обнаружения мошенничества.

Клиент отправляет запросы JSON-RPC к обоим серверам по протоколу HTTPS.

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

Клиент передает оба ответа модели, которая объединяет их в один сводный отчет.

Все — как запросы, так и ответы, а также идентификатор аналитика — записывается в журнал аудита.

Минимальный сервер на Python, созданный с использованием официальной схемы SDK, демонстрирует, как мало кода требуется для такого инструмента:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

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

Некоторые привычки способствуют стабильной работе производственных серверов:

• Для каждого сервера следует определить одну систему, которую он будет обрабатывать, а не монолит, охватывающий корпоративное банковское обслуживание, борьбу с мошенничеством и CRM.
• Описания инструментов следует писать так, как было бы написано руководство для нового аналитика, поскольку модель определяет, когда применять тот или иной инструмент, исключительно на основе этого текста.
• Необходимо версионировать схемы инструментов. Изменение обязательного параметра в get_transactions без уведомления нарушает работу всех ассистентов, которые от него зависят, включая тех, кто работает не в команде по борьбе с мошенничеством.

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

A2A, агенты, общающиеся между собой

MCP обрабатывает связи между моделью и инструментами. A2A, введенный Google в 2025 году и теперь поддерживаемый Linux Foundation, обрабатывает другой тип связи: когда один автономный агент обращается к другому, особенно если они были созданы разными командами или поставщиками.

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

Делегирование осуществляется с помощью карточки агента — машинно читаемого описания того, что может делать агент. Она похожа на список инструментов сервера MCP, но описывает возможности всего агента, а не отдельные функции. Координирующий агент службы поддержки клиентов читает карточку агента по борьбе с мошенничеством и узнаёт, что тот может изучать спорные транзакции; читает карточку агента по кредитам и узнаёт, что тот может определять пригодность для рефинансирования, после чего выбирает подходящего агента для выполнения запроса клиента.

Координация определяет способ, которым агенты передают друг другу задачи, передают частичные результаты и сообщают о успехе или неудаче через стандартный канал связи. Каждая сторона рассматривает другую как «черный ящик». Агенту по обслуживанию клиентов не нужно знать, как построен агент по борьбе с мошенничеством, вызывает ли он инструменты MCP в системе корпоративного банкинга, какой моделью он управляется или сколько шагов требуется для выполнения задачи. Ему достаточно знать возможности агента и способа передачи ему работы.

Два примера из банковской практики иллюстрируют это. Во-первых, клиент сообщает о незнакомой оплате в размере пятисот долларов и также спрашивает о более выгодной ставке по ипотеке. Ассистент не может решить ни одну из этих проблем самостоятельно. Он направляет жалобу агенту по борьбе с мошенничеством, а вопрос об ипотеке — агенту по кредитам, запускает их одновременно, а затем объединяет ответы в один ответ клиенту.

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

ACP — слой обмена сообщениями

В то время как A2A сосредотачивается на делегировании задач, ACP занимается обменом сообщениями в ходе многопользовательских диалогов, особенно обработкой состояний, данных в памяти и ошибок во время длительных взаимодействий.

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

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

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

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

Как сравниваются пять подходов

Если рассматривать их параллельно, варианты отличаются по нескольким критериям:

• Что они соединяют. Обычные API связывают одно приложение с другим. Механизм вызова инструментов связывает модель с функцией. MCP связывает модель или приложение с инструментами, данными и запросами. A2A связывает агентов между собой. ACP связывает агентов на уровне сообщений.
• Стандартизация между поставщиками. Обычные API — нет. Механизм вызова инструментов — частично. MCP, A2A и ACP — да.

Открытие возможностей. Нет таковых для обычных API и вызовов инструментов. Динамическое открытие возможностей в MCP через карточки агентов для взаимодействия A2A, ограниченное в ACP.

Встроенные конвенции состояния и памяти. Нет таковых для обычных API и вызовов инструментов, частичные в MCP и A2A, а основное внимание уделяется им в ACP.

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

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

Одно сообщение клиента — от начала до конца

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

1. Клиент отправляет сообщение ИИ-ассистенту, приложению-хосту внутри банковского приложения.
2. С помощью A2A ассистент передает вопрос о мошенничестве агенту по борьбе с мошенничеством, а вопрос об ипотеке — агенту по кредитам; оба агента начинают работу одновременно.

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

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

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

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

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

Безопасность между агентами и протоколами

• Внедрение промптов. Вредоносная инструкция, скрытая в документе, электронном письме или загруженном файле, может попытаться повлиять на следующее действие агента. Представьте себе мошеннический спор, содержащий скрытый текст, который приказывает агенту по борьбе с мошенничеством одобрить заявку без проверки. Инструменты MCP изменяют реальное состояние, поэтому опасность действительна. Меры противодействия: рассматривать весь полученный контент как ненадежный, никогда не разрешать выводу модели запускать инструменты с высоким уровнем риска, такие как place_transaction_hold, без проверки политик, а также ограничивать набор инструментов, доступных модели в конкретном контексте.
• Аутентификация. Каждая связь клиент-сервер MCP и каждая передача данных между компонентами требуют аутентификации, обычно с использованием OAuth 2.1, чтобы анонимный пользователь не мог использовать инструменты центрального банкинга или поручать задачи агенту по проверке соответствия правилам.

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

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

Подтверждение человеком. Действия, имеющие финансовое, безопасностное или регуляторное значение, такие как замораживание счета, снятие ограничений или утверждение кредита, требуют подтверждения человеком. Это решение, основанное на уровне риска, а не недостаток технологии.

Хроники аудита. Фиксируйте каждый вызов инструмента, деlegation и изменение состояния с достаточной степенью детализации, чтобы можно было восстановить, что произошло и почему. Если регулятор спросит, почему счет был заблокирован на шесть часов, банк должен иметь возможность показать точную цепочку решений агента и вызовов инструментов, а не лишь оценку.

Каковы перспективы

Направление передачи данных легко понять. Протоколы вроде MCP становятся слоем драйверов устройств в области ИИ, обеспечивая стандартный путь от любой модели к любому инструменту без необходимости в специальных промежуточных решениях. Ожидается, что операционные системы ИИ станут отдельной категорией, где серверы в стиле MCP будут считаться инфраструктурой первого класса, аналогичной базам данных и очередям сообщений, а серверы центрального банкинга — компонентами, в которые будет подключаться каждый внутренний проект ИИ без необходимости их переписывания. Ожидаются рынки серверов, прошедшие предварительную проверку и аудит, что позволит банкам использовать серверы верификации KYC, одобренные регуляторами, вместо того чтобы создавать их сами. Также ожидается развитие инструментов управления для аудита вызовов MCP и процедур передачи полномочий между системами, поскольку команды, отвечающие за соблюдение нормативов и управление рисками, будут нуждаться в такой прозрачности перед тем, как все это начнет использоваться с реальными деньгами. Кроме того, ожидается, что эти же подходы распространятся далеко за пределы банкинга, на любые сферы, где системам принятия решений требуется стандартный, подлежащий аудиту способ взаимодействия с внешним миром.

Краткая версия

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

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