Средний

14 мин

48

Эта статья про то, как работая над продуктом “AI для 1С” (комплексная AI-система для Аналитиков и Разработчиков 1С), я сначала прикрутил Vanessa Automation, а потом решил реализовать нативный TestClient протокол, но ничего не вышло. А потом внезапно сильно продвинулся с помощью новой модели от Антропик - Fable 5. В итоге получился быстрый и функциональный qa-mcp - собственный контур тестирования для AI-разработки в 1С.

Спойлер: это не статья в стиле “Vanessa плохая, мы все переписали лучше”.

Vanessa Automation - классный, рабочий и очень важный инструмент, который принес в 1С-мир BDD (Behavior-Driven Development) и Gherkin-подход. Без нее этой истории, скорее всего, вообще бы не было. Но в какой-то момент стало понятно, что для AI-агента нам нужен не просто mcp-мост к Vanessa, а другой уровень владения последним метром проверки.

С чего все началось

Когда я начал собирать пакет инструментов “AI для 1С”, первое желание было довольно естественным: взять существующие инструменты для тестирования в 1С, обернуть их в MCP и дать AI-агенту нормальные “ручки” и “глазки” для работы через UI 1С:Предприятие.

Для полноценной работы аналитика и программиста в 1С с помощью AI-агента нам крайне желательно иметь несколько “коннекторов”:

• доступ к коду и метаданным конфигурации;

• доступ справке и стандартам разработки;

• доступ к данным в базе;

• умение за пользователя кликать мышкой и вносить данные в формы;

Поэтому в продукте постепенно появился набор инструментов: meta-mcp для карты конфигурации и кода, help-mcp для справки платформы, knowledge-mcp для внутренней документации, live-mcp для работы с данными в базе, config-mcp и bls-mcp для редактирования/валидирования XML/BSL-кода, admin-mcp для выполнения всевозможных консольных команд платформы. Плюс еще пара важных инструментов. А для тестирования UI сначала собрали свой vanessa-mcp-контур вокруг готовой Vanessa Automation, VanessaExt, client_mcp/WebTransportAddIn и Codex-обвязки. То есть не переписывали мир с нуля, а дали агенту аккуратные ручки к уже привычному BDD-слою.

На Linux это выглядело вполне терпимо. В headless-режиме окна 1С где-то там сами живут под Xvfb (виртуальный дисплей), тесты бегают, ничего перед глазами не мелькает. Ты сидишь, пьешь чай, агент что-то делает, сервер где-то шумит своими процессами.

А потом я начал адаптировать это все к поставке продукта “AI для 1С” для Windows и к нормальному повседневному использованию.

И тут выяснилась следующее: Если AI-агент запускает тестирование на моей рабочей машине, то он запускает 1С как полноценный сеанс - с окнами, формами, переключением вкладок, нажатием кнопок, выпадающими списками и так далее (собственно, а чего я хотел?). При этом рядом стартует еще одна 1С - менеджер тестирования. И все это начинает жить прямо на моем ноуте своей “тестовой” жизнью.

Сначала это даже было забавно - впервые кто-то в 1С работает вместо меня.

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

В какой-то момент я поймал себя на мысли: я делаю инструмент, который должен освободить меня от ручной проверки, но попутно он освободил меня от возможности нормально работать вообще. А второго ноута специально для AI-агента у меня нет (может ему еще ключи от квартиры, где деньги лежат?)

Так появилась простая идея:

А что если сделать свой AI-native менеджер тестирования на Python?

Идея звучала прекрасно ровно до того момента, пока я не сформулировать вторую половину:

Для этого надо разобраться, как именно сеансы 1С “разговаривают” между собой в режиме тестирования.

Как вообще устроено штатное тестирование в 1С

Тут надо сказать, что я не считаю себя экспертом в вопросах тестирования на 1С и Vanessa Automation. Нет, я конечно знал, что такое есть и даже пару раз сталкивался в моей многолетней практике разработчика 1С. Именно поэтому для меня было особенно важно “закрыть” этот блок максимально качественно.

Если совсем грубо, штатная картина такая:

Менеджер тестирования
   |
   | команды
   v
Клиент тестирования
   |
   | действия пользователя
   v
Формы 1С, элементы, сообщения, данные

Менеджер тестирования запускается с параметром вроде /TESTMANAGER. Клиент тестирования запускается с /TESTCLIENT и принимает управляющие команды механизма тестирования.

Vanessa Automation в этой схеме делает очень важную вещь: она дает человеку удобный BDD-слой. То есть вы пишете не низкоуровневый код управления формой, а сценарий на языке Gherkin:

