EDT-MCP + v8std-MCP: учим ИИ-агента понимать ошибки EDT и писать код по стандартам 1С

Проблема: ИИ-агент видит код ошибки, но не знает стандартов 1С

Использование ИИ-ассистентов (Cursor, Claude Code, Cline, OpenCode, Antigravity) в 1С-разработке постепенно переходит из категории экспериментов в ежедневный рабочий инструмент. Если вы разрабатываете в 1С:EDT, для интеграции с агентами уже есть отличный мост - EDT-MCP. Он дает языковой модели доступ ко всей рабочей области EDT: дереву метаданных, структуре модулей, панели ошибок, запуску отладки и модификации исходников.

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

Агент вызывает инструмент get_project_errors в EDT-MCP и получает список диагностик:

- CommonModules/КлиентскийМодуль.bsl:15  BSLLS:UsingModalWindows
- Documents/ЗаказПокупателя.bsl:42       bsl-variable-name-invalid
- CommonModules/ФоновыеВызовы.bsl:8      CommonModuleMissingAPI
- Catalogs/Номенклатура/Forms/Форма:12   module-structure-method-in-regions

Коды ошибок перед агентом есть, но что именно требует стандарт 1С, модель не знает.

В обучающих выборках открытых и закрытых LLM стандарты разработки 1С (ИТС / v8std) представлены крайне скудно или фрагментарно. Правила регулярно обновляются вендором: меняются требования к асинхронным вызовам, структуре общих модулей, именованию переменных, областям видимости и защите от SQL-инъекций в SDBL.

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

Как подружить агента со стандартами: 3 подхода

Существует три способа передать агенту знание стандартов 1С.

Способ 1. «Пусть модель выкручивается сама»

