Крутое пике. Сериал про RPA. Сезон 1, эпизод 2 (LangGraph в 1С: два свидетеля для агента)

Для кого: разработчики 1С и авторы агентов, которым нужно проверять ответы по коду и данным.

Это второе дело сериала «Крутое пике» (эпизод 1, пролог). Граф продолжает архитектуру из статьи 1. Для чтения этого эпизода достаточно исходной жалобы; устройство предыдущего графа разберём после показаний свидетелей.

ЛИСТ 0106:32 UTC. Поставка, которой нет

Четверг, 1 октября 2026 года. Прошло полторы недели после дела о пропавшем токене.

После дела №1 в оркестраторе RB-PROD-04 кое-что поменялось. Ретроспектива записала: «В один день два вердикта по похожим симптомам оказались противоположными. Одного проверяющего мало». Теперь на каждую жалобу робот вызывает двух свидетелей:

• Знаток - текстовый сервис nopikreport.com/api/ask. Он отвечает по руководству, базе знаний и коду расширения.
• Очевидец - тот же API, но со скриншотом формы. Отвечает зрительный конвейер (tier: 2, source: vision-l0).

Результаты получает Супервайзер, узел с правилами выбора следующей проверки.

В 06:40 робот снял два скриншота под профилем «Кладовщик FBS»: меню «Поставка» в АРМ кладовщика и настройку генерации документов FBS. Оба снимка ушли Очевидцу. Жалоба Лены и вопрос о кнопке ушли Знатоку.

Снимок из демонстрационной базы: «Управление торговлей 11», расширение «УправлениеОнлайнТорговлей» 1.7.6.276, «Онлайн торговля» → «Сбор, маркировка и доставка заказов клиентов сервисов». Команда называется «Создать поставку в сервисе».

ЛИСТ 02Показания свидетелей

Знаток: «сбой обмена» и «кнопка сработает и без флага»

На жалобу Лены Знаток ответил через 31,7 секунды длинной лекцией: сбой при отправке запроса к API Wildberries, недействительный API-ключ, перегрузка API, ошибка фонового задания. Совет - проверить журнал регистрации и обновить ключ. О настройках поставки ни слова.

Второй вопрос робот задал прицельно: «Создаёт ли кнопка „Создать поставку в сервисе“ поставку в личном кабинете, если в настройке генерации документов не установлен флаг „Создавать поставку в сервисе“?» Ответ пришёл за 14,6 секунды:

1
2
3
4
5
6

{
  "answer": "Да, кнопка «Создать поставку в сервисе» в АРМ кладовщика **создаст поставку в личном кабинете Wildberries**, даже если в настройке генерации документов не установлен флаг… Кнопка же является **прямой командой пользователя**… Она игнорирует настройку автоматического создания…",
  "sources": ["База знаний 1С:Предприятие (общие знания)"],
  "tier": 1,
  "source": "vertex"
}

Реальный ответ, сокращён: evidence/api/ch2-04-button-title.json.

Уверенно, логично, с объяснением «почему». И один-единственный источник - «общие знания». Ни руководства, ни кода.

Очевидец: видит верно, объясняет как придётся

Со снимком настройки генерации документов Очевидец справился почти безупречно (27,3 с):

Снимок из демонстрационной базы (форма открыта без записи). Флаг «Использовать поставку в сервис» включён, «Создавать поставку в сервисе» выключен.

Дальше он перечислил состояние каждого флага. Все пять переключателей он прочитал верно, затем добавил шестой, которого в форме нет. Это поясняющая надпись под последним переключателем. В метаданных формы она оказалась подсказкой (ToolTip с отображением ShowBottom) у переключателя «Создавать отгрузку при закрытии поставки».

Со снимком меню АРМ вышло интереснее (27,2 с):

Вывод совпал с верным, а основание выдумано. Надпись о версии для разработчиков - это полоса платформы в демобазе, к созданию поставок она отношения не имеет.

Сводка

Все четыре ответа: evidence/api/ch2-03, ch2-04, ch2-10, ch2-11.

Знаток и Очевидец предлагают разные сценарии. В одном надо срочно проверять токены и сеть; для дела №1 такая проверка была бы уместна. В другом достаточно включить флаг. Лена ждёт, до отгрузки четыре часа.

ЛИСТ 03Улика №1. Почему свидетели путаются

Прежде чем судить, Супервайзер должен понимать, чего стоят показания. Робот устроил свидетелям перекрёстный допрос: одни и те же вопросы через API, на сайте и из 1С, несколько раз подряд. Все замеры сделаны вечером 25 сентября, запросы к API - с 19:52 до 20:40 UTC.

Один вопрос - три канала - три версии. Вопрос Лены «почему нет штрихкода поставки и самой поставки в ЛК» дал:

• через API - лекцию про сбой обмена (источник №1 - «общие знания»); пять ответов с 20:22 до 20:40 - одна и та же версия;
• на сайте - ту же лекцию («Проблемы с обменом данными…», «Некорректный токен/ключ API»);
• в 1С - третью версию.

NOPik 1.0.6.1 в демонстрационной базе. Про штрихкод - честное «информации в руководстве недостаточно». Про ЛК - «после закрытия поставка перестаёт отображаться как текущая». Это верная цитата раздела 8.15 руководства, но объясняет она совсем другое.

В этих ответах ни один канал не назвал флаг. Почему API, сайт и клиент 1С дали разные объяснения, по сохранённым ответам установить нельзя: конфигурации RAG, версии модели и полный контекст запросов мы не сравнивали. Разный контекст или конвейер могли бы влиять на ответ, но конкретную причину здесь не заявляем. Указанные в sources документы помогают проверять ответ; они не раскрывают устройство всей системы.

