Agentit päättelevät tavoitteiden perusteella, laskevat parametrit asiayhteydestä ja valitsevat toiminnot dynaamisesti. Tästä syystä jokaisen agentin käyttämän integraation täytyy käsitellä epäselvyys, tukea turvallista toistoa ja epäonnistua, jotta agentti voi toipua itsenäisesti.

Agenttien järjestelmät mitätöivät useita oletuksia, jotka perinteisen integraation suunnittelu pitää itsestäänselvyytenä. Syötetyt tiedot eivät ole aina hyvin muotoiltuja. Yksittäinen käyttäjän toiminto voi luoda organisaation eri rajojen ketjun agentteja, jotka kaikki tarvitsevat delegoidun valtuuden toimia.

Tämä asiakirja kartoittaa todellisuudesta seuraavat arkkitehtoniset työvuorot: uudet suunnitteluperiaatteet, agenttien kuviot ja miten Salesforce-alusta toimittaa ne.

Tämän asiakirjan jokainen kuvio noudattaa samaa rakennetta:

Nimi: Kuvion tunnus, joka osoittaa kuviossa olevan integraation tyypin.

Konteksti: Kokonaisvaltainen integraatioskenaario, johon kuvio vaikuttaa. Konteksti tarjoaa tietoja siitä, mitä käyttäjät yrittävät saavuttaa ja miten sovellus toimii heidän tarpeidensa mukaan.

Ongelma: Haaste (ilmaistuna kysymyksenä), jonka ratkaisemiseksi kuvio on suunniteltu. Kun tarkastelet kuvioita, lue tämä osio ymmärtääksesi nopeasti, sovelletaanko kuviota integraatioskenaarioosi.

:Voimat Rajoitukset ja olosuhteet, jotka voivat vaikeuttaa ongelman ratkaisemista.

Salesforce-kuviosovellus: Suositeltu tapa soveltaa kuviota skenaarioon.

Luonnos: Yhtenäistetty mallinnuskieli (UML) -järjestelmäkaavio, joka näyttää, miten kuviosovellus käsittelee skenaariota.

Tulokset: Miten kuvio ratkaisee skenaarioon liittyvät voimat. Tämä osio sisältää myös uusia haasteita, jotka voivat ilmetä kuviossa.

Suunnittelussa huomioitavia asioita: Sovellusalustan ulkopuolinen ohje ratkaisun oikeaan käyttöön, jonka jälkeen tulee Salesforce-kohtaisia toteutushuomautuksia. Nämä huomioitavat asiat koskevat toimintojen suunnitteluperiaatteita ja sovellusalustakohtaisia kokoonpanovaatimuksia.

Virheiden käsittely ja palautus: Ohjeita virheiden hallintaan kuviokäyttöönoton aikana. Tämä parametri kattaa neljä aluetta:

• Miten toiminnot kertovat virheistä agentille rakenteellisten ja interaktiivisten virheiden vastausten avulla, jotka tarjoavat riittävän asiayhteyden myöhempää päätöksentekoa varten
• Miten agentti määrittää, yrittääkö hän suorittaa uudelleen, korjaa itsensä vai lopettaa suorituksen
• Miten kompensaatiotoiminnot käsittelevät osittaisia lopputuloksia ja yhteensopimattomia sovellusalustan välisiä tiloja
• Idempotenssin vaatimukset poistetuille kirjoitustoiminnoille

Turvallisuudessa huomioitavia asioita: Kuvion turvallisen käyttöönoton suojausvaatimukset. Nämä huomioitavat asiat koskevat tunnusten hallintaa, integrointikäyttäjien ja yhdistettyjen sovellusten vähiten käyttöoikeuksia, agenttien kutsuttamien toimintojen lokien kirjautumista ja muun muassa käyttäjän tarjoamasta tai LLM:n antamasta sisällöstä peräisin olevien parametrien syöttövahvistuksen vaatimuksia.

Esimerkki: Päättymiskenaario, joka kuvaa, miten suunnittelukuviota käytetään todellisessa Salesforce-skenaariossa. Tämä esimerkki selittää tavoitteet ja miten käyttää kuviota tavoitteiden saavuttamiseen.

Seuraava taulukko kuvaa katetut toteutuskuviot.

Kuvioiden luettelo

Tämän asiakirjan kuviot on jaettu kolmeen luokkaan. Tämä luokittelu auttaa arkkitehtejä tunnistamaan nopeasti, mitkä kuviot ovat tärkeitä ratkaisemassaan integraatiokysymykseen, olivatpa he suunnittelevat, mitä agentti kutsuu, mikä käynnistää agentin tai miten agentti perustuu Knowledgeen ennen kuin se toimii. Sen sijaan, että luisit jokaisen kuviosi, voit siirtyä suoraan suunnitteluun liittyvään kategoriaan.

Toiminnon kutsu:

Nämä kuviot kattavat, miten agentti kutsuu ulkoisia järjestelmiä noutamaan tietoja tai suorittamaan toimintoja osana päättelysykliään. Nämä ovat lähteviä kuvioita, joissa agentti on käynnistin. Ne käsittelevät järjestystä (kun vaiheet ovat riippuvaisia toisistaan), rinnakkaisuutta (kun ne eivät ole), idempotenssia ja osittaisten virheiden käsittelyä. Käytä näitä kuvioita suunnitellessasi työkaluja, joita agentti kutsuu töiden suorittamiseen.

Agentin kutsu:

Nämä kuviot käsittelevät, miten ulkoiset järjestelmät tai tapahtumat auttavat agenttia toimimaan. Nämä ovat saapuvia kuvioita, joista ulkoiset järjestelmät käynnistävät nämä agentit. Käynnistin voi olla henkilökohtainen sovellus, joka soittaa ohjelmallista puhelua ja odottaa vastausta, tai itsenäinen dataehto, joka käynnistää agentin. Käytä näitä kuvioita suunnitellessasi, miten ja milloin agentti käynnistetään.

Alustaminen Enterprise-datalla:

Tämän kategorian kuviot kattavat, miten agentit peritään tarkalla, ajankohtaisella ja organisaatiokohtaisella Knowledgella ennen kuin he antavat syitä tai toimivat.

Oikean strategian valitseminen ei ole tarpeeton. Jokainen kuvio keskittyy tiettyyn huolenaiheeseen: järjestelmän ominaisuudet, datamäärä, virheiden käsittely ja transaktiivisuus.

Valintamatriisitaulukoissa näytetään kuviot ja niiden tärkeimmät näkökohdat, jotka auttavat sinua määrittämään, mikä kuvio sopii parhaiten integraatiovaatimuksiisi. Kuvakkeet luokitellaan näiden ulottuvuuksien perusteella.

Tämä taulukko kuvaa kuviot ja niiden tärkeimmät näkökohdat, jotta voit määrittää, mikä kuvio sopii parhaiten tarpeisiisi, kun integraatiosi tapahtuu Salesforcesta toiseen järjestelmään.

Kuvioiden jokainen osio kuvaa, miten ne rakennetaan. Jokainen kuvio on toistuva ratkaisu tiettyyn integraation ongelmaan agenttien arkkitehtuurissa. Se kattaa, milloin kuviota käytetään, mitkä voimat määrittävät päätöksen ja miten Salesforce-alusta tarjoaa sen.

Konteksti

Monet liiketoimintatyönkulut ovat luonnostaan järjestyksessä – jokainen vaihe vaatii edellisestä vahvistetun tuloksen ennen kuin se voidaan jatkaa. Hyvitystä ei voi esimerkiksi käynnistää ennen kuin oikeutus on vahvistettu, laskutustiliä ei voi luoda ennen kuin tilaustietue on olemassa eikä vaatimustenmukaisuuden tarkistusta voi kirjata lokiin ennen kuin tarkastus on suoritettu.

Perinteisessä automatisoinnissa nämä sidonnaisuudet on koodattu kovakoodatuksi kulun logiikaksi. Agenttijärjestelmässä agentti arvioi kunkin toiminnon tuloksen ja määrittää, täyttyvätkö seuraavan vaiheen edellytykset.

Tämä kuvio kuvaa lähtevän integraation perusmallia. Tässä tapauksessa yksi agentti toimii yhdessä toimialueessa ja kutsuu järjestystä, jossa kunkin toiminnon output-portaali kutsuu ketjun seuraavaa toimintoa. Orkestrointiagentti ylläpitää transaktioiden kontekstia koko ketjussa, kerääen tunnisteita, tilakoodeja ja kunkin vaiheen palauttamia tietoja. Se käyttää tätä kontekstia myöhempien päätösten tekemiseen.

Tämä kuvio on agenteellinen vastaavuus Prosessin etäkutsut – Pyynnöt ja vastaukset Integration Patterns -oppaasta, joka kuvaa yhden synkronoidun callout-kutsun. Agenttikuvio laajentaa kuvion agentteihin perustuvaan sidonnaisten puheluiden ketjuun yhdessä päättelysyklissä.

Ongelma

Kun agentti suorittaa monivaiheisen työnkulun, joka kattaa isäntäjärjestelmän ja yhden tai useamman etäjärjestelmän, hänen täytyy ratkaista neljä ongelmaa:

• Sequencing – Toimintoja täytyy kutsua oikeassa järjestyksessä, ja jokainen vaihe on varattu edellisen vaiheen onnistuneen suorittamisen perusteella.
• Datan propagointi - Vastaustiedot jokaisesta vaiheesta täytyy välittää syötteenä seuraavaan vaiheeseen.
• Virheen eristys - Ketjun missään vaiheessa tapahtuneet virheet eivät saa aiheuttaa osittaista tai epäjohdonmukaista tilaa eri järjestelmissä.
• Valmistuksen vahvistus - Agentin täytyy vahvistaa, että kaikki vaiheet on suoritettu onnistuneesti ennen tuloksen raportointia.

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Riippuvatko ketjun toiminnot edellisen toiminnon palauttamista tiedoista vai ovatko riippuvuudet vain onnistuneen tai epäonnistuneen tilan perusteella?

  Datan sidonnaisuudet vaativat, että agentti käyttää tunnisteita ja attribuutteja eri vaiheissa.

• Voivatko kaikki etäpäätepisteet vastata agentin päättelysyklin aikakatkaisun sisällä?

  Hidas ulkoinen järjestelmä ketjun missä tahansa vaiheessa estää koko järjestyksen.

• Vaatiikö ketju täydellisen lopputuloksen vai hyväksytäänkö osittainen suoritus?

• Jos täysi lopputuloksen onnistuminen on pakollista, määritä korvausstrategia vaiheille, jotka täytyy peruuttaa, kun alaviiva epäonnistuu.

• Voiko ketjun kirjoitusoperaatioita yrittää uudelleen turvallisesti?

  Kaikkien kirjoitustoimintojen täytyy olla idempotent-muotoisia. Agentin järkeytyskulku voi kutsua samaa toimintoa useammin kuin kerran suurten kielimallien (LLM) uudelleenyritysten tai epäselvien vahvistusten vuoksi.

• Kutsuuko ketjua käyttäjän vuorovaikutus (keskustelu, vähäinen samanaikaisuus) vai automatisoitu käynnistin (mahdollisesti suuri samanaikaisuus)?

  Tämä määrittää, onko synkronoitu esto hyväksyttävä vai vaaditaanko asynkronointikuvio.

Salesforce-kuviosovellus

Kuvaus

Jakson kaavio toimintojen peräkkäiselle kutsulle

Tulokset

Agentti suorittaa järjestelmien välisen työnkulun johdonmukaisena ja valvomana järjestyksenä, eikä ”Fire and Forget” -komentosarjana. Jokaisen vaiheen tulokset arvioidaan ennen seuraavan vaiheen käynnistämistä, joten agentti havaitsee virheet mahdollisimman varhaisessa vaiheessa sen sijaan, että hän huomasi suorituksen osittain tapahtuneen jälkeen.

Isäntäjärjestelmä (Salesforce CRM) päivitetään vasta, kun etätoiminto on vahvistanut tilan (onnistui tai epäonnistui). Ulkoisten järjestelmien palauttamat tunnisteet ja tilat, kuten laskutustilien numerot, transaktioiden tunnukset ja vahvistuskoodit, lisätään ketjun läpi ja säilyvät, mikä luo työnkulun lopputuloksen täydellisen ja jäljitettävän tietueen.

Agentti on vastuussa tulosten perustelemisesta ja päätösten järjestyksestä. Jokainen toiminto on vastuussa vain omasta toiminnostaan ja rakenteellisen tuloksen palauttamisesta. Kumpikaan kerros ei koodaa toisen logiikkaa.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Varmista, että jokainen ketjun toiminto sisältää semanttisen kuvauksen, joka on kirjoitettu tarkoituskielellä, eikä teknisen metodin allekirjoituksena. Agentti valitsee toimintoja näiden kuvausten perusteella. Kuvaus, jossa lukee ”kutsuu laskutus-API:a”, on vähemmän hyödyllinen kuin kuvaus, jossa lukee ”luo laskutus-tilin laskutusjärjestelmässä ja palauttaa uuden tilin tunnisteen”.
• Tee ketjun kaikista kirjoitustoiminnoista idempotent. Agentin päättelysilmukka saattaa yrittää toimintoa uudelleen, jos se saa epäselvän vastauksen. Toiminnon täytyy tuottaa sama lopputulos toistuvalle kutsulle.
• Vahvista kaikki LLM:n johtamat syöttöparametrit puolustuksellisesti toimintorajoituksessa. Älä koskaan oleta, että agentin välittämät parametrit ovat hyvin muodostettuja, alueen sisällä tai odotetun tyypin.
• Suunnittele jokainen toiminto yhdelle vastuulle. Toiminto, joka luo laskutustilin ja lähettää vahvistussähköpostin samassa puhelussa, on vaikeampi yrittää uudelleen, vaikeampi testata ja agentin on vaikeampi päättää kahdesta erillisestä toiminnosta.

Salesforcen toteutushuomautukset

• Huomioi Apex-toiminnot @InvocableMethod(otsikko=’...’ description=’...’). Agentti lukee ”kuvauksen” määrittääkseen, milloin toimintoa kutsutaan. Esittele kaikki input- ja output-muuttujat @InvocableVariable-muuttujalla käyttämällä kuvaavia ”otsikko”- ja ”kuvaus”-kenttiä. Palauta rakenteellisia tulosobjekteja, joilla on selkeät onnistumisen/epäonnistumisen osoittimet ja ihmiselle luettavissa olevat virheviestit.
• Käytä kulkutoiminnoille vain automaattisesti käynnistyviä kulkuja. Ruutukulkuja ei tueta autonomisissa agenttien asiayhteyksissä. Pidä jokainen kulku atomina: yksi toiminto, yksi vastuu. Määritä vikapolut jokaiselle ulkoiselle callout-elementille havaitaksesi integraatiovirheet ja palauttaaksesi agenteille interaktiivisia virheviestejä sen sijaan, että sallisit havaitsemattomien poikkeusten lopettaa istunnon.
• Tuo kohdejärjestelmän OpenAPI-määritys ulkoisille palveluille ja rekisteröi luodut toiminnot Agentforce-aiheessa. Käännä luodut kentät nimettyihin tunnuksiin välttyäksesi toiminnon määritelmän päätepisteiden tai tunnusten kovakoodaamiselta.
• Määritä erilliset aikakatkaisut kaikille ulkoisille callout-kutsuille. Callout, joka keskeytyy ilman aikakatkaisua, estää agentin päättelysyklin, kunnes istuntojen rajoitus saavutetaan. Palauta hienostunut virhe kuvaavalla virheviestillä, kun aikakatkaisu ylittyy. Kaikilla ulkoisilla callout-kutsuilla on määritettävä aikakatkaisu enintään 120 sekuntia. Ne ovat myös Apexin synkronoitujen transaktioiden hallintarajoitusten alaisia, joten muista vähentää yli 50 transaktion esiintymisen riskiä, jotka kestävät yli viisi sekuntia.

Virheiden käsittely ja palautus

• Agentti palauttaa jokaisen vaiheen, kun vaiheen edellinen onnistui. Toimintojen täytyy palauttaa rakenteellinen tulos, joka sisältää selkeän onnistumisen tai epäonnistumisen osoittimen. Agentti ei voi luotettavasti päätellä epäonnistumista yksin puuttuvasta vastauksesta tai null-vastauksesta.
• Kun toiminto epäonnistuu, agentti käyttää toiminnon palauttamaa virheviestiä määrittääkseen seuraavan siirron: pyydä käyttäjää tekemään korjattuja syötteitä, yritä itse parantaa uudelleen säädetyillä parametreillä tai pysäytä ketju ja kirjaa epäonnistuminen ihmisen tarkastettavaksi. Virheviestien täytyy siis olla tarkkoja ja interaktiivisia: "Virheellinen ajanjakso: endDate ei voi olla ennen startDate" -arvoa käytettävissä; vain 400-tilakoodi ei.
• Jos ketjujen osittainen täydennys luo epäjohdonmukaisen tilan (esimerkiksi laskutustili luotiin, mutta CRM-tietuetta ei päivitetty), agentti kutsuu korvaustoimintoa peruuttaakseen tai merkitäkseen osittaisen tilan ennen kuin virhe ilmestyy. Suunnittele kompensaatiopolut nimettyinä toimintoina edistymispolun vieressä.
• Jos kirjoitustoiminto onnistui mahdollisesti, mutta palautti epäselvän vastauksen (verkon aikakatkaisu, ei hyväksyntää), uudelleenyrityksen täytyy käyttää samaa idempotenss-avainta tai ulkoista viitetunnusta kuin alkuperäinen kutsu. Älä koskaan lähetä valitsematonta uudelleenyritystä ei-idempotent-kirjoitukselle.

