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

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

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

Каждая схема в этом документе использует одинаковую структуру:

Имя: Идентификатор схемы, обозначающий тип интеграции, содержащийся в схеме.

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

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

Силы: Ограничения и обстоятельства, которые могут затруднить решение проблемы.

Приложение схемы Salesforce: Рекомендуемый способ применения схемы к сценарию.

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

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

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

Обработка и восстановление ошибок: Рекомендации по управлению сбоями во время применения схемы. Этот параметр охватывает четыре области:

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

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

Пример: Сквозной сценарий, описывающий способ использования схемы проектирования в реальном сценарии Salesforce. Пример объясняет цели и способ применения схемы для достижения этих целей.

В следующей таблице перечислены охваченные схемы внедрения.

Список шаблонов

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

Вызов действия:

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

Вызов агента:

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

Заземление с данными предприятия:

Шаблоны в этой категории охватывают, как агенты основаны на точных, текущих, характерных для организации Knowledge до того, как они мотивируют или действуют.

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

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

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

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

Контекст

Многие бизнес-процессы изначально последовательны – каждый этап требует проверенного результата из предыдущего, прежде чем продолжить. Например, возмещение не может быть инициировано до подтверждения права на участие, организация для выставления счета не может быть создана до наличия записи заказа и проверка соответствия не может быть зарегистрирована до завершения проверки.

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

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

Данная схема является агентским аналогом руководства «Удаленный вызов процесса: запрос и ответ из схем интеграции», описывающего одну синхронную выноску. Агентская схема распространяет схему на управляемую агентом цепочку зависимых вызовов в одном цикле рассуждения.

Проблема

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

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

Силы

При применении данной схемы ответьте на следующие вопросы:

• Зависит ли каждое действие в цепочке от данных, возвращенных предыдущим действием, или зависимости только от статуса успеха или сбоя?

  Зависимости данных требуют, чтобы агент переносил идентификаторы и атрибуты через этапы.

• Способны ли все отдаленные конечные точки отвечать в течение времени ожидания цикла рассуждений агента?

  Медленная внешняя система на любом этапе цепочки блокирует всю последовательность.

• Требует ли цепочка полного успеха или частичное завершение допустимо?

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

• Можно ли безопасно повторить операции записи в цепочке?

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

• Вызывается ли цепочка взаимодействием пользователя (разговорным, низким совпадением) или автоматическим триггером (потенциально высоким совпадением)?

  Это определяет допустимость синхронной блокировки или обязательность асинхронной схемы.

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для последовательного вызова действия

Результаты

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

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

Агент отвечает за аргументацию результатов и последовательность решений. Каждое действие отвечает только за собственную операцию и возврат структурированного результата. Ни один из слоев не кодирует логику другого.

Рекомендации по проектированию

Руководство по платформе-агностике

• Убедитесь, что каждое действие в цепочке содержит семантическое описание, написанное на языке намерения, а не в качестве подписи технического метода. Агент выбирает действия на основе следующих описаний. Описание, которое гласит "вызывает API выставления счета", менее полезно, чем описание, которое гласит "создает организацию выставления счета в системе выставления счета и возвращает новый идентификатор организации".
• Сделайте все операции записи в цепочке немощными. Цикл рассуждения агента может повторить действие, если получит неоднозначный ответ. Действие должно привести к одному результату при повторном вызове.
• Проверьте все выведенные параметры ввода LLM оборонительно на границе действия. Никогда не думайте, что параметры, переданные агентом, сформированы должным образом, в пределах диапазона или ожидаемого типа.
• Создайте каждое действие для одной ответственности. Действие, создающее организацию для выставления счета и отправляющее электронное подтверждение в одном вызове, сложнее повторить, труднее протестировать и труднее агенту рассудить более двух отдельных действий.

Примечания к внедрению Salesforce

• В действиях Apex примечание должно содержать @InvocableMethod(label=’...’ description=’...’). «Описание» считывается агентом для определения времени вызова действия. Объявите все переменные ввода и вывода с @InvocableVariable посредством полей описательной метки и описания. Возврат структурированных объектов результатов с четкими индикаторами успеха/сбоя и читаемыми сообщениями об ошибках.
• В действиях потока используйте только автоматически запущенные потоки; потоки окон не поддерживаются в контекстах автономного агента. Держите каждый поток атомарным; одно действие, одна ответственность. Настройте пути ошибок в каждом внешнем элементе выноски для обнаружения ошибок интеграции и возврата действенных сообщений об ошибках агенту, вместо того, чтобы разрешать неуловимым исключениям завершение сеанса.
• Для внешних служб импортируйте спецификацию OpenAPI целевой системы и зарегистрируйте созданные действия в теме Agentforce. Во избежание жесткого кодирования конечных точек или регистрационных данных в определении действия, добавьте созданные заглушки в именованные регистрационные данные.
• Для всех внешних выносок установите четкое время ожидания выноски. Выноска, висящая без времени ожидания, блокирует цикл рассуждений агента до достижения ограничения сеанса. Возвращает изящный сбой с описательным сообщением об ошибке при превышении времени ожидания. Все внешние выноски имеют настраиваемое время ожидания до 120 секунд. Они также подпадают под ограничения регулятора синхронных транзакций Apex, поэтому обязательно снизьте риск мгновенного выполнения более 50 транзакций, каждая из которых выполняется более пяти секунд.

Обработка и восстановление ошибок

• Агент проверяет каждый этап на явный успех предшественника этапа. Действия должны возвращать структурированный результат, содержащий четкий индикатор успеха или сбоя. Агент не может достоверно сделать вывод об ошибке только на основе отсутствующего или нулевого ответа.
• При неудачном выполнении действия агент использует сообщение об ошибке, возвращенное действием, для определения следующего действия: напоминание пользователю о необходимости откорректированного ввода, попытка повторной попытки самовосстановления с откорректированными параметрами или остановка цепочки и регистрация сбоя для проверки человеком. Поэтому сообщения об ошибках должны быть конкретными и действенными: "Недопустимый диапазон дат: endDate не может предшествовать startDate» используется; код 400 статуса сам по себе не используется.
• В цепочках, где частичное завершение создает несогласованное состояние (например, организация для счета была создана, но запись CRM не была обновлена), агент вызывает действие компенсации для отката или обозначения частичного состояния перед всплыванием сбоя. Разработайте пути компенсации в качестве именованных действий наряду с прямым путем.
• Если действие записи потенциально успешно, но вернуло двусмысленный ответ (время ожидания сети, без подтверждения), повторная попытка должна использовать тот же ключ импотентности или внешний код ссылки, что и исходный вызов. Никогда не создавайте необработанную повторную попытку неимпотентной записи.

Рекомендации по безопасности

• Перенесите все внешние выноски в именованные регистрационные данные. Никогда не используйте конечные точки или регистрационные данные жесткого кода в коде Apex или конфигурации потока. Они должны управляться посредством безопасного хранилища регистрационных данных платформы и ротироваться без изменений кода.
• Примените принцип наименьших прав к пользователю интеграции или связанному приложению, используемому каждым действием. Действие, считывающее только данные заказа, не должно содержать полномочия записи в системе выставления счета. Регистрационные данные области к минимуму операций, необходимых действию.
• Зарегистрируйте вызов каждого действия в цепочке с кодом сеанса, параметрами ввода (проверенными конфиденциальными значениями) и результатом. Если результат оспаривается, этот контрольный журнал является основным механизмом для восстановления причины выполнения агентом заданной последовательности действий.
• Очистите все параметры ввода, исходящие из предоставленного пользователем текста, прежде чем передавать их во внешние системы. Вводные данные пользователя, переданные через агента во внешнюю выноску API, являются потенциальным вектором инъекции. Проверьте тип, формат и диапазон на границе действия до выполнения выноски.

Пример

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

1. GetOrderDetails (Apex Action) извлекает запись заказа из системы управления заказами посредством кода заказа, предоставленного пользователем. Возвращает статус заказа, позиции строки, дату покупки и метод оплаты. Агент оценивает, находится ли заказ в состоянии возмещения, прежде чем продолжить.
2. ValidateRefundEligibility (автоматически запущенный поток) применяет бизнес-правила для права на возмещение, включительно с окном возврата, ограничениями категорий продуктов и журналом предыдущего возмещения. Данная функция возвращает логическое значение, а также, при его отсутствии, обычную причину, по которой агент может появиться у пользователя.
3. InitiateRefund (Apex Action) вызывает API внешнего шлюза оплаты с кодом заказа и суммой возмещения. Возвращает «refundTransactionId» при успешном выполнении. Это действие недействительно. При повторном вызове с одинаковым кодом заказа возвращается существующий код транзакции, а не создается повтор возмещения.
4. UpdateCaseStatus (автоматически запущенный поток) обновляет запись обращения CRM с кодом транзакции возмещения, устанавливает статус обращения на «Решено, что возмещение выдано» и создает дополнительную задачу для ответственного за организацию. Этот шаг выполняется только после того, как «InitiateRefund» вернет подтвержденный код транзакции.

