Esittely

Huomautus: Tämän artikkelin aikana "aiheet" on nimetty "alagenteiksi" uusimpien tuotteiden nimeämiskäytäntöjemme mukaisesti.

Saatat rakentaa agentin, joka toimii hyvin testiympäristössä, jotta se voi seurata täysin eri reittejä käsitellessään samaa työnkulkua kahdesti. Tämä perusoikeus osoittaa, miten edellinen Agentforce käsitteli suorituksen: LLM teki kaikki päätökset reaaliajassa, tarkoitusten tulkinnasta toimintojen valintaan, eikä työnkulussa ole taattu polkua.

LLM:t voivat tuottaa epäjohdonmukaisia lopputuloksia vastauksena identtisiin syötteisiin. Yksinkertaiset variaatiot asiayhteydessä, järjestelmän kehotteet tai valtuuksien generointi riittävät lähettämään agentin toiselle reitille. Tämä muuttuja on hyväksyttävää monille vuorovaikutuksille. Monivaiheisia työnkulkuja, jotka vaativat auditointia, toistettavuutta ja jäljitettävyyttä, ei kuitenkaan ole. Lainan hyväksyntä, inventaarion siirto tai potilasluokitusprosessi eivät voi riippua agentista, joka perustelee vaiheet eri tavalla joka kerta.

Uusi Agentforce Builder ja Agent Script korjaavat tämän ongelman erottamalla deterministinen suoritus ja LLM-argumentaatio. Agentforcen hybridimalli varmistaa, että agentti noudattaa tarkasti määritettyä rakennetta jokaiselle työnkulun suoritukselle, mutta käyttää silti LLM-perusteluita, kun oikeasti tarvitaan tuomiota, luonnollisen kielen ymmärrystä tai asiayhteydestä johtuvaa tulkintaa.

Agentforcen aiemmassa versiossa agentti toimi yksinkertaisena reagoivana silmukkana. LLM teki jokaisen päätöksen reaaliajassa, tarkoituksen tulkinnasta seuraavan toiminnon valitsemiseen, perustuen vain käyttäjän viimeisimpiin tietoihin. Ei ollut taattua suorituspolkua, pysyvää tilaa tai mekanismia vaiheiden sarjan noudattamiseksi.

Suorituspolkuja ei voitu taata

Koska jokainen päätös riippui LLM:n reaaliaikaisesta perustelusta, pienet eroavaisuudet syötteessä, järjestelmäkehotteessa tai malliversiossa johtivat eri toimintovalintoihin identtisille pyynnöille. Tämän vuoksi edellisen mallin testaaminen oli vaikeaa: Vaiheittainen työnkulku saattaa toimia eri tavalla tuotantoympäristössä, eikä tiettyä suorituspolkua voi luotettavasti toistaa virheenkorjausta tai auditointia varten.

Jokainen vuorovaikutus maksoi LLM:n täyden hinnan

Jopa yksinkertaiset selkokieliset skenaariot vaativat vähintään kolme LLM-sykliä: agentin valinta, toiminnon valinta ja lopullisen vastauksen generointi. Monivaiheiset tehtävät, jotka on laajennettu viiteen tai useampaan sykliin. Jos arkkitehti suunnittelee raskaita tai viiveestä riippuvaisia työnkulkuja, tämä ei ollut vain suorituskykyyn liittyvä huolenaihe. Se tarkoitti, ettet voinut lyhentää päättelyylä vaiheille, jotka eivät vaativat arviointia, koska arkkitehtuurilla ei ollut mekanismia niiden erottamiseksi toisistaan.

Ei-deterministinen suoritus loi tarkastuksen aukon

Säänneltyjen toimialojen auditointi tarkoittaa, että voit osoittaa, että tiettyä prosessia seurattiin tietyllä tavalla tietylle transaktiolle. Puhtaasti ei-deterministinen malli ei voi tarjota tätä takuuta. Jos suorituspolku vaihtelee suorituskertojen välillä, myös kirjausketju vaihtelee, ja "agentti päätti" ei ole puolustettava vastaus vaatimustenmukaisuuden tarkastuksessa.

Tila ei selvinnyt keskustelusta

Yksittäisen vaiheen käsittelyyn luottaminen tarkoitti, ettei agentilla olisi pysyvää muistia aiemmista vaiheista. Jos keskustelu poikkeaa hieman, agentti saattaa pudottaa aiemmin kaapatun asiayhteyden ja pakottaa käyttäjän aloittamaan uudelleen. Tämä loi luotettavuusrajan monivaiheisille transaktioiden työnkuluille: Mitä useampia vaiheita prosessissa on, sitä todennäköisemmin asiayhteys häviää ennen sen suorittamista.

Valmistettuja vaiheita ei muistettu

Ilman osavaltion hallintaa agenteilla ei olisi tietueita käyttäjän jo suorittamista pakollisista vaiheista. Tämä tuotti odottamattoman silmukan, jossa agentti palasi vaiheeseen, jonka käyttäjä oli jo suorittanut. Tämä aiheutti käyttäjäkokemuksen vaikutuksen lisäksi syvällisemmän arkkitehtuurin ongelman: luotettavan järjestyksellisen työnkulun suunnitteleminen oli mahdotonta, koska agentti ei voinut noudattaa järjestystä.

