Привет! Меня зовут Михаил Васильев, я разработчик Битрикс24.
На портале Битрикс24 есть ИИ-помощник для пользователей. Сначала он назывался Марта, отправлял запросы в LLM и умел только отвечать пользователям текстом. Когда мы начали масштабировать и улучшать Марту, она научилась делать и другие вещи, например настраивать CRM и управлять документами.
Когда мы только начинали добавлять новые функции, было несколько способов добавить ИИ-агенту работу с инструментами. Мы выбрали MCP и не прогадали. В статье рассказываю подробнее, как это работает и в каких случаях её стоит использовать.
Что было на старте: агент и function calling
Чтобы пользователям было проще ориентироваться в возможностях Битрикс24, мы добавили ИИ-инструмент. Сначала он назывался Марта, а потом эта логика развилась в агента следующего уровня — BitrixGPT.
Со временем мы решили масштабировать возможности помощника, чтобы он не просто отвечал текстом, а мог выполнять и другие действия: например, получить список задач из бизнес-портала, создать новую задачу или обратиться к другим данным. Для этого мы развивали агентские способоности.
ИИ-агент — программа вокруг языковой модели. Модель отвечает за понимание запроса, генерацию ответа, выбора инструментов, которые будет использовать, а агент — задает для модели границы и правила работы.
Первый вариант агента — простая схема: агент получил запрос, выполнил действие, дал ответ. Для таких задач достаточно сделать специализированного агента на function calling: механизме, когда разработчики заранее описывают модели доступные функции. Например: «получить задачи», «создать задачу», «получить события календаря». Тогда модель видит эти описания и в нужный момент просит агента вызвать подходящую функцию.
В начале это нормальный путь, но только пока действий немного. Если агент должен уметь делать всего несколько вещей, их можно описать прямо в Python-коде и дать модели право вызова этих функций. После этого нужно протестировать старые сценарии и выкатить новую версию сервиса. Одна-две таких доработки выглядят терпимо.
До MCP агент мог работать только через function calling.
Другой вариант — более общий агент, который выполняет не только жёстко прописанные сценарии, но и сам выбирает подходящий инструмент под задачу пользователя. Такому агенту уже недостаточно знать одну-две функции. Ему нужен актуальный каталог возможностей: какие инструменты доступны, что они делают, можно ли использовать их от имени конкретного пользователя.
Function calling для агента, которого планируется расширять, недостаточно, потому возможностей нужно больше: нужно добавить работу с календарём, потом — с CRM, потом — с другими разделами портала. При старом подходе каждую новую группу функций нужно добавлять в код агента, описывать для модели и обновлять сам сервис. Получается, чтобы добавить новый пласт функций, нужно каждый раз заново собирать агента и статически прописывать ему эти функции.
Другая проблема в том, что так агент постепенно превращается в тяжёлую систему, где список возможностей жёстко зашит внутрь. То есть агент получает полный каталог возможностей при работе с любым пользователем, но в реальности у портала сложная система с ограничениями: много модулей, разные права доступа, пользователи и установки.
Поэтому нужен был способ, чтобы агент мог получать новые инструменты динамически для каждого пользователя отдельно.
Почему при масштабировании выбрали MCP
Протокол MCP позволяет вынести инструменты за пределы агента во внешний сервис. Агент обращается к MCP-серверу, получает список доступных инструментов и их описания, а потом сам решает, что вызвать. В случае Битрикс24 источником этих инструментов остаётся портал. Он знает, какие модули включены, какие права есть у пользователя и какие действия ему можно выполнять. MCP-слой превращает эти возможности в каталог инструментов, понятный агенту:
Агент спрашивает, какие возможности ему доступны.
MCP-сервер отдаёт агенту список инструментов с их описанием и нужными параметрами для использования.
Для Битрикс24 MCP был хорошим вариантом по двум причинам.
Инструменты можно развивать отдельно от агента. Если на портале появляется новая группа функций, её можно отдать через MCP, а не переписывать каждый раз Python-код агента.
Разные пользователи могут получать разные наборы инструментов. Например, у одного пользователя есть доступ к календарю, у другого — к CRM, у третьего — только к задачам. Тогда агенту не нужно заранее держать один большой общий список для всех. Вместо этого он спрашивает портал через MCP-слой и получает ровно то, что разрешено конкретному пользователю, потому что у Битрикс24 инструменты зависят от пользователя и портала.
Так MCP стал основой для того, чтобы Марта могла сходить на портал и выполнить действие внутри Битрикс24.
Как выглядела первая версия работы с MCP
Первая версия была внутренней: Марта работала в закрытом контуре Битрикс24, а между агентом и порталом поставили MCP-прокси. Прокси принимал запросы от Python-агента и передавал их на портал.
Общая логика была такой:
Пользователь обращается к помощнику Марта в интерфейсе Битрикс24.
Сообщение принимает PHP-часть портала.
Сообщение передаётся его в Python-сервис, где работает агентская логика Марты.
Марта через MCP-прокси вызывает инструменты портала.
Ответ возвращается обратно в PHP и показывается пользователю.
Марта как пользовательский помощник видна в интерфейсе Битрикс24. Марта как агентская программа работает в Python-сервисе. PHP-портал передает ей запросы и получает ответы обратно.
Получалось, что начало и конец процесса находились в PHP: туда приходило сообщение пользователя, оттуда же в итоге возвращался ответ. В середине работал Python-сервис с агентом. Сначала Марта была простым циклом и в одном проходе могла, например, дёрнуть список задач или создать новую задачу.
Как добавили авторизацию в первую версию
Когда агент вызывает инструмент портала, порталу нужно понимать, от имени какого пользователя идёт вызов. Это важно, потому что если пользователь не имеет доступа к CRM, агент от его имени тоже не должен получать инструменты CRM.
В ранней версии протокола MCP не было готовой нормальной авторизации. Поэтому для быстрого внутреннего решения команда сделала свою схему: подписанный идентификатор пользователя. Это user ID с дополнительной подписью, которая подтверждает, что ID выдан самой системой. В итоге получается так:
Без идентификатора сервису передают просто «пользователь А»
С идентификатором передают «пользователь А + подтверждающая подпись».
Внутри закрытого контура этот идентификатор можно даже не проверять на промежуточном этапе, потому что сообщение извне недоступно. Важно проверить, что подпись верная в конечных точках и что при транзите ничего не подменили. Эта схема позволяла быстро авторизовать вызовы и точно знать, что инструменты вызываются от конкретного пользователя на конкретном портале.
Как появился внешний MCP
Следующим шагом нужно было сделать свой MCP-сервер уже для клиентов. Понадобились две доработки:
Транспорт — способ, которым клиент и сервер передают данные друг другу. Агенту и серверу нужно обмениваться сообщениями: получить список инструментов, вызвать инструмент, вернуть результат.
Полноценная авторизация, которая может работать для клиентов. Для внешнего MCP уже нельзя опираться на внутреннюю схему с подписанным user ID. Внешний клиент находится за пределами закрытого контура, поэтому нужен более стандартный и управляемый механизм доступа.
На PHP-стороне нужно было добавить новый способ авторизации, а клиентский сервер по сути вызывал те же самые инструменты.
Для доработки транспортного слоя команда перешла от раннего варианта MCP на SSE к новому внешнему входу на Streamable HTTP.
Для авторизации добавили OAuth — стандартный способ дать приложению доступ к данным пользователя без передачи пароля. Пользователь разрешает доступ, система выдает токен, а потом по этому токену можно проверять права.
Плюсы и минусы раннего MCP
Anthropic представила MCP в ноябре 2024 года. Задача расширять возможности ИИ-агента в компании появилась в марте 2025, и мы выбрали эту технологию.
Что было хорошо: ранняя ставка дала выигрыш, потому что команда уже успела построить архитектуру вокруг протокола, который потом развился: например, добавили нормальную авторизацию и нормальный транспорт.
Что было минусом: технические неудобства. Протокол развивался, менялся способ передачи данных, появлялись новые стандартные решения. Приходилось поддерживать эти изменения и адаптироваться. Это обычный минус раннего внедрения: сначала чего-то нет, потом это появляется по индустриальному стандарту, и вокруг этого нужно достраивать систему.
Как агент получает список инструментов для каждого пользователя
У Битрикс24 сложная доменная структура.
Отдельная функциональная зона продукта называется доменной областью. Например, задачи, календарь или CRM. Логическое представление такой зоны как отдельного источника инструментов называется виртуальным MCP-сервером. Для агента это выглядит как отдельный набор возможностей. То есть календарь будет одним виртуальным сервером, CRM — другим, задачи — третьим.
У разных пользователей отличается доступ к доменным областям и инструментам внутри них: кому-то CRM доступна, кому-то — нет, потому что часть возможностей закрыта правами. Если агенту каждый раз обходить все виртуальные MCP-серверы по очереди и узнавать, какие инструменты какому пользователю доступны, получается лишняя работа. Поэтому команда добавила поддержку запроса к порталу, чтобы портал возвращал общий список инструментов уже с учётом конкретного пользователя.
Tool Hell и решение в виде mcp-cli
Когда агента начали развивать дальше, инструментов стало много.
Проблема: когда у агента слишком много инструментов, и их описания начинают забивать контекст модели. Это называется Tool Hell.
Если в контекст положить слишком много описаний инструментов, модель ещё до начала работы получает огромный технический справочник. Например, пользователь может обсуждать постановку задачи, и агенту в этот момент совсем не обязательно знать, как добавлять события в календарь или делать их рекуррентными. Но если все инструменты заранее загружены в контекст, эта информация всё равно там лежит и забивает контекст.
Tool Hell — прямое следствие роста возможностей. Чем больше агент умеет, тем больше описаний нужно дать.
Решение: с MCP можно работать как с интерфейсом командной строки CLI. В обычной разработке через CLI пишут команды вроде «покажи список» или «найди файл». Тогда агент получает возможность выполнять команды в Shell.
Если использовать CLI, агенту не нужно сразу загружать в контекст все инструменты. Он может сам запросить нужный список, например: показать доступные инструменты, найти инструменты с календарем в названии, открыть список инструментов конкретного сервера. С таким подходом ИИ может сначала понять задачу пользователя, потом через команду найти подходящий инструмент и только после этого вызвать его.
Параллельно изменилась сама агентская среда. Агент стал ближе к кодинговому агенту: у него появилась возможность выполнять команды, записывать данные в файлы и читать их обратно. Это помогло решить ещё одну проблему — работу с большими ответами инструментов.
Обработка длинных ответов
У инструментов портала могут быть длинные ответы, если агент запросил большой список задач или крупный набор данных. Если такой ответ целиком попадёт в контекст, он займёт много места и ухудшит дальнейшую работу модели.
Чтобы не перегружать контекст, мы добавили такую обработку: длинный ответ сохраняется в файл, и агент может прочитать из него нужную информацию по мере необходимости. Так получается аккуратно: модель не обязана сразу читать весь массив данных.
Кому будет полезен MCP
Мы взяли базовую технологию, и саму по себе её не меняли. Но при этом у нас получилось достроить снаружи полезные вещи.
В итоге благодаря MCP из простого агента с несколькими функциями выросла целая инфраструктура для работы с инструментами Битрикс24 — с правами, разными пользователями, внешними подключениями и защитой контекста модели.
По нашему опыту можно дать такую рекомендацию: выбирать MCP сейчас нужно, если у вас есть расширяющийся набор инструментов. При этом стоит помнить, что есть и альтернативы в виде вызова REST-методов напрямую из модели или использования скиллов с заготовленными скриптами для выполнения определённых действий.
А главный совет такой: не останавливаться на одной технологии и всегда стараться совмещать подходы. В следующий раз расскажем, как это делаем мы =)