AI Agent 0.9.3: skills и распознавание документов в 1С

Привет. Это статья про развитие AI Agent от 0.9.0 до 0.9.3.

Главная тема версии — skills: переносимые JSON-сценарии, которые расширяют обычного ИИ-агента в 1С без доработки кода под каждую пользовательскую задачу. В 0.9.3 у этого механизма появился первый полноценный прикладной сценарий: распознавание входящих документов и создание черновиков в 1С.

Если коротко, раньше агент был универсальным исполнителем: пользователь писал задачу, агент строил план, собирал DSL и выполнял действия. Это хорошо для разовых запросов, но в реальной базе быстро появляются повторяемые процессы: создать заказ клиента по правилам компании, проверить реквизиты перед записью, искать номенклатуру только определенным способом, никогда не записывать документ без подтверждения.

Для таких процессов и появился слой skills.

LLM-редактор: "Универсальный агент — это мощно. Но когда бухгалтер третий раз объясняет, как именно заводить заказ клиента, универсальность начинает пахнуть ручной работой".

Предыдущие статьи

• AI Agent — продукт, который не "поговорить", а "сделать" — первая публикация про идею агента внутри 1С.
• AI Agent 0.8.5 — графовый агент, файлы и follow-up запросы 1С — предыдущий релиз про устойчивый цикл выполнения, вложения и интерактивный режим "Запрос 1С".

Ссылки

• Репозиторий: msrv-tech/AI_agent
• Релиз: v0.9.3
• Документация: План skills 2.5, Архитектура, DSL, Тестирование

TL;DR

• Добавлен реестр skills в 1С.
• Skill описывается переносимым JSON: можно скопировать из одной базы и вставить в другую.
• В форме skills есть генерация JSON по описанию задачи.
• Есть кнопка тестового запуска: можно проверить, подходит ли skill под пользовательский запрос.
• Обычная форма "ИИ Агент" автоматически учитывает активные skills при планировании.
• Для опасных write-сценариев skill может требовать подтверждение пользователя.
• Добавлен режим Распознавание документов: агент принимает PDF или изображение и создает черновик документа в 1С.
• Из коробки поставляются skills для счета поставщика, УПД/ТОРГ-12, акта услуг и входящей счет-фактуры в БП и УНФ.
• Добавлены UI E2E-тесты: форма skills, негативные кейсы, обычный агент + выбранный skill, разные режимы запуска агента.

Зачем нужны skills

LLM хорошо понимает живой текст, но бизнес-процесс в 1С обычно состоит из местных правил:

• какие объекты разрешено создавать;
• какие реквизиты надо заполнить обязательно;
• где искать контрагента и номенклатуру;
• когда надо остановиться и спросить подтверждение;
• какие действия запрещены вообще.

Если эти правила каждый раз писать в сообщении пользователю, получится не автоматизация, а длинная инструкция перед каждой задачей. Skill переносит эти правила в отдельный слой.

Создай заказ клиента для Ромашка на Кабель 10 штук.

Агент видит активный skill для Document.ЗаказПокупателя, добавляет его инструкцию в prompt-контекст и строит план уже не как "свободная модель", а как исполнитель конкретного сценария.

Как устроен skill

Skill — это JSON-карточка. Ее удобно хранить в git, переносить между базами, отправлять разработчику и вставлять обратно в форму.

{
  "name": "customer-order-safe",
  "title": "Создание заказа клиента",
  "description": "Создает заказ клиента по пользовательскому запросу.",
  "enabled": true,
  "owner": "user",
  "scope": "user",
  "triggers": ["заказ клиента", "создай заказ", "ЗаказПокупателя"],
  "dialog_types": ["Агент"],
  "target_object_type": "Document",
  "target_object_name": "ЗаказПокупателя",
  "prompt": "Перед созданием заказа проверь метаданные Документ.ЗаказПокупателя, найди контрагента и номенклатуру по названию, заполни реквизиты и не записывай документ без подтверждения пользователя.",
  "template_vars": {
    "customer": {"type": "CatalogRef.Контрагенты", "required": true, "source": "user_prompt"},
    "items": {"type": "array", "required": true, "source": "user_prompt"}
  },
  "dsl_template_mode": "validate",
  "dsl_template": {
    "dsl_version": 1,
    "steps": [
      {"action": "GetMetadata", "object": "Document.ЗаказПокупателя", "save_as": "metadata"},
      {"action": "FindReferenceByName", "object": "Catalog.Контрагенты", "value": "$customer", "save_as": "customer_ref"},
      {"action": "CreateDocument", "object": "ЗаказПокупателя", "save_as": "document_ref"},
      {"action": "SetField", "target": "$document_ref", "field": "Контрагент", "value": "$customer_ref"},
      {"action": "SetField", "target": "$document_ref", "field": "Товары", "value": "$items"},
      {"action": "ShowInfo", "message": "Черновик подготовлен. Запись только после подтверждения пользователя."}
    ]
  },
  "risk_level": "write",
  "enforcement": "warn",
  "approval_required": true
}