Агент опирается только на свои внутренние веса. Для очевидных вещей (вроде удаления неиспользуемой переменной) это может сработать. Но для структурных требований (правильное разделение на #Область ПрограммныйИнтерфейс и #Область СлужебныеПроцедурыИФункции, тонкости вызовов без модальности, формат комментариев методов по стандартам ИТС) модель неизбежно ошибается.

Способ 2. Папка с описаниями в EDT-MCP («Check descriptions folder»)

В EDT-MCP есть полезная встроенная функция: можно указать локальный каталог с markdown-файлами описаний проверок из репозитория v8std. При вызове get_project_errors сервер автоматически обогащает выдачу полным текстом описания каждой найденной ошибки.

У этого подхода есть пара существенных минусов в реальной работе:

1. Перерасход контекста и токенов. Если проект выдает 50-100 замечаний статического анализа, плагин загрузит описания по всем 100 ошибкам прямо в контекстное окно агента. Это сотни килобайт текста, удорожание каждого запроса и риск вытеснения полезной истории диалога.
2. Сложность актуализации. Markdown-каталог нужно клонировать, хранить рядом с проектом и вручную обновлять при каждом релизе стандартов.

Способ 3. Второй MCP-сервер стандартов рядом (архитектурный оптимум)

Мы поднимаем рядом с EDT-MCP второй специализированный сервер - v8std-MCP, который выступает динамической базой знаний.

Агенту дается компактное системное правило (всего 5 строк): «Получил коды ошибок из EDT -> запроси их точечную расшифровку через v8std -> прочитай стандарт -> исправь код».

Преимущества схемы:

• Экономия контекста. Описания и тексты стандартов загружаются только по тем правилам, которые агент реально исправляет в текущей итерации.
• Связи стандартов. v8std знает иерархию: как код проверки АПК, BSL LS или 1C:Code style V8 связан с конкретным пунктом официального стандарта 1С (например, std455, std454, std456).
• Свежесть данных. Сервер содержит актуальный структурированный индекс базы v8std.ru.

Архитектура: разделение обязанностей двух MCP

В этой связке каждый инструмент делает то, для чего он спроектирован:

1. EDT-MCP (http://localhost:8765/mcp): предоставляет агенту API для взаимодействия с проектом 1С.
2. v8std-MCP (http://localhost:8766/mcp): предоставляет семантическую базу знаний стандартов 1С.

Доступные методы v8std-MCP

Почему локальный Docker-контур критичен для 1С-разработки

У проекта v8std есть публичный сервер (https://ai.v8std.ru/mcp). Однако для реальной корпоративной разработки на 1С использование внешнего MCP несет риски:

1. Конфиденциальность и NDA. Когда агент использует explain_snippet или анализирует контекст модуля, фрагменты исходного кода вашей конфигурации передаются на сервер MCP. В локальном Docker-контейнере весь код остается на вашей машине или в закрытой сети предприятия.
2. Стабильность и скорость. Локальный контейнер на Alpine с готовым индексом отвечает за миллисекунды и не зависит от доступности внешних каналов связи.
3. Безопасность сетевого контура. Сервер v8std поддерживает встроенную защиту от DNS-rebinding, предотвращая несанкционированный доступ из браузеров к локальным RPC-интерфейсам.

Быстрый старт: готовый легковесный Docker-образ

Раньше для локального запуска v8std требовалось клонировать весь репозиторий проекта, собирать образ локально и запускать сборку вместе с генератором статического сайта zensical.

Чтобы убрать этот барьер, я подготовил отдельную легковесную MCP-сборку на базе Alpine Linux (без зависимостей zensical и HTML-рендерера). База стандартов и предрассчитанный поисковый индекс уже упакованы внутрь образа.

Изменения предложены в upstream-репозиторий (zeegin/v8std#33), а готовый multi-arch образ опубликован в Docker Hub: malikovpro/v8std-mcp:latest (~305 МБ, архитектуры linux/amd64 и linux/arm64).

Вариант 1: Запуск одной командой

bash

docker run -d --name v8std-mcp -p 127.0.0.1:8766:8765 malikovpro/v8std-mcp:latest

Вариант 2: Запуск через docker-compose (для рабочих станций и командного сервера)

Создаем docker-compose.yml:

yaml

services:
  v8std-mcp:
    container_name: v8std-mcp
    image: malikovpro/v8std-mcp:latest
    restart: always
    ports:
      - "${V8STD_MCP_BIND:-127.0.0.1}:8766:8765"
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    environment:
      V8STD_MCP_PORT: "8765"
      V8STD_MCP_ALLOWED_HOSTS: "${V8STD_MCP_ALLOWED_HOSTS:-}"

Рядом размещаем файл .env:

ini

# Разрешенные хосты для защиты от DNS-rebinding:
# Указывается точный хост или префикс:* (например: 192.168.57.18:*, devserver.local:*)
V8STD_MCP_ALLOWED_HOSTS=192.168.57.18:*, localhost:*

# Интерфейс публикации: 127.0.0.1 (только локально) или 0.0.0.0 (для всей локальной сети)
V8STD_MCP_BIND=127.0.0.1

Запуск:

bash

docker compose up -d v8std-mcp

Важные нюансы настройки сети

1. Разведение портов. EDT-MCP по умолчанию слушает порт 8765, и v8std внутри контейнера тоже настроен на 8765. Чтобы избежать конфликта, публикуем v8std наружу на порт 8766 (маппинг 8766:8765).
2. Защита DNS-rebinding. Библиотека MCP SDK проверяет заголовок Host. Если вы разворачиваете v8std на выделенном сервере для команды 1С, обязательно добавьте IP/доменное имя сервера в переменную V8STD_MCP_ALLOWED_HOSTS. Записи вида 192.168.57.* SDK отклоняет - требуется формат 192.168.57.18:* или имя хоста.

Подключение связки EDT-MCP + v8std-MCP к агентам

1. Claude Code

Добавление двух серверов в CLI:

bash

claude mcp add --transport http EDT-MCP http://localhost:8765/mcp
claude mcp add --transport http v8std http://localhost:8766/mcp

2. Cursor (.cursor/mcp.json)

json

{
  "mcpServers": {
    "EDT-MCP": {
      "url": "http://localhost:8765/mcp"
    },
    "v8std": {
      "url": "http://localhost:8766/mcp"
    }
  }
}

3. Cline / OpenCode / Antigravity

В интерфейсе настроек MCP-серверов добавьте два SSE/HTTP endpoint:

• Name: EDT-MCP, URL: http://localhost:8765/mcp
• Name: v8std, URL: http://localhost:8766/mcp

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

Чтобы агент понимал, как комбинировать возможности обоих MCP-серверов, добавьте в конфигурацию правил вашего ассистента (.cursorrules, .cursor/rules/1c.mdc, CLAUDE.md или системный промпт) следующий блок:

markdown

# Правило работы с кодом 1С и ошибками EDT

При анализе и исправлении ошибок из EDT-MCP (инструменты get_project_errors, get_problem_summary):

1. Извлеки коды диагностик из отчета EDT (префиксы BSLLS:xxx, v8cs:xxx, acc:NNNN, символические id EDT).
2. Вызови инструмент v8std_explain_diagnostics пакетом со всеми найденными кодами, чтобы получить их описания и ссылки на связанные стандарты.
3. Перед модификацией кода обязательно прочитай требования стандарта через v8std_get_page и следуй каноническому стилю 1С, а не догадкам.
4. Если код диагностики не расшифровался (вернулся в unknown_codes) - выполни поиск по ключевой фразе ошибки через v8std_search.
5. При внесении правок через write_module_source сохраняй структуру областей модуля и оформляй экспортные методы по канонам ИТС.
6. После правок вызови revalidate_objects или get_project_errors для подтверждения устранения замечаний.

Благодаря этому правилу агент перестает изобретать собственные стандарты и работает как квалифицированный 1С-разработчик, сверяясь с ИТС.

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

Посмотрим на работу связки в реальной сессии. В качестве подопытного выступает общий модуль ОбработкаСообщенийВФоне тестовой конфигурации 1С.

Шаг 1. EDT-MCP: сбор ошибок статического анализа

Агент запрашивает список проблем через get_project_errors(projectName='Информационная_база_1', objects=['ОбработкаСообщенийВФоне']):

text

Найдено 32 ошибки в модуле ОбщийМодуль.ОбработкаСообщенийВФоне:

| Описание проблемы                                       | Код проверки (Check ID)            |
|---------------------------------------------------------|------------------------------------|
| Метод "ОжиданиеИОбработкаСообщений" необходимо          | module-structure-method-in-regions |
|   разместить в одной из стандартных областей...         |                                    |
| Имя переменной мз введено некорректно                   | bsl-variable-name-invalid          |
| Неиспользуемая локальная переменная 'Ответ'             | module-unused-local-variable       |
| [BSL LS] Общий модуль должен иметь хотя бы один         | CommonModuleMissingAPI             |
|   экспортный метод в области ПрограммныйИнтерфейс       |                                    |
| [BSL LS] Используется прямое указание пути к файлу      | UsingHardcodePath                  |
| [BSL LS] Длина строки 128 превышает лимит 120 символов  | LineLength                         |
| [BSL LS] Несколько подряд идущих пустых строк           | ConsecutiveEmptyLines              |

В отчете одновременно присутствуют и нативные проверки 1C:Code style V8 из EDT, и проверки BSL Language Server с префиксом [BSL LS].

Шаг 2. v8std-MCP: пакетная расшифровка кодов

Агент берет список кодов и вызывает v8std_explain_diagnostics:

json

{
  "codes": [
    "v8cs:module-structure-method-in-regions",
    "bslls:CommonModuleMissingAPI",
    "bslls:LineLength",
    "bslls:UsingHardcodePath",
    "bslls:UnusedLocalVariable",
    "v8cs:variable-name-invalid"
  ]
}

Результат ответа v8std-MCP:

text

Расшифровано:
- v8cs:module-structure-method-in-regions -> Связанный стандарт: std455 «Структура модуля»
- bslls:CommonModuleMissingAPI            -> Связанный стандарт: std455 «Структура модуля»
- bslls:LineLength                        -> Связанный стандарт: std456 «Тексты модулей»
- bslls:UsingHardcodePath                 -> Описание: запрет литералов путей к файлам в коде
- bslls:UnusedLocalVariable               -> Описание: удаление мертвых переменных

В unknown_codes:
- v8cs:variable-name-invalid

За один запрос агент получил привязку к стандартам std455 и std456 и конкретные указания по оформлению.

Шаг 3. Обработка неизвестного кода через v8std_search

Код v8cs:variable-name-invalid не сопоставился напрямую. Срабатывает пункт 4 системного правила: агент выполняет поиск по тексту ошибки:

v8std_search(query='Имя переменной введено некорректно строчные буквы')

Поисковый индекс v8std выдает:

• Диагностика: acc:248 («Имена переменных не должны начинаться с подчеркивания или строчных букв»)
• Первоисточник: стандарт std454 «Правила образования имен переменных»

Шаг 4. Чтение стандарта и автоматический рефакторинг

Агент запрашивает полный текст v8std_get_page(id_or_alias_or_url='std455'), видит точный синтаксис канонических областей 1С и вносит исправления в модуль через write_module_source:

1. Структура модуля (std455): Процедуры и функции распределены по областям #Область ПрограммныйИнтерфейс и #Область СлужебныеПроцедурыИФункции.
2. Именование (std454): Переменная мз переименована в МассивЗадач, переменная no_ack заменена на CamelCase-идентификатор БезПодтверждения.
3. Чистка кода: Удалена неиспользуемая переменная Ответ, убраны лишние пустые строки.
4. Безопасность: Хардкод пути C:\temp\queue.json вынесен в параметр процедуры.

После перезапуска валидации в EDT количество ошибок в модуле становится равным 0.

Практические сценарии внедрения для команд 1С

1. Автоматизация Code Review на раннем этапе. Агент в связке с EDT-MCP и v8std может автоматически проходить по измененным в Git ветках модулям, выдавать замечания с точными ссылками на пункты стандартов ИТС и формировать pull request с автоисправлениями.
2. Обучение начинающих разработчиков. При разработке в паре с ИИ-ассистентом программист получает не просто исправленный код, но и пояснение, какому именно пункту стандарта 1С не соответствовал изначальный вариант.
3. Миграция легаси-кода. Быстрое приведение старых конфигураций 1С (написанных без соблюдения областей, без стандартов именования и с синхронными вызовами) к современным требованиям стандартов платформы 8.3.

Резюме и ссылки

Связка EDT-MCP и v8std-MCP превращает ИИ-ассистента из генератора случайного кода в строгого 1С-линтера и архитектурного помощника, действующего строго в рамках стандартов ИТС. А готовый Docker-образ позволяет поднять этот контур за пару минут без сложной настройки окружения.

Полезные ссылки:

• EDT-MCP на GitHub - сервер интеграции с 1С:EDT
• v8std на GitHub - открытая база стандартов разработки 1С и диагностик
• Сайт v8std.ru - онлайн-версия стандартов и правил
• Docker Hub: malikovpro/v8std-mcp - готовый легковесный образ MCP-сервера
• Pull Request #33 в zeegin/v8std - сборка Alpine-образа v8std-MCP
• BSL LS connector for EDT на GitHub - плагин моста BSL LS для EDT
• Статья на Инфостарте о BSL LS коннекторе - первая часть цикла