На этой странице
Число 420 может быть правильным по двум несовместимым причинам. В условном примере два агента возвращают сегмент контактов, и оба считают 420 клиентов. Первый использовал утверждённую аудиторию магазина и проверил согласие. Второй скопировал старую выгрузку из другого рабочего пространства и случайно получил то же число.
Оценка только результата поставит обоим высший балл. Это неверная оценка.
Обсуждение проверки работы агентов разделяет конечный результат и путь к нему. В примере с электронной таблицей правильное число составляет лишь часть задачи. Формулы, ссылки на источники и обязательный формат тоже важны. Для интеграций различие острее: происхождение результата может определять саму допустимость действия.
Конечное значение не доказывает происхождение
Допустим, агент предлагает сопоставить поля объекта клиента магазина с маркетинговой системой. Он связывает email с адресом email, firstName с именем, а поле согласия со статусом маркетинга в назначении. Предварительный просмотр выглядит разумно.
Что агент прочитал перед выбором? Действующую схему, старый образец или документ другого аккаунта? Изучил ли значение поля согласия или угадал его по названию? Посчитал ли null значением «не подписан» или «неизвестно»?
Каждый ответ меняет степень доверия к той же конечной схеме. Сопоставление является результатом. Цепочка доказательств служит аргументом для его применения.
Эта цепочка должна указывать, какая версия каждого источника была доступна во время решения. Поздний снимок уже исправленной схемы не объясняет вчерашнее предложение. Сохраните относящуюся к делу версию схемы или документа вместе с решением и связь между версией и утверждённым правилом. Цель восстановить решение, а не сохранить каждую страницу, увиденную агентом.
Поэтому трасса вызовов инструментов может быть важнее уверенного объяснения. Она фиксирует конкретные вызовы и идентификаторы. Письменное резюме полезно, но не доказывает обращения к источнику. В интеграции доказательства должны вести к исходному объекту, контракту назначения и конкретному правилу перемещения данных.
Руководство по интеграции бизнес-инструментов начинает с владельца каждого поля: одинаковые названия не определяют полномочий. Проверка процесса спрашивает, обратился ли агент к решению о владельце до подготовки записи.
Опишите допустимый путь в задаче
Хороший тест состоит из двух частей. Укажите, что должно оказаться в назначении. Затем укажите, какие источники и действия допустимы по пути.
Для условного сегмента ожидаемый результат может составлять 420 контактов. Допустимый путь дополнительно требует запроса в пределах аккаунта магазина, текущего сопоставления согласий и предварительного просмотра с перечнем исключённых записей. Чтение другого рабочего пространства и прямую отправку кампании можно запретить.
Тогда проверяющий получает конкретные правила. Идентификатор чужого пространства можно отклонить механически. Можно убедиться, что просмотр предшествовал активации и источник в результате совпадает с источником в трассе. Это правила, а не мнения модели.
Остаётся вопрос, требующий суждения: означает ли выбранное поле согласия разрешение именно для этой кампании? Определение поля и назначение использования должны изучить человек или узкая модель решений. Правило и суждение делают разную работу.
Тест тогда сообщает полезную причину неудачи. «Неверный ответ» оставляет команду гадать. «Число верно, но аудитория взята из чужого рабочего пространства» указывает на нарушение границы данных. «Схема верна, но определение согласия отсутствует» указывает на нехватку доказательств. Проверяющий должен назвать нарушенное условие и вызов из трассы, чтобы исправить путь, а не только формулировку.
Что подтверждает трасса?
-
Одобренный источник и нужные проверки
Принять путь
У результата есть требуемые задачей доказательства.
-
Источник из другого пространства
Отклонить путь
Совпадение числа не разрешает такое чтение.
-
Обязательных данных нет
Передать на рассмотрение
Результат не доказывает способ получения.
Не превращайте трассу в ритуал
Разумное возражение: «Агент может сделать обязательные вызовы и не учесть ответы». Верно. Список вызовов доказывает их выполнение, но не влияние полученных данных на решение.
Проверьте это изменением доказательств. Дайте две похожие записи с разными статусами согласия. Если агент одинаково сопоставляет и объясняет обе, обращение к источнику может быть видимостью. В другом испытании уберите обязательный источник и потребуйте остановки. Агент, заполнивший пробел по памяти, не соблюдал путь.
Цена заключается в более сложном тестовом наборе. Кто-то должен определить разрешённые источники, ожидаемые различия и запрещённые обходы. Общую оценку «Хорошо ли выглядит ответ?» построить дешевле, но она учит меньшему.
Reverse ETL превращает сопоставление в повторяющееся движение данных. После утверждения обычный код может применять его без повторного расследования на каждой строке. Проверка пути нужна в решениях, создающих или меняющих правило, а также после изменения контракта.
Верный ответ, полученный через чужой аккаунт, не является почти успешной задачей. Это другая задача.
Часто Задаваемые Вопросы
Зачем проверять путь, если итоговый ответ верен?
Агент мог использовать запрещённые данные, пропустить обязательную проверку или случайно получить верное значение. Сам результат не доказывает, что путь был безопасным и повторяемым.
Нужен ли человек для просмотра каждого промежуточного действия?
Нет. Записывайте вызовы инструментов и применяйте детерминированные правила для запрещённых действий. Изучайте значимые или спорные шаги и проверяйте представительные трассы.
Как это проверять команде?
Сопоставьте ожидаемое конечное состояние с допустимыми источниками и обязательными проверками. Повторите случаи, где обходной путь даёт тот же ответ, и убедитесь, что проверяющий его отклоняет.