Как я учил ИИ работать с 1С и другими корпоративными системами

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

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

Я занимаюсь разработкой ИскраБота – это российский ИИ-агент. Недавно создал один навык для корпоративной системы проектировщика, а в другой интеграции исправлял подключение к 1С через VPN. Расскажу о проблемах, с которыми столкнулся, но для начала – о том, что такое навык.

Что у нас называется навыком

В ИскраБоте есть текстовые и программные навыки. Текстовый навык задает инструкции для модели: что уточнить у пользователя, в каком порядке выполнять задачу и как оформить результат. Например, навык «Презентации» описывает порядок подготовки слайдов и проверки готовой презентации.

Программный навык содержит код для конкретных операций. С такими навыками ИскраБот может найти документ на Google Диске, показать последние письма в Gmail или получить сведения о сделке из amoCRM или Битрикс24. К этому же типу относятся интеграции с 1С и сервисом рассылок UniSender.

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

Дальше сосредоточусь на двух навыках, которые создавал и дорабатывал сам.

Навык: подключение к 1С

Среди навыков ИскраБота уже была интеграция с 1С. Я исправлял то, как она работает через VPN.

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

В упрощенном виде путь запроса выглядит так:

Диалог → инструмент навыка → платформа запуска навыков
↓
VPN-шлюз
↓
внутренняя сеть → 1С

Навык формирует запрос к 1С, а VPN-шлюз устанавливает соединение с сетью компании и передает туда запрос. Такое разделение упрощает поиск ошибок: сначала можно проверить, доступна ли 1С через VPN, а затем — правильно ли навык запрашивает данные.

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

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

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

До этого цепочка обрывалась в месте, которое легко пропустить, если смотреть только на факт авторизации.

Подключение к 1С застряло на настройке VPN

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

В старой версии обработчика VPN-профиля в конфигурацию принудительно добавлялась строка:

script-security 0

У OpenVPN эта настройка управляет запуском внешних программ. При уровне 0 такие вызовы запрещены полностью. Уровень 1 допускает штатные сетевые утилиты, например ip и route. Уровень 2 разрешает еще и пользовательские скрипты. Различие описано в документации OpenVPN ^[1].

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

Из этого случая получается вполне прикладной порядок диагностики. Сначала нужно проверить авторизацию на VPN-сервере и передачу данных через туннель. Затем — доступность OData-интерфейса, авторизацию в 1С и чтение структуры базы. Общая ошибка ^[2] подключения скрывает, на каком из этих этапов остановилась работа.

В нашем случае исправлять логику ^[3] запроса к 1С на первом шаге было бы рано: запрос еще не мог до нее добраться.

Профиль с auth-nocache добавил еще один сценарий

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

Здесь возникла несовместимость с директивой auth-nocache: она требует забывать ^[4] логин и пароль после использования. При переподключении реквизиты нужны снова, но в памяти ^[5] их уже нет, а доступ к файлу потерян из-за снижения прав. Поэтому первое соединение могло работать, а повторная авторизация — завершаться ошибкой.

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

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

Проверил обрыв, потом сам тест

Автоматическую проверку провел на стенде с настоящим OpenVPN и тестовым HTTP-сервисом, который возвращает заранее известный ответ. База 1С в этом тесте не участвует: он проверяет работу VPN и повторную авторизацию. Описанную выше проверку подключения к 1С и чтения структуры базы проводили отдельно.

Для переподключения добавил отдельный тест TestE2E_ReconnectWithCredentials. Сценарий состоял из нескольких шагов:

1. Установить VPN-соединение

2. Остановить VPN-сервер и дождаться обрыва

3. Вернуть сервер

4. Проверить по журналу VPN-сервера, что появилась новая успешная авторизация

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

Такой тест проверяет переход между состояниями. Одного работающего соединения для него недостаточно: нужно пройти через потерю связи и вернуться к рабочему состоянию.

Дальше проверил, что тест действительно обнаруживает нужную поломку, для этого временно вернул проблемное поведение ^[6]. Первое соединение поднялось, а повторная авторизация не состоялась – тест это обнаружил. После возврата исправления сценарий снова прошел.

Получилась следующая проверка:

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

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

Навык: комментарии в корпоративную систему проектировщика

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

Голосовой ввод в ИскраБоте уже был. Навыку оставалось связать подготовку текста с конкретной операцией в корпоративной системе. Для первой версии выбрали добавление комментария к отчету.

Если описать сценарий со стороны пользователя, он короткий: сформулировать или надиктовать текст, заполнить форму, подтвердить отправку. Внутри нужно согласовать несколько вещей:

• К какому отчету относится заметка?

• Что именно будет отправлено?

• Как получить временные реквизиты доступа?

• Что показать, если внешняя система не приняла комментарий?

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

Одна из существенных деталей – новый комментарий нужно добавлять к существующему. Операция замены текста в том же поле может быть технически корректной и при этом нарушать рабочий процесс: предыдущие записи должны сохраниться. Поэтому требование к результату приходится формулировать точнее, чем просто «записать текст в отчет».

Другая деталь – временный токен доступа. Его нужно обрабатывать отдельно от обычного содержимого переписки. Текст заметки нужен для подготовки комментария, реквизиты – для выполнения операции. У этих данных разные назначения, и объединять их в одно сообщение по принципу «модель разберется» здесь было бы плохим решением.

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

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

Пользователь выбрал навык, но модель ждала команду

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

Ожидаемое поведение здесь такое: выбор навыка задает контекст, а следующая заметка становится содержимым будущего комментария. Агент должен открыть форму для проверки и подтверждения отправки. Повторять ^[8] название системы и команду пользователю не требуется.

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

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

Что проверять, когда подключаешь ИИ к корпоративным системам

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

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

3. Перед изменением данных показывайте пользователю подготовленное действие и запрашивайте подтверждение.

4. Проверяйте восстановление после обрыва соединения, включая повторную авторизацию и передачу данных.

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