Определение агентской и традиционной автоматизации бизнес-правил

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

Agentforce объединяет Einstein Trust Layer, Reasoning Engine, Agent Script, Flow, Apex и Data 360 в единую объединенную платформу. Эта комбинация обрабатывает все, от простой автоматизации триггеров записи до сложной мультиагентной оркестрации в голосовом режиме, зрении, документах и телеметрии в реальном времени. MuleSoft расширяет эту платформу с помощью ткани MuleSoft, управления и межсистемной оркестрации, необходимой для подключения агентских бизнес-правил в рамках предприятия. Эти возможности Agentforce Operations (ранее Agentforce Supply Chain) применяет к конкретным требованиям операционных и производственных процессов.

Это руководство представляет инфраструктуру плотности оркестрации и рекомендации по принятию обоснованных решений в этом ассортименте продуктов. Инфраструктура предоставляет архитекторам повторяемый подход для выбора правильных инструментов и схем с помощью уровней плотности для интеллектуальных способов использования автоматизации на Salesforce Platform.

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

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

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

  • Используйте Agentforce Grid для сценариев использования пакетного вывода с низкой или средней сложностью оркестрации. Эта схема использует генеративные рассуждения одного оборота для классификации, оценки или резюмирования данных в большом объеме записей CRM, обеспечивая высокопроизводительное выполнение с немедленной возможностью аудита.

  • Используйте Agentforce с Agent Script для задач с неопределёнными целями, но точный путь выполнения не может быть задан во время проектирования. Примените эту схему к требованиям, требующим аргументации посредством пошагового детерминизма, чтобы обеспечить предсказуемые и отслеживаемые результаты.

  • Используйте операции Agentforce для оптимизации и автоматизации бизнес-процессов с помощью управления на основе искусственного интеллекта для бизнес-процессов цепочки поставок.

• Избегайте применения агентских бизнес-правил к сценариям использования с низкой плотностью оркестрации. Оцените компромиссы между традиционной и агентурной автоматизацией на наличие функциональных и нефункциональных требований. Традиционная автоматизация может предложить масштаб, надежность и производительность, необходимые для вашего сценария использования.

• Применить гибридный подход к автоматизации Agent Automation, сочетающий Agentforce и традиционную автоматизацию с Flows и Apex, если этот синергизм дает больше преимуществ, чем изолированное использование агентской или традиционной автоматизации.

Salesforce sObject традиционно является основной точкой входа для автоматизации записи. Система выполняет логику на основе правил, начиная сразу после события DML (например, insert, update или delete). Чтобы выбрать между инструментами эффективной автоматизации записи, мы ввели Плотность автоматизации в качестве средства измерения сложности системы, учитывая количество автоматизации, объем записи и разрастание зависимости. Традиционная автоматизация ограничена большой предварительной работой, необходимой для добавления данных в структурированную, соответствующую схеме и основанную на правилах конструкцию.

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

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

Плотность оркестрации — это мера сложности агентского бизнес-правила. Плотность оркестрации определяется тремя факторами: путь выполнения, сложность цели и сочетание модальностей. Плотность автоматизации измеряет физическую сложность правил и объема системы, а плотность оркестрации измеряет сложность аргументации пути агента к цели. Используйте составную плотность оркестрации для оценки требований к дизайну и соотнесения с архитектурным стандартом.

• Путь выполнения: Степень, в которой бизнес-правило может быть полностью объемным и определенным во время проектирования. Полностью определенный бизнес-правило означает, что бизнес-правило определяет каждое ответвление и результат, приводящий к предопределенному пути выполнения. Неуказанный бизнес-правило имеет путь, который может появиться во время выполнения посредством аргументации против контекстных данных и инструкций.
• Сложность цели: Количество разных результатов, точек решения и вариантов пути, которые бизнес-правило должно решить во время выполнения. Бизнес-правило низкой сложности обрабатывает одну содержащуюся задачу с предопределенным результатом, в то время как цель высокой сложности охватывает несколько этапов с конкурирующими или конфликтующими целями с краевыми обращениями, которые невозможно предвидеть в проектное время.
• Сочетание модальностей: Диапазон типов ввода, которые должен обработать бизнес-правило, и форм вывода, которые оно должно создать. Сочетание низких модальностей считывает стандартные поля CRM и производит обновления записей. Средняя модальность использует сочетание структурированных полей CRM и статических неструктурированных данных, например, тексты сообщений эл. почты или транскрипты обращений, для создания обновлений записей. Высокая модальность использует динамические потоки в реальном времени, например, аудио или телеметрию в реальном времени, и создает мультимодальные выводы в нескольких внешних системах.

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