Если InitiateRefund истекает или возвращается ошибка, агент останавливает цепочку, не вызывает UpdateCaseStatus и отправляет пользователю действенное сообщение. Обращение остается открытым и нерешенным, сохраняя точное состояние в CRM.

Контекст

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

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

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

Проблема

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

Силы

При применении данной схемы ответьте на следующие вопросы:

• Какие рекомендации по действиям, касающимся безопасности потока и общего доступа к изменчивому состоянию?
• Каким образом решение сможет управлять и избегать достижения контролирующих ограничений Salesforce для параллельных выносок Apex в рамках одной транзакции?
• Нужно ли использовать асинхронные схемы (например, Queable Apex или события платформы), чтобы избежать губернаторских ограничений?
• Требуется ли синхронное агрегирование результатов, прежде чем агент сможет продолжить работу?

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для вызова параллельного действия

Результаты

Если независимые действия выполняются параллельно, время сквозного бизнес-правила ограничивается самым медленным отдельным действием, а не суммой всех действий. Для бизнес-правил с тремя независимыми выносками в среднем 300 мс каждая параллельное выполнение выполняется за ~300 мс; последовательное выполнение занимает ~900 мс. В масштабе эта разница усугубляется в каждом сеансе агента, выполняемом одновременно.

Рекомендации по проектированию

Руководство по платформе-агностике

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

Примечания к внедрению Salesforce

• Для Queueable Apex: Отправьте все задания в рамках одной транзакции, чтобы увеличить вероятность параллельного выполнения. Помните, что доступные временные интервалы параллельности являются общими в организации; проектируйте, исходя из предположения, что временные интервалы могут быть не всегда доступны, и создайте резервную копию последовательного выполнения, если они недоступны.
• Для событий платформы: Запишите результат каждой операции в выделенную запись этапа (с ключом от общего кода корреляции), а не обновляйте целевую запись напрямую. Окончательная агрегация Поток или триггер Apex считывает все записи этапирования после достижения ожидаемого количества, потом применяет консолидированное обновление атомарно.
• Для отказа от промежуточного программного обеспечения: Установите четкое время ожидания для одной выноски, превышающее ожидаемое время ответа в худшем случае самого медленного сервера, но в пределах ограничения времени ожидания выноски Salesforce. Промежуточная программа возвращает частичные результаты с четким указанием, какие компоненты не сработали, а не время всего ответа.

Обработка и восстановление ошибок

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

Рекомендации по безопасности

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

Пример

Агент обслуживания отвечает на сложный вопрос выполнения: Можешь отправить мне этот заказ к пятнице? Ответ требует данных из всех независимых систем одновременно, как указано ниже:

1. Агент определяет три независимые потребности в данных: текущий уровень запаса, активные права клиента и примерное окно доставки перевозчика для расположения клиента.
2. Параллельно вызываются три действия: GetInventoryStatus (из внешней системы запаса посредством промежуточного программного обеспечения), GetCustomerEntitlements (из Salesforce CRM) и GetDeliveryEstimate (из API оператора посредством промежуточного программного обеспечения).
3. Каждое действие возвращается независимо. Агент дожидается получения всех трех ответов (или завершения времени ожидания агрегации).
4. При наличии всех трех результатов агент мотивирует объединенные данные, оценивая, достаточно ли запаса, право клиента покрывает экспресс-доставку, и перевозчик подтверждает, что доставка в пятницу возможна для почтового индекса клиента.
5. Агент возвращает пользователю один приземленный ответ, полученный из трех систем, за время, потраченное на самый медленный из трех вызовов.

Контекст

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

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

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

Проблема

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

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

Силы

При применении данной схемы ответьте на следующие вопросы:

• Требуется ли агенту результат этой операции для завершения текущего хода? Если да, это неправильная схема. Используйте вызов последовательного действия.

• Способна ли система в нисходящем направлении получать и надежно обрабатывать отправленное сообщение или событие без синхронного подтверждения? Целевая система должна быть долговечной. Сообщение не должно быть утеряно, если оно временно недоступно.

• Операция неэффективна или повторная отправка требует охраны? Повторы на уровне сети и попытки аргументации агента могут привести к нескольким попыткам одной и той же отправки. Если операция в нисходящем направлении не является немощной, действие должно содержать ключ дедупликации.

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

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для вызова асинхронного действия

Результаты

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

Рекомендации по проектированию

Руководство по платформе-агностике

• Напишите описания действий на языке намерения. Например, «Отправляет уведомление о продлении в очередь службы сообщений и возвращает код ссылки отправки» больше полезно агенту, чем «вызывает конечную точку уведомления».
• Никогда не описывайте действие отправки как "отправляет и подтверждает доставку". Агент может только подтвердить принятие. Доставка и обработка в нисходящем направлении находятся за пределами видимости агента.

Примечания к внедрению Salesforce

• Возвращает код ссылки из каждого действия вызова, например, ReplayId события платформы, код задания в очереди, PublishResult replayId Public/Sub API или маркер внешнего подтверждения. Запишите его в запись CRM во время вызова. Это единственный контрольный журнал, создаваемый сеансом агента.
• Для Pub/Sub API агент вызывает действие Apex, которое выполняет выноску gRPC в конечную точку Pub/Sub API ‘/Publish’. Действие должно обрабатывать этап регистрации схемы - события должны быть сериализированы в формате Avro относительно зарегистрированной схемы. Верните PublishResult ‘replayId’ агенту в качестве ссылки на отправку.
• В событиях платформы позвоните EventBus.publish() в действии Apex и проверьте SaveResult на наличие ошибок, прежде чем возвращать индикатор успеха агенту. Не предполагайте успешность публикации, проверьте ее.
• Для заданий в очереди внедрите интерфейс «В очереди» и вызовите System.enqueueJob() из действия. Возврат полученного кода AsyncApexJob агенту.
• Для внешних асинхронных конечных точек целевая конечная точка должна немедленно вернуть подтверждение (HTTP 202 Accepted) с кодом ссылки. Если конечная точка блокируется до завершения обработки, она синхронизируется и эта схема не применяется.

Обработка и восстановление ошибок

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

Рекомендации по безопасности

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

Пример

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

1. CheckRenewalEligibility (автоматически запущенный поток) оценивает условия контракта, уровень клиента и статус отказа. Возвращает логическое значение и предпочтительный канал уведомления.
2. DispatchRenewalNotification (Apex Action) публикует событие платформы RenewalNotification\_\_e, содержащее код контракта, код клиента, канал уведомления и созданный ключ импотенции. Возвращает ReplayId, подтверждающий принятие события платформой.
3. UpdateContractRecord (автоматически запущенный поток) записывает отметку времени ReplayId и отправки в запись контракта и устанавливает флаг статуса «Отправлено уведомление».

Контекст

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

Все чаще абонент сам является агентом искусственного интеллекта или оркестратором, а не приложением, обращенным к человеку. В этих схемах взаимодействия искусственного интеллекта агент оркестрации делегирует этап рассуждения, поиск CRM или действие Agentforce в качестве отдельного вызова инструмента. Для поддержки этой схемы нам нужно предоставить доступ к серверу Model Context Protocol (MCP).

Проблема

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

Силы

При применении данной схемы ответьте на следующие вопросы:

• Ожидает ли внешний абонент синхронного ответа с низкой задержкой или асинхронный обратный вызов допустим?
• Как устанавливается и распространяется личность абонента в контексте выполнения агента для доступа к данным и персонализации?
• Какой ожидаемый объем параллельных сеансов, запущенных API, и как это взаимодействует с уровнем API Salesforce и ограничениями параллельных сеансов?
• Требуется ли внешней системе поддерживать непрерывность сеанса в несколько оборотов (многооборотный диалог) или каждый запрос является безгосударственным?
• Как должен быть структурирован ответ агента, чтобы система вызова могла анализировать и обрабатывать его программным способом?
• Является ли абонент человеческим приложением, требующим прямой интеграции REST, или агентом на основе искусственного интеллекта или оркестратором, который может вызвать Agentforce как инструмент посредством стандартного протокола, например, MCP?

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для вызова агента по запросу

Результаты

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

Когда абонент является агентом искусственного интеллекта или оркестратором, механизм Agentforce via MCP (доступный в готовом виде посредством Salesforce Headless 360) полностью устраняет необходимость настраиваемой интеграции REST. Сервер MCP обрабатывает жизненный цикл сеанса от имени вызывающего агента, что позволяет Agentforce участвовать в качестве первоклассного инструмента в бизнес-процессах нескольких агентов без дополнительной сантехники.

Рекомендации по проектированию

Руководство по платформе-агностике

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

Примечания к внедрению Salesforce