# language: ru
Функциональность: Проверка валют

  Сценарий: открыть справочник валют
    Когда Я открываю основную форму справочника 'Валюты'
    Тогда Элемент формы с именем 'Наименование' присутствует на форме

А Vanessa транслирует это в штатные механизм тестирования 1С. Но если смотреть глазами AI-агента, то у нас получается несколько отдельных слоев:

.feature на Gherkin
   |
   v
библиотека шагов Vanessa
   |
   v
Vanessa Automation runtime
   |
   v
TestManager/TestClient 1С
   |
   v
реальная форма 1С

Моя идея была в том, чтобы сохранить верхний слой, потому что Gherkin и Vanessa-style шаги уже понятны 1С-сообществу, но убрать лишний runtime из середины:

.feature на Gherkin
   |
   v
qa-mcp transpiler + runner
   |
   v
native TestClient protocol
   |
   v
реальная форма 1С

Красиво? Да. Просто? Нет.

Потому что между “давайте управлять TestClient напрямую” и “у нас работает QA-контур” лежит довольно нетривиальная задача: разобрать протокол "общения" менеджера и клиента.

Задача, которая выглядела разумной минут десять

На бумаге задача раскладывалась так:

1. Научиться запускать native /TESTCLIENT в контролируемом окружении.

2. Понять handshake между менеджером и клиентом.

3. Записать реальные сессии штатного TestManager.

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

5. Научиться переигрывать минимальный набор кадров.

6. Понять, какие кадры зависят от конфигурации, а какие нет.

7. Сделать Python-раннер, который синтезирует команды без Vanessa runtime.

8. Поверх этого поднять MCP-сервер.

9. Поверх этого вернуть Gherkin, чтобы существующие сценарии не стали мусором.

10. Поверх этого добавить отчеты, проверки данных, regression gate.

В списке это звучит почти как нормальный план.

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

• вот у нас pcap;

• вот кадр;

• вот еще кадр;

• вот какие-то байты;

• вот GUID;

• вот поле, которое похоже на длину;

• нет, не длина;

• нет, все-таки длина, но не там;

• нет, это вообще другой слой;

• а почему это работает только если повторить ровно эти байты?

Я на тот момент плотно работал с Codex, в режиме максимально глубокого рассуждения. Развернул Linux-стенд на демо-конфигурации 1С, поднял клиент и менеджер, начал записывать трафик, строить гипотезы и гонять replay-пробы.

Через неделю я понял, что мы ходим по кругу. Точнее по самому краю этого круга.

Что-то получалось. Мы смогли разобрать байты handshake, научились узнавать несколько первых кадров, увидели структуру отдельных сообщений. Но общей карты не было. Идея “давайте просто составим карту всех возможных вариантов, которые менеджер может послать клиенту” умерла довольно быстро, как только я прикинул все пространство вариантов.

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

Я приуныл.

День, когда задача сдвинулась

Примерно в этот момент вышла новость про Fable 5. В моем понимании это был такой “урезанный Mythos от Anthropic” - достаточно сильная модель для сложного анализа, но без всей тяжести незаконных действий.

С Anthropic у меня к тому моменту были довольно натянутые отношения. За пару месяцев до этого они последовательно заблокировали несколько моих оплаченных аккаунтов. Деньги вернули, но желание бесконечно воевать с ними как-то пропало. Я в итоге просто ушел в Codex и решил: не одним Опусом единым…

Но тут задача была очень подходящая - крепкий орешек, как раз для проверки новой модели. Тут вам не лендос в один промпт написать. А взять мутный бинарный/полубинарный протокол 1С, кучу сырых данных, pcap (файлы с захваченными данными), куски Python-кода, гипотезы, провалившиеся гипотезы, и попытаться вытащить из этого что-то рабочее.

Я купил pro-аккаунт за 20 баксов и скормил модели задачу. И меньше чем за день мы прошли больше половину всей дороги!

Не половину продукта, конечно, а процентов 70-80 главной исследовательской задачи: понять, что внутри протокола и как его можно воспроизводить. Там, где до этого мы с Codex неделями осторожно ходили по краю, Fable 5 довольно бодро начал собирать связную картину: какие кадры являются обязательным handshake, какие можно переиспользовать, где динамические поля, какие команды можно синтезировать, а где надо не фантазировать, а брать результат захвата.

Это был тот редкий момент в AI-разработке, когда ты не просто ускорился, а реально прошел “сквозь стену”.

