Меня зовут Александр Жогов, я основатель ИТ-компании “+Альянс”.

Больше всего времени в сборке помощника первой линии съело не написание MCP-сервера, а встраивание его в Copilot Studio. Живого человека за агентом у нас нет, и на аутентификации сервера это сказалось целиком. После статьи вы сможете проверить свою систему заявок на пригодность для фонового помощника и закрыть до начала работ три вопроса: откуда возьмутся свежие данные, как подключить MCP-сервер, за которым нет живого пользователя, и кто пишет правило подтверждения, когда агент начинает действовать.

Первая линия у нас - 20 операторов Okdesk, кейс внутренний. Начиналось всё с чат-бота в мессенджере, собранного на API ChatGPT. Мешали две вещи. Первый ход оставался за человеком: специалист сначала вспоминал про бота, потом заходил к нему в диалог. И данных компании у бота не было - отвечал он тем, что нашлось в открытом вебе. Доступа к нашим обращениям мы тому боту не давали: дело в нашей сборке, а не в OpenAI.

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

Прежде чем ставить у себя фонового помощника, задайте своей системе заявок два вопроса. Есть ли событие, на которое повесить запуск? Лежит ли в заявке текст решения? Если решение пишут в переписке, а в заявку падает “сделано”, брать подсказку агенту неоткуда.

Кнопку согласия нажать некому

MCP-сервер, через который агент ходит в историю заявок, стоит у нас в контейнере на своём железе, отвечает по Streamable HTTP, а Copilot Studio держит этот сервер как инструмент агента. Что Copilot Studio поддерживает по транспорту и аутентификации MCP-сервера, я разбирал отдельным текстом, с цитатами документации. Здесь только то, что определило нашу сборку.

Режим stateless: сессия между вызовами не держится, терять при остановке нечего - контейнер при долгом простое гасится в ноль. Первое включение стоит примерно 10-15 секунд, оператор их не замечает: комментарий приходит через API.

Коннектор в Copilot Studio у нас подключён без аутентификации: в настройках выбран тип “None”. Причина в том, как устроен OAuth 2.0, когда за агентом нет живого человека.

Адрес авторизации руководство Copilot Studio по подключению существующего MCP-сервера (https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent) описывает так: агент отправляет туда пользователя войти и выдать разрешения. Карточка согласия показывается в переписке с агентом - “consent card presented in the agent chat”. Дальше в сервер агент ходит под именем этого человека - “The access token lets your agent use the MCP server on behalf of the user”.

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

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

Отсюда наша схема: аутентификации у MCP-сервера нет, а пропуском работает секрет в адресе. Маршруты живут под 24-байтным hex-префиксом, вне него сервер отдаёт 404 - открытым оставлен только /v1/health, иначе ломаются health-пробы контейнера. Swagger и OpenAPI тоже уведены под префикс, иначе они бы секрет и выдали. Компромисс очевиден: секрет в пути аутентификацию не заменяет, он оседает в логах прокси и в истории запросов.

Красивее у меня не получилось.

Час отставания, который мы выбрали сами

Из индекса Microsoft Search агент берёт корпоративные данные: файлы SharePoint, проекты Azure DevOps, сделки Битрикс24. Такие примеры источников привёл наш разработчик 14 сентября 2026 года.

Свежие записи в Microsoft Search кладёт наш синхронизатор, запуск ежечасный; выбор частоты разработчик объяснил консистентностью данных. Цена прямая: в индексе нет событий последней минуты, отставание - до часа. Отставание мы приняли осознанно, и то, что должно быть свежим, агент запрашивает через MCP-сервер, живьём.

Коннектор под Битрикс24 мы писали сами. Среди систем, для которых страница “Copilot connectors overview” (https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/overview) перечисляет готовые коннекторы, Битрикс24 не назван. Объём такой работы та же страница описывает прямо - “Building a custom connector requires a developer to define a schema, register the connection in Microsoft Entra ID, and write code to pull and push data”.

Рейт-лимитера на MCP-сервере нет

Ни счётчиков, ни 429, ни троттлинга на MCP-сервере нет вообще.

