Надежность для предприятия-агента

Автономные агенты внедряют недетерминистские схемы выполнения, принципиально отличающиеся от традиционной автоматизации Salesforce. В то время как Salesforce Flow и Apex следуют предсказуемым путям, которые дают повторяемые результаты в контролируемых условиях, агенты рассуждают о проблемах динамично. Например, один вопрос, заданный дважды, может использовать разные пути выполнения, использовать разные ресурсы и получать разные результаты. Этот недетерминизм создает проблемы надежности, которые не решаются традиционными методами тестирования и мониторинга.

Режимы сбоев надежности агента категорически отличаются от сбоев Salesforce Flow или Apex. Службы вывода широкоязычной модели (LLM) представляют внешние зависимости с характеристиками доступности отдельно от Salesforce Platform. Агенты создают ответы, которые иногда нарушают ожидаемую структуру, несмотря на оперативные инструкции. Подготовка контекста агента использует контролирующие ограничения непредсказуемо. Неограниченное извлечение данных влияет на агентов сильнее, поскольку агенты могут запрашивать неограниченный контекст, в то время как детерминистские запросы имеют четкий контроль объема.

Архитектура надежного агента требует многоуровневой резервной цепочки, которая изящно деградирует – от сложных агентов до более простых агентов с ограниченным контекстом, до детерминистских механизмов правил и, наконец, до передачи человека посредством мультиканала. События платформы поддерживают долговременные очереди повторных попыток со схемами контрольных точек, что позволяет возобновить неудачные бизнес-правила с последнего успешного этапа. Автоматические выключатели отслеживают работоспособность службы LLM в кэше платформы для статуса в реальном времени, поддерживаемые типами настраиваемых метаданных для порогов и конфигурации, перенаправляя в резервные схемы после последовательных сбоев. Мониторинг требует отслеживания уровня успеха разговора, среднего времени между сбоями (MTBF), среднего времени до восстановления (MTTR) и точности заземления. Наблюдаемость Agentforce предоставляет трассировки сеансов, показатели состояния и задержки, а также коэффициенты расширения и отклонения, но вам нужно будет самостоятельно измерить показатели надежности, например, MTBF, MTTR и точность заземления.

Этот документ охватывает изменения, происходящие при нахождении агентов на фотографии. Для получения базовых схем надежности, применимых ко всем решениям Salesforce (проектирование объекта уровня обслуживания (SLO), отказоустойчивость, масштабирование и мониторинг), см. столбец надежности.

Агенты Agentforce выходят из строя по-другому, чем Salesforce Flow или Apex. Понимание этих режимов сбоев и формирует архитектуру надежности.