• Внедрите контекст сеанса в запрос POST создания сеанса, а не в первое сообщение пользователя. Когда внешняя система создает сеанс, у нее есть возможность передать структурированные переменные контекста (код организации, данные права, сводка предыдущего взаимодействия) напрямую в качестве именованных параметров сеанса. Эти переменные доступны агенту перед обработкой одного хода, поэтому он начинает рассуждения из заземленного состояния, не отправляя поисковых вызовов для определения, кто является клиентом или на что он имеет право. Передача тех же данных в текст сообщения заставляет агента анализировать неструктурированный текст для извлечения фактов, которые он мог бы получить в качестве типизированных переменных - увеличение задержки, внедрение ошибок извлечения и использование этапов рассуждения, которые не добавляют бизнес-ценности.
• Создайте ответы агента для структурирования и компьютерного анализа. Используйте правила переменной вывода и инструкции, направляющие агента на возврат удобных или четко определенных ответов JSON, если абонент является системой, а не человеком.
• Явно управляйте жизненным циклом сеанса. Завершайте сеансы сразу после использования DELETE /einstein/ai-agent/v1/sessions/{sessionId}, чтобы освободить параллельные интервалы и избежать сохранения устаревшего контекста в несвязанных взаимодействиях.
• Учитывайте ограничения параллельных сеансов Salesforce. Для высокопроизводительных сценариев внедрите пул сеансов или слой очереди в систему вызовов, чтобы предотвратить отклонение запроса во время пиковой нагрузки.
• При вызове Agentforce посредством MCP передайте контекст как параметры ввода инструмента, а не как переменные сеанса. Сервер MCP управляет жизненным циклом сеанса прозрачно, поэтому вызывающий агент не может установить именованные параметры сеанса напрямую во время создания. Убедитесь, что весь обязательный контекст (коды записей, удостоверение пользователя, данные права) включен в полезные данные вызова инструмента, чтобы агент начал рассуждать из заземленного состояния.
• Рассматривайте прозрачное управление сеансами сервера MCP как удобство, а не как обход параллельности. Каждый вызов инструмента по-прежнему использует интервал сеанса агента Salesforce. Высокочастотные оркестранты, вызывающие Agentforce посредством MCP в масштабе, должны учитывать те же ограничения параллельных сеансов, что и прямые абоненты API.

Обработка и восстановление ошибок

• Agent API возвращает стандартные коды ошибок HTTP. Система вызова должна обрабатывать «429 слишком много запросов» (ограничение по количеству запросов) с экспоненциальным отключением и «503 служба недоступна» с логикой повтора попытки.
• Когда сам агент сталкивается с неполадками инструмента, это возвращает изящную естественно-языковую ошибку в тексте ответа. Система вызова обнаруживает эти ответы часового (например, проверка поля статуса «ошибка» в ответе) и перенаправляет их соответственно либо повторной попыткой с дополнительным контекстом, либо предоставлением резервного взаимодействия, либо переходом на человеческий уровень.
• При вызове посредством MCP ошибки появляются на двух отдельных уровнях: Ошибки транспортировки MCP (неправильные вызовы инструментов, недоступность сервера) и ошибки рассуждения Agentforce (ошибки выполнения инструмента, неустранимые действия). Агент оркестрации должен обрабатывать оба слоя независимо. Ошибки транспортировки MCP должны инициировать попытки на уровне протокола; ошибки рассуждений Agentforce, возвращенные в ответе инструмента, должны обрабатываться резервной логикой самого оркестратора или логикой расширения.

Рекомендации по безопасности

• Используйте минимально возможные области OAuth для приложения внешнего клиента. Интеграция, которая должна вызывать только агента, не должна ограничивать доступ к данным тем, что требуется самому агенту.
• Проверьте и оздоровите все вводные данные из внешней системы, прежде чем вводить их в качестве переменных сеанса. Внешние вводные данные являются поверхностью атаки для быстрого ввода. Например, вредоносный абонент может создать поле «customerQuery», предназначенное для переопределения инструкций агента.
• Примените добавление в список разрешенных IP-адресов в приложении внешнего клиента, чтобы ограничить доступ внешних систем к проверке подлинности и вызову API агента.
• Зарегистрируйте все входящие сеансы, запущенные API, с удостоверением абонента, кодом сеанса и метаданными запроса/ответа в целях проверки и безопасности.
• При вызове Agentforce посредством MCP сервер MCP выполняет проверку подлинности в Salesforce от имени вызывающего пользователя. Убедитесь, что регистрационные данные связанного приложения сервера MCP ограничены минимальными обязательными полномочиями и что удостоверение конечного пользователя (используя инструменты MCP, например, Claude) - удостоверение распространено в контекст сеанса явно посредством параметров ввода инструмента.

Пример

Портал финансовых услуг запускает агента Agentforce для обработки запроса по ипотеке.

1. Портал проверяет подлинность посредством потока OAuth регистрационных данных клиента и получает маркер носителя.
2. Он вызывает «POST /einstein/ai-agent/v1/sessions» с переменными сеанса: «{ "accountId": "001xx...", "productType": "mortgage", "loanAmount": 450000 }».
3. Пользователь отправляет свой вопрос: "Какие документы нужны для заполнения заявления?"
4. Портал вызывает текст пользователя POST /einstein/ai-agent/v1/sessions/{sessionId}/messages.
5. Агент Agentforce вызывает действие «ПолучитьDocumentChecklist», извлекает требования типа кредита и возвращает структурированный список.
6. Портал отображает ответ агента встроенно и закрывает сеанс при выходе пользователя.

Контекст

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

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

Проблема

Когда бизнес-событие в реальном времени происходит в Data 360 или Salesforce Platform, как это событие может автономно обработать сеанс агента, предоставить полезные данные события в качестве контекста заземления и довести бизнес-процесс не разговорного действия до завершения без участия человека, инициирующего или направляющего взаимодействие?

Силы

При применении данной схемы ответьте на следующие вопросы:

• Требуется ли ответ немедленно в момент запуска события или обработка в близком к реальному режиме времени (от секунд до минут) допустима?
• Содержит ли полезные данные события достаточный контекст для запрета агента или агенту нужно выполнить дополнительные поиски, прежде чем он сможет эффективно рассуждать?
• Какой ожидаемый объем и частота событий? Высокопроизводительные потоки событий требуют управления тарифами во избежание исчерпания ограничений совпадения агентов.
• Может ли одно и то же событие запускаться несколько раз для одного бизнес-объекта (как минимум одна доставка)? Если да, действия должны быть неэффективными.
• Существует ли путь человеческой эскалации, если агент не может решить событие автономно?
• Как должна отображаться обработка неудачных событий? С очередью из мертвых букв, предупреждением или созданием обращения?

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для выполнения агента под управлением событий

Результаты

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

Система запуска (данные 360 или события платформы) продолжает отвечать за обнаружение событий и формирование полезных данных. Агент несет ответственность за рассуждения над полезной нагрузкой и выбор правильной цепочки действий. Диалоговый поворот не требуется; полезные данные события являются полным вводом.

Рекомендации по проектированию

Руководство по платформе-агностике

• Разработайте все действия для вызова без разговора. Поворота пользователя нет; агент должен получить разрешение только из исходного контекста заземления. Действия должны возвращать структурированные, детерминистские результаты, а не требовать разъяснений.
• Убедитесь, что полезные данные события содержат достаточный контекст заземления до создания сеанса агента. Похудевшая полезная нагрузка, которая вынуждает агента выполнять несколько поисковых вызовов до того, как он сможет обосновать, увеличивает задержку и потребление совпадений.
• Сделайте все операции записи, запущенные агентами, управляемыми событиями, идемпотентными. Системы доставки событий обычно предоставляют гарантии как минимум один раз. Обработка повторяющихся событий не может привести к повторным побочным эффектам.

Примечания к внедрению Salesforce

• В потоках, запущенных Data 360, соотнесите атрибуты полезных данных событий (например, «accountId», «eventType», «metricValue», «productIds») напрямую с именованными переменными сеанса во время создания сеанса. Это позволяет агенту с первого этапа рассуждения не требовать действия извлечения.
• Для триггеров событий платформы используйте автоматически запущенный поток, а не поток окон. Потоки окон не поддерживаются в автономных, не диалоговых контекстах.
• Установите четкое время ожидания сеанса для сеансов, запущенных событиями. В отличие от диалоговых сеансов, нет пользователя для расширения взаимодействия; сеанс, который буксует после неудачного действия, не должен удерживать интервал параллельности неопределенно долго.
• Используйте пути ошибок потока для обработки ошибок создания сеанса агента. Если сеанс не может быть создан, путь ошибки должен опубликовать компенсирующее событие или создать обращение для последующих действий, а не скрывать событие.

Обработка и восстановление ошибок

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

Рекомендации по безопасности

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

Пример

Розничная компания использует Data 360 для отслеживания поведения корзины в реальном времени. Если корзина со значением выше заданного порога оставлена:

