Designa subagenter som undviker dubblettmeddelanden

Note

Den här artikeln beskriver egenskaper och beteende hos standardselen. Lär dig hur du får tillgång till standardfunktioner i Access standardagenter och agentflöden.

Duplicerade meddelanden beror på brister i kontexten. Agentdesign måste ta hänsyn till kontext i varje steg.

En subagent, antingen en barnagent eller en kopplad agent, körs på ett eget orkestreringslager inom en moderagents plan. Den tar emot en förfrågan från föräldern och slutför uppgiften. Subagenten producerar tre typer av utdata: innehåll den visar användaren, värden den returnerar genom definierade utdata, och ett implicit svar den skickar till den anropande agenten. Föräldern kan inte se subagentens utbyte med användaren och får bara veta resultatet genom de definierade utdata och det implicita svaret. Denna begränsade synlighet leder ofta till dubbletter och missade svar.

Tip

För vägledning om när arbetet ska delas upp mellan agenter och allmänna bästa praxis för flera agenter, se Multi-agent orkestreringsmönster och bästa praxis samt Multi-agent-mönster. Den här artikeln förklarar hur indata och utdata stämmer överens med en subagents svar med moderagentens kontext.

Denna artikel bygger vidare på kontextmodellen som beskrivs i Context distribution in the standard harness och designbesluten i Design best practices för att undvika dubblettmeddelanden.

Stäng av föräldrakontext för en ansluten agent

En subagent som tar emot förälderns samtalskontext kan agera på den. Om den kontexten innehåller en förfrågan som föräldern ännu inte har svarat på, kan subagenten svara på den, upprepa något som föräldern redan hanterat, eller anta fel roll. Dessa handlingar orsakar ofta dubbletter av meddelanden.

En ansluten agent har en inställning, Skicka konversationshistorik till denna agent, som styr om den tar emot förälderns konversationskontext. Den här inställningen är aktiverad som standard. Avmarkera det så att den anslutna agenten bara fungerar utifrån de indata föräldern skickar, inte hela konversationen.

Skärmdump av alternativet 'Skicka konversationshistorik till denna agent' aktiverat, notera att avmarkering hindrar historikdelning mellan agenter.

En barnagent har ingen motsvarande miljö. Den körs inuti föräldern och tar alltid emot förälderns konversationskontext.

För anslutna agenter som behöver behålla kontexten för det arbete de tilldelas, och för barnagenter som har kontext som standard, använd en avgränsande indata för att skydda subagentens omfattning.

Använd indata för avgränsning

Ibland behöver en underagent moderagentens kontext för att slutföra sina uppgifter. När du passerar den kontexten, inkludera en avgränsande input – den talar om för subagenten exakt vad den ska arbeta med, så att kvarstående, obesvarade förfrågningar i kontexten inte drar bort den från uppgiften. Om du inte skickar med kontexten behöver du ingen indata för avgränsning, eftersom subagenten bara har den förfrågan som den överordnade agenten vidarebefordrade till den.

För att skydda underagentens omfattning lägger du till en indataparameter med namnet scopedRequest och en beskrivning som till exempel: The specific request this agent should fulfill. Orkestreringslagret fyller i indata när det anropar subagenten. Moderagenten identifierar den relevanta delen av förfrågan och skickar endast den delen, även om dess kontext innehåller en annan obesvarad förfrågan.

En scoping-input är en robust design även när du inte behåller föräldrakontexten. Inmatningen ger skaparen mer kontroll över innehållet i förfrågan som skickas till subagenten.

Förankra subagentens instruktioner i den indatan så att den utgår från den avgränsade begäran och ignorerar allt annat som liknar en ursprunglig begäran.

Exempel på instruktioner för delagent:

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

Konfigurera indata och utdata

Indata och utdata är kontraktet mellan föräldern och underagenten. Inputen avgränsar vad subagenten arbetar med, och outputen berättar för föräldern vad som hänt så att den kan orkestrera resten av samtalet. Den överordnade agenten kan inte se underagentens kommunikation med användaren, så det här kontraktet är den enda tillförlitliga signalen som finns.

Viktigt!

En subagent som inte ger några utgångar är en varningssignal. Utan utdata har föräldern ingen registrering av vad underagenten svarade eller vad som återstår. Den kan upprepa ett svar som underagenten redan gett, eller ta bort den del av förfrågan som underagenten inte hanterade.

Konfigurera följande in- och utdata och skriv en beskrivning av var och en så att det överordnade orkestreringslagret kan läsa den:

Indata eller utdata Description Så här använder du
scopedRequest (indata) Den specifika önskan som denna agent bör uppfylla. Föräldern fyller i den med endast den relevanta delen av användarens begäran. Det skyddar underagenten från att svara fel på frågan när förälderns kontext fortfarande innehåller andra, obesvarade förfrågningar. Ankra subagentens instruktioner till denna indata.
answered (utgång) Sant när användaren redan fått ett svar på scopedRequest. Ställ in det på varje subagent, oavsett om den skickar meddelanden till användaren eller förblir tyst. Den övergripande instruktionen, som visas härnäst, läser den så att föräldern inte svarar på samma förfrågan igen.
scopedRequest (utgång) Förfrågan som denna agent arbetade med. Upprepa den avgränsade begäran så att den når orkestreringslagret på toppnivå, som inte konsekvent behåller de indata som det skapar i sitt eget sammanhang. I konversationsvändor med flera avsikter som kräver mer än en underagent gör den här funktionen det möjligt för den övergripande nivån att planera korrekt och undvika att skicka fel underagent till fel fråga.
interactionSummary (utgång) En kort sammanfattning av svaret som levererades till användaren. Returnera det när subagenten skickar ett direkt meddelande till användaren, så att föräldern vet vad som kommunicerades och inte upprepar det.
findings (utgång) Svaret på scopedRequest, som den överordnade komponenten ska leverera till användaren. Returnera den när subagenten är tyst, så att föräldern har innehållet att leverera med.
openQuestions (utgång) Alla delar av användarens förfrågan som förblir obesvarade. Returnera den från vilken underagent som helst som bara kan uppfylla en del av förfrågan, eller där en ny förfrågan dök upp i subagentens konversation, så att moderagenten kan slutföra resten och fortsätta verktygskedjan. Subagenten ska inte gissa vilken agent som hanterar resten.

