Бот в мессенджере или агент внутри заявки: как мы собирали ИИ-подсказчика для своей первой линии

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

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

Кейс внутренний: агент работает на первой линии компании «+Альянс», охват — 20 операторов Okdesk. Внедрений у заказчиков за ним нет: на 4 сентября 2026 года проекты направления услуг «Внедрение ИИ» ещё на согласовании.

Коротко

• Помощник на API ChatGPT в мессенджере на первой линии компании «+Альянс» не пошёл: приходить к нему надо было самому, а истории заявок у той версии не было.
• Работающая конструкция компании «+Альянс»: агент на Copilot Studio включается при назначении ответственного в Okdesk и пишет в заявку скрытый комментарий, а решение принимает оператор.
• В нашем MCP-сервере для Okdesk 22 инструмента написано и 20 включено в проде: семь из них работают с заявками, четыре с базой знаний Okdesk, остальные — со справочниками, сотрудниками, компаниями, контактами и вложениями.
• Три источника подсказки подключены тремя разными механизмами: свой MCP-сервер как инструмент агента, кастомный коннектор к Microsoft Graph и доступ к SharePoint компании.
• Против уверенного вранья модели у нас работают правила системного промпта — запрет отвечать по памяти, обязанность сказать «не нашёл», ссылка на источник — и признак неполной выдачи на стороне своего сервера.

Почему первый помощник не прижился и что проверить у себя

У первой линии компании «+Альянс» до агента на Copilot Studio стоял бот в мессенджере на API ChatGPT. Не сошлось два условия. К боту надо приходить самому — подсказку получал тот, кто про неё вспомнил. И накопленного опыта поддержки у той версии не было: без доступа к нашей истории заявок она выдавала найденное в интернете. Это свойство нашей первой сборки, а не ограничение OpenAI.

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

До агента решение на первой линии мы добывали четырьмя путями: своя диагностика, вопрос коллегам, вопрос второй линии, поиск в интернете. По истории заявок искали крайне редко — так я описал это состояние 11 сентября 2026 года. Отдельного замера, сколько времени уходит на поиск чужого опыта, у нас нет. Именно история заявок и стала потом первым источником агента.

Рабочая конструкция: агент пишет в заявку сам

Фоновый подсказчик — так я называю помощника, который включается по событию в системе заявок и сам кладёт туда результат.

Триггер фонового подсказчика у компании «+Альянс» — назначение ответственного по заявке, а не её поступление. Агент собран на Copilot Studio, живёт внутри Okdesk и оставляет в заявке скрытый комментарий: подбирает решение по прошлому опыту, смотрит в наши документы, ищет в интернете и складывает из этого рекомендацию специалисту. Клиенту агент не пишет и решений за человека не принимает.

15 сентября 2026 года разработчик компании описал слой, который стоит перед автокомментарием: это дешёвый гейт, отдельный промпт с ответом «да» или «нет» на вопрос, стоит ли вообще вклиниваться в эту заявку. Я считаю гейт обязательной частью конструкции. Без него комментарий появится и там, где агенту сказать нечего, а подсказчик, который пишет в каждую заявку, быстро становится шумом.

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

Откуда берётся подсказка: три источника, три механизма

Состав подключённого разработчик компании назвал 14 сентября 2026 года: Okdesk, Битрикс24, корпоративные данные в Microsoft (SharePoint, Teams, Power BI) и Azure DevOps. Механизмы подключения стоят в его ответе от 11 сентября 2026 года, и они разные — это несущая часть конструкции.

Сущности, которые MCP-сервер отдаёт агенту, 11 сентября 2026 года я перечислил так: заявки и комментарии. Состав инструментов шире — 22 написано, 20 включено в проде, а разбивку по группам разработчик прислал 15 сентября 2026 года. Семь инструментов работают вокруг заявок, четыре вокруг базы знаний Okdesk, по три приходится на справочники (статусы, типы, приоритеты) и на сотрудников, по одному — на компании, на контакты и на вложения. Разрыв между 22 и 20 я объяснить не могу: причину мне не называли.

Основная нагрузка подсказки лежит на заявках и базе знаний Okdesk — так я читаю разбивку инструментов по группам. Справочники, сотрудники, компании, контакты и вложения, на мой взгляд, обвязка вокруг этих двух; «не нужно» ни про что из перечисленного разработчик не говорил. Признак для своего проекта я взял бы такой: новую группу инструментов пишут тогда, когда без неё подсказка в живой заявке остаётся неполной.

Способы, которыми внешние данные попадают в Copilot, разобраны по документации Microsoft в статье «Microsoft 365 Copilot: что это и как его подключают к CRM и 1С, а не только к почте». Для выбора конструкции важно другое: коннектор к своей системе заявок мы писали сами, и в плане проекта такая работа занимает отдельную строку.

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

Что мы заложили против уверенного вранья модели