Я тут же купил максимальный тариф и продолжил работу уже на нем. Дальше история с доступностью к Fable 5 стала отдельным маленьким сериалом в мировом масштабе. Модель, как известно, быстро заблокировали вообще для всех, а мой уже открытый сеанс ... продолжал работать и работать! В итоге этот сеанс протянул еще двое суток и честно сделал свою часть работы, пока контекст не стал слишком тяжелым. Получилось как в сказке - было ровно 3 желания (3 дня), а потом лавочку прикрыли :-)

До полностью рабочего состояния MCP я доводил проект уже связкой:

• Codex - много прикладного кода по спецификациям, тесты, интеграционные куски;

• Claude Code Opus 4.8 - планирование, архитектура, стратегия;

• локальные проверки на Linux-стенде;

• много ручного здравого смысла, не банальной логики, опыта и навык танцев с бубном.

Если очень грубо оценивать, то первые 70% исследовательского прорыва заняли 3 дня с Fable 5, а превращение этого в рабочий продукт заняло еще около двух недель с Codex и Claude на максималках.

Что получилось в итоге

Проект получил название qa-mcp. Если коротко, это Python QA manager / MCP server, который управляет реальным 1С TestClient напрямую через нативный TestClient протокол, без Vanessa Automation в цепочке.

Текущее состояние на 23 июня 2026 года:

• около 60 MCP-инструментов (позже будет оптимизировано);

• 475 offline-тестов;

• поддержка (transpile) реального Vanessa-корпуса с 12% до 100%;

• live-verified возможности на реальном lab-контуре демо конфигурации 1С;

• Gherkin/BDD-слой;

• JUnit/Allure-отчеты;

• UI -> DB проверки через OData;

• генерация smoke-тестов из метаданных;

• Покрытие/Производительность через debug protocol;

• live-regression обвязка;

• protocol drift detector.

Сразу оговорюсь: “100% поддержка корпуса” не означает “любой .feature из любого проекта на планете пройдет без адаптации”. Это означает, что наш реальный Vanessa-корпус перестал быть отдельным миром: шаги распознаются, unmapped не исчезают молча, а сценарии можно переносить в qa-mcp как в целевой runner.

Высокоуровнево архитектура выглядит так:

Gherkin .feature или прямой MCP-вызов
   |
   v
qa-mcp FastMCP server
   |
   +-> transpile / run_scenario / run_step
   +-> read_form_descriptor / actions / assertions
   +-> assert_data / assert_data_count / role_data_matrix
   +-> generate_smoke_suite
   +-> measure_scenario
   +-> write_test_report
   |
   v
native TestClient protocol + Xvfb/XTEST там, где без GUI никак
   |
   v
реальная 1С

MCP-сервер в qa-mcp сделан на FastMCP.

Gherkin без Vanessa

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

mcp_server.open_list("Справочник.Валюты")
mcp_server.assert_form_value("Наименование", "...")

Для программного управления это нормально, но для 1С-сценариев уже есть культурный стандарт: Gherkin и Vanessa-style фразы.

Поэтому в qa-mcp есть:

• transpile - переводит .feature в native scenario JSON и сообщает unmapped steps;

• search_for_steps - показывает поддерживаемую библиотеку шагов;

• run_scenario - исполняет .feature или scenario JSON;

• run_step - исполняет один шаг, аналог execute_feature_step/execute_step_from_text в Vanessa-MCP-слое;

• BDD-механика: Scenario Outline, Examples, теги, Background, DataTables, вложенные сценарии.

Пример сценария:

# language: ru
Функциональность: Быстрая проверка формы

  Сценарий: открыть справочник валют
    Когда Я открываю основную форму справочника 'Валюты'
    Тогда Элемент формы с именем 'Наименование' присутствует на форме
    И Каждый шаг выполняется быстрее 60000 мс

Последняя строка уже не про буквальный перенос стандартного Vanessa-сценария. Это наш agent-facing шаг: проверка бюджета выполнения шага прямо в том же Gherkin/CI-контуре. В мире Vanessa тоже есть история про замеры производительности. Для нас отличие было в форме: агент получает машинно-читаемый gate. Мне было важно, чтобы транспилер не проглатывал молча непонятные строки. Если шаг не распознан, он должен попасть в unmapped. Лучше тест честно не соберется, чем создаст иллюзию, что он что-то проверил.

Почему это не просто паритет с Vanessa

