AWS объяснила, как выводить агентную автоматизацию из пилота в production

Сначала новый процесс, потом агенты

AWS опубликовала практическое руководство по созданию production-grade автоматизаций в Amazon Quick Automate — многоагентной функции внутри Amazon Quick. Система координирует агентов между подразделениями, корпоративными системами, UI, API и сторонними приложениями. Но центральная мысль материала не связана с выбором модели: качество агентной системы определяется тем, насколько хорошо команда понимает и перепроектирует сам бизнес-процесс.

Подходящие сценарии начинаются с измеримой проблемы: высокой стоимости операции, медленного выполнения, ошибок, неудовлетворённости клиентов или ручной рутины. Агенты особенно уместны там, где процесс связывает несколько systems of record, получает письма и документы в неструктурированном виде, требует контекстного решения и регулярно сталкивается с исключениями. AWS приводит два примера: обработку счёта поставщика и онбординг сотрудника, проходящий через HR, IT и facilities.

До разработки команда должна зафиксировать целевой показатель — cycle time, error rate, throughput или cost per transaction — и спроектировать to-be process. AWS советует не копировать старый ручной маршрут, добавляя к каждому шагу агента, а удалять ненужный перенос данных между таблицами, почтой и системами. Проверки, существовавшие только из-за разорванных инструментов, могут исчезнуть; контроль человека, напротив, надо оставить в точках, где теперь требуется подтвердить суждение модели.

Одна ответственность на одного агента

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

Quick Automate сужает доступные каждому агенту инструкции, tools и actions. Например, компонент чтения документов может получить Amazon Textract или Amazon Bedrock Data Automation, но не остальные средства обработки, которые ему не нужны. Automation Assistant подбирает такой scope по описанию процесса. Дополнительная граница — Structured Output: вместо свободного текста агент обязан вернуть vendor name, invoice number, line items и total по заранее заданной схеме.

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

Если правило можно записать полностью, модель не нужна

Quick Automate позволяет смешивать агентные и детерминированные шаги. Code steps выполняют точные преобразования, расчёты и интеграции с фиксированным контрактом; deterministic control flow проверяет структурированные поля и выбирает заранее заданную ветку. Проверка того, превышает ли сумма счёта порог согласования, должна каждый раз давать одинаковый результат, а не зависеть от reasoning модели.

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

Детерминированной может быть и последовательность нескольких агентов: выход одного компонента передаётся следующему в фиксированном порядке. Это повышает предсказуемость и сокращает время выполнения. Последнее влияет на стоимость напрямую, поскольку Quick Automate тарифицирует agent hours — продолжительность работы агента, — а не количество токенов.

Human-in-the-loop: остановка или параллельная проверка

Для high-stakes операций AWS не рекомендует полную автономность по умолчанию. В Quick Automate есть два разных режима human-in-the-loop. Blocking review останавливает конкретный workflow до ответа человека — например, если счёт не совпал ни с одним purchase order, перед выпуском крупного платежа, отправкой контракта клиенту или записью исправления в system of record. Non-blocking review уведомляет проверяющего, но позволяет системе обрабатывать другие транзакции, пока исключение ждёт решения.

Порог ревью нужно настраивать по реальным результатам. Слишком частая эскалация создаёт false positives: люди начинают механически подтверждать предложения агента. Слишком редкая — false negatives, когда система продолжает работу там, где должна была остановиться. AWS советует начать консервативно, измерять долю решений, которые проверяющие меняют, и повышать порог автономности только для тех классов случаев, где накоплены подтверждения надёжности.

Форма ревью должна показывать исходные изображения и PDF рядом с резюме агента, а blocking step обязан иметь timeout и путь эскалации. Иначе человеческий контроль превращается не в защиту, а в бесконечную остановку процесса. Это особенно важно для финансовых и договорных операций, где проверяющему нужен первичный документ, а не только интерпретация модели.

Evals и observability продолжаются после запуска

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

Custom agent unit testing в Quick Automate проверяет один компонент изолированно: извлекает ли он нужные поля или выбирает ли правильный маршрут при заданном входе. После изменения prompt, instructions или tools эти тесты показывают регрессию до сборки полного workflow. Но unit-level проверки не заменяют наблюдение всей цепочки, поскольку корректные локальные решения могут образовать неправильный общий эффект.

Для каждого выполнения Quick Automate сохраняет шаги, вызванные tools, входы и путь к решению; метрики поступают в Amazon CloudWatch. Наблюдаемость должна отвечать не только на вопрос, завершился ли run, но и почему агент выбрал конкретное действие. Без такой трассы невозможно отличить ошибку модели от неверного tool result, плохого контракта между шагами или неправильной настройки policy.

Identity зависит от того, от чьего имени действует автоматизация

Для запланированных и событийных процессов без присутствующего пользователя Quick поддерживает service authentication: автоматизация получает собственную identity и необходимые разрешения, а каждое действие связывается с этой service identity. Для чатов, персональных агентов и Flows, действующих от имени человека, предусмотрен user-based three-legged OAuth с его согласием и правами доступа.

Разделение важно для аудита и least privilege. Нельзя маскировать unattended process под общую пользовательскую учётную запись или давать персональному агенту безличные широкие credentials только ради удобства. Модель аутентификации должна соответствовать реальному субъекту действия, а набор разрешений — задачам конкретного агента.

Практический смысл руководства AWS — в отказе от противопоставления «умного агента» и жёсткого workflow. Production-система использует модель только в местах настоящей неопределённости, оборачивает её структурированными контрактами, детерминированными проверками, человеческим решением и полной телеметрией. Самая дорогая ошибка возникает раньше: команда автоматизирует старую неэффективность, не определив измеримый результат и не удалив лишние шаги.