Прицельный вопрос - и снова разные ответы. Вопрос о кнопке и флаге на сайте получил правильный ответ со ссылкой на руководство и на модуль АРМ кладовщика: без флага поставка ведётся «Офлайн», документ создаётся только в 1С.

AI-помощник на сайте. Источники - CG_Online_АРМКладовщика/…/Module.bsl и руководство. Ответ противоположен ответу API из показаний Знатока.

Через API этот вопрос прозвучал пять раз. Ответ «Да, создаст» со ссылкой на «общие знания» пришёл один раз, в 20:22. В остальных ответах «Да» не было; три сохранённых ответа верны и ссылаются на руководство. Робот получил ошибочную выдачу. По одному ответу нельзя судить, как часто она встречается.

На снимке настройки Очевидец прочитал нужный флаг верно во всех шести ответах. Его объяснения менялись: «версия для разработчиков», статья о FBS, незаполненная авторизация. При этом трижды появился лишний переключатель, а один раз пропал пятый. Проверяем чтение формы по её метаданным; объяснение модели сохраняем как версию.

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

Робот вывел из допроса правила:

1. Проверяйте, откуда взят ответ. Уверенное объяснение из «общих знаний» ещё нужно сверить с руководством или кодом расширения.
2. Проверяйте действие кнопки по её обработчику. В коде можно найти настройку, от которой зависит отправка запроса. Пять прогонов показывают этот способ проверки на одном примере; по ним нельзя оценить точность сервиса на других задачах.
3. Отдельно проверяйте чтение экрана и объяснение. В этих ответах ИИ верно прочитал выключенный флаг, но по-разному объяснил, почему поставка не появится в Wildberries.
4. Ищите подтверждение в другом источнике. Если оба ответа пересказывают одну статью базы знаний, их совпадение не подтверждает правильность этой статьи. Сверка с кодом добавляет проверку, которой повторный вопрос сервису не даёт.

Значит, нужен свидетель с другим источником знания. У робота он есть: код расширения лежит в выгрузке, руководство - в тексте. Читать их - работа Аналитика метаданных.

ЛИСТ 04Расследование. Роли и граф

Кто есть кто

Названия относятся к узлам графа. В этом прототипе два узла вызывают сервис, остальные исполняют Python-код.

«Аналитик метаданных» из дорожной карты здесь сокращён до «Аналитика». ReAct обозначает форму его трассы «мысль → инструмент → наблюдение». ToT обозначает сравнение нескольких ветвей у Супервайзера. Их политика в этом прототипе задана кодом; самостоятельное планирование этих узлов языковой моделью остаётся вариантом дальнейшей разработки.

Граф

В графе свидетели запускаются параллельно; Супервайзер ждёт обоих. Список показаний складывается редьюсером operator.add. После поиска Аналитика маршрут пересчитывается; после ответа Сборщика СКД дело доходит до гейта. Полный фрагмент сборки и ограничения цикла приведены в техприложении.

Правило маршрута: спор свидетелей либо лучшая оценка ниже 1,5 вызывают Аналитика, если он ещё не работал. Затем незакрытый запрос к данным вызывает Сборщика СКД. В остальных случаях вызывается гейт, который может вернуть NeedsHuman. Попадание в гейт само по себе не означает, что улик достаточно.

Как это связано с графом из статьи 1? Узел plan_executor там исполнял план из одного шага. Здесь на его месте целый подграф. Снаружи контракт тот же: на входе вопрос и TraceID, на выходе ответ для доставки в 1С.

ЛИСТ 05Улика №2. Аналитик: ReAct по коду

Свидетели спорят о кнопке. Аналитик проходит её путь в коде: где задаётся надпись, где проверяется флаг, где выполняется запрос к WB. Затем сверяет режим с руководством и ищет, какую запись оставила бы ошибка обмена. Переход от картинки к коду нужен потому, что снимок показывает состояние формы, а код определяет действие.

В сохранённой трассе эти шаги записаны как T (заданный шаг сценария), A (вызов инструмента) и O (найденный фрагмент). Полная трасса оставлена в техприложении. Ниже разберём условия, от которых зависит результат.

Надпись, которая ничего не обещает

Заголовок команды задаётся программно, в процедуре управления видимостью. Ветки две - с ордерными складами и без них. Надпись одна и та же:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// Обработка CG_Online_АРМКладовщика, форма ФормаОсновная, процедура УправлениеВидимостью (фрагмент)
Если CG_Online_ВзаимодействиеСКонфигурацией.ИспользоватьОрдерныеСклады() И ИспользоватьТоварныеОрдера Тогда
    Элементы.СоздатьРТО.Видимость = Истина;
    Элементы.СоздатьОтборРазмещениеТоваров.Видимость = Истина;
    Элементы.ДобавитьЗаказыВОтгрузку.Видимость = Ложь;
    Элементы.СоздатьПоставку.Заголовок = "Создать поставку в сервисе";
    // ...
Иначе
    ИспользоватьРТО = Ложь;
    Элементы.СоздатьРТО.Видимость = Ложь;
    Элементы.СоздатьОтборРазмещениеТоваров.Видимость = Ложь;
    Элементы.ДобавитьЗаказыВОтгрузку.Видимость = Истина;
    Элементы.ДокументыОтборРазмещениеТоваров.Видимость = Ложь;
    Элементы.ДобавитьРТОВПоставку.Заголовок = "Добавить заказы в поставку";
    Элементы.СоздатьПоставку.Заголовок = "Создать поставку в сервисе";
    // ...