• Недоступность службы LLM: Конечные точки вывода LLM испытывают периодические скачки задержки или проблемы доступности. Agentforce включена в список отслеживаемых продуктов на Trust.salesforce.com наряду с Analytics и другими службами Salesforce. Однако, детализированные показатели задержки вывода LLM и производительности по запросу там не открываются. Внедрите автоматические выключатели, используя кэш платформы для низкозадержек в режиме реального времени, поддерживаемый типами настраиваемых метаданных для порогов и конфигурации, для отслеживания работоспособности службы LLM. Кэш платформы — это лучшее, что можно сделать, — записи могут быть выселены до их срока действия (TTL) — поэтому сохраняйте состояние открытия/запуска в долговременном магазине, например, настраиваемый объект, а не только кэш. Настройте условие поездки на конечную точку: количество последовательных сбоев (например, пять) или уровень ошибок, преодолевающих порог над скользящим окном. Когда схема сработает, откройте ее и перенаправьте в резервные схемы, например, более простые напоминания, кэшированные ответы или человеческую передачу, пока успешный тестовый запрос не укажет на восстановление.
• Сбои проверки ответа: Агенты иногда создают ответы, нарушающие ожидаемую структуру, несмотря на оперативные инструкции. Агент иногда возвращает неправильное JSON, пропускает обязательные поля или добавляет непредвиденные типы данных. Кэш платформы может хранить проверенные схемы ответов, включающие быструю проверку. При неудачной проверке повторите попытку с помощью уточненных напоминаний, включительно с ошибкой проверки и примером правильной структуры. Установите максимальное количество попыток (3-5), чтобы предотвратить бесконечные циклы повторов.
• Обнаружение галлюцинаций: Если данные заземления неполные, агенты выдают правдоподобную, но некорректную информацию. В отличие от детерминистских запросов, возвращающих «не найдено», агенты заполняют пробелы выводом. Контрольный журнал слоя Einstein Trust регистрирует каждое напоминание, замаскированное напоминание, ответ, результат обнаружения токсичности и отзывы пользователей для проверки пост-специального управления. Однако, он не собирает пошаговые следы рассуждений. Для пошагового сбора рассуждений используйте отслеживание сеансов Agentforce, которое записывает выполнения механизма рассуждений. Требуйте, чтобы агенты ссылались на источники извлечения (RAG) Data 360 (ранее Data Cloud). Заявки агента перекрестной ссылки на извлеченные источники для обнаружения фактических отклонений перед выполнением действия. Встроенная проверка добавляет небольшую задержку, поскольку выполняется по источникам, уже находящимся в контексте. Чек, требующий отдельной поездки в оба конца, например, вызов второй модели или внешняя услуга, стоит дороже. Зарезервируйте эти проверки для высокоэффективных записей, включительно с финансовыми обновлениями или обновлениями заказа, и выполните их асинхронно во время разговора в реальном времени.
• Скачки ограничения регулятора: Подготовка контекста агента использует запросы языка запросов объекта Salesforce (SOQL), процессорное время и память кучи непредсказуемо на основе потока разговора. Proactive Monitoring - это служба права Signature Success (ранее Signature Support) в плане Salesforce Success, где Salesforce активно отслеживает организации-клиенты. Proactive Monitoring не является настраиваемым предупреждением самообслуживания, доступным всем клиентам. Для мониторинга лимитов управляющих самообслуживанием используйте Scale Center для определения ресурсоемких операций агентов, приближающихся к ограничениям. Внедрите пагинацию в действия агента по извлечению больших коллекций записей. Для часто используемых справочных данных используйте кэш платформы.
• Перекос данных в контексте агента: Агенты, извлекающие контекст для организаций с более чем 10 000 возможностей или обращений с сопоставимо большими журналами действий, сталкиваются с теми же проблемами искажения данных, что и пакет Apex. В отличие от детерминистских запросов, где вы управляете областью, рассуждения агента могут непредсказуемо запрашивать «всю историю». Чтобы предотвратить это, создайте действия агента с разумными жесткими ограничениями (например, ограничение порядка 200 детей на одного родителя) и реализуйте стратегии выборки при превышении ограничений. Ограничение ограничивает объем данных, поступающих в контекст агента. В сочетании с выборочными индексированными фильтрами сам запрос остается дешевым, поскольку неиндексированный фильтр или агрегация на искаженном родительском объекте сканирует полный дочерний набор до применения ограничения.

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

• Основной агент с полным контекстом: Сложный агент с полным заземлением Data 360, обширным журналом разговоров и сложной аргументацией. Высочайшее качество, но самый ресурсоемкий и самый высокий риск сбоев.
• Основной агент с сокращенным контекстом: Более простой агент, использующий сокращенный контекст (например, последние 30 дней по сравнению со всей историей, лучшие 5 результатов векторного поиска по сравнению с лучшими 20). Меньший контекст означает меньшее количество маркеров, более быстрый вывод и меньшую вероятность сбоя, но только если сокращенный контекст по-прежнему охватывает нужные задачи данные.
• Механизм детерминистского правила: Традиционная логика Salesforce Flow или Apex, обрабатывающая распространенные сценарии при неудачном рассуждении агента. Правила не могут адаптироваться к новым ситуациям, но они надежно обрабатывают известные схемы. Агент проверки заказа возвращается к стандартным правилам проверки, в то время как агент по оценке интересов возвращается к расчету рейтингов на основе правил.
• Передача через мультиканал: Маршрутизация в очередь, когда автоматические параметры исчерпаны. Настройте маршрутизацию на основе навыков, чтобы убедиться, что расширения достигают соответствующего уровня знаний. Передайте полный контекст разговора, включительно с попытками стратегий, любыми оценками надежности, вычисляемыми для агента, и причинами сбоев, чтобы включить эффективное вмешательство человека.

Внедрите резервную логику в оркестрацию Salesforce Flow или Apex, запущенную событиями платформы. Каждый уровень регистрирует успешную стратегию, создавая видимость схем сбоев и резервной эффективности.

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