Turvallisuudessa huomioitavia asioita

• Käännä kaikki ulkoiset callout-kutsut nimettyihin tunnuksiin. Älä koskaan kovakoodaa päätepisteitä tai tunnuksia Apex tai kulkukokoonpanoissa. Näitä täytyy hallita sovellusalustan suojatun tunnusten säilytyksen kautta ja kierrättää ilman koodimuutoksia.
• Sovella vähiten käyttöoikeuksia kunkin toiminnon käyttämälle integraatiokäyttäjälle tai yhdistetylle sovellukselle. Toiminnolla, joka vain lukee tilaustietoja, ei tulisi olla kirjoitusoikeuksia laskutusjärjestelmässä. Vaikutusalueen tunnukset toimintoon vaadittuihin vähimmäistoimintoihin.
• Kirjaa ketjun kunkin toiminnon kutsut lokiin sen istuntotunnuksella, input-parametreillä (luottamuksellisten arvojen sanitoimilla) ja lopputuloksella. Jos tulos on kiistanalainen, tämä kirjausketju on ensisijainen mekanismi, jolla voit määrittää, miksi agentti suoritti tietyn toimintojen järjestyksen.
• Purkaa kaikki syöttöparametrit, jotka saadaan käyttäjän antamasta tekstistä, ennen kuin välität ne ulkoisiin järjestelmiin. Agentin kautta ulkoiseen API-callout-kutsuun välitetty käyttäjän syöttämä tieto on potentiaalinen injektiovektor. Vahvista toiminnon rajan tyyppi, muoto ja arvoalue ennen callout-kutsun tekemistä.

Esimerkki

Hyvityspyynnön käsittelevä palveluagentti suorittaa nelivaiheisen ketjun:

1. GetOrderDetails (Apex-toiminto) noutaa tilaustietueen Tilaustenhallinta-järjestelmästä käyttäjän antaman tilauksen tunnuksen perusteella. Se palauttaa tilauksen tilan, rivikohteet, ostopäivän ja maksutavan. Agentti arvioi ennen jatkamista, onko tilaus hyvitettävissä.
2. ValidateRefundEligibility (Automaattisesti käynnistyvä kulku) käyttää hyvityksen oikeutusta koskevia liiketoimintasääntöjä, mukaan lukien palautusjakso, tuotekategorian rajoitukset ja edellinen hyvityshistoria. Se palauttaa ”hyväksyttävän” totuusarvon ja, jos ei, pelkän kielen syyn, miksi agentti voidaan näyttää käyttäjälle.
3. InitiateRefund (Apex Action) kutsuu ulkoisen maksusiltapalvelun API:a tilauksen tunnuksella ja hyvityksen summalla. Palauttaa ”refundTransactionId”-arvon onnistuneesti. Tämä toiminto on idempotent. Jos kutsutaan toista kertaa samalla tilaustunnuksella, se palauttaa olemassa olevan transaktion tunnuksen identtisen hyvityksen luomisen sijaan.
4. UpdateCaseStatus (Automaattisesti käynnistyvä kulku) päivittää CRM-tapausten tietueen hyvitystapahtuman tunnuksella, määrittää tapauksen tilaksi "Resolved Refund Issued" ja luo tilin omistajalle seurantatehtävän. Tämä vaihe suoritetaan vasta, kun ”InitiateRefund” on palauttanut vahvistetun transaktion tunnuksen.

Jos InitiateRefund aikakatkaisee tai palauttaa virheen, agentti pysäyttää ketjun, ei kutsu UpdateCaseStatus ja näyttää käyttäjälle interaktiivisen viestin. Tapaus pysyy avoinna ja ratkaisemattomana, mikä säilyttää tarkan tilan CRM:ssä.

Konteksti

Peräkkäiset toimintoketjut ovat tehokkaita, kun suoritusvaiheet ovat riippuvaisia toisistaan. Yksi vaihe avaa seuraavan. Monet työnkulut sisältävät kuitenkin vaiheita, joilla ei ole toistensa välistä riippuvuutta. Esimerkiksi vaiheet, joihin sisältyy tuoteinventaarion noutaminen, asiakkaan oikeutusten noutaminen ja toimituksen arvioinnin tarkastaminen, voivat tapahtua samanaikaisesti, koska yksikään vaihe ei tarvitse toisen vaiheen tuloksia. Näiden vaiheiden suorittaminen järjestyksessä kuluttaa aikaa suhteessa vaiheiden määrään.

Yhdensuuntaisessa kutsukuvioissa agentti tunnistaa, että toimintojen joukko on itsenäinen, ja kutsuu niitä samanaikaisesti eikä järjestyksessä. Kokonaistyönkulun aika riippuu hitaimmasta yksittäisestä toiminnosta, eikä kaikkien toimintojen aikojen summasta. Kun kaikki tulokset on palautettu, agentti kerää ne yhteen yhdenmukaiseen vastaukseen tai käyttää niitä yhdessä syötteinä seuraavaan perusteluvaiheeseen.

Tärkein arkkitehtuurin haaste ei ole itse rinnakkainen kutsu. Se hallitsee sovellusalustan samanaikaisten rajoitusten ulkopuolista poistamista ja varmistaa, että aggregointivaihe käsittelee osittaiset epäonnistumiset huolellisesti hylkäämättä onnistuneita tuloksia.

Ongelma

Miten agentti organisoi useiden itsenäisten ominaisuuksien samanaikaisen suorituksen tehokkaasti ja aggregoi yksittäiset tulokset yhdeksi yhdenmukaiseksi vastaukseksi käyttäjälle tai seuraaville vaiheille?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Mitkä ovat ketjun turvallisuutta ja vaihtuvan tilan jakamista koskevat toiminnot?
• Miten ratkaisu hallitsee ja välttää Salesforcen hallintarajoitusten ylittymistä samanaikaisille Apex yhdessä transaktiossa?
• Tarvitseeko ei-synkronoituja kuvioita (kuten Queueable Apex tai Platform Events) käyttää hallintarajoitusten välttämiseksi?
• Vaaditaanko tulosten synkronointi ennen kuin agentti voi jatkaa?

Salesforce-kuviosovellus

Kuvaus

Toimintojen rinnakkaisen kutsun järjestyskaavio

Tulokset

Kun itsenäisiä toimintoja suoritetaan rinnakkain, työnkulun päättymisaika riippuu hitaimmasta yksittäisestä toiminnosta kaikkien toimintojen summan sijaan. Jos työnkulussa on kolme itsenäistä callout-kutsua, joiden keskiarvo on 300 ms, samanaikainen suoritus suoritetaan ~300 ms:ssä; peräkkäinen suoritus kestää ~900 ms. Tämä eroavaisuus koostuu kaikista samanaikaisesti suoritetuista agentti-istunnoista.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Vahvista itsenäisyys ennen yhdistämistä. Toimintoja voidaan suorittaa turvallisesti rinnakkain vain, jos toinen toiminnoista ei lue toisen toiminnon kirjoittamaa tilaa, eikä kummankaan toiminnon epäonnistumisen pitäisi peruuttaa toista toimintoa. Jos riippuvuus on olemassa, käytä sen sijaan peräkkäistä ketjutusta.
• Suunnittele aggregointivaihe tarkasti. Määritä etukäteen, miltä täydellinen tulosjoukko näyttää, mitä osittainen tulosjoukko tarkoittaa myöhemmälle päättelylle ja tulisiko agentin odottaa kaikkia tuloksia vai jatkaa, kun kynnysarvo on palautettu (esimerkiksi viisi yhteensä seitsemästä puhelusta).
• Kaikkien samanaikaisten kirjoitusoperaatioiden täytyy olla idempotent. Jokainen toiminto suoritetaan erillään ilman jaettua transaktion rajaa, joten yksittäisen haaran uudelleenyrittäminen ei voi aiheuttaa samanlaisia sivuvaikutuksia.

Salesforcen toteutushuomautukset

• Queueable Apex: Lähetä kaikki työt yhteen transaktioon maksimoidaksesi samanaikaisen suorituksen mahdollisuuden. Ota huomioon, että käytettävissä olevat samanaikaiset aikaslotit ovat jaettuja koko organisaatiossa. Suunnittele ne olettaen, että aikaslotit eivät välttämättä ole aina käytettävissä, ja luo varmuuskopio järjestyksellisille suorituksille, kun ne eivät ole.
• Sovellusalustan tapahtumat: Kirjoita kunkin toiminnon tulokset erilliseen vaiheistustietueeseen (joka on jaetun korrelaatiotunnuksen avain) sen sijaan, että päivittäisit kohdetietuetta suoraan. Lopullinen aggregointikulku tai Apex lukee kaikki vaiheittaiset tietueet, kun odotettu määrä on saavutettu, ja soveltaa sitten yhdistettyä päivitystä atomisesti.
• Midleware Fan-Out: Määritä yksittäiselle callout-kutsulle selkeä aikakatkaisu, joka on pidempi kuin hitaimman taustaversion odotettu huonompi vastausaika, mutta silti Salesforcen callout-kutsujen aikakatkaisurajoituksen sisällä. Välitysohjelmisto palauttaa osittaisia tuloksia, jotka osoittavat selkeästi, mikä taustajärjestelmä epäonnistui, sen sijaan että ajoittaisi koko vastauksen.

Virheiden käsittely ja palautus

• Käsittele osittaista onnistumista ensimmäisen luokan lopputuloksena. Jos kolme tai neljä samanaikaista operaatiota onnistuvat, agentti käyttää kolmea onnistunutta tulosta ja käsittelee epäonnistumisen esittämällä sen käyttäjälle, kirjaamalla sen uudelleenyritykselle tai käynnistämällä korvaavan toiminnon sen sijaan, että se hylkäisi kaikki tulokset tai jatkaisi kuin epäonnistuminen ei olisi tapahtunut.
• Käytä Jonotettava- ja Sovellusalustan tapahtuma -kuvioille korrelaatiotunnusta (luotu fan-out-pisteessä) linkittääksesi kaikki rinnakkaiset haarat takaisin alkuperäiseen agentti-istuntoon. Tämä tunnus vaaditaan tulosten yhdistämiseksi uudelleen ja virheiden jäljittämiseksi lokien lähteeseen.
• Jos rinnakkainen haara epäonnistuu ja operaatio on turvallista yrittää uudelleen, jonota vain epäonnistunut haara uudelleen käyttämällä alkuperäistä korrelaatiotunnusta ja idempotency-avainta. Älä kutsu kaikkia haaroja uudelleen.
• Määritä aggregointivaiheen aikakatkaisun kynnysarvo. Jos kaikki tulokset eivät saavuta kynnysarvoa, jatka käytettävissä olevien tulosten kanssa ja merkitse ei-täydellinen joukko sen sijaan, että odottaisit loputtomiin.

Turvallisuudessa huomioitavia asioita

• Jokaisen samanaikaisen suorituksen asiayhteyden, olipa se sitten jonoitettava työ, sovellusalustan tapahtumien käynnistin tai middleware-callout, täytyy käyttää samoja käyttöoikeusasetuksia kuin peräkkäinen callout. Yhdensuuntaisuus ei lievennä tietojen käyttöoikeussääntöjä. Jokaisen haaran täytyy toimia samalla vähiten käyttöoikeuksia käyttävällä tunnuksella kuin jos sitä kutsuttaisiin yksittäin.
• Jos käytät middleware-tuotetta, middleware-kerros ei tallenna tai kirjaa lokiin vastausten tietosisältöjä aggregointijakson ulkopuolisista yksittäisistä taustakentistä. Jokaisen taustapäällikön vastaus voi sisältää luottamuksellisia tietoja, joita ei tulisi säilyttää välittömän toiminnon ulkopuolella.
• Varmista, että sovellusalustan tapahtumien aggregointiin käytetyt vaiheittaiset tietueet eivät ole agentin loppukäyttäjän luettavissa. Nämä tietueet saattavat sisältää väliaikaisia, osittain muodostettuja tietoja, joita ei voida vielä käyttää.

Esimerkki

palveluagentti vastaa monimutkaiseen täydennyskysymykseen: "Voitko lähettää tämän tilauksen minulle perjantaina?" Vastaus vaatii dataa kaikista riippumattomista järjestelmistä samanaikaisesti, niin kuin alla on kuvattu:

1. Agentti tunnistaa kolme itsenäistä datan tarvetta: tämänhetkinen inventaariotaso, asiakkaan aktiiviset oikeutukset ja operaattorin arvioima toimitusjakso asiakkaan sijainnille.
2. Kolme toimintoa kutsutaan rinnakkain: GetInventoryStatus (ulkoisesta inventaariojärjestelmästä middleware-ohjelmiston kautta), GetCustomerEntitlements (Salesforce CRM:stä) ja GetDeliveryEstimate (operaattorin API:sta middleware-ohjelmiston kautta).
3. Jokainen toiminto palauttaa arvon itsenäisesti. Agentti odottaa, kunnes kaikki kolme vastausta saadaan (tai aggregoinnin aikakatkaisu saavutetaan).
4. Kun kaikki kolme tulosta ovat käytettävissä, agentin syyt yhdistettyyn dataan, arvioi, onko inventaario riittävä, asiakkaan oikeutus kattaa nopean toimituksen ja operaattori vahvistaa, että perjantain toimitus on toteutettavissa asiakkaan postinumerolle.
5. Agentti palauttaa käyttäjälle yhden, perustetun vastauksen, joka saatiin kolmesta järjestelmästä, kolmen puhelun vastaamiseen kuluvan hitaimman ajan.

Konteksti

Jotkin agenttien käynnistämät toiminnot eivät tuota tuloksia, joita agentti tarvitsee jatkaakseen nykyistä päättelysykliään. Ilmoituksen lähettäminen, alaisen eräprosessin käynnistäminen, tapahtuman julkaiseminen viestijonoon tai pitkäaikaisen työn lähettäminen ovat kaikki toimintoja, joissa agentin velvollisuudet päättyvät lähetyksen yhteydessä; alainen järjestelmä ottaa omistajan ja suorittaa työn itsenäisesti.

Perinteisessä automatisoinnissa nämä mallinnetaan Fire-and-Forget-callout-kutsuina tai sovellusalustan tapahtumien julkaisuina. Agenttijärjestelmässä agentti päättää perustellessaan, että toiminto ei ole estävä, lähettää sen, tallentaa lähetyksen vahvistuksen ja jatkaa tai lopettaa vuoron odottamatta lopputulosta.

Tämä kuvio on agenteellinen vastaavuus Integration Patterns -oppaan Remote Process Invocation – Fire and Forget -komponenttiin. Agenttikuvio laajentaa sitä tekemällä lähetyksen päätöksestä osan agentin perusteluista ja varmistamalla, että lähetys on jäljitettävissä, vaikka agentille ei palautettaisi vastausta.

Ongelma

Kun agentin täytyy käynnistää edistyvä toiminto, joka ylittää agentin istunnon tai päättelysyklin, hänen täytyy ratkaista kolme ongelmaa:

• Ei-estävä kutsu: Agentin täytyy irtisanoa operaatio ja vahvistaa toimitus pitämättä päättelyjakson auki odottaakseen tuloksia.
• Toimituksen vahvistus: Agentin täytyy erottaa onnistunut lähetys (viesti hyväksyttiin) ja onnistunut lopputulos (alavirran prosessi suoritettu loppuun). Se voi vahvistaa vain edellisen.
• Seurattavuus: Koska agentti ei saa tuloksia, operaatiota täytyy voida havaita lokien, tapahtumatietueiden tai sovellusalustan valvonnan kautta, riippumatta agentti-istunnosta.

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Tarvitseeko agentti tämän toiminnon tuloksen suorittaakseen tämänhetkisen työvuoronsa? Jos näin on, tämä ei ole oikea kaava. Käytä sen sijaan toimintojen peräkkäistä kutsua.

• Voiko alempi järjestelmä vastaanottaa ja käsitellä lähetettyä viestiä tai tapahtumaa luotettavasti ilman synkronoitua hyväksyntää? Kohdejärjestelmän täytyy olla kestävää. Se ei saa menettää viestiä, jos se ei ole väliaikaisesti käytettävissä.

• Onko operaatio idempotent vai täytyykö identtinen lähetys suojata? Verkon tason uudelleenyritykset ja agenttien perusteluiden uudelleenyritykset voivat aiheuttaa saman lähetyksen yrityksen useammin kuin kerran. Jos alempi toiminto ei ole idempotent, toiminnon täytyy sisältää identtisyyden poistamisen avain.