Если бы qa-mcp только повторял Vanessa, это уже было бы полезно: меньше runtime-слоев, проще интеграция с agent workflow, прямой контроль над TestClient. Но настоящая ценность началась там, где мы добавили слой, которого не хватало именно нашему agent workflow. В нашем Vanessa-контуре проверка в основном жила в UI/BDD-слое: нажали, открыли, увидели. Это нормально для пользовательских сценариев. Но когда AI-агент меняет код, мне часто мало знать, что кнопка нажалась.

Мне нужно знать:

• что данные записались;

• что записей стало ровно столько, сколько нужно;

• что под другой ролью доступ отличается;

• что сценарий реально прошел по нужным строкам кода;

• что он не стал слишком медленным;

• что проверка не протухла после обновления платформы.

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

UI -> DB: проверить не только кнопку, но и данные

Самый простой пример: агент открыл форму, ввел значение, нажал “Записать”. UI-тест может увидеть, что форма закрылась или появилось сообщение. Но что стало с базой?

В qa-mcp есть assert_data: read-only OData-проверка, которая подтверждает, что UI-действие привело к ожидаемому изменению данных.

Потом это расширилось:

• assert_data_count - проверить количество записей по фильтру;

• absence checks - убедиться, что записей нет;

• role_data_matrix - прогнать data-layer read под разными ролями и увидеть, где read, а где denied.

Это уже не просто UI automation. Это связка пользовательского сценария с фактом в данных. Для 1С это особенно важно. Потому что “кнопка нажалась” и “документ провелся как надо” - разные утверждения.

Генерация smoke-тестов из метаданных

Второй слой, который мы вынесли в agent-facing MCP-инструмент, - metadata-driven smoke generation.

Если у нас есть meta-mcp, который знает конфигурацию, объекты, формы и навигационные ссылки, почему бы не сгенерировать базовый smoke:

• открыть основные формы справочников;

• открыть формы документов;

• проверить, что они рендерятся;

• собрать coverage по объектам.

Так появился generate_smoke_suite.

Сама идея дымовых сценариев по метаданным в мире Vanessa знакома. Отличие qa-mcp не в том, что “такого никто никогда не делал”, а в том, что это стало вызываемой агентом функцией поверх наших MCP-инструментов: посмотреть метаданные, собрать набор открытий форм, вернуть отчет о покрытии и сразу встроить это в regression workflow.

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

Опять же, это не замена QA-инженера. Это способ не начинать с пустого листа.

External EPF без VanessaExt

Еще один интересный хвост был связан с внешними обработками. В реальном Vanessa-корпусе был сценарий открытия внешней обработки или отчета .epf. В нашем Vanessa-контуре этот шаг был завязан на VanessaExt (внешняя компонента) и соответствующие механизмы.

В qa-mcp мы закрыли этот gap через open_external_processor: нативный путь “Главное меню -> Файл -> Открыть” -> GTK file chooser -> Unicode-safe path -> Enter.

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

Coverage и performance через debug protocol

Самая вкусная часть, которой мне не хватало именно в нашем Vanessa-MCP контуре, - measure_scenario. Идея такая: если мы уже запускаем сценарий в 1С, почему бы не измерять, какие модули и строки кода реально прошли, и сколько времени они заняли? В Vanessa есть своя история про замеры производительности, поэтому важное здесь не “мы первые придумали мерить скорость”, а форма интеграции: агент запускает сценарий и сразу получает машинно-читаемый результат для CI-gate. Для этого пришлось отдельно разобраться с /e1crdbg/ и debug protocol. В результате measure_scenario запускает замер производительности поверх сценария и возвращает named per-line coverage (построчное покрытие) + timing report (отчёт с временными метками).

Дальше поверх этого появились два CI-friendly gate:

• Gherkin-шаг “Каждый шаг выполняется быстрее N мс”;

• python -m qa_mcp.debug.gates для coverage gate.

То есть UI-сценарий может стать не только “прошло/не прошло”, но и источником ответа:

• какие модули реально были покрыты;

• какие строки прошли;

• где сценарий замедлился;

• можно ли выпускать изменение дальше.

Это уже сильно ближе к тому, что нужно AI-разработке. Потому что агент не просто “проверил кнопку”, а оставил измеримый след.

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

Теперь неприятная часть.

Наш “Native TestClient protocol” - это не публичный стабильный API, вокруг которого 1С обещает сохранять совместимость для внешних Python-драйверов.

В qa-mcp есть irreducible handshake (непреодолимое рукопожатие) и набор фреймовых шаблонов. Именно они привязаны к платформенному протоколу. В нашем lab-контуре это 8.3.27.2130. В других версиях платформах, часть байтов может остаться совместимой, а часть может поехать.