Uusi Agentforce, GA helmikuusta 2026, siirtyy pelkästään todennäköisyyksiin perustuvasta LLM-perusteesta hybridimalliin. Sen sijaan, että se reitittäisi kaikki päätökset LLM:n kautta, se erottaa deterministisen suorituksen LLM:n perustelusta ja sallii kunkin käsitellä vain sen, mihin se sopii. Agentforce on ottanut käyttöön kaksi artikkelityökalua: Agent Script koodiin perustuvaan kehitykseen ja Agentforce Studioon, joka on ilman koodia luova ympäristö.

Agentforce Builder

Agentforce Builder on suositeltu ympäristö uusien agenttien kehittämiseen. Se isännöidään Agentforce Studiossa ja korvaa vanhan määritystoiminnon, joka on edelleen käytettävissä, mutta joka ei ole enää ensisijainen kirjoituspolku. Rakentajassa työskentelet joko visuaalisessa esitysalueen näkymässä tai suoraan komentosarjan näkymässä, muokkaamalla agentin komentosarjaa, joka määrittää agenttisi toimintatavan.

Agentin komentosarja

Agenttikomentosarja on deklaratiivinen toimialuekohtainen kieli (DSL), joka määrittää kaiken siitä, miten agentti käyttäytyy: sen kokoonpano, liiketoimintalogiikka ja kehote. Se on rakennettu avain-arvo-parina, jotka voivat kattaa useita rivejä tai sisältää sisäkkäisiä alaominaisuuksia, ja se on suunniteltu selkokieliseksi ilman, että sen perustana olevaa kaavion arkkitehtuuria tarvitaan Knowledgea.

Agenttikomentosarja sallii sinun ilmaista samassa agentissa kahdentyyppisiä ohjeita: deterministisen logiikan ohjeet ja kehotteiden ohjeet. Deterministisen logiikan ohjeet määrittävät ehdot ja toimintojen järjestykset, jotka suoritetaan koodina ilman LLM-osallistumista. Kehotteiden ohjeet määrittävät luonnollisen kielen ohjeet, joita LLM tulkitsee suorituksen aikana. Näiden kahden välinen raja on selkeä ja tarkoituksenmukainen, ja rajan asettamisen ymmärtäminen on yksi tärkeimmistä suunnittelupäätöksistä, joita teet, kun rakennat uuden Agentforcen kanssa.

Deterministinen logiikka käytännössä

Kun ohjeet ovat deterministisiä, agentti noudattaa määritettyä suorituspolkua riippumatta siitä, miten käyttäjä laatii syöttämiään tietoja. Alla oleva esimerkki näyttää alitason agentin, joka lataa Älykkäät asiakastiedot -mittariston. Se tarkastaa asiakastunnuksen, noutaa profiilitiedot, tilaushistorian ja tukiliput ja laskee sitten asiakkaan elinkaaren arvon ja häiriöriskin. Mikään näistä vaiheista ei vaadi LLM-argumentaatiota.

Tämä logiikka kutsuu toimintoja kiinteässä järjestyksessä joka kerta, kun tietyt ehdot täyttyvät.

Kehotteiden ohjeet ja LLM:n tarkoituksellinen siirto

Kun deterministinen logiikka käsittelee ehtoja ja järjestyksiä, jotka voidaan ilmaista koodina, kehotteiden ohjeet käsittelevät kaiken, mikä vaatii arviointia, tulkintaa tai luonnollisen kielen luomista. Kun Atlas Reasoning Engine kohtaa noodin, joka sisältää kehotteen ohjeita, se käynnistää LLM-kutsun. Kun se ei toimi, se suoritetaan deterministisesti.

Alla oleva esimerkki näyttää tuotteiden ja palveluiden alitason agentin. Ohjeet ovat monirivisiä kehotteita, jotka kertovat LLM:lle, miten vastata, milloin hakea tietoja ja miten käsitellä epäselvyyttä. Tämä on oikea malli, kun mahdollisten käyttäjien syöttämien tietojen määrä on liian laaja ennustettavaksi ehdollisella logiikalla tai kun vastauksen laatu riippuu LLM:n kyvystä tulkita kontekstia ja luoda luonnollinen vastaus.

Noodin kehotteiden ohjeet käynnistävät LLM-kutsun. Tämä ei ole satunnaista — se on mekanismi, jolla Agent Script tekee LLM-rajasta selkeän ja pakotettavan sen sijaan, että se jätettäisiin suorituksen aikaiseen päätelmään.

Tämä alaagentti näyttää deterministisen logiikan ja LLM-toiminnon toiminnassa.

Kolmen vaiheen suoritusputki

Agentforce Builder ja Agent Script ovat kirjoituskerros, mutta agenttikaavio ja Atlas Reasoning Engine suorittavat agenttisi. Kumpikaan näistä komponenteista ei ole suunnitelmallisesti suoraan käytettävissäsi. Kirjoittamisen ja suorituksen erottaminen toisistaan sallii sovellusalustan noudattaa determinististä toimintatapaa riippumatta komentosarjan kirjoittamisesta.

