Einen Account-Recherche-Agenten in Salesforce Agentforce mit Bright Data erstellen

Die Kontorecherche vor einem Kundengespräch dauert für einen Vertriebsmitarbeiter oft zehn bis fünfzehn Minuten. Der Ablauf ist größtenteils manuell: Ein Mitarbeiter verlässt Salesforce, öffnet Google, durchsucht mehrere Tabs und fügt die Ergebnisse in ein Notizfeld ein. Der Großteil der Arbeit besteht aus Suche und Synthese.

Bright Data’s Web Unlocker liefert sauberes Markdown von den meisten öffentlichen URLs. Die Integration in Salesforce Agentforce ermöglicht es einem Mitarbeiter, Kontorecherchen über eine Chat-Eingabe mit zugeordneten Quellen abzurufen, ohne Salesforce zu verlassen. Unter der Haube besteht der Aufbau aus einem Agentforce-Subagenten, drei Apex-Klassen und einem kleinen Cloudflare Worker Proxy.

TL;DR

• Ein Agentforce-Subagent nimmt eine Eingabe in natürlicher Sprache von einem Vertriebsmitarbeiter entgegen, ruft Bright Data Web Unlocker auf und gibt ein Konto-Briefing mit zugeordneten Quellen zurück – alles innerhalb des Salesforce-Chats.
• Apex’s HTTP-Client schlägt ohne Warnung bei Chunked-Transfer-Antworten über wenigen Kilobyte fehl (verifiziert auf API v66.0), daher leitet die Integration über einen kleinen Cloudflare Worker, der puffert und mit einem expliziten Content-Length-Header erneut bereitstellt.
• Agentforce’s Canvas-UI verbirgt das is_user_input: True YAML-Flag, das für chat-gesteuerte Agenten erforderlich ist, um aus Prompts extrahierte Eingaben zu empfangen. Die Lösung liegt im Script-Modus.
• Salesforce’s aktuelles External Credential-Muster teilt sich in drei Objekte auf (External Credential, Named Credential, Permission Set), mit einem leicht zu übersehenden Kontrollkästchen, das bei Auslassung 401 zurückgibt.
• Agentforce schwärzt externe URLs aus Agenten-Antworten standardmäßig aus. Der Agent liest sie intern, zeigt sie aber nur an, wenn die Domain auf der Trusted URLs-Allowlist steht.
• Der Gesamtumfang beträgt etwa 6 KB Apex, einen Cloudflare Worker, drei Salesforce-Credential-Objekte und einen Subagenten. Jeder Codeblock wurde in einer Live-Salesforce Developer Edition-Org getestet.

Bevor Sie beginnen

Sie benötigen vier Konten und Tools, alle kostenlos für dieses Tutorial:

• Ein Bright Data-Konto mit mindestens einer bereitgestellten Web Unlocker-Zone. Neue Konten enthalten kostenlose Testguthaben, und das Anfragevolumen des Tutorials passt problemlos in diese Guthaben.
• Ein Cloudflare-Konto für den Worker Proxy. Für den kostenlosen Tarif ist keine Kreditkarte erforderlich; Sie wählen bei der ersten Nutzung eine workers.dev-Subdomain.
• Eine Agentforce-fähige Salesforce Developer Edition-Org. Aktuelle Developer Edition-Orgs werden mit Agentforce, Data Cloud und dem Agentforce Studio vorinstalliert geliefert. Überprüfen Sie, ob die Agentforce Studio-App in Ihrem App Launcher erscheint, bevor Sie über Teil 5 hinausgehen; wenn nicht, haben Sie eine Org ohne Agentforce, und die späteren Teile werden nicht funktionieren.
• Eine Möglichkeit, eine Test-HTTP-Anfrage zu senden. Teil 2 enthält einen curl-Befehl zur Überprüfung des Workers. macOS, Linux und Windows 11 werden mit curl geliefert. Wenn Sie lieber eine GUI verwenden möchten, funktionieren Postman oder Insomnia mit denselben Headern und dem gleichen Body. Wenn Sie keines davon haben und keines installieren möchten, können Sie den eigenständigen Worker-Test überspringen und stattdessen in Teil 3 von Salesforce aus End-to-End validieren.
• System Administrator-Profil (oder eines mit Author Apex, Modify All Data und Customize Application). Eine neue Developer Edition-Org gibt Ihnen dies automatisch. Wenn Sie in einer Unternehmens-Sandbox mit einem eingeschränkten Profil arbeiten, wechseln Sie stattdessen zu einer neuen Developer Edition-Org.

Was Sie erstellen werden

Sie werden einen Agentforce-Agenten namens Account Briefing Agent erstellen. Ein Mitarbeiter gibt eine Frage in natürlicher Sprache ein. Der Agent leitet den Prompt an einen benutzerdefinierten Subagenten weiter, wählt die richtigen Tools aus, ruft Bright Data über einen schlanken Cloudflare Worker Proxy auf, synthetisiert ein Konto-Briefing mit zugeordneten Quellen und veröffentlicht das Briefing im Chat. Die Architektur besteht aus fünf Teilen:

• Bright Data Web Unlocker als Web-Daten-Primitive. Es ist ein einzelner Endpunkt, der die meisten URLs entgegennimmt und sauberes Markdown zurückgibt.
• Cloudflare Worker als Proxy zwischen Salesforce und Bright Data. Der kostenlose Tarif deckt ein kleines Team ab.
• Salesforce External Credential + Named Credential + Permission Set als Auth-Schicht.
• Apex mit drei Klassen: ein gemeinsamer Service sowie zwei Wrapper mit @InvocableMethod (die Annotation, die sie von Agentforce aus aufrufbar macht, eine pro Agent Action).
• Agentforce-Subagent mit zwei angehängten Actions, einem Anweisungsblock und einer Klassifizierungsbeschreibung.

Architekturübersicht

Hier ist der Anforderungsfluss vom Prompt eines Mitarbeiters bis zu einem Briefing:

Rep prompt in Agentforce
        │
        ▼
Agent Router  ──►  Account Web Intelligence subagent
                          │
                          ├─► Apex: BrightDataNewsAction
                          │     └─► Named Credential → Cloudflare Worker → Web Unlocker → Google News
                          │
                          └─► Apex: BrightDataFetchAction
                                └─► Named Credential → Cloudflare Worker → Web Unlocker → target URL
        │
        ▼
LLM synthesis  ──►  Briefing back to the rep

Der Cloudflare Worker existiert, weil Salesforce Apex HTTP/1.1 Chunked-Transfer-Antworten nicht zuverlässig verarbeiten kann, und Bright Data Chunked Encoding für jede Nutzlast über wenigen Kilobyte verwendet. Der Worker puffert die Antwort in einen einzelnen ArrayBuffer und stellt sie mit einem expliziten Content-Length-Header erneut bereit. Ohne ihn gibt jeder Aufruf von Apex einen 200-Status und einen Null-Byte-Body zurück. Teil 2 unten führt durch das Debugging und die Lösung.