• Выполнение агентом контрольной точки: Многоэтапные бизнес-процессы агента публикуют события контрольной точки после каждого успешного этапа. Агент обработки контрактов завершает извлечение документа, публикует событие ContractParsed с извлеченными данными, потом переходит к анализу условий. Если анализ условия не удается, повторите событие ContractParsed для возобновления из извлеченных данных без повторного анализа. Это работает, когда полезные данные контрольной точки несут эти данные, а подписчик является идемпотентным, поскольку повтор передает события, а не возобновляет бизнес-правило на середине этапа. Сохраните состояние контрольной точки в поле события, включительно с кодом корреляции, завершенными этапами и состоянием, необходимым для продолжения.
• Очередь повтора с экспоненциальным отступлением: Неудачные запросы агентов публикуются в событии AgentRetryRequested с количеством повторных попыток в полезных данных. Процессы подписчика на события повторяются с экспоненциальными задержками обратной передачи (например, 30 сек, 2 мин, 8 мин, 30 мин). После максимального количества попыток (обычно 5) перенаправьте в очередь мертвых букв и операции предупреждения. Массовые события платформы сохраняют 72-часовое окно воспроизведения. Используйте тип массового события для очередей повторных попыток агента, чтобы подписчики могли наверстать упущенное после окон обслуживания организации или простоя развертывания. Стандартные события платформы хранятся только 24 часа.
• Оркестрация под управлением события: Создайте бизнес-правила агента в виде слабо связанных цепочек событий. Создание интереса публикует LeadCreated. Агент по оценке интересов подписывается, оценивает и публикует LeadScored. Агент маршрутизации интересов подписывается на LeadScored и назначается соответствующей очереди. Каждый агент может ошибиться и повторить попытку самостоятельно. Ошибка отдельного агента не блокирует весь бизнес-правило - дальнейший процесс агентов при восстановлении зависимостей.
• Отслеживание кода корреляции: Добавьте код корреляции в качестве настраиваемого поля во все полезные данные связанных событий. Воспроизводите события посредством Public/Sub API по replayId, непрозрачному, не смежному идентификатору, для восстановления журнала бизнес-правил в 72-часовом окне сохранности. Чтобы включить отладку на основе кода корреляции, внедрите схему со стороны подписчика, регистрирующую входящие события с помощью replayId и кода корреляции в настраиваемом объекте, включив отслеживание перекрестных событий. Эта схема регистрации является настраиваемой реализацией, созданной самостоятельно, а не нативной возможностью запроса платформы.

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

• Пакетный Apex для пакетных операций агента: Агент, анализирующий записи 1,000+, выигрывает от предоставления пакетным Apex 200 запросов SOQL, 150 операторов DML (до 10 000 строк DML) и 60 000 миллисекунд (60 секунд) процессорного времени на метод выполнения. Агент по оценке интересов, обрабатывающий ночной импорт интересов. Анализ мнений по обращениям в архивных обращениях. Прогнозирование возможностей с анализом завершенных ожидаемых продаж.
• Цепочки очереди для многоэтапных бизнес-правил: Сложные бизнес-процессы агента, требующие нескольких внешних вызовов API, анализа больших наборов данных или увеличения времени обработки, используют цепочки Apex в очереди. Каждое задание в очереди получает 60 процессоров и 12 МБ кучи. Цепочка до следующей очереди для бизнес-правил, превышающих ограничения для одного задания. Отслеживайте прогресс в настраиваемых объектах, чтобы неудачное задание могло возобновиться с последнего выполненного этапа.
• @future для простых асинхронных передач: Облегченные операции агента, например, отправка уведомлений, вход во внешние системы или несрочные обновления, используют методы @future. Схема «огонь и забвение» подходит, когда бизнес-правилу не нужны результаты обратно и он может перенести сбой.

Отслеживайте возможности обработки асинхронизации посредством страницы заданий Apex (Настройка → Задания Apex) и очереди Flex Apex. Не более 5 параллельных пакетных заданий ограничивают параллельную обработку агента; дополнительные задания в очереди Flex Apex, которая содержит не более 100 заданий в статусе «Удержание». Все типы асинхронных Apex, пакетные, будущие, очередные и запланированные Apex, используют одно единственное ежедневное ограничение (DailyAsyncApexExecutions) для асинхронных Apex: тем больше, чем в 250 000 или 200 раз больше лицензий пользователя. При выполнении высокочастотного опроса агентов или повторной попытки создания очередей подписчиков, очереди могут быстро исчерпать эту квоту. Во избежание этого, пакетируйте или закройте эти очереди, чтобы не выходить за рамки ограничения, которое применяется по всей организации во всех типах асинхронных Apex, а не как отдельное распределение только для очереди. Предупреждение о приближении потребления к этим ограничениям, чтобы рабочие группы могли активно управлять производительностью.

Проверьте устойчивость агента перед производством посредством стратегий тестирования, которые устраняют недетерминистское поведение.

