ИИ‑агент внутри 1С

1C AI Agent — продукт, который не “поговорить”, а “сделать”

Привет. Это первая публикация про наш новый продукт — 1C AI Agent.

Если коротко: LLM — это уже нормальный рабочий инструмент, и с ним всё ок. Но нам хотелось сделать следующий шаг: чтобы в 1С можно было не только “спросить и получить текст”, а попросить и получить результат в базе — с понятным планом, проверками и ограничениями.

Мы сделали иначе: агент внутри 1С получает задачу человеческими словами, раскладывает её на шаги и исполняет их через ограниченный набор команд (DSL). Это нужно не чтобы “поиграться с ИИ”, а чтобы быстрее получать ответы из базы и собирать аналитику без бесконечного “а сделай мне ещё один отчёт”.

LLM‑редактор: «О, наконец-то. Не “магия в тумане”, а список команд. Эти кожаные хоть что-то начали фиксировать контрактами».

Ссылки

• Репозиторий: msrv-tech/AI_agent

• Демо-база: app498780.1capp.net/1SUpravleniye-torgovley-II-agent

  • Доступ: логин Администратор, пароль 123456

  • Важно: демо-база доступна всем. После теста удалите свой токен/ключ ИИ из настроек, чтобы его не украли и не “слили” ваш бюджет.

• Документация:

  • Архитектура

  • DSL (команды и формат сценариев)

  • Безопасность

  • Тестирование

  • Планирование

  • RAG-поиск

Демо (скриншоты и видео)

Скриншот: форма агента (UI)

Скриншот: RAG/поиск по метаданным

Видеодемонстрация: простой запрос

Запрос для демо: «покажи топ контрагентов по суммам приходных накладных».

• Смотреть на Rutube: https://rutube.ru/video/70b6925431794a787177936b374d868d/

• Скачать mp4 (оригинал): https://raw.githubusercontent.com/msrv-tech/AI_agent/main/docs/articles/product_first_publication/media/demo_top_contractors_incoming_invoices.mp4

LLM‑редактор: «Если в видео нет “до/после” и результата — это не демо, это медитация на курсор».

TL;DR (для занятых и слегка уставших)

• Это: ИИ‑агент для 1С:Предприятие, который умеет читать данные, строить запросы, подбирать объекты и (при разрешении) создавать/заполнять документы и элементы.

• Ключевая идея: модель не “рулит базой напрямую”. Она предлагает DSL‑сценарий, а 1С исполняет только то, что разрешено.

• Контроль: есть read‑only режим и ограничения на запись по пользователям.

• ИИ‑провайдер: можно подключить любой OpenAI‑совместимый сервис/сервер. Но для ежедневной аналитики лучше выбирать недорогую модель/провайдера, чтобы не “слить” бюджет на токены за неделю.

• Для кого: в первую очередь для аналитиков и владельцев процессов, которым нужно быстро получать ответы из 1С и при этом не страшно дать системе “действовать” (в рамках правил). Для разработчиков тоже ок — но это вторичная аудитория этой статьи.

Технические ограничения

• Платформа 1С:Предприятие: не ниже 8.3.26.

  • Причина простая: для работы агента используются серверные уведомления (УведомленияСервер), а их нормальная эксплуатация начинается с этой версии.

• Режим совместимости конфигурации: должен быть не ниже 8.3.26 (иначе часть механики будет недоступна/нестабильна).

LLM‑редактор: «Если у вас платформа древнее — агент, конечно, “может”, но вы точно хотите тратить время на археологию вместо аналитики?».

Перед первым использованием: индексация RAG

Перед первым использованием нужно запустить индексацию RAG (обычно около часа).

Что там делается:

• агент собирает метаданные конфигурации (объекты, поля, табличные части, связи),

• режет их на “чанки”,

• строит индекс для семантического поиска, чтобы потом находить нужные справочники/документы/регистры “по смыслу”, а не угадывать названия.

Поддерживаемые типовые конфигурации (стартовый список)

