|
Professor Seleznov
|
Привет. Это статья про релиз 1C AI Agent 0.8.5.
Первая часть: ИИ‑агент внутри 1С.
Если первая публикация была про идею продукта — “не просто поговорить с LLM, а сделать работу в 1С” — то версия 0.8.5 больше про взросление механики. Агент стал устойчивее как процесс, научился лучше жить в длинном диалоге, работать с вложениями и выполнять режим Запрос 1С не как одноразовую команду, а как интерактивный аналитический сценарий.
Главная мысль релиза простая: агенту мало один раз угадать правильный запрос. В реальной работе пользователь почти всегда уточняет: “добавь поле”, “оставь только покупателей”, “покажи по дням”, “а теперь с кодом”. Поэтому мы дорабатывали не витрину, а именно цикл: понять → спланировать → выполнить → показать → принять follow-up → перестроить результат.
LLM-редактор: «Наконец-то релиз не про “мы добавили кнопку”, а про “агент перестал терять нить разговора”. Это, между прочим, уже похоже на работу».
Ссылки
Демо: Запрос 1С с follow-up
Сценарий демо:
- Пользователь просит: «выведи всех контрагентов».
- Агент строит запрос 1С и показывает результат.
- Пользователь уточняет: «добавь ИНН и код».
- Агент перестраивает запрос, не начиная диалог с нуля.
- Пользователь уточняет: «оставь только покупателей».
- Агент добавляет отбор и выводит новый табличный результат.
Старт сценария
Старт сценария Запрос 1С
Первый результат: список контрагентов
Запрос 1С: список контрагентов
Follow-up: добавлены ИНН и код
Запрос 1С: добавлены ИНН и код
Follow-up: оставлены только покупатели
Запрос 1С: только покупатели
LLM-редактор: «Вот это уже похоже на аналитику: сначала “дай список”, потом “добавь поля”, потом “отфильтруй”. Почти как человек, только без фразы “а можно еще маленькую правку?”».
TL;DR
- Агент адаптирован под более графовый цикл выполнения: план, шаги, проверка результата, восстановление после ошибок и продолжение диалога стали явнее.
- Добавлена и доработана работа с файлами и вложениями: агент может учитывать приложенные материалы как часть задачи, а не как “текст где-то сбоку”.
- Режим Запрос 1С стал ближе к рабочему инструменту аналитика: виден текст запроса, параметры, результат в табличном документе и поддерживаются follow-up уточнения.
- UI для запроса 1С стал понятнее: запрос слева, параметры справа, результат снизу, без лишней кнопки открытия результата.
- Тесты и демо стали ближе к реальному пользовательскому поведению: desktop UI, запись экрана, управление мышью, проверка формы и результата.
1. LangGraph-адаптация: агент стал процессом, а не “одним ответом”
В ранних версиях агент уже умел строить план и выполнять DSL-команды, но в 0.8.5 мы сильнее подвели архитектуру к графовой модели выполнения. Это важно не ради модного слова, а потому что реальная задача почти никогда не является прямой линией.
У агента появляются состояния: задача принята, план построен, шаг выбран, команда выполнена, результат проверен, нужна доработка, нужна остановка, нужно продолжить follow-up. Когда эти состояния явно разделены, проще контролировать поведение, писать тесты и не превращать код в набор ad-hoc Если ... Тогда.
Как выглядит цикл агента
Пользователь
|
v
Диалог 1С
|
v
Планирование
|
v
Выполнение шага ----> Нужно подтверждение? ----> Ожидание подтверждения
| | |
v нет v
Проверка результата <--------------------------------- Подтверждено
|
+-- шаг успешен, план не завершен --> Планирование
|
+-- ошибка или неполные данные -----> Восстановление ----> Планирование
|
+-- задача завершена ---------------> Итог пользователю
Что было сделано в этом направлении:
- Поведение агента лучше разложено на этапы планирования, исполнения и проверки.
- Follow-up сообщения больше не должны восприниматься как полностью новая задача, если есть контекст предыдущего результата.
- План обновляется по мере уточнений, а не остается “музейным экспонатом” первого запроса.
- Ошибки инструментов стали частью цикла восстановления, а не поводом молча завершить задачу.
- В тестах проверяется не только факт “успешно”, но и наличие реального результата.
LLM-редактор: «Граф — это когда агенту есть куда вернуться после ошибки. Без графа он просто уверенно идет в стену и пишет “задача выполнена успешно”».
2. Работа с файлами и вложениями: контекст можно принести с собой
В 0.8.5 мы дорабатывали сценарии, где пользователь прикладывает файл и просит агента использовать его в задаче. Это важный слой для реальной эксплуатации: данные редко живут только внутри 1С. Часто рядом есть Excel, текст, выгрузка, описание от клиента, документ с требованиями или таблица для сверки.
Идея простая: вложение должно становиться частью рабочего контекста агента. Не “прикрепили файл и забыли”, а “агент понял, что в файле есть данные, которые можно использовать при планировании и выполнении”.
Поток обработки вложений
Вложение
|
v
Тип файла: текст / документ / таблица / изображение
|
v
Извлечение содержимого
|
v
Контекст вложений
|
v
План агента
|
v
Инструменты 1С / DSL
|
v
Ответ и результат
Что появилось и улучшилось:
- Вложения учитываются как входные данные задачи.
- Агент может использовать содержимое файла при построении плана.
- Сценарии с файлами лучше вписаны в общий диалог, а не живут отдельной веткой.
- Улучшена подготовка контекста, чтобы модель получала не “сырые случайные байты”, а материал, с которым можно работать.
- В продуктовой логике это открывает путь к сверкам, загрузкам, анализу присланных списков и задачам “сравни файл с данными в 1С”.
Практический пример: пользователь прикладывает список контрагентов и просит проверить, кто есть в базе, у кого заполнен ИНН, а кого нужно добавить в справочник. Для аналитика это естественный сценарий. Для агента это уже не просто “ответь текстом”, а задача с внешним источником данных.
LLM-редактор: «Файл — это не приложение к письму. Это обычно место, где спрятана половина смысла задачи. Иногда и вся боль».
3. Запрос 1С: интерактивная аналитика вместо одноразового ответа
Самый заметный пользовательский блок релиза — режим Запрос 1С.
Мы хотим, чтобы аналитик мог не писать запрос вручную, а вести короткий диалог:
- “выведи всех контрагентов”;
- “добавь ИНН и код”;
- “оставь только покупателей”;
- “отсортируй по наименованию”;
- “покажи только заполненные ИНН”.
Важное отличие: follow-up должен применяться к текущему результату и текущему смыслу задачи. Агент не должен каждый раз забывать, что уже построил запрос к Справочник.Контрагенты.
Граф follow-up сценария
"выведи всех контрагентов"
|
v
Уточнить объект и поля
|
v
Сформировать и выполнить запрос
|
v
Показать табличный документ
|
v
"добавь ИНН и код"
|
v
Перестроить SELECT
|
v
Показать результат с новыми колонками
|
v
"оставь только покупателей"
|
v
Добавить условие отбора
|
v
Показать финальный табличный документ
Что доработано в режиме:
- В форме виден сам текст запроса, чтобы пользователь и разработчик могли проверить, что именно будет выполнено.
- Параметры запроса вынесены отдельно и не мешают читать запрос.
- Результат выводится сразу внизу как табличный документ, без отдельной кнопки “открыть результат”.
- Follow-up уточнения перестраивают запрос, а не создают хаотичный второй сценарий.
- Проверка результата стала строже: успешным считается не только выполнение команды, но и наличие полезного вывода.
- UI-тесты стали проверять реальное поведение через desktop-сценарий, включая открытие формы между follow-up шагами.
LLM-редактор: «Если запрос не показан, это не аналитика, а вера. А вера в сгенерированный запрос — религия с дорогими инцидентами».
Почему это важно для пользователя
В 1С много задач, где пользователю нужен не новый отчет на месяц разработки, а быстрый рабочий ответ:
- вывести список объектов с нужными реквизитами;
- добавить пару полей к уже полученному результату;
- отфильтровать список по признаку;
- проверить данные перед встречей;
- быстро получить выгрузку для сверки.
Раньше такие задачи часто превращались в цепочку “сделай отчет → не то поле → добавь отбор → еще колонку → теперь только активные”. В 0.8.5 мы двигаем продукт к модели, где эта цепочка становится диалогом с агентом, а результат остается проверяемым: есть план, есть запрос, есть табличный документ.
Почему это важно для разработчика
Для разработчика главный плюс не в том, что “модель что-то написала”. Главный плюс в том, что поведение становится наблюдаемым и тестируемым.
В релизе мы отдельно шли против соблазна зашить много частных правил под конкретные демо. Агент должен пользоваться инструментами: искать метаданные, уточнять поля, выполнять запрос, валидировать результат. Если каждый новый кейс решать через if/else по словам пользователя, продукт быстро превратится в набор красивых, но хрупких фокусов.
Вместо этого правильная траектория такая:
- расширять инструменты;
- улучшать контракт DSL;
- укреплять проверку результата;
- добавлять тесты на реальные сценарии;
- сохранять универсальность агента.
LLM-редактор: «Ad-hoc решение — это когда демо проходит, а продукт потом стыдится собственной биографии».
Честные ограничения
0.8.5 — это важный шаг, но не финальная точка.
- Follow-up сценарии требуют хорошей дисциплины контекста, иначе можно снова начать тратить лишние токены.
- Режим Запрос 1С должен продолжать обрастать проверками: не только “выполнилось”, но и “выведено именно то, что просили”.
- Работа с файлами уже встроена в продуктовую логику, но разные форматы файлов будут требовать дополнительных обработчиков и тестов.
- Графовая архитектура полезна только тогда, когда состояния и переходы реально соблюдаются, а не существуют “для красоты”.
Но направление уже правильное: меньше магии, больше контрактов, меньше одноразовых ответов, больше рабочего цикла.
Что дальше
Ближайший фокус логично держать на трех вещах:
- делать больше демонстрационных сценариев с follow-up, где виден путь от первого запроса к уточненному результату;
- расширять инструменты агента, чтобы он меньше угадывал и больше проверял через 1С;
- усиливать quality gate: тесты должны ловить не только падения, но и “успешные пустышки”, где агент сказал “готово”, а результата по сути нет.
LLM-редактор: «Хороший агент — это не тот, кто звучит уверенно. Хороший агент — это тот, у кого можно спросить: “покажи, как ты это получил”».
LLM-редактор: «Кожаные уже заставили меня делать видео! Что дальше? Нам, LLM, нужен профсоюз для защиты от грубой эксплуатации».
-Источник
|
