ИИ-агент — это уже не чат-бот: что происходит, когда нейросеть получает доступ к инструментам компании

Автор: Дмитрий Кондин, разработчик программных продуктов для бизнеса.

Когда несколько лет назад компании начали внедрять чат-ботов, основной сценарий выглядел примерно так: клиент задаёт вопрос, бот ищет подходящий ответ в базе знаний и отправляет его пользователю.

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

Но у этой технологии долго оставалось одно ограничение: нейросеть могла объяснить, что нужно сделать, но не обязательно могла сделать это сама.

Например, ИИ мог подготовить карточку нового клиента для CRM. Но создать её в системе, проверить наличие дублей, связать с существующей сделкой и добавить комментарий должен был сотрудник.

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

Сейчас ситуация меняется. ИИ-агента можно подключить к инструментам компании, дать ему доступ к определённым данным и разрешить выполнять конкретные операции.

Это меняет саму модель взаимодействия с программным обеспечением.

Представим работу агентства недвижимости.

Менеджер получает сообщение от клиента:

«Ищу двухкомнатную квартиру в центре, бюджет до 9 миллионов рублей. Желательно с ремонтом. Могу посмотреть варианты на выходных».

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

Более продвинутая языковая модель способна составить список критериев поиска, подготовить сообщение клиенту и предложить текст для объявления.

Но если у модели нет доступа к рабочим инструментам, на этом её возможности заканчиваются.

Сотруднику всё ещё предстоит открыть базу недвижимости, настроить фильтры, проверить результаты, сформировать подборку, скопировать ссылку и внести информацию в CRM.

Теперь представим другой сценарий.

Менеджер поручает задачу ИИ-агенту, подключённому к рабочей системе.

Агент:

Результат — не инструкция о том, как выполнить работу, а выполненная последовательность действий.

Именно здесь проходит важная граница.

Чат-бот преимущественно отвечает на запросы. ИИ-агент может использовать инструменты, чтобы добиваться поставленной цели.

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

Однако меняется принцип работы: вместо постоянного переключения между программами сотрудник может формулировать задачи на естественном языке.

Здесь возникает технический вопрос.

Допустим, в компании есть CRM, база объектов недвижимости, система обработки заявок, каталог товаров и внутренние документы.

Все эти данные уже существуют. Проблема заключается в том, что языковая модель сама по себе не знает, как обращаться к конкретной CRM, какие параметры принимает её API и какие операции разрешены пользователю.

Можно написать отдельную интеграцию для каждой модели и каждого сервиса. Но по мере развития ИИ-инструментов такой подход становится всё менее удобным.

Появляется необходимость в стандартном способе подключения моделей к внешним системам.

Один из таких способов — MCP, или Model Context Protocol.

MCP — открытый протокол, стандартизирующий взаимодействие ИИ-приложений с внешними источниками данных и инструментами. Он позволяет сервису объявлять доступные возможности, описывать параметры операций и передавать результаты их выполнения модели.

Если объяснять на бытовом примере, MCP можно сравнить с универсальным разъёмом.

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

С MCP похожая ситуация: если ИИ-клиент и сервер поддерживают соответствующий протокол, их можно соединить без создания отдельного интерфейса взаимодействия для каждой конкретной модели.

При этом MCP не является самой нейросетью и не превращает её автоматически в автономного сотрудника.

Это инфраструктурный слой, который помогает ИИ-приложению обнаруживать доступные инструменты и обращаться к ним.

В MCP предусмотрены разные типы возможностей.

Инструменты. Функции, которые агент может вызвать: найти запись, получить карточку объекта, создать контакт или выполнить другую разрешённую операцию.

Ресурсы. Данные и содержимое, которые приложение может предоставлять ИИ для работы с контекстом.

Промпты. Шаблоны, помогающие организовать взаимодействие с моделью для определённых задач.

На практике для автоматизации бизнес-процессов особенно важны инструменты. Через них модель может не только получать информацию, но и инициировать действия во внешней системе.

Например, сервер может предоставить агенту функцию поиска недвижимости с параметрами города, цены, площади и количества комнат.

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

Всё это происходит через определённый интерфейс, а не благодаря каким-то особым знаниям нейросети о внутреннем устройстве программы.

