Решение 002: единый MCP и REST-модуль магазина

Принято · 1 октября 2026. Основатель выбрал второй вариант после обсуждения идентификации и корзины. Он заменяет предыдущее решение того же дня о MCP непосредственно в OpenCart. Это целевая архитектура, не утверждение о готовой интеграции.

Решение

App / чат витрины → harness Agentfy → MCP / права Store Deputy
                                             ↓ HTTPS REST/JSON
                                        Модуль OpenCart
                                             ↓
                               Настоящий каталог и корзина

Agentfy отвечает за исполнение агента, skills, разговоры и вызовы инструментов. Store Deputy — за интерфейс аккаунта и подключения и контролируемый доступ к магазину: единый MCP, команды, права, контекст человека, подписки, согласования и аудит. Модуль OpenCart предоставляет версионируемый REST API, проверяет обращения и выполняет поддерживаемые операции платформы. Полного MCP внутри модуля нет.

В app: команды (одна по умолчанию), агенты, аккаунт, биллинг и чат с каждым агентом. Connect ведёт на вход/регистрацию, безопасное подключение, автоматическое создание агента в Agentfy с MCP URL Store Deputy и возврат в модуль. Первая команда и базовое подключение уже реализованы локально; интеграция и новые инструменты — нет.

Три границы полномочий

Граница	Доверенное подтверждение	Область доступа
Подключение магазина	Отдельные отзываемые серверные ключи модуля	Разрешённый магазин и его возможности
Действие сотрудника	Пользователь Store Deputy, членство, роль и проверенный контекст runtime	Права этого сотрудника; точное согласие на защищённую запись
Диалог покупателя	Сессия витрины, проверенная модулем и связанная с разговором	Корзина этого посетителя и явно разрешённые данные

Agentfy авторизуется в центральном MCP; Store Deputy отдельно авторизуется в модуле. MCP bearer не пересылается в OpenCart. Сервисный ключ Agentfy сам по себе не доказывает принадлежность корзины покупателю. Runtime добавляет вне prompt проверяемый контекст: тип участника, команда/магазин, conversation/run, scopes, срок и при необходимости непрозрачная привязка покупателя. Модель не выбирает себе личность или права.

Права проверяются при каждом вызове. Проверки принадлежности и локальная Pause в модуле действуют независимо от центральной оркестрации. Нельзя хранить current_customer на общем агенте: у каждого посетителя отдельный разговор и контекст.

Покупатель и корзина

1. Виджет обращается к модулю на домене магазина. Модуль определяет гостя/клиента по настоящей сессии OpenCart, а не по customer_id из браузера.
2. Через защищённый серверный обмен создаётся привязка разговора в Store Deputy. Браузер получает краткосрочный доступ к чату. Cookie OpenCart остаётся в магазине; непрозрачная ссылка не заменяет проверку полномочий.
3. Agentfy получает разговор и делегированный контекст через сервис чата. cart.get или cart.addItem(productId, quantity) работает с этой привязкой, не с выбранным моделью клиентом.
4. Store Deputy проверяет права и привязку; модуль повторно проверяет принадлежность и работает с существующей корзиной средствами OpenCart.
5. Магазин рассчитывает цены, наличие, акции, налог и итог. Подтверждённый результат и ревизия обновляют видимую корзину; второй независимой корзины у Store Deputy/Agentfy нет.

Вход, выход, истечение сессии и объединение гостевой корзины требуют обновить или отозвать привязку. Для нескольких вкладок нужен контроль конфликтов. У изменения один operation key на намерение: повтор не добавляет товар дважды; другой payload с тем же ключом отклоняется. Неопределённый результат после timeout сначала сверяется. Checkout, платежи, создание заказов и история заказов в первый объём корзины не входят.

В OpenCart 3.0.3.5 выбор корзины использует api_id, customer_id, session_id, а стандартный API login создаёт отдельную API-сессию. Поэтому одного такого входа недостаточно для корзины посетителя. Поведение адаптера нужно доказать на обеих поддерживаемых тестовых версиях.

Контракт и этапы

Сначала согласовать REST schemas, MCP transport/auth, делегирование Agentfy, capabilities, ошибки, отзыв, operation key и cart revision. Конкретные технические механизмы ещё предстоит реализовать и проверить. Предложенный контракт, который ещё нужно согласовать, — REST 1.0.

Этап A: защищённый API модуля, lifecycle подключения, центральный MCP, контекст сотрудника, автоматическое создание агента и реальное чтение каталога. До записи цен по существующему эпику проверить изоляцию и отзыв доступа.

Этап B: bootstrap покупателя, изолированные frontend-разговоры, чтение корзины, затем разрешённые изменения и обновление витрины. Этот этап зависит от Frontend Agent и подписки; он не блокирует первый Admin Agent. Автономного checkout нет.

PHP и модуль — Artem Belikov. API, Agentfy, общий контракт и сквозная интеграция — yevhen.kariakin. Работы на двух сторонах оформляются отдельными задачами. Существующие продуктовые эпики сохраняют свои результаты; этот эпик создаёт основу интеграции.

Последствия и альтернативы

Единый шлюз даёт стабильный интерфейс агенту и централизует права, аудит и коммерческие ограничения. Различия версий скрыты в адаптерах; неподдерживаемые функции явно отклоняются. Цена — дополнительный сетевой переход и зависимость операций от доступности/защиты Store Deputy. Нужны проверки и в API, и в модуле.

Прямой MCP в модуле не означает автоматическую потерю контроля: авторизуется клиент MCP, не модель. Для нашего продукта централизованные правила и единый интерфейс полезнее независимого MCP каждого магазина. Второй harness в Store Deputy не создаётся. Предыдущие черновики Bridge RPC не накладывают требований совместимости на REST 1.0; существующий экспериментальный код не реализует этот контракт.

Источники

• Обсуждение с основателем и журнал решений.
• Авторизация MCP: отдельные ресурсы и audience токена.
• Безопасность MCP: идентификатор состояния не является авторизацией.
• OpenCart 3.0.3.5: корзина, API login.

Протокол модуля ↔ API: REST 1.0