Как Salesforce решает проблему распространения агентов с помощью Agent Fabric

Проблема, с которой сталкиваются компании

Каждое предприятие, стремящееся использовать агентный ИИ, упирается в одну и ту же стену: распространение агентов. Команды создают агентов на любой платформе, которая подходит под их задачи — Agentforce здесь, кастомная служба Python там, агент Bedrock где-то еще, — и каждый из них работает изолированно. Это создает три конкретных проблемы:

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

Agent Fabric создана именно для решения этой задачи: это единый уровень оркестрации и управления, который обнаруживает агентов и инструменты везде, где бы они ни находились, управляет доступом к ним с помощью той же структуры политик, которую MuleSoft уже использует для API, и объединяет их в единые аудируемые рабочие процессы — без необходимости перестраивать самих агентов.

Как и другие предприятия, Salesforce также сталкивается с этими трудностями. Наша собственная команда внутреннего ИТ обратилась к Agent Fabric для управления многоагентными системами. В этой статье мы расскажем о реальном внутреннем внедрении — брокере аналитики MuleOps, — чтобы показать, как это выглядит на практике.

Внедрение Agent Fabric для поддержки производства

Собственная ИТ-команда Salesforce уже использовала возможности MuleSoft, задействуя более 2 000 API и интеграционных приложений в различных внутренних бизнес-подразделениях. Толчком к созданию послужило не столько распространение агентов, сколько банальная операционная проблема, стоящая за ним: наши инженеры по эксплуатации переключались между тремя отдельными инструментами — PagerDuty для оповещений, Splunk для логов и Anypoint Platform/CloudHub для статуса приложений — просто чтобы провести триаж одного производственного инцидента. Большая часть времени уходила на навигацию по инструментам, а не на анализ проблем и их решение.

Мы использовали Agent Fabric для создания брокера аналитики MuleOps: агентной сети, которая оркестрирует трех специализированных агентов (по одному для данных приложений PagerDuty, Splunk и CloudHub) за единой точкой входа на базе чата в Slack. Вот как три основных принципа реализованы в этом решении.

1. Обнаружение

Подобно тому, как разработчики MuleSoft уже находят API-ресурсы в Anypoint Exchange, агентские ресурсы — A2A-агенты, языковые модели (LLM) и серверы MCP — публикуются и обнаруживаются аналогичным образом через Agent Registry.

Agent Fabric централизует обнаружение в единый авторитетный каталог Agent Registry, в котором хранятся все агентские ресурсы, такие как ИИ-агенты, модели LLM или MCP-серверы предприятия, со стандартизированными метаданными: «Что существует, где это находится и как подключается». После регистрации ресурсы «готовы к повторному использованию или объединению в решения» разработчиками или агентами.

Существует два пути регистрации агентских ресурсов: автоматическая регистрация с помощью Agent Scanner или гибкая ручная регистрация:

• Автоматическое обнаружение с помощью Agent Scanners — коннекторов, которые указывают на каждую поддерживаемую платформу агентов (например, AWS, Bedrock/AgentCore, Google Vertex AI, Microsoft, Databricks, Kong, Agentforce и т. д.), запускаются по расписанию или по требованию и автоматически регистрируют всех обнаруженных агентов, API и MCP-серверы в соответствующем каталоге. Обнаруженные агенты затем могут быть проверены и добавлены в реестр со стандартизированными метаданными. Вы можете просматривать результаты последнего запуска и количество ресурсов, найденных при каждом сканировании.
• Гибкая ручная регистрация — для доморощенных агентов и MCP-серверов, до которых сканер не может дотянуться, вы регистрируете их, просто вставив URL-адрес карточки агента или схемы MCP-сервера в реестр, либо просто загрузив их файлы спецификаций yaml (примечание: регистрация путем загрузки файла схемы требует постоянного контроля и обслуживания при изменении схемы).

В нашем случае после публикации агентской сети сам брокер имеет доступную для обнаружения карточку, описывающую его навыки простым языком (управление инцидентами PagerDuty, поиск по логам Splunk, мониторинг CloudHub). Каждый подчиненный специализированный агент также доступен для независимого обнаружения: команда, которой нужен только поиск по логам Splunk для не связанного с этим рабочего процесса, может запросить доступ к этому агенту напрямую, вообще минуя брокера. Создавайте один раз, используйте везде.

Как видите, модель обнаружения работает на всех уровнях — брокера, агента и инструмента. Всё на виду, всё под контролем, всё в одном месте.

2. Управление

Агентские ресурсы в Agent Fabric управляются теми же политиками API Manager и Omni Gateway — тем же шлюзом, который защищает и управляет API сегодня; не нужно изучать отдельный уровень управления. Каждый агент, MCP-сервер и прокси субагента в сети отображается как управляемый экземпляр первого класса.

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

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

3. Оркестрация — подробный разбор

Именно здесь располагается сам брокер аналитики MuleOps, и на этом сосредоточена остальная часть данной публикации.

Внутри оркестрации: что на самом деле делает брокер