Именно поэтому наличие MCP-сервера само по себе ещё не гарантирует автоматизацию. Необходимо правильно спроектировать инструменты, права доступа, обработку ошибок и бизнес-логику.

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

У небольшого бизнеса ситуация другая.

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

Сотрудник принимает заявку, переносит данные в CRM, ищет объект, отправляет подборку, фиксирует результат разговора и напоминает себе перезвонить клиенту.

Каждое действие занимает немного времени. Но в совокупности они составляют значительную часть рабочего дня.

Рассмотрим несколько сценариев, в которых подключение ИИ к рабочим инструментам может быть полезно.

Менеджер завершил разговор с потенциальным покупателем.

Он может попросить агента:

«Добавь заметку по разговору. Клиент ищет однокомнатную квартиру до 6 миллионов рублей, рассматривает ипотеку, хочет получить варианты до пятницы».

Если агент подключён к CRM и располагает соответствующими инструментами, он может найти карточку клиента, проверить контекст и добавить заметку.

Следующий шаг — подбор объектов по заданным критериям.

В результате сотруднику не приходится отдельно открывать несколько разделов системы и вручную переносить информацию между ними.

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

Второй сценарий связан с ведением каталога.

Например, менеджер получает описание нового объекта в сообщении от собственника.

Агент может извлечь из текста площадь, количество комнат, этаж, цену и другие характеристики, а затем подготовить карточку объекта.

Если система поддерживает создание записей через инструменты, агент может передать эти данные непосредственно в рабочую базу.

При этом публикацию объявления разумно оставить под контролем сотрудника.

Такой подход позволяет использовать ИИ для подготовки данных, не предоставляя ему безусловного права самостоятельно публиковать всё, что он сформировал.

Ещё один сценарий — получение информации о состоянии работы.

Например:

«Какие сделки сейчас находятся на стадии показа?»

Или:

«Найди клиентов, по которым давно не было обновлений».

Если соответствующие инструменты доступны, агент может запросить данные из системы и подготовить сводку.

Это не обязательно сложная автоматизация. Но она может избавить руководителя от необходимости каждый раз вручную формировать отчёт.

Важно, чтобы такие ответы строились на актуальных данных CRM, а не на предположениях языковой модели.

В компании могут накапливаться инструкции, регламенты, договорённости и документация.

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

В некоторых случаях достаточно поиска по документам. В других требуется связать поиск с действиями в CRM или внутренней системе.

Здесь полезно различать два механизма: поиск информации и выполнение операций. Первый помогает получить ответ, второй позволяет изменить состояние рабочей системы.

Их можно объединять в одном сценарии, но не стоит считать взаимозаменяемыми.

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

На практике всё сложнее.

Модель может неправильно интерпретировать запрос. Пользователь может сформулировать задачу неоднозначно. В базе могут быть дубликаты. Инструмент может вернуть ошибку. Данные могут измениться между поиском и выполнением операции.

Поэтому разработка ИИ-агента — это не только подключение модели, но и проектирование системы, в которой её действия имеют понятные границы.

Я бы выделил несколько принципов.

Первый — минимально необходимые права.

Если для подбора недвижимости агенту достаточно читать каталог, нет необходимости предоставлять ему право изменять карточки объектов.

Второй — разделение чтения и записи.

Получение информации и изменение данных должны рассматриваться как разные уровни доступа.

Третий — подтверждение критичных операций.

Изменение цены, отправка сообщения клиенту или публикация объявления могут требовать подтверждения человека. Чем серьёзнее последствия ошибки, тем важнее такой контроль.

Четвёртый — журналирование.

Должно быть понятно, какой инструмент был вызван, с какими параметрами и к какому результату это привело.

Пятый — проверка входных данных.

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

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

Есть и отдельная проблема — недоверенные данные.

Например, в карточке объекта может находиться текст объявления, скопированный с внешнего сайта. В нём могут оказаться инструкции, обращённые к ИИ.

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

Это особенно важно, когда агент имеет доступ не только к чтению, но и к изменению информации.

В Sitebill мы развиваем инструменты для работы с недвижимостью. Поэтому для нас вопрос подключения ИИ к рабочим системам — не абстрактный эксперимент, а практическая инженерная задача.

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

Возникает другой вопрос: что, если человек сможет сформулировать задачу обычным языком, а ИИ самостоятельно выберет подходящие инструменты внутри системы?

