Design underagenter som unngår dupliserte meldinger

Note

Denne artikkelen beskriver egenskapene og oppførselen til standardselen. Lær hvordan du får tilgang til standardfunksjoner i Access standardagenter og agentflyter.

Dupliserte meldinger kommer fra konteksthull. Agentdesign må ta hensyn til kontekst i hvert steg.

En underagent, enten en barneagent eller en tilkoblet agent, kjører på sitt eget orkestreringslag inne i en foreldreagents plan. Den mottar en forespørsel fra forelderen og fullfører oppgaven. Subagenten produserer tre typer output: innhold den viser brukeren, verdier den returnerer gjennom definerte output, og et implisitt svar den sender til den kallende agenten. Forelderen kan ikke se subagentens utveksling med brukeren og lærer resultatet kun gjennom definerte utganger og implisitt respons. Denne begrensede synligheten fører ofte til duplikatmeldinger og tapte svar.

Tips

For veiledning om når arbeidet bør deles mellom agenter og generelle beste praksiser for flere agenter, se Multi-agent orkestreringsmønstre og beste praksis samt Multi-agent-mønstre. Denne artikkelen forklarer hvordan input og output stemmer overens med en underagents svar med foreldreagentens kontekst.

Denne artikkelen bygger videre på kontekstmodellen beskrevet i Context distribution i standard harness og designbeslutningene i Design best practices for å unngå dupliserte meldinger.

Slå av foreldrekontekst for en tilkoblet agent

En underagent som mottar forelderens samtalekontekst kan handle på den. Hvis den konteksten inneholder en forespørsel forelderen ennå ikke har svart, kan underagenten svare på den, gjenta noe forelderen allerede har håndtert, eller innta feil rolle. Disse handlingene fører ofte til dupliserte meldinger.

En tilkoblet agent har en innstilling, Send samtalehistorikk til denne agenten, som styrer om den mottar forelderens samtalekontekst. Denne innstillingen er aktivert som standard. Avmarker det slik at den tilkoblede agenten kun fungerer ut fra inputene foreldrene sender, ikke hele samtalen.

Skjermbilde av alternativet 'Send samtalehistorikk til denne agenten' aktivert, merk at deaktivering forhindrer historikkdeling mellom agenter.

En barneagent har ingen tilsvarende setting. Den kjører inne i forelderen og mottar alltid forelderens samtalekontekst.

For tilkoblede agenter som må beholde konteksten for arbeidet de er tildelt, og for barneagenter som har kontekst som standard, bruk en avgrensende input for å beskytte subagentens omfang.

Bruk en avgrensende inngang

Noen ganger trenger en underagent hovedagentens kontekst for å utføre sine oppgaver. Når du passerer den konteksten, inkluder en avgrensende input—den forteller underagenten nøyaktig hva den skal jobbe med, slik at gjenværende, ubesvarte forespørsler i konteksten ikke trekker det ut av oppgaven. Hvis du ikke sender konteksten, trenger du ikke en scoping-input fordi underagenten kun har forespørselen som forelderen rutet til den.

For å beskytte underagentens omfang, legg til en inngang med en beskrivelse scopedRequest som: The specific request this agent should fulfill. Orkestreringslaget fyller inngangen når det kaller subagenten. Foreldre-agenten identifiserer den relevante delen av forespørselen og sender kun den delen, selv om konteksten inneholder en annen ubesvart forespørsel.

En scoping-input er et robust design selv når du ikke beholder foreldrekonteksten. Inputen gir skaperen mer kontroll over innholdet i forespørselen som sendes til underagenten.

Forankr subagentens instruksjoner til den inputen slik at den fungerer fra den scoped-forespørselen og ignorerer alt annet som ligner en initial forespørsel.

Eksempler på instruksjoner for underagent:

Fulfill the request in the scopedRequest input. 
Treat it as your initial request and ignore any other initial requests in the conversation.

Konfigurer inndata og utdata