Myyntiputki käy läpi kolme vaihetta.

1. Sinä työskentelet kirjoituksessa. Agenttikomentosarja on ihmiselle luettavissa ja sitä voi muokata joko esitysalueen tai komentosarjan näkymässä Agentforce Builderissa. Tämä on ainoa kerros, jonka kanssa vuorovaikutat suoraan.
2. Kokoonpano tekee Salesforce-kokoonpanosta agenttikomentosarjasi agenttikaavioksi, joka on sarjanumeroitu suoritussuunnitelma, joka on optimoitu koneelliselle suoritukselle eikä ihmiselle. Et tee virheenkorjausta tässä kerroksessa. Kokoonpano tuottaa esityksen, jonka suorituksen aika voi selata tehokkaasti.
3. Atlas Reasoning Engine ottaa käyttöön suorituksen aikaisen suorituksen. Se lukee agenttikaavion, siirtyy sen läpi istunnon tämänhetkisen tilan perusteella ja päättää kussakin noodissa, suoritetaanko se deterministisesti vai kutsutaanko LLM:ää. Järjestelmä noudattaa suojalausekkeita ja ehdollista reititystä erikseen tässä, eikä sitä.

Agentin kaavio

Agentin kaavio on väliaikainen esitys, joka sijaitsee ihmiselle luettavan komentosarjan ja todellisen suorituksen aikaisen suorituksen välillä. Sen rakenne on optimoitu sen kuluttavalle osavaltion koneelle, ei komentosarjan tekijälle. Sen olemassaolon ja sen edustamisen ymmärtäminen on tärkeää, koska se on esine, jota Reasoning Engine käyttää komentosarjan määrittämän suoritussuunnitelman toteuttamiseen.

Atlas-luonnostelujärjestelmä

Atlas Reasoning Engine on osavaltion kone-suoritin. Joka kerta se ylittää agenttikaavion istunnon tilan perusteella, suorittaa deterministisiä noodeja koodina ja käynnistää LLM-kutsuja vain, kun kehotteen ohjeet ovat esillä. Se käyttää myös suojalausekkeita ja käsittelee ehdollisen reitityksen. Reasoning Engine on paikka, jossa hybridimallin perustelu toteutetaan. Komentosarja määrittää rajan ja järjestelmä kunnioittaa sitä.

Agentin kaavio ei ole LLM-pakkaus. Se on hybridimuotoinen päättelyjärjestelmä, joka erottaa deterministisen suorituksen todennäköisyyksiin perustuvasta päättelystä. Sääntö on yksinkertainen: Jos voit ilmaista päätöksen koodina, se tulisi kirjoittaa logiikaksi. Jos päätös vaatii tuomiota, tulkintaa tai luonnollisen kielen luomista, LLM:n tulisi käsitellä se. Tämä suunnittelupäätös on tärkein uuden Agentforce arkkitehtuurivaihtoehto. Missä LLM-raja laskee vaikuttaa suoraan ratkaisusi kustannuksiin, viiveeseen, auditoitavuuteen ja luotettavuuteen.

Atlas Reasoning Engine arvioi jokaisen saapuvan käyttäjän käännöksen ja reitittää sen yhteen kahdesta polusta.

Polku A: deterministinen suoritus

Tällä polulla ei ole LLM-rajoitusta. Se toimii kuin koodikoodi suorituksen aikana. Reasoning Engine luokittelee käyttäjän tarkoituksen ja määrittää, että looginen ohje täsmää, ohittaen LLM:n kokonaan. Yhdistetty agenttikomentosarja suoritetaan ylhäältä alas, ja if-else-säännöt suoritetaan ehdottomasti joka kerta. Kulkutoimintoja, Apex- tai API-toimintoja kutsutaan deterministisillä parametreillä, eikä kehotteiden kokoonpanoa tai mallin kutsuja. Tulos välitetään takaisin Trust läpi ja täysi kirjaus kirjaa.

Polku B: LLM:n perustelut

Reasoning Engine käyttää tätä polkua, kun se ei voi ratkaista tarkoitusta käyttämällä vain loogisia ohjeita. Se ylittää agenttikaavion ja arvioi kunkin noodin. Kehotteita sisältävät noodit käynnistävät LLM-kutsun. Noodit, joilla ei ole niitä, suoritetaan deterministisesti. Kehotteen ohjeen läsnäolo on käynnistin, ja se näytetään erikseen komentosarjassa sen sijaan, että se päätettäisiin suorituksen aikana.

Mikä käynnistää LLM-kutsun?

Suorituksen elinkaaressa on kahdeksan kohtaa, joissa LLM-ohjelma kutsutaan. Alitason agentin luokittelu tai päättää, mikä alitason agentti vastaa käyttäjän pyyntöä, on yksi, vaikka lyhytyhteyden polku voi ohittaa täyden LLM-kutsun, kun luokitus on yksiselitteinen. Agentin päättely, jossa agentti päättää, mitä tehdä seuraavaksi, käy aina läpi LLM:n. Sama koskee vastausten generointia, jossa lopullinen vastaus kerätään hydratusta kehotteesta.

