|
|
|
Professor Seleznov
|
TL;DR. Live Direct Marketing (LDM) — B2B email-платформа с собственным MCP-сервером. Веб-интерфейс и MCP экспонируют один и тот же /api/* через HybridAuthGuard, поэтому при подключении к голосовому ассистенту через MCP агент получает ровно ту же поверхность, что и пользователь дашборда. Без дублирования контроллеров, без отдельного agent API. Опробовали в полевых условиях на VODEXPO 2026: голосовая команда → рассылка по сегменту базы → пофайловая верификация доставки в инбокс. Ниже — архитектура, фрагменты кода, и где это всё реально ломается. Контекст LDM — мульти-тенантная платформа для B2B коммуникации: CRM (companies/contacts/leads), сегменты, креативы, рассылки, диалоги вход/выход, suppression/stop-lists, антиспам-маркинг, deliverability-чекер. Стек: NestJS + Prisma + PostgreSQL + BullMQ + Redis, фронт на React + Turborepo. Tenant-изоляция через отдельную БД на пользователя. Главная особенность — пофайловая верификация попадания исходящих писем в инбокс через сеть seed-mailboxes. Архитектурное решение: UI = MCP Когда стало понятно, что MCP станет дефолт-стандартом для агентного доступа к SaaS, стандартный выбор был: писать отдельный agent-API mirror поверх существующего веб-API, или сделать единую поверхность. Выбрали второе. Все эндпоинты живут под /api/*. Перед ними HybridAuthGuard, который умеет резолвить либо сессионный cookie (UI), либо Bearer-ключ формата ldm_pk_* (MCP/voice/external agent). Дальше — один контроллер, один scope-чек, одна бизнес-логика. typescript
// упрощённо @Injectable() export class HybridAuthGuard implements CanActivate { async canActivate(ctx: ExecutionContext): Promise<boolean> { const req = ctx.switchToHttp().getRequest(); // 1. Bearer (agent / MCP / voice skill) const m = req.headers.authorization?.match(/^Bearer (ldm_pk_\w+)$/); if (m) { const key = await this.apiKeys.verifyHash(m[1]); if (!key) throw new UnauthorizedException(); req.user = key.user; req.scopes = key.scopes; // gated по grant return this.checkScopeFor(req); } // 2. Session cookie (web UI) const session = await this.sessions.fromCookie(req); if (!session) throw new UnauthorizedException(); req.user = session.user; req.scopes = ['*']; // UI = full scope return true; } }
Каждая capability описана в /.well-known/agent-card.json (A2A discovery) со своим scope-ом: email:send, crm:read, dialogs:write, mailing:write, и так далее. Bearer-ключ выпускается с явным набором scope-ов — голосовому навыку можно выдать ограниченный ключ, который умеет читать диалоги и слать письма из конкретного аккаунта, но не имеет доступа к exports, billing, suppression management. MCP-сервер Опубликован как npm-пакет ldm-crm-mcp. Под капотом тонкая обёртка над /api/*: берёт LDM_API_KEY из env, проксирует MCP-tool вызовы в HTTP. ~30 инструментов на частые операции, ~120 эндпоинтов всего доступно через generic invocation. Конфиг Claude Desktop / Cursor: json
{ "mcpServers": { "ldm-crm": { "command": "npx", "args": ["-y", "ldm-crm-mcp"], "env": { "LDM_API_KEY": "ldm_pk_..." } } } }
Подключение к Яндекс Алисе Схема навыка:
- Голос → STT (Яндекс) → текст
- Текст → backend навыка → выбор MCP-инструмента + параметры
- MCP tool call → /api/* LDM → ответ
- Ответ → формулировка реплики → TTS Алисы
В роли «мозга» в backend навыка — Claude через API. Он интерпретирует свободную речь и выбирает нужный tool из MCP-списка. Это избавляет от необходимости писать grammar в навыке для каждой команды. Аутентификация: account linking через Yandex OAuth → пользователь получает в LDM привязку к Yandex ID, навык получает Bearer-ключ с ограниченным scope (dialogs:read, dialogs:write, mailing:write, contacts:read). Деструктивные действия (запуск рассылки, отправка письма, апдейт сделки) требуют голосового подтверждения — навык проговаривает summary и ждёт «да». Чтение и брифинг — без. Полевой кейс: VODEXPO 2026 22 мая 2026. Москва, последний день водохозяйственной выставки. Клиент работает на стенде. Подходит ландшафтный дизайнер, просит каталог решений по водоёмам. Клиент не за компьютером:
> Алиса, разошли каталог решений по водоёмам по всем подписавшимся ландшафтным дизайнерам. > Найдено: 247 контактов в сегменте "ландшафтные дизайнеры — подписка". Шаблон: "Каталог решений по водоёмам v3, май 2026". Подтвердить отправку? > Да. > Отправляю.
Что происходит под капотом (Claude-агент в backend навыка решает выполнить такую последовательность): bash
# 1. Резолв сегмента GET /api/contacts?tagId=landscape-designers&subscribed=1&pageSize=500 → 247 contacts # 2. Резолв креатива GET /api/creatives?search=каталог+водоёмы&latest=1 → creativeId # 3. Создание mailing task POST /api/tasks { "methodId": 2, "creativeId": "cmoue9...", "contactListId": "<ad-hoc>", "accountId": "<account>" } → taskId, status: DRAFT # 4. Self-approve (scope: mailing:write) POST /api/mailing/$TASK_ID/approve { "note": "Voice-approved, designer at VODEXPO booth" } # 5. Старт POST /api/tasks/$TASK_ID/start → status: ACTIVE
20 секунд — рассылка ушла. Дальше начинается то, ради чего, собственно, всё и затевалось. Per-message inbox verification Стандартная схема у cold/B2B email-платформ: warm-up + inbox rotation + pre-flight inbox placement test (отправили 20 писем на seed-mailboxes до запуска, посчитали процент в инбоксе). Это статистическая оценка по сэмплу до факта. У LDM схема другая: каждое реальное исходящее письмо после отправки верифицируется через сеть seed-mailboxes. На каждого провайдера развёрнуто 10–30 seed-ящиков (для Gmail и Outlook — около 100 каждый). Грубо схема такая: при отправке SMTP → реальный получатель параллельно создаётся test twin на seed-ящик соответствующего провайдера с теми же заголовками, body, аккаунтом-отправителем. Через IMAP опрашиваются папки INBOX vs SPAM/JUNK/Quarantine, результат пишется в поле placement диалога. Это не идеальный proxy — seed-ящик ≠ конкретный реальный получатель, провайдер может фильтровать индивидуально по recipient-сигналам. Но это сильно лучше pre-flight теста по трём причинам:
- Проверка идёт по каждому реальному отправлению, а не по выборке.
- Учитывается актуальное состояние репутации в момент отправки (а не за день до запуска кампании).
- Падение в спам у конкретного провайдера ловится в реальном времени — и срабатывает автоматический pause, если процент spam за окно превышает порог.
Endpoint, который опрашивает навык после рассылки: bash
GET /api/dialogs/stats?taskId=$TASK_ID { "total": 247, "placement": { "inbox": 231, "spam": 4, "unchecked": 12 }, "byProvider": { "gmail": { "inbox": 142, "spam": 1 }, "yandex": { "inbox": 47, "spam": 0 }, "outlook": { "inbox": 18, "spam": 3 }, ... } }
Алиса возвращает голосом: «Отправлено 247. В инбоксе 231, в спаме 4, ещё 12 проверяются. Outlook просел — 3 в спаме из 21». Биллинг — за 231 inbox-доставленных. 4 спам и 16 заблокированных не тарифицируются. Где голос работает плохо Без маркетингового лоска. Голос покрывает 20–30% операций оператора, не больше. Остальные 70% неудобны или невозможны. Работает хорошо:
- Утренний брифинг по входящим диалогам.
- Запуск заранее настроенной рассылки по известному сегменту.
- Ответ на конкретное входящее письмо (короткий).
- Проверка статуса доставки конкретного письма или кампании.
- Ad-hoc вопросы по статистике.
Не работает:
- Сложные многопараметрические фильтры (вроде «компании Москва + 50–500 сотрудников + e-commerce + без активности 30 дней + tag X»). Это удобнее в UI.
- HTML-вёрстка/правка креативов.
- Дизайн многошаговых пайплайнов (best-time-sending, последовательности follow-up, A/B-ветвления).
- Распознавание латинских доменов / имён компаний. Алиса систематически слышит Apple как «Эппл», Acme как «Акме». Лечится фонетической нормализацией на бэке через словарь из CRM, но точность ~70–85%, не 100%.
Хрупкие места:
- Refresh OAuth-токенов Yandex ID. Особенно если пользователь меняет пароль — навык теряет привязку, требуется переавторизация.
- Подтверждения в шумной среде. На стенде, в машине с открытыми окнами «да» распознаётся через раз.
- Латентность. Цепочка STT → Claude (intent + tool selection) → MCP → /api/* → ответ → формулировка → TTS — суммарно 4–8 секунд на типовой команде. Для email-операций приемлемо, для conversational UX чувствуется.
Tradeoffs архитектуры MCP — это транспорт. Полезность зависит от того, что через него экспонируется. У многих CRM-платформ (HubSpot, Salesforce DX) MCP read-only или ограничен подмножеством объектов. У LDM через MCP доступна полная UI-поверхность, включая запуск рассылок и self-approve — это полезно для агентов, но требует разумной модели scope-ов и подтверждений на стороне клиента (навыка / агента). Архитектурное решение «UI = MCP» имеет цену. Любое расширение API автоматически становится агент-callable. Это требует дисциплины — нельзя положить в /api/* что-то, что должно быть UI-only по соображениям UX или безопасности. На практике это решается scope-ами и доп. middleware для отдельных handler-ов, но это нагрузка на дизайн. Голос как UI — узкая ниша. Это не «новый интерфейс взамен дашборда». Это дополнение для конкретных сценариев — мобильности, занятых рук, быстрого брифинга. Прибавляет ценности на 10–15% операций, не больше. Что дальше
- MCP-сервер v2 с явной JSON Schema для каждого tool (сейчас многие возвращают свободный JSON, агенту приходится самостоятельно парсить).
- Подключение к ChatGPT MCP Apps directory.
- Voice-friendly dialogs/stats — плоский ответ, короче, без вложенных объектов, чтобы TTS не глотал секунды на проговаривании.
- Поддержка Apple Intelligence через MCP App Extensions, как только Apple откроет это для third-party (по обещаниям — Q3 2026).
Доки публичные: developers.live-direct-marketing.online. Вопросы по архитектуре / реализации — в комментариях или в почту.-Источник
|
|
|
|