Одноразовые интеграции размножаются
В первом пробной версии интеграции часто делают точечно: один скрипт читает CRM, второй забирает документы, третий пишет комментарий. Это быстро, но плохо масштабируется. Через несколько месяцев появляется набор несвязанных инструментов с разными правами и логами.
Стандартизированный слой инструментов помогает агентам работать с системами единообразно: описанные входы, права, ошибки, ограничение частоты запросов и журнал действий. Всё ещё инженерная работа, но уже не археология.
Что даёт MCP-подход без фанатизма
Model Context Protocol описывает стандартный способ подключать ИИ-приложения к внешним данным, инструментам и рабочие процессы. Для бизнеса это полезно потому, что появляется слой, который можно переиспользовать между ассистентами, агентами и внутренними продуктами.
- единое описание инструментов и их возможностей
- понятное разграничение доступа
- меньше дублирования при новых ИИ-сценариях
- лучше аудит: кто, что и почему вызвал
Как начать и не переписать всю внутреннюю часть системы
Не нужно сразу переписывать всю внутреннюю часть системы. Начните с 3-5 инструментов одного процесса: найти клиента, получить историю обращений, создать черновик задачи, прикрепить источник, отправить на подтверждении человеком. После этого станет понятно, какие контракты нужны и как агент должен обрабатывать ошибки.
Хотите проверить это на своих данных? Разберём задачу бесплатно и скажем, стоит ли браться.
Каталог инструментов вместо набора скриптов
Первый шаг к нормальному слою инструментов - каталог инструментов. В нём описано, что инструмент делает, какие данные принимает, какие права требует, что возвращает, какие ошибки возможны и меняет ли он состояние системы. Это звучит как документация API, потому что по сути так и есть.
Каталог помогает не только разработчикам. Владелец процесса видит, какие действия агент вообще может выполнять. Безопасность видит, где нужно подтверждение человеком. Аналитик видит, какие события логируются. Команда внедрения видит, какие инструменты можно переиспользовать в следующем агенте.
- инструменты чтения: поиск, просмотр, получение истории и источников
- Черновик инструменты: подготовка карточек, писем, задач, отчётов
- запись инструменты: действия только с правами, логами и подтверждением
Контракты: строгий вход, предсказуемый выход
Агенту нельзя давать инструмент с расплывчатым контрактом. Если функция принимает «что-нибудь про клиента», модель будет угадывать. Лучше явно описать поля: client_id, deal_id, date_range, channel, priority, status. Тогда ошибки становятся проверяемыми до вызова инструмента.
На выходе тоже нужна структура. Вместо свободного текста инструмент должен возвращать статус, данные, список предупреждений, источник и машиночитаемую ошибку. Агенту проще принять решение, а человеку проще понять, почему действие не выполнено.
Права доступа и режимы работы
Один и тот же инструмент может работать в разных режимах. Например, CRM-инструмент может читать карточку клиента, создавать черновик комментария или менять статус сделки. Эти режимы нельзя смешивать. Для пробной версии полезно начинать с только чтение и черновик, а запись-режим включать только после проверки логов и подтверждение человеком порядок работы.
Если в компании несколько ИИ-интерфейсов, общий слой инструментов помогает не дублировать права. Внутренний ассистент, чат на сайте и агент поддержки могут использовать разные части одного каталога, но с разными ролями и лимитами.
- роль пользователя определяет доступные инструменты
- режим инструмента определяет, можно ли менять данные
- журнал действий фиксирует вызов, аргументы, результат и инициатора
Наблюдаемость: что логировать
Интеграции без логов быстро становятся неуправляемыми. Нужно видеть, какой агент вызвал инструмент, с какими аргументами, какой ответ получил, сколько это заняло, была ли ошибка, подтвердил ли человек действие и какой итог ушёл в бизнес-систему.
Эти логи нужны для трёх вещей: расследовать инциденты, улучшать качество агента и считать экономику. Если агент сэкономил время, это должно быть видно по событиям процесса, а не по ощущениям после демо.
Тестирование слоя инструментов
Инструменты нужно тестировать отдельно от модели. Проверяются схемы входа, обработка пустых результатов, права доступа, ошибки внешних систем, ограничение частоты запросов, повторные вызовы и идемпотентность. Особенно важно понять, что произойдёт, если агент дважды отправит одно действие.
После этого тестируется агент поверх инструментов: выбирает ли он правильный инструмент, задаёт ли уточняющий вопрос при нехватке данных, не пытается ли обойти запрет и корректно ли объясняет пользователю, почему действие не выполнено.
Когда MCP действительно нужен
MCP имеет смысл, когда ИИ-сценариев становится больше одного: ассистент поддержки, агент продаж, внутренний поиск, обработка документов, аналитика. Если каждый из них заново подключается к CRM и файлам, стоимость поддержки растёт быстрее пользы.
Если сценарий один и простой, можно начать с обычного API-слоя. Но уже на пробной версии стоит проектировать контракты так, чтобы потом их можно было перенести в MCP-подход без переписывания логики доступа.
Что сделать дальше
- Сделайте каталог инструментов: чтение, поиск, запись, действие.
- Разделите права доступа по ролям и сценариям.
- Проектируйте слой инструментов как продукт, а не как набор временных скриптов. Временное живёт дольше всех.
Вывод
Резюме: чем больше ИИ-сценариев появляется в компании, тем важнее единый слой инструментов. MCP-подход помогает сделать интеграции повторяемыми, наблюдаемыми и безопасными.