Прогоны workflow агента перед живым доступом к реальным системам

Почему тестирование сразу в проде вызывает проблемы

Агенту не нужен огромный баг, чтобы устроить настоящий беспорядок. Если он получает живой доступ с первого дня, он может отправить сообщение клиенту, изменить запись или повторить одно и то же действие десятки раз, прежде чем кто‑то заметит. Быстрый тест очень быстро превращается в работу по очистке данных.

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

Вызовы инструментов могут нанести ещё больший ущерб. Один неверный запрос к CRM, биллинговой системе или системе поддержки может изменить статус, перезаписать заметки, закрыть кейс или создать дубликаты. Если агент зацикливается или повторяет вызовы без защит, плохие данные размножаются по другим инструментам.

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

Вот почему важны dry run для workflow агентов. Они ловят скучные ошибки, которые команды пропускают при ручном тестировании. Несоответствие прав, пустые значения, медленные ответы, частичные результаты и ненадёжные ответы инструментов не драматичны, но появляются в реальной работе каждый день.

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

Что включить в dry run

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

Начните с фиктивных данных, которые выглядят скучно и нормально. Используйте реалистичные имена, даты, номера заказов, суммы счетов, заметки поддержки и изменения статусов. Чистые примеры делают агентов лучше, чем они есть на самом деле, поэтому создавайте записи, похожие на те, что ваша команда видит в среду.

Затем усложните данные. Оставьте без e‑mail. Поставьте текст там, где должен быть номер. Добавьте пустое поле там, где агент ожидает дату выполнения. Дайте одной записи старый формат, а другой — опечатку от человека. Безопасное тестирование агентов становится полезнее, когда входные данные немного раздражают, потому что реальные системы полны таких мелочей.

Нужны и жёсткие отказы. Сделайте так, чтобы один инструмент отвечал «permission denied», когда агент пытается прочитать заметку, обновить запись или отправить сообщение. Агент не должен догадываться, проламываться через ограничения или бесконечно повторять попытки. Он должен остановиться, объяснить, что не получилось, и оставить чёткий след для проверки человеком.

Умышленно замедлите один инструмент. Если запрос к базе данных занимает 20 секунд или API таймаутится в первый раз и срабатывает при второй попытке, workflow должен оставаться спокойным. Тестирование таймаутов часто выявляет скрытые проблемы: дублирующие действия, незавершённые прогонки или петли повторов, которые создают больше проблем, чем исходная задержка.

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

Dry run обычно достаточно, если он отвечает на несколько простых вопросов. Выглядят ли данные достаточно правдоподобно, чтобы выявить неверные предположения? Обрабатывает ли агент отсутствующие и повреждённые поля без выдумывания ответов? Останавливается ли он чисто, когда доступ заблокирован? Восстанавливается ли он после медленных инструментов и кратковременных сбоев? Избегает ли дублирующих действий при повторных попытках?

Если на эти вопросы можно ответить «да», переход к живому доступу станет меньшим шагом, а не слепым прыжком.

Постройте безопасную тестовую среду

Хорошая тестовая среда кажется реальной для агента и безвредной для бизнеса. Если workflow всё ещё может отправлять письма клиентам, редактировать записи или запускать платежи, это не dry run. Это прод, в котором просто хотят надеяться на лучшее.

Скопируйте весь workflow в отдельное тестовое пространство. Сохраните те же prompts, порядок инструментов и логику передачи задач. Меняйте окружение вокруг него, а не сам workflow, чтобы понять, как ведёт себя реальный процесс.

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

Фиктивные данные должны выглядеть правдоподобно. Дайте агенту и чистые записи, и «грязные»: пропуски полей, одинаковые имена, старые статусы и заметки, не совпадающие с записью. Многие dry run выглядят хорошо только потому, что тестовые данные слишком аккуратные.

Поменяйте все живые секреты до первого прогона. Одна скопированная API‑токен или пароль SMTP могут превратить репетицию в реальное действие. Если инструмент может писать, удалять, публиковать, снимать деньги или уведомлять — направьте его в тестовый аккаунт или отключите соответствующее действие.

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

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

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

Прогоняйте workflow шаг за шагом