Muut käynnistimet toimivat paremmin: perustason vahvistus vahvistaa, että tulos perustuu haettuun dataan; toimintojen simulointi emuloi vastauksia Esikatsele- ja Simuloi-ympäristössä suorittamisen sijaan live-tilassa; rakenteellinen tulosten generointi käsittelee tapaukset, joissa vastauksen täytyy noudattaa määritettyä skeemaa; ja lokalisoinnin ja edistymisen osoittimen generoinnin käsittelymuotoilu ja väliaikainen viestintä, kun esimääritettyä oletusasetusta ei ole olemassa.

Mikä pysyy deterministisenä

Kaavion ylitys ja tilojen muutokset eivät koskaan sisällä LLM:ää. before_reasoning- ja after_reasoning-elinkaarilohkot suoritetaan deterministisesti, kunhan ne sisältävät vain toimintonoodien, joilla ei ole kehotteita. Matemaattinen, datan noutaminen, vahvistus ja ehdollinen logiikka kuuluvat kaikki koodiin. Kaikki toiminnot, jotka suorittavat kulun, Apexin tai REST API:n suoraan, pysyvät deterministisessä polussa. Mikä tahansa noodi, jolla ei ole kehotteita, suoritetaan ilman LLM-kutsuja.

Tämän rajoituksen selittäminen tiimillesi on tärkeää. Jokainen tarpeeton LLM-kutsu lisää viiveen, kustannuksen ja vaihtelevuuden. Arkkitehtien tulisi käyttää determinististä logiikkaa oletusarvoisesti ja varata LLM tapauksille, joissa tehtävä todella vaatii sen päättelykyvyn.

Suunnittelua koskevia ohjeita: työntölogiikkaa koodiin oletusarvoisesti

Käytä agenttikomentosarjan logiikkaa, kun kirjoitat kehotteiden ohjeita, jotka voidaan ilmaista ehdona, muuttujan kohdistuksena tai toimintosuodattimena. Jokainen tarpeeton LLM-kutsu lisää viiveen, kustannuksen ja vaihtelevuuden.

Oletusarvoisen sijainnin tulisi olla deterministinen. Eristää kaikki agenttien toimintatavat, jotka voidaan koodata sääntönä, ja siirtää ne agenttien komentosarjaan. Muut tehtävät, jotka vaativat luonnollisen kielen synteesiä, asiayhteydestä johtuvaa arviointia tai monimutkaista tulkintaa, kuuluvat kehotteita sisältäviin noodeihin. Tämä ei ole rajoitus, vaan rajat toimivat odotetulla tavalla. LLM käsittelee, mihin se sopii parhaiten, ja kaikki muu suoritetaan koodina.

Agentin komentosarjan ensisijainen suoritusyksikkö ei ole käyttäjän muutos. Se on jäsentä: yksi täysi sykli alitason agentin kolmen elinkaaren lohkojen läpi. Atlas Reasoning Engine käynnistää jäsentämisen joka kerta, kun alitason agentin täytyy käsitellä jotain, mikä tapahtuu kolmessa tilanteessa: ensimmäisellä sisäänkirjautumisella alagenttiin, jokaisen työkalupuhelun jälkeen, kun toiminto suoritetaan loppuun ja palauttaa tuloksen, ja jokaisella uudella käyttäjällä, joka siirtyy samaan alagenttiin.

Jäsentämisen rajojen ymmärtäminen on tärkeää, koska se määrittää, montako kertaa kukin lohko suoritetaan, ja siksi missä voit ja et voi luottaa tietyn logiikan osan suorittamiseen tarkalleen kerran.

Jokainen alaagentti määrittää kolme suoritusvyöhykettä:

Sekä before_reasoning että after_reasoning ovat täysin deterministisiä. He suorittavat toimintoja, määrittävät muuttujia ja käyttävät ehdollista logiikkaa käyttämättä LLM:ää. Tämä tekee niistä luotettavia ja edullisia lohkoja komentosarjassa.

Milloin käyttää before_reasoning

before_reasoning suoritetaan jokaisen jakson alussa poikkeuksetta. Se suoritetaan alitason agenttiin syötettäessä ensimmäistä kertaa ja uudelleen jokaisen työkalupuhelun tai uuden käyttäjän muutoksen jälkeen. run @actions.X before_reasoning on koodi. Toisin kuin kehotteen lohkossa oleva ohje, jota LLM voi noudattaa tai ei, before_reasoning suoritetaan ehdottomasti.

Käytä tätä lohkoa istunnon käynnistämiseen: kontekstien tietueiden noutaminen, istuntojen muuttujien määrittäminen Apexista tai kulusta. Se kuuluu myös todennus- ja oikeutustarkistuksiin, koska haluat vahvistaa ne ennen kuin LLM näkee työkaluja. Kontekstihydraatio soveltuu myös tähän: datan noutotoiminnon kutsuminen, jotta LLM vastaanottaa esimääritettyjä muuttujia sen sijaan, että sinun täytyisi pyytää niitä. Kaikki laskuri- tai auditointimuuttujat, jotka täytyy lisätä jokaiselle jaksolle, tulisi määrittää tässä, koska set-direktiivi before_reasoning on taattu tavalla, jota myyntiputken ohje ei ole.