Брокер описывается декларативным YAML-файлом плюс Agent Script, языком сценариев с открытым исходным кодом от Salesforce, который объединяет гибкость инструкций на естественном языке для обработки задач разговорного характера с надежностью программных выражений для обработки бизнес-правил — без пользовательских фреймворков оркестрации и написанного вручную кода маршрутизации. Вот как это выглядит.

Декларативный подход по дизайну — не нужно писать пользовательский код оркестрации

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

Сеть представляет собой YAML-файл (agent-network.yaml), в котором регистрируются каждый агент и соединение, а также файл сценария агента (Agent Script), определяющий собственную логику брокера в виде небольшого набора именованных шагов: классификатора, маршрутизатора, субагента для каждого специалиста и ответов, которыми заканчивается каждый путь. Фактически вы создаете системные промпты и инструкции: на что должен обращать внимание классификатор, что разрешено делать каждому специалисту, как должен быть сформулирован ответ. Инструментарий MuleSoft преобразует это описание в работающий визуализированный граф — Anypoint Code Builder отображает сеть в виде интерактивной панели рядом с YAML, благодаря чему вы можете видеть триггер, классификатор, ветви маршрутизатора, каждого субагента-специалиста и каждый конечный ответ в виде соединенных узлов в режиме реального времени по мере внесения изменений.

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

После развертывания сети агентов в CloudHub команды могут использовать Agent Network Tracer, чтобы протестировать и проверить возможности сети агентов с заинтересованными сторонами до того, как тратить время на создание пользовательского интерфейса для взаимодействия с брокером. Agent Network Tracer использует те же учетные данные Anypoint и отображает подробную информацию о каждом взаимодействии с агентом.

Топология

Сеть объединяет следующие компоненты:

• Специалист PagerDuty — инциденты, оповещения, службы, команды, графики дежурств, политики эскалации.
• Специалист Splunk — поиск по логам SPL, обнаружение индексов и типов источников (sourcetype), расследование ошибок и поиск оповещений Application Data Observability (ADO).
• Агент интеграционной системы — статус приложения CloudHub, рекомендации по развертыванию, оптимизация vCore.
• Соединение с LLM Gemini, которое обеспечивает логику работы самого брокера.

Примечательно не только то, что соединено между собой, но и то, где именно работают эти компоненты. MCP-сервер PagerDuty работает на Heroku. Агенты PagerDuty и Splunk работают на AWS. MCP-сервер Splunk работает на внутренней инфраструктуре, управляемой нашей внутренней командой SRE. Агент интеграционной системы — это агент Agentforce, работающий внутри экземпляра Salesforce. Четыре разных среды выполнения, четыре разных операционных команд — и Agent Fabric управляет ими всеми как единой управляемой сетью. Совершенно неважно, где находится агент или MCP-сервер.

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

1. Память агента и многошаговые диалоги

Инциденты в сфере ИТ-оперирования редко разрешаются с помощью одного вопроса. Брокер сохраняет контекст разговора между репликами с помощью параметра contextId: пользователь может спросить «кто дежурит по службе DET-Wallarm?» и затем, в рамках той же цепочки, задать уточняющий вопрос «проверь политику эскалации по умолчанию» без повторного указания названия службы — брокер автоматически переносит этот контекст. Это превращает брокера из ботах для ответов на вопросы без сохранения состояния в нечто более близкое к настоящему коллеге по диалогу.

// Шаг 1 — ответ (иллюстративный) { "jsonrpc": "2.0", "id": "1", "result": { "task": { "contextId": "ctx-7f3a9c21", "status": { "state": "TASK_STATE_COMPLETED", "message": { "parts": [ { "text": "Джейн Доу дежурит по DET-Wallarm-Prod в соответствии с политикой эскалации по умолчанию." } ] } } } } }

# Шаг 2 — используем повторно contextId из шага 1, новый messageId CTX='ctx-7f3a9c21'

curl -X POST "$BROKER_BASE/" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -H "A2A-Version: 1.0" \ -H "client_id: $MAF_CLIENT_ID" \ -H "client_secret: $MAF_CLIENT_SECRET" \ -d '{ "jsonrpc": "2.0", "id": "2", "method": "SendMessage", "params": { "message": { "role": "ROLE_USER", "contextId": "'"$CTX"'", "messageId": "test-0002", "parts": [ { "text": "Проверь политику эскалации по умолчанию." } ] } } }'

// Шаг 2 — ответ (иллюстративный). Имя службы не повторяется — брокер // перенес «DET-Wallarm-Prod» из контекста шага 1. { "jsonrpc": "2.0", "id": "2", "result": { "task": { "contextId": "ctx-7f3a9c21", "status": { "state": "TASK_STATE_COMPLETED", "message": { "parts": [ { "text": "Политика эскалации по умолчанию для DET-Wallarm-Prod сначала направляет запрос Джейн Доу, а затем менеджеру по дежурствам через 15 минут." } ] } } } } }

2. Поддержка протокола A2A для агентов Agentforce, регулируемая политиками