• Täytyykö käyttäjän tai alemman prosessin tietää, milloin toiminto suoritetaan loppuun? Agentti voi vain vahvistaa lähetyksen. Jos valmistumisen tila on pakollinen, suunnittele erillinen ilmoitus tai seurantamekanismi. Sovellusalustan tapahtuma, tapauksen päivitys tai callback – joka ei sisälly tähän päättelysykliin.

Salesforce-kuviosovellus

Kuvaus

Asynkronisten toimintojen kutsujen järjestyskaavio

Tulokset

Agentti kutsuu downstream-operaatiota estämättä sen päättelysykliä lopputulokselle. Kierros päättyy vahvistuksella, että toiminto hyväksyttiin, eikä että se suoritettiin. Alempi järjestelmä ottaa suorituksen täyden omistajuuden. Lähetettyä operaatiota voidaan seurata sovellusalustan tapahtumien tilaajien, työn tunnusten tai ulkoisten jonojen hyväksymistunnusten kautta, jotka tallennetaan CRM:ään lähetyksen aikana. Jos myöhempi toiminto epäonnistuu, virhe havaitaan järjestelmän oman valvonnan kautta, eikä sen käynnistäneen agenttiistunnon kautta.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Kirjoita toimintojen kuvauksia tarkoihin perustuvalla kielellä. Esimerkiksi "Lähettää uusimisilmoituksen viestintäjonoon ja palauttaa lähetyksen viitetunnuksen" on agentille hyödyllisempi kuin "kutsuu ilmoituksen päätepistettä".
• Älä koskaan kuvaile lähetystoimintoa "lähettää ja vahvistaa toimituksen". Agentti voi vain vahvistaa hyväksynnän. Alempi toimitus ja käsittely eivät ole agentin käytettävissä.

Salesforcen toteutushuomautukset

• Palauta viitetunnus jokaisesta kutsutoiminnosta, esimerkiksi sovellusalustan tapahtuman ReplayId, jonossa olevan työn tunnus, Pub/Sub API PublishResult replayId tai ulkoinen hyväksymisvaltuus. Tallenna se CRM-tietueeseen kutsun aikana. Tämä on ainoa tarkastusketju, jonka agentti-istunto tuottaa.
• Kun käytät Pub/Sub API -rajapintaa, agentti kutsuu Apex, joka tekee gRPC-kutsun Pub/Sub API:n ‘/Publish’ -päätepisteeseen. Toiminnon täytyy käsitellä skeeman rekisteröintivaihe - tapahtumat täytyy sarjoittaa Avro-muodossa rekisteröityyn skeemaan nähden. Palauta PublishResult ‘replayId’ agentille lähetyksen viitteenä.
• Jos käytät sovellusalustan tapahtumia, kutsu EventBus.publish() Apex-toiminnon sisällä ja tarkasta SaveResult-arvo virheiden varalta ennen kuin palautat agentille onnistumisen osoittimen. Älä oleta, että julkaisu onnistui. Vahvista se.
• Jos kyseessä on Queueable-töitä, toteuta Queueable-käyttöliittymä ja kutsu System.enqueueJob()-funktiota toiminnosta. Palauta agentille luotu AsyncApexJob-tunnus.
• Jos käytät ulkoisia asynkronoituja päätepisteitä, kohdepäätepisteen täytyy palauttaa välittömästi hyväksyntä (HTTP 202 Accepted) viitetunnuksella. Jos päätepiste estää käsittelyn loppuun asti, se on synkronoitu eikä tätä kuviota käytetä.

Virheiden käsittely ja palautus

• Kutsutoiminnon täytyy erottaa lähetysvirhe (viestiä ei hyväksytty) ja käsittelyvirhe (viesti hyväksyttiin, mutta myöhemmin alempi toiminto epäonnistui). Agentti voi käsitellä vain edellisen.
• Jos kutsu epäonnistuu, toiminnon täytyy palauttaa rakenteellinen virhe selkeällä syyllä. Agentti voi yrittää lähetystä uudelleen, eskaloida sen ihmiselle tai kirjata epäonnistuneen lähetystietueen lokiin, mutta hän ei voi palauttaa myöhäistä käsittelyvirhettä samassa istunnossa.
• Suunnittele toisiinsa erillinen palautteen silmukka, kuten alempaan prosessiin julkaistu sovellusalustan tapahtuma, ajoitettu kulku, joka tarkastaa työn tilan, tai agentti-istunnon ulkopuolella oleva seurantatapaus operaatioille, joiden täytyy lopulta paljastaa alempi virhe.

Turvallisuudessa huomioitavia asioita

• Käännä kaikki ulkoiset asynkronoidut callout-kutsut nimettyihin tunnuksiin. Kutsu-toiminto ei upota päätepisteiden URL-osoitteita tai tunnuksia koodiin.
• Vahvista ja purkaa kaikki kutsutoimintoon välitetyt parametrit ennen kuin ne upotetaan tapahtuman tietosisältöön tai viestin tekstiosaan. Käyttäjän antama teksti, joka välitetään asynkronointiviestiin, on potentiaalinen injektiovektori alemmassa kuluttajassa.
• Kirjaa jokainen lähetys lokiin istuntotunnuksella, viitetunnuksella ja sanitoidulla tietosisällöllä lähetyksen aikana. Koska agentille ei palauteta vastausta, tämä loki on ensisijainen mekanismi, jolla agentin käynnistämät toimet rakennetaan uudelleen.
• Käytä integrointikäyttäjälle tai yhdistetylle sovellukselle vähiten käyttöoikeuksia. Ilmoitusjonoon julkaistu lähetystoiminto ei saa sisältää tunnuksia, jotka sallivat ei-liittyvän järjestelmän lukemisen tai kirjoittamisen.

Esimerkki

Uusiutumispäällikkö, joka käsittelee lähestyvän sopimuksen, määrittää, että asiakas on oikeutettu automaattisen uusimisen ilmoitukseen. Agentti ei tarvitse vahvistaa, että sähköposti toimitettiin ennen vuoron suorittamista.

1. CheckRenewalEligibility (Automaattisesti käynnistyvä kulku) arvioi sopimusehdot, asiakastason ja tilauksen tilauksen. Palauttaa ”hyväksyttävän” totuusarvon ja toivotun ilmoituskanavan.
2. DispatchRenewalNotification(Apex-toiminto) julkaisee sovellusalustan tapahtuman, RenewalNotification\_\_e joka sisältää sopimuksen tunnuksen, asiakastunnuksen, ilmoituskanavan ja luodun idempotency-avaimen. Palauttaa ReplayId-arvon, joka vahvistaa, että sovellusalusta hyväksyi tapahtuman.
3. UpdateContractRecord (Automaattisesti käynnistyvä kulku) kirjoittaa sopimustietueeseen ReplayId- ja dispatch-aikaleiman ja määrittää tilan merkinnän "Ilmoitus lähetetty".

Konteksti

Ulkoisten sovellusten, kuten asiakasportaalien, mobiilisovellusten, kolmannen osapuolen SaaS-alustojen ja kumppanijärjestelmien, täytyy kutsua agentteja ohjelmallisesti käsitelläkseen palvelupyyntöjä, käynnistääkseen työnkulkuja tai esittääkseen tekoälyyn perustuvia vastauksia omissa käyttöliittymissään. Agentti toimii älykkään taustapalvelunä. Ulkoinen järjestelmä tarjoaa asiayhteyden, agentin syyt ja toiminnot ja soittaja kuluttaa vastauksen.

Soittaja on yhä useammin itse tekoälyagentti tai orkestroija, eikä ihmiselle tarkoitettu sovellus. Näissä tekoälyä tekoälyä käyttävissä kuvioissa orkestroiva agentti delegoi Agentforcelle perusteluvaiheen, CRM-haun tai toiminnon erillisenä työkalukutsuna. Meidän täytyy paljastaa mallin kontekstiprotokollan (MCP) palvelin tukeaksemme tätä kuviota.

Ongelma

Kun ulkoisen järjestelmän tai tekoälyn agentin täytyy hyödyntää Agentforce kykyjä tarvittaessa, miten se todentaa, luo agentti-istunnon, välittää tarvittavat selkokieliset ja asiayhteydestä riittävät tiedot ja vastaanottaa luotettavasti agentin rakenteellisen vastauksen edistääkseen omaa downstream-logiikkaaan?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Odottaako ulkoinen soittaja synkronoitua, vähäisen viiveen vastausta vai onko ei-synkronoitu callback hyväksyttävä?
• Miten soittajan henkilöllisyys määritetään ja levitetään agentin suorituksen asiayhteyteen tietojen käyttämistä ja personalisointia varten?
• Mikä on samanaikaisten API-käynnistettyjen istuntojen odotettu määrä ja miten se vuorovaikuttaa Salesforcen API-suhteen ja samanaikaisten istuntojen rajoitusten kanssa?
• Täytyykö ulkoisen järjestelmän ylläpitää istunnon jatkuvuutta useissa vaiheissa (monivaiheinen keskustelu) vai onko jokainen pyyntö tilaton?
• Miten agentin vastaus tulisi rakentaa siten, että soitusjärjestelmä voi jäsentää sitä ja työstää sitä ohjelmallisesti?
• Onko soittaja henkilökohtainen sovellus, joka vaatii suoran REST-integraation, vai tekoälyagentti tai orkestroija, joka voi kutsua Agentforcea työkaluna vakioprotokollan kautta, kuten MCP?

Salesforce-kuviosovellus

Kuvaus

Agentin kutsujen järjestyskaavio tarvittaessa

Tulokset

Tämä kuvio paljastaa Agentforcen kutsuttavana tekoälypalveluna. Ulkoiset järjestelmät saavat pääsyn agentin päättelytapaan, työkaluihin ja CRM-kontekstiin replikoimatta kyseistä logiikkaa. Soittaja on edelleen vastuussa istunnon elinkaaren hallinnasta ja vastauksen renderöinnistä. Agentti on edelleen vastuussa kaikista syistä, työkalujen valinnasta ja vastausten synteesistä.

Kun soittaja on tekoälyagentti tai orkestroija, Agentforce MCP -mekanismin kautta (saatavilla käyttövalmiina Salesforce Headless 360:n kautta) ei tarvitse käyttää mukautettua REST-integraatiota. MCP-palvelin käsittelee istunnon elinkaaren soittavan agentin puolesta, jolloin Agentforce voi osallistua ensiluokkaisena työkaluna usean agentin työnkuluihin ilman ylimääräistä myyntiputkea.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Vältä tekemästä ulkoisesta API-kutsusta synkronoitavaa ja estämästä sitä ajasta riippuvaisissa käyttöliittymän kuluissa. Ota käyttöön kysely- tai webhook-callback-kuvio, jossa agenttien vastausaikoja ei ole tarpeeksi, irrottaaksesi käyttäjäkokemuksen agentin käsittelyaikasta.
• Valitse soitusmekanismi soittajan luonteen perusteella, älä saatavuuden perusteella. Henkilökohtaisten sovellusten ja järjestelmäintegraatioiden tulisi käyttää Agent API -rajapintaa suoraan. MCP:tä tukevien työkalujen tulisi käyttää Agentforce MCP -palvelinta. Saman soittajatyypin mekanismien sekoittaminen lisää tarpeetonta monimutkaisuutta ilman arkkitehtuurisia etuja.

Salesforcen toteutushuomautukset

• Syötä istunnon konteksti istunnon luontipyyntöön POST, älä ensimmäisessä käyttäjäviestissä. Kun ulkoinen järjestelmä luo istunnon, sillä on mahdollisuus välittää rakenteellisia kontekstimuuttujia (tilin tunnus, oikeutustiedot, aiemman vuorovaikutuksen yhteenveto) suoraan nimetyinä istuntoparametreinä. Nämä muuttujat ovat agentin käytettävissä ennen kuin se käsittelee yhden käännöksen, joten se aloittaa perustelun perustellusta tilasta lähettämättä hakukutsuja määrittääkseen, kuka asiakas on tai mihin hänellä on oikeus. Saman datan välittäminen viestin tekstiosaan pakottaa agentin jäsentämään jäsentämätöntä tekstiä noutaakseen faktoja, joita hän olisi voinut saada kirjoitetuina muuttujina - mikä kasvattaa viiveitä, tuo esiin noutovirheitä ja kuluttaa päättelyvaiheita, jotka eivät lisää liiketoiminta-arvoa.
• Suunnittele agenttien vastaukset rakenteellisiksi ja koneellisesti jäsennettäviksi. Käytä output-muuttujien käytäntöjä ja kehotteiden ohjeita, jotka opastavat agenttia palauttamaan JSON-yhteensopivia tai selkeästi erotettuja vastauksia, kun soittaja on järjestelmä eikä ihminen.
• Hallitse istunnon elinkaarta erikseen. Lopeta istunnot välittömästi, kun olet käyttänyt vapaiden samanaikaisten aikojen DELETE /einstein/ai-agent/v1/sessions/{sessionId}-vaihtoehtoja, ja vältä vanhentuneen asiayhteyden säilymistä asiaan liittymättömissä vuorovaikutuksissa.
• Salesforcen samanaikaisten istuntojen tilien rajoitukset. Jos käytät tehokäyttöisiä skenaarioita, käytä puhelujärjestelmässä istuntoa tai jonokerrosta estääksesi pyyntöjen hylkäämisen ruuhka-aikojen aikana.
• Kun kutsut Agentforcea MCP:n kautta, välitä asiayhteys työkalujen input-parametreinä istuntojen muuttujien sijaan. MCP-palvelin hallitsee istunnon elinkaarta läpinäkyvästi, joten soittava agentti ei voi määrittää nimettyjä istuntoparametrejä suoraan sen luonnin aikana. Varmista, että kaikki tarvittavat asiayhteydet (tietueiden tunnukset, käyttäjän henkilöllisyystiedot, oikeutustiedot) sisältyvät työkalun puhelun tietosisältöön, jotta agentti voi aloittaa päättelyn perustellusta tilasta.
• Käsittele MCP-palvelimen läpinäkyvää istuntojen hallintaa mukavuutena, äläkä samanaikaisena ohituksena. Jokainen työkalun kutsu kuluttaa edelleen Salesforce-agenttien istunnon ajan. Suuren taajuuden orkestroijien, jotka kutsuvat Agentforcea MCP:n kautta skaalassa, täytyy huomioida samat samanaikaiset istuntojen rajoitukset kuin suorat Agent API -kutsut.

Virheiden käsittely ja palautus

• Agent API palauttaa HTTP-vakiovirhekoodit. Puheluiden järjestelmän täytyy käsitellä ”429 Liian monta pyyntöä” (suhderajoitus) ja ”503 Palvelu ei käytettävissä” uudelleenyrityslogiikalla.
• Kun agentti itse kohtaa ratkaisemattoman työkaluvirheen, hän palauttaa lahjakkaan luonnollisen kielen virheen vastauksen tekstiosassa. Puhelujärjestelmä havaitsee nämä varoitusvastaukset (esimerkiksi tarkastaa vastauksen ”virhe”-tilan kentän) ja reitittää ne vastaavasti joko yrittämällä uudelleen käyttämällä lisäkontekstia, esittämällä varakokemuksen tai eskaloimalla ne ihmiselle.
• Kun kutsut MCP:n kautta, virheet näytetään kahdessa erillisessä kerroksessa: MCP-kuljetusvirheet (virheelliset työkalukutsut, palvelimen käytöstä poistaminen) ja Agentforcen perusteluiden virheet (työkalujen suoritusvirheet, ratkaisemattomat toiminnot). Orkestroivan agentin täytyy käsitellä molemmat kerrokset erillään. MCP-kuljetusvirheiden tulisi käynnistää uudelleenkäynnit protokollatasolla. Agentforcen argumenttien virheet, jotka palautetaan työkaluvastauksessa, tulisi käsitellä orkestroijan omalla varalokilla tai eskalointilogiikalla.

Turvallisuudessa huomioitavia asioita

• Käytä ulkoisen asiakassovelluksen mahdollisimman kapeita OAuth-vaikutusalueita. Integraation, jonka täytyy kutsua vain agenttia, ei tulisi sisältää datan käyttöoikeuksia, jotka ylittävät agentin itsensä vaatimat vaikutusalueet.
• Vahvista ja sanitoi kaikki ulkoisesta järjestelmästä syötetyt tiedot ennen kuin syötät ne istuntomuuttujina. Ulkoiset syötteet ovat kehotteen injektion hyökkäyspinta-ala. Esimerkiksi pahantahtoinen soittaja voi luoda ”customerQuery”-kentän, joka on suunniteltu korvaamaan agentin ohjeet.
• Käytä IP-luettelointia ulkoiselle asiakassovellukselle rajoittaaksesi, mitkä ulkoiset järjestelmät voivat todentaa ja kutsua Agent API -rajapintaa.
• Kirjaa kaikki API:n käynnistämät saapuvat istunnot lokiin kutsun henkilöllisyydellä, istunnon tunnuksella ja pyyntöjen/vastausten metadatalla tarkastusta ja tietoturvaa varten.
• Kun Agentforce kutsutaan MCP:n kautta, MCP-palvelin todentaa itsensä Salesforceen soittavan käyttäjän puolesta. Varmista, että yhdistetyn MCP-palvelimen sovelluksen tunnukset on rajoitettu vaadittuihin käyttöoikeuksiin ja että loppukäyttäjän identiteetti (käyttämällä MCP-työkaluja, kuten Claude) -identiteetti levitetään istunnon asiayhteyteen erikseen työkalujen syöttöparametrien kautta.

