Вступление

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

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

Подходы

Что лучше, разработать API для прямого доступа к информационной базе или научить агента работать с запущенной графической сессией 1С?

Первый подход выглядит инженерно чище. Мы даём модели список функций, описываем параметры, возвращаем структурированные данные и исключаем хрупкую работу с интерфейсом. Допустим, нужно ввести поступление товаров. Тогда API должен уметь искать и создавать поставщика, договор, номенклатуру, склад, и так далее, включая сам документ. Если API предметный, список функций быстро растёт, если API универсальный, агенту приходится понимать схему данных, связи, ограничения, права и бизнес-логику.

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

• Часть полей документа может быть отключена функциональными опциями, ролями или настройками формы;
• В обработчиках формы находится логика предзаполнения, проверки, включения и выключения элементов;
• Списки выбора часто зависят от текущих значений других полей, параметров связи и обработчиков получения данных менеджеров прикладных объектов;
• Табличные части имеют собственные правила редактирования строк, пересчёта итогов и выбора значений;
• Предупреждения перед редактированием, состояние групп, видимость команд и доступность кнопок являются частью пользовательского процесса, тех правил, которые напрямую влияют на вводимые данные.

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

Может казаться, что пользовательские формы ввода являются временным рудиментом эпохи до ИИ. Возможно, когда-нибудь модель действительно будет формировать корректные бизнес-объекты напрямую, а интерфейс станет вторичным. Но в обозримом будущем для сложных конфигураций 1С более реалистичным выглядит другой путь: не обходить пользовательский интерфейс, а дать агенту возможность работать через него.

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

Виртуальный пользователь

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

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

Машинное зрение

Для понимания машиной графического интерфейса, можно воспользоваться бесплатными и быстрыми нейросетями, которые могут текстом вернуть описание картинки. Ещё до начала проекта было понятно, что из этого может выйти толк только при серьёзном до-обучении, и скорее всего, работать это будет для простых форм с логикой "Далее > Далее > Готово". Основная загвоздка здесь в отсутствии семантического слоя. К счастью, большую его часть можно получить от самой платформы, используя механизм сценарного тестирования.

Это важный сдвиг в понимании задачи. Агенту не нужно смотреть на экран так, как человек. Ему нужно получать достаточно точное описание текущего состояния программы, чтобы принимать решения. Картинка остаётся полезным вспомогательным средством, но основное "зрение" строится на структурированной информации из интерфейса.

Наивный подход

Сегодня наиболее продвинутыми способами внешнего взаимодействия с пользовательским интерфейсом 1С:Предприятие являются фреймворки тестирования. Казалось остаётся дело за малым - обучить ИИ на базе тысяч тестов, перевести все шаги/методы тестирования в агентские навыки, отшлифовать инструкции, и предоставить доступ к документации по программе и инструменту тестирования.

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

Переосмысление

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

План пришлось перестроить:

• сделать Тестер "утилитой", с которой агент может работать из своей среды;
• предоставить агенту главное меню программы со всеми подсистемами и навигационными ссылками;
• научить агента после каждого значимого действия смотреть в интерфейс, а не продолжать догадками;
• доработать методы тестирования так, чтобы они возвращали агенту подробное описание происходящего;
• дополнить стандартный механизм получения информации от клиента-тестирования данными, которые через штатный интерфейс получаются медленно (например - видимость) или неточно (например - состояние группы);
• описать в навыках базовые пользовательские приёмы: поиск в списках, выбор ссылочных значений, работа с табличными частями, чтение отчётов;
• внести изменения в целевую конфигурацию, чтобы агент видел больше полезной информации: подсказки, фиксированные отборы, специальные формы, дополнительные поля и пояснения.

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

Исполнитель команд

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

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

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

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

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

Реальный пример. Мы дали агенту задание ввести заказ поставщику на основе высланного по почте pdf-файла. Там 153 позиции запчастей к тракторам. Так вот, он начал вводить заказ, ввёл две позиции, пропуская каждое действие через себя, а потом взял и написал скрипт разбив весь заказ по пакетам из 10 позиций в каждом. В этом скрипте, он после каждого пакета, вставил программную проверку суммы строки и возврат, буквально используя возврат результатПроверки;. Передача этого "возврата" в языковую модель заметно расширяет алгоритмические возможности агента по формированию логики сценариев.

