За последние пару лет системы на больших языковых моделях прошли путь от «сгенерируй абзац» до автономных агентов. ИИ-агент в этом тексте — модуль, который получает задачу, хранит промежуточное состояние и вызывает внешние инструменты: API, файловую систему или другой сервис.
Как только такой агент выходит из демо в производство, всплывает системная проблема — фрагментация интерфейсов. Модель живёт отдельно, инструменты отдельно, другие агенты отдельно, корпоративный периметр безопасности отдельно. Классическая формулировка этой боли — проблема N×M: для связки N клиентов с M источниками данных приходится писать N×M уникальных адаптеров. Пять моделей и десять инструментов превращаются в полсотни самописных переходников, которые никто не хочет поддерживать.
На эту проблему уже отвечают несколько спецификаций и API-механизмов. Вокруг агентного взаимодействия появляется набор протоколов, API-паттернов и runtime-подходов — спецификаций, каждая из которых берёт на себя свой кусок связывания: как модель дотягивается до инструмента, как агент живёт во времени, как два агента договариваются, как данные безопасно выходят за периметр. Ниже — обзорный разбор десяти таких протоколов и стандартов. Разберём их по архитектурным уровням: модель-инструменты, процесс агента, межагентное взаимодействие, данные и безопасность.
Важное ограничение: пункты в списке различаются по зрелости. Часть — реальные, широко обсуждаемые и уже внедряемые стандарты (MCP, A2A, ACP, function calling у OpenAI). Часть — скорее зонтичные обозначения класса задач, чем один утверждённый протокол (AgentOS, TDF, OAP, AGP). Поэтому ниже эти пункты стоит читать не как десять равнозначных стандартов, а как карту разных уровней зрелости.
Как читать стек: четыре уровня эталонной модели
Чтобы сравнивать эти спецификации по роли в архитектуре, используем четырёхслойную схему: модель и инструменты, процесс агента, взаимодействие агентов, данные и governance. В этой статье будем использовать четыре уровня агентного стека:
- Model & Tool Level — как модель связывает контекст, вызывает функции и исполняет код.
- Agent / Process Level — как управляется состояние агента, планирование и циклы исполнения.
- Inter-Agent Level — как несколько агентов коммуницируют, оркеструются и делят задачи между собой.
- Data & Governance — как обеспечиваются безопасность, семантика, графы знаний и шлюзы доступа.
Начнём с уровня модели и инструментов.
Слой 1. Model & Tool Level: где модель дотягивается до инструментов
На этом уровне описываются способы передать модели контекст, объявить доступные функции и выполнить сгенерированный вызов.
MCP (Model Context Protocol) — Anthropic
Сфера применения: унифицированное подключение контекста, файлов и инструментов к LLM. Архитектурный слой: Integration / Data Fabric.
Открытый стандарт от Anthropic, ориентированный на снижение числа парных интеграций между клиентами и источниками данных. Архитектурно это клиент-серверная модель поверх JSON-RPC 2.0 с двумя транспортами: stdio для локальных процессов и SSE для сетевых. Сервер объявляет три базовых примитива:
- Prompts — готовые шаблоны взаимодействий, декларируемые сервером.
- Resources — пассивные данные для контекста (файлы, логи, API-ответы), которые читает клиент.
- Tools — активные исполняемые функции с побочными эффектами.
Среди перечисленных решений MCP относится к наиболее зрелым и активно внедряемым. Когда применять: когда нужно единообразно подключать к модели много разнородных источников и инструментов и нужно сократить число одноразовых интеграционных адаптеров — MCP даёт один контракт вместо десятков переходников.
FCP (Function Calling) — OpenAI
Сфера применения: строго детерминированный вызов внешних функций на уровне декодирования модели. Архитектурный слой: Model Interface Layer.
Механизм вызова функций, встроенный прямо в API OpenAI (Chat Completions и Responses API). Функция описывается через JSON Schema с параметрами strict: true и additionalProperties: false, после чего серверная инфраструктура компилирует схему в грамматику декодирования. Отсюда два ключевых свойства:
- Constrained Decoding — гарантия 100% соответствия генерируемого JSON заданным типам прямо на уровне выборки токенов (grammar masking, logit bias). Модель физически не может выдать невалидную структуру.
- Parallel Function Calling — в одном ответе модель может сгенерировать сразу несколько вызовов для параллельного исполнения на клиенте.
Это не самостоятельный сетевой протокол, а механизм API OpenAI; в этой карте он относится к уровню model-tool interface. Когда применять: когда критична валидность выходной структуры (никаких «модель иногда возвращает битый JSON») и хочется несколько параллельных вызовов за один ход.
TAP / ATP (Tool Agent Protocol → Agent Tool Protocol) — экосистема LangChain
Сфера применения: стандартизация описания и вызова внешних инструментов. Архитектурный слой: Execution & Tooling.
Протокол взаимодействия агента с инструментами и средами исполнения. В экосистеме LangChain/LangGraph он стандартизирует абстракции Runs, Threads и Store, а в развитии превращается в ATP — протокол безопасного исполнения кода. Основная инженерная цель — снизить расход контекстного окна на описание инструментов: вместо того чтобы на каждом ходу заново класть в контекст JSON-схемы под каждую функцию, TAP/ATP транслирует метаданные инструментов и позволяет агенту генерировать строгий исполняемый код (TypeScript/Python) внутри изолированного sandbox — например, V8 VM. Выигрыш двойной:
- существенная экономия контекстного окна — схемы не дублируются на каждом ходу;
- параллельное исполнение цепочек инструментов и фильтрация данных прямо в песочнице, до отправки результата обратно в LLM.
Когда применять: когда инструментов много, их описания инструментов занимают значительную часть контекстного окна, а часть логики (фильтрацию, агрегацию) выгоднее выполнить кодом в песочнице, а не гонять через модель.
Слой 2. Agent / Process Level: где агент живёт во времени
Следующий уровень описывает агента как долгоживущий процесс: со статусом, памятью, лимитами и восстановлением после сбоев.
AgentOS — проприетарные runtime-архитектуры
Сфера применения: управление жизненным циклом и ресурсами долгоживущих агентов. Архитектурный слой: Runtime / Infrastructure.
Термином AgentOS обозначают не один стандарт, а класс узкоспециализированных сред исполнения (обычно внутри корпоративных платформенных продуктов), которые абстрагируют железо и софт под задачи агентных систем. Функциональный стек тут инфраструктурный:
- Execution Throttling & Rate Limiting — управление лимитами API (TPM/RPM) и динамическое распределение токенов.
- Process Control — запуск, приостановка, дамп состояния (checkpointing) и восстановление агента при падении узла.
- Memory Paging — управление оперативным контекстом (short-term) и подкачка в векторные/реляционные хранилища (long-term memory).
По функциям это ближе к runtime-слою для управления агентом, чем к прикладному протоколу. Когда применять: когда агент работает долго и должен переживать сбои — нужен компонент, который сохраняет состояние, управляет лимитами и восстанавливает выполнение, если узел упал на середине трёхчасовой задачи, а бюджет токенов на исходе.
TDF (Task Definition Format) — Stanford
Сфера применения: декларативное описание сложных составных задач и оптимизация графов выполнения. Архитектурный слой: Specification / Graph Planning.
Спецификация, выросшая из исследовательских работ по агентным графам и планированию. Задаёт жёсткий декларативный формат (обычно YAML или JSON-LD) для описания целевого состояния системы, входных/выходных контрактов и графа зависимостей (DAG). Смысл — компилировать высокоуровневую цель в оптимизированный граф выполнения: распределять подзадачи между узкоспециализированными агентами и минимизировать общее число обращений к LLM. Пока это ближе к исследовательскому формату, чем к отраслевому стандарту. Когда применять: когда задача составная и многошаговая, и её выгоднее описать декларативно (что должно получиться и в каком порядке), а компиляцию в оптимальный план отдать движку, а не хардкодить цепочку вызовов руками.
Слой 3. Inter-Agent Level: где агенты договариваются друг с другом
Этот уровень нужен, когда несколько агентов обмениваются задачами, статусами и результатами.
ACP (Agent Communication Protocol) — IBM / BeeAI
Сфера применения: межагентный обмен сообщениями на уровне предприятия. Архитектурный слой: Application Layer (REST / Async HTTP).
Разработан в рамках инициативы BeeAI под эгидой Linux Foundation. Даёт вендоронезависимый HTTP-интерфейс для связывания агентов, написанных на разных языках и фреймворках (LangChain, CrewAI, кастомные среды). Механика: агент абстрагируется до набора REST-эндпоинтов (/agents, /runs, /sessions), а сообщения передаются структурированными JSON-пакетами с MIME-типизированными фрагментами (text/plain, application/json, мультимедиа). Две важные функции:
- Async-First — поддержка долгоживящих задач через SSE и механизмы паузы/возобновления (
await_request). - Offline Discovery — обнаружение метаданных агента и его capabilities даже при нулевом числе активных подов (scale-to-zero).
Когда применять: когда в контуре предприятия нужно связать разнородных агентов по обычному HTTP, с долгоживущими задачами и возможностью обнаруживать агентов, даже когда они не подняты.
A2A (Agent2Agent) — Google
Сфера применения: мультиагентная кооперация, распределённая оркестрация и согласование ролей. Архитектурный слой: Orchestration Layer.
Открытый протокол горизонтального взаимодействия автономных систем от разных вендоров. Интересен своей семантикой: агенты обмениваются не просто текстом, а декларативными ожиданиями от выполнения работы — протокол описывает переговоры (negotiation), делегирование задач и передачу роли. Ключевые элементы:
- Role Capability Matrix — формальное описание компетенций агента.
- Shared Context Bus — сквозной перенос состояния и цепочек рассуждений (Chain-of-Thought) с разграничением доступа к приватным токенам.
A2A сейчас активно обсуждается как протокол межагентного взаимодействия. Когда применять: когда нужно обеспечить совместную работу агентов разных вендоров — договариваться о ролях, делегировать друг другу подзадачи и делить общий контекст.
OAP (Open Agent Protocol) — open-source-сообщество
Сфера применения: децентрализованное обнаружение и маршрутизация агентов. Архитектурный слой: Network / Service Mesh.
Сообщественный стандарт под федеративные агентные сети — так называемый Internet of Agents. Две функции:
- Agent Discovery — поиск агентов по семантическому профилю через децентрализованные реестры.
- Inter-agent Routing — маршрутизация запросов по стоимости (cost-per-token), задержке (latency) и уровню надёжности (SLA) целевого агента.
Это скорее направление и класс, чем один устоявшийся стандарт. Когда применять: когда агентов в сети много и нужен механизм, который находит подходящий и маршрутизирует к нему запрос по цене, задержке и надёжности.
Слой 4. Data & Governance: где данные встречаются с безопасностью
Этот уровень отвечает за семантические модели данных, контроль доступа, маскирование чувствительной информации и аудит действий агента.
RDF-Agent (Semantic Web) — W3C / Open Web
Сфера применения: графы знаний, семантическая адресация и логический вывод. Архитектурный слой: Knowledge Representation Layer.
Подход, связывающий агентные архитектуры с классическими стандартами W3C — RDF, OWL, SPARQL. Данные и возможности агента описываются графом связанных данных (Linked Data), а сам агент использует SPARQL для точных детерминированных запросов к корпоративным графам знаний. Главное преимущество — связи проверяются по онтологии и запросам к графу знаний, а не выводятся только из вероятностной генерации модели. Когда применять: в финансовом, юридическом, медицинском контурах, где ошибка в связи между фактами может иметь юридические, финансовые или медицинские последствия, и нужен детерминированный, проверяемый вывод по онтологии.
AGP (Agent Gateways & Protocols) — industry standards
Сфера применения: безопасность, трансформации, аутентификация и enterprise-интеграция. Архитектурный слой: Security & Enterprise Gateway.
Промышленный класс протоколов и шлюзов, регулирующий периметр безопасности при выходе агента во внешние корпоративные контуры. Три функции, каждая из которых обычно требует отдельной реализации и контроля в production-среде:
- Identity & Access Management (IAM) — трансляция токенов пользователя (OAuth2/OIDC) в ограниченные права агента (Delegated Authority).
- Zero Trust Data Transformation — автоматическая маскировка PII и secrets (ключей API) в промптах до отправки во внешние LLM-провайдеры.
- Policy Enforcement — мониторинг действий агента в реальном времени с экстренной остановкой процесса (Circuit Breaking) при выходе за бюджет или обнаружении опасных команд.
Это не один протокол, а класс шлюзов. Когда применять: когда агент выходит во внешний контур из-под корпоративного периметра — чтобы транслировать права пользователя, не отдать наружу секреты и иметь возможность аварийно остановить процесс.
Сводная матрица стека
Собранные по слоям, десять протоколов складываются в компактную карту:
| Уровень архитектуры | Протоколы / стандарты | Основная задача |
|---|---|---|
| Model & Tool Level | MCP, FCP (OpenAI), TAP/ATP | Связывание контекста, вызов функций, исполнение кода |
| Agent / Process Level | AgentOS, TDF (Stanford) | Управление состоянием, планирование, циклы исполнения |
| Inter-Agent Level | ACP (IBM), A2A (Google), OAP | Коммуникация, оркестрация, распределение задач |
| Data & Governance | RDF-Agent, AGP (Industry) | Безопасность, семантика, графы знаний, шлюзы доступа |
Как этим пользоваться на практике
Эту классификацию полезно использовать для выбора уровня, на котором находится инженерная проблема. Алгоритм выбора можно сформулировать так — сначала определить слой, потом протокол:
- Если модель возвращает невалидный JSON, дублирует схемы инструментов или тратит слишком много контекста на tool definitions. Это Model & Tool Level: смотреть в сторону MCP (единый доступ к инструментам), FCP (строгая валидность вывода), TAP/ATP (исполнение кода в песочнице).
- Если агент выполняет долгую задачу, теряет состояние после сбоя или упирается в лимиты API. Это Agent / Process Level: runtime класса AgentOS, а для составных целей — декларативное описание в духе TDF.
- Если несколько агентов не согласуют роли, формат сообщений или порядок делегирования. Это Inter-Agent Level: ACP для HTTP-связки в предприятии, A2A для переговоров и делегирования между вендорами, OAP для обнаружения и маршрутизации в большой сети.
- Данные и безопасность — нужен детерминированный вывод по онтологии или защита периметра при выходе наружу. Это Data & Governance: RDF-Agent для графов знаний и точных запросов, AGP для IAM, маскировки PII и policy enforcement.
Симптом, видимый в ответе модели, может быть вызван проблемой на уровне runtime, orchestration или data governance — поэтому первый вопрос при проектировании и отладке агентной системы полезно ставить так: на каком слое живёт эта задача?
Текущая траектория стандартизации
По этим инициативам видно движение от самописных интеграций к повторно используемым интерфейсам и runtime-слоям. С честной поправкой на зрелость — часть слоёв уже стандартизирована и внедряется (MCP, A2A, ACP, function calling), а часть только кристаллизуется из класса задач в спецификацию (AgentOS, TDF, OAP, AGP как зонтичные обозначения). Часть интерфейсов уже используется в production, часть остаётся исследовательской или зонтичной категорией. Но его контур уже виден, и умение разложить любую агентную задачу по этим четырём этажам — такая классификация помогает отделить архитектурную проблему от задачи написания ещё одного адаптера.
Если источник данных поддерживает MCP, интеграция может свестись к подключению готового MCP-сервера вместо разработки отдельного адаптера. Выбор подхода зависит от того, удаётся ли сначала определить уровень проблемы: model-tool, process, inter-agent или data governance.
https://www.dobryakov.com/lead-magnets/ai-agent-protocol-stack.html?utm_source=None&utm_medium=None&utm_campaign=ai-agent-protocol-stack