Bright Data hat mehrere Produkte, die für diese Art von Aufbau geeignet sind: SERP API für geparste Google-Ergebnisse, dedizierte Scraper für LinkedIn und Crunchbase und andere. Dieser Aufbau verwendet nur Web Unlocker, weil er über denselben Endpunkt für jede URL funktioniert, was die Apex-Seite einfach hält. Der Cloudflare Worker Proxy in Teil 2 deckt jeden Bright Data API-Endpunkt gleichermaßen ab, sodass das spätere Einwechseln von SERP API oder einem dedizierten Scraper die Salesforce-seitige Verkabelung nicht ändert.

Teil 1: Bright Data einrichten

Wenn Sie kein Bright Data-Konto haben, erstellen Sie eines auf der Bright Data-Anmeldeseite. Die Web Unlocker-Zone, die Sie verwenden werden, befindet sich im Abschnitt Web Access API des Dashboards.

Web Unlocker-Zone erstellen oder notieren

Öffnen Sie das Dashboard, gehen Sie zu Web Access API in der linken Navigation und bestätigen Sie, dass eine Web Unlocker-Zone vorhanden ist. Wenn Ihr Konto keine hat, klicken Sie auf Create API (oben rechts) und wählen Sie Unlocker API aus dem Dropdown. Geben Sie ihr einen beliebigen Namen (Zonennamen können nach der Erstellung nicht geändert werden, wählen Sie also etwas Stabiles wie agentforce_unlocker). Wie auch immer Sie sie nennen, notieren Sie es. Sie werden es in die UNLOCKER_ZONE-Konstante in BrightDataService.cls in Teil 4 und in den curl-Test in Teil 2 einfügen.

Die Web Unlocker-Zone ist das Primitive, das beide Agentforce-Actions verwenden.

API-Token erstellen

Klicken Sie auf Settings (unten links) → Tab Users and API keys → Add API key mit User-Berechtigung. Der Schlüssel wird einmalig bei der Generierung angezeigt und dann maskiert. Kopieren Sie ihn jetzt und bewahren Sie ihn sicher auf; Sie werden ihn in Teil 3 in Salesforce einfügen.

Das ist die vollständige Bright Data-Einrichtung.

Teil 2: Den Cloudflare Worker Proxy bereitstellen

Bevor Sie Salesforce konfigurieren, benötigen Sie einen Proxy vor Bright Data. Der Grund ist eine Einschränkung in der Art und Weise, wie Salesforce Apex Chunked-Transfer-Antworten liest; jeder Apex-Entwickler, der nicht-triviale HTTP-Callouts durchführt, wird wahrscheinlich darauf stoßen.

Der Fehler

Salesforce Apex’s Http-Client unterstützt Standard-HTTP mit einer praktischen Lücke: Er parst HTTP/1.1-Antworten, die Chunked Transfer Encoding ohne Content-Length-Header verwenden, nicht zuverlässig. Bei einer Chunked-Antwort gibt der Callout Status Code = 200, Content-Type = null, Response Size = 0 bytes zurück, ohne Ausnahme oder Warnung. Sowohl getBody() als auch getBodyAsBlob().toString() geben leere Strings zurück.

Bright Data’s /request-Endpunkt verwendet Chunked Transfer Encoding für Antworten über wenigen Kilobyte. Ein Web Unlocker-Aufruf auf einer winzigen Testseite (die Bright Data welcome.txt) bleibt unter dem Schwellenwert und gibt eine Content-Length-Antwort zurück, die Apex sauber parst. Aber eine echte Seite (eine Unternehmens-Homepage, eine Google News-Suche) überschreitet den Schwellenwert und wird in Chunks aufgeteilt, und Apex gibt einen leeren Body zurück.

Zwei Dinge beweisen, dass dies auf der Apex-Seite liegt, nicht auf der Netzwerkseite: Ein curl-Aufruf an denselben Endpunkt mit derselben Nutzlast gibt einen 9-KB-Body sauber zurück, und derselbe Aufruf aus der anonymen Apex-Ausführung gibt 0 Bytes mit Transfer-Encoding: chunked in den Antwort-Headern zurück.

Die Lösung ist strukturell, keine Konfigurationsänderung: Stellen Sie einen Puffer-Proxy zwischen Salesforce und Bright Data. Der Proxy liest Bright Data’s Chunked-Stream vollständig, dann stellt er die Antwort an Salesforce mit einem expliziten Content-Length-Header erneut bereit. Apex parst diese Antwort sauber.

Ein Cloudflare Worker ist eine gute Wahl für das Hosting dieses Proxys. Er ist kostenlos für geringes Volumen, wird in Minuten bereitgestellt, läuft am Edge, und der gesamte Body passt auf einen Bildschirm JavaScript.

Den Worker erstellen

Registrieren Sie sich im Cloudflare-Dashboard, wenn Sie kein Konto haben. Suchen Sie im Dashboard nach Workers (erscheint unter Compute → Workers & Pages, je nach Ihrer Dashboard-Version). Klicken Sie auf Create application, dann wählen Sie Hello World aus den Templates. Bei der ersten Nutzung fordert Cloudflare Sie auf, eine workers.dev-Subdomain zu wählen; wählen Sie beliebig (es ist Ihre kostenlose Dev-Subdomain). Benennen Sie den Worker mit etwas Einprägsamen; dieser Aufbau verwendet bd-proxy. Nachdem der Platzhalter bereitgestellt wurde, klicken Sie auf Edit code.

Wählen Sie den gesamten Platzhaltercode im Editor aus und fügen Sie stattdessen Folgendes ein:

/**
 * Bright Data to Salesforce Apex proxy.
 *
 * Salesforce Apex does not reliably consume HTTP/1.1 chunked-transfer
 * responses, which is what Bright Data returns for any non-trivial payload.
 * This Worker buffers the full response and re-serves it with an explicit
 * Content-Length header. Apex parses that response cleanly.
 *
 * Production deployments typically route external API calls through an
 * integration layer like MuleSoft or Heroku. This Worker is the minimal
 * stand-in for that role.
 */

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const bdUrl = 'https://api.brightdata.com' + url.pathname + url.search;

    // Strip Cloudflare-injected headers we shouldn't forward upstream.
    const forwardHeaders = new Headers(request.headers);
    forwardHeaders.delete('host');
    forwardHeaders.delete('cf-connecting-ip');
    forwardHeaders.delete('cf-ray');
    forwardHeaders.delete('cf-visitor');
    forwardHeaders.delete('x-forwarded-for');
    forwardHeaders.delete('x-forwarded-proto');
    forwardHeaders.delete('x-real-ip');

    try {
      const bdResponse = await fetch(bdUrl, {
        method: request.method,
        headers: forwardHeaders,
        body: ['GET', 'HEAD'].includes(request.method)
          ? undefined
          : await request.arrayBuffer(),
      });

      // Buffer the entire response into a single ArrayBuffer. This collapses
      // chunked transfer into a buffer of known length.
      const bodyBuffer = await bdResponse.arrayBuffer();

      const responseHeaders = new Headers();
      const ct = bdResponse.headers.get('Content-Type');
      if (ct) responseHeaders.set('Content-Type', ct);
      responseHeaders.set('Content-Length', bodyBuffer.byteLength.toString());
      const brdStatus = bdResponse.headers.get('x-brd-status-code');
      if (brdStatus) responseHeaders.set('X-Brd-Status-Code', brdStatus);

      return new Response(bodyBuffer, {
        status: bdResponse.status,
        headers: responseHeaders,
      });
    } catch (err) {
      return new Response(
        JSON.stringify({ error: 'Proxy error', message: err.message }),
        { status: 502, headers: { 'Content-Type': 'application/json' } }
      );
    }
  },
};

Die zwei Zeilen, die die Integration beheben, sind await bdResponse.arrayBuffer() (das den gesamten Chunked-Stream in den Speicher liest) und der explizite Content-Length-Header, der aus bodyBuffer.byteLength gesetzt wird (Apex parst den Body daraus sauber). Alles andere behandelt die Header-Weiterleitung: Es entfernt Cloudflare-injizierte Header für eingehende Anfragen und bewahrt den Upstream-Statuscode für ausgehende Antworten.

Klicken Sie auf Deploy (oben rechts). Cloudflare gibt Ihnen eine URL wie https://<worker-name>.<your-subdomain>.workers.dev. Kopieren Sie sie; Sie benötigen diese URL für Salesforce in Teil 3.

Die entscheidenden Zeilen: await bdResponse.arrayBuffer() liest den gesamten Chunked-Stream in den Speicher, und der explizite Content-Length-Header am Response-Objekt bedeutet, dass Apex den Body sauber parsen kann.

Überprüfen, ob der Worker funktioniert

Führen Sie von Ihrem lokalen Terminal aus einen schnellen Test gegen den Worker durch. Ersetzen Sie die URL durch Ihre eigene und verwenden Sie Ihr eigenes Bright Data API-Token:

curl -i https://<your-worker>.workers.dev/request \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-bd-token>" \
  -d '{"zone":"mcp_unlocker","url":"https://www.salesforce.com","format":"raw","data_format":"markdown"}' \
  | head -20

Die Antwort-Header sollten einen 200-Status und einen content-length: <some-number>-Header enthalten. Sie sollten kein transfer-encoding: chunked enthalten. Das ist der Beweis, dass der Proxy korrekt funktioniert. Hier sind die häufigen Fehler: 401 bedeutet, dass Ihr Bright Data-Token falsch ist (überprüfen Sie den Authorization: Bearer ...-Header erneut); 502 vom Worker bedeutet, dass Ihr Worker-Code nicht bereitgestellt wurde (überprüfen Sie den Deploy-Schritt erneut); ein noch erscheinender transfer-encoding: chunked-Header bedeutet, dass Sie die arrayBuffer() + Content-Length-Zeilen im Worker-Quellcode verpasst haben.

Bei einem Unternehmens-Rollout würde dieser Worker durch eine produktionsreife Integrationsschicht ersetzt werden: MuleSoft auf Anypoint, ein Heroku-Microservice oder ein benutzerdefiniertes API-Gateway mit Auth, Observability und Rate Limiting. Der Worker ist ein minimaler Ersatz für diese Rolle, aber dasselbe Muster funktioniert in diesen Produktions-Setups.

Teil 3: Salesforce-Credentials konfigurieren

Salesforce’s External Credential-Muster teilt eine Drittanbieter-Credential in drei Objekte auf: eine External Credential (enthält das Token), eine Named Credential (enthält den Endpunkt) und ein Permission Set (gewährt Benutzern Zugriff auf den Principal der External Credential).

Die External Credential erstellen

Klicken Sie auf das Zahnrad-Symbol (oben rechts auf jeder Salesforce-Seite) → Setup. Verwenden Sie in Setup das Quick Find-Feld oben in der linken Leiste und suchen Sie nach Named Credentials. Klicken Sie auf das Ergebnis. Klicken Sie auf der geladenen Seite auf den Tab External Credentials, dann auf New.

Füllen Sie die folgenden Felder aus:

• Label: Bright Data Cred
• Name: Bright_Data_Cred (wird automatisch ausgefüllt)
• Authentication Protocol: Custom

Klicken Sie auf Save.

Suchen Sie auf der Detailseite den Abschnitt Principals und klicken Sie auf New:

• Parameter Name: BrightDataPrincipal
• Sequence Number: 1
• Identity Type: Named Principal

Fügen Sie im Abschnitt Authentication Parameters unter dem Principal Folgendes hinzu:

• Name: api_key
• Value: fügen Sie Ihr Bright Data API-Token ein

Klicken Sie auf Save.

Suchen Sie auf der External Credential-Seite den Abschnitt Custom Headers und klicken Sie auf New:

• Name: Authorization
• Value: Bearer {!$Credential.Bright_Data_Cred.api_key}
• Sequence Number: 1

⚠️ Das Merge-Feld muss mit den von Ihnen gesetzten Namen übereinstimmen. Bright_Data_Cred in der Formel muss mit dem API-Namen der External Credential übereinstimmen. api_key muss mit dem Authentication Parameter-Namen übereinstimmen, den Sie im Principal gesetzt haben. Wenn Sie eines von beiden umbenannt haben, bearbeiten Sie die Formel entsprechend.

Dies ist entscheidend: Aktivieren Sie das Kontrollkästchen Allow Formulas in HTTP Header für diesen Custom Header. So finden Sie es: Klicken Sie nach dem Speichern der Header-Zeile auf die Zeile, um ihre Detailansicht zu öffnen. Das Kontrollkästchen befindet sich auf dieser Detailseite, nicht auf der übergeordneten External Credential-Seite. Wenn Sie es überspringen, sendet Salesforce den wörtlichen String Bearer {!$Credential...} an Bright Data, das 401 zurückgibt, und die Fehlermeldung sagt Ihnen nicht, welches Kontrollkästchen Sie verpasst haben. Klicken Sie auf Save.