1. Data 360 определяет сигнал об оставлении и запускает запущенный поток с полезной нагрузкой события: «customerId», «cartValue», «productIds» и «abandonmentTimestamp».
2. Поток соотносит эти атрибуты с переменными сеанса Agentforce и создает новый сеанс агента. Взаимодействие с пользователем не требуется.
3. Агент оценивает журнал покупок клиента, текущие права и компоновку корзины посредством доступных действий извлечения.
4. Агент вызывает действие SelectRecoveryOffer, которое применяет соответствующий уровень скидки на основе клиентского сегмента, и действие SendProactiveNotification для доставки предложения посредством предпочтительного канала клиента.
5. Агент вызывает CreateFollowUpTask для регистрации взаимодействия в CRM для доступности ответственного за организацию.
6. Сеанс закрывается автоматически после завершения цепочки действий. Исходный код события сохраняется в журнале сеансов для отслеживания.

Контекст

LLM обучаются общедоступным данным. They have no Knowledge о продуктах, политиках, журнале обращений или контрактах вашей организации, если эти сведения не предоставлены явно во время рассуждения. Без привязки агент спросил о праве клиента на обслуживание, иначе условия определенного контракта либо галлюцинируют ответ, либо признают, что не знают. Ни один из результатов неприемлем в контексте предприятия.

Retrieval-Augmented Generation (RAG) решает эту проблему, извлекая соответствующие документы из Enterprise Knowledge store и внедряя их в контекстное окно агента до создания ответа. Агент мотивирует извлечением содержимого, например, статьи Knowledge, прошлым решением обращения, спецификацией продукта, как если бы ему была предоставлена эта информация напрямую. LLM предоставляет аргументацию; слой извлечения предоставляет факты.

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

Проблема

Агенту нужно ответить на вопрос или принять решение, которое зависит от собственных организационных Knowledge (например, политики, контракты, документация по продуктам или архивные данные обращений), не входивших в данные обучения LLM. Как агент извлекает самое актуальное содержимое во время рассуждения, обеспечивает актуальность и авторитетность извлеченного содержимого и достаточно точно вводит его в контекст, чтобы избежать шума?

Силы

При применении данной схемы ответьте на следующие вопросы

• Статично ли и редко ли обновляется содержимое Knowledge (например, руководства по продуктам) или оно постоянно меняется (например, разрешения обращений, описания запасов)? Частота обновления определяет дизайн ожидаемых приемов.
• Насколько велико содержимое? Маленькая база Knowledge может быть получена исчерпывающим образом; большая база знаний требует фрагментации, встраивания и семантической индексации для возврата только наиболее актуальных отрывков.
• Выгодно ли запросу одно сфокусированное извлечение или объединение результатов из нескольких источников Knowledge (например, документация и прошлые обращения одновременно) позволит получить более обоснованный ответ? Последнее требует ансамблевого извлечения.
• Существует ли необходимость фильтрации извлеченного содержимого по метаданным перед семантическим ранжированием, например, ограничение результатов документами, относящимися к уровню продукта или географии клиента?
• Насколько конфиденциально содержимое базы Knowledge? Извлеченное содержимое добавляется в контекстное окно LLM и влияет на реакцию агента; содержимое, которое не должно отображаться определенным пользователям, должно управляться на уровне извлечения, а не фильтроваться LLM.

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для Knowledge Grounding из Enterprise Content

Результаты

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

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

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

Рекомендации по проектированию

Руководство по платформе-агностике

• Разделите и встройте содержимое базы Knowledge с нужной детализацией. Слишком большие фрагменты разбавляют актуальность. Слишком маленькие фрагменты теряют окружающий контекст, который LLM должен правильно рассудить. Для большинства типов корпоративных документов фрагментация на уровне абзаца с накладывающимися контекстными окнами создает лучшее качество поиска.
• Считайте точность извлечения первоклассной проблемой проектирования. Внедрение неактуального содержимого в контекстное окно агента не является нейтральным. Это вводит шум, ухудшающий качество ответа. Настройте пороги извлечения и лучшие ограниченияk для баланса отзыва и точности для каждого домена Knowledge.
• Задержка принятия является действующим SLA. Если документ политики обновлен, но векторный индекс не обновлен, агент извлекает и выполняет действия по устаревшей информации. Определите допустимый допуск устаревания для каждого типа содержимого и создайте конвейеры приема.

Примечания к внедрению Salesforce

• Заполните векторные индексы Data 360 посредством соответствующего ожидаемого приема для частоты обновления содержимого. Используйте пакетный прием для статических документов и потоковый или изменение сбора данных (CDC) для записей, которые меняются постоянно.
• В поле «Ретриверы ансамблей» настройте веса рейтинга релевантности для каждого источника. Индекс разрешенных обращений может нуждаться в предвзятости погрешности; индекс документации политики может не требоваться. Настройте веса на основе типов запросов, которые должен обрабатывать агент.
• Используйте фильтры метаданных в настраиваемых Apex или извлекателях потоков для масштабирования извлечения перед выполнением семантического поиска. Фильтрация по строке продукта, региону или типу документа перед ранжированием уменьшает шум и повышает точность вводимых данных в контекст.
• Не вводите полный извлеченный документ в контекст LLM. Передайте только соответствующие фрагменты или фрагменты. Крупные вливания контекста расходуют бюджет маркера, увеличивают задержку и уменьшают долю контекстного окна, доступного для рассуждений агента.

Обработка и восстановление ошибок

• Если извлечение не возвращает результатов, верните четкий статус «результаты не найдены» вместо продолжения безосновательной работы. Потом агент может развернуть запрос, обратиться к пользователю за разъяснениями или перейти к человеку.
• Каждый возвращенный фрагмент извлекателей содержит оценку релевантности. В зависимости от сценария использования, определенное значение надежности/актуальности порога должно быть настроено, выше которого агент должен считать извлечение уверенным, иначе оно должно вернуться к разъяснению или расширению.
• Если векторный индекс или служба извлечения временно недоступны, действие ретривера или выноска Apex должны вернуть структурированную ошибку с описательной причиной. Зарегистрируйте ошибку с кодом сеанса и запросом, чтобы можно было определить пробелы в извлечении и отслеживать индекс или службу на наличие.
• Для доменов Knowledge с учетом времени внедрите проверку свежести как часть ответа на извлечение. Если последний совпадающий документ был обновлен сверх заданного порогового значения, пометьте его агенту, чтобы он мог определить свой ответ или запрос на проверку.

Рекомендации по безопасности

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

Пример

Агент финансовых услуг обрабатывает запрос клиента о штрафах за досрочное погашение срочного накопительного продукта:

1. Клиент спрашивает: "Какой штраф будет, если я заберу свои средства на полгода раньше?"
2. Агент вызывает действие отдельного ретривера, настроенное по векторному индексу документов условий продукта.
3. Ретривер выполняет семантический поиск посредством контекста запроса, например, типа продукта и организации клиента, а также конкретного вопроса и возвращает три наиболее актуальных фрагмента документа - условие досрочного выкупа, таблицу расчета штрафа и исключения, применимые к случаям трудностей.
4. Извлеченные фрагменты добавляются в контекстное окно агента вместе с вопросом клиента.
5. Агент мотивирует извлечение условий, определяет применимый размер штрафа для уровня продукта клиента и временной шкалы выкупа и возвращает точный, обоснованный политикой ответ, ссылаясь на дату вступления в силу использованных условий.
6. Идентификаторы документов извлеченных фрагментов регистрируются с записью сеанса для проверки.

Контекст

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

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

Например, прежде чем агент по ценообразованию вызовет действие «GenerateQuote», конфигурация субагента автоматически впрыскивает значение сегмента, уровня и срока действия клиента из объединенного профиля. Действие получает проверенные факты, а не аппроксимации LLM, и смета привязана к фактическим коммерческим отношениям клиента.

Это не альтернатива схеме Knowledge Grounding from Enterprise Content. Хорошо разработанный агент может использовать оба варианта: «Knowledge Grounding from Enterprise Content» предоставляет Knowledge на основе документа, в то время как «Проверенная вставка контекста клиента» устанавливает личность клиента.

Проблема

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

Силы

При применении данного шаблона ответьте на следующие вопросы:

• Какие параметры ввода действий представляют характерные для клиента факты, которые, если они будут выведены, а не получены, приведут к некорректным или непоследовательным результатам?
• Доступны ли обязательные атрибуты профиля в качестве стандартных полей объединенного профиля Data 360 или они требуют вычисленных важных данных, полученных из исходных поведенческих и транзакционных данных?
• Как часто меняются соответствующие атрибуты профиля? Такие атрибуты, как оценка риска оттока или тенденция CSAT требуют гарантии свежести; устаревшие данные профиля приводят к тем же некорректным результатам, что и галлюцинированные данные.
• Следует ли впрыскивать атрибуты профиля во время создания сеанса (постоянно в течение сеанса) или извлекать новые в момент вызова действия (для отображения изменений состояния в середине сеанса)?
• Нужно ли агенту рассуждать над атрибутами профиля напрямую или они используются только действием и непрозрачны для цикла рассуждений агента?

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для проверенного внедрения контекста клиента

Результаты

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

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