Esimerkki

Finanssipalveluiden portaali käynnistää Agentforce käsittelemään asuntolainan kyselyn.

1. Portaali todentaa itsensä käyttämällä Client Credentials OAuth -kulkua ja saa haltijatunnuksen.
2. Se kutsuu ”POST / Einstein/ai-agent/v1/sessions” ja istuntojen muuttujat: ”{ "accountId": "001xx...", "productType": "mortgage", "loanAmount": 450000 }”.
3. Käyttäjä lähettää kysymyksensä: "Mitä asiakirjoja tarvitsen hakemukseni suorittamiseen?"
4. Portaali kutsuu käyttäjän tekstiä ”POST / Einstein/ai-agent/v1/sessions/{sessionId}/messages”.
5. Agentforce kutsuu kulun ”GetDocumentChecklist”-toimintoa, noutaa laintatyyppikohtaiset vaatimukset ja palauttaa rakenteellisen luettelon.
6. Portaali renderöi agentin vastauksen suoraan ja sulkee istunnon, kun käyttäjä poistuu.

Konteksti

Kaikki agenttityönkulut eivät periydy ihmispyynnöstä. Liiketoimintaan kriittisiä signaaleja, kuten tuotekäytön tilastojen äkillinen lasku, arvokkaan ostoskorin hylkääminen tai riskin kynnysarvon ylittäminen maksun epäonnistumisesta, esiintyy usein toiminta-datassa. Kun nämä signaalit vaativat älykkäitä, monivaiheisia vastauksia, ihmisen huomaamisen ja toiminnan odottaminen lisää viiveen, joka yhdistetään todellisiin liiketoimintakustannuksiin.

Tämä kuvio kuvaa, miten reaaliaikaiset tapahtumat toimivat agenteille itsenäisinä sisäänkirjautumispisteinä. Agentti kutsutaan datayhteydestä käyttäjän sijaan, syistä tapahtuman asiayhteyteen ja suorittaa vastauksen työnkulun ilman ihmisen aloitusta.

Ongelma

Kun reaaliaikainen liiketoimintatapahtuma tapahtuu Data 360:ssa tai Salesforce-alustassa, miten se voi itsenäisesti luoda agentti-istunnon, toimittaa tapahtuman hyötykuorman perustana olevana asiayhteydenä ja edistää ei-keskustelutoimintojen työnkulkua ilman, että ihminen käynnistäisi tai ohjasi vuorovaikutusta?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Vaaditaanko vastaus välittömästi tapahtuman käynnistymishetkellä vai hyväksytäänkö lähes reaaliaikainen käsittely (sekunteista minuutteihin)?
• Sisältääkö tapahtuman tietosisältö tarpeeksi kontekstia agentin perustamiseksi tai täytyykö agentin suorittaa lisää hakuja ennen kuin hän voi päättää asiasta tehokkaasti?
• Mikä on tapahtumien odotettu määrä ja yleisyys? Suuren läpimenoasteen tapahtumaketjut vaativat tiedonsiirtojen hallintaa välttyäkseen agenttien samanaikaisten rajoitusten tyhjentämiseltä.
• Voiko sama tapahtuma käynnistyä useammin kuin kerran samalle liiketoimintayksikölle (vähintään kerran toimituksessa)? Jos näin on, toimintojen täytyy olla idempotent.
• Onko olemassa ihmisen eskalointipolku, jos agentti ei voi ratkaista tapahtumaa itsenäisesti?
• Miten epäonnistuneiden tapahtumien käsittelyä tulisi käsitellä? Jos sinulla on dead-letter-jono, hälytys tai tapausten luonti?

Salesforce-kuviosovellus

Kuvaus

Tapahtumiin perustuvan agentin suorituksen järjestyskaavio

Tulokset

Agentit ovat reagoivia osallistujia reaaliaikaisiin liiketoimintaoperaatioihin, eivät passiivisia vastaajia ihmisten pyyntöihin. Tapahtumien käynnistämät agentit voivat suorittaa palautus-, lajittelu- ja eskalointityönkulkuja datan nopeudella ihmisten huomiota nopeuttamatta.

Käynnistävä järjestelmä (Data 360 tai sovellusalustan tapahtumat) on edelleen vastuussa tapahtumien havaitsemisesta ja hyötykuormien muodostamisesta. Agentti on edelleen vastuussa hyötykuorman perustelemisesta ja oikean toimintoketjun valitsemisesta. Selkokielistä käännöstä ei tarvita. Tapahtuman tietosisältö on täydellinen input.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Suunnittele kaikki toiminnot muulle kuin selkokieliselle kutsulle. Käyttäjällä ei ole käänteitä. Agentin täytyy saavuttaa ratkaisu vain alkuperäisestä asiayhteydestä. Toimintojen tulisi palauttaa rakenteellisia, deterministisiä tuloksia, eikä kehottaa selkeyttämään niitä.
• Varmista, että tapahtuman hyötykuorma sisältää tarpeeksi asiayhteyttä ennen kuin agentti-istunto luodaan. Lihavoitu hyötykuorma, joka pakottaa agentin soittamaan useita hakupuheluita ennen kuin se voi päättää, kasvattaa viive- ja samanaikaista kulutusta.
• Tee kaikista tapahtumiin perustuvien agenttien käynnistämistä kirjoitustoiminnoista idempotentteja. Tapahtumien toimitusjärjestelmät tarjoavat tavallisesti vähintään kerran takuita. Identtisten tapahtumien käsittely ei voi aiheuttaa identtisiä sivuvaikutuksia.

Salesforcen toteutushuomautukset

• Kartoita tapahtumien tietosisällön attribuutit (esimerkiksi ”accountId”, ”eventType”, ”metricValue”, ”productIds”) suoraan nimetyn istunnon muuttujiin istunnon luonnin aikana Data 360:n käynnistämissä kuluissa. Tämä perustelee agentin ensimmäisestä perusteluvaiheesta ilman, että hänen täytyisi suorittaa palautustoimintoa.
• Käytä sovellusalustan tapahtumien käynnistimissä automaattisesti käynnistyvää kulkua ruutukulun sijaan. Ruutukulkuja ei tueta itsenäisissä, ei-keskusteluissa olevissa konteksteissa.
• Määritä tapahtumien käynnistämille istunnoille erillinen istunnon aikakatkaisu. Toisin kuin selkokieliset istunnot, käyttäjä ei voi laajentaa vuorovaikutusta. Istunnon, joka lykkää epäonnistuneen toiminnon, ei tulisi sisältää samanaikaista aikaa määrittämättömästi.
• Käytä kulkujen vikapolkuja käsitelläksesi agenttien istuntojen luonnin virheitä. Jos istuntoa ei voi luoda, vikapolun tulisi julkaista korvaava tapahtuma tai luoda tapaus ihmisten jatkotoimille sen sijaan, että tapahtuma jätettäisiin tyhjäksi.

Virheiden käsittely ja palautus

• Tapahtumat, jotka eivät onnistu käynnistämään agentti-istuntoa onnistuneesti samanaikaisten rajoitusten, istunnon luontivirheiden tai tietosisällön vahvistusvirheiden vuoksi, tulisi reitittää vikapolkuun, joka luo tapauksen, käynnistää hälytyksen tai julkaisee tapahtuman dead-letter-jonoon uudelleenkäsittelyä varten.
• Agenttien suoritusvirheet suorituksen aikana (esimerkiksi vaaditun toiminnon aikakatkaisu) tulisi kirjata alkuperäisen tapahtuman tunnuksella. Koska käynnistys on asynkroninen eikä puhelua odoteta, virhepinta perustuu kokonaan havaittavuuteen: lokit, mittaristot ja hälytyksen kynnysarvot.
• Toteuta uudelleenyritysrajoitus. Jos tapahtuma aiheuttaa agentin epäonnistumisen luotettavasti, rajoittamattomat uudelleenyritykset tyhjentävät samanaikaisten töiden rajoitukset. Kun yritysten enimmäismäärä on määritettävissä, reititä tapahtuma ihmisen tarkastusjonoon, johon on liitetty koko konteksti.
• Seuraa tapahtuman tunnusta agentin istunnon koko elinkaaren kautta. Tämä seuranta mahdollistaa alkuperäisen datan signaalin ja kaikkien alempien toimintojen välisen korrelaation tarkastusta ja virheenkorjausta varten.

Turvallisuudessa huomioitavia asioita

• Vahvista ja sanaloi kaikki tapahtumien tietosisältöattribuutit ennen kuin syötät ne agenttien istuntojen muuttujina. Data 360:sta tai ulkoisista julkaisijoista saatujen tapahtumien hyötykuormat ovat kehote-injektion hyökkäysalue. Esimerkiksi luotu hyötykuormakenttä voidaan suunnitella korvaamaan agenttien ohjeet.
• Suorita tapahtumien käynnistämiä agentti-istuntoja erillisen, vähiten käyttöoikeuksia käyttävän integraatiokäyttäjän perusteella korkean käyttöoikeuden omistavan pääkäyttäjän identiteetin sijaan. Agentilla on vain määritettyjen toimintojoukkojen suorittamiseen tarvittavat käyttöoikeudet.
• Kirjaa kaikki tapahtumien käynnistämät istunnot lokiin alkuperäisellä tapahtuman tunnuksella, tapahtumatyypillä ja luotaessa syötetyillä istunnon muuttujilla. Tämä kirjausketju vaaditaan, jotta agentti pystyy selvittämään, miksi hän suoritti tietyn toiminnon, jos lopputulos on kiistanalainen.

Esimerkki

Vähittäismyyntiyritys käyttää Data 360:a seuratakseen ostoskorin toimintatapaa reaaliajassa. Kun ostoskori, jonka arvo ylittää määritetyn kynnysarvon, hylätään:

1. Data 360 havaitsee hylkäämisen signaalin ja käynnistää kulun, jonka tietosisältö on tapahtuma: ”customerId”, ”cartValue”, ”productIds” ja ”abandonmentTimestamp”.
2. Kulku kartoittaa nämä attribuutit Agentforce muuttujiin ja luo uuden agentti-istunnon. Käyttäjän ei tarvitse tehdä mitään.
3. Agentti arvioi asiakkaan ostohistorian, tämänhetkiset oikeutukset ja ostoskorin koostumuksen käyttämällä sen käytettävissä olevia noutotoimintoja.
4. Agentti kutsuu SelectRecoveryOffer-toimintoa, joka käyttää asianmukaista alennustason asiakassegmentin perusteella, ja SendProactiveNotification-toimintoa tarjotakseen tarjouksen asiakkaan haluaman kanavan kautta.
5. Agentti kutsuu CreateFollowUpTask kirjatakseen vuorovaikutuksen CRM:ään tilin omistajan näkyvyyden varmistamiseksi.
6. Istunto sulkeutuu automaattisesti, kun toimintoketju on suoritettu. Alkuperäisen tapahtuman tunnus säilytetään istuntolokissa seurattavaksi.

Konteksti

LLM:t koulutetaan julkiseen dataan. Heillä ei ole Knowledgea organisaatiosi tuotteista, käytännöistä, tapaushistoriasta tai sopimuksista, ellei näitä tietoja ole annettu erikseen perustelun yhteydessä. Ilman perustetta, agentti kysyy asiakkaan palveluoikeutuksesta tai tietyn sopimuksen ehdoista joko hallitsee vastausta tai myöntää, ettei tiedä. Kumpaakaan lopputulosta ei voi hyväksyä yrityksen asiayhteydessä.

Retrieval-Aggmented Generation (RAG) ratkaisee tämän noutamalla asiaankuuluvia asiakirjoja Enterprise Knowledge -säiliöstä ja syöttämällä ne agentin kontekstiikkunaan ennen kuin se luo vastauksen. Agentti pohtii haettua sisältöä, kuten Knowledge, menneitä tapausten ratkaisuja ja tuotemäärityksiä, ikään kuin hänelle olisi annettu kyseiset tiedot suoraan. LLM tarjoaa perustelun; nouto-kerros tarjoaa faktat.

Esimerkiksi monimutkaisen takuuvaatimuksen käsittelevän palveluagentin ei tarvitse upottaa takuuehdot ohjeisiinsa. Sen sijaan, kun asiakas kuvaa ongelmansa, agentti suorittaa semanttisen haun tai yhdistetyn haun (avainsanahaku + semanttinen haku) takuuasiakirjojen vektori-indeksille, noutaa asiaankuuluvat termit ja käyttää niitä määrittääkseen oikeutuksen ja seuraavat vaiheet. Vastaus perustuu tämänhetkiseen, valtuutettuun käytännön asiakirjaan, ei mallin koulutusdataan.

Ongelma

Agentin täytyy vastata kysymykseen tai tehdä päätös, joka riippuu organisaation omistamasta Knowledgesta, kuten käytännöistä, sopimuksista, tuotedokumentaatiosta tai tapausten historiallisista tiedoista, jotka eivät kuuluneet LLM:n koulutusdataan. Miten agentti noutaa asianmukaisimman sisällön päättelyn aikana, varmistaa, että haettu sisältö on ajankohtaista ja luotettavaa, ja syöttää sen asiayhteyteen riittävän tarkasti melun välttämiseksi?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin

• Onko Knowledge staattinen ja päivitetty harvoin (esimerkiksi tuoteoppaassa) vai muuttuuko se jatkuvasti (esimerkiksi tapausten ratkaisuissa, inventaarion kuvauksissa)? Päivitysten yleisyys määrittää syötteen myyntiputken rakenteen.
• Kuinka suuri sisältö on? Pieni Knowledge voidaan hakea kattavasti. Suuri tietämyskanta vaatii pilkkomisen, upottamisen ja semanttisen indeksoinnin palauttaakseen vain tärkeimmät välilehdet.
• Hyödyttääkö kysely yhtä tarkennettua hakua vai tuottaisiko useiden Knowledge tulosten (esimerkiksi dokumentaation ja menneiden tapausten) yhdistäminen paremmin perustellun vastauksen? Jälkimmäinen vaatii yhdistelmän noutamisen.
• Tarvitseeko haettua sisältöä suodattaa metadatan perusteella ennen semanttista järjestystä, esimerkiksi rajoittaaksesi tulokset asiakirjoihin, jotka liittyvät asiakkaan tuotetasoon tai maantieteeseen?
• Kuinka luottamuksellinen Knowledge on? Noudettu sisältö syötetään LLM-kontekstiikkunaan ja vaikuttaa agentin vastaukseen. Sisältöä, jota ei tulisi näyttää tietyille käyttäjille, täytyy hallita noutokerroksessa, eikä olettaa, että LLM suodattaa sitä.

Salesforce-kuviosovellus

Kuvaus

Enterprise Contentin Knowledge-perustamisen järjestyskaavio

järjestyskaavio

Tulokset

Agentin vastaukset perustuvat organisaation tämänhetkiseen ja arvokkaaseen Knowledgeen, eivätkä LLM:n koulutusdataan. Todellisten kysymysten, kuten käytäntöjen ehtojen, tuotteiden määritysten ja oikeutusten lisätietojen, hallusinaatioiden riski vähenee, koska malli pohtii kerättyjä todisteita eikä luo niitä muistista.

Knowledge voidaan ylläpitää itsenäisesti. Käytäntöasiakirjan päivittäminen tai uuden tapauksen ratkaisun lisääminen indeksiin astuu voimaan välittömästi kaikille myöhemmille agenttien vuorovaikutuksille ilman mallin uudelleenkoulutusta tai käyttöönottoa.

Nouto tarjoaa myös epäsuoran kirjausketjun. Koska agentin vastaus saadaan tietyistä noudetuista asiakirjoista, lähdesisältö voidaan kirjata vastauksen viereen, jolloin voidaan seurata, miksi agentti antoi tietyn vastauksen.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Pura ja upota Knowledge oikealla tarkkuudella. Liian suuret lohkot laimentavat relevanttiuden. Liian pienet lohkot menettävät ympäröivän asiayhteyden, jonka LLM tarvitsee perustellakseen oikein. Useimmille yritysasiakirjatyypeille kappaletason pilkkominen päällekkäisillä konteksti-ikkunoilla tuottaa parhaan palautustason.
• Käsittele noutamisen tarkkuutta ensiluokkaisena suunnittelun huolenaiheena. Alhaisen relevanttiuden sisällön lisääminen agentin kontekstiikkunaan ei ole neutraalia. Se aiheuttaa melua, joka heikentää vastauksen laatua. Säädä palautuksen kynnysarvoja ja top-k-rajoituksia tasapainottaaksesi palautuksen ja tarkkuuden kullekin Knowledge.
• Syötön viive on toiminnallinen palvelutasosopimus. Jos käytäntöasiakirja päivitetään, mutta vektori-indeksiä ei ole päivitetty, agentti noutaa ja toimii vanhentuneiden tietojen perusteella. Määritä hyväksyttävä vanhentumisen toleranssi kullekin sisältötyypille ja suunnittele syöttöputket sen mukaisesti.

Salesforcen toteutushuomautukset