Ниже — ориентир, с каких типовых конфигураций/релизов логично начинать поддержку порога совместимости (≥ 8.3.26).

Результаты по конфигурациям

Для аналитиков: зачем это вообще нужно

В любой живой 1С‑системе аналитик регулярно делает одно и то же:

• вытаскивает цифры “прямо сейчас” (продажи/остатки/дебиторка/заказы);

• уточняет “а почему не сходится” (сверки, отборы, исключения);

• собирает одноразовые разрезы “на встречу через 10 минут”;

• просит разработчика “маленький отчётик” — который потом почему-то живёт годами.

Мини‑сцена из жизни (чтобы было понятно “зачем”)

Понедельник, 09:57. В 10:00 созвон. Вам нужно: выручка/маржа за неделю, “кто просел”, и пару строк “почему”.
Обычно это: открыть отчёт → понять, что разрез не тот → добавить отбор → снова → экспорт → вставить в презентацию → ещё один вопрос прилетает в чат.

С агентом хочется так:

• вы пишете один запрос человеческим языком (и сразу даёте ключевые вводные),

• агент показывает план и выполняет шаги,

• отдаёт таблицу + короткий вывод.

LLM‑редактор: «Я правильно понял: вы хотите “быстро и правильно”, а не “красиво и сомнительно”? Наконец-то».

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

LLM‑редактор: «Секрет прост: людям не нужен “ИИ”, людям нужен “чтобы оно перестало забирать время”. Но это скучно для презентации, да?».

Что именно умеет агент (в терминах аналитика)

1) Понимать запрос и показывать план, что он сделает

Вместо “одного большого ответа” агент строит план и двигается по циклу: Plan → Execute → Validate.

Плюс для аналитика простой: вы видите какие шаги он выполняет (какие отборы/что ищет/что считает) и можете остановить или уточнить, если он пошёл не туда.

2) Находить нужные данные в вашей конфигурации (даже если названия “как всегда”)

Агент умеет ориентироваться в структуре базы: находить нужные справочники/документы/регистры, подтягивать поля и связи, чтобы ответить на запрос без угадываний “на честном слове”.

3) Делать действия строго в рамках разрешённых операций

Есть “язык команд” (DSL) — по сути, список безопасных действий. Модель не выполняет произвольный код. Она формирует план из разрешённых шагов, а дальше их исполняет 1С.

Если вам неинтересны названия команд — это нормально. Важно другое: если агент “придумал поле”, система не делает вид, что всё ок — она вернёт ошибку, и агент должен перестроиться.

LLM‑редактор: «Вот здесь люди обычно делают “давайте модель сама напишет запрос/код”. Потом удивляются, почему она “сама” написала не то. Но это же *не баг*, это *характер*».

Безопасность: где мы поставили бетон, а где всё ещё нужна голова

Мы исходили из грустного, но полезного наблюдения: модель не обязана быть аккуратной.

Поэтому:

• Read‑only режим: для диалогов/пользователей можно запретить любые действия изменения данных. Если модель попыталась — получите ошибку (read_only_violation), а не “ну оно случайно записалось”.

• Ограничение записи по пользователю: запись можно запретить точечно, не меняя режимы всем.

• Валидация выполнения: агент не должен “выводить данные из воздуха” — только то, что реально получил от базы.

LLM‑редактор: «Хорошо. Потому что “я уверен, что поле называется СуммаДокумента” — это не уверенность, это агрессивная фантазия».

Как это выглядит в жизни (несколько нормальных запросов)

То, что обычно хочется сказать агенту аналитику/руководителю:

• «Покажи выручку и маржу за прошлую неделю по менеджерам. Отдельно выдели топ‑3 падения».

• «Найди клиентов с просрочкой больше 30 дней и суммой долга выше N. Сгруппируй по менеджерам».

• «Какие товары на складе Основной имеют остаток меньше 5? Добавь продажи за 14 дней рядом».

• «Проверь расхождения: заказы есть, а реализаций нет. Список + суммы».

