Главная

Блог

AI Agents & Orchestration

Enterprise MCP

Josh Cramoy

Enterprise Architect

Окт 20, 2026

Один инструмент. Семь приложений. Более тысячи возможностей, которые обнаруживают, тестируют и поддерживают себя сами. Вот архитектура, по сравнению с которой традиционный MCP-сервер выглядит как нарисованная от руки карта.

Каждая беседа с ИИ-платформой рано или поздно сталкивается с одной и той же издержкой — стоимостью контекста. Загрузите агента стандартным набором Google Workspace, и вы передадите ему схемы инструментов из Gmail, Drive, Calendar, Docs, Sheets, Slides и Contacts. Семь серверов. Десятки определений инструментов. Каждое из них постоянно находится в контексте модели, оплачиваясь на каждом отдельном шаге, независимо от того, нужны ли они для задачи. Затем кто-то должен все это поддерживать: каждый новый эндпоинт, выпускаемый Google, каждый формат полезной нагрузки, каждое OAuth-подключение, каждую оптимизацию — вручную, для каждого инструмента, вечно.

Мы создали другой подход. MCP-сервер Google Workspace от Workato охватывает все семь сервисов через один инструмент. Не один инструмент на приложение. Один инструмент плюс два хелпера, которые загружаются один раз и больше никогда не нужны. За ними располагается семантический слой из более чем 1000 проверенных и надежных действий, а за ним — офлайн-цикл самообучения, который самостоятельно обнаруживает новые возможности Google, изучает язык, на котором действительно говорят реальные пользователи, и продвигает функцию только после того, как она успешно проходит canary-тест и состязательную проверку тремя ИИ-моделями.

Вот та мысль, к которой я постоянно возвращаюсь: когда Google выпускает новую функцию, не требуется никакой инженерной работы. Никаких обновлений схем. Никаких релизов. Сервер замечает ее, тестирует и добавляет. Люди ушли из бизнеса технического обслуживания, а сервер в процессе стал умнее.

Счет за контекст сегодня

Экономика заложена в самой архитектуре.

Одна схема инструмента вместо десятков. Обычная многосерверная установка оплачивает каждое определение инструмента на каждом шаге каждой сессии. Наша фиксированная база — это один основной инструмент и два легковесных хелпера, которые загружаются единожды. Все остальное, все более тысячи возможностей, хранится на стороне сервера в семантическом слое и запрашивается во время вызова. Пользователь никогда не платит за функции, которые он не использует.

Никаких LLM на критическом пути. Ранняя версия архитектуры предполагала наличие ИИ, интерпретирующего каждый запрос. Это работало медленно и галлюцинировало, потому что ИИ просто выдумывает вещи, если его не заставлять поступать иначе. Поэтому ИИ полностью убрали из пути обслуживания. Критический путь представляет собой детерминированный поиск по семантическому слою: фраза сопоставляется с возможностью, возможность выполняется, готово. Именно поэтому вызовы выполняются быстро, воспроизводимо и дешево, а точность стандартных операций чтения и записи приближается к 100%.

Рабочие процессы сводятся к одиночным вызовам. Сервер отслеживает, какие возможности используются вместе, анализирует успешные последовательности и превращает их в составные функции. Черновик письма, отправка, архивация цепочки: один вызов вместо трех и один шаг модели вместо трех. Каждый несовершенный вызов — это целый шаг контекста, за который вы не платите.

Создан дешеветь, а не просто быть дешевым сегодня. Это тот пункт, на который я бы поставил. Каждый формат ответа на сервере определяется данными в реестре, а не кодом или рецептом. Когда нам нужна более компактная проекция по умолчанию для какой-либо возможности, возвращающая поля, необходимые агенту для принятия следующего решения, оставляя остальное на расстоянии одного перехода, это строка конфигурации, а не инженерная задача. Мы измерили именно этот рычаг при переработке Gmail MCP и сократили вывод инструментов почти на 80% во всех рабочих процессах. На этом сервере та же оптимизация применима к любой из более чем 1000 возможностей как к данным. Оптимизация здесь — это не проект. Это правка таблицы.

Как сервер остается актуальным без единого инженера

Раз в день сервер сканирует публичный каталог обнаружения Google — машиночитаемое описание каждого эндпоинта и схемы, публикуемых Google. Изменения версий, новые эндпоинты, новый функционал — абсолютно все.

Результат говорит сам за себя. Когда Google добавляет классную новую функцию в Gmail, с нашей стороны ничего не происходит. Никаких спринтов, изменений схем или деплоев. Сканер обнаружения замечает ее, цикл обучения подхватывает, а конвейер продвижения решает, появится ли она и в каком виде. Сервер обслуживает себя сам.

Цикл самообучения

Пока выполняется критический путь, фоновый цикл отслеживает, что люди реально говорят и делают. Каждый запрос попадает в систему как событие обучения. Появляющиеся фразы группируются, и новые возможности должны заслужить право на добавление: алгоритм требует реальных доказательств, наблюдаемых неоднократно, прежде чем цикл вообще отреагирует. Совершенно новая фраза или непроверенный эндпоинт не продвигаются при первой же встрече. Они отправляются на хранение вместе с собранными доказательствами, поэтому к моменту созревания эндпоинта сигнал о спросе уже готов.