Что именно видит агент

Главным методом наблюдения стал ПолучитьЭлементыАктивногоОкна (GetActiveWindowControls). Он возвращает дерево активного окна: форму, группы, поля, кнопки, таблицы, колонки, команды, текущий активный элемент и значения там, где их можно прочитать. Для верхнего уровня был добавлен метод получения главного меню. Агент может сначала узнать, какие подсистемы и команды вообще доступны, и только потом открывать нужный список или документ по известной навигационной ссылке.

Для производительности и читаемости результата появился отдельный метод получения изменений активного окна. После полного снимка формы Тестер запоминает базовое состояние, а после следующего действия может вернуть не всё дерево, а только различия (возвращается RFC 6902, JSON Patch). Это хорошо соответствует реальному пользовательскому процессу: после ввода значения важно увидеть, что именно изменилось, и машина результат сравнения JSON-ов хорошо понимает.

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

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

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

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

Механизм сценарного тестирования 1С позволяет узнать о клиенте много, но не всё. К тому же, получение некоторых свойств, например, видимости, происходит медленно, а некоторые сведения оказываются недостаточно точными. Типичный пример - состояние групп. К сожалению, надёжно узнать свёрнута группа или нет, через менеджер тестирования на момент написания этой публикации - нельзя.

Для человека всё очевидно: поле видно или не видно, группа раскрыта или свернута. Для агента это должно быть формальным свойством в структуре ответа, и нужно собирать эту информацию быстро, а не по 15-20 секунд на проход, как это делает сейчас стандартный менеджер тестирования.

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

Сценарий взаимодействия выглядит так:

1. Тестер получает активное окно через механизм тестирования;
2. По заголовку окна и имени формы он обращается по http к приложению;
3. Компонента передаёт запрос через внешнее событие;
4. Модуль расширения целевой конфигурации находит нужную клиентскую форму и перебирает её элементы;
5. В ответ возвращаются видимость, доступность, признак "только чтение", флажки, подсказки, текст предупреждения при редактировании, подсказка ввода, состояние сворачиваемых групп и язык интерфейса.

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

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

Метаданные, подсказки и смысл формы

Даже текущее состояние формы не всегда отвечает на вопрос "что это такое". Поле может называться ItemsProducerPrice, а заголовок может быть коротким или вообще отсутствовать. Человеку помогает знание предметной области и опыт работы с формой. Агенту нужно предоставить этот слой явно.

Как известно, на клиенте нельзя получить описание метаданных, а штатно сходить с клиентского общего модуля на сервер в контексте текущей формы, без её модификации и ничего о ней не зная - нельзя. Для этого в Тестер было добавлено чтение этих сведений из исходников конфигурации. Поддерживаются исходники формата EDT и выгрузка из конфигуратора. В результате, дерево интерфейса дополняется типами данных, принадлежности к табличным частям, подсказками и пояснениями в согласии с языком запущенной сессии прикладного решения.

Это решает сразу несколько задач:

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

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

Навыки вместо длинных сценариев

После первых проб и нудных наблюдений за агентом, стало ясно, что одних методов Тестера всё равно недостаточно. Агенту нужны устойчивые правила поведения. Вместо "нажми кнопку с таким-то именем", нужно "если выбираешь ссылочное значение, сначала открой форму выбора, посмотри её состояние, найди запись через стандартный поиск, убедись в найденной строке и только потом нажми выбор".

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

Первый тип - технические навыки работы с интерфейсом:

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

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

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

Изменения в целевой конфигурации

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

Рабочая среда

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

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

Виртуальная машина была установлена на рабочий компьютер главного бухгалтера. Рабочий стол основного компьютера был сделан общим с виртуальной машиной, чтобы файлы, документы, выгрузки и результаты работы могли естественно переходить между человеком и агентом. В качестве агента использовался Codex с моделью GPT-5.5 в режиме medium и подпиской Pro.

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

Полученный процесс

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