• Täytä Data 360 -vektori-indeksit asiaankuuluvan syöttöputken kautta sisällön päivitystiheydelle. Käytä staattisille asiakirjoille erien tuontia ja jatkuvasti muuttuville tietueille streaming- tai Change Datan taltiointia (CDC).
• Määritä Ensemble Retrievers -kenttään relevanttiusjärjestyksen painot per lähde. Ratkaistujen tapausten indeksi saattaa vaatia viimeaikaista vinoumaa, mutta käytäntöjen dokumentaatioindeksi ei välttämättä. Säädä painotuksia niiden kyselytyyppien perusteella, joita agentin odotetaan käsittelevän.
• Käytä metadata-suodattimia mukautetuissa Apex- tai kulkujen noutokäynnistimissä suorittaaksesi scope-haun ennen semanttisen haun suorittamista. Suodattaminen tuoterivin, alueen tai asiakirjatyypin perusteella ennen lajittelua vähentää melua ja parantaa asiayhteyteen syötettyjen tietojen tarkkuutta.
• Älä syötä noudettua koko asiakirjaa LLM-kontekstiin. Välitä vain asiaankuuluvat lohkot tai koodikatkelmat. Suuret konteksti-injektiot kuluttavat valtuusbudjettia, kasvattavat viiveitä ja vähentävät agentin päättelyyn käytettävissä olevaa konteksti-ikkunan osuutta.

Virheiden käsittely ja palautus

• Jos nouto ei palauta tuloksia, palauta selkeä "ei tuloksia löytynyt" -tila sen sijaan, että jatkaisit perittämättä. Sitten agentti voi laajentaa kyselyä, pyytää käyttäjältä selvitystä tai eskaloida sen ihmiselle.
• Jokainen noudottajien palauttama osio sisältää relevanttiuspisteet. Riippuen käyttötarkoituksesta, sinun tulisi määrittää tietty kynnysarvon luottamustaso/relevanttiarvo, jonka yläpuolella agentin tulisi käsitellä noutoa luottavaisena. Muussa tapauksessa sen tulisi jäädä takaisin selvittämiseen tai eskalointiin.
• Jos vektorin indeksi tai noutopalvelu ei ole väliaikaisesti käytettävissä, noutotoiminnon tai Apex tulisi palauttaa rakenteellinen virhe ja kuvaava syy. Kirjaa virhe istunnon tunnuksella ja kyselyllä, jotta haun aukot voidaan tunnistaa ja indeksiä tai palvelua voidaan valvoa saatavuuden varmistamiseksi.
• Jos Knowledge on ajasta riippuvainen, suorita tuoreustarkistus osana palautuksen vastausta. Jos vastaava asiakirja päivitettiin viimeksi määritetyn vanhentumisen kynnysarvon ylittyneenä, merkitse se agentille, jotta hän voi hyväksyä vastauksensa tai kehotteensa vahvistettavaksi.

Turvallisuudessa huomioitavia asioita

• Noutuksen täytyy noudattaa sen käyttäjän tietojen käyttöoikeuksia, jonka puolesta agentti toimii. Asiakkaille suoritettavan vuorovaikutuksen kontekstissa suoritettava agentti-istunto ei saa noutaa sisäisiä toiminta-asiakirjoja, hinnoittelustrategian huomautuksia tai tietueita, joiden käyttöoikeutta loppukäyttäjällä ei muutoin olisi. Käytä kenttätason ja tietuetason suojausta noutokerrokselle. Älä luota LLM-ohjelmaan säilyttääksesi luottamuksellista haettua sisältöä.
• Noudettu sisältö syötetään LLM-kontekstiikkunaan, ja se voi vaikuttaa tai näkyä agentin vastauksessa. Käsittele hakusisällössä olevia asiakirjoja mahdollisesti näkyvinä loppukäyttäjille ja hallitse sisällön jäsenyyttä sen mukaisesti.
• Kirjaa kaikki noutokyselyt ja noudettujen osien asiakirjatunnukset istunnon tunnuksen kanssa lokiin. Tämä kirjausketju mahdollistaa todisteiden rakentamisen uudelleen, joita agentti käyttää vastatessaan, mikä saattaa olla tarpeen vaatimustenmukaisuuden, riitojen ratkaisemisen tai selkeytettävyyden vaatimusten täyttämiseksi.

Esimerkki

Finanssipalveluagentti käsittelee asiakaskyselyn, joka koskee määräaikaisen säästämistuotteen aikaisempia lunastuksia:

1. Asiakas kysyy: "Mitä seuraamuksia minulla olisi, jos vetäisin rahojani kuusi kuukautta etukäteen?"
2. Agentti kutsuu yksityishenkilön hakutoimintoa, joka on määritetty tuoteehtojen ja -ehtojen asiakirjojen vektori-indeksille.
3. Noudaja suorittaa semanttisen haun käyttämällä kyselyn asiayhteyttä, kuten tuotetyyppiä ja asiakastiliä, sekä tiettyä kysymystä, ja palauttaa kolme tärkeintä asiakirjamerkkiä - aikaisen lunastuksen lauseke, sakkojen laskentataulukko ja vaikeuksiin liittyvät poikkeukset.
4. Noudetut lohkot syötetään agentin kontekstiikkunaan asiakkaan kysymyksen vieressä.
5. Agentti perustelee noudetut ehdot, tunnistaa asiakkaan tuotetasolle ja lunastuksen aikajanalle sovellettavan sakkoasteen ja palauttaa tarkan ja käytäntöön perustuvan vastauksen, jossa mainitaan käyttämiensä ehtojen voimaanastumispäivä.
6. Noudettujen osioiden asiakirjatunnukset kirjataan istuntotietueeseen tarkastusta varten.

Konteksti

LLM:t ovat todennäköisyyksiin perustuvia. Kun heitä pyydetään syöttämään syy tiettyyn asiakkaaseen, he päättelevät, arvioivat tai hallusinoivat faktoja, joita heille ei annettu erikseen. Agentti, joka kutsuu hinnoittelutoimintoa tietämättä, että asiakas on arvokas yritystili preferoidussa tasossa, voi käyttää väärää alennuslogiikkaa. Agentti, joka eskaloi tukitapauksen tietämättä asiakkaan häiriöriskin pistemäärää, saattaa poistaa prioriteetin tilistä, joka on päivien päässä häiriöstä.

Vahvistetun asiakkaan asiayhteyden syöttö korjaa tämän täyttämällä toiminnon input-parametrit valmiiksi yhtenäistetystä profiilista saaduilla vahvistetuilla, rakenteellisilla attribuuteilla ennen kuin agentti kutsuu toimintoa. Agentti ei laske asiakkaan segmenttiä, elinkaaren arvoa tai asiakastyytyväisyystrendiä (CSAT). Se vastaanottaa nämä faktat syöttäjinä ja niihin liittyvät syyt. Tämä kuvio vähentää hallusinaatioiden riskiä asiakaskohtaisten päätösten yhteydessä ja välttää tarpeettomat lookup-puhelut harkinnan aikana.

Esimerkiksi ennen kuin hinnoitteluagentti kutsuu ”GenerateQuote”-toimintoa, alitason agenttikokoonpano syöttää asiakkaan segmentin, tason ja elinkaaren arvon automaattisesti yhtenäistetystä profiilistaan. Toiminto vastaanottaa vahvistettuja faktoja LLM:n tekemien arviointien sijaan, ja tarjous on ankkuroitu asiakkaan todelliseen kaupalliseen suhteeseen.

Tämä ei ole vaihtoehto ”Knowledge periytyy Enterprise Contentista” -kuviolle. Hyvin suunniteltu agentti voi käyttää molempia: ”Knowledge Grounding from Enterprise Content” tarjoaa asiakirjoihin perustuvaa Knowledgea, kun taas ”Verified Customer Context Injection” edustaa asiakkaan identiteettiä.

Ongelma

Miten voit varmistaa, että agentilla on paikkansapitäviä ja asiakaskohtaisia tietoja, kuten segmentti, taso, elinkaaren arvo, häiriöriski tai muut profiilien attribuutit ennen kuin hän suorittaa toimenpiteen, sen sijaan, että arvailisit niitä itse?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Mitkä toiminnon input-parametrit edustavat asiakaskohtaisia faktoja, jotka johtaisivat virheellisiin tai epäjohdonmukaisiin lopputuloksiin, jos ne johdettaisiin sen sijaan, että ne johdettaisiin lähteeseen?
• Ovatko vaaditut profiiliattribuutit käytettävissä Data 360 -vakiomuotoisina yhtenäistettyinä profiilikenttinä vai vaativatko ne laskettuja havaintoja, jotka on saatu raakadasta toimintatapaa ja transaktiotietoja?
• Kuinka usein profiilien asiaankuuluvat määritteet muuttuvat? Attribuutit, kuten vaiheittaisen riskin pisteytys tai asiakastyytyväisyyden trendi, vaativat tuoreuden takuun. Vanhentuneet profiilitiedot johtavat samoihin vääriin lopputuloksiin kuin hallusinoitu data.
• Pitäisikö profiiliattribuutit syöttää istunnon luonnin aikana (vakio istunnon kestolle) vai noutaa uudelleen toimintokutsun yhteydessä (jotta ne vastaisivat tilojen muutoksia istunnon aikana)?
• Täytyykö agentin perustella profiilien attribuutit suoraan, vai kulutetaanko ne vain toiminnolla ja ovatko ne läpinäkymättömiä agentin päättelysilmukan perusteella?

Salesforce-kuviosovellus

Kuvaus

Vahvistetun asiakkaan asiayhteyden syötteen järjestyskaavio

Tulokset

Toiminnot saavat vahvistettuja rakenteellisia asiakkaan faktoja LLM:n määrittämien arvioiden sijaan. Agentin perustelut perustuvat asiakkaan todelliseen profiiliin, mikä vähentää hallusinaatioiden riskiä päätöksissä, joissa tosiasiallinen tarkkuus määrittää lopputuloksen laadun, kuten hinnoittelun, oikeutusten tarkastukset, eskaloinnin reititys ja säilytystarjoukset.

Profiilien maadoitus vähentää myös päättelyiden viiveitä. Kun agentin ei tarvitse lähettää hakupuheluita asiakkaan asiayhteyden perustamiseksi, päättelysykli on lyhyempi ja samanaikaiset puhelut kulutetaan vähemmän kierroksia varten.

Yhtenäistetty Data 360 -profiili on edelleen asiakkaan faktan todellinen lähde. Alagentin kokoonpano tai yhdistetty kulku on integraation sauma. Agentti on vastuussa näiden faktan perustelemisesta ja toimintojen valitsemisesta, eikä itse faktan hakemisesta.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Tunnista kaikki syötetyt toiminnot, joilla on hallusinaatioiden riski — joissa LLM:n johtopäätös voi tuottaa väärän lopputuloksen vahvistetun arvon sijaan. Syötteet, joilla on hallusinaatioiden riski, ovat ehdokkaita profiilien maadoittamiseen. Kaikki syötetyt tiedot eivät vaadi maadoitusta. Profiilitietojen liiallisen syöttämisen aiheuttaa melua agentin kontekstiikkunaan.
• Käsittele profiilin tuoreutta suunnittelupäätöksenä, äläkä jälkisuunnitteluna. Määritä hyväksyttävä vanhentumisen toleranssi kullekin maadoitetulle attribuutille ja valitse injektiomekanismi sen mukaisesti: istuntotason kartoitus staattisille attribuuteille, kulkuun perustuva päivitys haihtuville attribuuteille.
• Laskettujen havaintojen tulisi koodata liiketoimintalogiikkaa, ei raakatilastoja. Agentti, joka päättelee ”churnRiskScore”-arvon ylittymisestä 0,87, on tehokkaampi kuin agentti, joka päättelee 14 raakoa toimintosignaalia. Laske tulkinta Data 360:ssa ja välitä tulokset agentille.

Salesforcen toteutushuomautukset

• Profiilien perustaminen on vain yhtä luotettavaa kuin sen perustana oleva yhtenäistäminen. Esimerkiksi yhtenäistetyn profiilin arvo riippuu kokonaan identiteettien ratkaisun laadusta virtavirralla. Jos asiakkaalla on hajanaisia identiteettejä lähdejärjestelmissä, joita ei ole yhtenäistetty, agentin vastaanottamat profiiliattribuutit eivät ole täydellisiä tai ne edustavat vain osittaista näkymää (esimerkiksi elinkaaren arvo lasketaan datalla yhdestä kanavasta, mutta ei toisesta).
• Jos käytät yhdistettyjä Data 360 -kulkuja, käytä Nouda tietueita -elementtiä, joka sisältää suodattimen tämänhetkisen istunnon "recordId"- tai "accountId"-arvolle noutaaksesi vain asiaankuuluvan profiilitietueen. Palauta vain downstream-toiminnon vaatimat attribuutit. Älä palauta täyttä profiiliobjektia.
• Lasketut havainnot täytyy pitää ajan tasalla Data 360 -syöttöputkien kautta. Määritä streaming- tai lähes reaaliaikainen päivitys havainnoille, joita käytetään ajasta riippuvaisissa päätöksissä (esimerkiksi säilytystyönkulun häiriöriski). Eräpäivitetyt havainnot hyväksytään hitaammin liikkuville attribuuteille (esimerkiksi sopimuksen vuosittainen arvotaso).
• Vahvista, että kartoitetut profiiliattribuutit eivät ole null-attribuutteja ennen toiminnon kutsua. Hinnoittelutoimintoon välitetty null-arvo ”customerTier” on yhtä haitallinen kuin hallusinoitu arvo. Käytä kulun päätöselementtejä tunnistaaksesi puuttuvat profiilitiedot ja reitittääksesi ne varastoon, joka noutaa oletusarvon tai pyytää selventämistä.
• Kartoita profiilien attribuutteja alitason agenttikokoonpanossa toimintojen input-parametreihin käyttämällä kuvaavia, semanttisesti selkeitä muuttujien nimiä (esimerkiksi ”customerTier”, ”lifetimeValueUSD”, ”churnRiskScore”). LLM lukee nämä nimet valitessaan ja kirjoittaessaan toimintoja. Epäselvät nimet heikentävät valintojen tarkkuutta.

Virheiden käsittely ja palautus

• Jos vaadittu profiiliattribuutti on null tai se ei ole käytettävissä toiminnon kutsun aikana, agentin ei tulisi jatkaa mahdollisesti virheellistä oletusasetusta. Toiminnon tulisi palauttaa puuttuvaa attribuuttia osoittava rakenteellinen virhe, ja agentin tulisi joko pyytää käyttäjää selventämään sitä tai eskaloida se ihmiselle, jos se toimii ei-keskustelulla.
• Jos yhdistetty Data 360 -kulku ei onnistu noutamaan profiilitietoja (esimerkiksi Data 360 -palvelun keskeytyksen vuoksi), kulun vikapolun tulisi palauttaa agentille rakenteellinen virhe ja virheen syy. Sitten agentti voi päättää, yrittääkö hän uudelleen, jatkaa heikentyneen käyttökokemuksen käyttämistä vai paljastaa käyttäjälle virheen.
• Kirjaa kaikki istunnon luonnin tai toiminnon kutsun yhteydessä syötetyt profiiliattribuuttien arvot istunnon tunnuksen viereen. Näin varmistetaan, että kaikki kiistanalaiset agentin päätökset voidaan rakentaa uudelleen asiakkaan antamilla tarkkoilla faktoilla.

Turvallisuudessa huomioitavia asioita

• Agenttien kontekstiin syötettyjä profiiliattribuutteja koskevat samat datan käyttöoikeusasetukset kuin mitä tahansa CRM-tietuetta. Varmista, että profiilattribuuttien ratkaisemiseen käytetyllä integraatiokäyttäjällä tai yhdistetyllä sovelluksella on vain näytettävien attribuuttien kenttätason käyttöoikeudet eikä laajempia profiilien lukuoikeuksia.
• Laskettuja havaintoja, jotka koodaavat luottamuksellisia johdettuja tilastoja (esimerkiksi ennustettuja terveyspisteitä, taloudellisen riskin tasoa), tulisi käsitellä luottamuksellisina kenttinä ja niihin tulisi soveltaa samoja käyttöoikeuksia kuin perustana olevaan dataan. Korkean hälytysriskin pisteytyksen antaminen asiakkaalle toimivalle agentille vaatii tarkkaa huomiota siihen, mitä agentti saattaa kertoa.
• Älä näytä profiiliattribuutteja, joita toiminto ei vaadi. Jokainen agentin kontekstiikkunan lisäattribuutti on ylimääräinen dataelementti, joka voidaan toistaa agentin vastauksessa. Käytä profilointiin tarvittavaa vähimmäissääntöä.
• Tarkasta kaikki istunnot, joihin laskettuja havaintoja tai luottamuksellisia profiilien attribuutteja syötettiin input-arvoina. Nämä istunnot edustavat päätöksiä, jotka on tehty Älykkäät asiakastiedot perusteella, ja niihin voi liittyä selkokielisyys- tai lakisääteisiä vaatimuksia tietyillä toimialoilla.

Esimerkki