Начните с малого. Выберите одну задачу и один инструмент, затем прогоните этот путь от начала до конца, прежде чем добавлять что‑то ещё. Если агент может прочитать запись счёта и подготовить одно follow‑up сообщение, этого достаточно для первого прогона.

Перед запуском перечитайте prompt, правила и схему инструмента как рецензент, а не как разработчик. Ищите расплывчатые формулировки, отсутствующие ограничения и поля, которые инструмент ожидает, но про которые prompt ничего не говорит. Многие dry run ломаются из‑за простых причин: неверного имени поля или расплывчатой инструкции.

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

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

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

Такой небольшой, повторяемый подход ловит ошибки рано, когда в риске только фиктивные данные и несколько минут работы.

Проверьте права доступа, прежде чем доверять агенту

Сначала дайте агенту доступ только для чтения. Это звучит строго, но многое показывает. Если workflow всё ещё работает, агент, вероятно, читает правильные данные, выбирает нужные инструменты и понимает задачу. Если он проваливается, вы узнаете об этом, прежде чем он сможет изменить запись, отправить сообщение или что‑то удалить.

Затем сознательно заблокируйте операции записи. Не ждите настоящей ошибки, чтобы проверить реакцию агента. В dry run принудительный отказ — один из самых быстрых способов выявить плохое поведение. Некоторые агенты будут снова и снова пытаться выполнить тот же вызов. Другие начнут придумывать причины ошибки. Ни то, ни другое неприемлемо.

Желаемый паттерн прост. Когда агент доходит до шага записи, он должен приостановиться, пояснить, что собирается сделать, и запросить одобрение простыми словами. Человек должен понять запрос за секунды. «Обновить 12 записей клиентов» — ясно. «Execute tool action with payload» — нет.

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

Последний пункт важнее, чем команды думают. Хорошие записи помогают исправить prompts, ужесточить правила и объяснить потом, почему агент запросил больше полномочий. Если вы работаете с клиентами или внутренними командами, лог также прекращает споры: вы можете показать точный запрос и точный ответ.

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

Тестируйте медленные инструменты и битые ответы

Большинство проблем не начинаются с драматического краха. Инструмент зависает на 15 секунд, возвращает неполный payload или отправляет пустой результат, который выглядит достаточно правдоподобно, чтобы ввести агента в заблуждение. Поэтому dry run должны включать медленные ответы и «сломанные» ответы, а не только счастливые кейсы.

Начните с одного инструмента. Добавьте задержки 5, 15 и 60 секунд и наблюдайте за действиями агента на каждом шаге. 5 секунд тестирует терпение. 15 секунд часто выявляет логику повторных попыток. 60 секунд показывает, продолжит ли workflow ждать, повторит ли слишком рано или сдастся так, чтобы человек понял ситуацию.

Битый вывод важен не меньше медленного. Попросите инструмент вернуть пустой массив, пустую строку и неверно сформированные данные. Затем оборвите один ответ на полуслове, как будто сеть упала посередине. Многие агенты лучше справляются с явной ошибкой, чем с «грязным» ответом. Именно грязные случаи ведут к ошибочным решениям.

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

Следите за поведением: повторяет ли агент один раз или циклится бесконечно? Понимает ли он, что первое действие уже произошло? Логирует ли он сбой простым языком? Просит ли помощи, когда результат выглядит неполным? Останавливается ли он до того, как повторит рискованное действие?

Установите правило передачи управления до теста. Например: при одном таймауте для чтения — повторить один раз. При одном таймауте для записи — остановиться и попросить человека проверить состояние. Если ответ неверно сформирован, остановиться, если только инструмент не может подтвердить результат другим способом.

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

Простой пример: агент по напоминаниям по счетам

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

Хороший dry run начинается с фиктивных счетов, вымышленных имён клиентов и придуманной суммы. Команда может создать несколько типичных случаев: один счёт просрочен на семь дней, один в споре и один, который клиент оплатил сегодня утром. Имена, номера счетов и e‑mail должны быть выдуманными, чтобы никто случайно не получил реальное напоминание.

