Большинство ИИ-помощников бездействуют, пока вы о чём-то не спросите. Вы вводите вопрос, они отвечают, а затем ждут. При соблюдении торговых требований эта модель имеет фундаментальную проблему: риски не ждут, пока кто-то о них спросит.
В Atlas Verified мы создали систему автономных облачных агентов, постоянно отслеживающих цепочки поставок, сканирующих государственные базы и выявляющих риски соответствия по расписанию без ввода запросов человеком. Они работают в фоне для каждой организации на нашей платформе и доставляют структурированную аналитику непосредственно на панель управления.
Эта публикация посвящена инженерии постоянно работающих ИИ-агентов: их отличиям от разговорного ИИ, важности структурированного вывода и задачам оркестрации автономных агентов в большом масштабе.
От реактивного подхода к проактивному
Разговорный ИИ по природе реактивен. Пользователь задаёт вопрос, модель размышляет над ним, вызывает инструменты и возвращает ответ. Это хорошо подходит для разовых исследований и анализа документов. Но мониторинг соответствия требует проактивной аналитики.
Представьте сценарий: USDA за ночь приостанавливает органическую сертификацию поставщика. Его поставка уже в пути. Новое решение OFAC добавляет экспедитора в санкционный список. FDA выпускает предупреждение об импорте сырья, которое вы активно ввозите.
Ни одно из этих событий не ждёт, пока специалист войдёт в систему и задаст правильный вопрос. К моменту, когда кто-то решит проверить, окно для предупредительных действий может закрыться. Товары уже в порту. Документы поданы. Риск реален.
Облачные агенты решают это, переворачивая взаимодействие. Вместо управления ИИ пользователем ИИ сам действует по расписанию, проверяет всё важное и передаёт выводы пользователю.
Архитектура с агентом для каждого квадранта
В первых прототипах облачных агентов мы пробовали одного агента для всего: нормативных изменений, статуса поставщиков, отслеживания поставок и обработки документов. Он выдавал бессистемный многословный результат. Агент увлекался одной интересной темой и игнорировал целые категории аналитики.
Решением стало разделение области задач на целевые направления, которые мы называем квадрантами:
Аналитика. Нормативные предупреждения, рыночные тенденции и сквозные риски. Этот агент отслеживает государственные базы на предмет изменений, влияющих на организацию: новых предупреждений FDA об импорте, обновлений списков OFAC, изменений тарифов и статуса органической сертификации.
Поставщики. Состояние сети поставщиков. Этот агент изучает статус проверки поставщиков, пробелы соответствия, истечение сертификатов и риски концентрации сети. Если 80% ваших органических поставок связано с одним органом сертификации, он это отмечает.
Поставки. Мониторинг активных поставок. Этот агент отслеживает положение судов, отклонения маршрутов и задержки, а также проверяет полноту документов. Он выявляет такие проблемы, как контейнеры, стоящие в порту дольше ожидаемого, или суда, отклонившиеся от заявленных маршрутов.
Рабочее пространство. Операционное состояние. Этот агент изучает статус обработки документов, ожидающие проверки, активность команды и модели использования платформы. Он выявляет документы с неудавшейся обработкой, требующие внимания, или слишком долго ожидающие проверки.
Каждый агент работает с целевым системным запросом и ограниченным набором инструментов своего направления. Это даёт значительно лучший результат, чем один всезнающий агент, по той же причине, по которой команда специалистов превосходит одного универсала: глубина сосредоточенности.
Общий слой инструментов с агентом чата
Одним из важнейших архитектурных решений стало использование облачными агентами того же слоя инструментов, что и разговорным агентом чата. Обе системы используют одинаковые проверки OFAC, поиск USDA, отслеживание судов, запросы торговых данных и инструменты анализа документов.
Это даёт значительные инженерные преимущества:
Без дублирования инструментов. Когда мы добавляем источник данных или улучшаем адаптер, агент чата и облачные агенты сразу получают пользу. Одна реализация, один набор тестов, одна область обслуживания.
Согласованные результаты. Санкционная проверка облачного агента и проверка пользователя в чате вызывают одну функцию с одинаковой логикой. Результаты напрямую сопоставимы и доступны для перекрёстной проверки.
Проблема в том, что инструменты для интерактивного использования не всегда работают так же в пакетном контексте. Агент чата может попросить уточнение при неоднозначном запросе. Облачный агент не может. Мы решаем это более конкретными запросами и более высокими пределами рекурсии для облачных агентов: у них больше времени на самостоятельное исправление, поскольку никто не ждёт ответа в реальном времени.
Структурированный вывод: от свободного текста к карточкам панели
Здесь облачные агенты наиболее резко отличаются от агентов чата. Агент чата создаёт повествовательный текст, иногда со встроенными структурированными карточками. Облачный агент должен выдавать исключительно структурированный результат, отображаемый прямо на панели управления.
Каждый запуск агента создаёт массив аналитических карточек. Каждая карточка имеет определённый тип и схему:
Счётчики показывают ключевые показатели с индикаторами тенденций: общее число активных поставок, поставщиков с истекающими сертификатами и ожидающих проверок.
Сигналы риска выделяют конкретные проблемы соответствия, требующие внимания: поставщика с приостановленной сертификацией, санкционное совпадение, предупреждение FDA об импорте.
Уведомления сообщают информацию, важную во времени: нормативные изменения, новые включения в OFAC, обновления тарифов, влияющие на активные поставки.
Графики и таблицы представляют аналитические данные: тенденции объёмов поставок, распределение торговых направлений, доли завершённых проверок.
Карты показывают географическую аналитику: положение судов, активность портов, распределение поставщиков.
Инженерная задача — добиться от LLM стабильного корректного структурированного вывода. Языковые модели хотят рассказывать, объяснять и оговаривать. Для получения чистого JSON-массива карточек с правильными типами, полями и данными нужны тщательно разработанные запросы и валидация вывода.
Когда результат агента не соответствует ожидаемой схеме карточек, мы разбираем доступное и отбрасываем некорректные карточки, вместо отказа всего запуска. Частичная аналитика лучше отсутствия аналитики.
Пользовательские агенты: автономные мониторы, определяемые пользователем
Помимо четырёх системных агентов, пользователи могут создавать собственных облачных агентов. Пользовательский агент имеет название, системный запрос, написанный пользователем, и расписание. Он использует тот же слой инструментов и создаёт те же типы карточек, но его направление полностью определяется пользователем.
Пользователь может создать агента, отслеживающего нарушения на конкретном торговом направлении. Или ежедневно проверяющего определённую группу поставщиков по санкционным спискам. Или отслеживающего движение цен на конкретное сырьё по торговым источникам. Возможности ограничены лишь доступом слоя инструментов.
Для безопасности и полезности потребовалось несколько инженерных решений:
Ограничение организацией. Каждый пользовательский агент принадлежит организации и имеет доступ только к её данным. Агент не может пересекать границы организаций, даже если запрос пользователя пытается заставить его это сделать.
Фильтрация возможностей инструментов. Пользовательские агенты имеют доступ к тем же инструментам проверки и исследований, что и системные, но наследуют границы разрешений организации. Агент не может получить доступ к инструментам или данным, недоступным самому пользователю через чат.
Управление расписанием. Пользовательские агенты работают по заданному пользователем расписанию в пределах ограничений платформы. Это не позволяет одной организации потреблять несоразмерные вычислительные ресурсы, планируя ежечасный запуск десятков агентов.
Оркестрация в большом масштабе
Ежедневный запуск автономных агентов во многих организациях создаёт задачи оркестрации, отсутствующие в системе чата.
Удаление дубликатов. Если планировщик срабатывает, а агент организации A уже запускался в окне удаления дубликатов, запуск пропускается. Это предотвращает двойные запуски из-за повторных попыток, пересекающихся расписаний или сбоев планировщика. Каждая пара агент–организация считается отдельной единицей планирования.
Изоляция сбоев. Если агент одной организации отказывает из-за ошибки инструмента, неразбираемого вывода LLM или недоступности зависимого сервиса, это не должно влиять на запуски агентов других организаций. Каждый запуск — независимое задание. Сбои записываются в журнал, запуск отмечается как неудачный, и планировщик продолжает работу.
Жизненный цикл карточек. Аналитические карточки имеют срок жизни. Старые карточки истекают и заменяются при следующем запуске агента. Это обеспечивает актуальную аналитику на панели вместо накопления устаревших выводов. Когда агент создаёт новые карточки, предыдущие карточки данного квадранта атомарно заменяются.
Бюджетирование ресурсов. Запуски агентов потребляют токены LLM, вызовы внешних API и соединения с базой данных. Мы отслеживаем расход токенов на запуск и организацию для управления затратами и выявления агентов с несоразмерным потреблением ресурсов. Агент, вышедший из-под контроля и совершающий 50 вызовов вместо достаточных 10, отмечается.
Соединение Cloud Agents и чата
Облачные агенты и агент чата не изолированы. Они образуют контур обратной связи.
Агент чата может запрашивать результаты облачных агентов. Когда пользователь спрашивает «что нашли мои агенты?» или «есть ли риски соответствия, о которых мне нужно знать?», агент чата получает свежие аналитические карточки и представляет их в разговоре. Он может объяснить сигнал риска, дать дополнительный контекст или помочь принять меры по выводу.
Это создаёт естественный процесс: облачные агенты выявляют проблемы ночью, пользователь утром изучает панель, а для более глубокого изучения вывода открывает чат. Агент чата уже знает, что нашли облачные агенты, и продолжает с того места, где они остановились.
Работает и обратный путь: закономерности пользовательских разговоров помогают нам настраивать запросы облачных агентов. Если пользователи часто спрашивают о риске, который агенты не выявляют, это сигнал скорректировать их направление.
Чему мы научились
Разработка автономных ИИ-агентов дала уроки, неочевидные при создании разговорных агентов:
Структурированный вывод сложнее свободного текста. Добиться от LLM стабильного корректного JSON, соответствующего схеме, — существенно иная задача, чем получить хороший абзац. Модели хотят объяснять, и нужно направлять эту аналитическую энергию в структурированные поля.
Область задач решает всё. Целевой агент с ясным направлением создаёт лучшую аналитику, чем широкий агент с доступом ко всему. Архитектура с агентом для каждого квадранта стала нашим крупнейшим улучшением качества.
Частичные результаты лучше неудачных запусков. В пакетной системе нельзя спросить пользователя, что делать при проблеме. Плавное снижение функциональности — создание доступных карточек с указанием пробелов — необходимо.
Пользователям нужен контроль. Пользовательские агенты оказались одной из самых востребованных функций. Специалисты по соблюдению требований знают свои конкретные риски лучше любой универсальной системы. Возможность программировать автономные мониторы на естественном языке дала значительную ценность.
Контур обратной связи важен. Облачные агенты и агенты чата полезнее вместе, чем по отдельности. Проактивная аналитика определяет повестку, а разговорный ИИ обеспечивает глубину. Проектирование этого двустороннего потока с самого начала улучшило обе системы.
Взгляд вперёд
Облачные агенты означают фундаментальный сдвиг в нашем понимании ИИ для соблюдения требований. Вопрос не «на что ИИ может ответить по запросу?», а «что ИИ должен проверять без запроса?»
По мере расширения слоя инструментов новыми источниками и усложнения нормативной среды ценность автономного мониторинга растёт. День специалиста не должен начинаться с ручной проверки шести государственных баз и трёх сервисов отслеживания. Он должен начинаться с панели, точно показывающей ночные изменения и то, что требует внимания.
Именно это дают облачные агенты. А инженерная задача сделать это надёжным, масштабируемым и полезным — одна из самых увлекательных в нашей работе.
Облачные агенты Atlas Verified автономно отслеживают цепочки поставок, сканируют государственные базы и выявляют риски соответствия, чтобы специалисты могли сосредоточиться на решениях, а не сборе данных.