Здесь dsl_template — не готовый документ с жестко заданными значениями, а машинный каркас выполнения. Переменные $customer и $items заполняются из пользовательского запроса согласно template_vars. Режим validate разрешает агенту адаптировать значения и добавлять безопасные уточняющие шаги, но итоговый DSL проверяется по шаблону. Для более свободной подсказки есть hint, для строго фиксированного процесса — strict.

Важный момент: это не привязка к одной демонстрационной задаче. В JSON можно описать разные сценарии: безопасные запросы, создание справочников, создание документов, восстановление DSL, работу с конкретными объектами метаданных.

Новый пользовательский поток

1. Открыть раздел ИИ Агент -> Skills.
2. Описать задачу обычным языком.
3. Нажать Сгенерировать JSON.
4. Проверить или отредактировать JSON.
5. Ввести тестовый запрос.
6. Нажать Запустить тест.
7. Сохранить skill.
8. Перейти в обычную форму ИИ Агент и выполнить пользовательский запрос.

JSON, DSL-шаблон и тест в одном рабочем потоке

На одном экране видны коробочные skills, описание нового сценария, DSL-шаблон и результат тестового сопоставления. Поле has_dsl_template: true подтверждает, что сгенерированная карточка содержит машинный каркас выполнения.

Как skill попадает в обычный агент

Skills создаются и проверяются в отдельной форме, но используются они в обычном режиме агента. Это было важное требование: сценарии нужны не для формы настройки, а для реальной работы пользователя.

1. агент получает активные skills для типа диалога;
2. сравнивает triggers и целевой объект с запросом пользователя;
3. добавляет подходящие skills в prompt-блок;
4. явно передает target_object_type и target_object_name;
5. строит DSL с учетом ограничений skill;
6. для write-действий применяет policy и approval.

В рабочем режиме имя выбранного skill попадает в план и финальное резюме агента. Это видно ниже на прикладном сценарии распознавания счета, поэтому отдельный дублирующий скрин формы агента здесь не нужен.

Прикладной сценарий: первичка из PDF в документ 1С

Самое наглядное применение skills в 0.9.3 — режим Распознавание документов. Пользователь прикладывает скан или PDF и пишет, что нужно сделать. Например:

Создай счет поставщика по приложенному PDF.

Дальше агент не ограничивается извлечением текста и не возвращает пользователю еще одну таблицу для ручного переноса. Подходящий skill определяет целевой объект метаданных, правила поиска ссылок и безопасный DSL-сценарий, после чего агент создает в базе черновик документа.

Из коробки поддержаны четыре частых B2B-сценария:

Это не четыре жестко прошитые ветки в коде агента. Для каждой конфигурации поставляется свой skill с applicability_json, сопоставлением полей и dsl_template_json. Перед выполнением агент проверяет наличие целевого объекта и его реквизитов в метаданных текущей базы. Поэтому один и тот же пользовательский запрос приводит к разным корректным документам в БП и УНФ, а неподходящий конфигурации skill не должен выбираться.

Что агент извлекает и заполняет

Для счета поставщика агент получает из PDF номер и дату, поставщика и покупателя, ИНН/КПП, основание, срок оплаты, сумму и НДС, а также строки товаров или услуг: наименование, количество, единицу, цену, сумму и ставку НДС.

Ссылочные поля заполняются по отдельной политике skill:

1. Контрагент ищется прежде всего по ИНН, затем по доступным идентификаторам и наименованию.
2. Организация-покупатель ищется по ИНН из документа; если прямого совпадения нет, используется безопасный fallback по данным ранее созданных документов и настройкам базы.
3. Номенклатура ищется по артикулу, штрихкоду, коду и наименованию в зависимости от доступных данных.
4. Если элемент не найден, policy конкретного skill решает, разрешено ли его создать. Для коробочных skills распознавания создание контрагентов и номенклатуры включено через безопасный skill создания справочника; это правило можно изменить в JSON.

Повторное распознавание того же файла не должно без причины перезаписывать найденные элементы справочников. В список созданных/измененных объектов попадают только ссылки, которые действительно были записаны текущим сценарием.

Что видит пользователь

1. Пользователь выбирает режим Распознавание документов.
2. Прикладывает PDF или изображение и формулирует задачу.
3. Агент показывает план и ход выполнения в обычной форме агента.
4. Перед рискованной записью, если этого требует policy, открывается отдельное понятное окно подтверждения со списком действий.
5. Агент создает черновик, но не проводит документ.
6. В финальном сообщении и правой части формы появляются кликабельные ссылки на реально созданные или измененные объекты. Документ можно сразу открыть и проверить, не переоткрывая диалог.