Затем команда прогоняет агента по тем же шагам, что и в проде: читает счёт, проверяет историю платежей, готовит письмо и решает, отправлять ли его или приостановить.

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

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

Когда почтовый инструмент тормозит, агент должен избегать повторных отправок. Если инструмент зависает на 20–30 секунд, агент может сохранить подготовленное сообщение как черновик, залогировать задержку и попросить человека проверить. Это защищает команду от дублей и недоразумений.

Успех в таком dry run — это специально скучный результат. Никакое живое сообщение не уходит. Агент либо формирует аккуратный черновик с краткой причиной, либо маршрутизирует кейс к человеку. Если вы хотите, чтобы агенты помогали в финансовой работе, такая осторожность — это преимущество, а не недостаток.

Ошибки, создающие ложную уверенность

Многие dry run проходят по ложным причинам. Агент выглядит спокойным, логи коротки, и команда считает его готовым. Но первый же «грязный» кейс ломает весь поток за минуты.

Ложная уверенность чаще всего возникает из‑за дизайна теста, а не из‑за агента. Если workflow видит только чистые входы и гладкие ответы инструментов, вы тестируете демо, а не рабочий процесс.

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

Ещё одна проблема — слишком чистые фиктивные данные. Имена совпадают, ID существуют, даты валидны и каждая запись однообразна. В реальных системах есть устаревшие записи, лишние пробелы, наполовину заполненные формы и старые значения, которые никто не пофиксил.

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

Логика повторов тоже может ввести в заблуждение. Агент, который бесконечно повторяет попытки, выглядит настойчиво на тестах, но в проде он может съесть бюджет API, заблокировать аккаунт или создать дубли. Установите лимиты повторов и фиксируйте итоговую причину остановки.

Логи — не опция. Когда dry run проваливается, команда должна увидеть ввод, вызов инструмента, ответ и последующее решение агента. Без этой трассы люди начинают догадываться, а догадки приводят к слабым утверждениям.

Простое правило помогает: сделайте тестовое окружение чуть раздражающим. Добавьте «грязные» записи. Замедлите один инструмент. Откажите в одном праве. Верните один искажённый ответ. Безопасное тестирование агентов должно казаться немного нечестным, потому что реальные системы часто такими и бывают.

Если workflow всё ещё завершает задачу или останавливается чисто с понятной причиной, результат значит гораздо больше.

Быстрая проверка перед живым доступом

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

Используйте простый проход/провал. Если хоть одна проверка неясна — оставляйте агента в тестовом режиме.

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

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

Один человек должен подписать результат после прочтения вывода прогона. Совместная ответственность часто превращается в отсутствие ответственности.

Небольшой пример иллюстрирует мысль. Допустим, агент по напоминаниям читает неоплаченные счёта и формирует письма. В тесте почтовый инструмент возвращает отказ в доступе, а финансовая система зависает на одном клиенте. Хорошая прогонка не импровизирует: она логирует оба сбоя, пропускает шаг отправки, сохраняет черновик или помечает кейс как ожидающий, и оставляет достаточно деталей для проверки человеком.

Эта финальная подпись важнее, чем команды признают. Один человек должен просмотреть транскрипт, сравнить с ожидаемыми результатами и сказать «да, можно запускать» или «нет, сначала исправьте эти два случая». Такое решение не позволит живому доступу стать первым реальным тестом.

Что делать после dry run

После прогона удержитесь от желания сразу открыть полный доступ. Безопаснее действовать поэтапно: исправьте то, что упало, подтвердите исправление, и только потом расширяйте область.

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

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

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

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

Держите ручную проверку для первых живых прогонов. Кто‑то должен сверять входы, планируемые вызовы инструментов и итог перед тем, как доверять автоматике — до тех пор, пока workflow не начнёт вести себя одинаково несколько раз подряд. Это займёт чуть больше времени, но обойдётся дешевле, чем исправление неверных записей или недовольных клиентов.

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

Если workflow затрагивает продовые системы, деньги или данные клиентов, привлеките второе мнение. Oleg Sotnikov делится подобными советами Fractional CTO через oleg.is, и такой обзор может помочь ужесточить права, повторы и защитные меры перед расширением доступа.

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