• Загрузочное тестирование в безопасной среде Full Copy Sandbox: Протестируйте производительность агента при загрузке в масштабах производства, используя полные объемы данных. Имитация параллельных разговоров, соответствующих пиковому спросу. Измерьте задержку р95 и р99, определив ухудшение производительности при стрессе. Проверьте, держится ли управляющее ограничение потребления ниже пороговых значений при максимальной нагрузке. Тестирование загрузки в безопасной среде Partial Copy Sandbox с сокращенными данными предоставляет обманчивую уверенность, поскольку объем данных напрямую влияет на производительность агента. Прежде чем выполнить эти тесты, получите одобрение Salesforce (не менее чем за неделю до запросов на тестирование производительности). Неутвержденное тестирование может быть заблокировано.
• Впрыск ошибки: Умышленно введите ошибки проверки механизмов восстановления. Имитация ошибок вывода LLM в сервисном слое, который отслеживает автоматический выключатель, для проверки активации выключателя. Внедрите исключения SOQL для тестирования обработки ошибок. Повреждение ответов агента на логику проверки теста. Введите искажения данных (организации с дочерними организациями 10000+) для проверки логики пагинации. Установите агрессивное время ожидания для тестирования обработки времени ожидания и повторной попытки стратегий.
• Инженерный хаос: Случайным образом отключите подписчиков события платформы для тестирования восстановления повтора. Завершите асинхронные задания в середине выполнения для тестирования перезапуска контрольной точки. Введите переменную задержку во внешние системы для тестирования стратегий постепенного истечения срока действия. Эксперименты хаоса проверяют устойчивость в реалистичных сочетаниях сбоев. Запланируйте регулярные дни хаоса в средах этапирования, поддерживая устойчивость по мере развития агентов.
• Долговременные испытания на стабильность: Выполняйте загруженность агента непрерывно в течение 72+ часов, отслеживая зависимые от времени ошибки. Накопление ошибок и постепенное ухудшение производительности всплывают только при устойчивой работе. Отслеживайте тенденции времени процессора для определения постепенной деградации в динамике.

Определите индикаторы уровня обслуживания (SLI), включающие измерение надежности цели. Установите ООД до создания агентов, а не после производственных сбоев.

• Уровень успеха разговора: Процент завершенных разговоров агента без ошибок или истечения времени ожидания. Изящная передача человеку считается успехом, а не неудачей — эскалация по замыслу является последним резервным эшелоном. Считайте неудачные или непреднамеренные расширения по сравнению с показателем — это полезный сигнал надежности, но несовершенный косвенный признак взаимодействия пользователя, поскольку вежливое подтверждение может скрыть нерешенную проблему. Отслеживайте отдельно по типу агента и сценарию использования, поскольку критерии успеха оценки интересов отличаются от проверки контракта. Предупреждение о снижении уровня успеха ниже SLO (обычно 95-99%).
• Среднее время между сбоями (MTBF): Среднее время работы между сбоями агента. Более высокий MTBF указывает на меньшее количество сбоев и лучшую надежность. Вычисляются как общее количество рабочих часов агента, разделенное на количество отказов. Отслеживайте каждый тип агента для определения наименее надежных агентов, требующих инвестиций оптимизации.
• Среднее время восстановления (MTTR): Среднее время от обнаружения сбоя до восстановления обслуживания. Автоматическое восстановление посредством повтора события платформы и автоматических выключателей восстанавливает обслуживание намного быстрее и с меньшим количеством ошибок вручную, чем ручное вмешательство. Снижение MTTR уменьшает влияние бизнеса на инцидент.
• Точность заземления: Процент фактически корректных ответов агента на основе проверки исходных данных. Примеры ответов случайных агентов для проверки претензий по источникам Data 360. Точность заземления ниже 95% указывает на проблемы галлюцинаций, требующие быстрой настройки или лучшего контекстного поиска.
• Пробелы повтора события платформы: Количество пропущенных или не доставленных событий, например, подписчик в автономном режиме за пределами окна сохранности. Zero gaps - это положительный сигнал здоровой архитектуры, управляемой событиями. Пробелы обозначают проблемы подписчика, ошибки публикации событий или ограничения нагрузки. Отслеживайте эти пробелы с помощью схемы регистрации со стороны подписчика, описанной выше, и записывайте replayId и код корреляции каждого события в настраиваемый объект.

Надежные агенты получаются от проектирования на случай сбоя заранее, определяя SLI/SLO, обработку контекста с ограничением управления и многоуровневые резервные цепочки перед созданием, а не прикручивая их потом. Автоматические выключатели слоя и логика на основе события платформы попробуйте и контрольная точка, чтобы бизнес-процессы восстанавливались автоматически, с человеческой передачей в качестве последнего средства. Проверьте проектирование посредством систематической нагрузки, инъекции ошибки и тестирования хаоса, потом продолжайте отслеживать одинаковые SLI в производстве, чтобы убедиться, что они сохраняются в динамике.

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

Опубликуйте отзыв о инфраструктуре с хорошей архитектурой.