ИИ сказал «готово». Как проверить результат?

Концептуальная иллюстрация, сгенерированная ИИ; содержание — гипотетический пример.

Предположим, вы попросили ИИ сохранить отчёт в командный документ, а затем уведомить ответственного. Через несколько минут он отвечает: «Уже готово».

Вы открываете документ и видите только заголовок и один вводный абзац; затем смотрите уведомление — в указанном канале сообщения нет. Ассистент ничего не выдумал: на каждом вызванном им шаге был получен ответ, просто «уже готово» описывает процесс его вызовов, а не нужный вам результат.

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

Описывайте «готово» как проверяемый результат

«Привести в порядок отчёт и уведомить команду» подходит как краткое описание задачи, но не годится для приёмки. Это можно развернуть в набор условий, которые можно сверить в целевых системах.

Возьмём еженедельный отчёт о конкурентах:

Требование задачи	Условие завершения (где можно проверить)
Привести в порядок отчёт	Охватывает указанный период, сохраняет ссылки на источники, отмечает отсутствующие материалы
Сохранить документ	Находится в указанном рабочем пространстве и под указанной родительской страницей, основной текст совпадает с финальной версией
Уведомить команду	Появляется в указанном канале, ссылка в сообщении ведёт на документ, описанный выше
Передать результат	Возвращает расположение документа, запись об уведомлении, а также незавершённые или непроверенные пункты

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

«Уже отправлено» и «получатель уже прочитал» тоже нужно разделять. Появление сообщения в канале может подтверждать суждение «опубликовано»; при отсутствии записи о прочтении или подтверждении нельзя делать дальнейший вывод, что получатель увидел сообщение и отреагировал.

Три вида доказательств отвечают на разные вопросы

При проверке есть три вида материалов, и каждый может ответить лишь на часть вопросов.

Ответ инструмента      Какой ответ получен на этот вызов?
                       Статус, ошибка, идентификатор возвращённого объекта
                            │
Целевая запись         Где оказался результат? Можно ли его прочитать обратно?
                       Документ, сообщение, запись в целевом приложении
                            │
Проверка содержимого   Соответствует ли артефакт требованиям?
                       Сверка основного текста, источников, отсутствующих пунктов с условиями завершения

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

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

Проверка содержимого показывает, можно ли передавать артефакт. Документ существует, но в нём всё ещё может отсутствовать раздел; отчёт содержит ссылки на источники, но может ссылаться на данные за неверный период. На этом шаге нужно вернуться к исходным условиям завершения и сверить их пункт за пунктом, а не просто смотреть, «удалось ли создать».

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

Частичный успех нужно сообщать отдельно

Многошаговая задача может быть выполнена лишь частично: предыдущий шаг уже завершён, а по следующему вывода всё ещё нет.

Ниже — набор гипотетических записей, иллюстрирующих подход, а не фактический журнал вызовов:

Шаг	Наблюдаемый результат	Текущая оценка
Сохранить документ	Возвращён идентификатор документа; после повторного чтения основной текст полон, расположение верное	Сохранён и проверен
Отправить уведомление	Запрос завершился тайм-аутом, идентификатор сообщения не получен	Результат неизвестен
Запросить целевой канал	У текущей учётной записи нет прав на чтение сообщений	Невозможно подтвердить с этой учётной записи

В этом случае ассистент должен сообщить: «Документ сохранён, результат уведомления не подтверждён», приложив ссылку на документ и причину блокировки.

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

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

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

Сохраняйте статус «не подтверждено» в итоговом отчёте

Рабочая квитанция может выглядеть так. Содержимое в квадратных скобках заполняется фактическим результатом; если получить его не удалось, укажите это явно и не создавайте правдоподобную на вид ссылку.

Задача: сохранить еженедельный отчёт о конкурентах и уведомить указанный канал

Документ: сохранён и проверен
Расположение: [фактическая ссылка на документ или идентификатор записи]
Проверено: целевое рабочее пространство, родительская страница, основной текст, ссылки на источники

Уведомление: результат не подтверждён
Причина: запрос на отправку завершился тайм-аутом; текущая учётная запись не может читать сообщения целевого канала
Действие: повторная отправка приостановлена во избежание дублирования уведомления

Требуется ваше подтверждение: появилось ли в целевом канале сообщение со ссылкой на указанный выше документ

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

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

Что можно узнать из записей выполнения OOMOL

Слой подключений может предоставить возможность вызова и записи о вызовах, но суждение о приёмке всё равно должна давать сама задача.

Контроль доступа в OOMOL настраивает доступные для вызова операции по connection. При проектировании задачи стоит учитывать два момента: во-первых, нужно одновременно учитывать возможности чтения, необходимые для проверки, — разрешение создавать документы не означает автоматически, что ассистент сможет прочитать обратно соответствующие записи; во-вторых, даже если права позволяют вызвать какую-либо операцию, перед отправкой сообщения, изменением внешних данных, расширением области общего доступа или удалением содержимого всё равно следует подтвердить целевой connection, операцию и окончательные параметры.

При самостоятельном развёртывании OpenConnector последние записи о запусках содержат обезличенные сводки входных данных и ошибки provider; с помощью OOMOL_CONNECT_ALLOWED_ACTIONS и OOMOL_CONNECT_BLOCKED_ACTIONS можно ограничить исполняемые операции. Ассистент видит только schema, scope, статус выполнения и безопасные метки учётных записей. Эти записи подходят для диагностики сбоев вызова, но они описывают вызов, а не то, достигнута ли бизнес-цель. Руководство по самостоятельному развёртыванию

Если задача требует ожидания ручного утверждения, узлы Approval и Wait в Open Flow сохраняют состояние ожидания, и после подтверждения можно продолжить тот же запуск, не повторяя уже завершённые шаги. История запусков связана с соответствующей версией процесса, что позволяет выяснить, какая версия логики создала тот или иной результат. Управляемая версия · Исходный код и самостоятельное развёртывание

Условия завершения, статусы шагов, решения о повторе и итоговую квитанцию должны реализовывать инструкции ассистента, бизнес-код или рабочий процесс. Слой подключений даёт путь вызова и записи, но не решает за вас, прошла ли вся задача приёмку.

Начните с задачи, результат которой можно проверить

Сначала выберите один шаг записи, не связывайте сразу всю цепочку. Настройте в OOMOL Connections подключения, необходимые для задачи, сверьте доступные операции, а затем передайте ассистенту следующее требование:

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

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

Ключ к приёмке не в том, что ассистент сказал в конце, а в том, сможете ли вы по указанному им расположению найти этот результат в целевой системе. Когда каждому шагу записи соответствует проверяемое условие, у фразы «уже готово» появляется основание.