Автор проекта ИскраБот, российского ИИ-агента, поделился опытом интеграции модели с корпоративными системами проектной организации. В одном из сценариев пользователь прикрепил к диалогу готовый навык и начал писать рабочую заметку, предполагавшую добавление комментария к отчёту. Однако модель даже не попыталась вызвать нужный инструмент, хотя в его описании прямо указывалось условие применения при явной просьбе добавить комментарий. Человек уже выбрал навык и приступил к формулировке текста, но для ИИ этого оказалось недостаточно, и до фактической отправки дело не дошло. Этот случай показывает, что выбор навыка пользователем и наличие инструкции в описании инструмента ещё не гарантируют, что модель корректно распознает намерение и запустит нужное действие.

В ИскраБоте используются два типа навыков: текстовые и программные. Текстовый навык задаёт последовательность инструкций для модели — что уточнить у пользователя, в каком порядке выполнять задачу и как оформлять результат; примером служит навык подготовки презентаций. Программный навык содержит код для конкретных операций: поиск документа на Google Диске, просмотр последних писем в Gmail, получение сведений о сделке из amoCRM или Битрикс24, а также интеграции с 1С и сервисом рассылок UniSender. Модель выбирает подходящее действие и работает с запросом, программная часть выполняет вызов, а платформа обеспечивает подключение, разрешения и взаимодействие с пользователем. Именно на стыке этих уровней и возникают основные сложности, которые автор описал на примере двух собственных доработок.

Первый разбор касается подключения к 1С через VPN. База 1С находится во внутренней сети организации, и путь к ней состоит из двух этапов: сначала VPN-шлюз устанавливает туннель в корпоративную сеть, и только затем навык обращается к OData-интерфейсу 1С с учётной записью для доступа к базе. Реквизиты VPN и реквизиты 1С нужны на разных этапах, а упрощённая цепочка выглядит так: диалог, инструмент навыка, платформа запуска навыков, VPN-шлюз, внутренняя сеть и уже сама 1С. Такое разделение упрощает диагностику: сначала проверяется доступность 1С через VPN, а затем корректность запросов навыка к данным. Дополнительное препятствие возникло до установки соединения: шлюз был изолирован от внутренней сети платформы и не мог напрямую обратиться к серверу, выдающему VPN-настройки. Автор добавил специальный маршрут через сервис запуска навыков mcphub, доступный с обеих сторон, который передаёт запрос к одному заранее заданному адресу и возвращает ответ шлюзу, сохраняя сетевую изоляцию. После исправлений проверка на реальном подключении прошла всю цепочку: туннель установился, проверка соединения с 1С вернула успешный статус, а навык прочитал метаданные и доступные объекты базы.

Основная причина сбоя на этапе VPN оказалась в настройке безопасности OpenVPN. VPN-сервер принимал логин и пароль, но туннель на стороне клиента не поднимался, и до проверки учётной записи 1С дело не доходило. В старой версии обработчика VPN-профиля в конфигурацию принудительно добавлялась строка script-security 0, которая полностью запрещает запуск внешних программ. Уровень 1 допускает штатные сетевые утилиты вроде ip и route, а уровень 2 разрешает ещё и пользовательские скрипты. Автор исправил настройку, разрешив только штатные сетевые команды и оставив запрет на произвольные скрипты из загруженного профиля. Из этого случая выведен прикладной порядок диагностики: сначала проверяется авторизация на VPN-сервере и передача данных через туннель, затем доступность OData-интерфейса, авторизация в 1С и чтение структуры базы. Общая ошибка подключения скрывает, на каком именно этапе остановилась работа, поэтому исправлять логику запроса к 1С на первом шаге было бы преждевременно.

Отдельный сценарий связан с директивой auth-nocache. При первом подключении OpenVPN читает логин и пароль из защищённого файла, после настройки туннеля процесс переходит на пользователя с ограниченными правами и теряет доступ к этому файлу. Директива auth-nocache требует забывать реквизиты после использования, поэтому при переподключении логин и пароль оказываются недоступны, и повторная авторизация завершается ошибкой. Сначала профили с этой директивой отклонялись целиком, затем обработку изменили: исходный профиль принимается, но сама директива удаляется из конфигурации перед запуском OpenVPN, а при переподключении используются реквизиты, сохранённые после первого чтения файла. У решения есть компромисс — реквизиты остаются в памяти процесса OpenVPN на время жизни туннеля, что позволяет повторно авторизоваться после снижения прав, но требование исходного профиля забывать пароль уже не выполняется. Работу такого подключения необходимо проверять и после обрыва связи, поэтому на первом успешном соединении проверку не завершили.

Автоматическую проверку автор провёл на стенде с настоящим OpenVPN и тестовым HTTP-сервисом, возвращающим заранее известный ответ; база 1С в этом тесте не участвует. Такой подход позволяет изолированно воспроизводить сетевые сценарии и проверять поведение навыка без риска для рабочей системы. В более широком контексте эти заметки отражают типичные трудности интеграции ИИ-агентов с корпоративным ПО: модели требуется не только корректное описание инструмента, но и надёжная инфраструктура подключения, прозрачная диагностика и аккуратная работа с учётными данными. Для российского рынка, где 1С остаётся одной из самых распространённых корпоративных платформ, подобные кейсы важны: они показывают, что внедрение ИИ-агента упирается не столько в качество модели, сколько в сетевую конфигурацию, права доступа и совместимость с устаревшими настройками. Открытыми остаются вопросы о том, как масштабировать такие интеграции на разные организации, как проверять устойчивость подключений при обрывах и как формализовать требования к описанию навыков, чтобы модель надёжнее вызывала нужные инструменты.