Telekommunikaatioyritys käyttää Agentforcea käsitelläkseen säilytyskeskusteluita asiakkaiden kanssa, jotka ovat käynnistäneet peruutuspyynnön.

• Kun peruutustapaus avataan, agentti-istunto luodaan asiakkaan asiayhteydeksi ”accountId”.
• Alagentin kokoonpano kartoittaa kolme Data 360 Unified Profile -attribuuttia istunnon muuttujiin luonnin aikana: ”customerTier” (Enterprise), ”lifetimeValueUSD” (42 000) ja ”contractRenewalDate” (60 päivää).
• Laskettu havainto, kuten ”churnRiskScore” (0,91, laskettu käyttövähennyksestä, tukipyyntöjen yleisyydestä ja NPS-trendistä), kartoitetaan ylimääräisenä istuntomuuttujana Data 360 -yhteensopivan kulun kautta, joka kutsutaan ensimmäisenä toimintovaiheena.
• Agentti, joka on nyt perustettu vahvistettuihin asiakkaan faktoihin, kutsuu ”SelectRetentionOffer”-toimintoa. Koska syötetyt arvot sisältävät arvot ”customerTier = Enterprise”, ”lifetimeValueUSD = 42000” ja ”churnRiskScore = 0,91”, toiminto palauttaa enimmäistason säilytystarjouksen vakiomuotoisen tarjouksen sijaan.
• Agentti kutsuu ”PresentOffer”-arvoa tarjotakseen tarjouksen keskustelussa ja ”LogRetentionAttempt”-arvoa tallentaakseen vuorovaikutuksen CRM-järjestelmässä kaikkien auditoitavaksi säilytettyjen perustettujen attribuuttien kanssa.

Konteksti

Yritystiedot on pilkottu. Agentti, joka voi toimia vain Salesforce Platformissa olevien tietojen perusteella, on rajoitettu tiettyyn osaan tietoja, joita hänen täytyy ymmärtää tehokkaasti. Palvelukysymyksen vastaaminen saattaa vaatia asiakkaan avoimen tiketin lukemista Service Cloudissa. Ehdotuksen valmisteleminen saattaa vaatia tiedoston noutamista Google Drivesta. Tuotteiden käytön analysointi saattaa vaatia datan varaston kyselemistä. Kullakin näillä järjestelmillä on omat API-rajapintansa, oma todennusmallinsa ja oma datan skeemansa, ja kustannukset, jotka aiheutuvat räätälöidyn integraatiokoodin kirjoittamisesta kullekin järjestelmälle, ovat muuttaneet agenttien ja järjestelmien yhteyden historiallisesti kalliiksi ja hauraaksi.

MCP on avoin standardi, joka käsittelee tätä suoraan. Se määrittää yhtenäisen käyttöliittymän, jonka kautta agentti voi löytää ja kutsua minkä tahansa MCP-yhteensopivan palvelimen paljastamia työkaluja, riippumatta sen perustana olevasta järjestelmästä. Jokainen MCP-palvelin toimii sovittimena: se kerää kohdejärjestelmän natiivikäyttöliittymät standardoituun, työkaluihin keskittyvään käyttöliittymään, jonka agentti voi kysellä, kutsua ja kirjoittaa tietämättä mitään järjestelmäkohtaisista protokollista tai skeemasta.

Agentin näkökulmasta yhteyden muodostaminen Slackiin, rakenteelliseen kyselykielitietokantaan (SQL) ja asiakirjojen hallintajärjestelmään näyttää identtiseltä, kolme MCP-palvelinta, joista jokainen näyttää joukon kuvattuja, kutsuttavia työkaluja. Agentti valitsee ja järjestelee ne semanttisten kuvaustensa ja tavoitteen perusteella.

Ongelma

Kun agentin täytyy hakea tietoja tai käynnistää toimintoja useista ulkoisista järjestelmistä – joilla jokaisella on eri API-rajapinnat, todennukset ja skeemat – miten hän voi löytää, kutsua ja koostella omia kykyjään ilman räätälöityä integraatiokoodia per järjestelmä tai tiivistä yhteydenottoa minkä tahansa järjestelmän toteutukseen?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Täytyykö agentin käyttää Salesforce Platformin ulkopuolisia järjestelmiä, kuten asiakirjakauppoja, yhteistyötyökaluja, tietokantoja ja kolmansien osapuolten SaaS-palveluja, joiden API-rajapintoja ei ole esitetty oletusarvoisesti Agentforce?
• Vaaditaanko dynaamista työkalujen tutkimista, jossa agentti tunnistaa oikean integraation päätepisteen nykyisen pyynnön perusteella, eikä integraatioita kovakoodattu sen kokoonpanossa?
• Muuttuuko integrointiympäristö usein: lisätäänkö uusia järjestelmiä, päivitetäänkö olemassa olevia järjestelmiä ja muutetaanko niitä siten, että järjestelmäkohtainen lähestymistapa aiheuttaisi kestämättömiä ylläpitokustannuksia?
• Tarvitseeko agentin perusteluasteikkoa irrottaa alempien järjestelmien toteutustiedoista, jotta kohdejärjestelmän API:n muutos ei vaadi muutoksia agentin ohjeisiin tai alitason agentin kokoonpanoon?
• Ovatko eri tiimien tai tavarantoimittajien omistamat kohdesysteemit vastuussa omien kykyjensä paljastamisesta, mikä tekee MCP Server -mallista käytännöllisemmän kuin kuluttajan integraatiosta per agentti?

Salesforce-kuviosovellus

Kuvaus

Vahvistetun asiakkaan asiayhteyden syötteen järjestyskaavio

Tulokset

Agentin käytettävissä oleva pinta-ala laajenee lisäämättä integraation monimutkaisuutta. Uuden ulkoisen järjestelmän lisääminen tarkoittaa MCP-palvelimen käyttöönottoa tai määrittämistä sille eikä räätälöityjen Apex tai kulkujen integraatioiden kirjoittamista per agentti. Agentin päättelykerros pysyy muuttumattomana. Se löytää ja kutsuu uusia työkaluja niiden semanttisien kuvausten perusteella.

MCP-standardi luo myös puhtaan omistajuuden erottamisen: Järjestelmästä vastaava tiimi paljastaa sen ominaisuudet MCP-palvelimena. Agenttien tiimi käyttää näitä ominaisuuksia ymmärtämättä järjestelmän sisäisiä ominaisuuksia. Tämä rajoitus vähentää koordinoinnin kokonaiskustannuksia, kun integroitujen järjestelmien määrä kasvaa.

Työkalun komentoitavuus on suora lopputulos. Koska kaikilla työkaluilla on sama kutsun käyttöliittymä, agentti voi ketjuttaa työkaluja eri järjestelmistä, noutaa tiedoston Google Drivesta, noutaa dataa siitä ja kirjoittaa tuloksen CRM-tietueeseen luonnollisesti ketjutustoimintoina yhdessä järjestelmässä.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Työkalun kuvaukset ovat agentin ainoa peruste päättääkseen, kutsutaanko työkalua ja miten. Kirjoita kuvauksia selkeällä ja tarkoihin perustuvalla kielellä, joka kertoo mitä työkalu tekee, milloin sitä käytetään ja mitä se palauttaa. Kuvaus, jossa lukee "kyselee CRM-tietokantaa", on vähemmän hyödyllinen kuin "hakee tilin avoimet tapaukset, prioriteettijärjestyksessä, tietylle tilin tunnukselle". Huono kuvaus aiheuttaa huonon valinnan työkaluille.
• Laajenna jokainen MCP-työkalu yhteen atomien kapasiteettiin. Työkalu, joka noutaa asiakirjan ja myös kirjoittaa yhteenvedon takaisin lähdejärjestelmään, on agentille vaikeampi ymmärtää, vaikeampi yrittää uudelleen epäonnistumisen yhteydessä ja vaikeampi suojata kuin kaksi erillistä työkalua. Yksi työkalu, yksi vastuu.
• Suunnittele työkaluja siten, että tulokset ovat kirjoitettavia tietoja. Palautustyökalun tuloksen tulisi olla rakennettu siten, että se kartoitetaan luonnollisesti sen tavallisesti seuraavien toimintotyökalujen input-parametreihin, mikä vähentää agentin täytyy suorittaa transformaatiotyötä vaiheiden välillä.
• Etäpalvelimen MCP-palvelimet. Paikalliset binaariset asennukset luovat käyttöönotto- ja versioinnin monimutkaisuutta, joka kasvaa agenttiympäristöjen määrän myötä. Etäpalvelin voidaan päivittää riippumatta sen kuluttavista agenteista.

Salesforcen toteutushuomautukset

• Jos haluat yhdenmukaisen MCP-todennuksen, nopeusrajoituksen ja hyötykuormien vahvistuksen kaikissa lähtevissä MCP-kutsuissa, käytä MCP-palvelimia tukevaa tekoälyyhdyskäytävää, kuten MuleSoft Omni Gateway, ja määritä se ennen kuin näytät MCP-palvelinta agenteille.
• Käytä OAuth 2.0 -tunnuksia kaikille MCP Server -yhteyksien vaatimille tunnuksille. Tunnuksia ei saa näyttää työkaluparametreissä, toimintojen kokoonpanoissa tai Apex.
• Jotkin MCP-työkalut saattavat tarvita loppukäyttäjän tunnuksia suorittaakseen joitakin toimintoja liiketoimintatarkoituksesta riippuen (kuten rahoitussiirto). Jos haluat kopioida loppukäyttäjien identiteettivaltuuksia, käytä OAuth 2.0 On behalf Of Credentials Injection -käytäntöä, jota MuleSoft Omni Gateway tukee tällä hetkellä.
• Mukautetuille MuleSoft MCP -palvelimille: Määritä MCP-työkalun skeema MuleSoftin API-määrityksissä ja rekisteröi palvelimen päätepiste Agentforce. Testaa työkalun kuvauksia edustavien agenttien kyselyissä varmistaaksesi, että agentti valitsee oikean työkalun oikealle tehtävälle ennen kuin se otetaan käyttöön tuotantoympäristössä.

Virheiden käsittely ja palautus

• Kun MCP-työkalun kutsu palauttaa virheen, agentti tarkastaa koneellisesti luettavan virhekoodin määrittääkseen asiaankuuluvan palautustoiminnon: puuttuvien parametrien pyytäminen käyttäjältä, uudelleenyritys korjatulla syötteellä tai eskalointi ihmiselle. Se ei koskaan hiljaa virheitä tai jatka ajattelua kuin työkalupyyntö olisi onnistunut.
• Agentti käyttää uudelleenyrityslogiikkaa väliaikaisille virheille suoraan.
• Kirjaa kaikki MCP-työkalun kutsut asiakassivulta työkalun nimellä, sanitoiduilla input-parametreillä ja lopputuloksella. Tämä asiakassivun seuranta ja palvelinpuolen lokit ovat ensisijainen mekanismi, jolla voidaan diagnosoida, miksi agentti käytti tiettyä toimintopolkua, kun työnkulku ei tuota odotettua tulosta.

Turvallisuudessa huomioitavia asioita

• Kaikki lähtevät MCP-palvelinyhteydet kulkevat yhdyskäytävän läpi. Portaali noudattaa todennusvahvistusta, nopeusrajoitusta estääkseen työkalujen väärinkäytön ja hyötykuormien tarkastusta havaitakseen kehote-injektiokyselyt työkalun parametreissä. Suorat, välittämättömät yhteydet agenteilta MCP-palvelimiin ohittavat nämä asetukset eikä niitä sallita.
• Raja kunkin agentin MCP-palvelinyhteydet vain palvelimiin, joiden työkaluja agentti todella tarvitsee. Agentilla, joka on määritetty käyttämään kaikkia käytettävissä olevia MCP-palvelimia, on suurempi hyökkäysalue kuin agentilla, joka on yhdistetty vain työkaluihin, joita hänen määrittämänsä tehtävät vaativat.
• Vahvista ja sanaloi työkalun syöttöparametrit ennen niiden välittämistä työkaluun, varsinkin kun parametriarvot saadaan käyttäjän tarjoamasta tekstistä tai LLM:n luomasta sisällöstä. Älä välitä vahvistamattomia LLM-tuloksia suoraan työkalu-parametreinä. Hyökkääjä, joka voi vaikuttaa agentin päättelyyn, voi käyttää tätä polkua syöttääkseen haitallisia arvoja alempaan järjestelmäkutsuihin.
• Käsittele agentin luetteloa yhdistetyistä MCP-palvelimista ja niiden työkalujen inventaarioista luottamuksellisena kokoonpanona. Hyökkääjällä, joka tietää, mitä työkaluja agentilla on käytettävissä ja mitä parametrejä hän hyväksyy, on kartta kehotteiden injektion hyötykuormien luomiseen, joka on suunniteltu näiden työkalujen väärinkäyttämiseksi.

Esimerkki

Myyntiagentti valmistelee kattavan tilin tiedotuksen ennen arvokasta asiakaspuhelua:

1. Agentti vastaanottaa pyynnön: "Valmistele Acme Corp -tietueen esittely ennen huomispäivän jatkosopimusta."
2. Agentti kyselee MCP-työkalujen katalogia ja tunnistaa kolme relevanttia työkalua kahdesta MCP-palvelimesta: GetRecentEmails, GetOpenOpportunities ja GetSupportTicketSummary.
3. Agentti kutsuu kaikkia kolmea työkalua rinnakkain. Jokainen MCP-palvelin kääntää kutsun kohdejärjestelmänsä natiiviin API-rajapintaan, noutaa asiaankuuluvat tiedot ja palauttaa rakenteellisen tuloksen.
4. Agentti näkee kolme tulosta. Viimeisimmät sähköpostin viestiketjut, avoimen uusimisen mahdollisuus diilin koon ja vaiheen kanssa sekä yhteenveto avoimista tukipyyntöistä prioriteetin mukaan, ja syntetisoi ne rakenteelliseksi tilin esittelyssä.
5. Agentti kutsuu CreateAccountNote tallentaakseen tiedotuksen tilitietueeseen ja palauttaa yhteenvedon pyytävälle käyttäjälle.
6. Kaikki neljä MCP-työkalun kutsua kirjataan lokiin yhdyskäytävällä, joka sisältää työkalujen nimet, palvelimen identiteetit ja lopputulokset istunnon auditointitietueelle.

Konteksti

Lähtevä MCP-kuvio kuvaa Agentforce-agenttia, joka kuluttaa työkaluja ulkoisista MCP-palvelimista. Saapuva kuvio kääntää tämän. Salesforce Platform -ominaisuudet, kuten CRM-tietueet, kulut, Apex ja Data 360 -havainnot, näytetään MCP-työkaluina, joita ulkoiset agentit voivat löytää ja kutsua mistä tahansa LLM-kehyksestä.

Tämä kuvio on tärkeä, koska yrityksen tekoälyn käyttöönotot ovat harvoin yksittäisiä. Kumppanin agentin täytyy ehkä hakea asiakkaan tilin tila Salesforcessa, jos se on rakennettu eri kehykseen. Sisäisen datatieteellisen tiimin, joka käyttää Python-pohjaista agenttia, täytyy ehkä käynnistää Salesforce-kulku käynnistääkseen hyväksymisprosessin. Ilman standardoitua altistumismekanismia jokainen ulkoinen kuluttaja tarvitsee räätälöidyn integraation. Salesforcen ominaisuuksien paljastaminen MCP-palvelimena tarjoaa jokaiselle MCP-yhteensopivalle agentille yhtenäisen ja löydettävän käyttöliittymän sovellusalustan työkaluihin riippumatta soittavan agentin rakenteesta.

Esimerkiksi kumppanin hankintaagentin, joka perustuu kolmannen osapuolen kehykseen, täytyy vahvistaa toimittajan sopimuksen tila Salesforcessa ennen ostotilauksen hyväksymistä. Sen sijaan, että se rakentaisi suoran REST-integraation, se kutsuu Salesforcen MCP-palvelimella olevaa GetContractStatus-työkalua. Työkalu käyttää samoja käyttöoikeuksia kuin mikä tahansa Salesforce-toiminto. Soittava agentti näkee vain tulokset.

Ongelma

Kun ulkoisen agentin, joka on rakennettu eri kehykseen, jonka kumppani omistaa tai jollain muulla tavalla toimii Salesforce Platformin ulkopuolella, täytyy kutsua Salesforce-ominaisuuksia osana omaa työnkulkuaan, miten nämä ominaisuudet voidaan paljastaa standardoidulla, havaittavalla ja turvallisesti hallitulla tavalla, joka ei vaadi räätälöityä integraatiota per ulkoinen kuluttaja?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Rakentavatko ulkoiset agentit, joiden täytyy kuluttaa Salesforce-ominaisuuksia, kehyksiä, jotka tukevat MCP-standardia? Jos se ei ole, REST API tai Webhook-lähestymistapa saattavat olla sopivampia kuin MCP.
• Mitkä Salesforce-ominaisuudet täytyy paljastaa - Vain luku -datan noutaminen, kirjoitustoiminnot, kulun kutsut tai yhdistelmä? Vaikutusalue määrittää suoraan suojaustilan, jota täytyy hallita.
• Miten ulkoisen soittajan henkilöllisyys tulisi vahvistaa ja minkä Salesforce-käyttöoikeuksien perusteella sen kutsut tulisi suorittaa? Agentista sovellusalustaan -kutsut eivät saa periä laajempia käyttöoikeuksia kuin mitä tietty toiminto vaatii.
• Onko Salesforce MCP -palvelin tarkoitettu sisäisille kuluttajille (saman organisaation muiden tiimien agentit) vai ulkoisille kuluttajille (kumppani- ja asiakasagentit)? Trust ja todennusvaatimukset vaihtelevat merkittävästi näiden kohdeyleisöjen välillä.
• Miten paljastettujen työkalujen joukko kehittyy ajan myötä? Kaikki yhdistetyt agentit voivat havaita MCP-palvelimeen lisätyt uudet Salesforce-ominaisuudet välittömästi. Tarkoittamattoman työkalun altistumista täytyy hallita tarkoituksellisen julkaisuprosessin kautta.