КонецЕсли;

Флаг «Создавать поставку в сервисе» здесь не участвует: кнопка всегда говорит «в сервисе». Обратите внимание и на соседние строки. Видимость «Создать РТО» и «Добавить заказы в отгрузку» зависит от ордерных складов, а видимость самой команды «Создать поставку в сервисе» здесь не меняется. Робот, который сверяет форму с контрактом из дела №1, обязан знать обе ветки. Иначе кнопка, скрытая по бизнес-логике, превратится в ложную тревогу.

Условие, которое решает всё

1
2
3
4
5
6
7
8

// Та же форма, процедура СоздатьПоставкуНаСервере (фрагмент)
Если НастройкаГенерацииДокументов.СоздаватьПоставкуВСервисе
    И ПустаяСтрока(ИДПоставки) Тогда
    Результат = CG_Online_ИнтеграцииССервисамиСервер.СоздатьПоставкуТоваровВСервис(
        ПараметрыУчетнаяЗапись);
    // ...
КонецЕсли;
// дальше документ «Поставка товаров в сервис» создаётся или обновляется в 1С - при любом значении флага

Первый фрагмент разделяет два результата: документ появляется в 1С при любом значении флага, а вызов создания поставки в сервисе требует установленного флага и пустого ИДПоставки. Если ID уже есть, именно эта ветка нового вызова создания не делает.

Коннектор WB проверяет флаг и перед добавлением заказов в поставку:

1
2
3
4
5
6
7
8

// Обработка CG_Online_WB_ИнтеграцияСВайлдберриз, функция ДобавитьЗаказыВПоставкуТоваровВСервис (фрагмент)
Если НастройкаГенерацииДокументов.СоздаватьПоставкуВСервисе Тогда
    Для Каждого Заказ Из Заказы Цикл
        Коннектор = CG_Online_ИнтеграцииССервисамиСервер.НастройкиПодключенияAPI(
            НастройкаАвторизации, "api/v3/supplies/" + ИДПоставки +
            "/orders/" + Заказ, "Wildberries_" + НастройкаАвторизации + "_Поставка");
        // ...
        Ответ = CG_Online_ИнтеграцииССервисамиСервер.HTTPЗапрос(Коннектор, "PATCH");

Во втором фрагменте PATCH …/orders/… находится внутри проверки флага. При снятом флаге цикл добавления заказов в поставку WB пропускается.

Та же проверка есть при закрытии поставки:

1
2
3
4
5
6
7
8

// Та же обработка, функция ЗакрытьПоставкуТоваровВСервис (фрагмент)
Если  НастройкаГенерацииДокументов.СоздаватьПоставкуВСервисе Тогда
    // ... PATCH api/v3/supplies/<ИДПоставки>/deliver
КонецЕсли;

Если Результат.Статус <> "Ошибка" Тогда
    Результат.Статус = "Выполнено";
КонецЕсли;

Без флага коннектор не отправляет в Wildberries ни создания поставки, ни добавления заказов, ни закрытия. При этом он возвращает «Выполнено». АРМ считает закрытие успешным и продолжает: запрашивает маркировку заказов и, если это настроено, создаёт отгрузку. Штрихкод поставки ЗакрытьПоставкуНаСервере запрашивает только при установленном флаге. Ошибок нет, потому что ничего не упало.

«Офлайн» здесь - термин режима расширения: поставка ведётся как документ 1С без показанных вызовов создания и закрытия поставки WB. Он не означает отсутствие интернета и не запрещает остальные запросы расширения, в том числе запрос маркировки. Руководство описывает этот режим в разделе 8.15. Офлайн-повтор из файла-компаньона - другое: воспроизведение сохранённой трассы вообще без сетевых вызовов.

Цепочка до стикеров

Заказы не были добавлены в поставку WB: запросов PATCH …/orders/… не было. Стикеры расширение запрашивает в двух местах.

• При закрытии поставки АРМ вызывает маркировку для заказов без стикеров, и флаг здесь не проверяется. Коннектор отправляет api/v3/orders/stickers. Если стикеров в ответе нет, процедура ЗагрузитьМаркировкуИзСервиса молча выходит. Ответ WB с кодом, отличным от 2xx, HTTPЗапрос записывает в журнал обмена, но пользователю ничего не показывается.
• Автоматическая маркировка при загрузке заказов отбирает только заказы в определённых статусах:

1
2
3
4
5
6

// Общий модуль CG_Online_ВзаимодействиеСКонфигурацией_УТ_11, функция АвтоматическаяМаркировкаПриЗагрузке (фрагмент)
ИначеЕсли НастройкаАвторизации.Сервис = ПредопределенноеЗначение("Перечисление.CG_Online_Сервисы.Wildberries") Тогда
    МассивСтатусов.Добавить("confirm");
    МассивСтатусов.Добавить("complete");
    МассивСтатусов.Добавить("delivering");
    РасширениеФайла = "svg";

Здесь перечислены условия отбора в расширении 1.7.6.276. Для заказа new автоматическая маркировка при загрузке не выполняется. При закрытии документа запрос стикеров может уйти независимо от флага; его ответ нужно смотреть отдельно.

В официальной документации FBS Wildberries метод POST /api/v3/orders/stickers описан для сборочных заданий в статусах confirm и complete. Проверка документации при редактуре - 10.10.2026; это дополнение к историческим прогонам. delivering в показанном коде - условие расширения, его нельзя автоматически приписывать этому API-методу.

Почему Аналитик читает код сам

Ссылка на модуль в sources помогает найти первоисточник, но условие всё равно нужно прочитать. Ответ ch2-18 верно заметил постоянную надпись, а затем приписал соседнему условию изменение видимости самой команды. В показанном фрагменте такого присваивания нет.

