Создание или покупка в Agentforce: готовые действия, Flow, Apex и API

Краткое изложение

Действия (Actions) – это момент, когда агент переходит от разговоров к реальным делам, и именно здесь сосредоточены основные риски и затраты на обслуживание. Существует четыре способа реализации: стандартные действия, Flow, Apex и внешние сервисы через API. Выбор между ними — это не вопрос возможностей (почти любое действие можно реализовать любым способом), а вопрос того, кто будет поддерживать, насколько быстро можно вносить изменения и как осуществлять тестирование.

Рекомендуемый порядок выбора — сверху вниз: начинаем со стандартного действия, переходим к Flow при необходимости бизнес-логики, к Apex, когда сложность становится реальной, и к внешним сервисам, когда источник истины находится вне Salesforce. Каждое смещение вниз по этой шкале увеличивает затраты на обслуживание и, следовательно, требует обоснования.

Таблица принятия решений

Первое правило: описание до реализации

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

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

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

Когда использовать Flow, а когда Apex

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

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

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

Действия с внешними системами

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

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

Задержка (Latency) — это не только технический, но и пользовательский фактор. Вызов, занимающий несколько секунд, приемлем в чате, если агент сообщает, что проверяет информацию; вызов, который длится дольше, требует асинхронного подхода — агент подтверждает получение и обновляет статус, когда приходит ответ.

Шаблоны обработки ошибок интеграции подробно описаны в статье Обработка ошибок интеграции в Salesforce.

Разрешения на уровне действия

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

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

Когда разделять действие

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

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

Планирование точек остановки между частями подробно описано в Human-in-the-Loop в Agentforce.

Сценарий: организация, перешедшая с Apex обратно на Flow

Компания, предоставляющая услуги, разработала шесть действий (Actions) на Apex в рамках пилотного проекта, полагая, что это обеспечит полный контроль. В течение двух месяцев выяснилось, что четыре из них трижды меняли логику – не из-за ошибок, а потому что бизнес-правила выявлялись в процессе использования. Каждое изменение требовало разработчика, тестирования и цикла развертывания продолжительностью в несколько дней.

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

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

Риски и превентивные меры

Метрики для действий

Если требуется сопровождение при планировании слоя Actions и его адаптации к существующей архитектуре, услуги Agentforce и AI — это практический путь для дальнейших действий.

Чек-лист для каждого действия

• ☐ Написано описание с указанием "что", "когда да" и "когда нет"
• ☐ Параметры минимальны и имеют определенный тип
• ☐ Выбрана максимально высокая реализация, достаточная для нужд
• ☐ Для действия определено отдельное разрешение
• ☐ Валидация находится внутри действия, а не только в инструкциях
• ☐ Определена идемпотентность действия и политика повторных попыток (Retry)
• ☐ Установлено максимальное время ожидания и сообщение об ошибке для пользователя
• ☐ Разделены действия с множеством решений
• ☐ Существует тестовый сценарий для сбоя, а не только для успеха