Salesforce-kuviosovellus

Kuvaus

Jakson kaavio liiketoimintaominaisuuksille kutsuttavana työkaluna

Tulokset

Salesforcesta tulee ensiluokkainen osallistuja monivalmistajien agenttien ekosysteemeihin. Ulkoiset agentit voivat löytää ja kuluttaa sovellusalustan ominaisuuksia ilman, että heidän täytyisi suorittaa mukautettua REST-integraatiota kuluttajakohtaisesti tai käyttötarkoittain. Kuluttajien määrä voi kasvaa ilman, että integraation ylläpitokustannuksissa olisi suhteellista kasvua.

Headless 360:n avulla Salesforce-käyttöoikeusmalli hallitsee kaikkia saapuvia työkalujen kutsutuksia. Ulkoiset MCP-asiakassovellukset eivät ohita olemassa olevia datan käyttöoikeuksia, vaan ne toimivat niiden sisällä. Tämä tarkoittaa, että kykyjen paljastaminen MCP:n kautta vastaa niiden paljastamista minkä tahansa muun todennetun API-ympäristön kautta.

Työkalujen löydettävyys on yhdistelmähyöty. Kun MCP Serverin työkalukategoriaan lisätään uusia Salesforce-ominaisuuksia, ne ovat välittömästi kaikkien yhdistettyjen ulkoisten agenttien käytettävissä ilman, että heidän täytyisi päivittää kokoonpanojaan.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Julkaise vain ulkoisten agenttien tarvitsemat kohteet. Jokainen MCP Server -hakemistoon lisätty työkalu laajentaa hyökkäyksen pinta-alaa ja hallintakuormaa. Tarkasta työkalujen inventaario tarkoituksella. Määritä ulkoiselle kulutukselle hyväksytyt ominaisuudet ja käsittele hyväksymätöntä altistumista kokoonpanovälinä, äläkä oletuksena.
• Kirjoita työkalujen kuvauksia ulkoisille kuluttajille. Ulkoisen agentin operaattori ei tunne sisäistä datamalliasi tai nimeämiskäytäntöjäsi Knowledgea. Pidä kuvaukset sellaisenaan: mitä työkalu tekee, mitä kukin parametri tarkoittaa, mitä tulos edustaa ja mitä rajoituksia tai edellytyksiä soittajan täytyy täyttää.
• Versioi työkalut erikseen, kun niiden input- tai output-skeemat muuttuvat. Ulkoinen agentti, joka on riippuvainen työkalun tämänhetkisestä skeemasta, rikkoutuu hiljaa, jos skeema muuttuu ilman erillistä ilmoitusta. Käsittele MCP-työkalun käyttöliittymään tehdyt muutokset samalla tavalla kuin julkisen REST API:n muutokset.

Salesforcen toteutushuomautukset

• Suorita jokainen saapuva Salesforce Out-of-Box (OOTB) MCP (Headless 360) -työkalun kutsu loppukäyttäjälle, jonka käyttöoikeudet on rajoitettu vain paljastettujen työkalujen vaatimiin toimintoihin. Älä suorita saapuvien agenttien puheluita korkean oikeutuksen ylläpitäjän henkilöllisyydellä.
• Jos haluat käyttää todennusta, tiedonsiirtorajoitusta, skeeman vahvistusta ja henkilötietojen tunnistusta yhdenmukaisesti kaikissa MCP-työkaluissa, käytä tekoälyyhdyskäytävää, kuten MuleSoft Omni Gateway -palvelua.
• Määritä MuleSoft MCP Facades -työkalun MCP-skeema MuleSoftissa riippumatta sen perustana olevasta Salesforce API -skeemasta. MCP-käyttöliittymän tulisi vastata soittavan agentin käsitteellisiä tarpeita eikä sitä tukevan Salesforce-objektin muotoa. Tämä irrottaminen sallii Salesforce-toteutuksen kehittyä rikkomatta ulkoisen työkalun sopimusta.

Virheiden käsittely ja palautus

• Työkalun kutsujen virheiden täytyy palauttaa rakenteellisia MCP-virheiden vastauksia, jotka sisältävät koneellisesti luettavan koodin ja pelkän kielen kuvauksen. Soittavalla ulkoisella agentilla ei ole näkyvyyttä Salesforce Platformin sisäisiin tietoihin, koska virheviestien täytyy olla itsenäisiä ja interaktiivisia ilman, että heidän tarvitsee olla Knowledgea Salesforcekohtaisista virhekoodeista tai objektimalleista.
• Säännön rajoitusvirheet ja todennusvirheet täytyy palauttaa nopeasti ja niillä täytyy olla riittävästi tietoja, jotta ulkoisen agentin operaattori voi diagnosoida ja korjata, mikä säännön rajoitus saavutettiin tai mikä tunnus hylättiin paljastamatta sisäisen kokoonpanon lisätietoja.
• Kirjaa kaikki saapuvat MCP-työkalun kutsut lokiin Omni-yhdyskäytävään soittavan agentin henkilöllisyydellä, kutsutulla työkalulla, syöttöparametreillä (luottamuksellisista arvoista sanitoitu) ja lopputuloksella. Tämä loki on ensisijainen näyttöketju ulkoisten kuluttajien ilmoittamien virheiden diagnosoimiseen ja ulkoisten agenttien käyttämien tietojen tarkastamiseen.

Turvallisuudessa huomioitavia asioita

• Jokaisen saapuvan MCP-yhteyden täytyy olla todennettu ennen kuin työkalut ovat käytettävissä. Älä salli työkalukatalogin todentamatonta löytämistä. Näytettyjen ominaisuuksien luettelo on itsessään luottamuksellisia tietoja.
• Käytä yhteyden tason todennuksen lisäksi työkalutason valtuutusta. Rekisteröidyn ulkoisen agentin tulisi voida kutsua vain tietyt työkalut, joihin hänelle on erikseen myönnetty käyttöoikeus, eikä koko katalogia. Noudata tätä käytäntöä yhdyskäytävässä, äläkä sovelluksen kerroksessa.
• Vahvista ja sanaloi kaikki saapuvat työkaluparametrit ennen kuin välität ne Salesforce Platform -toimintoihin. Ulkoisista agenteista saadut parametrit ovat epäluotettu syöttöalue – pahantahtoisesti luotu parametri saattaa yrittää korvata kyselyn suodattimia, syöttää Salesforce Object Query Language (SOQL) -fragmentteja tai vaikuttaa kulun muuttujiin. Vahvista MCP-palvelimen tai fasadin rajan tyyppi, muoto ja arvoalue.
• Suorita rekisteröityjen ulkoisten kuluttajien käyttöoikeustarkastus säännöllisesti. Kumoa tunnukset agenteille, jotka eivät ole enää aktiivisia tai joiden käyttöoikeusaluetta on muutettu. Keskeytetyn kumppani-integraation pysyvä, mutta käypä tunnus on tarpeeton pysyvä riski.
• Varo sovellusalustan rajoituksia rikkomalta rajoittamalla saapuvien MCP-viestien määrää yhdyskäytävässä. Rajoita muiden kuin kriittisten agenttien liikennettä, kun palvelutasosopimukseen perustuvat tasokäytännöt ovat käytössä.

Esimerkki

Logistiikkakumppanin ylläpitämän hankintaagentin täytyy vahvistaa toimittajan sopimus ja luottotila ennen arvokkaan ostotilauksen hyväksymistä:

1. Kumppanin agentti todentaa itsensä yhdyskäytävään käyttämällä rekisteröityjä OAuth 2.0 -asiakastunnuksiaan ja saa rajautetun käyttöoikeusvaltuuden.
2. Agentti kyselee Salesforcen MCP Serverin työkalukategoriaa ja tunnistaa kaksi asiaankuuluvaa työkalua: GetSupplierContractStatus ja GetAccountCreditSummary.
3. Agentti kutsuu GetSupplierContractStatus-palvelua, joka sisältää toimittajan tunnisteen. MCP-palvelin kääntää tämän Salesforce-tietuekyselyksi, käyttää integraatiokäyttäjän kenttätason suojausta ja palauttaa sopimuksen tämänhetkisen tilan, vanhenemispäivän ja merkittyjä vaatimustenmukaisuuden säilytyksiä.
4. Agentti kutsuu GetAccountCreditSummary-palvelua, joka reitittää MuleSoftin MCP-fasadin läpi. Fatsadi kerää toimittajan laskujen erääntymisen ja maksuhistorian kahdesta Salesforce-objektista ja palauttaa yhden yhdistetyn hyvitysyhteenvedon.
5. Kumppanin agentti määrittää molemmilla tuloksilla, että sopimus on aktiivinen ja luottotilanne on hyväksyttävissä olevissa rajoituksissa, ja hyväksyy ostotilauksen omassa järjestelmässä.
6. Molemmat työkalun kutsut kirjataan yhdyskäytävään, joka sisältää kumppaniagentin henkilöllisyyden, kutsutut työkalut ja lopputulokset, jotka luovat tarkastettavan tietueen ulkoisista käyttöoikeuksista ja palautetuista tiedoista.

Konteksti

Yritysjärjestelmät ovat nyt riippuvaisia yhteistyöagenteista tai verkostoista, joissa monimutkaiset pyynnöt pilkotaan ja delegoidaan eri toimialueiden tai toimittajan sovellusalustojen erikoistuneille agenteille. Nämä agentit, joilla jokaisella on oma roolinsa, kykyjään ja työkalujaan, tarvitsevat standardoidun ja turvallisen viestintämenetelmän koordinoidakseen yhteisiä tavoitteita ilman, että heidän tarvitsisi osallistua jokaiseen vaiheeseen.

Ongelma

Miten soittava tekoälyagentti voi dynaamisesti löytää, vuorovaikuttaa turvallisesti monimutkaisia tai toimialuekohtaisia tehtäviä ja delegoida monimutkaisia tai toimialuekohtaisia tehtäviä etäagentille, joka voidaan rakentaa eri kehykseen tai jota toimii eri toimittaja ja joka vastaanottaa rakenteellisia tuloksia laajemman yrityksen työnkulun suorittamiseksi?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Miten agentit, jotka on kehitetty käyttämällä erilaisia kehyksiä tai jotka toimivat erillisissä sovellusalueissa, toimivat yhdessä?
• Miten agentit voivat tehdä yhteistyötä ja delegoida tehtäviä paljastamatta sisäistä logiikkaansa, muistiaan tai omia työkalujansa?
• Miten agentit tukevat monimutkaisia ja pitkäaikaisia tehtäviä tarjoamalla reaaliaikaisia tilapäivityksiä, streaming-ilmoituksia ja työntöilmoituksia?
• Miten agentit noudattavat organisaatiotason tietoturvaa (todennusta, valtuutusta) ja käytäntöjen noudattamista agenttien välisessä viestinnässä?
• Miten agentit käsittelevät rakenteellisia tehtävien työnkulkuja (aloitus, edistyminen, suorittaminen), jotka ylittävät yksinkertaiset API-kutsut?

Salesforce-kuviosovellus

A2A-protokolla on avoin standardi, jonka avulla agentit voivat löytää, delegoida ja tehdä yhteistyötä muiden agenttien kanssa työtovereina. Se tarjoaa agenteille yhteisen kielen, jolla he voivat vaihtaa tietoja ja koordinoida toimintoja turvallisesti eri sovellusalustojen ja toimittajien välillä. A2A keskittyy peer-to-peer-viestintään, joka täydentää MCP:tä ja joka keskittyy agenttien yhdistämiseen työkaluihin ja API-rajapintoihin.

Kuvaus

Arkkitehtuuri sisältää soittavan agentin, joka käynnistää viestinnän, jota helpottaa agentin katalogi/rekisteri löytämiseksi:

Ristiagenttien delegoinnin järjestyskaavio

Vertaisagentti käsittelee pyynnön käyttämällä toimialuekohtaista logiikkaa, muistia ja työkaluja ja palauttaa sitten rakenteelliset tulokset soittavalle agentille.

Tulokset

A2A-valtuutus erottaa toimialueen omistajuuden työnkulkujen orkestroinnista. Soittajan ei tarvitse tietää, miten vertaisagentti on rakennettu, millä alustalla se toimii tai mitä työkaluja se käyttää sisäisesti. Hän delegoi tehtävän ja saa rakenteellisen artefaktin. Tämä rajoitus tarkoittaa, että asiantuntijaagenttia (taustatarkistus, taloudellisten riskien pisteytys, logistinen reititys) voidaan kehittää, ottaa käyttöön ja parantaa riippumatta sen kutsuvista työnkuluista.

Protokollan tehtävien elinkaarimalli (lähetetty, työskennellyt, valmis, epäonnistui) tukee
pitkäaikaiset toiminnot oletusarvoisesti. Soittava agentti voi rekisteröityä osavaltioiden päivityksiin sen sijaan
kuin estävän yhteyden pitäminen, mikä tarkoittaa, että A2A-tehtävät voivat kattaa minuutteja tai tunteja
ilman, että orkestroivan agentin täytyy pysyä aktiivisena koko ajan.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Monimutkaisissa skenaarioissa agenttien välittäjä voi toimia älykkään reitityspalvelun tai "älykkään valintapaneelin" roolissa koordinoidakseen eri agenttien tehtävien delegointia ja hallitakseen monivaiheisia prosesseja.
• Koska A2A tukee pitkäaikaisia tehtäviä, viestinnän täytyy olla suunnattu tehtävien suorittamiseen, määrittää tehtäväobjektin elinkaari ja tarjota reaaliaikaisia tilapäivityksiä ja ilmoituksia.
• Protokolla on suunniteltu tukemaan useita sisältötyyppejä, kuten tekstiä, tiedostoja, rakenteellista dataa, ääniä ja videoiden suoratoistoa.
• Agenttien ja heidän kykyjensä väliset suhteet ja riippuvuudet määritetään määritysti kokoonpanotiedostossa (esimerkiksi "agent-network.yaml") ja julkaistaan agenttien rekisteriin.

Salesforcen toteutushuomautukset

• Pidä yhdistetyt alitason agentit alle 7 säilyttääksesi reitityksen laadun, jotta SOMA-organisaatio voi orkestroida tehokkaasti.
• Tällä hetkellä vain yhtä valtuutuskerrosta tuetaan (superagentti → alagentti); syvemmät ketjut siirtävät viiveen "ei kestävään nopeuteen". Tällä hetkellä alitason agentit eivät voi delegoida toisia yhdistettyjä alitason agentteja.
• Ihmisten välittämistä tuetaan vain orkestrointitasolla. Alavirkailijat eivät voi eskaloida toisiaan.
• Käytä SOMA-järjestelmässä Agent Scriptia, kun LLM-pohjainen reititys aiheuttaa epäselvien syötettyjen tietojen reitityksen virheitä determinististä reititystä varten. Agenttikomentosarja ottaa käyttöön agenttien välisen jaetun kontekstin.

Virheiden käsittely ja palautus

A2A-protokolla määrittää kattavat virhekoodit, jotka auttavat virheenkorjauksessa ja virheiden hallinnassa.

• Palautuslogiikka: Agenttien tulisi lisätä uudelleenyrityskäytäntöjä (uudelleenyrityksiä), vianmäärityslogiikkaa vaihtoehtoisille sopiville agenteille ja erillisiä aikakatkaisuja.
• Tehtävän tilan seuranta: Tehtävien hallinnan työnkulku varmistaa, että agentit voivat pysyä ajan tasalla tehtävän uusimman tilan kanssa, mikä helpottaa palautusta häiriöiden varalta.
• Huomautettavuus: Vuorovaikutusten lisätietojen, kuten viiveen, onnistumissuhteiden ja virheiden yleisyyksien, kirjaaminen lokiin on tärkeää laadun ja vianmäärityksen valvomiseksi.

Turvallisuudessa huomioitavia asioita

• Enterprise-grade-todennus: A2A on suunniteltu vastaamaan yritystason todennus- ja valtuutusstandardeja, kuten OAuth 2.0 ja JWT, joita hallitaan usein ulkoisilla alustoilla, kuten Okta.
• A2A-suojauksen yhdyskäytävä: Portaali (esimerkiksi MuleSoft Omni Gateway) on välttämätön kaikkien A2A-viestien käytäntöjen noudattamiseksi, ja se toimii sekä sisään- että uloskirjautumisportaalina, joka suojaa agentteja ja hallitsee ulkoisten agenttien ja palveluiden lähtevää liikennettä.
• Vakuutus: A2A-palvelimelle ja tietoturvalle tulisi soveltaa Agent Card Rewrite-, Skeema Validation-, Spike Control-, PII Detector- ja muita käytäntöjä.