Объединенный профиль Data 360 остается авторитетным источником фактов клиента. Конфигурация субагента или связанный поток является швом интеграции. Агент отвечает за аргументацию этих фактов и выбор действий, а не за источник самих фактов.

Рекомендации по проектированию

Руководство по платформе-агностике

• Определите все вводные данные действий, несущие риск галлюцинаций, где вывод LLM может привести к неправильному результату вместо проверенного значения. Входные данные с риском галлюцинаций являются кандидатами на заземление профиля. Не каждый ввод требует заземления; перезагрузка данных профиля добавляет шум в контекстное окно агента.
• Рассматривайте свежесть профиля как дизайнерское решение, а не как запоздалую мысль. Определите допустимый допуск устаревания для каждого заземленного атрибута и выберите соответствующий механизм впрыска: соотнесение уровня сеанса для стабильных атрибутов, обновление на основе потока для неустойчивых.
• Вычисленные важные данные должны кодировать бизнес-логику, а не исходные показатели. Рассуждения агента над “churnRiskScore” 0,87 более эффективны, чем рассуждения агента над 14 исходными поведенческими сигналами. Вычислите толкование в Data 360; передайте результат агенту.

Примечания к внедрению Salesforce

• Заземление профиля вызывает столько же доверия, сколько и стоящее за ним объединение. Например, значение объединенного профиля полностью зависит от качества разрешающей способности при опознавании в нисходящем направлении. Если у клиента есть фрагментированные удостоверения в исходных системах, которые не были объединены, атрибуты профиля, получаемые агентом, будут неполными или они представляют только частичное представление (например, значение срока действия, вычисляемое на основе данных из одного канала, но не из другого).
• Для связанных потоков Data 360 используйте элемент получения записей с фильтром по «recordId» или «accountId» текущего сеанса для извлечения только соответствующей записи профиля. Возвращает только атрибуты, обязательные для действия в нисходящем направлении; не возвращайте полный объект профиля.
• Вычисленные важные данные должны поддерживаться в актуальном состоянии посредством ожидаемых приемов Data 360. Настройте потоковое или близкое к реальному обновление для важных данных, используемых в срочных решениях (например, риск оттока в бизнес-процессе сохранности). Пакетно обновленные важные данные допустимы для более медленных атрибутов (например, уровень стоимости годового контракта).
• Убедитесь, что соотнесенные атрибуты профиля не нулевые перед вызовом действия. Нулевое значение «customerTier», переданное действию ценообразования, также вредно, как и галлюцинированное значение. Используйте элементы решения потока для обнаружения отсутствующих данных профиля и маршрутизации в резервную версию, которая либо извлекает стандартные параметры, либо запрашивает разъяснения.
• В конфигурации субагента соотнесите профиль атрибутов с параметрами ввода действия посредством описательных, семантически ясных имен переменных (например, «customerTier», «lifetimeValueUSD», «churnRiskScore»). LLM считывает эти имена при выборе и создании действий; неоднозначные имена ухудшают точность выбора.

Обработка и восстановление ошибок

• Если обязательный атрибут профиля нулевой или недоступный во время вызова действия, агент не должен использовать потенциально некорректный стандартный параметр. Действие должно возвращать структурированную ошибку, обозначающую отсутствующий атрибут, а агент должен либо напоминать пользователю о разъяснении, либо переходить к человеку, если он работает не в диалоговом режиме.
• Если связанный поток Data 360 не извлекает данные профиля (например, из-за прерывания обслуживания Data 360), путь ошибки потока должен вернуть структурированную ошибку агенту с определенной причиной сбоя. Агент потом может решить, нужно ли повторить попытку, продолжить работу с ослабленным взаимодействием или показать ошибку пользователю.
• Зарегистрируйте все значения атрибутов профиля, введенные при создании сеанса или вызове действия вместе с кодом сеанса. Это обеспечивает возможность восстановления любого спорного решения агента с точными фактами клиента, предоставленными агенту в то время.

Рекомендации по безопасности

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

Пример

Телекоммуникационная компания использует Agentforce для обработки разговоров о сохранении с клиентами, инициировавшими запрос на отмену.

• При открытии обращения отмены создается сеанс агента с «accountId» клиента в качестве контекста.
• Конфигурация субагента соотносит три атрибута объединенного профиля Data 360 с переменными сеанса во время создания: «customerTier» (предприятие), «lifetimeValueUSD» (42 000) и «contractRenewalDate» (60 дней).
• Вычисленные важные данные, например «churnRiskScore» (0.91, вычисляется из снижения использования, частоты билетов поддержки и тренда NPS) соотносятся в качестве дополнительной переменной сеанса посредством связанного потока Data 360, вызываемого в качестве первого этапа действия.
• Агент, теперь основанный на проверенных фактах клиента, вызывает действие «SelectRetentionOffer». Поскольку вводные данные включают «customerTier = Enterprise», «lifetimeValueUSD = 42000» и «churnRiskScore = 0,91», действие возвращает предложение сохранности максимального уровня, а не стандартное.
• Агент вызывает «PresentOffer» для доставки предложения в разговоре и «LogRetentionAttempt» для записи взаимодействия в CRM со всеми приземленными атрибутами, сохраненными для проверки.

Контекст

Данные предприятия фрагментированы. Агент, который может действовать только в соответствии с тем, что находится внутри Salesforce Platform, ограничен долей информации, необходимой для эффективного обоснования. Ответ на сервисный вопрос может потребовать чтения открытого билета клиента в Service Cloud. Подготовка предложения может потребовать извлечения файла из Google Drive. Анализ использования продуктов может потребовать запроса хранилища данных. Каждая из этих систем использует собственные API, собственную модель проверки подлинности и собственную схему данных, а стоимость написания индивидуального кода интеграции для каждой из них исторически делает подключение между агентами дорогостоящим и хрупким.

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

С точки зрения агента, подключение к Slack, базе данных структурированного языка запросов (SQL) и системе управления документами выглядит идентичным, три сервера MCP, каждый из которых открывает набор описанных, вызываемых инструментов. Агент выбирает и секвенирует их на основе их семантического описания и цели, которую он пытается достичь.

Проблема

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

Силы

При применении данной схемы ответьте на следующие вопросы:

• Требуется ли агенту доступ к системам за пределами Salesforce Platform, например, к хранилищам документов, инструментам сотрудничества, базам данных, стороннему SaaS, API которых изначально не представлены как действия Agentforce?
• Требуется ли обнаружение динамического инструмента, когда агент определяет правильную конечную точку интеграции во время рассуждения на основе текущего запроса, а не жестко программирует интеграции в конфигурации?
• Часто ли меняется интеграционный ландшафт; добавляются ли новые системы, обновляются существующие и могут ли потребоваться другие изменения, которые приведут к тому, что индивидуальный подход приведет к нерациональному обслуживанию?
• Существует ли необходимость отделить слой рассуждений агента от сведений о внедрении последующих систем, чтобы изменение API целевой системы не потребовало изменений в инструкциях агента или конфигурации подагента?
• Ответственность за целевые системы несут разные рабочие группы или поставщики, каждый из которых отвечает за раскрытие собственных возможностей, что делает модель сервера MCP со стороны поставщика более практичной, чем интеграция со стороны клиента на агента?

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для проверенного внедрения контекста клиента

Результаты

Доступная площадь поверхности агента расширяется без повышения сложности интеграции. Добавление новой внешней системы означает развертывание или настройку MCP Server для нее и отказ от написания настроенных выносок Apex или интеграций потока на агента. Уровень аргументации агента остается неизменным; он обнаруживает и вызывает новые инструменты на основе только их семантического описания.

Стандарт MCP также создает чистое разделение ответственности: рабочая группа, ответственная за систему, открывает свои возможности в качестве сервера MCP; рабочая группа агента использует эти возможности, не разбираясь во внутренних функциях системы. Эта граница уменьшает координацию над расходами по мере роста числа интегрированных систем.

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

Рекомендации по проектированию

Руководство по платформе-агностике

• Описания инструментов являются единственной основой для принятия агентом решения о вызове инструмента и способе его вызова. Напишите описания понятным языком на основе намерений, в котором будет указано, что делает инструмент, когда он применяется и что возвращает. Описание, содержащее «запрос к базе данных CRM», менее полезно, чем «извлечение открытых обращений организации в порядке приоритета для заданного кода организации». Плохие описания приводят к плохому выбору инструмента.
• Охват каждого инструмента MCP одной атомной возможностью. Инструмент, который извлекает документ, а также записывает сводку обратно в исходную систему, труднее рассуждать агенту, труднее повторить ошибку и труднее защитить, чем два отдельных инструмента. Один инструмент, одна ответственность.
• Создайте инструменты, чтобы результаты были составными вводными данными. Результат инструмента извлечения должен быть структурирован таким образом, чтобы он естественным образом соотносился с параметрами ввода инструментов действий, которые обычно следуют за ним, уменьшая работу трансформации, которую должен выполнять агент между этапами.
• Удаленные серверы MCP. Локальные двоичные установки создают сложность развертывания и версии, которая растет с увеличением количества сред агента. Удаленный сервер может быть обновлен независимо от агентов, его использующих.

