Opublikowano: 12 czerwca 2026 | Czas czytania: 7 minut | Kategoria: Salesforce

TL;DR

Budowa agenta serwisowego Agentforce do przechwytywania leadów wymaga bezpiecznego zarządzania stanem wieloetapowym. Chociaż standardowe przepływy (Flows) świetnie nadają się do prostych zadań, użycie metody Apex @InvocableMethod pozwala na trwałe śledzenie stanu między etapami rozmowy i bezpieczne operacje DML w trybie USER_MODE. Oto dokładny sposób budowy takiego agenta.

Wprowadzenie: Era Agentforce

Salesforce Agentforce całkowicie zmieniło sposób, w jaki myślimy o zautomatyzowanych interakcjach z klientami. Przechodzimy od sztywnych, opartych na drzewach chatbotów do autonomicznych agentów, którzy potrafią rozumować, zadawać pytania doprecyzowujące i wykonywać akcje.

Jednym z najczęstszych wczesnych zastosowań Agentforce jest przechwytywanie leadów. Cel jest prosty: agent AI pyta użytkownika o jego dane (np. Nazwisko i Firma), przechowuje te informacje przez wiele etapów rozmowy i tworzy rekord Leada w Salesforce po zebraniu wszystkich wymaganych danych.

Chociaż można by to osiągnąć za pomocą przepływu ekranowego (screen flow) lub przepływu uruchamianego automatycznie (autolaunched flow), wywoływalne akcje Apex zapewniają znacznie większą kontrolę nad zarządzaniem stanem i kontekstem bezpieczeństwa.

Oto dokładny plan produkcji gotowego agenta do przechwytywania leadów w 2026 roku.

Architektura

Nasze rozwiązanie wymaga trzech kluczowych komponentów:

  1. Router Agentów (start_agent): Wita użytkownika i kieruje go do odpowiedniego podagenta na podstawie intencji.
  2. Podagent Przechwytywania Leadów (subagent): Instruuje LLM, jakie pola są wymagane (Nazwisko i Firma) i uruchamia akcję.
  3. Wywoływalna Akcja Apex (@InvocableMethod): Rzeczywisty "silnik", który analizuje dane wejściowe, przechowuje stan i wykonuje wstawienie do bazy danych.

1. Skrypt Agentów DSL

Agentforce używa specyficznego języka domenowego (DSL) do definiowania zachowania agenta. Definiujemy zmienne do przechowywania danych wejściowych użytkownika między etapami.

variables:
    last_name: mutable string = ""
        description: "Lead last name"
    company: mutable string = ""
        description: "Lead company"
    lead_created: mutable boolean = False
        description: "Whether the lead has already been created"
    last_lead_id: mutable string = ""
        description: "The most recently created Lead ID"

Logika naszego podagenta dyktuje, że dla każdej wiadomości wysłanej przez użytkownika podczas interakcji w temacie przechwytywania leadów, wywołujemy naszą akcję Apex. Przekazujemy bieżącą wiadomość użytkownika (userMessage) wraz z zebranymi dotychczas zmiennymi last_name i company.

subagent lead_capture:
    label: "Lead Capture"
    description: "Collect last name and company, then create a Salesforce Lead through Apex."
    reasoning:
        instructions: ->
            if @variables.lead_created == True:
                | A lead has already been created in this conversation. Share the Lead ID and ask if the user wants anything else.
            if @variables.lead_created == False:
                | Use Process Lead Capture Turn for every lead-capture message.
        actions:
            process_lead_turn: @actions.process_lead_turn
                    with userMessage = ...
                    with knownLastName = @variables.last_name
                    with knownCompany = @variables.company
                    set @variables.last_name = @outputs.resolvedLastName
                    set @variables.company = @outputs.resolvedCompany
                    set @variables.lead_created = @outputs.isSuccess
                    set @variables.last_lead_id = @outputs.leadId

2. Wywoływalna Akcja Apex

Prawdziwa moc tego wzorca leży w klasie Apex. Zamiast polegać na LLM w zgadywaniu, kiedy utworzyć leada, używamy wywoływalnej akcji do bezpiecznego zarządzania logiką biznesową.

Dlaczego Apex zamiast Flow?

  • Stan wieloetapowy: Przekazując knownLastName i knownCompany do akcji Apex i zwracając resolvedLastName i resolvedCompany, doskonale utrzymujemy stan rozmowy, nawet jeśli użytkownik poda informacje w niewłaściwej kolejności.
  • Kontekst bezpieczeństwa: Możemy dynamicznie egzekwować uprawnienia Field Level Security (FLS) i CRUD za pomocą AccessLevel.USER_MODE.

Poniżej znajduje się struktura zmiennych wejściowych i wyjściowych:

public class LeadCaptureTurnAction {
    
    public class Request {
        @InvocableVariable(required=true label='User Message')
        public String userMessage;
        
