ИИ-агенты в 1С: что это такое на самом деле и как их строить без магии | infolimp.ru

ИИ-агенты в 1С: что это такое на самом деле и как их строить без магии

6 июля 2026 · infolimp.ru

Термин «ИИ-агент» ворвался в экосистему 1С с шумом, но за ним чаще всего скрывается либо обычный чат-бот с GPT-обёрткой, либо «умный помощник», который на самом деле — просто набор правил Если-Тогда. Здесь мы разберём, что такое ИИ-агент с точки зрения архитектуры 1С, где проходит граница между «магией» и инженерным решением, и как построить агента, который действительно принимает решения, а не просто подставляет шаблон.

ИИ-агент vs. «Умный помощник»: где проходит граница?

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

В экосистеме 1С ключевая ловушка — путаница между автоматизацией по жёсткому сценарию и агентным поведением. Первое — это регламентное задание, которое в 3 часа ночи проводит документы. Второе — это сущность, которая сама решает, какие документы провести, а какие отправить на перепроверку, исходя из контекста.

Ключевой тезис: ИИ-агент в 1С — это не нейросеть внутри платформы. Это архитектурный паттерн, где «мозг» (внешний LLM или модель машинного обучения) управляет «телом» (объектами 1С) через чётко определённый протокол. Без этого протокола вы получите просто дорогой скрипт.

Архитектура агента: три слоя, которые нельзя смешивать

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

Слой 1: Восприятие (Perception)

Этот слой отвечает за сбор данных из системы. В 1С это может быть:

Главная ошибка — пытаться «скормить» агенту сырые данные в виде таблицы значений. Агент должен получать контекст, а не дамп. Например, вместо передачи всей табличной части документа «РеализацияТоваровУслуг» передавайте структуру: {"Товары": [{"Номенклатура": "Ноутбук", "Количество": 5, "Сумма": 600000}], "Контрагент": "ООО Ромашка", "Скидка": 10}.

Слой 2: Принятие решений (Decision)

Здесь и начинается самое интересное. В 1С нет встроенных нейросетей, и это нормально. Решение может приниматься тремя способами:

МетодКогда использоватьПример в 1С
Жёсткие правила (Если-Тогда)Чёткие границы, регуляторикаПроверка лимитов кредита контрагента
Дерево решений / СкорингМного факторов, но данные структурированыОценка вероятности просрочки платежа
Внешний LLM (через HTTP-сервис)Неструктурированный ввод, генерация текстаАвтоматическое описание проводок по первичке

Главная нетривиальная ловушка — попытка использовать LLM для задач, которые решаются скорингом. LLM даёт красивый ответ, но он недетерминирован и дорог. Агент должен сам выбирать, какой «мозг» использовать для каждой задачи.

Слой 3: Действие (Action)

Это самый простой слой — выполнение команд в 1С. Но здесь кроется вторая ловушка: агент не должен иметь прямого доступа к объектам метаданных. Взаимодействие должно идти через командный интерфейс — набор разрешённых операций, которые агент может вызвать.

Предупреждение: Никогда не давайте агенту возможность выполнять произвольный код через Выполнить(). Это путь к катастрофе. Агент должен работать только через предопределённые команды, как пользователь через интерфейс.

Как построить агента без магии: архитектура на HTTP-сервисах

