EN
Связаться
Глава 30

Соберите MCP внутри A2A и выпустите систему

Теперь всё сходится в одну картину. Production-архитектура нашего примера использует A2A на границе самостоятельного Review Agent и MCP - внутри его runtime, для runbooks, CI-evidence и release-проверок. Снаружи координатор видит агента; внутри агент видит возможности. И каждый слой сохраняет собственные идентификаторы, authorization и failure-семантику.

Граница A2A проходит между Release Coordinator и Review Agent: Agent Card, SendMessage, состояния Task, input_required, Artifact. Команда Review Agent свободна менять внутреннюю реализацию, пока держит контракт. А внутри проходит граница MCP: Review Host читает ресурс runbook, читает снимок релиза, вызывает детерминированный review-tool - и каждый сервер имеет least privilege. Полный production-путь запроса проходит через обе границы по очереди.

  1. A2A submitted
  2. working
  3. MCP discovery
  4. MCP calls
  5. Validate
  6. Artifact
  7. completed
A2A request
  authenticate coordinator
  create durable Task
  publish submitted/working
  run bounded agent workflow
    MCP discover allowed servers
    read runbook://release-policy
    read release://service/version
    call review_release
  validate + redact artifact
  publish completed
  persist audit + metrics

Чтобы такую систему можно было отлаживать, критично не смешивать идентификаторы разных слоёв - у каждого своё назначение.

Поле · Назначение · Не смешивать с

  • trace id - Сквозной observability; Authorization proof
  • A2A taskId - Жизненный цикл делегации; MCP request id
  • A2A contextId - Группа связанных conversations; HTTP session
  • MCP JSON-RPC id - Correlation одного call; Доменный job id
  • idempotency key - Защита side effect; Trace id
  • actor/tenant - Security context; Model-provided metadata

Собрать финальный release gate целиком - с порогами по успешности, стоимости и латентности - можно в лаборатории.

Интерактивная лаборатория 6

Production release gate

Отмечено 0 из 9. До release остаются незакрытые условия.

И это не теория: companion-проект реально проходит проверку, и её результат зафиксирован.

Проверка · Результат 01.08.2026

  • TypeScript - Strict compile, skipLibCheck: false, без any в source/tests
  • Tests - 14 passed, 0 failed
  • MCP E2E - Modern era, 2 tools, 3 listed resources, 1 prompt, decision ready
  • A2A E2E - Agent Card resolved; completed Task с Markdown/JSON artifact и input-required Task
  • Network/model - Не требуется; reasoning намеренно детерминирован

Главный критерий, по которому судят зрелость такой архитектуры, - независимость границ.

Готовый критерий архитектуры. Удаление A2A-слоя не должно менять MCP capability schemas. Замена MCP-сервера не должна менять публичную семантику A2A skill. Если оба условия выполняются - границы действительно независимы, и систему можно развивать по частям.

И последнее - дисциплина, без которой книга по живым протоколам превращается в тыкву.

Перепроверяйте версии перед deploy. MCP и A2A активно развиваются. Держите protocol conformance tests и читайте официальный changelog при каждом обновлении SDK, даже если TypeScript-компиляция остаётся зелёной. Зелёный компайл не значит совместимый протокол.

На этом система собрана целиком - от выбора контракта до выпуска. Все технические утверждения книги сверены с первоисточниками; их полный список - в следующей главе.

Ссылки