Поэтому рядом с драйвером появился инструмент “protocol drift detector”:

python -m qa_mcp.regression.versioning

И манифест:

config/protocol-capture-manifest.json

Там записывается версия платформы и хэши зафиксированных шаблонов. Если платформа отличается, детектор говорит: версия другая. Это не всегда значит, что все сломалось, но это сигнал. Если live-regression при этом зеленый, можно работать. Если красный - значит, протокол реально сдвинулся, надо обновить шаблоны. И для этого у нас есть подробный гайд для агента capture-refresh-runbook.md, где описано как это быстро исправить.

Что осталось некрасивым

Я не хочу, чтобы статья звучала как “мы всех победили”. Есть вещи, которые все еще требуют внимания.

Во-первых, часть действий не может быть чистым headless-протоколом. Ввод через ОС, выбор файла, некоторые GUI-действия - это Xvfb/XTEST, display, window manager, Unicode input. Это работает в наших тестах, но нужно еще гонять на более широком корпусе реальных сценариев.

Во-вторых, write-сценарии создают данные. Поэтому live-regression core по умолчанию read-only, а write roundtrip включается опционально. Иначе ночное тестирование внезапно станет фабрикой сотен тестовых валют, документов и прочих нежелательных следов в базе.

В-третьих, код вырос эмпирически. Когда ты сначала исследуешь протокол, потом быстро превращаешь это в рабочий инструмент, у тебя неизбежно появляются большие файлы и “магические байты”. В бэклоге еще остаются архитектурные задачи: разделить большие файлы по группам инструментов, оптимизировать сам состав доступных инструментов, добавить session/config object и кэширование шаблонов.

В-четвертых, юридический вопрос. Я пока не выкладываю проект в общий доступ, потому что не изучал границы: что можно публично делать с этим протоколом (это же по сути реверс инжиниринг, верно?), как на это смотрит 1С, где нормальная инженерная совместимость, а где зона юридических рисков. Если у вас есть опыт или понимание этой стороны вопроса, мне правда интересно обсудить это в личных сообщениях.

И наконец, это пока не коробка “скачал, нажал, все заработало на любой базе”. Это работающий MVP, который развивается и тестируется. Ключевые возможности доказаны, проверено в реальных задачах, regression gate есть, но путь до гладкой поставки для чужих контуров еще требует работы.

Что можно использовать отдельно

При этом qa-mcp потенциально можно использовать и отдельно от всего “AI для 1С”.

Если вам нужен native QA-контур:

• запускать Gherkin-сценарии без Vanessa runtime;

• читать формы через TestClient;

• делать UI -> DB проверки;

• генерировать smoke из метаданных;

• получать JUnit/Allure;

• гонять live-regression;

• экспериментировать с coverage/perf;

то это отдельная ценность.

Пока я не выкладываю проект публично, в первую очередь из-за юридических и продуктовых вопросов. Но если вам интересно попробовать qa-mcp в личной работе или на тестовом контуре, напишите (контакты в профиле). Я готов дать погонять бесплатно, за обратную связь. Мне хочется понять, насколько это нужно людям как отдельный инструмент.

Особенно интересно мнение тех, кто уже живет с Vanessa:

• чего вам в ней не хватает;

• насколько это проблема - запуск отдельного экземпляра 1С “Менеджер тестирования”;

• насколько нужны UI -> DB проверки (то есть проверить результат проведения документа по регистрам);

• хотите ли вы метрики покрытие/производительность поверх UI-сценариев;

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

Что я понял после этой истории

Главный вывод для меня такой:

Не надо стесняться браться за сложные задачи - держи нос по ветру и все получится.

А если вам интересна тема AI разработки в 1С, подписывайтесь на мой Telegram-канал “Желтый краб”: https://t.me/yellow_crab_ai. Там я пишу про новости из мира AI, про то, как и где AI реально можно использовать в 1С, какие инструменты у нас получаются, где модели помогают, а где все еще боль, окна и ручная инженерия.

И отдельно буду благодарен за комментарии:

• нужен ли такой инструмент, если есть классическая Vanessa;

• насколько вам важен режим без отдельного окна/сеанса Vanessa-менеджера тестирования;

• видите ли вы риск в работе с нативным TestClient протоколом;

• знаете ли вы юридические ограничения, которые стоит учитывать;

• какие сценарии 1С вы бы первыми отдали AI-агенту на проверку.

Мне кажется, что следующий большой шаг в AI для 1С в том, что будет честно доказана полноценная работа всей цепочки - от ТЗ до результата в проде.