Skills и MCP для разработки на 1С: что выбрать и как сочетать
Чем Skills отличаются от MCP в разработке на 1С: работа с XML и CLI, доступ к базе, актуальность выгрузки, ограничения безопасности и совместный процесс.
Skills помогают передать ИИ-агенту рабочие приёмы команды. MCP помогает подключить к агенту инструменты и источники контекста через общий протокол. В разработке на 1С полезны оба подхода: выбор зависит от того, нужно ли править выгрузку, работать с установленной конфигурацией или проверять результат в приложении.
Сам по себе каталог навыков не гарантирует знания о вашей информационной базе. Сам по себе MCP тоже не гарантирует актуального контекста и правильного кода. Разберём, где проходит эта граница и что проверять перед подключением.
В статье:
- Что дают Skills
- Что добавляет MCP
- Когда навыков достаточно
- Когда нужны дополнительные инструменты и контекст
- Как собрать общий процесс
Что дают Skills
По спецификации Agent Skills навык — каталог с файлом SKILL.md, инструкциями и необязательными скриптами, справочниками и шаблонами. Это способ упаковать повторяемую работу: как устроены исходники, какие команды запускать, в каком порядке проверять результат. Поддержка и порядок подключения зависят от конкретного агента.
Для 1С такой навык может описывать создание обработки из XML, изменение управляемой формы, сборку расширения, пакетный запуск Конфигуратора или проверку через веб-клиент. Скрипты способны вызывать CLI, обращаться к API и работать с живой базой, если среда предоставляет нужные программы, сеть и права. Ограничивать Skills одной текстовой памяткой было бы неверно: официальное руководство по скриптам рассматривает исполняемый код как часть навыка.
Сильная сторона подхода — близость к процессу разработки. Инструкции можно хранить рядом с кодом, проверять в ревью и менять вместе с принятыми в команде правилами. Например, навык может требовать после изменения формы собрать расширение, открыть форму в тестовой базе и пройти конкретный сценарий.
Что добавляет MCP
MCP задаёт общий способ взаимодействия клиента с сервером. Сервер объявляет доступные возможности, клиент подключает их к агенту. Архитектура MCP описывает эту связь независимо от предметной области: сервером может быть коннектор к 1С, файловому хранилищу или другой системе.
Через tools сервер публикует именованные операции со схемами входных параметров. Через resources он может отдавать контекст по URI. Есть также prompts — шаблоны взаимодействия. Конкретный сервер не обязан поддерживать все эти возможности.
Практическая польза для 1С — повторяемый интерфейс к метаданным, поиску, анализу и другим реализованным операциям. Агенту не приходится каждый раз собирать командную строку для одной и той же задачи. Но охват определяется сервером и редакцией продукта, а не словом MCP. У Feenlace состав опубликованных инструментов приведён отдельно для Открытой, Расширенной и Профессиональной версий.
| Вопрос | Skills | MCP |
|---|---|---|
| Где описан порядок работы | В инструкциях и связанных материалах | Может быть в описаниях и prompts; процесс всё равно нужно задать |
| Как запускается операция | Через доступные агенту инструменты, например shell | Через вызов опубликованного server tool |
| Откуда берётся контекст | Из файлов, скриптов и подключений среды | Из реализованных инструментов и ресурсов сервера |
| Что нужно сопровождать | Инструкции, скрипты, CLI и их зависимости | Сервер, совместимость клиента, подключения, права и зависимости |
| Что обеспечивает безопасность | Реальные ограничения среды и вызываемых систем | Реальные проверки клиента, сервера и вызываемых систем |
Когда навыков достаточно
Предположим, команда разрабатывает небольшую внешнюю обработку. Все XML-исходники находятся в репозитории, сборка уже воспроизводится одной командой, тестовая база доступна через существующий сценарий. В таком случае навык, который объясняет структуру проекта и запускает эти команды, может полностью закрыть задачу. Дополнительный сервер стоит подключать ради конкретного недостающего действия.
Навыки особенно удобны для соглашений команды: как именовать реквизиты, где хранить макеты, какие проверки обязательны перед передачей заказчику. Эти правила не возникают автоматически после подключения MCP. Даже подробная схема инструмента не объясняет, какой стиль кода принят именно у вас.
Когда нужны дополнительные инструменты и контекст
Первая причина — неполный исходный контекст. У агента может быть выгрузка типовой, а в тестовой базе установлены другие версии основной конфигурации и расширений. Инструкция «учитывай доработки» не добавляет отсутствующие модули. Нужен способ получить правильные исходники и подтвердить их происхождение: скриптом навыка, MCP-инструментом или существующим процессом выгрузки.
Вторая — различие между текстом и поведением. По XML можно увидеть реквизиты формы, но доступность поля может меняться в BSL при открытии. Наличие имени метода в файле не доказывает, что нужная ветка выполняется. Для таких вопросов требуется запуск в тестовой базе с подходящими данными. Навык может организовать этот запуск; MCP может предоставить часть операций. Оставшуюся проверку нужно выполнить явно.
Третья — сопровождение интеграции. Если каждый разработчик настраивает собственные пути к платформе, параметры подключения и скрипты, команда получает несколько вариантов одной процедуры. Единый MCP-интерфейс может уменьшить этот разнобой. При этом качественный общий CLI со стабильным контрактом тоже способен решить задачу: переход на MCP оправдан, когда он упрощает подключение и использование инструментов в ваших клиентах.
Наконец, важно различать просьбу и ограничение. Фраза «не изменяй рабочую базу» в навыке полезна как правило, но не заменяет запрета записи в вызываемой системе. То же относится к описанию MCP-инструмента. Рекомендации MCP по безопасности отдельно разбирают риски сервера и авторизации. Проверяйте фактические права, границы файлового доступа и состав данных, возвращаемых модели.
У MCP есть и эксплуатационная цена: запуск и обновление сервера, настройка соединений, диагностика сбоев, управление доступом. Локальное размещение коннектора само по себе не удерживает все сведения внутри компании: если клиент отправляет результат инструмента облачной модели, этот результат покидает локальную среду. Для конфиденциальных исходников нужно проверить всю цепочку, включая выбранного провайдера модели.
Как собрать общий процесс
Начните с одного реального изменения, например добавления поля в форму документа.
- В навыке закрепите порядок: найти объект, проверить связанные модули, внести правку, собрать, открыть форму и пройти сценарий.
- Получите контекст через уже работающие средства. Если используете MCP-1C, сверяйте доступные действия с вашей редакцией и списком инструментов клиента.
- Зафиксируйте источник: версия конфигурации, состав расширений, дата или ревизия выгрузки. Ответ по индексу старой выгрузки остаётся ответом по старой выгрузке, даже если соединение MCP установлено сейчас.
- Проверьте результат на тестовой базе: открытие формы, заполнение поля, сохранение и повторное открытие. Добавьте подходящий автоматический регресс в существующий набор.
- Перед переносом в рабочую среду примените обычное ревью и принятый порядок согласования.
Если сборка и проверки уже работают через общий CLI, навык может просто запускать их. Подключайте MCP, когда его готовые операции закрывают конкретный пробел — например, поиск по метаданным или доступ к нужному источнику. Порядок работы и проверка результата остаются частью процесса команды.
Для следующего шага: что делает MCP-сервер для 1С, как читать метаданные и как посмотреть схему формы по выгрузке.