Tämä ei sisällä logiikkaa, joka tulisi suorittaa vain kerran istunnossa, koska before_reasoning suoritetaan jokaiselle jaksolle eikä vain ensimmäiselle merkinnälle. Kaikki tämänhetkisestä kierroksesta syötettyihin tietoihin perustuvat tiedot eivät kuulu tähän, koska niitä ei ole vielä käsitelty. Siirtojen ei tulisi olla koskaan before_reasoning: Alla oleva transition to-ohje käynnistää ehdottomasti jokaisen jakson ja luo silmukoita.

Jos tarvitset kerran istunnossa aloitusta, säilytä se erikseen:

Yksi käyttäjätoiminto voi käynnistää useita jäseniä: kerran syötettäessä ja sitten uudelleen jokaisen työkalupuhelun jälkeen. Tällä ominaisuudella on kolme käytännön seurausta: before_reasoning-objektin alustustoiminnot suoritetaan useammin kuin kerran per käyttäjä siirtyy usean toiminnon kulkuun, tässä lasketut laskumuuttujat vastaavat jäsenten määrää, eivät kääntöjen määrää, ja toimintoja, joilla on sivuvaikutuksia, ulkoisia API-kutsuja tai tietueiden kirjoituksia, ei tulisi käyttää before_reasoning-objekteina, ellei jokaisen jäsenten uudelleen suorittamista hyväksytä erikseen.

before_reasoning ei ole rakentaja. Se on lentoa edeltävä tarkastus, joka suoritetaan jokaisella jaksolla. Suunnittele se asianmukaisesti.

Milloin käyttää after_reasoning

after_reasoning suoritetaan, kun perustelusilmukka on valmis, kun LLM on vastannut ja toiminnon tulokset on kerätty. Toimintojen jälkeiset deterministiset tarkistukset kuuluvat tähän: toimintojen tulosten ja haarautumisen arviointi tulosten perusteella. Deterministiset siirtymät tai siirtyminen seuraavaan alitason agenttiin muuttujan tilan perusteella LLM-arvojen sijaan, istu tässä. Tämä koskee myös muuttujien siivousta ennen seuraavaa kierrosta ja orkestroinnin järjestystä, kun sinun täytyy ketjuttaa alitason agentteja ennustettavassa järjestyksessä ilman LLM-reitityspäätöstä.

Käsittele after_reasoning-kuvaketta suojakerroksena. Siellä noudatat liiketoimintasääntöjä ja osavaltion hallintaa, kun LLM on tehnyt työnsä, varmistaaksesi, että kriittiset prosessikulut pysyvät ennustettavina riippumatta siitä, mitä LLM tuotti.

Käytä is_displayable: True älykkäästi

Jokaisen orkestrointikulkujen suunnittelijan täytyy ymmärtää tämä sovellusalustan toimintatapa. Kun toiminnolle on määritetty is_displayable: True, sovellusalusta poistuu perustelukulusta heti, kun LLM päättää näyttää kyseisen tuloksen. Tämä poistuminen tapahtuu välittömästi, eli after_reasoning ei suorita koskaan.

Tämä on tunnettu sovellusalustan toimintatapa, mutta sillä on suora vaikutus orkestrointiin: Kaikki after_reasoning-muotoon lisäämäsi logiikat ohitetaan, kun näytettävä toiminto on osana kulkua.

Vastaus on yksinkertainen. Siirrä logiikkaa, jonka täytyy suorittaa luotettavasti seuraavan alagentin before_reasoning-lohkoon nykyisen after_reasoning-lohkon sijaan.

Suunnittelua koskevia ohjeita: mihin sijoittaa alustuslogiikkaa

Logiikan asettamisen määrittäminen on tärkeää, kun suunnittelet alitason agenttia. Tämä kehys kattaa yleisimmät skenaariot:

Perusperiaate on yksinkertainen. Kun kirjoitat kehotteen ohjeeksi, joka käskee LLM:ää "suorittamaan aina" toiminnon, se on ehdotus. LLM voi seurata sitä tai ei, riippuen asiayhteydestä. Kun asetat run-direktiivin muotoon before_reasoning, se on koodi. Se suoritetaan jokaiselle jaksolle poikkeuksetta.

Ehdollinen toimintojen saatavuus on mekanismi, jolla agenttikomentosarja paljastaa tai piilottaa toimintoja LLM:stä suorituksen aikaisen muuttujan tilan perusteella. Kun available when-ehto palauttaa arvon false, toiminto poistetaan kokonaan LLM:lle esiteltävästä työkaluiden luettelosta. Mikä tahansa epätosiarvo, mukaan lukien None, False, 0 tai tyhjä merkkijono, estää toiminnon.

Tämä ei ole kehote-ohje, joka käskee LLM:tä "älä kutsu tätä vielä", se on sovellusalustan tason kova portti. LLM ei voi kutsua toimintoa, jota se ei voi käyttää.