Välj vilken komponent som kommunicerar med användaren

Bestäm om moderagenten eller subagenten kommunicerar med användaren. I de flesta fall låt moderagenten kommunicera med användaren så att den kan kombinera resultaten till ett svar. Låt subagenten kommunicera direkt när den behöver ge ett långt svar eller ha en konversation över flera turer. Ge tillräckligt med information för att föräldern ska kunna hantera resten av samtalet med kontext.

Oavsett vilken komponent som kommunicerar, lägg till en toppnivåinstruktion så att orkestreringslagret kontrollerar varje subagents utdata innan det svarar.

Denna exempelinstruktion på toppnivå fungerar i alla fall, oavsett om en subagent skickar direkt meddelanden till användaren eller förblir tyst. Redigera och anpassa det efter behov.

När något ämne eller agent anropas, leta alltid efter det 'besvarade' booleska resultatet innan du bestämmer vad du ska svara. Ämnen och agenter har sin egen kommunikationskanal med användaren. Om 'svarat' är sant, anta alltid att förfrågan har besvarats korrekt med minst en av utdatavariablerna, och kontrollera vilka baserat på utdatabeskrivningen. Ge inte en obekväm bekräftelse på det besvarade innehållet. Ge bara de obesvarade resultaten och fortsätt samtalet naturligt med nästa steg.

Begreppet kanal syftar inte på en integrationskanal. Det är en prompt-enhet som talar om för orkestreringslagret att användaren kanske redan har sett svaret genom en annan komponent.

Skriv subagentens beskrivning för moderorkestreringslagret, så att den vet när subagenten ska användas och hur den ska läsa dess utgångar. Ett exempel:

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

Ställ in svarstillstånd och värdeutdata på varje subagent, oavsett om subagenten skickar ett meddelande till användaren eller förblir tyst, och ge föräldern en instruktion att läsa dem. Med detta tillvägagångssätt kan en agent blanda tysta subagenter och subagenter som skickar meddelanden direkt till användaren, endast särskiljda av deras utdata. Läs mer i Design, en robust överordnad instruktion för att undvika upprepade meddelanden.

Delegera användarkommunikation till föräldern

Överväg att routa all användarkommunikation genom moderagenten istället för en subagent. Samla in vad subagenten behöver som indata innan den startar, läs vad den producerat som utdata efter att den är klar, och instruera den att inte skicka meddelanden direkt till användaren. En subagent som aldrig skriver till användaren kan inte svara på något som föräldern redan svarat på.

Säg åt underagenten att vara tyst och lämna tillbaka sina resultat. Ett exempel:

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

En tyst underagent returnerar findings och openQuestions, båda beskrivna i Konfigurera in- och utgångar, för att ge sitt svar till föräldern och flagga eventuellt kvarvarande arbete.

Returnera en openQuestions utgång. Det låter orkestreringslagret slutföra resten av användarens begäran och fortsätta verktygskedjan när en subagent bara kan uppfylla en del av det som efterfrågats.

Att hålla subagenten tyst kräver en tydlig instruktion. Som standard kan en subagent skicka meddelanden till användaren på egen hand medan den körs. Inställningen Efter att ha kört slutförande förhindrar inte dessa meddelanden eftersom den bara talar om för föräldern vad den ska göra när subagenten är klar.

Note

Att säga till moderagenten, "Du är den enda agenten som pratar med användaren," fungerar inte. Moderagenten kan inte stoppa en körande subagent, och subagenten kan fortfarande skicka meddelanden till användaren på egen hand. Instruera istället subagenten att vara tyst och testa sedan för att bekräfta.

Vissa delagenter måste kommunicera direkt

En underagent som skickar meddelanden direkt till användaren är ett giltigt val, inte ett regelbrott, men det kräver medveten design för att undvika upprepade meddelanden från föräldern.

Vissa användningsområden kräver att subagenten svarar direkt till användaren, antingen för att leverera ett långt svar utan att kopiera det till föräldrakontexten eller för att hålla en konversation. För att undvika upprepade meddelanden och förlorad kontext, skicka kontext till föräldern i utdata.

Låt underagenten ge ett långt svar och returnera en sammanfattning

Subagenten ger sitt fullständiga svar direkt till användaren och returnerar endast en kort sammanfattning eller en notis om att den levererat svaret. Använd detta tillvägagångssätt för långa svar, såsom detaljerade analyser, och begränsa informationen som returneras till förälderns kontext. Målet är att hålla föräldrakontexten liten men informerad.

Returnera answered och interactionSummary, båda beskrivna i Konfigurera in- och utgångar.

Låt subagenten hålla en konversation med användaren

Subagenten utbyter flera meddelanden med användaren i flera steg för att slutföra den avgränsade begäran. Den största risken är att föräldern inte känner till de mellanliggande samtalsstegen, underagentens arbete och eventuella svar som ges, eller eventuella nya förfrågningar som dykt upp. Som ett resultat kan föräldern inte agera på nya förfrågningar eller svara korrekt i senare steg.

Returnera answered, scopedRequest, och interactionSummary, som beskrivs i Konfigurera in- och utgångar.

Den övergripande instruktionen täcker också detta användningsfall.

  • Last updated on