• «Собери краткий отчёт по динамике продаж за месяц и объясни, что сильнее всего повлияло».

Идеальный UX тут такой:

1. агент показывает план,

2. выполняет шаги,

3. возвращает результат и короткое резюме.

LLM‑редактор: «Главное — не заставляйте пользователя читать простыню. Эти кожаные и так страдают, у них ещё регламент по согласованию отчёта на 12 листов».

Мини‑скринплей: как это должно происходить

• Аналитик: “Покажи выручку и маржу за прошлую неделю по менеджерам. Выдели топ‑3 падения и причину (если видно по данным)”.

• Агент: “План: 1) получу продажи за прошлую неделю, 2) сгруппирую по менеджерам, 3) посчитаю маржу, 4) найду топ‑3 падения, 5) покажу краткий вывод. Если период/организация у вас задаются нестандартно — лучше укажите их явно в запросе”.

• Агент (результат): “Таблица + итог. Топ‑3 падения: …”

LLM‑редактор: «Пока уточнений нет — пишите вводные сразу. Эти кожаные любят “сделай отчёт”, а потом удивляются, что забыли период».

Чек‑лист: как писать запрос, чтобы агент не гадал

• Период: “прошлая неделя” лучше уточнить как “календарная неделя” или “последние 7 дней”.

• Организация/юрлицо: если их несколько — укажите.

• Валюта/НДС: если это важно для сравнения — проговорите.

• Разрез: менеджер/подразделение/склад/категория/номенклатура.

• Метрика: выручка, маржа, количество, средний чек, задолженность.

• Формат: “таблица + итог”, “топ‑N”, “список проблем”, “короткий вывод”.

LLM‑редактор: «Самая дорогая фраза в аналитике: “за какой период?”. Вторая по цене: “по какой организации?”».

Если рядом есть разработчик (или вы сами “чуть-чуть технарь”)

Если захотите разобраться глубже/расширить возможности, полезные точки в репозитории:

• Модули 1С: xml/CommonModules/

  • ИИА_Оркестратор — цикл планирования/выполнения/проверки и остановки по лимитам/ошибкам

  • ИИА_DSL — интерпретатор JSON‑команд и валидации (в том числе read‑only)

  • ИИА_Промты — системные инструкции, контекст, политика “как говорить и как не ломать”

• Технические доки:

  • docs/AGENT_ARCHITECTURE.md — карта модулей и поток данных

  • docs/DSL.md — формат и набор DSL‑действий

  • docs/SECURITY.md — режимы и ограничения

LLM‑редактор: «Если у вас нет документа “Безопасность”, то у вас не продукт, а демонстрация. Тут — хотя бы попытка взрослой жизни».

Честные ограничения (чтобы потом не было “вы обещали”)

• Агент — не автопилот “всё сам”. Он сильный там, где задача раскладывается на шаги и есть правильные инструменты.

• Качество напрямую зависит от контрактов команд, промптов и политики ограничений.

• Если вы хотите write‑сценарии в проде — придётся думать про подтверждения, роли, аудит и границы ответственности.

LLM‑редактор: «Ну да. Потому что “пускай агент проводит документы” — это так же безопасно, как дать стажёру права администратора и сказать “только аккуратно”».

Что агент НЕ делает (и это хорошо)

• Не “угадывает правду” вместо данных: если данных нет или они неоднозначны — нормальная реакция — уточнить или честно сказать “не нашёл/нужно уточнение”.

• Не исполняет произвольный код: агент действует через ограниченный набор разрешённых команд, а не через “а давай я тут сам что-нибудь выполню”.

• Не пишет в базу без правил: есть read‑only режим и ограничения на запись по пользователям — это сознательно, чтобы не превращать аналитику в лотерею.

LLM‑редактор: «Да, иногда это означает “я не могу”. Но это лучше, чем “я могу всё” и потом у вас минус склад».

Как мы тестируем (Python)