Tässä esimerkissä execute_transfer ei ole näkyvissä LLM:ssä ennen kuin validation_passed palauttaa arvon true. Portaali noudatetaan sovellusalustan toimesta, ei ohjeiden perusteella.

Suunnittelua koskevia ohjeita: älä koskaan salli LLM:n määrittää porttimuuttujaa

Anna jokaiselle available when-lausekkeen muuttujalle deterministinen koodipolku, joka määrittää muuttujan ennen siihen liittyvän toiminnon suorittamista. Käytä before_reasoning-arvoa tai determinististä run ja set-lohkoa reasoning-arvoa pitääksesi muuttujan tunnetussa tilassa. Jos luotat LLM:ään määrittääksesi porttimuuttujan, olet ottanut portin estämiseksi suunnitelun muuttuvuuden uudelleen käyttöön. Riippuen keskustelusta, LLM voi määrittää sen tai ei, mikä tarkoittaa, että portti voidaan avata tai ei.

Toiminnon silmukan ongelma

Toimintosilmukka tapahtuu, kun LLM kutsuu samaa toimintoa toistuvasti saavuttamatta koskaan lopullista tilaa. Se tapahtuu, kun kaksi ehtoa täyttyvät samanaikaisesti: available when-ehto pysyy tyytyväisenä toiminnon suorittamisen jälkeen, eikä johdanto-ohjeissa sanota suoraan LLM:lle, että se lopettaisi sen kutsumisen.

Sovellusalusta ei estä toimintoa automaattisesti sen kutsumisen jälkeen. Jos portti pysyy avoinna ja perustelun ohjeet ovat epäselviä, LLM kutsuu samaa toimintoa jokaiselle jaksolle määrittämättömästi.

Kuvittele esimerkiksi available when @variables.interest != "". Jos toiminto suoritetaan, mutta mielenkiinnon muuttuja ei ole tyhjä, portti pysyy avoinna seuraavalla jaksolla. LLM näkee toiminnon käytettävissä olevana, sillä ei ole ohjeita sen lopettamiseen ja kutsuu sitä uudelleen.

Silmukan rikkomiseen on kaksi luotettavaa tapaa. Ensimmäinen on määrittää porttimuuttujan suljetuksi tilaksi osana toiminnon suorituksen jälkeistä logiikkaa, jotta se available when palauttaa arvon seuraavalla jaksolla.false Toinen tapa on käyttää erillistä has_run-totuusarvoa, joka sulkee portin ensimmäisen suorituksen jälkeen. Molemmat lähestymistavat antavat portille deterministisen suljetun tilan, joka on ehto, jota sovellusalusta tarvitsee toiminnon estämiseksi.

Pankkisiirto on hyödyllinen linssi ymmärtääksesi, miten nämä kuviot toimivat yhdessä käytännössä. Työnkulku näyttää yksinkertaiselta ulkoisesti: siirtää rahaa tilistä toiseen. Toteutus vaatii useita monimutkaisia vaiheita. Ennen kuin siirto suoritetaan, agentin täytyy kerätä tilin lisätiedot, vahvistaa summa, tarkastaa siirron rajoitukset, vahvistaa saatavilla oleva saldo ja paljastaa siirto-toiminto vasta sitten. Jokainen vaihe riippuu edellisistä vaiheista. Yhtään niistä ei tulisi jättää LLM-arviointiin.

Kokoele ja vahvista syötettyjä tietoja

Ensimmäinen alagentti kerää lähdetilin, kohdetilin ja siirron summan käyttäjältä. Se ei jatka ennen kuin kaikki kolme ovat voimassa. Agenttikomentosarja tarkastaa kunkin kentän järjestyksessä: jos lähdetili puuttuu, se kysyy. Jos kohde puuttuu, se kysyy. Jos summa on nolla tai negatiivinen, se kysyy. validation_passed-muuttujaksi määritetään vain true, kun kaikki tarkistukset on suoritettu.

Alla oleva komentosarja näyttää tämän käytännössä. Huomaa, että validation_passed on määritetty erikseen jokaisen epäonnistumisajankohdan false-arvoksi, ja LLM-ohjelmalla on ohjeita olla jatkamatta. Deterministiset tarkastukset suoritetaan ehdottomasti, kun taas kehotteiden ohjeet käsittelevät käyttäjän vastauksen.

Käytä liiketoimintasääntöjä

Kun agentti on vahvistanut syötetyt tiedot, se tarkastaa, ylittääkö siirron summa määritetyn siirron rajoituksen. Näin liiketoimintasäännöt muuttuvat koodiksi ohjeiden sijaan. Rajoitus ei ole jokin LLM:n perusteluista; se on kestävä kynnysarvo, joka on määritetty komentosarjassa ja joka tarkistetaan deterministisesti jokaisessa lausekkeessa.

Jos summa ylittää rajoituksen, validation_passed palautuu arvoon false ja LLM tarjoaa käyttäjälle kolme vaihtoehtoa: siirrä sallittu enimmäismäärä, jaa useisiin siirtoihin tai ota yhteyttä tukeen saadaksesi enemmän rajoituksia. Agentti ei voi jatkaa ennen kuin käyttäjä ratkaisee poikkeuksen. Huomaa, miten tämä kehotteen ohje toimii juuri siihen, mihin LLM-argumentaatio soveltuu: vaihtoehtojen esittäminen selkokielisesti ja käyttäjän vastauksen käsittely. Liiketoimintasääntö itsessään on deterministinen, mutta sen ympärillä oleva keskustelu ei.