В ответе ch2-17 две настоящие строки были перенесены в чужой контекст:

Для вывода о закрытии нужна именно функция закрытия с её условиями. Подлинная строка из соседней ветки не заменяет такой проверки.

Как Аналитик проверил версию Знатока

С точки зрения метода особенно важен шаг T5. Аналитик проверяет версию Знатока вопросом: что оставила бы после себя эта версия? Если бы запрос к Wildberries упал, коннектор записал бы в журнал обмена «Ошибка при закрытии поставки Wildberries» (ЗаписьВЛог). Значит, H1 можно проверить по журналу обмена.

Но журнал - это данные информационной базы, а их Аналитик не видит.

ЛИСТ 06Улика №3. Супервайзер: дерево гипотез

Прототип хранит четыре заранее заданные версии. Они перечисляют возможные места сбоя, а не результат самостоятельного поиска модели.

В прототипе H3 и H4 не получили поддерживающих улик. Нулевой балл означает отсутствие поддержки в этом расчёте; их отдельную проверку он не выполнил.

H5 - «версия для разработчиков» появилась только из объяснения Очевидца. Она записана в исторической трассе, получила 0,2 за рассуждение по снимку и не прошла отсечение 0,3. Признаков такой редакции в материалах дела нет. Сохранение H5 в журнале показывает происхождение ошибочной версии и не придаёт ей достоверности.

Вес показания определяет источник

Веса и пороги заданы вручную для демонстрации маршрута. Баллы не являются вероятностями. Два фрагмента одного расширения могут поддержать H2 дважды; сумма не доказывает независимость этих источников и не измеряет надёжность решения.

Главное в этой таблице - разделение восприятия и рассуждения у Очевидца. Улика №1 показала, почему: восприятие верно шесть раз из шести, а рассуждения меняются от ответа к ответу.

Второй механизм - дискредитация. Если Аналитик находит в коде факт, который выбивает основание показания, это показание перестаёт учитываться. Знаток говорил: «кнопка - прямая команда, она игнорирует флаг». Код показал, что надпись на кнопке всегда одна и та же, а обращение к сервису зависит от флага. Показание снимается.

Что означают пороги

В коде PRUNE_BELOW = 0.3, VERDICT_MIN = 1.5, VERDICT_MARGIN = 1.0; сохраняются до двух ветвей. Эти значения не подобраны по выборке размеченных инцидентов. На показанном примере одиночного ответа RAG (0,3) и чтения флага (0,6) мало для вердикта. Поиск по коду и руководству поднимает H2 выше порога.

Это разбор условий кода, а не новые прогоны. Изменение порога отсечения влияет на состав двух ветвей, отмеченных beam, но само по себе не вызывает дополнительные проверки H3/H4: маршрутом управляют отдельные условия. Для рабочего применения веса и пороги потребовали бы калибровки по размеченным случаям.

Прогон

Показания утреннего допроса Супервайзер оценил так (это реальные ответы 25.09 в 20:22 UTC, приведённые выше):

раунд 1 H2   0.5 beam   Поставка создана офлайн: снят флаг   −0.1 Знаток/general +0.6 Очевидец/vision_perception
раунд 1 H1   0.3 beam   Сбой обмена с WB (API, токен, сеть)   +0.3 Знаток/rag
раунд 1 H5   0.2 pruned Ограничение версии для разработчиков  +0.2 Очевидец/vision_reasoning
раунд 1 H3   0.0 pruned Регрессия формы АРМ после обновления
раунд 1 H4   0.0 pruned Не хватает прав пользователя
раунд 1 → analyst
раунд 2 H2   3.4 beam   Поставка создана офлайн: снят флаг   +0.6 Очевидец/vision_perception +1.0 Аналитик/code +0.8 Аналитик/manual +1.0 Аналитик/code
раунд 2 H1   0.3 beam   Сбой обмена с WB (API, токен, сеть)   +0.3 Знаток/rag
раунд 2 → skd_collector
раунд 3 (Сборщик СКД: данных нет - оценки не изменились) → gate
Вердикт: H2, 3.4 | второе место: H1 (0.3) | класс: Configuration
Открытый вопрос: журнал обмена по настройке авторизации WB и история изменения
  настройки генерации документов FBS за 48 часов - нет канала к данным информационной базы

Вывод tools/two_witnesses.py на записанных ответах 20:22; строки с нулевыми ветвями в раундах 2–3 опущены.

Что стоит заметить:

1. После первого раунда вердикта нет. H2 впереди (0,5 против 0,3), но гейт требует не меньше 1,5 балла и отрыва в 1,0. Показаний двух свидетелей для решения не хватает, и это правильно.
2. Спор направляет расследование к Аналитику. Два свидетеля, пересказывающие одну статью, могут дать уверенный неверный ответ.
3. Луч шириной 2. H1 сильно отстаёт, но не отсечена. У неё есть проверяемое следствие - запись в журнале обмена. Отсекать ветку, которую можно дёшево проверить, неразумно, поэтому Супервайзер отправил запрос Сборщику СКД.
4. Ответ «данных нет» - тоже результат. Третий раунд ничего не изменил, но гейт вынес вердикт с явной пометкой: версия H1 не проверена, и вот какой запрос для этого нужен.

ЛИСТ 07Улика №4. Что показали живые прогоны

Пять живых прогонов 25.09.2026 выявили ошибки разбора ответов и маршрута. В первом случае Очевидец не дал распознанного показания, и Аналитик не был вызван: итог - NeedsHuman. После изменения правила слабая оценка стала отдельным поводом для поиска по коду.