Агент интеграционной системы — это не то, что мы создали специально для этого проекта; это сервисный агент Agentforce, который мы создали и выпустили 2 года назад, задолго до того, как Agent Fabric появился как возможный вариант. Мы не переписывали его и не меняли в нем ни единой строки кода. Мы добавили его в сеть как есть, по протоколу A2A через A2A policy for Agentforce, и его существующие навыки стали доступны наряду со специалистами PagerDuty и Splunk без каких-либо доработок со стороны Agentforce.

Это существенная часть ценностного предложения для предприятий, у которых агенты уже рассредоточены по платформам разных вендоров: Agent Fabric не требует стандартизации на базе какого-то одного фреймворка агентов. Любой агент, поддерживающий протокол A2A — независимо от того, где он был создан и кому принадлежит, — может управляться с помощью тех же политик Omni Gateway, что и все остальное, и встраиваться в граф оркестрации.

3. Сценарии агентов (Agent Script) для детерминированных рабочих процессов

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

• Узел генератора классифицирует входящий запрос в типизированный маршрут (PagerDuty / Splunk / платформа интеграции / общий вопрос / вне зоны ответственности / требуется уточнение) — один недорогой вызов LLM без доступа к инструментам, поэтому он не может ответить самостоятельно.
• Затем узел маршрутизатора выполняет детерминированное ветвление на основе этой классификации — никаких дополнительных вызовов LLM, никакой двусмысленности относительно того, какой специалист должен быть задействован. В данном случае маршрутизатор проверяет префикс входящего сообщения. Если сообщение удовлетворяет одному из условий, указанных в маршрутизаторе «fastPath», оно направляется напрямую соответствующим субагентам без обращения к вызову LLM брокера.
• Каждый специалист имеет собственный выделенный узел субагента с жесткой инструкцией вызывать назначенное ему действие и никогда не отвечать на основе собственных знаний — это предотвращает распространенный сценарий сбоя, когда оркестратор «отвечает» на вопрос без фактической проверки исходной системы.

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

4. Коммуникация между агентами по принципу «нулевого доверия» (Zero Trust)

Каждое соединение в сети проходит аутентификацию независимо — между брокером и его собственными субагентами нет неявного доверия только потому, что они являются частью одной сети. Конкретно: ни один потребитель, включая самого брокера, никогда не обращается напрямую к среде выполнения агента или сервера MCP. Каждый вызов проходит через управляемый прокси-сервер Flex Gateway перед этой средой выполнения. Брокер не хранит учетные данные для систем, с которыми он взаимодействует — Agent Fabric внедряет нужные учетные данные на уровне прокси во время вызова, а эти секреты хранятся в Anypoint Control Plane и никогда не попадают в код оркестрации.

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

Другими словами, брокер никогда не хранит никаких секретов. Когда ему нужно связаться с агентом Splunk, он не передает учетные данные. Agent Fabric автоматически внедряет правильные учетные данные на уровне прокси во время выполнения. Секреты управляются в Anypoint Control Plane и никогда не зашиваются жестко в логику оркестрации.

Это обеспечивает взаимодействие агентов по принципу нулевого доверия (zero-trust). Даже внутренние вызовы между брокером и его собственными субагентами полностью аутентифицируются. А поскольку у каждого агента есть свой прокси-сервер, вы можете применять политики, специфичные для конкретного агента — например, ограничивать скорость ИИ-трафика иначе, чем трафик разработчиков-людей, — не затрагивая других потребителей.

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

5. Единый интерфейс Slack для всех возможностей брокера

Все это не имеет значения для инженера по эксплуатации, если для работы по-прежнему требуется три разных входа. Перед брокером находится интеграция со Slack: инженеры упоминают брокера в своем существующем операционном канале, задают вопрос на естественном языке и получают ответ прямо в трэде — охватывая PagerDuty, Splunk и CloudHub, не покидая Slack. Им не нужно входить в PagerDuty. Им не нужно открывать Splunk. Им не нужно просматривать Anypoint Platform. Один интерфейс, возможности трех систем — в канале, где команда уже ведет совместную работу.

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

Почему это важно за пределами одного брокера

Сегодня живой агент задает вопрос MuleOps Intelligence Broker в Slack. Завтра другой агент или автоматизированный рабочий процесс сможет вызывать тот же самый брокер программно — сантехника (инфраструктура) не меняется. В этом и суть: это не разовая интеграция, а многократно используемый паттерн. Добавление нового агента в сеть означает его регистрацию и настройку политик шлюза; Agent Fabric занимается созданием прокси, привязкой учетных данных и маршрутизацией. Каждый агент становится подключаемым, самостоятельно защищенным активом, а существующие инвестиции в агентов (например, агент Agentforce, созданный за год до появления Agent Fabric) не выбрасываются, а используются повторно.

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

Для Salesforce в этом и заключается выгода. Сегодня инженеры поддержки тратят около 15 минут активного времени на одно оповещение, что составляет примерно 550 часов в месяц или 6600 часов в год. Устраняя переключение между инструментами и ручной сбор диагностических данных, описанные в начале этой статьи, MuleOps Intelligence Broker стремится к среднему времени обработки в 10 минут на одно оповещение. Это позволило бы вернуть команде примерно треть этих затрат труда — около 2200 часов в год.