Alla oleva komentosarja osoittaa, miten rajoituksen tarkastus toimii. Deterministinen ehto arvioi siirron summan rajoitusmuuttujaan nähden, määrittää validation_passed false-arvoksi, jos kynnysarvoa ei noudateta, ja delegoi kehotteen ohjeeksi käyttäjän vastauksen käsittelemiseksi.

Käytä suojalausekkeita

Kun summa- ja rajoitustarkistukset on suoritettu, agentti noutaa lähdetilin saldon ja vahvistaa, että saatavilla on riittävästi varoja. Valvonta-lausekkeet estävät agenttia yrittämästä toimintoja, kun edellytykset eivät täyty. Toisin kuin kehotteen ohje, joka käskee LLM:ää tarkastamaan saldon, agenttikirjoituksen suojalauseke tekee tarkastuksesta ehdottoman. LLM ei päätä, suoritetaanko se.

Jos saldo on riittämätön, agentti laskee puutteen ja tarjoaa käyttäjälle konkreettisen vaihtoehdon. validation_passed on määritetty arvoon false, kunnes tämä tarkastus läpäistään, mikä tarkoittaa, että siirtotoiminto pysyy suljettuina.

Alla oleva komentosarja näyttää deterministisen toimintokutsun, joka noutaa tasapainon, ja sen jälkeen ehdollisen tarkastuksen, joka arvioi sen. Nouto suoritetaan vain, jos saldoa ei ole vielä noudettu, jolloin vältetään tarpeettomia API-kutsuja myöhemmissä jäsenteissä.

Pintavirheet selkeästi

Valvonta-lausekkeet määrittävät osavaltion. Virheviestit ilmoittavat siitä. Kun validation_passed on false, agentin täytyy antaa käyttäjälle tarpeeksi tietoja ongelman ratkaisemiseksi ilman uudelleenkäynnistystä. Epätarkat virheviestit aiheuttavat jännitystä. Rakenteelliset viestit sulkevat silmukan nopeammin.

Alla oleva komentosarja näyttää riittämättömien varojen virheviestin käytännössä. Se ei vain kerro käyttäjälle, että siirto epäonnistui. Se näyttää käytettävissä olevan saldon, pyydetyn summan, lasketun puutteen ja tarjoaa konkreettisen seuraavan vaiheen, joka on koottu istuntojen muuttujista, eikä LLM:n luomista muuttujista.

Puutteiden laskenta tapahtuu komentosarjassa, ei LLM:ssä. Ehdotettu vaihtoehto, joka siirtää käytettävissä olevan saldon, saadaan deterministisesti istunnon tilasta. LLM:n rooli tässä on pelkkää esitelmää: se tarjoaa viestin, jonka komentosarja on jo rakentanut.

Lähetä siirto-toiminto portille

Jokainen edellisten vaiheiden vahvistustarkistus määrittää tai tyhjentää saman muuttujan: validation_passed. Tämä muuttuja tekee nyt tärkeintä työtään. execute_transfer-toiminto on ehdollisesti käytettävissä, eli se näytetään LLM:n työkaluiden luettelossa vain, kun validation_passed on true. Toimintoa ei ole olemassa LLM:n näkökulmasta ennen kuin jokainen edellinen tarkastus on läpäissyt ja määrittänyt kyseisen muuttujan.

Tämä on kuvio aiemmasta porttiosiosta, jota sovellettiin tuotantotyönkulkuun. Kehotteen ohje ei piilota siirto-toimintoa. Sovellusalusta piilottaa sen. Mikään selkokielinen painostus tai epäselvä lause ei voi aiheuttaa sitä, että LLM kutsuu sitä ennen kuin edellytykset täyttyvät.

Alla oleva komentosarja näyttää, miten portti on määritetty. available when-klausuuli viittaa suoraan validation_passed-toimintoon, ja toimintoparametrit ovat sidoksissa edellisissä vaiheissa kerättyihin ja vahvistettuihin istuntomuuttujiin.

Kaikki kolme parametriä, from_account, to_account ja amount, välitetään deterministisesti istuntomuuttujista. Kun tämä toiminto on käytettävissä, kaikki arvot on vahvistettu. LLM ei kerää parametrejä keskustelun asiayhteydestä, vaan lukee ne tilasta.

Seuraa tilaa työnkulussa

Edellisten osioiden kuviot toimivat vain, koska istuntotila säilyy koko työnkulussa. Ensimmäisessä vaiheessa kerätyt tilinumerot ovat käytettävissä neljännessä vaiheessa. Vahvistuksen tulokset määritetään yhden tarkastusportaalin toiminnoissa toisessa. Keskustelu voi poiketa, käyttäjä voi esittää jatkokysymyksiä, ja agentti tietää silti tarkalleen, missä hän on prosessissa.