Самая дорогая ошибка подсказчика, на мой взгляд, — уверенный ответ, который никто не проверит: он лежит в заявке рядом с настоящими фактами и выглядит так же.

У агента компании «+Альянс» на Copilot Studio часть защиты живёт в системном промпте. Его фрагмент разработчик прислал 14 сентября 2026 года с оговоркой, что полная версия больше. Правил в этом фрагменте пять. Первое: перед ответом обязательно искать по корпоративным данным и по данным заявки, а не по памяти. Второе разрешает признать неудачу: данных нет — так и написать. Дословно в промпте сказано: «не додумывай, не предполагай и не заполняй пробелы вымышленными фактами».

Форму ответа в системном промпте нашего агента на Copilot Studio задают три правила из пяти: конкретика (номера заявок, даты, статусы, ответственные, если они нашлись), явное указание на расхождение, когда источники противоречат друг другу, и обязательная ссылка на источник, из которого ответ собран.

Два правила появились в промптах не на старте, а по факту работы; дословно их прислал разработчик. Для меня это самые полезные строки из всего присланного: каждая закрывает уже найденный дефект. Против раздутого ответа стоит строка «Лучше 3 точных шага, чем 14 на всякий случай». Вторая написана против пересказа чужих неудач: «Отличай, что реально ПОМОГЛО, от того, что просто предлагали». В истории заявок лежат и провальные попытки, в том числе прежние комментарии самого агента, и без такого правила он подаёт собственный несработавший совет как готовое решение.

Признак неполной выдачи ставит наш MCP-сервер: дошёл инструмент до своего потолка — и агенту уезжает флаг усечения вместе с советом поднять лимит или сузить фильтры. Цену молчаливой обрезки разработчик назвал прямо 16 сентября 2026 года: модель уверенно сообщит, что нашлось 50 заявок, когда их триста, и в заявке этого никто не проверит.

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

Две недели двумя программистами — и что заняло дольше всего

Агента первой линии компании «+Альянс» собрали за две недели силами двух программистов. Дольше всего разбирались не с MCP, а с тем, как встроиться в Copilot Studio.

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

Запустили сразу на реальных заявках

Тестового периода на старых заявках у нас не было. Агент компании «+Альянс», собранный на Copilot Studio, пошёл сразу в живой поток заявок Okdesk: пишет он только операторам, то есть цена ошибки ограничена подсказкой, которую человек может отбросить. Качество контролировала первая линия, обратную связь операторы давали регулярно.

Оператор влияет на агента двумя путями. В самой заявке есть «призыв»: оператор обращается к агенту и уточняет запрос прямо там. Систематические претензии уходят в отдел разработки — его ребята и корректируют работу агента. Деталь, которую стоит знать заранее: внутренней памяти у него нет, вызовы между заявками чистые. Сказанное ему живёт в пределах одной заявки и дообучением не становится.

На первой линии компании «+Альянс» доля диагнозов, верных с первого раза, стала 73 % против прежних 55 %; верным мы считаем диагноз, после исправления которого проблема ушла. Среднее время первичной диагностики (счёт идёт от момента, когда специалист взял заявку, и останавливается на диагнозе) теперь 31 минута, а до агента держалось порядка 60 минут. Обе пары чисел я разобрал отдельной статьёй «„Ускорилось в два раза“: разбираю цифру эффекта нашего агента на Copilot Studio — и показываю, где она проверку не проходит». Оговорка оттуда переносится сюда целиком: это внутренняя оценка — считали мы сами и по своему же потоку заявок, а объём выборки в том разборе не назван.

До живого потока проверьте, как к вам вернётся жалоба на плохую подсказку. У нас для этого есть «призыв» в самой заявке и претензии, которые уходят в разработку. Нет ни того ни другого — качество подсказок вы увидите только по косвенным признакам, когда оператор просто перестанет их читать.

Что видно только в эксплуатации

Контейнер с MCP-сервером компании «+Альянс», из которого агент на Copilot Studio берёт историю заявок Okdesk, при долгом простое останавливается, чтобы не занимать ресурсы сервера, и первое обращение после простоя стоит примерно 10–15 секунд. Про секунды разработчик уточнил 15 сентября 2026 года: оператор их не видит, потому что комментарии в Okdesk создаются через API, анимаций там нет — растёт только время появления комментария.

Индекс Microsoft Search отстаёт от источника максимум на час. Новое в него по крону раз в час заливает наш синхронизатор, и к этому же индексу подключён агент; цепочку разработчик описал ответами 14 и 15 сентября 2026 года. Для подсказки по свежей заявке это значит простую вещь: то, что случилось десять минут назад, агент может ещё не увидеть.

