ИИ-агенты уже умеют писать письма, резюмировать встречи и искать ответы в базе знаний. Но в корпоративной среде этого мало. Пока агент только работает с текстом, он остаётся помощником рядом с процессом, а не участником самого процесса.
Чтобы агент действительно помогал в корпоративных бизнес-приложениях по типу ITSM, SDLC или других enterprise-сценариях, ему нужен безопасный доступ к действиям: получить данные, проверить статус, создать задачу, найти связанный объект, сходить во внешнюю систему и вернуть результат пользователю. Причём сделать это не напрямую через базу данных и не через случайный API-вызов, а в управляемом контуре — с правами, описанными инструментами и понятной логикой исполнения.
В этой статье совместно с технологическим партнёром Ainergy, который разрабатывает инфраструктурный слой GenAI-платформы SimpleOne, разберём, как для такой задачи можно использовать MCP и как устроить агентскую архитектуру так, чтобы LLM не просто генерировала текст, а работала с корпоративными процессами.
В корпоративной среде агенту нужен управляемый доступ к действиям. Например, получить список инцидентов, создать задачу в SDLC, найти связанную услугу, проверить статус изменения, забрать данные из внешней системы или обновить запись. При этом агент не должен работать напрямую с базой данных или вызывать случайный набор API. Ему нужен контролируемый контур: с понятными правами, описанными инструментами, проверяемыми параметрами и предсказуемой логикой выполнения.
Для этого используется MCP — Model Context Protocol. Anthropic представила его 25 ноября 2024 года как открытый стандарт для подключения AI-приложений к источникам данных, бизнес-инструментам и средам разработки. Протокол задает единый способ, по которому агент видит доступные инструменты, понимает их параметры и вызывает нужные действия.
Интерес к MCP связан с общим ростом agentic AI — подхода, при котором ИИ отвечает на запрос и выполняет действия через подключенные инструменты. По прогнозу Gartner, к концу 2026 года до 40% enterprise-приложений будут включать task-specific AI agents. Forrester относит agentic AI к технологиям, которые помогут компаниям гибче автоматизировать бизнес-процессы, но подчёркивает потребность в точности, доверии и координации. McKinsey связывает масштабирование агентских сценариев с подготовкой данных, архитектуры и рабочих процессов к тому, что агенты будут работать с корпоративными действиями.
Для корпоративной платформы это меняет требования к ИИ. Агенту мало уметь отвечать в чате. Ему нужен безопасный способ работать с действиями: получить список инцидентов, создать задачу в SDLC, найти связанную услугу, проверить статус изменения, забрать данные из внешней системы или обновить запись. MCP помогает описать такие действия единым способом и передать их агенту как управляемый набор инструментов.
Если упростить, MCP описывает взаимодействие агента с внешними системами через tools. Tool — это действие, которое агент может использовать во время работы: получить данные, найти документ, создать запись, проверить статус или обратиться к внешней системе. MCP-сервер публикует список tools, их описания и параметры. MCP-клиент получает этот список и передаёт его в контекст LLM. Далее модель, исходя из поставленной задачи и перечня доступных инструментов, определяет, какой tool следует использовать, а клиент обеспечивает выполнение этого вызова и передачу результата обратно модели.
MCP не заменяет API и не отменяет существующие интеграции. В большинстве случаев MCP-сервер использует те же API под капотом.
Его ценность в другом: он предоставляет агентам стандартизированное описание действий, позволяя подключать новые системы без разработки отдельной интеграционной логики под каждую модель или агентный фреймворк.
В SimpleOne GenAI мы развиваем этот подход внутри платформы. MCP-модуль уже доступен внутри SimpleOne GenAI. Сейчас мы расширяем набор сценариев, проверяем их на enterprise-процессах и уточняем, какие модели взаимодействия с агентами дают наибольшую пользу корпоративным командам.
Коротко: мы рассматриваем три сценария
Дальше разберём, как устроена эта модель и что важно учитывать в enterprise-сценариях: права, безопасность, аудит, ошибки и эксплуатацию.
Упрощенно схема выглядит так:
Сначала договоримся о терминах
Вокруг агентов много маркетингового шума, поэтому важно разделить несколько сущностей.
Агент работает в заданном контуре: использует только описанные инструменты, передает параметры и возвращает результат пользователю. В упрощённом виде это конфигурация: описание задачи, инструкции, выбранная модель, ограничения и набор инструментов, которыми агент может пользоваться. «Мозгом» выступает LLM, но сама по себе модель не знает, какие действия разрешены в конкретной корпоративной системе.
Tool — термин из MCP. Так называется действие, которое агент может вызвать через MCP-сервер: получить данные, найти документ, создать запись, обратиться к внешней системе. Во внутренних сценариях SimpleOne похожую роль выполняют AI-методы. Они тоже дают агенту доступ к действиям, но исполняются внутри платформы.
MCP-сервер — слой вокруг внешней системы или её API. Он описывает доступные tools и выполняет их. Например, если у компании есть, например, Confluence, MCP-сервер может предоставить tool «получить документ по названию». Агент получает описание tool, вызывает его с параметрами, а MCP-сервер обращается к Confluence и возвращает результат.
MCP-клиент — часть агентской системы, которая подключается к MCP-серверу, получает список tools и вызывает нужный tool. В сценариях SimpleOne эта логика нужна, когда агент внутри платформы работает с внешними MCP-серверами.
Это разделение важно для точности. Не каждый внутренний метод агента — это MCP. Внутренние AI-методы SimpleOne могут быть похожи на tools по роли в агентском сценарии, но они не обязательно используют MCP-протокол. Их ценность в другом: они нативно исполняются внутри платформы, рядом с её объектной моделью, данными, бизнес-правилами и интеграционными возможностями.
Базовая модель SimpleOne: агент, адаптер и метод
Чтобы LLM могла вызвать инструмент, этот инструмент нужно описать понятным для модели способом. Модель должна знать, что инструмент делает, какие параметры принимает, когда его стоит использовать и какой результат он возвращает.
Без такого описания агент либо останется обычным текстовым помощником, либо начнёт «догадываться», как устроена система. В enterprise это неприемлемо: агент не должен придумывать API, менять данные напрямую или обходить бизнес-логику платформы.
В SimpleOne GenAI эту задачу решает связка «агент — Nexus — адаптер — метод». Ниже разберём роли агента, адаптера и метода, а к Nexus вернемся отдельно: он отвечает за управляемое подключение к LLM и другим сервисам.
Nexus — это единая сущность на платформе, определяющая правила маршрутизации к модели или нейросетевому сервису
Агент отвечает за прикладной сценарий. Например, один агент помогает анализировать инциденты, другой готовит сводку по задачам разработки, третий ищет информацию по связанным объектам. В конфигурации агента задаются его назначение, модель, стратегия работы, инструкции, ограничения и набор доступных инструментов.
Адаптер собирает инструменты, которые агент может использовать. Это контейнер методов, которые мы отдаём агенту в конкретном сценарии. Через адаптер агент получает «витрину» доступных операций: какие методы есть, что они делают, какие параметры принимают и какой результат возвращают.
Метод — отдельное действие, доступное агенту внутри SimpleOne. Если действие выполняется на стороне платформы, называем его AI-методом. Если действие приходит от внешнего MCP-сервера, используем термин tool. Для агента оба варианта похожи по структуре: есть описание действия, входные параметры и результат выполнения. Разница в месте исполнения: AI-метод выполняется внутри SimpleOne, tool — на стороне MCP-сервера.
Такой подход разделяет рассуждение и исполнение. LLM понимает запрос, выбирает инструмент и формирует параметры. Но само действие выполняет платформа или подключённый MCP-сервер. Для корпоративной среды это принципиально: бизнес-логика остаётся в управляемом контуре, а агент получает доступ только к явно описанным и разрешённым действиям.
На уровне потока выполнения агентский сценарий можно представить так:
Сценарий 1. Агент работает внутри платформы
Первый сценарий — самый близкий к платформенной логике. Агент создаётся внутри системы и использует её данные, бизнес-объекты, внутренние методы и интеграционные возможности. Для такого сценария не нужен отдельный внешний MCP-сервер, отдельный agent backend или дополнительная инфраструктура для исполнения действий.
Здесь важно отличие от «чистой» MCP-схемы с внешним сервером. Корпоративная платформа уже умеет работать с собственными таблицами, объектами, процессами, бизнес-правилами, скриптами и интеграциями. Поэтому часть действий можно описывать и исполнять внутри самой системы как AI-методы.
Например, пользователь просит агента: «Собери краткую сводку по критичным инцидентам за последние сутки».
Агент передаёт запрос в LLM. Модель понимает, что для ответа нужны данные об инцидентах, и выбирает соответствующий AI-метод из адаптера. Затем формирует параметры: период — последние 24 часа, приоритет — критичный. Callback метода выполняется на стороне платформы: обращается к данным, применяет фильтры, учитывает нужные правила и возвращает результат агенту.
После этого LLM работает уже не с предположениями, а с фактическими данными: группирует инциденты по услугам, выделяет повторяющиеся признаки, показывает динамику и формирует краткую сводку для пользователя.
Ценность такого сценария — в меньшей инфраструктурной сложности. Компании не нужно разворачивать отдельный MCP-сервер рядом с основной системой, настраивать дополнительные сетевые доступы и дублировать бизнес-логику во внешнем слое. Агент работает ближе к данным и процессам, с которыми должен взаимодействовать.
При этом внутренние AI-методы не стоит называть MCP-tools в строгом смысле. Это нативные инструменты агентского модуля. Они решают ту же прикладную задачу — дают агенту управляемый набор действий, — но исполняются внутри платформы, а не через внешний MCP-сервер.
Сценарий 2. Агент подключается к внешнему MCP-серверу
Второй сценарий нужен, когда агенту недостаточно внутренних данных и методов. В корпоративной среде процессы редко живут в одной системе. Задачи разработки могут находиться в Jira документация — в Confluence, метрики — в системе мониторинга, а сервисные процессы — в ITSM-контуре.
В такой архитектуре агенту нужен распределённый контекст. Если пользователь просит разобрать инцидент, агенту может понадобиться не только карточка обращения, но и связанные задачи разработки, комментарии инженеров, документация по сервису или данные о недавних изменениях.
Для таких сценариев в платформе можно подключать внешние MCP-серверы. Администратор регистрирует сервер, который публикует набор tools. Система получает их описание, а нужные tools можно добавить в адаптер конкретного агента.
С точки зрения агента это похоже на работу с внутренними AI-методами. У него есть адаптер, а внутри адаптера — доступные действия. Разница в том, что часть этих действий исполняется не внутри основной платформы, а на стороне внешнего MCP-сервера.
Например, специалист поддержки работает с инцидентом и просит агента: «Проверь, есть ли по этому инциденту связанные задачи в Jira, и кратко объясни, на каком этапе исправление».
Агент получает контекст инцидента: номер обращения, затронутую услугу, описание проблемы, приоритет и связанные объекты. Затем LLM выбирает внешний tool, который работает с Jira через MCP-сервер. Агент передаёт параметры поиска: идентификатор сервиса, ключевые слова из описания или ссылку на связанную задачу. Внешний MCP-сервер возвращает список задач, их статусы, ответственных и последние комментарии. После этого агент объединяет данные из ITSM-контура и Jira в один ответ.
Похожая логика работает с базой знаний. Допустим, пользователь просит подготовить краткий отчёт по последним статьям в Confluence. MCP-сервер Confluence предоставляет tool для получения документов. Агент видит этот tool, вызывает его с нужными параметрами, получает документы и передаёт их в контекст LLM для подготовки summary.
Для пользователя это один сценарий. Он не переключается между системами, не ищет связанные задачи вручную и не сопоставляет разные статусы. Агент берёт на себя сбор контекста, а корпоративная платформа остаётся точкой, где этот контекст используется внутри бизнес-процесса.
Плюс такого подхода — расширяемость. Если внешняя система уже предоставляет MCP-сервер, её инструменты можно подключать через единый механизм. Если готового MCP-сервера нет, его можно реализовать как отдельный слой вокруг API нужной системы и затем подключить к агентскому сценарию.
Сценарий 3. Платформа выступает как MCP-сервер
Третий сценарий работает в обратную сторону. В первых двух случаях агент находился внутри платформы. Но в enterprise агентская логика может жить и снаружи: в IDE, CLI-инструменте, отдельной AI-среде или специализированной агентской платформе.
Например, команда разработки может использовать агента в среде разработки. Аналитики могут работать с внешним AI-инструментом для подготовки требований. Инженеры эксплуатации могут запускать агентские сценарии из своего рабочего контура. При этом всем им может понадобиться доступ к корпоративным данным и действиям: создать задачу, найти инцидент, получить статус изменения, посмотреть связанную услугу или обновить запись.
Для этого платформа может сама выступать как MCP-сервер. Внешняя агентская система подключается к ней, запрашивает список доступных tools, получает их описание и вызывает нужные методы по стандартной MCP-логике.
В этом сценарии корпоративная платформа становится источником инструментов для внешних агентов. Она не просто принимает запросы через API, а описывает внешней агентской системе, какие действия доступны, какие параметры нужны и какой результат может вернуться.
Представим пример с разработчиком. Он работает во внешней AI-среде и просит агента: «Создай задачу в SDLC по этому дефекту, добавь краткое описание и свяжи её с текущим модулем продукта».
Агент обращается к MCP-серверу платформы и получает список доступных методов. Среди них есть метод создания задачи в SimpleOne SDLC. Агент формирует параметры: название, описание, тип задачи, модуль продукта, приоритет и дополнительные поля. Платформа принимает вызов, выполняет свою бизнес-логику и возвращает результат — например, номер созданной задачи и ссылку на запись.
Такой подход полезен компаниям, которые уже используют внешние агентские инструменты. Им не нужно переносить все сценарии внутрь основной системы. Вместо этого платформа может стать частью агентской экосистемы и предоставить внешним агентам управляемый доступ к корпоративным действиям.
При этом контроль над бизнес-логикой остаётся внутри системы. Внешний агент не работает напрямую с базой данных и не обходит правила процесса. Он вызывает опубликованные методы, которые выполняются на стороне платформы.
Прежде чем перейти к сценариям с MCP, отдельно зафиксируем роль Nexus. Без этого термина архитектура SimpleOne GenAI будет выглядеть неполной: агент выбирает действие, адаптер описывает доступные инструменты, метод выполняет конкретную операцию, а Nexus отвечает за подключение к сервису, который нужен агенту для работы.
Где здесь Nexus
В агентских сценариях Nexus отвечает за управляемое подключение к целевому сервису. Чаще всего это LLM: в Nexus задаётся, какую модель использовать, с какими параметрами, по каким правилам и через какой endpoint.
Но эта сущность шире, чем просто конфигурация модели. Через Nexus платформа может описывать взаимодействие и с другими нейросетевыми или внешними сервисами.
Для агентской архитектуры это инфраструктурный слой: агенту нужна модель или внешний сервис, а платформа должна подключаться к ним устойчиво и предсказуемо. Поэтому Nexus можно воспринимать как маршрут к сервису, через который агентский сценарий получает доступ к нужной модели или внешнему инструменту.
Что важно для enterprise-сценариев
Когда агент может выполнять действия в корпоративной системе, одного механизма вызова tools недостаточно. Важно заранее определить, что агенту разрешено делать, от чьего имени он действует и как компания сможет проверить его работу.
1. Права доступа
При работе с корпоративными процессами агент должен действовать в заданных границах: использовать только разрешенные инструменты, передавать ожидаемые параметры и возвращать результат через платформенную логику. Поэтому доступ к данным и действиям должен определяться не только набором tools, но и правилами платформы.
В целевой модели агент работает через явно опубликованные инструменты. Каждый инструмент описывает конкретное действие, параметры и ожидаемый результат. Это позволяет не отдавать агенту «всю систему», а предоставить ограниченный набор операций для конкретного сценария.
Для действий, которые меняют данные, может потребоваться отдельная политика: например, подтверждение пользователем, ограничение по роли или разделение tools на read-only и write-операции.
2. Аудит и трассировка
Если агент создал задачу, обновил запись или получил данные из внешней системы, это должно быть видно в журнале. Для эксплуатации и безопасности важно понимать:
кто инициировал запрос;
какой агент был вызван;
какая модель использовалась;
какой инструмент выбрала LLM;
какие параметры были переданы;
где исполнялся tool: внутри SimpleOne или на внешнем MCP-сервере;
какой результат вернулся;
было ли действие выполнено автоматически или после подтверждения.
Такая трассировка нужна не только для расследования ошибок. Она помогает улучшать сценарии: смотреть, где агент выбирает неподходящий инструмент, где не хватает параметров и какие действия чаще всего требуют ручного вмешательства.
3. Ошибки и недоступность инструментов
В реальных процессах внешняя система может быть недоступна, MCP-сервер может вернуть ошибку, а пользовательский запрос может быть неполным. Поэтому агентский сценарий должен учитывать не только успешный путь.
Например, если внешний tool недоступен, агент не должен придумывать ответ. Он должен явно сообщить, что не смог получить данные из нужной системы, и показать, какой части контекста не хватает.
Если параметров недостаточно, агенту лучше запросить уточнение, чем выполнить действие с неверными данными. А для операций с последствиями — например, создания задачи или изменения статуса — можно предусмотреть подтверждение перед выполнением.
4. Безопасность внешних MCP-серверов
Подключение внешнего MCP-сервера расширяет возможности агента, но добавляет вопросы доверия. Важно понимать, какие tools публикует внешний сервер, какие данные уходят во внешнюю систему и какие действия агент может выполнить через этот канал.
Поэтому внешний MCP-сервер не должен автоматически становиться доступным всем агентам. Его tools нужно добавлять в адаптер осознанно: только для тех сценариев, где они действительно нужны. Такой подход помогает сохранить принцип минимально необходимого доступа.
5. Эксплуатация и мониторинг
Для промышленного использования важно видеть не только ответы агента, но и техническое состояние всей цепочки: LLM, Nexus, адаптера, внутренних методов и внешних MCP-tools.
На практике это означает метрики по вызовам, ошибкам, задержкам, недоступности внешних инструментов и доле сценариев, где потребовалось уточнение или ручное подтверждение. Без этого агентскую логику сложно сопровождать как часть корпоративной платформы.
Почему это не просто «доступ к API»
MCP-модуль не стоит воспринимать как способ дать LLM прямой доступ к API. Его задача другая: создать управляемую модель взаимодействия между LLM и корпоративными действиями.
Обычный API описывает endpoints и контракт взаимодействия для разработчика. MCP-сервер описывает tools для агента: что можно сделать, какие параметры нужны и какой результат вернётся. Это не отменяет API под капотом. Наоборот, MCP-сервер часто является обёрткой вокруг API внешней системы. Но для агента важен именно уровень tools, потому что LLM выбирает действие по описанию, а не пишет интеграционный код на лету.
В SimpleOne эта логика дополняется внутренними AI-методами. Там, где действие можно выполнить внутри платформы, не нужен внешний MCP-сервер. Там, где агенту нужен внешний контекст, SimpleOne может подключить MCP-сервер другой системы. А там, где внешнему агенту нужны действия SimpleOne, сама платформа может опубликовать свои методы как MCP-tools.
Это разделение важно для enterprise. Агент должен быть не обходным путём вокруг корпоративной системы, а участником её архитектуры. Тогда его можно встраивать в реальные процессы: анализ инцидентов, работу с задачами разработки, поддержку пользователей, обработку запросов, подготовку сводок и другие сценарии, где нужно сочетать гибкость LLM с управляемостью платформы.
Резюме
Главная ценность MCP в enterprise не в том, что агент «получает доступ к API». Ценность в другом: между LLM и корпоративными системами появляется управляемый слой инструментов.
За счёт этого агент может не только отвечать на вопросы, но и работать с данными, действиями и процессами в понятных границах: через описанные методы, с контролем доступа, предсказуемым исполнением и возможностью аудита. Для корпоративных платформ это, пожалуй, ключевое условие перехода от ИИ-помощников к ИИ-агентам, которые действительно могут участвовать в рабочих процессах.
MCP-модуль уже доступен внутри SimpleOne GenAI. Сейчас мы расширяем набор сценариев и отдельно смотрим на вопросы, которые важны для корпоративной эксплуатации: права доступа, аудит, безопасность внешних tools, обработку ошибок и мониторинг.
С какими ограничениями вы сталкивались чаще всего: безопасный доступ к данным, описание инструментов для LLM, права пользователей, интеграции с внешними системами, контроль действий агента или эксплуатация таких сценариев? Поделитесь опытом в комментариях.