Примечания к внедрению Salesforce

• Если вам нужна последовательная проверка подлинности MCP, ограничение по тарифам, проверки полезных данных во всех исходящих вызовах MCP, используйте Шлюз искусственного интеллекта, например, Шлюз мультипрограммы MuleSoft, поддерживающий серверы MCP, и настройте его, прежде чем открывать любой сервер MCP агентам.
• Используйте регистрационные данные OAuth 2.0 для всех регистрационных данных, обязательных подключениями сервера MCP. Регистрационные данные не должны отображаться в параметрах инструмента, конфигурациях действий или коде Apex.
• Некоторые инструменты MCP могут нуждаться в регистрационных данных конечного пользователя для выполнения некоторых действий в зависимости от сценария бизнес-использования (например, перевод средств). Чтобы распространить маркеры удостоверений конечного пользователя, используйте политику OAuth 2.0 «От имени впрыскивания регистрационных данных», которая в данный момент поддерживается шлюзом MuleSoft Omni.
• Для настраиваемых серверов MuleSoft MCP: определить схему инструмента MCP в спецификации MuleSoft API и зарегистрировать конечную точку сервера в каталоге инструментов Agentforce. Протестируйте описания инструментов по запросам репрезентативных агентов, чтобы убедиться, что агент выбрал подходящий инструмент для правильной задачи, прежде чем развертывать в производстве.

Обработка и восстановление ошибок

• Когда вызов инструмента MCP возвращает ошибку, агент проверяет машиночитаемый код ошибки для определения соответствующего действия восстановления: запрос отсутствующих параметров у пользователя, повторная попытка с исправленным вводом или расширение до человека. Он никогда не использует ошибки молча или продолжает рассуждения, как если бы вызов инструмента удался.
• Агент реализует логику повторной попытки для переходных сбоев напрямую.
• Зарегистрируйте каждый вызов инструмента MCP со стороны клиента, указав имя инструмента, санитарные параметры ввода и результат. Эта клиентская трассировка в сочетании с серверными журналами является основным механизмом для определения причин, по которым агент выбрал определенный путь действия, если бизнес-правило не приводит к ожидаемому результату.

Рекомендации по безопасности

• Все исходящие подключения сервера MCP проходят через шлюз. Шлюз применяет проверку подлинности, ограничение частоты для предотвращения злоупотребления инструментом и проверку полезных данных для обнаружения попыток быстрого внедрения в параметрах инструмента. Прямые непромежуточные подключения агентов к серверам MCP обходят эти элементы управления и не разрешены.
• Охватите подключения сервера MCP каждого агента только к серверам, инструменты которых действительно требуются этому агенту. Агент, настроенный с доступом ко всем доступным серверам MCP, имеет большую поверхность атаки, чем поверхность атаки, связанная только с инструментами, которые требуются для его определенных задач.
• Проверьте и оздоровите параметры ввода инструмента, прежде чем передавать их инструменту, особенно если значения параметров поступают из предоставленного пользователем текста или созданного LLM содержимого. Не передавайте непроверенный вывод LLM напрямую в качестве параметров инструмента; злоумышленник, который может повлиять на рассуждения агента, может использовать этот путь для добавления вредоносных значений в системные вызовы в нисходящем направлении.
• Считайте список подключенных серверов MCP и их запасы инструментов конфиденциальной конфигурацией. Злоумышленник, знающий, какие инструменты доступны агенту и какие параметры он принимает, имеет карту для создания полезных данных быстрого введения, предназначенную для злоупотребления этими инструментами.

Пример

Торговый агент готовит всеобъемлющий брифинг организации перед ценным вызовом клиента:

1. Агент получает запрос: "Подготовьте брифинг по Acme Corp до завтрашнего обсуждения продления."
2. Агент запрашивает каталог инструментов MCP и определяет три соответствующих инструмента на двух серверах MCP: GetRecentEmails, GetOpenOpportunities и GetSupportTicketSummary.
3. Агент вызывает все три инструмента параллельно. Каждый сервер MCP переводит вызов на собственный API целевой системы, извлекает соответствующие данные и возвращает структурированный результат.
4. Агент получает три результата. Недавние потоки сообщений эл. почты, открытая возможность продления с размером сделки и этапом, сводка открытых билетов поддержки по приоритету и синтезирует их в структурированный брифинг организации.
5. Агент вызывает CreateAccountNote для сохранения брифинга в записи организации и возвращает сводку запрашивающему пользователю.
6. Все четыре вызова инструментов MCP регистрируются шлюзом с именами инструментов, удостоверениями серверов и результатами для записи проверки сеанса.

Контекст

Схема исходящего MCP описывает агента Agentforce, использующего инструменты из внешних серверов MCP. Шаблон входящего инвертирует это. Возможности Salesforce Platform, например, записи CRM, потоки, логика Apex и важные данные Data 360, открываются как инструменты MCP, которые могут обнаруживать и вызывать внешние агенты, выполняемые на любой инфраструктуре LLM.

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

Например, агент по закупкам партнера, созданный на основе сторонней инфраструктуры, должен проверить статус контракта поставщика в Salesforce, прежде чем утверждать заказ на покупку. Вместо создания прямой интеграции REST, он вызывает инструмент GetContractStatus на сервере Salesforce MCP. Инструмент применяет те же средства управления доступом, что и любая нативная операция Salesforce; вызывающему агенту отображается только результат.

Проблема

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

Силы

При применении данной схемы ответьте на следующие вопросы:

• Внешние агенты, которым нужно использовать возможности Salesforce, созданы на основе инфраструктур, поддерживающих стандарт MCP? В противном случае, REST API или вебхук-подход может быть более подходящим, чем MCP.
• Какие возможности Salesforce должны быть открыты - извлечение данных только для чтения, операции записи, вызовы потоков или их сочетание? Масштабы воздействия напрямую определяют область поверхности безопасности, подлежащую управлению.
• Как следует проверить подлинность внешнего агента вызова и под какими полномочиями Salesforce должны выполняться его вызовы? Вызовы платформы Agent-to- Platform не должны наследовать более широкие полномочия, чем требуется для конкретной операции.
• Предназначен ли сервер Salesforce MCP для внутренних потребителей (агентов других рабочих групп в одной организации) или внешних потребителей (агентов-партнеров и клиентов)? Модель Trust и требования к проверке подлинности существенно отличаются между этими аудиториями.
• Как будет развиваться набор открытых инструментов в динамике? Новые возможности Salesforce, добавленные на сервер MCP, немедленно обнаруживаются всеми подключенными агентами; непреднамеренный доступ к инструменту должен регулироваться посредством процесса преднамеренной публикации.

Приложение схемы Salesforce

Эскиз

Диаграмма последовательности для бизнес-возможностей в качестве инструмента вызова

Результаты

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

С Headless 360 модель полномочий Salesforce управляет каждым входящим вызовом инструмента. Внешние клиенты MCP не обходят существующие элементы управления доступом к данным, они действуют в них. Это значит, что состояние безопасности предоставления возможностей посредством MCP эквивалентно их предоставлению посредством любой другой проверенной поверхности API.

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

Рекомендации по проектированию

Руководство по платформе-агностике

• Опубликуйте только то, что нужно внешним агентам. Каждый инструмент, добавленный в каталог сервера MCP, расширяет поверхность атаки и нагрузку на управление. Проверьте запас инструмента намеренно. Определите, какие возможности утверждены для внешнего потребления, и обрабатывайте неутвержденную экспозицию как пробел в конфигурации, а не по умолчанию.
• Напишите описания инструментов для внешних потребителей. Оператор внешнего агента не знает Knowledge о модели внутренних данных или правилах наименования. Поддерживайте самостоятельность описаний: что делает инструмент, что означает каждый параметр, что представляет результат и каким ограничениям или предпосылкам должен соответствовать абонент.
• Инструменты версии явно при изменении схем ввода или вывода. Внешний агент, зависящий от текущей схемы инструмента, будет молча ломаться, если схема изменится без предупреждения. Обращайтесь со взломом изменений в интерфейсе инструмента MCP с той же дисциплиной, что и со взломом изменения общедоступного REST API.

Примечания к внедрению Salesforce

• Выполните каждый входящий стандартный вызов инструмента Salesforce (OOTB) MCP (Headless 360) под конечным пользователем, чьи полномочия ограничены только операциями, необходимыми для открытых инструментов. Не выполняйте входящие вызовы агентов под удостоверением администратора с высокими правами.
• Чтобы последовательно применять проверку подлинности, ограничение уровня, проверку схемы и обнаружение персональных данных (PII) во всех инструментах MCP, используйте Шлюз искусственного интеллекта, например, шлюз мультипрограммы MuleSoft.
• Для фасадов MuleSoft MCP определите схему инструмента MCP в MuleSoft независимо от основной схемы Salesforce API. Интерфейс MCP должен отражать концептуальную потребность вызывающего агента, а не форму поддерживающего его объекта Salesforce. Это разделение позволяет внедрению Salesforce развиваться без нарушения контракта внешнего инструмента.