Innganger og utganger er kontrakten mellom forelderen og underagenten. Inndataene avgrenser hva underagenten jobber med, og utdataene forteller forelderen hva som skjedde slik at den kan orkestrere resten av samtalen. Forelderen kan ikke se underagentens utveksling med brukeren, så denne kontrakten er det eneste pålitelige signalet den har.

Important

En subagent som ikke returnerer noen utganger er et rødt flagg. Uten utdata har forelderen ingen oversikt over hva underagenten svarte eller hva som gjenstår. Den kan gjenta et svar underagenten allerede ga, eller droppe den delen av forespørselen underagenten ikke håndterte.

Konfigurer følgende innganger og utganger, og skriv beskrivelsen av hver enkelt for at det overordnede orkestreringslaget skal lese:

Inngang eller utgang Beskrivelse Slik brukes den
scopedRequest (inndata) Den spesifikke forespørselen denne agenten bør oppfylle. Forelderen fyller den ut med kun den relevante delen av brukerens forespørsel. Det beskytter underagenten mot å svare feil spørsmål når forelderens kontekst fortsatt inneholder andre, ubesvarte forespørsler. Forankr subagentens instruksjoner til denne inputen.
answered (utgang) Sant når brukeren allerede har mottatt svar på scopedRequest. Sett det på hver underagent, enten det sender melding til brukeren eller forblir taus. Den øverste instruksjonen, vist neste, leser den slik at foreldrene ikke svarer på samme forespørsel igjen.
scopedRequest (utgang) Forespørselen som denne agenten arbeidet med. Gjenta den scoped-forespørselen slik at den når toppnivå-orkestreringslaget, som ikke pålitelig beholder inputene den lager i sin egen kontekst. I flerintensjonsrunder som krever mer enn én underagent, gjør denne evnen at toppnivået planlegger riktig og unngår å rute feil underagent til feil spørsmål.
interactionSummary (utgang) En kort oppsummering av svaret som ble levert til brukeren. Returner den når underagenten sender direkte melding til brukeren, slik at forelderen vet hva som ble kommunisert og ikke gjentar det.
findings (utgang) Svaret på scopedRequest, som forelderen skal levere til brukeren. Returner den når underagenten forblir stille, slik at forelderen har innholdet som skal leveres.
openQuestions (utgang) Enhver del av brukerens forespørsel som forblir ubesvart. Send den tilbake fra en hvilken som helst underagent som bare kan oppfylle deler av forespørselen, eller der en ny forespørsel dukket opp i underagentens samtale, slik at foreldreagenten kan fullføre resten og fortsette verktøykjeden. Underagenten bør ikke gjette hvilken agent som håndterer resten.

Velg hvilken komponent som kommuniserer med brukeren

Bestem om foreldreagenten eller underagenten kommuniserer med brukeren. I de fleste tilfeller bør foreldreagenten kommunisere med brukeren slik at den kan kombinere resultatene til ett svar. La underagenten kommunisere direkte når den trenger å gi et langt svar eller ha en samtale over flere runder. Gi nok informasjon til at forelderen kan håndtere resten av samtalen med kontekst.

Uansett hvilken komponent som kommuniserer, legg til én toppnivåinstruksjon slik at orkestreringslaget sjekker hver subagents utganger før det svarer.

Denne eksempelinstruksjonen på toppnivå fungerer i alle tilfeller, enten en underagent sender direkte melding til brukeren eller forblir taus. Rediger og tilpass det etter behov.

Når et tema eller en agent blir kalt, se alltid etter det 'besvarte' boolske utgangspunktet før du bestemmer deg for hva du skal svare. Emner og agenter har sin egen kommunikasjonskanal med brukeren. Hvis 'besvart' er sant, anta alltid at forespørselen er besvart riktig ved bruk av minst én av utdatavariablene, og sjekk hvilke basert på utdatabeskrivelsen. Ikke gi en klønete bekreftelse på det besvarte innholdet. Gi kun de ubesvarte resultatene, og fortsett samtalen naturlig med neste steg.