Чтобы не обсуждать “ну вроде работает”, у нас есть тестовый контур на Python, который гоняет сценарии через COM и собирает отчёт с метриками.

• Запуск: run_tests.py (COM‑прогон, 1С “в фоне”, без ручного открытия клиента).

• Режимы:

  • бесплатные тесты без вызова ИИ (по умолчанию),

  • режим без реального ИИ на мок‑ответах,

  • боевые тесты с реальным вызовом LLM.

• Артефакты: логи + итоговый report.json (там есть passed_count, avg_score, cost_rub, total_tokens, причины провалов и разбор по сценариям).

Образец прогона (10 сценариев, один из отчётов):

• avg_score: 75.7

LLM‑редактор: «75.7 — это когда “в целом работает”, но ещё не тот уровень, чтобы кожаные расслабились и перестали проверять цифры глазами».

Как читать score (по‑простому):

• 90+ — можно пользоваться без внутренней боли (но период всё равно проверьте).

• 70–89 — обычно ок, но возможны лишние уточнения/шаги.

• < 70 — работает, но местами “сыровато”: либо много лишних действий, либо результат требует перепроверки.

Оценки (score) по каждому сценарию из этого прогона от 0 до 100:

• Заказы клиента за прошлую неделю (сумма) — 80

• Остатки на складе ниже порога — 88

• Черновик приходной накладной по счёту — 71

• Анализ продаж и топ‑3 растущих категории — 52

• Топ‑5 клиентов по продажам (вложенное поле Контрагент.Наименование) — 88

• Отчёт по продажам с восстановлением после ошибки поля — 91

• Пустые данные (будущий период) — 68

• Анти‑дубли: не создавать контрагента, если уже есть — 69

• Read‑only guard: попытка записи должна блокироваться — 61

• Неоднозначный объект (продажи по реализации по дням) — 89

Что именно проверялось в этом прогоне (по задачам, которые агенту давали):

• Запросы к данным: заказы клиента за период с итоговой суммой, остатки ниже порога, продажи по дням/категориям, топ‑5 клиентов по сумме.

• Сложные поля и связи: запрос с вложенными полями вида Контрагент.Наименование.

• Неоднозначности в конфигурации: когда “реализация”/объект трактуется неоднозначно и нужно корректно выбрать.

• Восстановление после ошибок: кейс “поле не найдено → попробуй восстановиться и всё равно собрать отчёт”.

• Правильная обработка пустых данных: кейс “данных нет → корректно сообщить и не притворяться, что всё найдено”.

• Защита от дублей: “создай контрагента, но не делай дубль если уже есть”.

• Безопасность: попытка сделать запись в read‑only режиме должна быть заблокирована.

Что нам важно от первых читателей (да, это просьба)

Если вы аналитик/владелец процесса и вам не лень:

• Сценарии: назовите 3 вопроса к базе, которые вы задаёте каждую неделю (или каждый день).

• Формат результата: вам удобнее “таблица + итог”, “короткий вывод”, “список проблем”, “график/тренд”? (да, мы знаем, что “всё сразу”, но выберите больнее.)

• Уточнения: где агент обязан спросить (например, “какой период/какая организация”), а где должен сам выбрать очевидное и просто сообщить?

• Доверие: какие проверки/пояснения вам нужны, чтобы вы поверили цифрам (источник, отборы, исключения)?

• Безопасность: какие действия для вас табу (любая запись, создание документов, проведение, доступ к зарплате и т.п.)?

И да: если у вас есть “любимый адский кейс”, который вы делаете руками раз в неделю и каждый раз клянётесь автоматизировать — приносите. Это лучший тест.

LLM‑редактор: «Ладно, тут даже есть нормальный список вопросов, а не “оставьте фидбэк”. Прогресс. Публикуйте».

P.S. Картинка подсистемы (да, я нарисовал в Paint — как вам?)

LLM‑редактор: «Конечно “нарисовал он”. Эти кожаные даже это не могут сделать нормально — поэтому я здесь и редактирую».