Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Generativ orkestrering stöder också multiagentsystem, där en agent kan anropa andra agenter. När du delar upp problem i flera specialiserade agenter gör du din applikation mer modulär, skalbar och hanterbar.
Inbyggda agenter
Inline-agenter, även kallade underordnade agenter, är små, återanvändbara arbetsflöden inom samma agent. De är ofta bara ämnen som huvudagenten använder som subrutiner. Till exempel kan huvudagenten anropa ämnet "Översätt text" som ett steg i en större plan. Inline-agenter delar kontext med huvudagenten, så att överföra data mellan dem är enkelt.
Bästa praxis: Håll inbyggda agenter fokuserade på ett enda ansvarsområde och testa dem väl.
Anslutna agenter
Sammankopplade agenter är separata agenter med egen orkestrering, verktyg och kunskap. Huvudagenten delegerar en del av en förfrågan till en underordnad agent. Till exempel kan en IT-agent ringa en försäljningsagent för att få information om prissättning. Sammankopplade agenter möjliggör modularitet och domänseparation, och kan kringgå planbegränsningar. De kan ha olika privilegier eller kunskaper, så tillämpa styrning och revisionskontroller.
Dock kräver användningen av sammankopplade agenter noggrann styrning:
Orkestrering: Den överordnade orkestreringen bör ha tydliga kriterier för när den ska överlämna till en sammankopplad agent. Orkestreraren överlämnar vanligtvis när användarens avsikt matchar den anslutna agentens domän. För att underlätta denna process, beskriv den anslutna agentens syfte tydligt i föräldraagentens konfiguration. Behandla hela den anslutna agenten som ett agentiskt ”verktyg” med en beskrivning, ur den överordnade agentens perspektiv.
Dataöverlämning: Du måste hantera dataöverlämning. Bestäm vilken kontext från den överordnade agenten som ska skickas vidare till den sammankopplade agenten. Copilot Studio vidarebefordrar konversationshistoriken som standard när en agent anropar en annan, så att den anslutna agenten förstår den tidigare kontexten i samtalet. Men du kan behöva skicka specifika parametrar också. Till exempel, om huvudagenten redan vet användarens namn sedan tidigare, kan den skicka det till den anslutna agenten för att undvika att fråga om det igen.
Säkerhet: Den sammankopplade agenten kan ha tillgång till saker som den överordnade agenten inte har. Se till att anrop till den anslutna agenten inte oavsiktligt kringgår begränsningar. Till exempel, om den överordnade agenten inte får radera poster men den sammankopplade agenten kan, bör den överordnade agenten inte anropa den sammankopplade agenten i situationer där radering kan ske utan korrekt godkännande. Behandla ett anrop till en sammankopplad agent som en kraftfull åtgärd. Om åtgärden är känslig ska den genomgå nödvändiga kontroller eller kräva användarens samtycke.
Granskning och övervakning: Logga när en sammankopplad agent anropas och vad den gör. Eftersom det är en separat agent har du separata transkriptioner för det. Det är viktigt för felsökning att korrelera den överordnade agentens och den sammankopplade agentens sessioner. Vanligtvis länkar identifierare i telemetrin de två.
När man ska separera agenter
Skapa inte en separat agent för varje deluppgift. Använd separata agenter om deluppgiften:
- Är tillräckligt komplex för att ha en egen verktygssvit eller kunskapsbas (ett annat expertområde)
- Kräver andra styrningsregler eller åtkomstkontroller än huvudagenten
- Kan återanvändas i många olika huvudagenter (så det är som en serviceagent)
Om inget av dessa villkor gäller kan en enkel inbyggd agent hantera jobbet väl samtidigt som den är enklare än en helt separat agent. Separata agenter medför extra belastning för systemet. Det är en något längre exekveringstid på grund av kontextväxling och komplexitet i att underhålla flera agenter. Så använd dem försiktigt. För ett praktiskt tillvägagångssätt, börja med en agent. Dela sedan bara upp i flera agenter när du tydligt ser behovet av modularitet eller en gräns som en enskild agent inte bör korsa.
Bästa metoder för multiagent-orkestrering
Följande bästa praxis gäller när man skriver instruktioner för överordnade och underagenter i en multiagentuppsättning.
1. Principen om ett enda svar
Se till att endast en agent kommunicerar med användaren vid varje interaktion. I en multiagentmiljö är det bara den överordnade agenten som ska leverera det slutgiltiga svaret. Underagenter är forskare, inte svarare.
- Gör: Lägg till i överordnat objekts instruktioner: "Du är den enda agent som kommunicerar med användaren." Kombinera resultat från alla underordnade agenter till ett enda svar."
- Gör inte: Låt det vara tvetydigt. Utan tydliga instruktioner kommunicerar underagenter direkt med användaren, vilket kan leda till duplicerade eller delvisa svar.
2. Underagentinstruktioner måste ange sin roll
Informera alltid subagenter om att de är subagenter. Subagenter vet inte automatiskt att de är en del av en orkestrering. Utan tydlig vägledning beter de sig som fristående agenter och skickar meddelanden direkt till användaren.
- Gör: Lägg till i varje underagents instruktioner: "Du är en underagent." Svara INTE användaren direkt. Ditt jobb är att leta efter information och lämna tillbaka dina fynd till den överordnade agenten. Den överordnade agenten hanterar all kommunikation med användaren.
- Gör inte: Anta att underagenter själva identifierar orkestreringsmönstret.
3. Använd tydligt, direkt språk i instruktionerna
Använd alltid direkt språk. Undvik mjuka eller artiga formuleringar. Plattformen inför systemnivåinstruktioner genom att använda starkt språk (MÅSTE, GÖR INTE, ALDRIG). Instruktioner skrivna med mjukt språk ("försök", "du borde", "det vore bra att") förlorar prioritet när de krockar.
- Gör ”Svara INTE användaren direkt. Returnera ENDAST dina resultat.”
- Gör: "Varje användarfråga ska få exakt ett slutgiltigt svar."
- Gör inte: "Försök undvika att skicka meddelanden till användaren och returnera istället dina resultat."
- Gör inte: "Idealiskt vill vi ha ett enda kombinerat svar."
4. Använd en kunskapskälla per underagent (ingen överlappning)
Tilldela distinkta, icke-överlappande kunskapskällor till varje underagent. Om två underagenter söker i samma kunskapsbas, hittar en underagent svaret först. Den andra underagenten returnerar antingen dubblettresultat eller hoppar över sin sökning helt, utan att tillföra något värde.
- Gör: CA-1 söker i Kunskapskälla A (till exempel HR-policyer). CA-2 söker i kunskapskälla B (till exempel IT-dokumentation).
- Gör inte: Ge båda underagenterna tillgång till samma dokument, Dataverse-tabeller eller SharePoint-sajter.
- Observera: Om du bara har en kunskapskälla, använd en enda agent med tillgång till kunskap istället för att skapa två underagenter. Multi-agent tillför värde endast när källorna verkligen är olika.
5. Använd tydliga och unika beskrivningar för underagenter
Skriv tydliga, tydliga beskrivningar för varje underagent som är synlig för den överordnade agenten. Den överordnade agenten använder underagentbeskrivningar för att bestämma routing. Om beskrivningarna är vaga, identiska eller felaktiga kan den överordnade noden inte fatta välgrundade routningsbeslut.
- Gör: CA-1: "Söker i HR-policydokument efter anställningsrelaterade frågor." CA-2: "Söker i IT-kunskapsbas efter tekniska supportfrågor."
- Gör inte: Ge båda agenterna samma beskrivning när de hanterar olika domäner.
- Gör inte: Använd generiska beskrivningar som "Denna agent kan hjälpa med frågor."
6. Överordnade instruktioner måste definiera orkestreringsmönstret
Informera den överordnade agenten om hur den ska orkestrera. Säg inte bara "använd underordnade agenter". Den överordnade användaren behöver explicita instruktioner för mönstret: anropa agenter, vänta på resultat, kombinera och svara sedan.
- Gör: "När användaren ställer en fråga: 1. Anropa båda de underordnade agenterna för att samla in information. 2. Vänta tills båda de underordnade agenterna återkommer med sina resultat. 3. Kombinera resultaten till ett enda, enhetligt svar. 4. Ge användaren exakt ett svar. Underordnade agenter får inte svara direkt till användaren."
- Gör inte: "När användaren ställer en fråga, anropa underordnad agent och få svar från båda källorna och ge ett gemensamt svar." (För vagt. Instruktionen säger inte åt underordnad agent att vara tysta.)
7. Inkludera direktivet "svara inte direkt" i uppgiftsdelegeringen
Även med tydliga instruktioner för underagenter ger tillägg av förstärkning i den delegerade uppgiften ett skyddsnät.
- Gör så här: Lägg till i överordnade instruktioner: "När du delegerar till en underordnad agent ska du alltid inkludera i uppgiften: 'Returnera endast dina slutsatser. Svara inte på användaren.”
- Gör inte: Lita enbart på underagentens egna instruktioner. Uppgiftskontexten ger subagenten fler signaler som förstärker mönstret.
8. Testa med frågor utanför alla subagenters domäner
Testa alltid med frågor som inte matchar någon subagents domän. Det här testet visar om underordnade agenter på ett smidigt sätt returnerar "ingen information hittades" i stället för att returnera information som kan vara felaktig, hänga sig eller skicka förvirrande meddelanden.
- Gör: Testa med frågor utanför alla subagenters domäner (till exempel, fråga om väder när agenter hanterar HR och IT).
- Gör så här: Kontrollera att de överordnade hanterar "båda agenterna hittade ingenting" på ett korrekt sätt.
- Gör inte: Testa bara med de enklaste frågor som matchar en subagents domän perfekt.
9. Föredra att fråga framför att informera när du förväntar dig en uppföljning
Använd frågeinteraktioner när du förväntar dig att användaren ska svara. Använd inform/send-stilen endast för slutliga envägsmeddelanden. Om agenten ställer en fråga till användaren med ett envägsmeddelande (inform), går användarens svar tillbaka till huvudplaneraren som en helt ny fråga. I det här fallet är det bättre att fortsätta samma samtal med subagenten.
- Gör: Skriv instruktioner som: "Om du behöver förtydligande, ställ en fråga till användaren och vänta på deras svar."
- Gör inte: Skriv instruktioner som: "Informera användaren om alternativen och låt dem välja." "Inform" signalerar ett envägsmeddelande, medan "ask" signalerar ett tvåvägsutbyte.
Snabbreferenschecklista
| # | Check |
|---|---|
| 1 | De överordnade instruktionerna säger uttryckligen "endast jag svarar användaren" |
| 2 | Varje underagentinstruktion ska uttryckligen säga "svara aldrig användaren direkt" |
| 3 | Instruktionerna är formulerade i ett starkt imperativt språk (MÅSTE, ALDRIG, ENDAST) |
| 4 | Varje underagent har en unik, icke-överlappande kunskapskälla |
| 5 | Underagenternas beskrivningar ska vara korrekta, avgränsade och specifika |
| 6 | Instruktioner för överordnat element ska definiera hela orkestreringsmönstret (anropa → vänta → kombinera → svara) |
| 7 | Överordnad skickar "inget direkt svar" i delegerad uppgiftskontext |
| 8 | Testad med domänmismatch-frågor |
| 9 | Distinktionen mellan att fråga och att informera är korrekt tillämpad i subagenters instruktioner |
Relaterad information
- Lägga till andra agenter – översikt
- Lägga till en underordnad agent
- Ansluta till en befintlig Copilot Studio-agent
- Ansluta till en Microsoft Foundry-agent
- Ansluta till en Microsoft Fabric dataagent
- Ansluta till en agent i SDK för Microsoft 365-agenter
- Ansluta till en agent tillgänglig via Agent2Agent-protokollet (A2A)