Enterprise-архитектура агентов для мобильного приложения

Давно не писал. Последнее время разбирался, как можно построить мультиагентную архитектуру для мобильного приложения в корпоративном контуре.

Не “чатик с LLM”, а ближе к enterprise-реальности: безопасность, права, аудит, MCP Hub, handoff между агентами и оркестратор как точка входа. Главная мысль Агент в проде — это не prompt и не markdown-файл.

Агент становится production-компонентом, когда у него есть:

  • зона ответственности;
  • владелец;
  • версия;
  • разрешенные tools;
  • ограничения по данным;
  • правила handoff;
  • аудит;
  • возможность отключить или откатить.

То есть агент — это управляемый участник backend-архитектуры. Как может выглядеть схема Mobile App -> BFF / API Gateway -> Agent Orchestrator -> Agent Registry -> Policy Engine -> MCP Hub -> Internal API Services -> Domain Services

Мобильное приложение не должно напрямую ходить в LLM. Оно создает задачу, передает контекст экрана, показывает статус, запрашивает подтверждение и отображает результат. **Оркестратор

Agent Orchestrator** — точка входа в агентный сценарий.

Он должен:

  • понять, какой агент нужен;
  • загрузить его конфигурацию;
  • проверить права;
  • вызвать нужные tools;
  • сделать handoff;
  • записать trace.

Например, пользователь пишет:

Почему не прошел платеж?

Оркестратор смотрит на контекст:

screen = operation_details operation_id = есть intent = payment_failed

И выбирает:

payments_agent

Если причина отказа — лимит по карте, сценарий передается в cards_agent. Agent Registry Чтобы не получить зоопарк промптов, нужен Agent Registry.

Это каталог, где хранится:

  • какие агенты существуют;
  • кто владелец;
  • какие tools разрешены;
  • какие handoff допустимы;
  • какие сценарии агент обслуживает.

Пример:

payments_agent: tools:

  • payments.get_operation_status
  • payments.get_commission handoffs:
  • cards_agent
  • fraud_agent
  • support_agent MCP Hub MCP удобен как способ подключать инструменты и контекст к агентам.

Но в enterprise агент не должен напрямую ходить в любые MCP-серверы.

Нужен слой контроля:

Agent -> MCP Hub -> MCP Adapter -> Internal API

MCP Hub проверяет права, доступные tools, параметры, audit, маскирование данных и необходимость approval. Безопасность Плохой вариант:

Agent -> Payments API

Лучше:

Agent -> MCP Hub -> API Service -> Domain Service

Агент просит:

payments.get_operation_status

А MCP Hub уже понимает, какой API вызвать, какие проверки сделать и что вернуть.

Минимально нужны:

  • allowlist tools;
  • policy check перед tool call;
  • scoped permissions;
  • аудит всех вызовов;
  • защита от prompt injection;
  • подтверждение пользователя для write-действий.

Агент может читать статус операции, но не должен сам выполнять платеж, менять лимит или персональные данные.

Пример

Пользователь нажимает:

Почему не прошел платеж?

Flow:

1. Mobile App отправляет запрос и контекст. 2. BFF проверяет сессию. 3. Orchestrator выбирает payments_agent. 4. Agent запрашивает статус операции через MCP Hub. 5. MCP Hub вызывает Payments API. 6. API возвращает status=failed и reason=card_limit_exceeded. 7. Agent понимает, что причина в карте. 8. Orchestrator делает handoff в cards_agent. 9. Пользователь получает объяснение и следующий шаг.

LLM рассуждает. Оркестратор управляет сценарием. Agent Registry управляет агентами. Policy Engine решает, можно ли. MCP Hub безопасно исполняет tools. Мобильное приложение дает пользователю интерфейс и контроль.

В таком разделении агентная архитектура становится похожей не на эксперимент, а на enterprise production-платформу.