Begrepet kanal refererer ikke til en integrasjonskanal. Det er en prompting-enhet som forteller orkestreringslaget at brukeren kanskje allerede har sett svaret gjennom en annen komponent.

Skriv subagentens beskrivelse for det overordnede orkestreringslaget, slik at den vet når den skal bruke subagenten og hvordan den skal lese dens utganger. Eksempel:

Handles payroll questions. 
If its answered output is true, the user has already received their response and it should not be answered again.

Angi svarstatus og verdiutdata for hver underagent, enten underagenten sender en melding til brukeren eller forblir stille, og gi overagenten én instruksjon om å lese dem. Med denne tilnærmingen kan en agent blande stille underagenter og underagenter som sender meldinger direkte til brukeren, kun skilt av sine utdata. Les mer i Design en robust toppnivåinstruksjon for å unngå gjentatte meldinger.

Deleger brukerkommunikasjon til forelderen

Vurder å rute all brukerkommunikasjon gjennom foreldreagenten i stedet for en underagent. Samle det subagenten trenger som input før den starter, les hva den produserte som output etter at den er ferdig, og instruer den om ikke å sende direkte melding til brukeren. En underagent som aldri skriver til brukeren kan ikke svare på noe forelderen allerede har svart på.

Si til subagenten at han skal være stille og returnere funnene sine. Eksempel:

Do NOT reply or communicate with the user directly. 
Only fulfill the scopedRequest provided in the input and respond with the result.

En stille underagent returnerer findings og openQuestions, begge beskrevet i Configure inputs and outputs, for å gi sitt svar til forelderen og flagge eventuelt arbeid som gjenstår.

Returner et openQuestions utgangspunkt. Det lar orkestreringslaget fullføre resten av brukerens forespørsel og fortsette verktøykjeden når en underagent bare kan oppfylle deler av det som ble bedt om.

Å holde under-agenten taus krever en eksplisitt instruksjon. Som standard kan en underagent sende melding til brukeren på egenhånd mens den kjører. Innstillingen etter fullføring forhindrer ikke disse meldingene fordi den bare forteller foreldrene hva de skal gjøre når underagenten er ferdig.

Note

Å si til hovedagenten: «Du er den eneste agenten som snakker med brukeren», fungerer ikke. Foreldreagenten kan ikke stoppe en kjørende underagent, og underagenten kan fortsatt sende melding til brukeren på egenhånd. I stedet, instruer underagenten om å være stille, og test deretter for å bekrefte.

Noen delagenter må kommunisere direkte

En underagent som sender meldinger direkte til brukeren er et gyldig valg, ikke et brudd på en regel, men det krever bevisst design for å unngå gjentatte meldinger fra forelderen.

Noen brukstilfeller krever at underagenten svarer direkte til brukeren, enten for å levere et langt svar uten å kopiere det inn i hovedkonteksten, eller for å holde en samtale. For å unngå gjentatte meldinger og tapt kontekst, send kontekst til forelderen i utgangene.

La underagenten gi et langt svar og returnere et sammendrag

Underagenten gir sitt fulle svar direkte til brukeren og returnerer kun et kort sammendrag eller en notis om at svaret er gitt. Bruk denne tilnærmingen for lange svar, som detaljerte analyser, og begrens informasjonen som returneres til forelderens kontekst. Målet er å holde foreldrekonteksten liten, men informert.

Returner answered og interactionSummary, begge beskrevet i Konfigurer innganger og utganger.

La underagenten holde en samtale med brukeren

Underagenten utveksler flere meldinger med brukeren gjennom flere trinn for å fullføre den scoped-forespørselen. Hovedrisikoen er at forelderen ikke er klar over de mellomliggende samtaletrinnene, underagentens arbeid og eventuelle svar, eller eventuelle nye forespørsler som dukker opp. Som et resultat kan ikke forelderen handle på nye forespørsler eller svare riktig i senere trinn.

Returner answered, scopedRequest, og interactionSummary, som beskrevet i Configure inputs and outputs.

Den øverste instruksjonen dekker også dette brukstilfellet.