В следующих прогонах менялись ответы, встречался HTTP 502 и «шестой флаг». В тех случаях, где выполнялся Аналитик, итогом оставалась H2. Финальная переоценка записанных ответов дала 3,4 для набора 20:22 и 3,7 для прогонов №2, №3 и №5. Это наблюдение на сохранённых случаях. Подробная таблица с временем и исправлениями - в техприложении.

Дополнительная проверка 10.10.2026

При редактуре я выполнила новый прогон основного прототипа через API NOPik. Все четыре запроса получили ответы; Очевидец верно прочитал пять флагов со снимка демобазы. Аналитик проверил условия в локальной выгрузке расширения 1.7.6.276 и руководстве v 1.7.6. Итог - H2 с оценкой 3,7, H1 - 0,0. Запрос журнала обмена и истории настройки остался открытым: подключение к базе 1С не настроено.

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

Восприятие - только структурой

Вопрос для Очевидца теперь звучит так: «Перечисли переключатели и их состояние. Ответь ТОЛЬКО JSON без пояснений и без Markdown, строго в формате {"flags": {"<подпись>": true|false}}». Живые ответы на него:

20:35  {"flags": {"Использовать поставку в сервис": true, "Создавать поставку в сервисе": false, …,
        "Создавать документ Реализация товаров и услуг/Передача товаров на комиссию при закрытии поставки": false}}
20:35  ```json { "flags": { … пять верных флагов … } } ```
20:40  ```json { … пять верных флагов + тот же фантомный шестой … } ```

evidence/api/ch2-13…, ch2-14…, лог прогона №5.

JSON пришёл все три раза. Но дважды он был в Markdown-обёртке, хотя мы просили без неё, и дважды с фантомным флагом. Поэтому ответ проходит две проверки. Первая - схема: снимаем обёртку, разбираем JSON, все значения должны быть true/false. Вторая - контракт формы: принимаются только подписи пяти переключателей (CheckBoxField), которые есть в Form.xml справочника CG_Online_IWS_НастройкиГенерацииДокументовСервисов. Всё остальное отбрасывается и попадает в протокол:

Очевидец vision_perception +H2: на скриншоте флаг «Создавать поставку в сервисе» выключен;
  вне контракта формы отброшено: ['Создавать документ Реализация товаров и услуг/Передача товаров…']

Контракт формы из дела №1 пригодился второй раз. Там он ловил пропавшие поля, здесь - лишние.

Почему не одна большая модель

Разделение узлов даёт отдельный журнал каждого шага: можно увидеть, что прочитано на снимке, что утверждал сервис и что найдено в коде. Оба свидетеля вызывают один сервис, поэтому независимость их ошибок не установлена. Поиск Аналитика добавляет проверяемый первоисточник. Сравнения с одной большой моделью на той же выборке мы не проводили.

ЛИСТ 0808:05 UTC. Развязка

Лена включила флаг и создала поставку заново. Заказы ушли в поставку WB, стикеры пришли, отгрузка успела к 11:00.

Вопрос Лены «кто снял флаг?» из дела №1 теперь стал вопросом робота. Аналитик превратил его в план. Нужен журнал регистрации: событие изменения элемента справочника «Настройки генерации документов сервисов», пользователь, время, а если включено версионирование - версия объекта до и после. Сервис NOPik на вопрос «как узнать, кто снял флаг» (25,9 с) предложил ту же дорогу: журнал регистрации, отбор по событиям изменения данных и по объекту метаданных.

План есть. Получить журнал робот пока не может: Сборщик СКД в этом эпизоде не подключён к базе.

Решения ретроспективы

Дело привело к двум изменениям прототипа: слабая оценка теперь тоже вызывает Аналитика, а JSON Очевидца сверяется с пятью переключателями Form.xml. Ответ 5xx после повторов сохраняется как недоступное показание; гейт перечисляет оставшиеся проверки.

Для следующего дела нужен ограниченный канал к данным 1С: проверить журнал обмена и историю настройки, сохранив отказ и происхождение ответа. Кнопке предложено давать заголовок, который отражает локальный режим; предложение вендору не означает, что оно уже реализовано.

ЛИСТ 09Врезка «Реальность и концепт»

Полные пути к материалам и различия между действующим кодом, сценарием и концептом приведены в техприложении.

ЛИСТ 10Техприложение

Фрагменты взяты из tools/two_witnesses.py в версии дела №2: вес data для показаний двери в архив появился позже, в деле №3. В блоках В и Г код упрощён: убраны протоколирование и печать.

А. Источник показания и веса

1
2
3
4
5
6
7
8
9
10
11

def source_kind(resp: dict) -> str:
    """Откуда сервис это знает: по полям source и sources ответа /api/ask."""
    if str(resp.get("source", "")).startswith("vision"):
        return "vision"
    src = resp.get("sources") or []
    if src and all("общие знания" in s for s in src):
        return "general"
    return "rag"

WEIGHT = {"unavailable": 0.0, "code": 1.0, "manual": 0.8, "vision_perception": 0.6,
          "rag": 0.3, "vision_reasoning": 0.2, "general": 0.1}

Б. Восприятие Очевидца: JSON + контракт формы

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Пять CheckBoxField из Form.xml справочника CG_Online_IWS_НастройкиГенерацииДокументовСервисов.
FLAG_CONTRACT = {"Использовать поставку в сервис", "Создавать поставку в сервисе", "Использовать товарные ордера",
                 "Использовать Отбор (размещение) товаров", "Создавать отгрузку при закрытии поставки"}