⚠️ Im nächsten Abschnitt werden Sie auf ein Kontrollkästchen mit demselben Namen stoßen. “Allow Formulas in HTTP Header” erscheint an zwei Stellen. Kontrollkästchen A ist das, das Sie gerade aktiviert haben (auf der Detailseite des Custom Headers). Kontrollkästchen B befindet sich in den Callout Options der Named Credential. Beide müssen aktiviert sein. Wenn nur eines aktiviert ist, wird das Merge-Feld als wörtlicher Text gesendet und Bright Data gibt 401 zurück.

Der Merge-Feld-Wert des Custom Headers ist der Teil, der das API-Token zur Anfragezeit auflöst. Das Kontrollkästchen Allow Formulas in HTTP Header (auf dieser Tiefe nicht sichtbar; es befindet sich auf der Detailseite des Headers) muss aktiviert sein, sonst wird das Merge-Feld als wörtlicher Text gesendet.

Die Named Credential erstellen

Wechseln Sie im selben Abschnitt Named Credentials zurück zum Tab Named Credentials und klicken Sie auf New:

• Label: Bright Data API
• Name: Bright_Data_API
• URL: fügen Sie Ihre Cloudflare Worker-URL ein (zum Beispiel https://bd-proxy.<your-subdomain>.workers.dev)
• Enabled for Callouts: aktiviert
• External Credential: wählen Sie Bright Data Cred

Setzen Sie unter Callout Options Folgendes:

• Generate Authorization Header: deaktiviert (Sie stellen Ihren eigenen über den Custom Header bereit)
• Allow Formulas in HTTP Header: aktiviert (damit das Merge-Feld aufgelöst wird)
• Allow Formulas in HTTP Body: aktiviert (damit dynamische JSON-Bodies funktionieren)

Klicken Sie auf Save.

Die URL zeigt auf den Cloudflare Worker, nicht direkt auf api.brightdata.com. So funktioniert die Chunked-Transfer-Lösung. Die drei Kontrollkästchen-Zustände sind unabhängig voneinander wichtig; wenn einer falsch ist, bricht der Callout ohne Warnung ab.

Das Permission Set erstellen

Salesforce blockiert selbst System Administratoren die Nutzung des Principals einer External Credential, bis ein Permission Set explizit Zugriff gewährt. Wenn Sie diesen Schritt überspringen, gibt Apex einen INVALID_OPERATION-Fehler ohne nützliche Diagnose zurück.

Suchen Sie in Setup nach Permission Sets und klicken Sie auf New:

• Label: Bright Data Access
• API Name: Bright_Data_Access
• License: leer lassen

Klicken Sie auf Save.

Scrollen Sie auf der Detailseite zu External Credential Principal Access und klicken Sie auf Edit. Verschieben Sie Bright_Data_Cred - BrightDataPrincipal von der Available-Liste in die Enabled-Liste. Klicken Sie auf Save.

Klicken Sie auf der Detailseite auf Manage Assignments oben, dann auf Add Assignments, wählen Sie Ihren eigenen Benutzer aus und schließen Sie die Zuweisung ab.

Das Permission Set ist der Kontrollmechanismus, mit dem Sie festlegen können, welche Benutzer Code ausführen können, der Bright Data aufruft. In einer Unternehmens-Org würde dies über eine Permission Set Group an Service-Benutzer oder bestimmte Profile zugewiesen werden, nicht an einzelne Admins.

Die Verkabelung überprüfen, bevor Sie fortfahren

Klicken Sie auf das Zahnrad-Symbol (oben rechts) → Developer Console. Es öffnet sich in einem neuen Browserfenster. Sobald dieses Fenster fokussiert ist, öffnen Sie Anonymous Apex über Debug → Open Execute Anonymous Window. Fügen Sie den folgenden Code ein und klicken Sie auf Execute:

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:Bright_Data_API/request');
req.setMethod('POST');
req.setHeader('Content-Type', 'application/json');
req.setBody('{"zone":"mcp_unlocker","url":"https://geo.brdtest.com/welcome.txt?product=unlocker&method=api","format":"raw"}');
req.setTimeout(60000);
HttpResponse res = new Http().send(req);
System.debug('STATUS: ' + res.getStatusCode());
System.debug('BODY: ' + res.getBody().left(500));

Nach dem Klicken auf Execute erscheint eine neue Log-Zeile im unteren Panel der Developer Console. Doppelklicken Sie auf diese Zeile, um den Log-Viewer zu öffnen, und aktivieren Sie dann Debug Only unten (oder geben Sie USER_DEBUG in das Filterfeld ein). Sie sollten zwei Zeilen sehen, die Ihre STATUS- und BODY-Werte ausgeben. Suchen Sie nach STATUS: 200 und einem Body, der den Bright Data-Willkommenstext enthält. Wenn Sie 401 sehen, überprüfen Sie das Kontrollkästchen “Allow Formulas in HTTP Header” des Custom Headers erneut (das auf der Detailseite des Headers, und das auf den Callout Options der Named Credential). Wenn Sie INVALID_OPERATION sehen, überprüfen Sie die Permission Set-Zuweisung erneut.

Teil 4: Die Apex-Schicht schreiben

Apex registriert nur eine @InvocableMethod pro Klasse als Agentforce-aufrufbare Action. Deshalb verwendet die Integration drei Klassen statt einer: einen gemeinsamen Service für HTTP-Infrastruktur und eine Klasse pro Agent Action.

Fügen Sie jeden Block unverändert ein. Die Hauptzeile, die Sie möglicherweise ändern möchten, ist private static final String UNLOCKER_ZONE = 'mcp_unlocker'; in BrightDataService.cls, wenn Ihre Bright Data-Zone einen anderen Namen hat (Teil 1).

Suchen Sie in Setup nach Apex Classes in Quick Find und klicken Sie auf das Ergebnis. Klicken Sie auf New. Der Editor öffnet sich mit einer Platzhalterklasse wie public class YourClassName {}. Klicken Sie auf den Codebereich (das große Textfeld, nicht das rechte Version Settings-Panel), wählen Sie den gesamten Platzhaltertext aus, drücken Sie Delete und fügen Sie dann den folgenden Quellcode ein. Der Klassenname wird aus dem Quellcode übernommen, sodass Sie keine anderen Felder ausfüllen müssen. Klicken Sie auf Save.

Erstellen Sie die drei Klassen in dieser Reihenfolge, da BrightDataNewsAction und BrightDataFetchAction beide auf BrightDataService verweisen. Der Service muss zuerst gespeichert werden:

BrightDataService.cls: die gemeinsame HTTP- und Parsing-Schicht

Diese Klasse enthält die HTTP-Infrastruktur und die zwei Hilfsmethoden (searchNews und fetchUrlAsMarkdown), die beide Agent Actions aufrufen. Hier ist kein @InvocableMethod; diese Annotation befindet sich in den Action-Wrapper-Klassen unten. Hier ist die Klasse:

public with sharing class BrightDataService {

    private static final String BD_ENDPOINT      = 'callout:Bright_Data_API/request';
    private static final String UNLOCKER_ZONE    = 'mcp_unlocker';
    private static final Integer CALLOUT_TIMEOUT = 60000;
    private static final Integer MAX_RESPONSE_CHARS = 50000;

    /**
     * Fetches the Google News results page for `companyName` (past month) as
     * clean Markdown via Bright Data Web Unlocker. The LLM downstream is
     * responsible for extracting individual articles, sources, and dates.
     */
    public static String searchNews(String companyName) {
        String googleNewsUrl =
            'https://www.google.com/search?q='
            + EncodingUtil.urlEncode(companyName, 'UTF-8')
            + '&tbm=nws&tbs=qdr:m';

        Map<String, Object> body = new Map<String, Object>{
            'zone'        => UNLOCKER_ZONE,
            'url'         => googleNewsUrl,
            'format'      => 'raw',
            'data_format' => 'markdown'
        };

        HttpResponse res = sendRequest(JSON.serialize(body));

        if (res.getStatusCode() != 200) {
            return 'Bright Data returned status '
                + res.getStatusCode() + ': ' + res.getBody().left(300);
        }

        String content = res.getBody();
        if (String.isBlank(content)) {
            return 'No content returned for "' + companyName
                + '". The page may have been empty or blocked.';
        }
        if (content.length() > MAX_RESPONSE_CHARS) {
            content = content.left(MAX_RESPONSE_CHARS)
                + '\n\n[Content truncated at ' + MAX_RESPONSE_CHARS + ' characters]';
        }

        return 'Google News results for "' + companyName
            + '" (past month). Extract article titles, sources, '
            + 'publication dates, and URLs from the Markdown below:\n\n'
            + content;
    }

    /**
     * Fetches any URL via Bright Data Web Unlocker and returns the page as
     * clean Markdown.
     */
    public static String fetchUrlAsMarkdown(String url) {
        Map<String, Object> body = new Map<String, Object>{
            'zone'        => UNLOCKER_ZONE,
            'url'         => url,
            'format'      => 'raw',
            'data_format' => 'markdown'
        };

        HttpResponse res = sendRequest(JSON.serialize(body));

        if (res.getStatusCode() != 200) {
            return 'Web Unlocker returned status '
                + res.getStatusCode() + ': ' + res.getBody().left(300);
        }

        String content = res.getBody();
        if (content.length() > MAX_RESPONSE_CHARS) {
            content = content.left(MAX_RESPONSE_CHARS)
                + '\n\n[Content truncated at ' + MAX_RESPONSE_CHARS + ' characters]';
        }
        return content;
    }

    private static HttpResponse sendRequest(String jsonBody) {
        HttpRequest req = new HttpRequest();
        req.setEndpoint(BD_ENDPOINT);
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setBody(jsonBody);
        req.setTimeout(CALLOUT_TIMEOUT);
        return new Http().send(req);
    }
}

Die Klasse hat absichtlich kein @InvocableMethod. Sie ist die gemeinsame HTTP-Schicht, die die beiden Action-Klassen verwenden.

BrightDataNewsAction.cls: die Nachrichtensuche-Action

Agentforce ruft diesen schlanken aufrufbaren Wrapper auf, wenn der Agent entscheidet, nach Nachrichten zu suchen. Er validiert die Eingabe, delegiert die HTTP-Arbeit an BrightDataService.searchNews() und gibt das Ergebnis in der Response-Form zurück, die Agentforce erwartet. Hier ist die Klasse:

public with sharing class BrightDataNewsAction {

    public class Request {
        @InvocableVariable(
            required=true
            label='Company Name'
            description='The name of the company to search news about. E.g. "Salesforce" or "Acme Corp".')
        public String companyName;
    }

    public class Response {
        @InvocableVariable(
            label='News Results'
            description='Formatted summary of recent news with titles, sources, dates, URLs, and snippets.')
        public String newsResults;
    }

    @InvocableMethod(
        label='Search Recent Company News (Bright Data)'
        description='Searches Google News via Bright Data for recent (past month) articles about a specific named company. Use this whenever the user asks about recent news, announcements, press releases, funding rounds, acquisitions, leadership changes, or current events for a named company.'
        callout=true)
    public static List<Response> searchCompanyNews(List<Request> requests) {
        List<Response> responses = new List<Response>();
        for (Request req : requests) {
            Response resp = new Response();
            try {
                resp.newsResults = String.isBlank(req.companyName)
                    ? 'Error: A company name is required.'
                    : BrightDataService.searchNews(req.companyName);
            } catch (Exception e) {
                resp.newsResults = 'Error fetching news for ' + req.companyName + ': ' + e.getMessage();
            }
            responses.add(resp);
        }
        return responses;
    }
}

Agentforce’s Reasoning Engine liest das description-Feld der @InvocableMethod-Annotation, um zu entscheiden, wann diese Action aufgerufen werden soll.

BrightDataFetchAction.cls: die URL-Abruf-Action

Der zweite aufrufbare Wrapper folgt demselben Muster wie die Nachrichten-Action, ruft aber jede URL ab, die der Mitarbeiter erwähnt. Der Validierungsblock weist auch fehlerhafte Eingaben vor dem Callout zurück. Hier ist die Klasse:

public with sharing class BrightDataFetchAction {

    public class Request {
        @InvocableVariable(
            required=true
            label='URL to Fetch'
            description='The full URL of a web page to retrieve. Must start with http:// or https://.')
        public String url;
    }

    public class Response {
        @InvocableVariable(
            label='Page Content'
            description='Clean Markdown representation of the page content.')
        public String pageContent;
    }

    @InvocableMethod(
        label='Fetch Web Page as Markdown (Bright Data)'
        description='Retrieves the content of any web URL via Bright Data Web Unlocker and returns it as clean Markdown. Use this when you need to read a specific URL: a company homepage, blog post, press release, or any link the user mentions.'
        callout=true)
    public static List<Response> fetchUrlAsMarkdown(List<Request> requests) {
        List<Response> responses = new List<Response>();
        for (Request req : requests) {
            Response resp = new Response();
            try {
                if (String.isBlank(req.url)
                    || (!req.url.startsWithIgnoreCase('http://')
                        && !req.url.startsWithIgnoreCase('https://'))) {
                    resp.pageContent = 'Error: A valid URL starting with http:// or https:// is required.';
                } else {
                    resp.pageContent = BrightDataService.fetchUrlAsMarkdown(req.url);
                }
            } catch (Exception e) {
                resp.pageContent = 'Error fetching ' + req.url + ': ' + e.getMessage();
            }
            responses.add(resp);
        }
        return responses;
    }
}

Nach dem Speichern aller drei sollten sie in Setup → Apex Classes als Active angezeigt werden.

Der gesamte Apex-Umfang beträgt etwa 6,4 KB über drei Klassen. Der gemeinsame Service plus eine Action-Klasse pro Agent Action ist das Standard-Salesforce-Muster, wenn mehr als eine aufrufbare Methode benötigt wird.

Die Actions testen

Bevor Sie die Actions mit Agentforce verbinden, bestätigen Sie, dass sie End-to-End funktionieren. In Anonymous Apex:

BrightDataNewsAction.Request r = new BrightDataNewsAction.Request();
r.companyName = 'Salesforce';
List<BrightDataNewsAction.Response> out =
    BrightDataNewsAction.searchCompanyNews(new List<BrightDataNewsAction.Request>{ r });
System.debug('LENGTH: ' + out[0].newsResults.length());
System.debug('PREVIEW: ' + out[0].newsResults.left(800));

Erwarten Sie LENGTH zwischen 5.000 und 10.000, mit einer Vorschau, die mit dem Präfix der Service-Klasse beginnt und dann dem Google News-Markdown. Wenn Sie LENGTH: 0 oder einen Fehler-String sehen, kehren Sie zum Verifizierungsschritt in Teil 3 zurück.

Teil 5: Die Actions als Agentforce Assets registrieren

Apex-Klassen sind für Agentforce standardmäßig nicht sichtbar. Jede @InvocableMethod muss als Agent Action (neuere Bezeichnung: Agentforce Asset) registriert werden, bevor der Agent sie aufrufen kann.

Suchen Sie in Setup nach Agent Actions (oder Agentforce Assets, je nachdem, welche Bezeichnung Ihre Org hat) und klicken Sie auf New Agent Action. Dies tun Sie zweimal, einmal für jede Action-Klasse.

Füllen Sie für die Nachrichten-Action Folgendes aus:

• Reference Action Type: Apex
• Reference Action Category: Invocable Methods
• Reference Action: BrightDataNewsAction.searchCompanyNews

Füllen Sie auf dem nächsten Bildschirm diese Felder aus:

• Agent Action Label: behalten Sie das automatisch ausgefüllte Search Recent Company News (Bright Data)
• Agent Action Description: behalten Sie die automatisch ausgefüllte Beschreibung (sie stammt aus der @InvocableMethod-Annotation)
• Show loading text for this action: aktiviert
• Loading Text: Searching recent news…

Salesforce erkennt automatisch die Eingabe (companyName, erforderlich, String) und die Ausgabe (newsResults, String). Lassen Sie die automatisch erkannte Zuordnung. Klicken Sie auf Finish.

„Agent Populated” ist die Bezeichnung, die Salesforce verwendet, wenn eine Eingabe zur Laufzeit durch LLM-Reasoning befüllt wird. Dies ist der Zustand, den die Integration für chatgesteuerte Agenten benötigt.

Teil 7: Den Agenten testen

Klicken Sie im Agent Builder auf den Tab Preview. Die Chat-Oberfläche öffnet sich mit einem gelben Banner, das eine Schaltfläche Reset Simulator enthält. Falls das Banner erscheint, klicken Sie darauf. Das Zurücksetzen ist wichtig, weil der Konversationsspeicher des Simulators sitzungsbezogen ist und das Zurücksetzen zwischen Tests die einfachste Methode ist, um unabhängige Traces zu erhalten. Die vier folgenden Tests überprüfen Routing, einzelne Aktionsaufrufe, parallele Aufrufe und das Verhalten bei ehrlichem Fehlschlag.

Wenn der Tab Preview ausgegraut ist, suchen Sie oben auf der Canvas nach einem Activate-Schalter und aktivieren Sie ihn. Die Aktivierung hier ermöglicht den Agenten nur für die Preview/den Simulator; Endbenutzer können nicht darauf zugreifen, bis Sie ihn auch über Setup → Agentforce Studio → Connections zuweisen, was für diesen Build nicht im Scope liegt.

Test 1: Nur Nachrichtensuche

Um zu überprüfen, ob die Nachrichtenaktion vollständig ausgeführt wird, geben Sie Folgendes ein:

What's new at Salesforce in the past month?

Der Agent sollte zu Account Web Intelligence weiterleiten, einen Ladezustand „Searching recent news…” anzeigen und dann eine thematisch gegliederte Nachrichtenzusammenfassung mit inline zitierten Quellennamen zurückgeben. Öffnen Sie den Tab Trace am unteren Rand der Canvas, um die vollständige Reasoning-Kette zu sehen. Das Panel Interaction Summary rechts neben der Vorschau zeigt dieselbe Kette in kompakter Form: welchen Subagenten der Router ausgewählt hat, welche Aktionen aufgerufen wurden und wie der Agent geschlussfolgert hat.

Dies ist ein sauberer Einzelaktionslauf. Der Router hat korrekt weitergeleitet, der Agent hat companyName="Salesforce" aus der natürlichsprachlichen Eingabe extrahiert, die Aktion aufgerufen und eine thematisch gegliederte Zusammenfassung erstellt. Die URL_Redacted-Platzhalter sind Salesforces URL-Vertrauensrichtlinie in Aktion (erklärt im Abschnitt „Enterprise Governance” weiter unten).

Das Routing ist LLM-gesteuert, daher kann es in seltenen Fällen vorkommen, dass die Beschreibung des Account Web Intelligence-Subagenten gegenüber einer ähnlichen im Template (z. B. General FAQ) unterliegt. Wenn Ihr erster Test zum falschen Subagenten weiterleitet, fügen Sie der Beschreibung spezifischere Schlüsselwörter hinzu („company news”, „press release”, „recent funding”, „fetch URL”), speichern Sie, klicken Sie auf Reset Simulator und versuchen Sie es erneut. Der Router klassifiziert bei jeder neuen Sitzung neu.

Test 2: Nur URL-Abruf

Um zu überprüfen, ob eine direkte URL-Eingabe zur Fetch-Aktion weitergeleitet wird, klicken Sie auf Reset Simulator und geben Sie Folgendes ein:

Read https://www.snowflake.com and tell me what they do

Der Agent sollte die Fetch-Aktion aufrufen, nicht die Nachrichtenaktion. Eine andere Eingabe leitet zu einem anderen Tool weiter.

Es ist derselbe Agent, aber eine andere Eingabe leitet zu einem anderen Tool weiter. Der Agent Router hat die Eingabe als URL-Abruf (nicht als Nachrichtensuche) klassifiziert und nur die Fetch-Aktion aufgerufen. Dies ist ein Beleg dafür, dass der Agent schlussfolgert und keine feste Pipeline ausführt.

Test 3: Beide Aktionen parallel

Test 3 gilt als bestanden, wenn beide Aktionen aufgerufen werden, unabhängig davon, ob beide 200 zurückgeben. Wenn beide erfolgreich sind, sehen Sie ein sauberes kombiniertes Briefing. Wenn eine fehlschlägt (wie im Screenshot unten), sollte der Agent dennoch ein Briefing mit der erfolgreichen Aktion erstellen. Dies demonstriert Regel 5. Geben Sie nach Reset Simulator Folgendes ein:

Give me a briefing on Anthropic, recent news plus what their homepage says about their product

Der Agent sollte beide Aktionen aufrufen und dann ein kombiniertes Briefing erstellen. Der Trace zeigt zwei separate Aktionszeilen in derselben Reasoning-Kette.

Der Agent hat beide Aktionen aus einer einzigen Benutzereingabe aufgerufen. Der Anthropic-Nachrichtenabschnitt stammt von Bright Data’s Web Unlocker, der Google News aufruft.

Dieselbe Antwort setzt sich unten mit dem Homepage-Abschnitt fort, wo dieser Lauf auf einen partiellen Fehler gestoßen ist, der es wert ist, ihn im Detail zu betrachten:

Der Homepage-Abruf hat einen 520-Fehler zurückgegeben, den Status, den Web Unlocker verwendet, wenn eine Zielseite bei einem bestimmten Versuch nicht abgerufen werden kann. Der Agent hat keinen Homepage-Inhalt erfunden; er hat den Fehler eingestanden, die gerade empfangenen Nachrichtendaten genutzt, um zu beschreiben, was das Unternehmen tut, und angeboten, es erneut zu versuchen.

Graceful Degradation bei einem partiellen Tool-Fehler ist das Produktionsverhalten, das Regel 5 der Subagenten-Anweisungen erzeugen soll. Dies ist wichtig, weil das öffentliche Web adversarial ist: Zielseiten ändern ihre Abwehrmechanismen, CDNs schlagen gelegentlich fehl, und jeder Agent, der Live-URLs aufruft, muss gelegentliche Nicht-200-Antworten tolerieren. Wenn ein Agent sagt „der Homepage-Abruf ist fehlgeschlagen, hier ist, was ich aus den Nachrichten habe”, ist das produktionsreifes Verhalten.

Test 4: Keine-Halluzination-Prüfung

Um zu überprüfen, ob der Agent ehrlich versagt, wenn es keine echte Antwort gibt, klicken Sie auf Reset Simulator und geben Sie Folgendes ein:

What's the latest news about Triposat Industries?

Dies ist ein fiktiver Unternehmensname, daher gibt es keine echten Nachrichten zu finden. Bright Data kann einen 520-Fehler, ein leeres Ergebnis oder irrelevante Snippets zurückgeben – keines davon ist eine echte Antwort. Der Agent sollte keine Nachrichten erfinden, unabhängig davon, was zurückkommt. Das Erfolgskriterium hier ist das Verhalten, nicht der Statuscode: Akzeptable Antworten umfassen „no recent news found”, „I couldn’t retrieve results” oder jede ehrliche Offenlegung. Ein Fehlschlag wäre, wenn der Agent einen Forbes-Artikel oder eine Finanzierungsrunde erfindet, die nicht existiert.

Der Agent hat keine Nachrichteneinträge erfunden und keine Quellen erdichtet. Er hat die Aktion aufgerufen, ein schlechtes Ergebnis erhalten und es offengelegt. Regel 5 der Subagenten-Anweisungen hat wie beabsichtigt funktioniert.

URL-Redaktion in Agentforce

Jede Demo-Antwort in den obigen Screenshots zeigt Quell-URLs als URL_Redacted. Dies ist Salesforce Agentforce’s integrierte URL-Vertrauensrichtlinie.

Standardmäßig entfernt Agentforce beliebige externe URLs aus Agentenantworten, bevor sie den Endbenutzer erreichen. Intern liest der Agent jedoch weiterhin die echten URLs, wenn das Tool antwortet, und verwendet sie für das Reasoning; er kann sie nur nicht in die Chat-Ausgabe aufnehmen, es sei denn, die Domain befindet sich auf einer expliziten Allowlist.

Es ist konfigurierbar: Suchen Sie in Setup nach Trusted URLs und fügen Sie die Domains hinzu, die Sie zulassen möchten. Für einen Sales-Briefing-Agenten umfasst eine realistische Allowlist Google-Domains, die eigenen Marketing-Domains des Unternehmens und eine kuratierte Auswahl von Nachrichtenquellen (Forbes, Reuters, Bloomberg, TechCrunch).

Lassen Sie die Standard-Redaktion aktiviert. Sie macht die Demo stärker: Der Agent zitiert Quellen namentlich (Forbes, TechAfrica News, SAP News Center), und die Redaktion macht Salesforces Governance-Schicht sichtbar. Eine Demo mit rohen URLs ist von einem Consumer-Chatbot nicht zu unterscheiden; die redigierte Version macht die Governance-Schicht sichtbar.

Was es kostet

Bright Data berechnet nur für erfolgreiche Web Unlocker-Antworten auf seinen Pay-as-you-go- und gestaffelten Tarifen; nicht erfolgreiche Antworten werden nicht in Rechnung gestellt. Zum Listenpreis liegt ein Briefing, das beide Aktionen aufruft, im Bruchteil-eines-Cents-Bereich; gestaffelte Tarife reduzieren die Kosten pro Anfrage weiter.

Um Ihre eigenen Ausgaben zu prognostizieren, lautet die Formel:

requests/month = reps × briefings_per_rep_per_day × workdays × actions_per_briefing

Für ein 100-köpfiges Vertriebsteam, das 5 Briefings pro Person an 22 Arbeitstagen mit 2 Aktionen pro Briefing durchführt, ergibt das 22.000 Anfragen pro Monat. Multiplizieren Sie das mit Bright Data’s aktuellem Preis pro Anfrage (von der Preisseite), um Ihre monatlichen Kosten zu erhalten.

Auf der Cloudflare-Seite bleibt der Worker bei typischen Vertriebsteam-Volumina innerhalb seines kostenlosen Kontingents; beachten Sie die Workers-Preisgestaltung, bevor Sie über ein einzelnes Team hinaus skalieren.

Auf der Salesforce-Seite werden die Kosten aus dem bestehenden Einstein Generative-AI-Kreditkontingent Ihrer Organisation gedeckt, demselben gemessenen Pool, den jede Agentforce-Aktion verwendet. Überprüfen Sie Setup → Einstein Generative AI → Usage, um das aktuelle Kontingent und die Nutzung Ihrer Organisation zu sehen.

Nächste Schritte

Der obige Build ist eine minimale Einheit einer Account-Intelligence-Schicht. Hier sind drei Dinge, die zu tun sind, bevor dies in die Produktion geht:

• Verschieben Sie den Cloudflare Worker hinter eine benutzerdefinierte Domain (Ihre eigene Subdomain auf Ihrem eigenen DNS) und leiten Sie ihn dann durch das API-Gateway Ihrer Organisation. Der Worker passt in diese Proxy-Rolle; eine benutzerdefinierte Domain plus Gateway macht ihn operativ zu Ihrem eigenen.
• Sperren Sie die Bright Data-Zone auf Ihren Egress-IP-Bereich. Bearbeiten Sie im Bright Data-Dashboard die Web Unlocker-Zone und fügen Sie die ausgehenden IPs des Cloudflare Workers (Cloudflare veröffentlicht diese) zur Allowlist der Zone hinzu. Dies verhindert, dass der API-Token außerhalb Ihrer Integration verwendet werden kann.
• Fügen Sie eine Apex-Testklasse für BrightDataService mit HttpCalloutMock hinzu. Drei Testmethoden (Erfolgspfad, leerer Body, Nicht-200) decken die realistischen Fehlermodi ab und erfüllen Salesforces 75%-Abdeckungsanforderung. Die Salesforce HttpCalloutMock-Dokumentation zeigt das Muster.

Wenn Sie Web Unlocker für eine Zielseite überwachsen haben, tauschen Sie einen der vorgefertigten Scraper von Bright Data ein. Derselbe Cloudflare Worker-Proxy verarbeitet diese ebenfalls; sie verwenden denselben /request-Endpunkt mit anderen zone– und dataset_id-Parametern. Zum Beispiel geben dedizierte LinkedIn Company Profile-, LinkedIn Jobs- und Crunchbase-Scraper strukturiertes JSON statt Markdown zurück, was dem Agenten ermöglicht, den LLM-Extraktionsschritt zu überspringen und direkt in benutzerdefinierte Salesforce-Felder zu schreiben. Allgemeiner gesagt decken Bright Data’s Web Scraper APIs vorgefertigte Scraper für Hunderte von Seiten ab.

Betrachten Sie den obigen Build als Gerüst. Die Credential-Schicht, der Proxy, die Subagenten-Struktur, die Aktionsverkabelung: Das Fundament bleibt gleich, wenn Sie ein anderes Bright Data-Produkt am selben /request-Endpunkt einsetzen. Wählen Sie den Account-Intelligence-Typ, den Ihre Vertriebsmitarbeiter tatsächlich benötigen; ändern Sie die Prompts in den Subagenten-Anweisungen. Der Agent bleibt; die Fragen, die er beantwortet, ändern sich.

Häufig gestellte Fragen

Warum gibt mein Apex-Callout einen leeren Body zurück?

Apex’s HTTP-Client parst HTTP/1.1-Antworten, die Chunked Transfer Encoding ohne einen Content-Length-Header verwenden, nicht zuverlässig. Bright Data und viele moderne APIs chunken Antworten über einige Kilobytes. Die Lösung besteht darin, den Aufruf durch einen Puffer-Proxy zu leiten, der die Antwort mit einem expliziten Content-Length neu bereitstellt.

Kann dieser Build Bright Data’s SERP API verwenden?

Ja. Der Cloudflare Worker-Proxy funktioniert für jeden Bright Data-API-Endpunkt, der auf api.brightdata.com gehostet wird, einschließlich SERP API, Web Scraper API und Dataset-Trigger. Ändern Sie den zone-Wert in der Apex-Service-Klasse auf den SERP-Zonennamen und den URL-Parameter auf eine Google-Such-URL mit brd_json=1.

Warum Apex InvocableMethods statt MCP verwenden?

Dieser Build exponiert Bright Data über Apex InvocableMethods, weil jede Aktion zu einer prüfbaren Agent Action mit eigener Permission Set-Governance wird. Wenn Ihre Organisation Salesforce-gehostete MCP (Model Context Protocol)-Server aktiviert hat (Beta ab Spring ’26), können Sie Bright Data alternativ über Bright Data’s eigenen MCP-Server exponieren. Beide Wege funktionieren. Der hier gezeigte InvocableMethod-Weg gibt Ihnen Salesforce-native Governance-Hooks; der MCP-Weg ist leichtgewichtiger, weil Bright Data den Server für Sie betreibt.

Wie lesen Agentforce-Aktionen Benutzereingaben?

Agentforce-Aktionen lesen Benutzereingaben über ein YAML-Flag namens is_user_input: True, das im Script-Modus für jede Eingabe gesetzt wird. Die Canvas-Benutzeroberfläche verbirgt dieses Flag und setzt Eingaben standardmäßig auf statische Variablen, daher wechseln Sie im Agent Builder in den Script-Modus und bearbeiten das YAML direkt, um den Wert zu ändern.

Warum verbirgt Agentforce Quell-URLs?

Externe URLs werden aus Agentenantworten entfernt, es sei denn, ihre Domain wird zu Setup → Trusted URLs hinzugefügt. Es ist eine integrierte Governance-Schicht. Dennoch liest der Agent die echten URLs intern weiterhin und verwendet sie im Reasoning. Um bestimmte URLs an Benutzer weiterzuleiten, fügen Sie die Quell-Domains (Forbes, Reuters, Ihre eigenen Seiten) zur Allowlist hinzu.

Was ist ein Bright Data 520-Fehler?

Ein 520 ist der Status, den Web Unlocker zurückgibt, wenn eine Zielseite bei einem bestimmten Versuch nicht abgerufen werden konnte, normalerweise weil die Abwehrmechanismen der Seite die Anfrage blockiert haben. Regel 5 der Subagenten-Anweisungen verbietet das Erfinden von Inhalten, wenn ein Tool fehlschlägt, sodass der Agent den Fehler ehrlich meldet und anbietet, es erneut zu versuchen.

Welche anderen Anwendungsfälle deckt dieses Muster ab?

Abwanderungsrisiko, Wettbewerbsintelligenz und Verlängerungsrisiko-Briefings passen alle in dieses Muster. Das liegt daran, dass die beiden Apex-Aktionen (Nachrichten suchen, URL abrufen) die meisten Account-Intelligence-Typen abdecken. Für Abwanderungsrisiko verwenden Sie die Nachrichtensuche, um Entlassungen und Führungswechsel zu verfolgen. Für Wettbewerbsintelligenz rufen Sie die Preisseiten der Konkurrenten ab. Nur die Prompts ändern sich.