Оптимизация ресурсов и затрат для предприятия-агента
Автономные агенты потребляют ресурсы Salesforce иначе, чем детерминистская автоматизация. Загруженность агентов непредсказуема и непрерывна, а не фиксирована и связана с транзакциями. Тезис «Ценность на затраты» компонента «Оптимизация ресурсов и затрат» переносится непосредственно на предприятие-агент. Эффективность ресурса означает использование уже оплаченных мощностей, а оптимизация расходов означает намеренное направление расходов на автономные возможности, которые приносят прибыль. Агенты изменяют форму обоих. Эффективное проектирование агентов позволяет контролировать потребление, а выбор модели ценообразования, моделирование общей стоимости владения (TCO) и финансовое управление позволяют поддерживать соответствие расходов стоимости. Этот документ рассматривает эффективность ресурса и оптимизацию затрат как одно решение, поскольку для агентов это два представления одной цели.
Агенты изменяют предсказуемость потребления. Традиционный процесс Apex работает над известным набором записей с известной стоимостью ресурса. Агент действует диалогово, и один разговор может выполнить десятки действий, как мотивирует агент посредством задачи. Каждое действие использует контролирующие ограничения внутри собственной транзакции, а не накапливает их в разговоре. Подготовка контекста для одного хода может запросить 200 записей или 20 000, в зависимости от того, что спрашивает пользователь. Расход API ускоряется, поскольку агенты могут действовать автономно, а активные, исходящие и запланированные агенты действуют непрерывно, а не только во время транзакции пользователя. Эта непредсказуемость объясняет, почему управление ресурсами агента должно защищаться по замыслу, а не настраиваться после резкого роста потребления.
Стоимость меняется не меньше. Автономные агенты вводят ценообразование на основе потребления, отличающееся от традиционного лицензирования мест. Agentforce предлагает две модели ценообразования на основе потребления - Flex Credits и Per-Conversation. Каждое развертывание агента выбирает одну из этих моделей. Организация использует одну модель потребления за раз. , но надстройка «На пользователя», предлагаемая на пользователя в месяц для неучтенного использования, может прослойка рядом с моделью потребления, чтобы агенты, ориентированные на клиента, выполняли Flex Credits или Per-Conversation, пока сотрудники используют неучтенные лицензии. Data 360 активирует заземление агента посредством векторного поиска и извлечения и использует нагрузку обработки данных, в то время как MuleSoft включает интеграции агента, использующие нагрузку API. Эти переменные затраты шкалируются с использованием агентов, что создает схему инвестиций, требующую финансового управления, созданного для изменчивости, а не для фиксированной годовой подписки.
Решения, созданные для бизнес-ценности с оптимизированной стоимостью на предприятии-агенте, поддерживают эффективность потребления агента посредством действий, обрабатывающих записи в пакете, дисциплинированных контекстных окон и кэширования. Они также намеренно направляют расходы посредством правильной модели ценообразования, полного моделирования ТСО и постоянного мониторинга затрат относительно бизнес-результатов. Без этого выравнивания развертывания агентов накапливают стоимость, не демонстрируя пропорциональное значение, и агент, причины которого в неограниченном цикле могут сжечь кредиты быстрее, чем может вмешаться человеческий надзор. Такая же работа по повышению эффективности, которая удерживает агента в пределах управляющего, удерживает его в пределах кредитного бюджета, что является основным тезисом, выраженным в агентских терминах.
Этот документ охватывает изменения, происходящие при нахождении агентов на фотографии. Базовые схемы ресурса и оптимизации затрат, применимые к каждому решению Salesforce, включая оптимизацию производительности, контролирующие ограничения, анализ TCO и лицензионную дисциплину, см. в компоненте «Оптимизация ресурсов и затрат». Управление агентами и человеческий надзор подключаются к компонентам Traft и Fairness, которые охватывают компоненты программы, поддерживающие безопасность и подотчетность автономного поведения.
Расход ресурсов агента следует той же механике платформы, что и Flow или Apex, но его непредсказуемый, управляемый разговорами вызов затрудняет прогнозирование потребления и, следовательно, требует защитных схем. Ваши обязанности оптимизации охватывают бюджетирование с ограничением управляющего в цепочках действий, потребление API, задержку ответа, эффективность заземления Data 360, управление контекстным окном и компонованный дизайн, позволяющий агентам масштабировать без дублирования. Каждая ответственность является решением по стоимости до технической, поскольку агенты повторяют неэффективность в каждом разговоре.
Агенты вызывают действия, запускающие Apex, потоки и интеграции. Один разговор может выполнить десятки действий в качестве причины агента посредством сложной задачи. Основополагающая дисциплина такая же, как и в любом решении Salesforce, но непредсказуемая схема вызова повышает ставки. Создайте действия для принятия коллекций, чтобы агент, обновляющий 50 обращений, вызывал одно действие, а не 50 отдельных вызовов. Одно действие, работающее над коллекцией записей, использует гораздо меньше запросов Salesforce Object Query Language (SOQL) и операций DML для одной работы. Управляйте бюджетом SOQL в цепочках действий намеренно, поскольку бизнес-правило, вызывающее от 10 до 15 действий, может приблизиться или превысить синхронное ограничение 100 запросов, когда каждое действие выполняет несколько собственных запросов. Используйте запросы взаимосвязи для извлечения родительских и дочерних данных в одном операторе и ссылки на данные, кэшированные в кэше платформы, в действиях в одном разговоре. Эти две практики хранят многофакторную цепочку в бюджете.
Переместите операции агента, превышающие синхронные ограничения, в Queable или Batch Apex, где асинхронный контекст удваивает заголовок SOQL и процессора, доступный для работы. Крупные аналитические операции, например, оценка 1 000 интересов или анализ настроения в архивных обращениях, относятся к асинхронной обработке, а не блокировке разговора. Сам вывод широкоязычной модели происходит вне системы Salesforce и потребляет Flex Credits, а не процессорное время Apex, поэтому бюджет профилированного процессора расходуется логикой действий, трансформациями данных и интеграциями, запускаемыми агентом. Сценарии искажения данных, когда родительские записи связаны с тысячами дочерних записей, заслуживают особого внимания агентов. Уязвимость возникает из-за того, что агент может запросить «всю историю» для организации с десятками тысяч связанных записей так, как никогда не запросил бы детерминистский запрос. Разработайте действия с жесткими ограничениями дочерних записей и пагинацией и примените выборку, когда объемы превышают пороговое значение искажения данных. Эти ограничения предотвращают превращение непредсказуемого запроса в неограниченный. Отслеживание сеансов Agentforce определяет, какие действия потребляют избыточные запросы на уровне сеанса, а Scale Center отслеживает общую производительность транзакций Apex и состояние организации.
Архитектуры агентов используют API быстрее, чем бизнес-правила, управляемые пользователем, поскольку агенты работают автономно и, для активных или запланированных агентов, непрерывно. Способ отображения агента определяет способ уменьшения нагрузки API. Агенты, вызванные посредством REST API, расходуют один вызов на ход разговора. Агенты, встроенные на страницы Lightning посредством стандартных компонентов, не расходуют вызов API на взаимодействие, хотя их стоимость все равно измеряется в кредитах или разговорах выбранной модели ценообразования. Настраиваемые веб-компоненты Lightning, выполняющие прямые вызовы REST, потребляют нагрузку API. Компоненты, созданные на основе проводных адаптеров Lightning Data Service, этого не делают, поскольку Lightning Data Service обслуживается из общего клиентского кэша, а не выдает вызов API. Отслеживайте потребление в мониторинге событий во время пробной версии, чтобы понять фактическое использование перед полным развертыванием.
Шаблоны, управляемые событиями, являются крупнейшим рычагом на расточительное потребление API агентом. Публикация события платформы, когда условие требует вмешательства агента, позволяет избежать запланированного опроса, использующего вызовы API, независимо от того, есть ли работа, и агент, подписывающийся на события сбора данных об изменении, поддерживает текущий контекст без ежедневных вызовов опроса, которые в противном случае выполняет внешний оркестратор. Логика «значение на стоимость» прямая: Опрос, который не обнаруживает работы, - это нагрузка, потраченная просто так, а событие, запускающее только реальные изменения, - это нагрузка, потраченная только на реальную работу. Создание с дополненным извлечением добавляет собственное потребление, поскольку каждый векторный поиск по Data 360 использует вычисления, поэтому задайте ограничения извлечения для возврата только результатов, фактически используемых агентом.
Задержка для хода агента - это сумма времени вывода LLM, времени выполнения действия, времени запроса Data 360 и времени интеграции, когда эти этапы выполняются последовательно. В противном случае, это самое длинное параллельное ответвление плюс все последовательные этапы. Задержка - это проблема стоимости, а также проблема взаимодействия, поскольку медленное действие дольше удерживает ресурсы открытыми, а разочарованный пользователь начинает больше разговоров, чем решенный. Более короткие напоминания создают более быстрые ответы, поэтому удалите устные инструкции, избыточные примеры и ненужный контекст. Выборочный контекст улучшает как задержку, так и качество ответов, где исчерпывающий контекстный дамп только добавляет шума. Быстро поддерживайте действия посредством выборочного SOQL для индексированных полей, пакетирования и кэшированных справочных данных, поскольку 3-секундное действие становится препятствием, независимо от скорости вывода. Проверьте запросы действий с помощью инструмента «План запросов», чтобы определить полные сканирования таблиц, повышающие задержку действий.
Оркестрация Agent Builder может выполнять действия параллельно, если между ними нет зависимостей, например, извлечение сведений об организации и связанных возможностей одновременно занимает столько же времени, сколько медленное из двух, сколько и сумма двух. Для вызовов, распространяющихся на несколько последующих систем, соедините Agentforce с платформой интеграции, например, MuleSoft; агент вызывает одно действие, MuleSoft получает запрос и отправляет параллельные вызовы в базовые системы, потом возвращает один агрегированный ответ. Кэш платформы удаляет вывод и задержку запроса для повторяющихся запросов, а обработка несрочной работы асинхронно, например, анализ длинного документа, позволяет агенту немедленно принять запрос и вернуть результат, когда он будет готов, а не удерживать разговор открытым.
Data 360 предоставляет векторный поиск, который основывает ответы агента в текущих данных, а не только в данных обучения модели, и его эффективность управляет качеством заземления и вычислениями, которые вы используете для его достижения. Разделение на фрагменты, выбор встраивания, фильтрация метаданных и ограничения результатов - самые ценные решения. Разделите Knowledge на семантически значимые сегменты, поскольку слишком маленькие фрагменты заставляют извлекать много вопросов, а слишком большие фрагменты разбавляют актуальность с неактуальным контекстом и раздувают бюджет маркера, переносимый в вывод. Выберите модель встраивания, соответствующую способу фактического запроса агентов, поскольку схожесть ответов на вопросы отличается от классификации документов, и проверьте выбор по репрезентативным запросам. Сочетайте семантическое сходство с фильтрами метаданных, чтобы бизнес-ограничения сохранялись независимо от сходства, например, исключение прекращенных продуктов из рекомендации, независимо от близости соответствия. Установите ограничения для возврата только результатов, используемых агентом. Например, если 5 результатов содержат ответ, извлечение 50 добавляет 45 неиспользованных результатов к полезной нагрузке заземления и бюджету маркера.
Объединенные профили являются ресурсосберегающими, поскольку агент, запрашивающий один объединенный профиль Data 360, извлекает полный контекст клиента в одной операции, а не оркестрирует отдельные запросы по организациям, контактам, возможностям, обращениям и кампаниям для каждого хода. Настройте экземпляры Data 360 в регионах, требуемых нормативными требованиями, чтобы агенты, обрабатывающие данные для данной юрисдикции, запрашивали экземпляр, хранящий в нем личные данные.
Контекстные окна широкоязычной модели содержат конечное количество маркеров, и управление этим бюджетом поддерживает связность долгого разговора, не исчерпав возможности и не увеличивая стоимость каждого вызова вывода. Определяйте приоритеты намеренно, а не произвольно: журнал недавних разговоров имеет наивысший приоритет, критические бизнес-данные, например, текущее состояние записи и полномочия, занимают второе место, а более старый журнал добавляется только при наличии места. После первых нескольких оборотов резюмируйте более ранний разговор в краткий обзор, сохраняющий критические факты, не неся полного дословного журнала. Данная сводка сохраняет преемственность без увеличения бюджета маркера. Храните расширенный контекст в Data 360 или настраиваемых объектах по запросу внешней памяти, а не воспроизводите полный журнал в каждом вызове и возвращайте только важные поля из каждого действия, поскольку ответ, который переносит все 50 полей записи, когда задача нуждается в 8, лучше расходует контекстный бюджет на разговор или запрет.
Создание агентов из многоразовых компонентов уменьшает затраты на разработку и обслуживание. Возможность, созданная один раз и повторно используемая, намного дешевле на протяжении срока действия, чем та же возможность, внедренная повторно и обслуживаемая отдельно для каждого агента. Централизованные библиотеки действий, охватывающие операции записи, утверждения, уведомления и проверку, позволяют группам платформы поддерживать последовательное поведение, безопасность и производительность в каждом потребителе, а также позволяют собирать нового агента из проверенных структурных элементов за несколько дней, а не создавать из настраиваемых действий за несколько недель. Фокусированные агенты-специалисты с четкими границами домена поддерживают более узкий контекст и более четкое поведение, чем один универсальный агент, пытающийся реализовать каждый сценарий, а оркестрация конструктора агентов координирует специалистов, когда задача выходит за пределы доменов. Проверенные шаблоны напоминаний в Конструкторе подсказок собирают проверенные схемы для блокировки, аргументации и форматирования ответов, чтобы качество оставалось последовательным при ускорении разработки, а общедоступная база Knowledge в Data 360 проверяет многих агентов из одного источника, поэтому обновление охватывает каждого потребителя сразу, а не требует изменения каждого агента.
Группы, работающие с предприятиями, все чаще создают несколько агентов вместе, а не создают одиночных монолитных агентов, когда агент оркестратора создает запрос и делегирует его специалистам-субагентам, или специализированных агентов, передающих друг другу в процессе разговора между доменами. Эта композиция поднимает вопросы ресурса и стоимости сверх того, с чем сталкивается один агент, потому что Orchestraation overhead, inter-agent Trust и state handoff - все это составляющие в цепочке, а не удержание в одном действии. Подсказки оркестрации должны быть узкими, ограничиваться классификацией намерений и маршрутизацией, а не предлагать оркестратору также рассуждать об основной задаче, поскольку эта аргументация относится к подагенту с соответствующим контекстом и глубиной цепочки ограничений, если сценарий использования явно не требует более глубокого вложения, чем между оркестраторами. Рассматривайте каждый ответ субагента как ненадежный ввод, как и внешний ответ API. Проверьте ожидаемую форму и соответствие бизнес-правилам, прежде чем действовать в соответствии с ними. Внедрите безопасность поля и общий доступ независимо для каждого действия агента.
Передайте только состояние, необходимое агенту-получателю, используя структурированную полезную нагрузку передачи кодов записей, сводки задач и соответствующих полей, а не пересылку журнала исходных разговоров, чтобы бюджет маркера по всей цепочке оставался управляемым, и сохраняйте состояние сеанса кросс-агента в Data 360 или настраиваемый объект, когда передача должна выжить в отдельных транзакциях. Ограничения применяются к каждому агенту, а не один раз в разговоре, поэтому каждый агент в цепочке составляет собственный бюджет SOQL, DML и процессора. Цепочка оркестранта и трех субагентов расходует каждое из этих ограничений в четыре раза больше, а более глубокие цепи еще больше увеличивают потребление. Одинаковые мотивы умножения стоимости, что делает неограниченную глубину цепочки риском стоимости больше, чем риск ограничения губернатора.
Определите действия оркестранта, когда субагент не справляется, время ожидания истекает или возвращает результат с низкой надежностью, будь то ограниченная попытка, резервный ответ или переход на человека, чтобы время ожидания одного субагента не привело к сбою всей цепочки. Соотнесите запрос по каждому касаемому агенту с общим кодом трассировки, распространенным по полезной нагрузке раздачи, поскольку диагностика того, какой агент в цепочке привел к скачку задержки или стоимости, в противном случае требует ручного корреляции журналов в отдельных сеансах агента.
Неудачные действия и неудачные вызовы дочерних агентов влияют не только на надежность, поскольку каждая повторная попытка может повторно выполнить работу SOQL, DML и процессора, уже потраченную на неудачную попытку, и в цепочке с несколькими агентами эта стоимость добавляется к количеству неудачных агентов в нисходящем направлении. В ценообразовании на основе потребления одни и те же составляющие сбоев расходуют, а также вычисляют: повторное пробное действие использует кредиты в разделе Flex Credits. Создайте логику повтора попытки для учета надежности и стоимости. Прежде чем решить, как реагировать, отличайте переходные ошибки, например, время ожидания выноски или спор о блокировке, от логических ошибок, например, ошибки проверки или неправильного ввода, поскольку переходный сбой может стоить одной ограниченной попытки, а логический сбой не выполняется идентично при повторении и сжигает только бюджет гарантированного повторного сбоя, который должен немедленно расшириться.
Укупорьте попытки повтора на действие с двух или трех попыток и примените экспоненциальную обратную связь между ними, а не не немедленный повторный вызов, поскольку неограниченная или плотная попытка выполнения действия с большим количеством SOQL или DML может исчерпать синхронные ограничения в одной транзакции или прожечь накопительный бюджет цепочки и совокупные кредитные расходы в разговоре нескольких агентов. Создайте действия, чтобы повторный вызов производил такое же конечное состояние, как и один успешный вызов, используя ключ импотенции, например, код запроса или внешний код, с логикой обновления и вставки вместо вставки, поэтому повторная попытка обновляет ту же запись, а не создает повтор; действие, лишенное импотенции, вынуждает попытку удвоить потребление ресурсов посредством повторов записей в нисходящем направлении или удвоить выставленные счета за действия или разговоры за работу, которая уже произошла один раз.
Отслеживайте состояние завершения на агента в цепочке, поскольку действие одного агента может успешно подтвердить DML до сбоя агента в нисходящем направлении, а средство обработки сбоев, знающее, что уже удалось, может компенсировать или возобновить из точки сбоя, а не перезапускать и повторно выставлять счета по всей цепочке. Статус «Повторная попытка» или «Выполняется» для конечного пользователя во время ограниченной попытки в полете, поскольку пользователь, который видит тишину и повторяет запрос, запускает абсолютно новый разговор и новый набор действий, дополняя ресурс и стоимость выставления счета за исходную попытку повтором.
Схемы оптимизации ресурсов, описанные в этом документе, помогают только архитектору увидеть, где агент действительно тратит запросы SOQL, процессорное время, строки DML и маркеры при выполнении в производстве. Без доступности каждого действия и каждого сеанса нарушение ограничения или регрессия задержки отображаются как симптом, не позволяющий отследить их обратно к действию или агенту в цепочке, вызвавшей их. Эта проблема отличается от доступности расходов, предоставляемой Digital Wallet в разделе «Мониторинг затрат и финансовое управление». Digital Wallet отображает количество кредитов или разговоров, израсходованных агентом, в то время как инструментарий отображает, почему они были израсходованы, на уровне отдельного запроса, строки DML или действия, которые привели к этому потреблению. Правильный инструмент зависит от того, что предоставляет организация данного клиента и соглашение о поддержке, а не от того, какой инструмент теоретически лучше, поэтому соотнесите рекомендацию с лицензией и уровнем доступа, а не по умолчанию с наиболее доступным инструментом.
Любой архитектор может создать настраиваемые события платформы, запускаемые в начале и конце каждого действия и вызова субагента. Эти события трассируют выполнение в разговоре, не используя ничего, кроме стандартных возможностей платформы, в сочетании с записью уровня действия в настраиваемый объект, собирающий количество запросов SOQL, время процессора, количество строк DML и использование кучи при выполнении каждого действия. Оба события доступны для запроса посредством отчетов или SOQL и предоставляют каждой организации базовую диагностическую возможность, вне зависимости от выпуска или дополнительного лицензирования. Мониторинг событий, внедренный ранее для отслеживания потребления API во время пробных запусков, также отображает схемы агрегированного использования ресурсов в сеансах агентов по всей организации для клиентов, чья организация содержит это дополнение, позволяя архитектору определить, какие бизнес-процессы движутся к контролирующим ограничениям во многих диалогах, а не диагностировать по одному. Scale Center предлагает глубокое отслеживание транзакций, приближающихся к контролирующим ограничениям, обычно доступных посредством взаимодействия со службой поддержки или доступных напрямую на уровнях организаций, предоставляющих его.
Версия агентов независимо делает возможным управляемое развертывание, откат и сравнение, а также защищает инвестиции в работающего агента во время его усовершенствования. Помогите алгоритму при любой возможности пройти конфигурацию, используя типы настраиваемых метаданных и Конструктор подсказок, чтобы администраторы настраивали шаблоны напоминаний и выбор действий без цикла разработки. Используйте возможность пробного тестирования A/B для маршрутизации небольшого набора пользователей в экспериментальную версию. Сравните качество, удовлетворенность и выполнение задачи перед полным развертыванием. Это сравнение проверяет улучшения при реальном использовании и обнаруживает регрессии при ограниченном воздействии. Определите четкие контракты интерфейса между компонентами, указав вводные данные, результаты, ошибки и ожидания производительности, чтобы внедрение можно было заменить без изменения зависимых от него агентов.
Экономика агента начинается с общей стоимости владения, оцениваемой по сравнению с бизнес-ценностями, но ценообразование на основе потребления автономных агентов приводит к тому, что стоимость ведет себя не так, как традиционное лицензирование. Выбранная модель ценообразования является основополагающим архитектурным решением, поскольку она определяет, для чего вы оптимизируете весь жизненный цикл агента. Этот раздел устанавливает модели ценообразования, полную картинку TCO для внедрения агента и решение «Создать по сравнению с покупкой» для возможностей агента.
Agentforce предлагает две модели ценообразования на основе потребления, и организация выбирает одну из двух для заданного развертывания агента. Цена Flex Credits за действие агента, что делает эффективность действия рычагом управления расходами. Цена за разговор взимает фиксированную плату за разговор, независимо от продолжительности или сложности, что делает сдерживание разговора рычагом. Подписки на пользователя предоставляют неучтенное использование агента в качестве надстройки для сотрудника, а не третьей модели потребления, и они переносят фокус оптимизации с эффективности потребления на внедрение, поскольку ценность поступает от лицензированных пользователей, активно привлекающих агента, а не от минимизации каждого взаимодействия. Обе модели потребления не смешиваются для одной организации, но надстройка «На пользователя», предлагаемая на пользователя в месяц для неучтенного использования, может прослойкиваться рядом с моделью потребления, чтобы агенты, ориентированные на клиента, выполняли Flex Credits или Per-Conversation, пока сотрудники используют неучтенные лицензии.
В разделе Flex Credits стоимость действия фиксирована на действие до определенного потолка маркера. В отличие от ценообразования на основе маркера, стоимость кредита не меняется в зависимости от длины запроса или сложности модели, поэтому ответ из одного предложения и ответ из нескольких пунктов стоят одинаково. Взаимодействие нескольких действий использует кредиты для каждого действия, поэтому взаимодействие, извлекающее данные, причины и обновляющее запись, использует кредиты трех действий, а создание с дополнением извлечения добавляет дальнейшие действия посредством векторного поиска и извлечения документа перед рассуждениями. Таким образом, понимание среднего количества действий на бизнес-транзакцию является предпосылкой для моделирования стоимости в Flex Credits.
В ценообразовании за разговор применяется фиксированная плата за разговор, а несколько оборотов в одном сеансе считаются одним разговором, поэтому управление расходами происходит от решения проблемы в одном разговоре и определения четких границ сеанса, а не от обрезания отдельных действий. Заземление Data 360 и интеграция MuleSoft потребляют собственную нагрузку вместе с выбранной моделью, поскольку создание встраивания и поиск схожести сокращают нагрузку обработки данных для каждого заземленного запроса, а каждое внешнее действие потребляет нагрузку API как в исходной, так и в целевой системе.
Общая стоимость ответственности (TCO) для внедрения агента охватывает шесть категорий, и моделирование всех шести превращает кредитную оценку в обоснованное инвестиционное решение. Стоимость разработки охватывает проектирование агентов, оперативную разработку, разработку интеграции и тестирование, и она широко варьируется от простого единого целевого агента до многоагентной системы со сложной оркестрацией. Стоимость вывода зависит от выбранной модели ценообразования и требует моделирования ожидаемых объемов действий в разделе Flex Credits, объемов разговоров в разделе Per-Conversation или количества лицензированных пользователей в разделе Per-User. Для агентов, загруженных в большие базы Knowledge, инфраструктура Data 360, питающая заземление, может соперничать или превышать стоимость вывода. Стоимость инфраструктуры покрывает лицензирование Data 360 и MuleSoft, дополнительные безопасные среды и инфраструктуру мониторинга, и они в основном фиксированы или функционируют поэтапно на основе уровней нагрузки. Оперативные расходы охватывают операции по мониторингу, оперативную настройку, реагирование на инциденты и поддержку пользователей, а для программ зрелых агентов они обычно составляют значительную часть затрат на разработку в год, в соответствии с общими отраслевыми критериями для агентов на основе искусственного интеллекта, а не с показателем Salesforce. Расходы на управление охватывают проверку безопасности, человеческий надзор, регистрацию аудита и проверку соответствия, которые растут в связи с автономией агента и риском, а компонент «Справедливость» охватывает основные компоненты программы. Стоимость изменений охватывает обучение пользователей, адаптацию бизнес-процессов и управление организационными изменениями, и именно эти группы чаще всего недооценивают.
Создайте модели электронных ТСО, которые прогнозируют затраты от 3 до 5 лет. Предположения документа для объемов взаимодействия, количества действий и роста. Выполните анализ конфиденциальности для определения предположений, которые больше всего влияют на общую сумму, потом сфокусируйтесь на проверке этих предположений. Смоделируйте все три структуры расходов, Flex Credits, Per-Conversation и Per-User, относительно предполагаемого использования, прежде чем принимать обязательства, поскольку оптимальная структура зависит от схемы использования, и неправильный выбор дорого раскрутить, когда агент в производстве.
Решение «Создание по сравнению с покупкой» для агентов следует той же логике, что и для любой возможности Salesforce, оценивая немедленное время стоимости готового решения по сравнению с точным соответствием настраиваемой сборки на протяжении 3-5-летнего горизонта TCO. Бизнес-процессы сырьевых товаров благоприятствуют покупке, в то время как базовые возможности, определяющие личную дифференциацию, оправдывают создание. Agentic Enterprise предлагает спектр вариантов, а не двоичный выбор. Готовые агенты Agentforce, например, агент обслуживания или представитель по развитию продаж, предоставляют проверенные функции с быстрым развертыванием и поддерживаемыми платформой обновлениями. Они потребляют кредиты в соответствии с выбранной моделью ценообразования. Коммерчески доступные агенты из сообщества независимого поставщика программного обеспечения (ISV) Salesforce предлагаются посредством AgentExchange, где можно найти решение, уже соответствующее требованию, а не создавать его. Настраиваемые агенты, созданные с помощью конструктора агентов, обеспечивают точную подгонку и конкурентоспособную дифференциацию по цене начальной разработки, а также текущей оперативной настройки и обслуживания. Настройка готового агента посредством Конструктора подсказок и конфигурации действий предоставляет золотую середину, которая стоит дешевле полной настраиваемой разработки, при этом адаптируя агента к организации. Помимо стоимости, взвесьте требования по времени к значению, возможности внутренней разработки, стратегическую дифференциацию и допустимость зависимости поставщика и запишите решение в запись решения по архитектуре, чтобы его можно было переоценить по мере изменения требований.
Учреждения-исполнители, имеющие четкое представление о структуре расходов, обеспечивают устойчивое расширение автономного потенциала, а не истощение бюджетных средств. Рычаг оптимизации зависит от модели ценообразования, поскольку то, что вы настраиваете для управления стоимостью, отличается между оплатой за действие, оплатой за разговор и оплатой за пользователя. Принцип постоянен во всех трех компонентах: настроить потребление по сравнению с фактически доставленным значением, чтобы способный агент не сжег спокойно свой бюджет быстрее, чем вернет бизнес-результат.
В Flex Credits оптимизация означает минимизацию действий на бизнес-результат при сохранении качества. Решайте простые запросы в одном действии, а не в многоэтапном бизнес-правиле, чтобы ответы на вопросы и ответы или выполнение обычного поиска не использовали кредиты цепочки из трех действий. Объедините операции в одно действие, где это целесообразно, объединяя поиск, анализ и ответ, а не оплачивая каждый отдельно, когда одно действие будет служить. Ответы кэширования для повторяющихся запросов, чтобы часто задаваемые вопросы служили из кэша, а не использовали новые действия над каждым идентичным запросом, что является самым большим рычагом эффективности в этой модели, когда значительная доля запросов повторяется.
В ценообразовании на разговор оптимизация означает решение проблем в одном разговоре, а не в нескольких. Разработайте границы сеанса и время ожидания, чтобы разговор продолжался надлежащим образом, не прерываясь преждевременно и не принуждая к новому разговору, оплачиваемому. Сосредоточьтесь на способности агента к разрешению первого разговора, чтобы задача была выполнена в первичном разговоре, а не требовала последующих действий. Отслеживайте уровень разрешения первого разговора в качестве показателя эффективности затрат и не рекомендуем расширять область, когда пользователь открывает отдельные разговоры для связанных проблем, которые мог бы решить существующий контекст разговора.
В подписках на каждого пользователя оптимизация означает увеличение значения, возвращаемого каждым лицензированным пользователем, поскольку расход не учитывается, а стоимость фиксирована на место. Сосредоточьтесь на внедрении, чтобы лицензированные пользователи активно вовлекали агента, отслеживали использование для идентификации пользователей с низким уровнем использования для целевого обучения или перераспределения лицензий и связывали взаимодействия агентов с бизнес-результатами по количеству пользователей, чтобы сценарии использования с высокой ценностью оправдывали инвестиции, в то время как использование с низкой ценностью сигнализировало о необходимости оптимизации или другой модели ценообразования. Просмотрите заполнение пользователей в каденции, чтобы лицензии соответствовали фактическому использованию.
Независимо от модели ценообразования, архитектура влияет на стоимость. Внедрите агентов сортировки, которые обрабатывают начальную маршрутизацию с помощью простой логики и направляют пользователей к специализированному агенту, только когда этого требует сложность, чтобы дорогостоящие сложные вызовы происходили только при необходимости. Возвращаемся к традиционной автоматизации для детерминистских сценариев, когда достаточно логики на основе правил, позволяя потокам обрабатывать детерминистские пути с меньшими затратами, в то время как агенты обрабатывают неоднозначные ситуации, которые действительно нуждаются в аргументации. Выборочно извлекайте данные заземления, вызывая векторный поиск и извлечение документов, только если этого требует аргументация агента, а не каждое взаимодействие, чтобы потребление Data 360 отслеживало реальную потребность. Эти схемы поддерживают пропорциональность затрат на аргументацию и потребление архитектуры сложности работы.
Мониторинг затрат для автономных агентов сложнее, чем для традиционных загруженности, поскольку агенты не следуют предсказуемой схеме запрос-ответ. Агент может итерировать посредством многоэтапных рассуждений, адаптивно вызывать инструменты на основе условий среды выполнения и координировать других агентов, что создает очень переменное кредитное потребление, которое трудно прогнозировать. Без мониторинга агент, выполняющий глубокую повторяющуюся работу, может израсходовать большой объем кредитов до вмешательства кого-либо, а неэффективная оперативная разработка или избыточные циклы рассуждений могут спокойно истощить бюджеты во всем парке агентов. Эффективное управление, таким образом, требует отображения в реальном времени расхода на каждого агента и на операцию, автоматического оповещения и элементов управления, предотвращающих утечку стоимости, сохраняя автономность, которая делает агентов полезными. Финансовое управление для агентов также требует четкой ответственности и многоуровневого утверждения, созданного для переменного потребления, а не для статической стоимости вычисления.
Salesforce Digital Wallet - встроенный инструмент мониторинга продуктов на основе потребления, включительно с Agentforce Flex Credits, и организации, использующие Flex Credits, должны установить его в качестве основного механизма мониторинга расходов, а не создавать настраиваемые панели мониторинга для копирования предоставляемых им данных. Digital Wallet предоставляет данные о потреблении в близком к реальному режиме времени с важными данными об использовании на уровне действий, разбивкой на агента, отображающей, какие агенты потребляют больше всего, предупреждения об активном потреблении и архивные тренды для анализа схем и прогнозирования. Соотнесите мониторинг с моделью ценообразования. В разделе Flex Credits отслеживайте потребление по агенту, количеству пользователей, периоду времени и типу действия, а также дополняйте Digital Wallet настраиваемыми панелями мониторинга, связывающими потребление кредита с бизнес-транзакциями. В разделе «Цены за разговор» отслеживайте объемы разговоров, среднюю продолжительность и процент выполнения. В подписках на каждого пользователя отслеживайте использование, а не потребление, отслеживая активных пользователей и бизнес-ценность на пользователя, чтобы инвестиции в лицензию отображались как предоставление пропорциональной ценности.
Атрибуция расходов на взаимодействие связывает потребление с бизнес-транзакциями и отображает стоимость на решенное обращение, квалифицированный интерес или обработанный заказ, что позволяет вычислить рентабельность инвестиций и сравнить сценарии перекрестного использования. Предупреждение о бюджете запускает уведомление по мере приближения потребления к определенным пороговым значениям, при пороговых значениях, например, 70% и 85% бюджета, чтобы оптимизация происходила до достижения ограничения. Настройте предупреждения для каждого агента и каждого сценария использования, а не только в организации, чтобы локализовать проблему в источнике. Обнаружение аномалий инициирует резкий скачок потребления, который указывает на непредвиденную схему использования или цикл рассуждений, требующий исследования. Предоставьте общий доступ к панелям мониторинга стоимости заинтересованным бизнес-лицам и техническим группам, чтобы прозрачность способствовала использованию агентов с учетом затрат.
Применение финансового управления перед выделением средств на архитектуру агента. Требуйте бизнес-обоснование для инвестиций агента, которое охватывает прогнозируемый TCO на протяжении 3-5 лет в соответствии с выбранной моделью ценообразования, ожидаемые бизнес-результаты с методом измерения, сравнение с альтернативами, включительно с ручными процессами и традиционной автоматизацией, а также оценку риска, охватывающую качество, безопасность и операционный риск. Определите пороговые значения утверждения, позволяющие отделить инвестиции, которые может санкционировать отдел, от инвестиций, требующих утверждения руководителя, чтобы агент с высоким уровнем инвестиций или высоким уровнем риска получил пропорциональное разрешение. Предписывайте пилотные развертывания, которые проверяют предположения перед полным производством, поскольку пробная версия отображает фактическое потребление, качество и внедрение, которые учитываются как в решении об инвестициях в производство, так и в выборе модели ценообразования.
Управляйте имуществом агента как портфолио, а не как агент по агенту, поскольку представление портфолио отображает возможности оптимизации, которые пропускает проверка одного агента. Просмотрите всех агентов вместе, сравнивая стоимость, использование, бизнес-ценность и стратегическое выравнивание, и определите критерии заката, выводящие из эксплуатации агентов с низким внедрением, плохим рентабельностью инвестиций, вытесненными функциями или чрезмерной стоимостью, чтобы агенты с низкой стоимостью не накапливали и не расходовали бюджет на неопределенный срок. Перераспределите инвестиции от низкоэффективных агентов в ценные возможности в качестве постоянной практики, которая перенаправляет расходы в соответствии с меняющимися приоритетами, а не одноразовой очисткой.
Распределение расходов создает ответственность за потребление агентов, и организации внедряют его с помощью тех же двух моделей, которые применяются к остальной платформе. Отчеты по отображению расходов агента по бизнес-единицам без внутренней оплаты, что создает осведомленность о расходах и информирует об оптимизации обсуждения без спора о внутренних выставления счетов. Обратный платеж распределяет фактические затраты агента между бизнес-единицами-потребителями, что способствует усилению оптимизации, поскольку стоимость напрямую влияет на бюджет отдела, но требует точного метода распределения во избежание споров. Гибридный подход применяет обратный платеж к массовым производственным агентам, используя обратный платеж для экспериментальных или массовых агентов, что позволяет балансировать ответственность за крупные инвестиции и гибкость в интересах инноваций.
Архитектуры агентов привносят собственные рекомендации по устойчивости, поскольку вывод широкоязычной модели является вычислительно интенсивным и некоторые агенты выполняются непрерывно, а не только в отдельных транзакциях, запущенных пользователем. Активные, исходящие и запланированные агенты работают без пользователя в цикле, разговорные агенты накапливают потребление во многих оборотах, а векторный поиск, подготовка контекста и выполнение действий увеличивают нагрузку на инфраструктуру. Устойчивое проектирование агента минимизирует потери вычислений, сохраняя адаптивность взаимодействия. Как и в компоненте «Оптимизация ресурсов и затрат», взаимосвязь между одним решением и эмиссиями центра обработки и хранения данных является косвенной. Эффективность отдельного клиента напрямую не понижает эмиссии. Однако, повышение эффективности всех клиентов помогает Salesforce запустить инфраструктуру при более высоком использовании и отложить расширение нагрузки. и базовые практики Sustainability из компонента «Оптимизация ресурсов и затрат» применяются к агентам, а последующие стратегии эффективности учитывают то, что характерно для разговорных систем, поддерживаемых широкоязычной моделью. Каждая из них также снижает стоимость, поэтому устойчивость и рентабельность являются одинаковой дисциплиной, оцениваемой с учетом разных результатов.
Вывод является самым ресурсоемким компонентом агентской архитектуры, поэтому эффективность окупается быстрой длиной, использованием контекста и кэшированием. Оптимизируйте напоминания, чтобы передать намерение в меньшем количестве маркеров, удалив словесные инструкции и избыточные примеры, поскольку более короткое напоминание уменьшает вычисление предзаполнения пропорционально, даже если оно не изменяет вычисление создания ответа. Управляйте контекстным окном, суммируя журнал разговора после первых нескольких ходов и возвращая только важные поля из каждого действия, чтобы бюджет маркера, перенесенный в каждый вывод, оставался ограниченным, а не рос вместе с разговором.
Векторный поиск и запросы объединенного профиля используют вычислительные ресурсы, поэтому та же дисциплина ограничения результатов и фильтрации, которая контролирует стоимость заземления, также уменьшает загрузку инфраструктуры заземления. Установите ограничения для возврата только результатов, используемых агентом, поскольку извлечение 50, когда 5 сообщает ответ, содержит 45 неиспользованных результатов, которые расходуют бюджет маркера заземления без каких-либо преимуществ, и используйте фильтры метаданных для сужения поиска до ранжирования сходства. Запросите объединенные профили для сбора полного контекста в одной операции, а не выдачу отдельных запросов по нескольким объектам на каждый ход, и профили кэширования для агентов с высокой близостью пользователей, например, торговых агентов, работающих с фиксированным набором организаций, чтобы повторная сборка контекста не повторяла запрос.
Действия агента используют запросы SOQL, операции DML и процессорное время, поэтому пакетное кэширование и асинхронная дисциплина компонента «Оптимизация ресурсов и затрат» применяются напрямую к действиям агента. Создайте действия для принятия коллекций, чтобы обновление многих записей было одной операцией, а не многими, используйте запросы взаимосвязи для извлечения родительских и дочерних данных в одном операторе, кэшируйте справочные данные в кэше платформы и пакетируйте DML в коллекции, а не в каждой записи. Переместите операции, превышающие синхронные ограничения, в Queable или Batch Apex, обрабатывайте несрочные работы, например, пакетную оценку или архивное обогащение, асинхронно и планируйте запущенные агентом пакетные задания для окон вне пиковых значений, где возможно, чтобы нагрузка распределялась во времени, а не концентрировалась в часы работы. Отслеживайте асинхронное выполнение, чтобы накопившаяся очередь сигнализировала о необходимости планирования нагрузки, прежде чем она станет неудачной.
Структура потребления агентов меняется по мере роста использования, поэтому устойчивость требует постоянного мониторинга, а не одноразового прохождения. Отслеживайте средние маркеры на вывод посредством доступной телеметрии использования, чтобы увеличение размера напоминания показывало возможность оптимизации, отслеживайте распределение продолжительности разговора, чтобы неограниченные разговоры показывали проблему границы задачи и анализируйте частоту выполнения действий в мониторинге событий, чтобы высокочастотное действие стало приоритетом оптимизации. Просмотрите схемы запросов Data 360, чтобы найти распространенные запросы, которые стоит кэшировать или предварительно вычислить, отслеживайте уровень достижения семантического кэша, чтобы низкий уровень запускал настройку порога, и измерьте процентили задержки, чтобы хвостовая задержка отображала любые преграды. Регулярно проверяйте использование агентов на наличие отклонения в области. Например, изучите агента, средняя продолжительность разговора которого увеличивается с нескольких оборотов до многих за несколько месяцев. Уточните границы агента, чтобы потребление вернулось к плану. Некоторые из этих поверхностей мониторинга открывают использование в агрегированных панелях мониторинга, а не в качестве отдельного журнала выводов, поэтому подтвердите точную телеметрию, доступную для вашей конфигурации при создании мониторинга.
Оптимизация ресурсов определяет, расширяются ли архитектуры агентов по мере роста населения и расширения способов использования, а оптимизация расходов определяет, возвращает ли эта шкала пропорциональное значение бизнеса. Эти два решения образуют единый мандат:
- Архитектурная эффективность: создавать действия с пакетированием, бюджетировать SOQL в цепочках действий, перевести тяжелую обработку на асинхронизацию, оптимизировать потребление API посредством составных и управляемых событиями схем, управлять контекстными окнами посредством расстановки приоритетов и резюмирования и создавать составные архитектуры из многоразовых компонентов.
- Финансовое руководство: намеренно выбрать модель ценообразования, смоделировать полную ТСО перед принятием обязательства, отслеживать потребление относительно бизнес-результатов и управлять инвестициями посредством многоуровневого утверждения и проверки портфолио.
Организации, осваивающие эти схемы, предоставляют адаптивные взаимодействия агентов в ограничениях платформы, сохраняя расходы в соответствии со значением, возвращаемым агентами.
Базовые рекомендации по ресурсам и оптимизации затрат для всех решений Salesforce, включая оптимизацию производительности, контролирующие ограничения, анализ ТСО, лицензионную дисциплину и управление затратами, находятся в компоненте «Оптимизация ресурсов и затрат». Компоненты управления агентами, человеческого надзора и программы безопасности подключаются к компонентам Trust и Fairness. Подробные рекомендации по внедрению агентов в этом документе, охватывающие эффективность ресурсов, экономику, оптимизацию действий, управление и устойчивость, собраны в библиотеке агентских схем.