Alla oleva muuttujalohko näyttää tämän työnkulun täyden istuntotilan. Jokaisella muuttujalla on määritetty tyyppi, oletusarvo ja kuvaus. Kaksi muuttujaa käsittelevät suurimman osan orkestrointityöstä: validation_passed hallitsee toimintojen saatavuutta jokaisessa portissa ja validation_information sisältää ihmiselle luettavissa olevan asiayhteyden tarkastuksen epäonnistumisesta, jonka LLM voi näyttää käyttäjälle ilman, että hänen täytyisi perustella sen perustana olevaa tilaa.

Jokainen muuttuja alkaa tunnetulla oletustilalla. Merkkijono on oletusarvoisesti tyhjä, numero on nolla ja validation_passed totuusarvo on false. Tämä tarkoittaa, että portti on oletusarvoisesti suljettu. Työnkulun täytyy aktiivisesti ansaita oikeus jatkaa jokaisessa vaiheessa sen sijaan, että se aloittaisi portin avaamisen ja luottaisi tarkastuksiin sen sulkemiseksi.

Pankkisiirto-esimerkki osoittaa, missä deterministinen logiikka on oikea työkalu, mutta se ei ole aina paras vaihtoehto. Rajojen ymmärtäminen on yhtä tärkeää kuin kuviot.

Deterministinen logiikka on oikea valinta, kun työnkulku vaatii taatun suoritusjärjestyksen, kun virheillä on merkittäviä seurauksia, kun prosessin täytyy tuottaa toistettava kirjausketju tai kun liiketoimintasäännöt on määritetty riittävän hyvin, jotta ne voidaan ilmaista ehdoina ja kynnysarvoina. Rahoitus-, terveydenhuolto- ja vakuutustyönkulut kuuluvat yleensä tähän luokkaan.

Puhdas LLM-peruste ilman tiukkoja deterministisiä rajoituksia on järkevämpää, kun vuorovaikutuksen arvo perustuu joustavuuteen eikä tarkkuuteen. Avoin asiakaspalvelu, alkuvaiheiset tuotteet, joissa liiketoimintaprosessit ovat vielä kehittymässä, ja vähäisen panoksen tiedotuskyselyt ovat kaikki tapauksia, joissa LLM-argumenttien vaihtelevuus on ominaisuus, ei ongelma.

Käytännössä useimmat tuotanto-agentit tarvitsevat molempia. Rajoituksen raja-arvo ei ole deterministinen tai todennäköisyyksiin perustuva binäärivaihtoehto. Se on suunnittelupäätös, jonka teet nooditasolla agenttiesi työnkulun jokaiselle osalle.

Rajoitus on suunnittelupäätöksenteko

Esimerkki pankkisiirrosta on esimerkki suunnittelufilosofiasta: että deterministisen suorituksen ja LLM-argumentaation välinen raja on tärkein arkkitehtoninen päätös, jonka teet luodessasi tuotanto-agenttia.

Aseta liian jäykkä rajoitus, niin saatat löytää agentin, joka on jäykkä, kallis ylläpitää ja ei kykene käsittelemään todellisten keskusteluiden luonnollista variaatiota. Jos raja on väärässä toisessa suunnassa, agentti on joustava mutta ei-ennustettava, toimii hyvin testauksessa, mutta käyttäytyy eri tavalla tuotantoympäristössä, eikä hän voi tuottaa luotettavaa kirjausketjua tai luottaa korkean panoksen transaktioon.

Uusi Agentforce tarjoaa sinulle työkalut rajoituksen asettamiseen tarkoituksella. Agenttikomentosarja sallii sinun ilmaista determinististä logiikkaa ja kehotteiden ohjeita samassa tiedostossa, ja antaa selkeän syntaksin, joka näyttää rajan. Atlas Reasoning Engine noudattaa logiikkaa ja kehotteita suorituksen aikana. before_reasoning- ja after_reasoning-lohkot tarjoavat sinulle taattuja suoritusvyöhykkeitä LLM-kutsun molemmilla puolilla. Ehdollisten toimintojen saatavuus varmistaa, että LLM voi toimia vain, kun edellytykset täyttyvät.

Mikään näistä ominaisuuksista ei ole erillään. He työskentelevät yhdessä luodakseen yhdenmukaisen arkkitehtuurin agenttien rakentamiseksi, johon yritykset voivat Trust missioniin perustuvien työnkulkujen avulla. Hybridimuotoinen perustelumalli tunnistaa, että sekä deterministisellä että joustavalla toiminnolla on rooleja arkkitehtuurissasi. Arkkitehtien tehtävänä on päättää tarkalleen, mihin niitä sovelletaan.

Agentin komentosarjareseptit

Agentforce Developer Guide

Agentforcen agenttikaavio: Opastetulle deterministisyydelle hybridisellä perustelulla

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.

Miriam McCabe on johtaja ja Arkkitehti Evangelism -tiimin johtaja. Hänen työnsä keskittyy sallimaan globaalin Salesforce-arkkitehtuuriyhteisön johtaa agenttien aikaa syvällisen teknisen sisällön, live-ohjelmoinnin ja yhteisön osallistumisen avulla. Seuraa häntä LinkedInissa.