Рассмотрим реальную архитектуру, которую можно внедрить в типовую конфигурацию начиная с платформы 8.3.10 (HTTP-сервисы). Агент состоит из трёх частей:

  1. Сборщик контекста — обработка, которая по запросу формирует JSON с текущим состоянием системы.
  2. Решатель — внешний сервис (может быть написан на Python, C# или даже на 1С через механизм правил), который возвращает команду.
  3. Исполнитель — HTTP-сервис в 1С, который принимает команду и выполняет её.

Пример: агент контроля дебиторской задолженности

Допустим, мы хотим, чтобы агент сам решал, блокировать ли отгрузку контрагенту с просрочкой. Вместо того чтобы писать 50 условий в модуле менеджера, мы строим агента.

// Сборщик контекста (вызывается решателем)
Функция СобратьКонтекстПоКонтрагенту(ИдКонтрагента) Экспорт
    Контекст = Новый Структура;
    Контекст.Вставить("Контрагент", Справочники.Контрагенты.НайтиПоКоду(ИдКонтрагента).Наименование);
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ
    |   СуммаВзаиморасчетов.СуммаОстаток КАК Долг,
    |   СуммаВзаиморасчетов.СрокПросрочки КАК ДнейПросрочки
    |ИЗ
    |   РегистрНакопления.СуммаВзаиморасчетов.Остатки() КАК СуммаВзаиморасчетов
    |ГДЕ
    |   СуммаВзаиморасчетов.Контрагент = &Контрагент";
    Запрос.УстановитьПараметр("Контрагент", Справочники.Контрагенты.НайтиПоКоду(ИдКонтрагента));
    Результат = Запрос.Выполнить().Выгрузить();
    
    Если Результат.Количество() > 0 Тогда
        Контекст.Вставить("Долг", Результат[0].Долг);
        Контекст.Вставить("ДнейПросрочки", Результат[0].ДнейПросрочки);
    Иначе
        Контекст.Вставить("Долг", 0);
        Контекст.Вставить("ДнейПросрочки", 0);
    КонецЕсли;
    
    Возврат Контекст;
КонецФункции

Решатель (внешний микросервис на Python) получает этот JSON и возвращает команду:

{
  "action": "block_shipment",
  "reason": "Просрочка более 30 дней, сумма долга превышает 50% лимита",
  "confidence": 0.92
}

Исполнитель в 1С принимает команду и выполняет:

// HTTP-сервис: POST /api/agent/execute
Функция ВыполнитьКоманду(Команда, Контекст) Экспорт
    Если Команда.action = "block_shipment" Тогда
        // Создаём задачу на блокировку
        Задача = Справочники.ЗадачиОбработки.СоздатьЭлемент();
        Задача.Наименование = "Блокировка отгрузки: " + Контекст.Контрагент;
        Задача.Дата = ТекущаяДата();
        Задача.Комментарий = Команда.reason;
        Задача.Записать();
        
        // Отправляем уведомление менеджеру
        Уведомление = Новый ИнтернетПочтовоеСообщение;
        Уведомление.Тема = "Требуется решение по отгрузке";
        Уведомление.Текст = "Контрагент " + Контекст.Контрагент + " заблокирован агентом. Причина: " + Команда.reason;
        // ... отправка через ИнтернетПочтовыйПрофиль
    КонецЕсли;
КонецФункции
Ключевой тезис: Агент не должен писать документы напрямую. Он создаёт задачи для людей или выполняет только те действия, которые явно разрешены в конфигураторе. Иначе вы получите «чёрный ящик», который наделает долгов.

Типичные ошибки при внедрении ИИ-агентов

На основе опыта внедрений в нескольких крупных проектах (от 500 до 5000 пользователей) выделим три главные ошибки:

Ошибка 1: Агент как замена бухгалтеру

Самая частая — пытаться заставить агента делать всё: от ввода первички до закрытия месяца. Агент должен быть ассистентом, а не заменой. Он готовит данные, подсвечивает аномалии, но финальное решение всегда за человеком. Иначе при первой же ошибке (а она будет) доверие к системе рухнет.

Ошибка 2: Отсутствие логирования решений

Агент принял неверное решение? Без полного лога контекста и цепочки рассуждений вы не сможете понять, почему. Обязательно логируйте:

Ошибка 3: Игнорирование обратной связи

Агент без обучения — это просто дорогой скрипт. Даже простая система «палец вверх/палец вниз» после каждого действия агента позволяет накопить статистику и со временем улучшать решатель. В 1С это можно реализовать через регистр сведений:

// Регистр сведений: ОбратнаяСвязьАгента
// Измерения: ДатаСобытия, ИдСессииАгента
// Ресурсы: Контекст (ХранилищеЗначения),

Расширение «НОПик» для 1С — встраиваемый коннектор к внешнему AI с интеллектуальным поиском по базе. Задавайте вопросы обычными словами - AI сам найдёт нужное. 45 дней бесплатно.

Попробовать НОПик →