def parse_flags(answer: str) -> tuple[dict, list, str]:
    """JSON восприятия → (флаги из контракта, «фантомы» вне контракта, ошибка)."""
    raw = re.sub(r"^\s*`{3}(?:json)?\s*|\s*`{3}\s*$", "", answer.strip())  # просили без Markdown - не всегда слушается
    try:
        flags = json.loads(raw)["flags"]
    except (ValueError, KeyError, TypeError) as e:
        return {}, [], f"не JSON по схеме ({type(e).__name__})"
    if not all(isinstance(v, bool) for v in flags.values()):
        return {}, [], "значения флагов не true/false"
    return ({k: v for k, v in flags.items() if k in FLAG_CONTRACT},
            [k for k in flags if k not in FLAG_CONTRACT], "")

В. Оценка ветвей и маршрут Супервайзера

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

def score(hyps: dict, evidence: list) -> dict:
    discredited = {c for e in evidence for c in e.get("discredits", [])}
    out = {}
    for h in hyps:
        s = 0.0
        for e in evidence:
            if e["claim"] in discredited:          # основание показания выбито кодом
                continue
            w = WEIGHT.get(e["kind"], 0.1)
            s += w * ((h in e["supports"]) - (h in e["refutes"]))
        out[h] = round(s, 2)
    return out

PRUNE_BELOW = 0.3                       # ниже - ветку не развиваем
VERDICT_MIN, VERDICT_MARGIN = 1.5, 1.0  # гейт: достаточно улик и явный отрыв от второго места

# маршрут: спор свидетелей ИЛИ слабые улики → Аналитик; открытый запрос данных → Сборщик СКД; иначе → гейт
witnesses_disagree = len(supported) > 1 or bool(supported & refuted)
too_weak = best_score < VERDICT_MIN

Г. Отказ свидетеля

1
2
3
4
5
6
7
8
9
10
11
12
13

for attempt in (1, 2):
    try:
        with request.urlopen(req, timeout=180) as resp:
            return {"qid": qid, **json.loads(resp.read().decode("utf-8"))}
    except error.HTTPError as e:
        err = f"HTTP {e.code}"
        if e.code < 500:
            break                           # 4xx повторять бессмысленно
    except (error.URLError, TimeoutError) as e:
        err = type(e).__name__
    if attempt == 1:
        time.sleep(5)
return {"qid": qid, "error": err}           # свидетель даст показание «не получено», граф продолжит работу

В LangGraph параметр retry_policy заново запускает узел целиком. Очевидец проверяет заголовок кнопки и перечисляет флаги формы; ответы занимали от 18 до 48 секунд. Повтор узла заново задавал бы уже отвеченный вопрос, поэтому повторяется только сетевой вызов, завершившийся ошибкой.

Д. Запуск аудита и примера из архива-компаньона

Файл-компаньон к статье решает прикладную задачу: позволяет читателю провести локальный аудит собственного инцидента создания поставки Wildberries FBS, сопоставить ответы ИИ с кодом расширения и контрактом формы и получить локальный HTML-отчёт с доказательствами (файл, строка).

Распакуйте архив-компаньон и откройте терминал в его каталоге. Команды для Windows:

1
2

py -3.12 -m venv .venv
.venv\Scripts\python.exe -m pip install -r requirements.txt

1. Проверка установки и базовый повтор авторской трассы:

1

.venv\Scripts\python.exe tools\two_witnesses.py --replay evidence\run.json

Python читает четыре ответа из сохранённого прогона 25.09.2026 в 20:40 UTC, затем выполняет поиск по приложенным фрагментам кода и руководства. Ожидаемый итог: H2 («флаг снят») - 3,7; H1 («сбой обмена») - 0,3. Запрос журнала базы остаётся открытым вопросом, сетевые соединения отключены.

2. Прогон набора из 8 контрольных краевых сценариев:

1

.venv\Scripts\python.exe tools\two_witnesses.py --verify-suite

Утилита автономно проверяет отсечение выдуманных переключателей (вне form-checkboxes.xml), отказ от поспешных выводов при несовместимой версии или временном разрыве снимка настройки, а также фиксацию неполноты журнала.

3. Аудит собственного инцидента с генерацией HTML-отчёта:

1

.venv\Scripts\python.exe tools\two_witnesses.py --case cases\benchmark --report report.html

Читатель формирует каталог случая: описание инцидента (case.json), ответы сервиса NOPik или сохранённые ответы модели (oracle_calls.json), при наличии - выгрузку технологического журнала (exchange_log.json) и историю изменений настройки (settings_history.json). Программа формирует локальный report.html с диагностическим заключением, таблицей аудита утверждений, проверкой контракта формы и конкретным следующим шагом для инженера 1С.

Е. Чек-лист мультиагентного расследования

1. Запишите источники каждого ответа. Два ответа по одной статье базы знаний не дают независимого подтверждения.
2. Каждое показание хранит вопрос, ответ, sources, tier/source, время и TraceID.
3. Запрашивайте состояния флагов в JSON и сверяйте их названия со списком элементов формы. Объяснение поведения программы проверяйте отдельно по коду.
4. Если ответы расходятся или подтверждений мало, проверьте код и руководство. Согласие большинства ответов не заменяет чтение этих источников.
5. Для каждой версии назовите проверку: например, ошибка запроса должна оставить запись в журнале обмена. Если журнал недоступен, укажите это в итоговом ответе.
6. Итог выбирается по заданным в коде порогам. Ограничьте число шагов графа через recursion_limit, а для сетевых вызовов задайте таймаут и правило повтора.
7. Перед выпуском проверьте согласованность правил на отдельном проверочном наборе (--verify-suite). В приложенный файл-компаньон входит утилита локального аудита инцидентов читателя с генерацией HTML-отчёта, проверочный набор и офлайн-повтор авторской трассы.