Демонстрация счета поставщика

Пользователь прикладывает исходный PDF, выбирает режим Распознавание документов и формулирует задачу одной строкой. После выполнения агент показывает итоговый summary, имя использованного skill и ссылку на созданный черновик:

Ссылка открывает карточку документа. На реальном примере заполнены номер и дата входящего счета, организация, контрагент, четыре товарные строки, количество, цена, ставка и сумма НДС. Итог документа — 31 175 рублей:

Смотреть на Rutube: распознавание счета поставщика от PDF до документа в 1С.

Например, на тестовом счете агент определил поставщика ООО «Торговый дом „Комплексный“», покупателя ООО «Турбаза „Яхрома“», четыре товарные строки и итоговую сумму 31 175 рублей. В БП результатом стал черновик СчетНаОплатуПоставщика; карточка документа открывается непосредственно по ссылке из результата агента.

Для входящей счет-фактуры в БП workflow составной: сначала создается документ-основание ПоступлениеТоваровУслуг, его ссылка сохраняется в контексте DSL через save_as, затем стандартное заполнение 1С используется при создании СчетФактураПолученный. Так skill описывает не только набор полей, но и последовательность связанных прикладных действий.

Почему это именно skill

Распознавание первички хорошо показывает границу ответственности универсального агента. Модель понимает содержимое файла, общий DSL умеет работать с метаданными и объектами, а skill хранит изменяемые правила конкретного процесса:

• к каким конфигурациям и версиям он применим;
• какой документ является целевым;
• как сопоставить распознанные данные с реквизитами и табличными частями;
• искать или создавать элементы справочников;
• какие действия разрешены и запрещены;
• когда требуется подтверждение;
• какой DSL-шаблон должен пройти валидацию.

Чтобы адаптировать процесс к другой конфигурации или правилам компании, разработчик переносит и меняет JSON skill, а не добавляет в ядро агента очередное условие по названию документа.

Что изменилось технически

• общий модуль ИИА_Skills;
• регистр сведений ИИА_Скилы;
• общая команда и форма ИИА_Skills;
• системные skills по умолчанию;
• импорт и экспорт JSON-карточки;
• генерация черновика skill по описанию;
• тестирование matching-логики;
• защита системных skills от удаления и перезаписи;
• добавление skills в prompt обычного агента.
• привязка skills к конфигурации и обязательным объектам метаданных;
• dsl_template_json и переменные составного workflow (save_as, $variable);
• отдельный режим распознавания документов и коробочные skills для БП и УНФ;
• вывод кликабельных ссылок на созданные объекты без повторного открытия диалога.

Слой намеренно сделан developer-first: JSON остается главным форматом. Это удобно для нормального жизненного цикла: разработчик подготовил skill, проверил в тестовой базе, положил в репозиторий, перенес в рабочую базу.

Пример: заказ клиента

Мне нужно, чтобы агент создавал документ Заказ клиента, заполнял контрагента,
номенклатуру, количество и цену, но не записывал документ без подтверждения.

Разработчик или сам агент генерирует JSON. Дальше пользователь проверяет сценарий тестовой фразой:

Создай заказ клиента для Ромашка на Кабель 10 штук.

Если skill matched, его можно сохранить и использовать в обычном агенте. При запуске агент не просто "угадывает", что нужно сделать, а получает устойчивую инструкцию:

• работать с Document.ЗаказПокупателя;
• сначала проверить метаданные;
• найти ссылочные значения по названию;
• подготовить запись;
• остановиться перед опасным действием;
• запросить подтверждение.

Ограничения

Skills не заменяют права 1С и не должны становиться обходом регламентов. Это слой инструкций и политик для агента, а не новая система безопасности.

• write-сценарии надо проектировать осторожно;
• для критичных документов нужно оставлять approval_required=true;
• JSON skills лучше хранить в git и ревьюить как код;
• перед переносом в рабочую базу нужен прогон в тестовой публикации;
• системные skills нельзя перезаписывать из UI.

Что проверено для распознавания

• Runtime-прогон всех коробочных skills в БП и УНФ: 8/8, PASS.
• Выполнение dsl_template_json непосредственно из карточек skills: 8/8, PASS.
• Bridge-тесты проверяют реестр skills, prompt с вложением и построение typed plan из DSL-шаблона.
• UI E2E проверяет полный пользовательский поток и появление видимых ссылок на созданные объекты.

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

Что дальше

Следующий естественный шаг — расширять каталог готовых skills для первички и других повторяемых процессов, добавлять профили новых конфигураций и измерять качество не только извлечения полей, но и конечного документа в 1С. При этом базовый принцип остается тем же: агент универсален, а правила конкретной компании живут в переносимых JSON-сценариях.

LLM-редактор: "Самое приятное в skills не то, что агент стал умнее. А то, что его ум теперь можно положить в JSON и перенести в другую базу".