Обработка и восстановление ошибок

• Ошибки вызова инструмента должны возвращать структурированные ответы ошибок MCP с машиночитаемым кодом и простым описанием. Вызывающий внешний агент не имеет доступа к внутренним данным Salesforce Platform, например, сообщения об ошибках должны быть автономными и действенными, не требуя Knowledge кодов ошибок Salesforce или моделей объектов.
• Ошибки ограничения частоты и сбои проверки подлинности должны быть возвращены быстро с достаточным количеством информации, чтобы оператор внешнего агента мог диагностировать и исправить, какое ограничение частоты было достигнуто или какие регистрационные данные были отклонены без предоставления сведений о внутренней конфигурации.
• Зарегистрируйте все входящие вызовы инструментов MCP на шлюзе мультиканала с помощью удостоверения вызывающего агента, вызываемого инструмента, параметров ввода (проверенных конфиденциальных значений) и результата. Этот журнал является основным журналом доказательств для диагностики сбоев, сообщенных внешними потребителями, и для проверки того, к чему имели доступ внешние агенты.

Рекомендации по безопасности

• Каждое входящее подключение MCP должно пройти проверку подлинности, прежде чем любой инструмент будет доступен. Не разрешайте непроверенное обнаружение каталога инструментов; список открытых возможностей сам по себе является конфиденциальной информацией.
• Примените авторизацию на уровне инструмента в дополнение к проверке подлинности на уровне подключения. Зарегистрированный внешний агент должен иметь возможность вызывать только определенные инструменты, к которым ему был предоставлен доступ, а не полный каталог. Внедрите это на шлюзе, а не на уровне приложения.
• Проверьте и оздоровите все входящие параметры инструмента, прежде чем передавать их в операции Salesforce Platform. Параметры от внешних агентов являются ненадежной поверхностью ввода - злонамеренно созданный параметр может попытаться переопределить фильтры запросов, внедрить фрагменты языка запросов объекта Salesforce (SOQL) или повлиять на переменные потока. Проверьте тип, формат и диапазон на границе сервера MCP или фасада.
• Периодически проверяйте доступ зарегистрированных внешних потребителей. Отмените регистрационные данные для агентов, которые больше не активны или чья область доступа изменилась. Недействующие, но действительные регистрационные данные для незадействованной интеграции партнера - это ненужный постоянный риск.
• Защитите от нарушения ограничений платформы, ограничивая частоту входящих сообщений MCP в шлюзе. Сократите трафик некритичных агентов при загрузке посредством политик уровней на основе SLA.

Пример

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

1. Агент партнера проходит проверку подлинности в шлюзе с помощью зарегистрированных регистрационных данных клиента OAuth 2.0 и получает маркер доступа.
2. Агент запрашивает каталог инструментов сервера Salesforce MCP и определяет два соответствующих инструмента: GetSupplierContractStatus и GetAccountCreditSummary.
3. Агент вызывает GetSupplierContractStatus с идентификатором поставщика. Сервер MCP переводит это в запрос записи Salesforce, применяет безопасность поля пользователя интеграции и возвращает текущий статус контракта, дату истечения срока действия и любое помеченное соответствие.
4. Агент вызывает GetAccountCreditSummary, перенаправляющую через фасад MuleSoft MCP. Фасад агрегирует непогашенный баланс счета поставщика и журнал оплаты из двух объектов Salesforce и возвращает одну составную кредитную сводку.
5. При наличии обоих результатов агент партнера определяет активность контракта и кредитную позицию в допустимых пределах, а также утверждает заказ на покупку в собственной системе.
6. Оба вызова инструмента регистрируются шлюзом с удостоверением агента-партнера, вызываемыми инструментами и результатами, создающими проверяемую запись того, какой внешний доступ был предоставлен и какие данные были возвращены.

Контекст

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

Проблема

Каким образом агент на основе искусственного интеллекта может динамически обнаруживать, безопасно взаимодействовать и делегировать сложные или доменные задачи удаленному агенту-коллеге, который может быть создан на другой основе или эксплуатироваться другим поставщиком и получать структурированные результаты для выполнения более крупного бизнес-правила предприятия?

Силы

При применении данной схемы ответьте на следующие вопросы:

• Как взаимодействуют агенты, разработанные посредством разных инфраструктур или функционирующие в изолированных средах приложений?
• Как агенты могут сотрудничать и делегировать задачи, не открывая внутреннюю логику, память или собственные инструменты?
• Каким образом агенты поддерживают сложные и долгосрочные задачи, предоставляя обновления состояния в реальном времени, потоковые и всплывающие уведомления?
• Каким образом агенты внедряют безопасность корпоративного уровня (проверку подлинности, авторизацию) и соблюдение политик для межагентской связи?
• Как агенты обрабатывают структурированные бизнес-процессы задач (инициация, продвижение, завершение), выходящие за рамки простых вызовов API?

Приложение схемы Salesforce

Протокол A2A - это открытый стандарт, позволяющий агентам находить, делегировать другим агентам полномочия и сотрудничать с ними в качестве коллег. Он предоставляет общий язык для агентов для безопасного обмена информацией и координации действий на разных платформах и у разных поставщиков. A2A фокусируется на одноранговом общении, дополняя MCP, которое фокусируется на подключении агентов к инструментам и API.

Эскиз

Архитектура предполагает инициирование коммуникации вызывающим агентом при содействии каталога/реестра агентов для обнаружения:

Диаграмма последовательности для делегирования кросс-агентов

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

Результаты

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

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

Рекомендации по проектированию

Руководство по платформе-агностике

• В сложных сценариях брокер-агент может действовать как интеллектуальная служба маршрутизации или «интеллектуальный коммутатор» для координации делегирования задач между специализированными агентами и управления многоэтапными процессами.
• Поскольку A2A поддерживает долгосрочные задачи, коммуникация должна быть ориентирована на выполнение задачи, определение жизненного цикла для объекта задачи и предоставление обновлений состояния в реальном времени и уведомлений.
• Протокол предназначен для поддержки разных типов содержимого, включая текст, файлы, структурированные данные, потоковое аудио и видео.
• Взаимосвязи и зависимости между агентами и их возможностями декларативно определяются в файле конфигурации (например, Agent-network.yaml) и публикуются в реестре агентов.

Примечания к внедрению Salesforce

• Для эффективной оркестрации SOMA держите подключенных субагентов ниже 7, чтобы сохранить качество маршрутизации.
• В настоящее время поддерживается только один слой делегирования (суперагент → субагент); более глубокие цепочки приводят к «несостоятельной частоте» задержки. В настоящее время субагенты не могут делегировать полномочия другим подключенным субагентам.
• Человеческая передача поддерживается только на уровне оркестранта; субагенты не могут расширяться.
• В SOMA используйте сценарий агента, когда маршрутизация на основе LLM создает неправильную маршрутизацию на неоднозначных вводных данных для детерминистской маршрутизации. Сценарий агента включает курируемый общий контекст между агентами.

Обработка и восстановление ошибок

Протокол A2A определяет комплексные коды ошибок для облегчения надежной отладки и управления ошибками.

• Логика восстановления: Агенты должны внедрить политики повторов (повторов), логику отказа альтернативным способным агентам и четкие сроки ожидания.
• Отслеживание состояния задачи: Бизнес-правило управления задачами обеспечивает синхронизацию агентов с последним статусом задачи, облегчая восстановление в случае прерывания.
• Обозримость: Регистрация сведений о взаимодействии, например, задержка, уровень успеха и частота ошибок, важна для мониторинга качества и устранения неполадок.

Рекомендации по безопасности

• Проверка подлинности предприятия: A2A разработана для соответствия стандартам проверки подлинности и авторизации корпоративного уровня, например, OAuth 2.0 и JWT, часто управляемым внешними платформами, например Okta.
• Шлюз для защиты A2A: Шлюз (например, шлюз мультипрограммы MuleSoft) необходим для внедрения политик во всех коммуникациях A2A, выступая в качестве шлюза входа и выхода для защиты агентов и управления исходящим трафиком внешним агентам и службам.
• Применение политики: Перезапись карты агента, проверка схемы, управление всплывающими данными, детектор персональных данных и другие политики должны применяться к серверу A2A и защите данных.

Пример

Бизнес-процесс поиска кандидатов

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

1. Discovery: Агент оркестранта запрашивает реестр агентов и обнаруживает специализированного агента по подбору кадров и агента по проверке подлинности (оба коллегиальных агента).
2. Делегация (A2A): Агент оркестранта отправляет структурированный запрос задачи (сообщение A2A) агенту по подбору кадров исходным кандидатам.
3. Обработка коллег: Агент по подбору кадров выполняет собственный бизнес-правило (например, вызов внешнего инструмента LinkedIn посредством MCP).
4. Возврат артефактов (A2A): Агент по подбору кадров возвращает список предложенных кандидатов (артефакт).
5. Последовательное делегирование: Агент оркестранта потом делегирует еще одну задачу (A2A) агенту фоновой проверки лучшего кандидата. Этот агент выполняет проверку и возвращает результат, выполняя общую задачу.