Ж. Сборка графа и полная трасса Аналитика

В LangGraph (версия 1.2.12) это десяток строк. Ключевые места:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class CaseState(TypedDict, total=False):
    evidence: Annotated[list, operator.add]   # редьюсер: показания узлов складываются в один список
    react:    Annotated[list, operator.add]
    tot:      Annotated[list, operator.add]
    hypotheses: dict
    route: str
    verdict: dict
    ...

g = StateGraph(CaseState)
g.add_edge(START, "expert")                          # свидетели опрашиваются параллельно
g.add_edge(START, "eyewitness")
g.add_edge(["expert", "eyewitness"], "supervisor")   # Супервайзер ждёт обоих
g.add_conditional_edges("supervisor", lambda s: s["route"],
                        {"analyst": "analyst", "skd_collector": "skd_collector", "gate": "gate"})
g.add_edge("analyst", "supervisor")
g.add_edge("skd_collector", "supervisor")
g.add_edge("gate", END)
app = g.compile()
app.invoke(state, config={"recursion_limit": 12})    # предохранитель от бесконечного спора

Три детали, которые легко упустить:

1. Редьюсер operator.add. Свидетели работают в одном шаге графа параллельно и оба пишут в evidence. Без редьюсера LangGraph не знает, как сложить два значения, и граф падает с InvalidUpdateError: «Can receive only one value per step».
2. add_edge([...], "supervisor") - узел ждёт, пока оба свидетеля закончат. Знаток отвечает о поставке и работе кнопки; пара ответов занимала от 29 до 82 секунд. Параллельный опрос экономил от трети до половины времени в этих прогонах.
3. recursion_limit. Цикл «Супервайзер → Аналитик → Супервайзер» не должен крутиться вечно. Лимит - это бюджет на расследование.

ReAct (Reason + Act) - это цикл «Мысль → Действие → Наблюдение». Агент не отвечает сразу. Он решает, какой инструмент вызвать, смотрит на результат и только потом думает дальше. Вот трасса Аналитика из живого прогона 25.09.2026 в 20:40 UTC:

T1: Свидетели спорят о кнопке. Надпись кнопки - заголовок элемента. Откуда он берётся?
A1: grep_code('СоздатьПоставку.Заголовок', АРМ)
O1: …/CG_Online_АРМКладовщика/Forms/ФормаОсновная/Ext/Form/Module.bsl:109: Элементы.СоздатьПоставку.Заголовок = "Создать поставку в сервисе";
O1: …/CG_Online_АРМКладовщика/Forms/ФормаОсновная/Ext/Form/Module.bsl:121: Элементы.СоздатьПоставку.Заголовок = "Создать поставку в сервисе";
T2: Надпись ничего не доказывает. При каком условии поставка реально уходит в сервис?
A2: grep_code('СоздаватьПоставкуВСервисе', АРМ)
O2: …/Module.bsl:1158: Если НастройкаГенерацииДокументов.СоздаватьПоставкуВСервисе
O2: …/Module.bsl:1231: Если  НастройкаГенерацииДокументов.СоздаватьПоставкуВСервисе Тогда
T3: Код говорит «флаг». Что говорит руководство?
A3: read_manual('Создавать поставку в сервисе')
O3: PDF с. 105: …создан только в 1С. Для включения работы с сервисом необходимо перейти в настройку генерации документов и на вкладке «Поставки товаров в сервис» …
T4: Если поставки в сервисе нет, что будет со стикерами заказов?
A4: grep_code('МассивСтатусов.Добавить("confirm")')
O4: CommonModules/CG_Online_ВзаимодействиеСКонфигурацией_УТ_11/Ext/Module.bsl:8169: МассивСтатусов.Добавить("confirm");
T5: Проверю H1. Если бы запрос к WB упал, коннектор записал бы это в журнал обмена?
A5: grep_code('Ошибка при закрытии поставки Wildberries')
O5: DataProcessors/CG_Online_WB_ИнтеграцияСВайлдберриз/Ext/ObjectModule.bsl:5723: "ru = 'Ошибка при закрытии поставки Wildberries.'…
T6: Готово. Основная версия - H2. H1 не опровергнута, но проверяется только данными 1С.

Вывод tools/two_witnesses.py, пути сокращены. Полный лог - evidence/ch2-run/run-20260925-204027.json.

Честная оговорка. Строки T в прототипе формирует сценарная политика: заранее заданные шаги с ветвлением по наблюдениям. Если в O1 надписи окажутся разными, дальше пойдёт другая ветка. Если в O2 условия не найдётся, Аналитик не поддержит версию H2. В рабочей системе этот шаг можно отдать LLM. Инструменты и гейт сохранятся, формат трассы останется прежним. Трассу можно воспроизвести и положить в проверку.

Теперь разберём, что Аналитик нашёл.

З. Реестр проверенных материалов

И. Статус цепочки и файл-компаньон

Сервис NOPik в этом цикле. Сервис отвечает по документам: руководству пользователя, базе знаний и коду расширения. К данным вашей базы он пока не подключён, поэтому о них не знает. Подключение устроено так: на вопрос о данных сервис присылает схему отчёта СКД, NOPik показывает, что она читает, и строит отчёт в вашей базе, а результат в сервис переносите вы сами. Схема только читает и сама ничего не передаёт; изменений в рабочей базе нет и не будет. Ошибки сервиса, которые мы находим, уходят команде открытым списком, исправления отмечаются в статьях датой. Цель цикла - к последней главе довести эту цепочку до работы. Главы выходят раз в неделю.