14 сентября 2026 года разработчик описал случай на переходе от советов к действиям: агент из Okdesk пробовал создать заявку и не смог обратиться к основному агенту в Copilot Studio, потому что в ответ приходила карточка авторизации Microsoft. Её флаги мы разобрали кодом прямо с HTML-страницы, чтобы кнопку подтверждения нажимал сам агент, без участия разработчика. Это приём для нашего контура, читателю я его не предлагаю.

Карточку авторизации неинтерактивная служба пройти не может, и это не наша частная беда, а норма платформы. Как устроено OAuth 2.0-подключение, разбирает страница документации Microsoft «Connect your agent to an existing Model Context Protocol (MCP) server» (https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent). По её описанию агент перенаправляет пользователя на вход, где тот и выдаёт разрешения. Согласие человек даёт в чате, и в тексте Microsoft это звучит так: «consent card presented in the agent chat». Полученный токен позволяет агенту работать с MCP-сервером «on behalf of the user» — то есть от лица того же пользователя. Обе цитаты — про подключение MCP-коннектора, а случай 14 сентября — про вызов агента из Okdesk: места в конструкции разные, механику одного на другое я не переношу.

Аутентификацию у MCP-коннектора компании «+Альянс» в Copilot Studio мы не включали, и причину разработчик назвал 15 сентября 2026 года: платформа тогда привязывает подключение к пользователю беседы, а неинтерактивная служба его так не установит.

Запрос без секрета в пути MCP-сервер компании «+Альянс» не принимает: все маршруты живут под hex-префиксом, а мимо него любой вызов получает 404. Открытым снаружи оставлен один адрес — проверка здоровья контейнера. Это размен, а не образец: за аутентификацию такой секрет не считается и при этом попадает в логи прокси и в историю запросов.

Порядок проверок перед тем, как ставить свой MCP-сервер под агента, — транспорт, способ подключения, аутентификация, политика данных Power Platform — разобран в статье на Хабре «Подключаем свой MCP-сервер к Copilot Studio: SSE не примут, а доступ решает политика Power Platform». Если будете повторять, считайте заранее цену обоих обходов: и секрета в пути, и разбора флагов из карточки.

Что дальше

Следующий шаг у агента компании «+Альянс» на Copilot Studio — переход от подсказок к действиям: чтобы его можно было попросить из любого места инфраструктуры, например создать заявку. Работа идёт, случай 14 сентября 2026 года произошёл именно на создании заявки. Готовой функцией я это не называю: о запуске речи пока не было. В работе ещё MCP для 1С.

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

Частые вопросы

Чем фоновый агент отличается от ИИ-бота в мессенджере?

Первым ходом. Фоновый агент стартует сам: у компании «+Альянс» его будит назначение ответственного в Okdesk, и ответ он кладёт прямо в заявку. К боту в мессенджере человек приходит с вопросом. У нашей первой линии это и решило выбор: подсказку видит каждый, к кому попала заявка.

Что минимально подключить, чтобы подсказка не была пересказом интернета?

Свою историю обращений: агент компании «+Альянс» берёт из Okdesk заявки и комментарии к ним. Начните с проверки, лежат ли решения в самих заявках текстом. Если решения обсуждают в чатах, а в заявку попадает «сделано», подключать пока нечего — сначала дисциплина комментариев, потом агент. Это моя позиция, замером она не подтверждена.

Развалится ли своя интеграция при очередном обновлении системы заявок?

Ни одно обновление Битрикс24 или Okdesk работу агента не ломало — так ответил разработчик 15 сентября 2026 года. Объясняет он это так: MCP-обёртка изолирует агента от API Okdesk, а Битрикс24 подключён не напрямую — его данные наш синхронизатор кладёт в кастомный коннектор к Microsoft Graph. Это его объяснение, а не проверенный на аварии вывод: подходящего случая у компании «+Альянс» не было.

Агент может дать неверную подсказку — чем это ограничено?

Тем, что подсказка адресована оператору и остаётся скрытым комментарием в Okdesk: клиенту она не уходит, решение принимает человек. В конструкции компании «+Альянс» это главный предохранитель, а правила промпта и признак неполной выдачи работают уже внутри него.

Сколько времени занимает сборка такого агента?

У компании «+Альянс» — две недели и два программиста, в своей системе заявок Okdesk и для своей поддержки. Как срок для чужого проекта я эту цифру не называю: состав систем, доступы и платформа агента у каждого свои.

Что заставило бы меня собрать это иначе

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

Порядок для себя я формулирую так: сначала место, куда придёт подсказка, потом данные, на которых она строится, и только потом модель.

Александр Жогов, основатель компании «+Альянс». Устройство агента описано по ответам нашего разработчика от 11, 14, 15 и 16 сентября 2026 года; цифры эффекта и состояние направления услуг «Внедрение ИИ» зафиксированы 4 сентября 2026 года; страница документации Microsoft о подключении MCP-сервера к Copilot Studio сверена 16 сентября 2026 года.