Для частичных или неуказанных путей продолжайте оценивать сложность цели. Если сложность цели четко определена, но определенные узлы на пути нуждаются в вероятностных оценках, рекомендуем вызвать агентов из Flow или Apex для удовлетворения определенной локализованной потребности. Вместо этого, если этапы пути выполнения требуют одного или нескольких требований на основе искусственного интеллекта в большом наборе записей, обратите внимание на Agentforce Grid. Сетка поддерживает многоэтапные бизнес-правила на основе листа в нескольких столбцах искусственного интеллекта или агента. Он лучше всего подходит для пакетного, ориентированного на строку выполнения. Этот метод обеспечивает высокую производительность и аудит бизнес-правил, вызывая вероятностные рассуждения только там, где путь не может быть предопределен.

С увеличением сложности цели с конкурирующими измерениями (например, определение выплаты по страховому требованию вместе с обнаружением мошенничества, соответствием политикам и качеством обслуживания клиентов) и неопределенными путями выполнения, обратитесь к Agentforce с Agent Script для получения пошагового детерминизма в автоматизации. Для межкорпоративных способов использования, связанных с системой Salesforce и сторонними системами, используйте MuleSoft Fabric и Agent Broker.

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

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

• Традиционная автоматизация (низкая плотность оркестрации): Используйте традиционную автоматизацию, если процесс запускается изменением записи, данные структурированы, логика основана на правилах и предопределена, а результат должен быть предсказуемым (например, расчет стандартной цены или создание автоматических задач).
• Agentforce Grid (низкая и средняя плотность оркестрации): Используйте Agentforce Grid, когда нужно обработать пакетные задачи на основе искусственного интеллекта в существующих записях (например, суммируйте последние 50 обращений для каждой организации в этом списке, вычислите рейтинг настроения и сохраните рейтинг в поле обращения).
• Гибридная оркестрация (дополненная автоматизация высокого порядка): Используйте гибридную оркестрацию при автоматизации сложного сквозного бизнес-процесса (например, обработка претензий или адаптация), требующего возможностей планирования на основе искусственного интеллекта, но целостности транзакций Flow и Apex.
• Сценарий Agentforce Agent Script (высоконамеренная сложность): Используйте сценарий агента, если точка входа неструктурирована (например, чат, электронная почта и голосовой режим), а разрешение требует разговора или возможности обработки неоднозначных запросов пользователей.

Данная таблица содержит общие наиболее подходящие рекомендации для разных способов использования.

Задержка

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

Стоимость

Стоимость обоснования агентского бизнес-правила должна быть обоснована бизнес-значением результата. Для массовых задач с низкой плотностью оркестрации при наличии детерминистского пути традиционная автоматизация или Agentforce Grid может быть более экономичной, чем комплексный агентский бизнес-процесс. Убедитесь, что конструкция учитывает правильную схему повтора с четкими ограничениями максимального количества попыток и брекерами. Это ограждение ограничивает дополнительный риск перерасхода, связанный с пакетной обработкой.

Правительственные ограничения

Оцените массовые агентские бизнес-правила по ежедневным ограничениям платформы для асинхронного выполнения. Пакетные операции Agentforce Grid выполняются в соответствии со стандартными ограничениями транзакций платформы. Для автоматизации, связанной с объектами Salesforce, учитывайте общее ежедневное количество операций DML, поскольку Salesforce внедряет управление общедоступными ресурсами в среде с несколькими клиентами и ограничения для управляющих, чтобы предотвратить монополизацию общедоступных ресурсов устаревшей автоматизацией.

Слышимость и соответствие

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

Расширение

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

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

В указанном пути выполнения в узлах, где требуется аргументация, начните встраивать агента. Следуйте рекомендациям по созданию агентов в Agentforce. Избегайте пакетирования большого количества субагентов (ранее «темы») и никогда не вздувайте инструкции. Агенты, развернутые в сценариях использования автоматизации, могут позволить себе быть экономными, поскольку они не являются единственным интерфейсом. Выберите правильный примитив для цепочки. Схема оркестрации (делегирования) имеет более жесткий контроль над последовательностью выполнения и может делегировать подзадачи специалистам. Избегайте хореографических (передаточных) шаблонов. Если вам нужно внедрить дизайн передачи, предоставьте агенту-получателю цель, контекст и состояние, чтобы он мог оптимизировать глобальные, а не локальные задачи.

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

Наличие более одного действия (и разных конструкций вывода) для выполнения одной задачи уменьшает возможность агента рассуждать или выбирать подходящий инструмент для задания. Из-за этого агент может пропустить нюансы. Накладывающиеся определения действий чреваты неправильной классификацией. Убедитесь, что библиотека действий проверена, версирована и соответствует области «Субагент (ранее тема)».

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

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

Об авторе

Арвинд Паланисвами — архитектор программного обеспечения в офисе главного архитектора группы, работающей с хорошей архитектурой. Он любит оформлять сложные системы в простейших формах, используя первые принципы. Он понимает инженерное дело, операции и бизнес на основе многолетнего опыта и образования MS/MBA(Kellogg).