• Бухгалтер формулирует задачу обычным языком: найти информацию, подготовить документ, обработать поступление, сверить два (внешний и внутренний) акта сверки, заполнить отсутствующие реквизиты, или выполнить другое действие в программе;
• Агент читает задачу, при необходимости смотрит файлы или письма, затем переходит к 1С;
• Затем он изучает меню программы, читает навыки;
• Согласно основной инструкции, он начинает писать короткие сценарии и передавать их Тестеру на выполнение;
• Тестер выполняет сценарии получает состояние и отправляет информацию обратно агенту.

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

Поиск элементов справочников

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

На момент написания этой публикации, наиболее рабочий вариант - это векторизация данных (embedding) и замысловатый алгоритмом поиска, который включает в себя несколько стадий отбора подходящих кандидатов и систему ранжирования в зависимости от класса искомой сущности. Сверху этого нужен MCP-сервер с подключением его к агенту и написанием навыка.

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

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

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

Что получилось

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

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

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

Границы результата

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

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

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

Пособие по запуску

Проект может быть запущен на Linux или Windows, Mac OS пока не поддерживается. Внутри моей компании, вся разработка и текущая опытная эксплуатация, ведётся на Linux для проприетарной конфигурации собственной разработки. Для большей части сообщества специалистов и пользователей 1С, привычным является окружение на базе операционной системы Windows и типовых конфигураций 1С. Поэтому ниже, я буду описывать процесс развёртывания для пользователей Windows. В качестве типовой конфигурации, будет использоваться демонстрационная база Бухгалтерия предприятия (для Linux, процедура практически идентична).

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

Итак, необходимо выполнить следующее:

1. Клонировать репозиторий:

cd "%USERPROFILE%\Documents"
git clone https://github.com/grumagargler/tester.git

2. Создать новую информационную базу, войти в неё конфигуратором и загрузить dist/agent.dt. При создании информационной базы, не забудьте в настройках указать параметр /testmanager:

3. Затем, запустите Тестер, войдите в меню Репозитории, откройте из списка единственную там запись и измените два поля, указанные маркером. В первом поле нужно указать вашу сессию, во втором путь к папке, где будут создаваться скрипты Тестера:

Можно прямо в директории assistant клонированного репозитория создать папку tester (она находится в .gitignore). Обратите внимание, флажки Проинициализировать и Синхронизация должны быть ыключены.

4. Следующим важным шагом нужно указать путь к выгруженной конфигурации. В нашем случае, это Бухгалтерия предприятия. Чтобы выгрузить конфигурацию в файлы, необходимо зайти в конфигуратор, затем в меню Конфигурация > Открыть конфигурацию и сразу после этого меню Конфигурация > Выгрузить конфигурацию в файлы. Директорию, куда вы произведёте выгрузку, нужно будет указать в Тестере, как на картинке ниже. Также, поддерживается формат выгрузки EDT:

Обратите внимание, что как и в случае настройки репозитория, нужно изменить сессию (маркер №2) с моей, на вашу.

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

5. Удостоверимся, что MCP-сервер Тестера активен и работает. Для этого, откройте меню > Настройки:

На этом настройка Тестера завершена, перейдём к Бухгалтерия предприятия.

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

/testclient -tport 63400

2. Далее, запускаем Бухгалтерия предприятия в режиме 1С:Предприятие, и подключаем расширение из клонированного репозитория dist/tester.cfe:

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

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

На этом настройки 1С готовы, переходим к агенту, в моих экспериментах это Codex CLI.

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

1. Устанавливаем и запускаем Codex (https://developers.openai.com/codex/app);
2. Запускаем, настраиваем, подключаем к используемому плану;
3. Затем, в кодексе, открываем директорию (File > Open Folder) assistant в папке, куда мы клонировали github-репозиторий. Это важный шаг, так как именно в этой директории настроены базовые навыки и инструкция для агента;
4. Перейдём в список MCP-серверов кодекса и убедимся, что runner запущен:

Всё, настройка закончена, можно пробовать начинать общение. На этом видео, пример задачи и его решения (видео опубликовано на youtube, к сожалению, доступ к российским площадкам мне пока получить не удалось).

На этом у меня всё. Спасибо за внимание!