Esimerkki

Candidate Sourcing -työnkulku

Rekrytointipäällikkö pyytää keskitetyn orkestrointiagenttinsa löytämään työluetteloa ja taitojoukkoa vastaavia ehdokkaita.

1. Discovery: Orkestraattori-agentti kyselee agenttien rekisteriä ja löytää erikoistuneen rekrytoivan agentin ja taustan tarkastajan (kumpikin vertaisagentteja).
2. Valtuutus (A2A): Orkestrointiagentti lähettää rakenteellisen tehtäväpyynnön (A2A-viestin) rekrytoivalle agentille lähdeehdokkaille.
3. Kumppanin käsittely: Rekrytoiva agentti suorittaa oman työnkulunsa (esimerkiksi kutsumalla ulkoista LinkedIn-työkalua MCP:n kautta).
4. Artefaktin palautus (A2A): Rekrytoiva agentti palauttaa ehdotettujen ehdokkaiden luettelon (artifakti).
5. Seuraava valtuutus: Sen jälkeen orkestrointiagentti delegoi toisen tehtävän (A2A) taustan tarkastusagentille parhaalle ehdokkaalle. Tämä agentti suorittaa tarkastuksen ja palauttaa tuloksen ja suorittaa kokonaistehtävän.

Konteksti

Monimutkaiset yritystyönkulut vaativat usein ulkoisilla alustoilla tai kumppanijärjestelmillä isännöityjä erikoistuneita agentteja käynnistääkseen tehtäviä, delegoidakseen kyselyitä tai tarjotakseen päivityksiä sisäisille agenteille (esimerkiksi Salesforce Platform -agenteille). Tämä kuvio käsittelee, miten sisäinen Agentforce vastaanottaa ja käsittelee turvallisesti ja luotettavasti etäagentilta saatuja pyyntöjä toimialuekohtaisen ominaisuuden suorittamiseksi.

Ongelma

Miten sisäinen erikoistunut tekoälyagentti (esimerkiksi Agentforcen taustatarkistusagentti) voi paljastaa toimialuekohtaiset ominaisuutensa turvallisesti ulkoisille vertaisagenteille, käsitellä saapuvan rakenteellisen A2A-pyynnön ja hallita tehtävän elinkaarta (mukaan lukien reaaliaikaiset tilapäivitykset) palauttaakseen rakenteellisia esineitä etäpuheluagentille?

Voimat

Kun käytät tätä kuviota, vastaa seuraaviin kysymyksiin:

• Miten voit paljastaa sisäisten agenttien ominaisuudet ulkoisille agenteille turvallisesti estämättä sisäistä logiikkaa tai työkaluja?
• Miten noudatat yritystason suojauskäytäntöjä vahvistaaksesi soittavan agentin henkilöllisyyden ja valtuutetun valtuuden ennen pyyntöjen käsittelyä?
• Miten käsittelet pitkäaikaisia saapuvia tehtäviä tarjoamalla rakenteellisia, ei-synkronoituja tilapäivityksiä?
• Miten voit varmistaa saumattoman vuorovaikutuksen eri ulkoisiin kehyksiin perustuvien agenttien kanssa?

Salesforce-kuviosovellus

A2A-protokolla tarjoaa avoimen standardin suojattuun, vertaisryhmäkohtaiseen valtuutukseen ja yhteistyöhön. Sisäinen agentti toimii vertaisagenttina ja mainostaa omia kykyjään agentin katalogin/rekisterin kautta ja käyttää A2A:ta suojattujen kanavien (HTTPS/SSE) kautta vastaanottaakseen ja vastatakseen rakenteellisiin pyyntöihin.

Kuvaus

Jakson kaavio agenteille kutsuttavina palveluina

Tulokset

Tämä kuvio paljastaa sisäiset agentit erikoistuneina palveluina usean agentin verkostossa. Ulkoiset agentit voivat delegoida tehtäviä turvallisesti sisäisille ominaisuuksille, kun organisaatio ylläpitää hallittavuutta, valvottavuutta ja käytäntöjen noudattamista.

Suunnittelussa huomioitavia asioita

Platform-agnostic-ohjeet

• Portaali (esimerkiksi MuleSoft Omni Gateway) täytyy sijoittaa sisäänkirjautumiskohteeksi noudattaakseen kaikkien saapuvien A2A-pyyntöjen käytäntöjä, mukaan lukien nopeusrajoituksia, todennusta ja hyötykuormien vahvistusta.
• Sisäisten agenttien täytyy hallita tehtäväobjektin tilaa ulkoisesta käynnistyksestä loppuun, jotta etäagentti saa yhdenmukaisia ja vahvistettavia tilapäivityksiä.
• Varmista, että agentin julkaisemat ominaisuudet agenttikortissa ovat selkeitä, tarkoitusperusteisia ja sisältävät tarvittavat tietoturva-alueet delegointia varten.

Virheiden käsittely ja palautus

• Rakenteelliset virhekoodit: Jos epäonnistui, sisäisen agentin täytyy palauttaa soittavalle agentille A2A-yhteensopivia rakenteellisia virheviestejä ottaakseen käyttöön etäyrityslogiikka tai vaihtoehtoiset failover-mekanismit.
• Idempotenssi: Agentin täytyy varmistaa, että kaikki ulkoisen agentin uudelleenkäynnistämästä A2A-pyynnöstä (verkon keskeytyksen tai palautuksen vuoksi) aiheutuneet haittavaikutukset ovat todennäköisiä.

Turvallisuudessa huomioitavia asioita

• Saapuvan käytännön noudattaminen: Portaalin täytyy noudattaa käytäntöjä ulkoisten agenttien sallimiseen/estämiseen ja JWT/OAuth 2.0 -valtuuksien vahvistamiseen vahvistaakseen puhelun lähettäneen agentin henkilöllisyyden ja delegoidun valtuuden.
• Syötteen puhdistaminen: Vahvista ja sanitoi kaikki saapuvat pyyntöjen tietosisällöt välttyäksesi kehotteiden mahdollisilta syötteiltä tai haitallisilta datahyökkäyksiltä.
• Identiteetin propagointi: Kartoita ulkoisen agentin henkilöllisyys ja valtuutettu valtuutus turvallisesti sisäisiin tietoturvakonteisiin (esimerkiksi Salesforce-käyttäjäprofiileihin) ennen toimintojen suorittamista sisäisille järjestelmille.

Esimerkki

Ulkoinen järjestelmäpyyntö

1. Pyyntö: Kumppanijärjestelmän rekrytointiagentti lähettää A2A-tehtäväpyynnön sisäiselle Agentforcen Työntekijän vahvistusagentille (kumppaniagentille) vahvistaakseen uuden ehdokkaan työtilan.
2. Käsitellään: Työntekijän vahvistusagentti vastaanottaa pyynnön yhdyskäytävän kautta, vahvistaa kumppaniagentin tunnukset, suorittaa sisäisen työnkulun (esimerkiksi kutsuu sisäistä henkilöstöjärjestelmää) ja muotoilee vastauksen.
3. Vastaus: Vertaisagentti palauttaa rakenteellisen A2A-objektin (esimerkiksi työn alkamispäivän ja työnimikkeen) etärekrytointiagentille, joka jatkaa sitten ulkoista työnkulkua.

1. MCP-, A2A- ja API-rajapintojen suojauksen yhdyskäytävä

   Kaikkien agentilta järjestelmälle- ja järjestelmästä agentille -liikenteen yhtenä täytäntöönpanopisteenä vaaditaan yhdyskäytävä.

• Suojatut yhteydet: Portaali varmistaa, että vain todennetut ja valtuutetut agentit käyttävät MCP-, A2A- ja API-päätepisteitä rajoittamalla niiden käyttöoikeuksia.

• Käyttöönotetut palvelutasosopimukset: Portaali voi noudattaa nopeusrajoituksia, auttaa organisaatioita täyttämään suorituskykyvaatimukset ja estää MCP- ja A2A-palvelimen ylikuormituksen.

• Yksinkertaistettu hallinta: Portaali tarjoaa keskitettyä näkyvyyttä ja hallintaa kaikista palvelimen vuorovaikutuksista, mikä yksinkertaistaa agenttien toimintojen hallintaa ja valvontaa.

• Datan yhdenmukaisuus ja suojaus: Käytännöt, kuten skeeman vahvistus, datan yhdenmukaisuuden noudattaminen ja henkilötietojen tunnistaminen, voivat suojata luottamuksellisia tietoja.

MueleSoft Omni Gateway

2. Identiteetin propagation ketju

Kun yritykset omaksua agenttinen paradigma, uusi tietoturva haaste syntyy: Miten loppukäyttäjien identiteetti kulkee itsenäisten tekoälyagenttien verkoston kautta? Tavallisissa API-arkkitehtuurissa käyttäjä todentaa itsensä kerran ja sovellus kutsuu käyttäjän puolesta taustapalveluita. Identiteettiketju on lyhyt, ymmärrettävä ja sitä hallitaan tavallisesti yhdessä Trust toimialueessa.

Agenttien arkkitehtuurit sisältävät kuitenkin paljon pidempiä ketjuja, joissa yksi pyyntö lähetetään eri agenteille, palveluille ja MCP-palvelimille, jotka kaikki saattavat ylittää palvelurajoitukset, Trust toimialueet ja jopa organisaation rajat. Jos yrityksillä ei ole tarkoituksellista strategiaa henkilöllisyyden levittämiseksi, heidän täytyy valita tietoturvan ja toiminnallisuuden välillä – ongelma, jota arkkitehti ei tarvitse ratkaista.

MuleSoft korjaa identiteettien monimutkaisuuden käyttämällä sen luotettua agentin identiteettia -ominaisuutta. Tämä ratkaisu hyödyntää käytäntöihin perustuvaa yhdyskäytävän hallitsemaa strategiaa varmistaakseen, että loppukäyttäjien identiteetti säilyy eri vuorovaikutustyypeissä, mukaan lukien A2A-protokollat, MCP-työkalukutsut ja REST API -pyynnöt. Keskittämällä henkilöllisyyden hallinnan Omni Gateway -kerrokselle lähtevien todennuskäytäntöjen avulla yritykset voivat suojata koko agenttien verkostonsa muokkaamatta taustapalveluita tai agentteja. Lisätietoja on kohdassa Agentin yrityksen luotetun agentin identiteetti.

3. RAG-suojaus Data 360:ssa

Data 360 tukee attribuutteihin perustuvaa käyttöoikeuksien hallintaa (ABAC) objektin, kentän ja rivitasolla datan hallintakäytännön asetusten kautta. Tämä on ensisijainen tapa hallita, mitä tietoja näytetään kenellekin, mukaan lukien RAG-haun indekseissä. Rakenteellisten tietojen käyttöoikeusehdot toteutetaan käyttämällä käyttäjäattribuutteja ja käyttöoikeusjoukkoja. Jos käytät jäsentämättömiä tietoja, metadatan suodattaminen (haun indeksien esisuodattimet) voi rajoittaa haettavaa dataa.

Yhteydenpito LLM:n kanssa tapahtuu Einsteinin Trust Layer -kerroksen kautta, joka peittää luottamukselliset/PII-tiedot ennen kuin ne saavuttavat tietoturvamallin paitsi haun aikana myös ennen luomista.

Varmista, että tiukkoja datan hallinta- ja vahvistussääntöjä sovelletaan ennen kuin dataa käytetään vektorihaussa, jotta se ei aiheuta RAG-myrkytyksiä. Einstein Trust Layer voi myös noudattaa kehotteiden peittämisen/toksisuuden tarkastuksia. Voit käyttää Agenttikäyttäjä-profiilille tiukkoja käyttöoikeusjoukkoja.

4. Uusi nimetty tunnusmalli Salesforce on parantanut todennusarkkitehtuuriaan ottamalla käyttöön kaksitasoisen nimettyjen tunnusten mallin, joka erottaa yhteyden ja identiteetin väliset huolenaiheet toisistaan. Käytä tätä aina, kun teet kutsuja Apexin kautta, ja vältä luomasta omaa todennusprotokollaasi. Tämä malli tarjoaa myös laajennettavuutta ja parannettua tietoturvaa. Ulkoiset tunnukset sijaitsevat tämän mallin perustana. Ne sisältävät todelliset todennustiedot ja tukevat kattavaa joukkoa protokollia, kuten OAuth 2.0 -asiakastunnuksia, JWT-haltijaa ja AWS-allekirjoituksen V4-versiota, ja määrittävät samalla, miten periaatteet kartoitetaan: joko yhtenä nimettynä vastuuhenkilönä (jaettuna kaikille käyttäjille) tai käyttäjäkohtaisina vastuuhenkilöinä (jossa jokainen käyttäjä todentaa itsensä omalla identiteetillään). Nimetyt tunnukset toimivat puolestaan päätepistekerroksena. Ne määrittävät callout-URL-osoitteen ja viittaavat ulkoiseen tunnukseen käsittelemään todennuksen kädenlyöntiä, jolloin päätepisteiden kokoonpano on erillään tunnusten hallinnasta. Pääkäyttäjät kartoittavat käyttöoikeusjoukot asiaankuuluvaan Ulkoinen tunnus -pääkäyttäjään ottaakseen käyttäjäkohtaiset todennuskulut käyttöön, jotta vain käyttäjät, joille on kohdistettu oikea käyttöoikeusjoukko, voivat kutsua callout-kutsuja omalla identiteetillään. Tämä kaksitasoinen rakenne ei ainoastaan yksinkertaista suojattujen callout-kutsujen kokoonpanoa, vaan tarjoaa myös arkkitehdeille paljon enemmän joustavuutta ja hallintaa siitä, miten integraatiot todennetaan Salesforcen yhdistämissä järjestelmissä. Lisätietoja on kohdassa Nimetyt tunnukset -dokumentaatio.

Tämä osio kartoittaa arkkitehtuurin datan käsittelymallit vaatimustenmukaisuutta koskeviin velvollisuuksiin, joita tavallisesti esiintyy säänneltyjen yritysten käyttöönotoissa.

Käyttöoikeuksien hallinta: Eniten käyttöoikeuksia omaava integraatiokäyttäjien malli, joka on kuvattu integraatiokuvioissa (vaikutusalueiden nimetyt tunnukset, agenttikohtaiset OAuth 2.0 -vaikutusalueet, yhdyskäytävän sallittujen luetteloiden luettelot), kartoitetaan suoraan loogisiin käyttöoikeuksien ohjaimiin. Ylläpidä todisteita siitä, että kunkin agentin tunnusten vaikutusalue on tarkastettu ja hyväksytty.

Tarkastusten kirjaaminen: Kuviokohtaiset kirjausvaatimukset (istunnon tunnus, työkalun kutsut, luottamuksellisista arvoista puhdistetut input-parametrit, lopputulokset) täyttävät valvonta- ja lokitoiminnot. Varmista, että lokit ovat vaarattomia, säilytetään vaaditun ajan ja että tietoturvatiimi voi käyttää niitä ilman, että tarvitsisi käyttöoikeutta tuotanto-järjestelmiin.

Muutosten hallinta: Kuluttajiin vaikuttavat MCP-työkalun skeeman muutokset ja A2A-agenttikorttien päivitykset ovat käyttöliittymän muutoksia, ja niiden tulisi olla muutostenhallinnan ohjainten alaisia. Versioi työkalut erikseen (mainittu MCP-saapuvan kuviossa) ja käsittele muutosten rikkoutumista hyväksyntää vaativina kokoonpanotapahtumina.

Käytettävyys: Agentin samanaikaiset rajoitukset, tapahtumien käynnistämien kuvioiden kokeilurajoitukset ja epäonnistuneiden tapahtumien dead-letter-reititys ovat käytettävyysasetuksia. Dokumentoi kunkin käyttöönotetun kuviokuvan odotettu läpimeno ja virheiden toimintatapa osana saatavuuden todennuspakettia.

Huomautus: Tämä luettelo ei ole täydellinen opas agenttien ratkaisujen vaatimustenmukaisuuden varmistamiseen. Kaikkien asiaankuuluvien lakisääteisten vaatimusten täytyy täyttyä.

• Agentin API:n käytön aloittaminen
• Luotettujen agenttien ottaminen käyttöön Data 360:lla
• MuleSoft Omni Gateway -sovelluksen yleiskatsaus
• OAuth 2.0 On-Demand Credential Injection Policy
• Agentin yrityksen luotettu agentin identiteetti

Gulal Kumar on Salesforcen ohjelmisto-arkkitehti, jolla on yli 20 vuoden kokemus. Hänen ammattitaitonsa kattaa tekoälyn, integraation, API-rajapintojen ja yritysarkkitehtuurin, ja keskittyy liiketoiminnan transformaation edistämiseen turvallisten, kestävien ja innovatiivisten tekoälyratkaisujen avulla. Ota yhteyttä häneen LinkedInissa.