        @InvocableVariable(label='Known Last Name')
        public String knownLastName;
        
        @InvocableVariable(label='Known Company')
        public String knownCompany;
    }
    
    public class Result {
        @InvocableVariable(label='Is Success')
        public Boolean isSuccess;
        
        @InvocableVariable(label='Lead ID')
        public String leadId; // GOTCHA: Must be String, not Id
        
        @InvocableVariable(label='Resolved Last Name')
        public String resolvedLastName;
        
        @InvocableVariable(label='Resolved Company')
        public String resolvedCompany;
        
        @InvocableVariable(label='Message')
        public String message;
    }
    
    @InvocableMethod(label='Process Lead Capture Turn')
    public static List<Result> processTurn(List<Request> requests) {
        // 1. Parse the userMessage for missing fields using Regex
        // 2. Combine found fields with knownLastName and knownCompany
        // 3. If both are present, insert the Lead
        // 4. Return the Result
    }
}

Pułapka z powiązaniem leadId

Zauważ, że public String leadId; jest zdefiniowany jako String, a nie Id. Jest to kluczowy niuans w Agentforce. Podczas powiązania wyjścia wywoływalnej akcji ze zmienną skryptu agenta (set @variables.last_lead_id = @outputs.leadId), Agentforce zdecydowanie preferuje prymitywne typy stringowe nad ścisłymi typami Id Salesforce. Użycie Id może powodować ciche błędy powiązania podczas wykonywania.

3. Egzekwowanie bezpieczeństwa za pomocą USER_MODE

Kiedy Agentforce wykonuje wywoływalną akcję, działa w kontekście użytkownika Einstein Service Agent (lub Twojego domyślnego użytkownika agenta).

Jeśli spróbujesz wstawić leada za pomocą standardowego DML (insert newLead;), kontekst systemu może ominąć niezbędne kontrole bezpieczeństwa lub zakończyć się niepowodzeniem w nieprzewidywalny sposób, w zależności od ustawień udostępniania organizacji.

Poprawne podejście w 2026 roku polega na zawsze egzekwowaniu DML w trybie użytkownika:

Database.SaveResult sr = Database.insert(newLead, false, AccessLevel.USER_MODE);

Brakujący Zestaw Uprawnień

Aby wstawienie USER_MODE działało, użytkownik Einstein Service Agent musi mieć uprawnienia do tworzenia rekordów Lead.

Musisz utworzyć Zestaw Uprawnień (np. LeadCaptureAgent_Apex_Access), który przyznaje:

  1. Dostęp do klasy Apex: Do Twojej klasy LeadCaptureTurnAction.
  2. Dostęp do obiektu: Uprawnienia odczytu i tworzenia na obiekcie Lead.
  3. Uprawnienia do pól: Dostęp do edycji pól LastName i Company.

Przypisz ten Zestaw Uprawnień do użytkownika Einstein Service Agent. Bez niego agent będzie zapętlał się w nieskończoność, pytając o pola, które już zebrał, ponieważ ciche niepowodzenie DML w trybie USER_MODE uniemożliwia zwrócenie isSuccess jako true.

4. Testowanie Agenta Lokalnie

Przed publikacją powinieneś zweryfikować logikę wieloetapową za pomocą Salesforce CLI. Polecenie sf agent preview pozwala symulować rozmowę bezpośrednio z terminala.

# Start the session
sf agent preview start --json --authoring-bundle LeadCaptureAgent --use-live-actions --target-org my-org

# Send the first utterance (Company only)
sf agent preview send --json --session-id <SESSION_ID> --utterance "My company is Acme Corp" --authoring-bundle LeadCaptureAgent --target-org my-org

# Send the second utterance (Last Name)
sf agent preview send --json --session-id <SESSION_ID> --utterance "My last name is Smith" --authoring-bundle LeadCaptureAgent --target-org my-org

# Verify the Lead creation
sf data query --query "SELECT Id, LastName, Company FROM Lead ORDER BY CreatedDate DESC LIMIT 1" --target-org my-org

Podsumowanie

Agentforce pozwala nam tworzyć niezwykle dynamiczne doświadczenia konwersacyjne, ale wymaga zmiany sposobu, w jaki zarządzamy stanem i bezpieczeństwem. Kierując przechwytywanie leadów przez dedykowanego podagenta i polegając na wywoływalnych akcjach Apex do deterministycznego zarządzania stanem, zapewniasz bezpieczne, odporne i przyjazne dla użytkownika doświadczenie.

Zawsze pamiętaj, aby używać String dla wyjść ID, egzekwować DML w trybie USER_MODE i przypisywać odpowiednie zestawy uprawnień do użytkownika agenta.

O autorze: Ten przewodnik został napisany przez zespół redakcyjny Resumity, badający przecięcie nowoczesnych platform AI i architektury CRM dla przedsiębiorstw.