Статус цепочки: последняя сохранённая проверка - 27.09.2026. Ответ команды сервиса о схеме СКД не подтверждает, что схема уже приходит; форма NOPik для проверки такой схемы ещё в работе.

• ПРОВЕРЕНО сервис отвечает по документам: руководство, база знаний, код расширения; NOPik в 1С передаёт ему вопрос и скриншот;
• ПРОВЕРЕНО отчёт СКД по готовой схеме строится в учебном расширении из статьи 1;
• ВЕРСИЯ сервис составляет схему СКД под вопрос о данных - ответ rc5-ch3-03-who-unchecked-flag от 27.09.2026 не подтвердил получение схемы;
• ВЕРСИЯ форма NOPik, которая проверяет схему по списку разрешённого и строит отчёт, - в работе;
• в этой главе Сборщик СКД - заглушка: канала к данным у робота нет;
• в следующей главе: почему сервис не отвечает о данных базы (к ней он пока не подключён) и как робот добирается до них сам.

Ограничения собраны во врезке «Реальность и концепт».

Архив содержит утилиту аудита инцидентов читателя, генератор локального HTML-отчёта с доказательствами, проверочный набор из 8 краевых сценариев, эталонный контракт переключателей формы form-checkboxes.xml, авторскую трассу и фрагменты кода. Инструкция - README.md внутри архива. Программа работает полностью автономно и не выполняет запросов во внешнюю сеть.

К. Сверка повторных ответов и журнал прогонов

Рассуждения Очевидца плавают, восприятие - нет. Вопрос по меню АРМ («появится ли поставка в ЛК») Очевидец получил пять раз:

Прогон в 20:26 шёл без сохранения текста ответа. Источники - evidence/api/ch2-10… и логи evidence/ch2-run/.

Четыре сохранённых ответа дали разные объяснения, и ни одно не указало причину по коду. Состояние флага «Создавать поставку в сервисе» на скриншоте настройки Очевидец прочитал верно во всех шести ответах от 25.09.2026: часть ответов была прозой, часть - JSON. Лишние или пропущенные строки всё же встречались: «фантомный» шестой флаг появился в трёх ответах из шести, в одном ответе потерялся пятый.

Стабильность - не истина. Вопрос о статусах заказа FBS прозвучал трижды: в 19:52 и дважды в 20:22. Все три ответа совпали слово в слово: «Новые → В сборке → Готовы к отгрузке → Отгружены», а собрать заказ нельзя, пока его не «Приняли в работу». Источник - статья базы знаний «Заказы FBS Wildberries в ИСМП». Сверим с кодом расширения, с перечислением CG_Online_WB_СтатусыЗаказов:

«Готовы к отгрузке» и «Отгружены» в перечислении нет. В руководстве v 1.7.6 нет ни одного из четырёх названий, которые дал сервис. Три одинаковых ответа означают только то, что свидетель стабильно пересказывает одну статью. Правдивость самой статьи так не проверить.

То же с вопросом из дела №1 («почему вместо токенов Client-Id и Api-Key»). Повтор в 20:23 дал ответ, совпадающий с ответом 19:52 до буквы, - по-прежнему правдоподобный и неверный (ch1-10, ch2-12). А в ответе о 401 после ротации токена (ch5-01) свидетель противоречит сам себе: токен «истёк» и тут же «бессрочный до отзыва».

На записанных ответах граф работал с первого раза. В пяти прогонах против живого сервиса от 25 сентября трижды возникала ошибка; в одном маршруте Аналитик не был вызван. Логи лежат в evidence/ch2-run/.

Главное в этой таблице. Как только дело доходит до Аналитика, вердикт один и тот же. В прогонах №2 и №3 даже с ошибками разбора вышло H2 (2,2 и 3,1 балла). Финальная версия кода на ответах 20:22 даёт H2 с 3,4 балла, на ответах прогонов №2, №3 и №5 - H2 с 3,7 (--replay). Вердикт держится на коде и руководстве, а свидетели влияют только на первый раунд. В этих сохранённых случаях поиск по коду удержал итог при разных ответах свидетелей. Это ещё не проверка устойчивости на других задачах. Прогон №1 показал отдельный риск: маршрут прошёл мимо Аналитика.

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

ЛИСТ 11Следующее дело

RB-PROD-04 закрыл AUD-WB-0519 с пометкой «вердикт по коду; открытый вопрос - журнал обмена и история настройки». Дважды за две недели кто-то снял один и тот же флаг, а робот не может посмотреть, кто. Павел Сергеевич прав: подключать агента к базе напрямую нельзя. Нужна узкая дверь с замком: контракт на каждый запрос, проверка ответа по схеме - как мы только что проверяли JSON Очевидца - и ссылка e1cib/data/…, по которой человек в один клик откроет ту самую запись.

Дело №3: «Ключ от архива». MCP-сервер 1С, валидация контрактов и навигационные ссылки. На Infostart - «Крутое пике. Сериал про RPA. Сезон 1, эпизод 3».

🏁 Итог

В этом примере два ответа ИИ сравниваются вместе с их источниками. Состояние флагов сверяется с формой, объяснение работы кнопки - с кодом и руководством. Итог выбирается по заданным порогам и содержит открытый вопрос, если для проверки нужны недоступные данные базы. В пяти прогонах 25.09.2026 прототип показал такой маршрут на задаче с флагом FBS; это демонстрация на сохранённых данных, не оценка точности для других баз и сервисов.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 70 публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S