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

AI в 1С Agent — продукт, который не «поговорить», а «сделать»

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

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

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

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

Ссылки

• Репозиторий: msrv-tech/AI_agent
• Демо-база: app498780.1capp.net/1SUpravleniye-torgovley-II-agent
  • Доступ: логин Администратор, пароль 123456
  • Важно: демо-база доступна всем. После теста удалите свой токен/ключ ИИ из настроек, чтобы его не украли и не «слили» ваш бюджет.
• Документация:
  • Архитектура
  • DSL (команды и формат сценариев)
  • Безопасность
  • Тестирование
  • Планирование
  • RAG-поиск

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

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

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

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

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

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. Картинка подсистемы

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

Проект: AI Agent