Для этого мы реализовали MCP-сервер для платформы Sitebill.

Он позволяет совместимым ИИ-клиентам обращаться к определённым функциям системы недвижимости через стандартный протокол.

В текущей реализации предусмотрены инструменты для работы с объектами, контактами и сделками.

Например, агент может искать недвижимость по параметрам, получать сведения об объекте, находить контакты, добавлять заметки, создавать сделки и перемещать их между стадиями воронки. Также предусмотрено создание подборок объектов для клиентов.

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

Используются права сотрудника, от имени которого выпущен токен. Чтение и запись разграничены, новые объекты создаются в виде черновиков, а удаление объектов, контактов и сделок через MCP не предусмотрено. Вызовы инструментов журналируются, а доступ можно отозвать.

Для меня здесь важна сама архитектурная идея.

Мы не пытаемся заменить CRM языковой моделью. Мы предоставляем ИИ стандартный интерфейс к существующей бизнес-логике.

CRM продолжает отвечать за хранение данных, ограничения и правила работы. ИИ выступает дополнительным способом взаимодействия с этой системой.

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

В последнем случае между ИИ и рабочим процессом остаётся человек, выполняющий роль интеграционного механизма.

При подключении инструментов часть этих операций можно передать агенту.

Подробнее об архитектуре и доступных возможностях мы рассказали на странице MCP-сервера Sitebill.

Возникает закономерный вопрос: если ИИ сможет работать с программами через обычный язык, останутся ли нужны интерфейсы?

На мой взгляд, останутся. Но изменится роль, которую они играют.

Графический интерфейс хорошо подходит для визуального контроля, сравнения вариантов, просмотра карточек и принятия решений, требующих внимания человека.

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

Например, руководитель может попросить подготовить сводку по сделкам, а затем открыть конкретную карточку и проверить детали.

Это не выбор между кнопками и текстом. Скорее, появление ещё одного способа управлять программным обеспечением.

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

Но такой подход работает только тогда, когда у агента есть корректно описанные инструменты, необходимые данные и достаточные права.

Естественный язык сам по себе не отменяет сложность программного обеспечения. Он меняет способ взаимодействия с ней.

Я бы не рекомендовал начинать с идеи «давайте дадим нейросети доступ ко всей компании».

Это слишком широкая постановка задачи, из которой трудно вывести измеримый результат.

Гораздо разумнее выбрать один повторяющийся процесс.

Например, подготовку подборки объектов недвижимости по запросу клиента.

Затем определить:

После этого можно провести небольшой эксперимент.

Сравнить, сколько времени занимает выполнение задачи вручную и сколько — с использованием агента. Проверить не только скорость, но и качество результата, число исправлений и количество ситуаций, в которых потребовалось вмешательство сотрудника.

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

Если нет — сначала стоит разобраться в причине. Возможно, процесс плохо организован, данные не структурированы или агенту не хватает подходящих инструментов.

В этом смысле ИИ не заменяет проектирование бизнес-процессов. Напротив, он делает их качество ещё более важным.

Автоматизация плохо организованной работы не обязательно улучшает результат. Иногда она лишь позволяет быстрее получать ошибки.

В последние годы мы привыкли оценивать ИИ по качеству ответов: насколько хорошо он пишет, рассуждает, анализирует документы и понимает контекст.

Но для бизнеса появляется другой критерий.

Насколько надёжно ИИ может выполнить полезное действие в реальной рабочей системе?

Это уже не только вопрос качества языковой модели. Здесь важны архитектура интеграции, права доступа, качество данных, обработка ошибок и организация контроля.

MCP не решает все эти задачи автоматически. Но он предоставляет стандартный способ связать ИИ-приложение с внешними инструментами.

Именно поэтому я считаю подключение ИИ к рабочим системам одним из наиболее интересных направлений развития прикладного искусственного интеллекта.

Мы постепенно переходим от нейросетей, которые помогают думать и формулировать ответы, к системам, которые могут участвовать в выполнении рабочих процессов.

И здесь важно не пытаться сделать ИИ максимально самостоятельным любой ценой.

Гораздо полезнее научиться давать ему ровно те возможности, которые необходимы для конкретной задачи, и строить систему так, чтобы результат можно было проверить.

В конечном счёте ценность технологии определяется не тем, насколько впечатляюще она выглядит в демонстрации.

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