Контекст

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

Проблема

Как внутренний специализированный агент на основе искусственного интеллекта (например, агент фоновой проверки в Agentforce) может безопасно предоставить внешним одноранговым агентам доступ к функциям домена, обработать входящий структурированный запрос A2A и управлять жизненным циклом задачи (включая обновления статуса в реальном времени) для возврата структурированных артефактов удаленному агенту вызова?

Силы

При применении данной схемы ответьте на следующие вопросы:

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

Приложение схемы Salesforce

Протокол A2A обеспечивает открытый стандарт для безопасного и коллегиального делегирования полномочий и сотрудничества. Внутренний агент выступает в качестве коллегиального агента, рекламируя свои возможности посредством каталога/реестра агентов и используя A2A по защищенным каналам (HTTPS/SSE) для получения и ответа на структурированные запросы.

Эскиз

Диаграмма последовательности для агентов в качестве вызываемых служб

Результаты

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

Рекомендации по проектированию

Руководство по платформе-агностике

• Шлюз (например, шлюз мультипрограммы MuleSoft) должен быть расположен в качестве точки входа для внедрения политик, включительно с ограничением скорости, проверкой подлинности и проверкой полезных данных, во всех входящих запросах A2A.
• Внутренние агенты должны управлять состоянием объекта задачи от внешней инициализации до завершения, обеспечивая получение агентом удаленного вызова последовательных, проверяемых обновлений статуса.
• Убедитесь, что опубликованные возможности агента в карте агента четкие, основаны на намерениях и содержат необходимые области безопасности для делегирования.

Обработка и восстановление ошибок

• Коды структурированных ошибок: В случае сбоя внутренний агент должен вернуть агенту, совместимому с A2A, структурированные сообщения об ошибках для включения удаленной логики повтора или альтернативных механизмов сбоя.
• Идемпотентность: Агент должен проверить, являются ли побочные эффекты, запущенные повторным запросом A2A от внешнего агента (из-за прерывания или восстановления сети), неэффективными.

Рекомендации по безопасности

• Применение входящей политики: Шлюз должен внедрить политики для добавления в список разрешенных/блокированных внешних агентов и проверки маркеров JWT/OAuth 2.0 для проверки подлинности и делегированных полномочий вызывающего агента.
• Санитаризация ввода: Проверьте и оздоровите все полезные данные входящих запросов, чтобы предотвратить потенциальное быстрое внедрение или вредоносные атаки данных.
• Распространение удостоверений: Безопасно соотнесите личность внешнего агента и делегированные ему полномочия с контекстами внутренней безопасности (например, профилями пользователей Salesforce), прежде чем выполнять действия против внутренних систем.

Пример

Запрос внешней системы

1. Запрос: Агент по подбору кадров в партнерской системе отправляет запрос задачи A2A внутреннему агенту по проверке сотрудников (коллеге-агенту) в Agentforce для подтверждения статуса занятости нового кандидата.
2. Обработка: Агент проверки сотрудника получает запрос через шлюз, проверяет регистрационные данные агента-партнера, выполняет внутренний бизнес-правило (например, вызов внутренней системы управления персоналом) и форматирует ответ.
3. Ответ: Коллеги-агенты возвращают структурированный артефакт A2A (например, дата начала работы и должность) удаленному агенту по подбору кадров, который затем выполняет внешний бизнес-правило.

1. Шлюз для защиты MCP, A2A и API

   Шлюз обязателен в качестве единой точки внедрения для всего трафика между агентами и между системами.

• Безопасные подключения: Шлюз обеспечивает взаимодействие только проверенных и авторизованных агентов с конечными точками MCP, A2A и API, ограничивая доступ.

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

• Упрощенное управление: Шлюз предлагает централизованную видимость и контроль над всеми взаимодействиями сервера, упрощая управление действиями агента и мониторинг.

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

Шлюз мультиканала MueleSoft

2. Цепочка распространения удостоверений

По мере внедрения предприятиями агентурной парадигмы возникает новая проблема безопасности: Каким образом удостоверение конечного пользователя проходит через сеть автономных агентов на основе искусственного интеллекта? В традиционных архитектурах API пользователь проходит проверку подлинности один раз, и приложение вызывает фоновые службы от имени пользователя. Цепочка удостоверений коротка, понятна и обычно управляется в одном домене Trust.

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

MuleSoft решает проблемы распространения удостоверений посредством функции «Надежное удостоверение агента». Это решение использует стратегию на основе политики, управляемую шлюзом, чтобы обеспечить сохранение подлинности конечного пользователя в разных типах взаимодействия, включительно с протоколами A2A, вызовами инструментов MCP и запросами REST API. Централизация управления удостоверениями на уровне шлюза мультиканала посредством исходящих политик проверки подлинности позволяет предприятиям обезопасить всю сеть агентов без изменения базовых служб или агентов. Дополнительные сведения см. в разделе «Удостоверение надежного агента для предприятия-агента».

3. Безопасность RAG в Data 360

Data 360 поддерживает управление доступом на основе атрибутов (ABAC) на уровне объекта, поля и строки посредством параметров политики управления данными. Это основной способ управления доступными данными, в том числе в поисковых индексах RAG. Для структурированных данных условия доступа пользователя реализуются посредством атрибутов пользователя и наборов полномочий. Для неструктурированных данных фильтрация метаданных (предварительные фильтры по поисковым индексам) может ограничить извлекаемое.

Связь с LLM осуществляется через слой Einstein Trust, который маскирует конфиденциальную информацию/PII до того, как она достигает модели, защищающей конфиденциальность данных не только во время поиска, но и до создания.

Чтобы защититься от отравления RAG, обеспечьте применение строгих правил управления данными и проверки до того, как данные станут доступны для векторного поиска. Слой Einstein Trust также может применить быструю маскировку/проверку токсичности. Вы можете применить строгие наборы полномочий к профилю пользователя-агента.

4. Создать модель именованных регистрационных данных Salesforce обновила архитектуру проверки подлинности, внедрив двухуровневую модель именованных регистрационных данных, которая четко разделяет проблемы между подключением и удостоверением. Используйте это при выполнении выносок через Apex и избегайте создания собственного протокола проверки подлинности. Эта модель также обеспечивает расширяемость и повышенную безопасность. Внешние регистрационные данные лежат в основе этой модели. Они хранят фактические сведения о проверке подлинности и поддерживают богатый набор протоколов, включительно с регистрационными данными клиента OAuth 2.0, носителем JWT и AWS Signature V4, а также определяют способ соотнесения субъектов: либо как единый именованный субъект (общий доступ для всех пользователей), либо как субъекты на пользователя (где каждый пользователь проверяет подлинность с помощью собственной идентификации). Именованные регистрационные данные, в свою очередь, выступают в качестве слоя конечной точки. Они определяют URL-адрес выноски и ссылаются на внешние регистрационные данные для обработки рукопожатия проверки подлинности, поддерживая четкую связь между конфигурацией конечной точки и управлением регистрационными данными. Чтобы включить потоки проверки подлинности для каждого пользователя, администраторы соотносят наборы полномочий с соответствующим субъектом внешних регистрационных данных, так что только пользователи с соответствующим назначением набора полномочий могут вызывать выноски под собственным именем. Этот двухуровневый дизайн не только упрощает безопасную конфигурацию выноски, но и предоставляет архитекторам гораздо большую гибкость и управление контролем над способом проверки подлинности интеграций в подключенных системах Salesforce. Дополнительные сведения см. в документации именованных регистрационных данных.

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

Контроль доступа: Модель пользователя интеграции с наименьшими правами, описанная в схемах интеграции (объем именованных регистрационных данных, области OAuth 2.0 на агента, списки разрешенных шлюза), соотносится напрямую с логическими элементами управления доступом. Подтверждайте проверку и утверждение области регистрационных данных каждого агента.

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

Управление изменениями: Изменения в схеме инструмента MCP и обновления карточки агента A2A, влияющие на потребителей, представляют собой изменения интерфейса и должны подлежать управлению изменениями. Инструменты версии явно (упоминается во входящей схеме MCP) и рассматривают всплывающие изменения как события конфигурации, требующие утверждения.

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

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

• Начало работы с API агента
• Включение надежных агентов посредством Data 360
• Общие сведения о шлюзе мультиканала MuleSoft
• Политика впрыска регистрационных данных OAuth 2.0 от имени
• Удостоверение надежного агента для предприятия-агента

Гуляль Кумар является архитектором программного обеспечения в Salesforce с более чем 20-летним опытом работы. Его опыт охватывает искусственный интеллект, интеграцию, API и архитектуру предприятия, с акцентом на стимулировании трансформации бизнеса посредством безопасных, устойчивых и инновационных решений на основе искусственного интеллекта. Свяжитесь с ним в LinkedIn.