В этом разница между статичным MCP-сервером и живым. Большинство серверов знают только то, что человек ввел в них на этапе сборки. Этот сервер изучает собственный трафик.

Canary-тестирование: докажи, прежде чем продвигать

Если вы работали в инженерии, вам знаком этот термин. Отправьте канарейку в угольную шахту и посмотрите, вернется ли она.

Прежде чем какая-либо фраза попадет на путь обслуживания, система запускает canary-тест: она прогоняет реальные вызовы через тестовую учетную запись песочницы, создавая тестовое письмо, удаляя его, создавая тестовый слайд, и сравнивает результат с тем, что было обещано фразой. Если фраза не дает ожидаемого результата в песочнице, она не выпускается. Пользователи никогда не сталкиваются с возможностью, которая не была предварительно протестирована от начала и до конца.

Три ИИ-модели, контролирующие друг друга

Вот в чем секретный ингредиент, и началось все с проблемы, с которой сталкивалась любая ИИ-команда: предоставленная самой себе, отдельная модель судьи становится излишне сговорчивой. Вы спрашиваете: «Это годится для продвижения?», и она отвечает: «Да, вроде нормально, давай запускай». Затем плохая фраза попадает в семантический путь и выдает ошибку прямо перед пользователем.

Поэтому я перестал доверять одной модели и нанял комитет.

Судья. Одна модель с четкими инструкциями взвесить доказательства canary-теста и сформировать мнение.

Оппонент. Совершенно другая модель с другими весами и противоположными инструкциями: атаковать этот тезис. Найти изъян. Ее задача — полностью не соглашаться, что заставляет первую модель быть честнее, потому что заставить один ИИ контролировать другой гораздо сложнее, чем заставить ИИ оценивать собственную домашнюю работу.

Арбитр. Третья роль, которая принимает оба мнения вместе с жесткими результатами запусков в песочнице и выносит вердикт: продвинуть, отправить в отставку или отложить для последующих доказательств.

Продвижение означает, что фраза прошла порог оценки, выдержала реальную состязательную атаку и была подтверждена в рабочей песочнице. Такова планка для доступа к критическому пути, и именно поэтому показатель точности остается на высоте.

Под капотом

Все это работает на Workato, и архитектура именно такая, какую вы надеетесь увидеть: уровень данных, MCP-инструмент и офлайн-цикл LLM.

Семантический слой представляет собой набор таблиц данных Workato, поддерживаемых в актуальном состоянии рецептами автоматизации. Семантический реестр хранит каждую конечную точку с ее ключом индекса, идентификатором возможности, сопоставлением служб и состоянием активации. Индекс извлечения сводит все это к компактной таблице поиска с контрольными суммами и указателями, благодаря чему запрос обрабатывается за считанные строки вместо сканирования тысяч. Подсказки об ошибках учат сервер самовосстанавливаться при сбоях вышестоящих вызовов. Майнеры пробелов в покрытии отслеживают запросы пользователей, с которыми слой пока не может справиться.

Путь обслуживания работает на кастомном коннекторе, а не на стандартных от Google. Это тысячи строк кода на Ruby, и версия уже 121-я, если хотите представить, сколько итераций потребовалось для доработки. Источником вдохновения для этого паттерна послужила наша команда Enterprise Data MCP, которая создала самообучающийся семантический слой для данных: я решил, что нет никаких причин не применить это к прикладному MCP, и оказалось, что их действительно нет.

Каждый вызов выполняется от имени конечного пользователя через систему идентификации Workato (VUA). Агент действует за вас в рамках ваших разрешений. Никаких общих служебных аккаунтов, выдающих себя за всех подряд. Идентификация, выполнение и управление объединены на одной платформе.

Куда это движется дальше

Этот паттерн не является чем-то специфичным для Google. Семантическому слою все равно, что находится за ним, а это значит, что тот же подход применим к Salesforce, Workday или любому другому приложению с описываемым API. Пойдите дальше, и вы объедините целый бизнес-процесс: CRM, инструмент обогащения, презентацию, электронное письмо, изученные как единый наблюдаемый рабочий процесс и предоставленные как один вызов. Определите процесс как таблицу данных, заполнив ее тем, что люди действительно делают по порядку, и семантический сервер сможет выполнять весь рабочий процесс.

Строго говоря, эта последняя часть еще не доказана. Но в Workato не было ничего, что я не смог бы построить, проявив немного креативности и упрямства, так что я ставлю на его успех.

Традиционная модель MCP-серверов, в которой люди вручную определяют каждый инструмент, поддерживают каждую схему и оптимизируют каждый полезный блок данных, не просто дорога. Она избыточна. Сервер, который поддерживает себя сам, уже здесь, и он умнее, чем в день своего выпуска.