В 2026 году вокруг AI-агентов шум стоит такой, что иногда сложно расслышать главное. Почти в каждом разговоре всплывают две аббревиатуры: MCP и A2A. И да, мнения о них — кто бы сомневался — часто расходятся до смешного. Кто-то называет MCP «USB-C для AI», кто-то уверяет, что A2A вот-вот его вытеснит, а кто-то вообще машет рукой: мол, всё это ещё сыровато для production. Правда, как обычно, чуть менее драматична и куда полезнее.
MCP и A2A не конкурируют напрямую. Они закрывают разные уровни одной и той же большой задачи — построения надёжных AI-систем. MCP описывает, как агент подключается к инструментам, данным и внешним сервисам. A2A — как один агент договаривается с другим агентом, передаёт ему работу, получает статус и результат. Перепутать эти роли легко. А потом архитектура начинает скрипеть, как дверь на даче в ноябре.
Ниже — не академическая лекция, а нормальный практический разбор: что это за протоколы, как устроены, где применяются, чем отличаются и как их сочетать в реальных проектах по разработке AI-агентов и автоматизации. Плюс — нюансы по безопасности, архитектуре и enterprise-внедрению. Без тумана, по возможности.
Сначала — две разные проблемы. Вот в чём весь фокус
До появления MCP и A2A почти каждая интеграция с AI собиралась вручную. Нужно подключить модель к PostgreSQL? Пишите свой адаптер. Нужен доступ к Slack, Jira, Google Drive или CRM? Ещё один адаптер. Нужно, чтобы один агент исследовал данные, а второй писал отчёт, а третий проверял риски? Ну... удачи. Обычно это превращалось в клубок из кастомной логики, временных решений и кода, который никто не хотел трогать через три месяца.
По сути, индустрия уткнулась в две отдельные боли.
Первая — интеграция инструментов.
У каждого AI-провайдера был свой формат вызова функций и работы с инструментами. OpenAI — один подход. Anthropic — другой. Google — третий. Разные схемы, разные ответы, разные правила ошибок, разные ожидания от клиента. Один и тот же коннектор приходилось переписывать под каждую экосистему. Именно эту проблему и решает MCP.
Вторая — координация агентов.
Как агенту найти другого агента? Как понять, что тот умеет? Как передать задачу, дождаться прогресса, обработать промежуточные статусы, получить артефакты? Раньше всё это делалось на уровне прикладной логики, без общего стандарта. То есть каждый строил свой маленький интернет — только хуже. Эту проблему и закрывает A2A.
И вот здесь важный, почти банальный, но критичный вывод: MCP — про инструменты. A2A — про взаимодействие агентов. Не вместо, а рядом.
MCP: протокол, который даёт агенту руки
Что такое MCP на практике
MCP (Model Context Protocol) — это стандарт взаимодействия между AI-клиентом или агентом и внешними возможностями: инструментами, источниками данных, шаблонами запросов и, в некоторых сценариях, вызовами модели. Проще говоря, если агенту нужно не просто «думать», а что-то читать, запускать, извлекать, преобразовывать или вызывать — MCP даёт для этого единый контракт.
Если говорить языком enterprise-архитектуры, MCP упрощает слой интеграции и делает его переносимым. Один раз подняли MCP-сервер для PostgreSQL, GitHub, Slack или внутренней BI-системы — и дальше его могут использовать разные клиенты и среды. Это уже не разовая склейка, а повторно используемый компонент. Для команд, которые строят архитектуру AI-агентов, это, честно говоря, огромная экономия времени и нервов.
Как устроена архитектура MCP
MCP обычно работает по клиент-серверной модели и использует JSON-RPC 2.0 как формат обмена сообщениями. Клиентом выступает AI-приложение, агент, IDE или хост. Сервером — поставщик возможностей: база данных, API-обвязка, файловый слой, корпоративный сервис и так далее.
┌─────────────────────┐ JSON-RPC 2.0 ┌──────────────────┐
│ │ ◄──────────────────► │ │
│ MCP Client │ (stdio, SSE, │ MCP Server │
│ (AI Agent/Host) │ HTTP Streaming) │ (Tool Provider)│
│ │ │ │
│ ┌───────────────┐ │ │ ┌────────────┐ │
│ │ Claude/GPT/ │ │ Request: │ │ Resources │ │
│ │ Gemini/Local │──┼──► tools/call ────────►│ │ (read data)│ │
│ │ │ │ │ ├────────────┤ │
│ │ │◄─┼── Result/Error ◄──────│ │ Tools │ │
│ └───────────────┘ │ │ │ (actions) │ │
│ │ │ ├────────────┤ │
│ │ │ │ Prompts │ │
│ │ │ │ (templates)│ │
│ │ │ ├────────────┤ │
│ │ │ │ Sampling │ │
│ │ │ │ (LLM calls)│ │
│ │ │ └────────────┘ │
└─────────────────────┘ └──────────────────┘
У MCP-сервера обычно есть четыре базовых типа возможностей:
- Resources — данные только для чтения: файлы, записи БД, ответы API, документы.
- Tools — действия: выполнить запрос, отправить письмо, создать сущность, обновить запись.
- Prompts — переиспользуемые шаблоны промптов со структурированными параметрами.
- Sampling — сценарий, при котором сервер может инициировать запрос к модели через клиента.
На бумаге всё выглядит аккуратно. В жизни — тоже, что приятно и даже немного подозрительно.
Пример MCP-сервера на TypeScript
Ниже — пример MCP-сервера, который даёт агенту доступ к PostgreSQL: можно читать список таблиц, выполнять только SELECT-запросы, получать схему таблицы и формировать шаблон анализа.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import postgres from "postgres";
const sql = postgres(process.env.DATABASE_URL!);
const server = new McpServer({
name: "postgres-explorer",
version: "1.0.0",
});
// Resource: List available tables
server.resource(
"tables",
"postgres://tables",
async (uri) => {
const tables = await sql`
SELECT table_name FROM information_schema.tables
WHERE table_schema = 'public'
`;
return {
contents: [{
uri: uri.href,
mimeType: "application/json",
text: JSON.stringify(tables, null, 2),
}],
};
}
);
// Tool: Execute a read-only query
server.tool(
"query",
"Execute a read-only SQL query against the database",
{
sql: z.string().describe("The SQL query to execute (SELECT only)"),
},
async ({ sql: query }) => {
if (!query.trim().toUpperCase().startsWith("SELECT")) {
return {
content: [{ type: "text", text: "Error: Only SELECT queries allowed" }],
isError: true,
};
}
const result = await sql.unsafe(query);
return {
content: [{
type: "text",
text: JSON.stringify(result, null, 2),
}],
};
}
);
// Tool: Get table schema
server.tool(
"describe-table",
"Get the schema of a specific table",
{
tableName: z.string().describe("Name of the table to describe"),
},
async ({ tableName }) => {
const columns = await sql`
SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_name = ${tableName} AND table_schema = 'public'
ORDER BY ordinal_position
`;
return {
content: [{
type: "text",
text: JSON.stringify(columns, null, 2),
}],
};
}
);
// Prompt: Generate an analysis prompt
server.prompt(
"analyze-table",
"Generate a prompt to analyze data in a specific table",
{
tableName: z.string().describe("Table to analyze"),
focus: z.string().optional().describe("Specific aspect to focus on"),
},
async ({ tableName, focus }) => ({
messages: [{
role: "user",
content: {
type: "text",
text: `Analyze the "${tableName}" table in our PostgreSQL database.${
focus ? ` Focus specifically on: ${focus}.` : ""
} Start by examining the schema, then run queries to understand the data distribution, identify patterns, and surface any anomalies.`,
},
}],
})
);
const transport = new StdioServerTransport();
await server.connect(transport);
Смысл здесь не только в коде. Смысл в переносимости. Один такой сервер можно подключить к разным MCP-совместимым клиентам — от десктопных приложений до IDE и внутренних агентных платформ. Это уже фундамент для масштабируемой агентной памяти и RAG, если поверх него строится доступ к документам, индексам и корпоративным знаниям.
Транспортные механизмы MCP
MCP поддерживает несколько транспортов, и выбор здесь зависит не от моды, а от сценария развёртывания.
| Транспорт | Где обычно используется | Как работает |
|---|---|---|
| stdio | Локальные инструменты, CLI, desktop-приложения | Сервер запускается как дочерний процесс, обмен идёт через stdin/stdout |
| SSE | Удалённые серверы, веб-сценарии | HTTP-соединение с потоковой передачей событий от сервера к клиенту |
| Streamable HTTP | Production API, облачные развёртывания | Полноценный HTTP-канал с поддержкой двустороннего стриминга |
stdio по-прежнему очень удобен для локальной разработки и внутренних desktop-интеграций. Но для production-среды, особенно если речь идёт о корпоративных AI-сервисах, всё чаще выбирают Streamable HTTP. Это проще масштабировать, мониторить и вписывать в существующую инфраструктуру.
Почему MCP так быстро прижился
Потому что он решает реальную, приземлённую проблему. Не абстрактную, а ту самую, из-за которой команды неделями пишут интеграционный слой. Когда один и тот же MCP-сервер можно использовать в нескольких клиентах без переписывания — это уже не «интересный стандарт», а рабочий актив.
Кроме того, MCP хорошо ложится на enterprise-требования: контроль доступа, аудит вызовов, ограничение инструментов, проксирование через внутренние шлюзы, централизованное управление политиками. А если проекту нужна безопасность AI-агентов, то именно на уровне MCP часто внедряют ограничения на действия, валидацию параметров, фильтрацию запросов и журналирование.
И да, маленький, но важный момент: MCP не делает агента умнее. Он делает его полезнее. Это разные вещи.
A2A: когда агентам нужно договариваться между собой
Что такое A2A без лишней мистики
A2A (Agent-to-Agent Protocol) — это стандарт, который описывает взаимодействие между агентами: обнаружение, описание возможностей, постановку задач, отслеживание статусов, передачу сообщений и получение результатов. Если MCP — это интерфейс между агентом и инструментом, то A2A — интерфейс между агентом и другим агентом.
Это особенно важно в системах, где один агент не должен делать всё сам. На практике так и бывает. Один специализируется на поиске информации, второй — на анализе, третий — на подготовке ответа, четвёртый — на проверке рисков и соответствия требованиям. В таких случаях без стандарта начинается ручная оркестрация, а затем — боль, интеграционные долги и вечные «давайте потом перепишем нормально». Обычно не переписывают.
Именно поэтому A2A становится ключевым элементом там, где строятся мультиагентные системы и распределённые AI-процессы.
Базовая архитектура A2A
A2A использует HTTP/JSON-модель взаимодействия. Один агент выступает клиентом или оркестратором, другой — удалённым специализированным агентом. Сначала идёт обнаружение возможностей, затем постановка задачи, потом — жизненный цикл выполнения, стриминг статусов и возврат артефактов.
┌─────────────────────┐ HTTP/JSON ┌──────────────────┐
│ │ ◄────────────────────► │ │
│ Client Agent │ │ Remote Agent │
│ (Orchestrator) │ │ (Specialist) │
│ │ 1. Discovery │ │
│ "I need this done" │ ──► GET /agent.json ────►│ Agent Card │
│ │ ◄── capabilities ◄──────│ (JSON manifest) │
│ │ │ │
│ │ 2. Task Lifecycle │ │
│ │ ──► tasks/send ──────────►│ Process task │
│ │ ◄── status updates ◄────│ (may be async) │
│ │ │ │
│ │ 3. Streaming │ │
│ │ ──► tasks/sendSubscribe ─►│ Real-time │
│ │ ◄── SSE events ◄────────│ progress │
│ │ │ │
│ │ 4. Artifacts │ │
│ │ ◄── result artifacts ◄──│ Deliverables │
└─────────────────────┘ └──────────────────┘
Ключевые сущности здесь такие:
- Agent Card — JSON-манифест с описанием агента, его навыков, требований к аутентификации и поддерживаемых возможностей.
- Tasks — единицы работы с жизненным циклом:
submitted,working,input-required,completed,failed,canceled. - Messages — сообщения внутри задачи, состоящие из частей: текст, файл, структурированные данные.
- Artifacts — результаты выполнения: отчёты, файлы, JSON-объекты, ссылки, вывод анализа.
- Streaming — потоковые обновления статуса для долгих операций.
Всё довольно логично. И, что приятно, логика здесь не декоративная, а реально полезная для production.
Agent Card: как агент объявляет, кто он такой
Agent Card — это, по сути, паспорт агента. Он публикуется по well-known URL и позволяет другому агенту понять: что умеешь, как к тебе обращаться, нужен ли токен, поддерживаешь ли стриминг, какие форматы входа и выхода принимаешь.
{
"name": "Code Review Agent",
"description": "Performs automated code review with security analysis, performance profiling, and style checking",
"url": "https://code-review.example.com",
"version": "2.1.0",
"capabilities": {
"streaming": true,
"pushNotifications": true,
"stateTransitionHistory": true
},
"authentication": {
"schemes": ["Bearer"],
"credentials": "OAuth 2.0 token required"
},
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["text/plain", "application/json"],
"skills": [
{
"id": "security-review",
"name": "Security Vulnerability Scan",
"description": "Scans code for OWASP Top 10 vulnerabilities, dependency risks, and secrets exposure",
"tags": ["security", "OWASP", "vulnerability"],
"examples": [
"Review this PR for security vulnerabilities",
"Scan the auth module for injection risks"
]
},
{
"id": "performance-review",
"name": "Performance Analysis",
"description": "Analyzes code for N+1 queries, memory leaks, unnecessary re-renders, and bundle size impact",
"tags": ["performance", "optimization", "memory"],
"examples": [
"Check this component for performance issues",
"Analyze the database query patterns in this service"
]
}
]
}
Почему это важно? Потому что оркестратор может автоматически подобрать подходящего агента под задачу — без жёстко зашитой конфигурации. Сегодня это агент code review, завтра — агент комплаенса, послезавтра — агент финансового анализа. Если контракт стандартизирован, замена и расширение становятся куда менее болезненными. Не идеально, конечно. Но уже по-человечески.
Жизненный цикл задачи в A2A
Ниже — типичный пример: один агент отправляет задачу агенту code review, передаёт текстовое описание и структурированные данные по pull request.
// Client Agent: Send a task to the Code Review Agent
const response = await fetch("https://code-review.example.com/tasks/send", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer <token>",
},
body: JSON.stringify({
jsonrpc: "2.0",
method: "tasks/send",
id: "task-001",
params: {
id: "review-pr-42",
message: {
role: "user",
parts: [
{
type: "text",
text: "Review PR #42 for security vulnerabilities. The PR modifies the authentication flow and adds a new OAuth provider.",
},
{
type: "data",
data: {
repository: "acme/backend",
prNumber: 42,
diffUrl: "https://github.com/acme/backend/pull/42.diff",
},
},
],
},
},
}),
});
const result = await response.json();
// result.result.status.state === "completed"
// result.result.artifacts contains the review findings
Если задача долгая — например, анализ большого репозитория, юридическая проверка документа или сложная аналитика — используется стриминг статусов. Это уже не просто «отправил и молюсь», а нормальный управляемый процесс.
И вот здесь A2A особенно хорош в enterprise-контуре: можно строить прозрачные пайплайны, где каждый агент отвечает за свою специализацию, а оркестратор видит состояние всей цепочки. Для компаний, которым важно AI compliance и соответствие требованиям, это не роскошь, а необходимость: кто что сделал, на каком этапе, с какими входными данными, какой результат вернул.
MCP и A2A: разница в одной таблице
| Критерий | MCP | A2A |
|---|---|---|
| Что стандартизирует | Доступ агента к инструментам, данным и сервисам | Взаимодействие одного агента с другим агентом |
| Основной сценарий | Вызов инструментов и получение контекста | Делегирование задач и координация работы |
| Тип участников | Клиент/агент ↔ MCP-сервер | Агент-оркестратор ↔ удалённый агент |
| Формат обмена | JSON-RPC 2.0 | HTTP/JSON, задачи, сообщения, артефакты |
| Что возвращается | Данные, результаты действий, шаблоны | Статусы задач, сообщения, артефакты результата |
| Где особенно полезен | Интеграции, RAG, доступ к корпоративным системам | Мультиагентные процессы, оркестрация, специализация |
Если совсем коротко: MCP подключает способности, A2A подключает исполнителей. Вот и всё. Ну, не всё, конечно, но суть именно такая.
Когда использовать MCP, когда A2A, а когда оба сразу
Сценарий 1: один агент, много инструментов
Если у вас один основной агент, которому нужно работать с CRM, базой данных, документами, Slack, Jira и внутренними API, то базовый выбор — MCP. Здесь не нужен отдельный протокол межагентного общения, потому что агент один, а вот интеграций много.
Сценарий 2: несколько специализированных агентов
Если система состоит из исследовательского агента, аналитического агента, агента проверки рисков и агента генерации ответа, то нужен A2A. Иначе оркестрация быстро превратится в хрупкий самописный слой, который сложно расширять и тестировать.
Сценарий 3: реальный enterprise-кейс
А вот тут обычно нужны оба протокола. Например:
- агент-оркестратор принимает бизнес-запрос;
- через A2A делегирует подзадачи специализированным агентам;
- каждый специализированный агент использует MCP для доступа к своим инструментам, данным, RAG-слою, внутренним API и хранилищам знаний;
- результаты собираются обратно, проверяются, логируются и отдаются пользователю или бизнес-системе.
Это, собственно, и есть зрелая агентная архитектура. Не магия — инженерия. Иногда скучная, но очень полезная.
Безопасность, governance и то, о чём вспоминают слишком поздно
Есть соблазн смотреть на MCP и A2A только как на протоколы интеграции. Но в enterprise-среде этого мало. Вопросы безопасности и соответствия требованиям встают почти сразу — а если не встают, то потом встают очень резко.
Для MCP критичны:
- ограничение доступных инструментов и команд;
- валидация входных параметров;
- разделение read-only- и write-операций;
- аудит вызовов и трассировка действий;
- изоляция секретов и контроль прав доступа.
Для A2A важны:
- надёжная аутентификация агентов;
- проверка доверия к Agent Card и endpoint-ам;
- контроль делегирования задач;
- логирование состояний и артефактов;
- политики обработки чувствительных данных между агентами.
И да, это тот самый момент, где «сначала запустим, потом защитим» обычно заканчивается плохо. Не сразу. Но стабильно.
Практический вывод
Если вы строите AI-систему в 2026 году, спор в духе «что лучше — MCP или A2A?» сам по себе поставлен криво. Это всё равно что спорить, что важнее в офисе: лифт или переговорка. Зависит от того, что вы вообще строите.
Выбирайте MCP, если задача — дать агенту стандартизированный доступ к данным, инструментам и действиям.
Выбирайте A2A, если задача — организовать сотрудничество нескольких агентов с разными ролями.
Используйте оба, если вы строите масштабируемую, безопасную, enterprise-ready агентную систему, где есть и интеграции, и специализация, и требования к управляемости.
Короче говоря: MCP отвечает на вопрос «чем агент может пользоваться?», A2A — «с кем агент может работать?». А хорошая система, как правило, должна уметь и то, и другое. Иначе потом начинаются костыли. А костыли, ну вы знаете, редко становятся архитектурным стандартом.