Давайте почнемо одразу з невеликої провокації.

Програмісти 1С — приготуйтеся.

Чому — я розповім трохи пізніше. А поки подивимося на результат того, що вдалося зробити.

Пошук даних у 1С через кодового агента

Отже, у нас є Claude Code. Давайте поставимо йому просте запитання:

Знайди мені всі вентилятори в 1С.

По суті, це кодовий агент, до якого підключений MCP-сервер. Подивимось, що він робить.

Спочатку він виконує індексацію. Продукт поки що трохи недопрацьований — індексацію, звісно, не потрібно робити щоразу, але з якоїсь причини вона виконується при кожному запиті.

Проте результат ми отримуємо:

  • система знайшла всі вентилятори у базі;

  • повернула 11 позицій.

Це типова демонстраційна база “Управління торгівлею”.

Отримання залишків товарів

Тепер попросимо систему:

Показати залишки по знайдених позиціях.

У цей момент задіюється ще одна функція. Ми підключаємо 1С безпосередньо до агента, після чого з’являється можливість ставити запитання безпосередньо до бази даних.

Наприклад:

  • яка є номенклатура;

  • залишки товарів організацій;

  • різні види звітів.

Після запиту формується звіт по залишках, і система повертає всю необхідну інформацію.

Що це взагалі таке

По суті, вийшов AI-агент, до якого підключений MCP-сервер з повністю універсальними звітами.

Як це працює:

  • агент сам формує фільтри для звітів;

  • він сам вирішує, який звіт потрібно викликати;

  • він сам передає параметри;

  • після отримання звіту з 1С аналізує дані та видає результат.

Наприклад:

  • можна запросити залишки по конкретній позиції;

  • можна отримати залишки по конкретному контрагенту;

  • можна запросити заборгованості або інші дані.

Система сама підбирає потрібний звіт і формує параметри.

Структура проєкту

Ось як виглядає проєкт.

У ньому є:

  • розширення MCP для 1С

  • тести для перевірки розширення

  • опис проєкту

  • невелика документація

Також у Claude підключені різні skills для роботи з 1С.

Найцікавіше: код я не писав

Тепер головний момент.

Я не написав жодного рядка коду.

Єдине, що було зроблено:

  1. Взяв базу 1С.

  2. Створив порожнє розширення.

  3. Вивантажив його в папку у вигляді XML-файлів.

Після цього я:

  • створив skill для Claude, який уміє:

    • завантажувати розширення у конфігуратор;

    • застосовувати його до бази;

    • перевіряти результат.

Потім:

  • база була опублікована на веб-сервері;

  • Claude отримав адресу публікації.

І після цього вся робота відбувалася лише через запити.

Наприклад:

  • зроби це;

  • зроби те;

  • додай таку функцію.

Як відбувалася розробка

Claude виконував повний цикл розробки:

  1. створював код;

  2. завантажував зміни в базу;

  3. автоматично застосовував розширення;

  4. перезапускав Apache;

  5. тестував роботу MCP-сервера;

  6. виправляв помилки.

Таким чином, буквально за один день було написано MCP-сервер.

Що вміє створений MCP-сервер

Сервер уміє:

  • автоматично вибирати потрібний звіт;

  • передавати в нього параметри;

  • аналізувати результати.

Для пошуку використовується нечіткий пошук через ембедінги.

Було зроблено:

  • індекс номенклатури

  • індекс контрагентів

Це дозволяє писати запити звичайною людською мовою.

Наприклад:

Дай залишки по 901 вентиляторам.

Агент:

  1. розуміє, що мова про вентилятори;

  2. знаходить потрібні моделі;

  3. формує звіт;

  4. повертає агреговані дані.

Не потрібно вводити точну назву номенклатури, як це робиться в деяких демонстраціях.

Скільки коду написав агент

Якщо подивитися на код:

  • 5 рядків BSL

  • 43 експортні функції API MCP

  • 1 HTTP-сервіс

  • кілька загальних модулів

HTTP-сервіс я зробив лише один раз — щоб база була опублікована і можна було перевірити, що вона працює.

У ньому просто є GET-запит, який повертає тестовий результат.

Усе інше писав Claude.

Архітектура рішення

У проєкті з’явилися такі модулі.

Ядро роботи зі звітами СКД

Основний механізм виклику звітів.

MCP-сервер

Спочатку був написаний базовий сервер, після чого він почав розширюватися.

Модуль індексації контрагентів

  • будує індекс

  • забезпечує нечіткий пошук через ембедінги

Модуль індексації номенклатури

Аналогічний модуль для товарів.

Універсальний модуль звітів

Він:

  • викликає звіти через СКД

  • передає параметри

  • знає, які параметри є у кожного звіту

Як проходила робота з кодом

Агент:

  • знаходив потрібні файли у розширенні

  • змінював їх

  • завантажував у конфігуратор

  • застосовував

  • тестував

  • знову змінював

Він також ставив запитання про те, як повинна працювати система.

Я виступав радше як архітектор, який спрямовує розробку.

Наскільки хороший вийшов код

Якщо подивитися на результат — код написаний достатньо непогано.

Але важливо розуміти:

  • я знаю архітектуру

  • я знаю, як правильно будувати такі системи

Тому я давав багато навідних підказок:

  • як організувати модулі

  • як будувати архітектуру

  • які патерни використовувати

Але більша частина коду написана повністю Claude.

Куди можна розвивати систему

Зараз MCP-сервер вийшов досить універсальним, але є напрямки розвитку.

Наприклад, іноді агент обирає не найкращий звіт.

Це можна покращити:

  • зробити окремий інструмент для кожного звіту

  • детально описати:

    • що робить інструмент

    • які параметри приймає

Можливі розширення

Далі можна додати:

  • формування замовлень голосом

  • підключення до будь-якого кодового агента

  • запуск усередині корпоративного контуру

Це важливо, тому що тоді дані не покидають підприємство.

Чому це важливо для 1С

Якщо ви думаєте, що такі технології ще не скоро торкнуться 1С, то це прямий доказ зворотного.

У цьому експерименті:

  • увесь код написав кодовий агент

  • людина виконувала лише:

    • архітектурну роль

    • налаштування середовища

    • постановку задач

Що відбувається в інших мовах

В інших екосистемах це вже активно розвивається.

Наприклад, у Python:

  • кодові агенти вже пишуть більшу частину коду;

  • розробник виступає як архітектор і рев’юер.

Він:

  • перевіряє код

  • затверджує зміни

  • приймає рішення про додавання у основний проєкт.

Майбутнє розробки в 1С

Залишається відкрите питання:

чи будуть подібні підходи розвиватися в екосистемі 1С?

Звісно, з розширеннями працювати простіше:

  • їх легше вивантажувати

  • легше завантажувати назад

А от із повноцінними конфігураціями та формами все може бути складніше.

Але сучасні кодові агенти:

  • мають великий контекст

  • стають усе розумнішими

І вони вже можуть:

  • виступати помічниками розробника

  • значно прискорювати розробку

Підсумок

На мою думку, вже час розвивати архітектуру розробки навколо кодових агентів і у світі 1С.

В інших мовах і екосистемах це розвивається дуже активно.

Цілком можливо, що в майбутньому модель розробки виглядатиме так:

  • код пише агент

  • архітектор спрямовує процес

  • розробник контролює якість

Оцените post