Сервер обслуживает одного агента, тот работает через очередь и ходит в инструменты последовательно внутри заявки: конкурентной нагрузки не возникает. Настоящий ограничитель лежит снаружи - это API системы заявок. Наш замер: при активном агенте меньше 20 запросов в минуту, в среднем треть запроса в секунду; пиковую секунду мы не мерили. Лимит в 2 запроса в секунду назвала техподдержка Okdesk, её ответ передал нам разработчик.

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

Потолок выдачи есть у каждого инструмента: список последних заявок отдаёт 50 штук по умолчанию, до 500 по запросу. Полезна здесь механика: упёрлись в потолок - в ответе появляется флаг усечения. Без него “нашлось 50 заявок” при трёхстах в базе звучит уверенно, и перепроверять никто не станет.

Два слоя промпта и правила, которые появились по ходу

Верхний слой - instructions агента в Copilot Studio: пока агент не сходил в свой инструмент Chat Copilot, ответ “у меня нет доступа” ему запрещён. Нижний слой - промпты-обёртки в Azure Function, и начинает их дешёвый гейт “да/нет”: есть ли агенту что сказать по этой заявке. Без гейта помощник писал бы в каждую заявку - это шум.

В присланном мне фрагменте против выдумывания стоят пять правил, полная версия длиннее, предупредил разработчик. Вот два из них. Агенту нельзя отвечать по памяти и общим знаниям: перед ответом обязателен поиск в корпоративных источниках и в самой заявке. Нашлось пусто или данных мало - правило требует сказать об этом прямо готовой фразой “не нашёл информации по этому вопросу” и не даёт заполнять пробелы вымышленными фактами.

Ещё два правила разработчик дописал по факту работы. Объём ответа держит строка системного промпта: “Лучше 3 точных шага, чем 14 на всякий случай”. Второе живёт в блоке обёрток и касается истории: решением считать “ТОЛЬКО то, по чему видно, что оно сработало”. Агент читает историю заявок, а там лежат и расписанные шаги, которые ни к чему не привели, в том числе его собственные.

У Claude Code в режиме auto действие, попавшее в правила allow, ask или deny, решается сразу: “Actions matching your allow, ask, or deny rules resolve immediately” - цитата из документации (https://code.claude.com/docs/en/permission-modes). То есть правила разработчика срабатывают без обращения к модели. Границы, которые человек назвал прямо в переписке, правилами там не сохраняются - “Boundaries are not stored as rules”; за гарантией та же страница документации Claude Code отправляет в явный запрет: “For a hard guarantee, add a deny rule instead”.

Claude Code - чужой инструмент, и правила в нём про действия, у нас про ответы. Переносимо само разделение: часть поведения держит текст промпта, часть - код вокруг модели.

Где кончается подсказка

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

Правило подтверждения лучше задать заранее - у другого вендора это прямо параметр: в документации Responses API OpenAI (https://developers.openai.com/api/docs/guides/tools-connectors-mcp) подтверждение перед вызовом MCP-инструмента задаёт поле require_approval - “always”, “never” или список инструментов. Обмен описан там же: когда одобрение требуется, в выдаче ответа появляется запрос на него - элемент mcp_approval_request, а решение разработчик присылает следующим запросом, с mcp_approval_response. Решает это разработчик, а не модель по ходу разговора. Наш случай 14 сентября лежит в другом узле цепочки, и карточка авторизации пришла на вызове основного агента. Объяснять свой эпизод чужим параметром я не берусь.

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

Среднее время первичной диагностики было у нас порядка 60 минут, стало 31; меряем его от взятия заявки в работу до названной причины сбоя. Верным с первого раза я считаю тот вывод, исправление по которому сняло проблему; таких стало 73 процента, месяцем раньше было 55. Числа - внутренняя оценка на своём потоке заявок: база в 60 минут оценочная, а размер выборки и месяцы сравнения я не записал.

Границу между “советует” и “делает” я для себя пока не провёл. Подсказку в скрытом комментарии не жалко, оператор отбрасывает её за секунду; заявка, созданная агентом, - уже действие, под ним стоит чья-то учётная запись. Где проходит эта граница у вас - по обратимости действия или по тому, чьими правами агент ходит?