- Kaasaegsed C# agendid ühendavad LLM-arutluskäigu tööriistade, mälu ja töövoogudega, et hakkama saada keerukate ja eesmärgipõhiste ülesannetega.
- Azure OpenAI assistendid ja Microsoft Agent Framework pakuvad .NET-is assistentide, seansside, tööriistade ja teostusprotsesside põhiprimitiivid.
- Tugevad arhitektuurid eraldavad spetsialiseeritud agente, säilitavad oleku, korraldavad töövooge ning jõustavad range testimise, jälgitavuse ja turvalisuse.
- Pilvepõhised tööriistad, nagu Azure AI Foundry ja VS Code'i tehisintellekti laiendused, lihtsustavad tootmiskvaliteediga agentide arendamist, hindamist ja juurutamist.
C# tööriistadega tehisintellekti agentide loomine on muutunud uurimiskatsest väga praktiliseks viisiks ärirakendustele reaalse intelligentsuse lisamiseks. Microsofti kaasaegsed raamistikud ning uusimad OpenAI ja Azure OpenAI SDK-d võimaldavad minna kaugemale lihtsatest vestlusrobotitest, ühendades suuri keelemudeleid koodi, failide, töövoogude ja ettevõtte süsteemidega, säilitades samal ajal kontrolli turvalisuse, kulude ja töökindluse üle.
See juhend tutvustab põhikontseptsioone, arhitektuurialaseid otsuseid ja konkreetseid .NET-näiteid, mida vajate C#-s tootmisvalmis agentide kujundamiseks. Me koondame ideid Azure OpenAI assistentidest, Microsoft Agent Frameworkist, orkestreerimismustritest, testimisest, jälgitavusest ja pilvejuurutamisest, selgitades, kuidas kõik sobitub reaalsete rakenduste sidusasse strateegiasse.
Mis tehisintellekti agent tegelikult on (ja miks see on .NET-is oluline)
.NET-ökosüsteemis on tehisintellekti agent kõige paremini mõistetav kui eesmärgipõhine tarkvarakomponent, mida toetab õigusteaduse magister (LLM), mis suudab teie rakenduses arutleda, tööriistu valida ja tegutseda. Jäiga skripti asemel, mis alati sama rada järgib, aktsepteerib agent avatud sisendit, otsustab, mida edasi teha, ning kasutab teie koodi ja andmeid tulemuse poole liikumiseks.
Agentidest saavad oluliselt kasulikumad funktsioonid, kui lisada lihtteksti genereerimisele veel kolm funktsiooni. Annad neile arutlus- ja otsustusvõime (LLM-ide, otsingu- või planeerimisalgoritmide kaudu), võimaluse kutsuda tööriistu (kohalikud C# funktsioonid, MCP-serverid, API-d, koodi käivitamine) ja kontekstiteadlikkuse (vestluste ajalugu, lõimed, vektorsalvestused, ettevõtte teadmiste graafikud või failiotsing). See muudab lihtsa vestluse lõpuleviimise komponendiks, mis suudab autonoomselt koordineerida mitmeastmelist tööd.
Kui eesmärgid muutuvad keerukamaks, käitate harva kõike ühe hiiglasliku läbipaistmatu käsuviibana; töö jagatakse töö töövoogudeks. Töövoog on eesmärgi saavutamiseks vajalike sammude jada või graafik: näiteks nõuete kogumine, funktsiooni kavandamine, rakendamine, testimine ja juurutamine. Iga samm võib sisaldada alamülesandeid ja olenevalt vigadest või uuest teabest võib uuesti tekkida tsükkel, seega muutub orkestreerimine kiiresti esmaklassiliseks mureks.
Kui paigutate agendid nendesse töövoogudesse, saate agentide töövooge : vooge, kus agendid teevad koostööd ülesannete täitmiseks, kohandamiseks ja optimeerimiseks. Teil võib olla agent, kes analüüsib logisid, teine, kes koostab koodiparandusi, ja kolmas, kes koostab sidusrühmade aruandeid. Oluline on see, kuidas nad teavet edastavad, kuidas neid koordineeritakse ja kuidas hoiate kogu süsteemi jälgitavana ja auditeeritavana.
Tehisintellekti assistentide ja agentide põhielemendid
Enamik tänapäevaseid C# ja .NET-ile suunatud tehisintellekti agendiplatvorme jagab väikest põhikomponentide komplekti, isegi kui nimetused Azure OpenAI Assistantsi ja Microsoft Agent Frameworki vahel veidi erinevad. Nende plokkide mõistmine aitab teil kujundada oma arhitektuuri, selle asemel et koodijuppe pimesi kopeerida.
Assistent või agent on keskne tehisintellekti klient, mis kasutab LLM plus konfiguratsiooni juhiste töötlemiseks, vestluste haldamiseks ja tööriistade käivitamiseks. Azure OpenAI Assistantsis mähib see objekt mudeli konfiguratsiooni, juhiseid ja tööriista konfiguratsiooni. Microsoft Agent Frameworkis on AIAgent sisaldab vestlusklienti (OpenAI või Azure OpenAI) koos tööriistade ja juhistega ning on tahtlikult olekuta, et see saaks samaaegselt teenindada mitut vestlust.
Lõim või seanss esindab ühte vestlust kasutaja ja agendi vahel, sealhulgas kõiki sõnumeid ja asjakohast olekut. Azure OpenAI assistendid räägivad lõimedest , mis omavad sõnumeid ja tegelevad automaatse kärpimisega, et need sobiksid mudeli kontekstiga. Microsoft Agent Framework räägib AgentSessionist , mis sisaldab ajalugu ning mida saab serialiseerida ja salvestada. Mõlemal on sama eesmärk: konteksti jälgimine mitme pöörde jooksul.
Sõnumid on kasutajate või assistendi loodud individuaalsed panused lõimes või seansis. Sõnumid võivad sisaldada lihtteksti, pilte või faile ning assistendi API-des salvestatakse need järjestatud loenditena lõimes. C# poolel hangitakse need tavaliselt tugevalt tüübitud kogumitena, kus saab uurida teksti, märkusi ja failiviiteid.
Käivitus, teostus või kutsumine on agendi ühekordne aktiveerimine antud lõime või seansi peal. Te võtate olemasoleva konteksti, saadate selle koos tööriistade ja konfiguratsiooniga mudelile ning ootate, kuni käivitamine jõuab lõppolekusse. Käitamise ajal saab agent luua uusi sõnumeid, kutsuda tööriistu ja värskendada lõime või seansi olekut.
Täitmisetapid moodustavad detailse jälje kõigest, mis agendi käitamise ajal toimus. Assistent võib ülesande kohta arutledes mitu korda kutsuda failiotsingu tööriista, käivitada koodiinterpretaatori või käivitada kohandatud funktsiooni. Nende sammude struktureeritud ülevaade on uskumatult kasulik, et mõista, miks konkreetne vastus loodi, ning hiljem käitumist siluda või auditeerida.
Minimaalse C# konsooliagendi loomine Azure OpenAI assistentidega
Nende kontseptsioonide toimimise nägemiseks saate käivitada minimaalse .NET-konsoolirakenduse, mis kasutab ametlikke OpenAI või Azure OpenAI SDK-sid, et luua assistent, mis loeb failidest andmeid ja genereerib visualiseeringuid. Idee on ühendada õigusteaduse assistent nii failiotsingu kui ka koodi käivitamisega ning seejärel lasta sel vastata analüütikaküsimustele loomulikus keeles.
Esimene samm on projekti seadistamine: looge uus .NET-konsoolirakendus ja lisage OpenAI ja Azure.AI.OpenAI NuGeti paketid. Seejärel loote peamiste klientide eksemplarid Program.cskas otse OpenAI jaoks või Azure OpenAI jaoks mandaadi abil, näiteks DefaultAzureCredentialOpenAI kliendilt saate AssistantClient assistentide ja eraldi haldamiseks OpenAIFileClient failide üleslaadimiseks.
Järgmisena valmistate ette realistlikud andmed, millega agent saab töötada, luues mällu dokumendi, serialiseerides selle JSON-ina ja voogesitades failikliendile. Näites kodeerib see JSON väljamõeldud ettevõtte mitme kuu toodete müügi, kaardistades kuud tootepõhiste kogustega. Selle üleslaadimine koos Assistants faili eesmärgil märgistate selle materjalina, mille hulgast agent saab otsida.
Kui andmed on süsteemis olemas, saate assistendi konfigureerida järgmiselt. AssistantCreationOptions et lubada nii failiotsingut kui ka koodiinterpretaatori tööriista. Sa määrad nime, selged juhised („oled assistent, kes otsib müügiandmeid ja loob visualiseeringuid, kui seda küsida“) ning seejärel lisad tööriistad: a FileSearchToolDefinition nii et assistent saab failide kohta päringuid teha ja lisaks veel CodeInterpreterToolDefinition nii et see saab analüüsimiseks või diagrammide genereerimiseks koodi kirjutada ja käivitada liivakastikeskkonnas.
Selleks, et failiotsing teie üleslaaditud müügidokumenti tegelikult kasutaks, seostate selle uue vektorsalvestusega ToolResources. Abistaja VectorStoreCreationHelper seob üleslaaditud faili ID vektorsalvestusega, mida assistent saab semantiliselt pärida toorteksti skannimise asemel. See on kerge, kuid võimas viis otsingu ja laiendatud genereerimise käitumise lisamiseks.
Kui valikud on paigas, saate assistendi luua sihtmudeli edastamise teel (näiteks gpt-4o) ja konfiguratsiooni ning seejärel loote vestluslõigu esialgse kasutajasõnumiga. See esimene küsimus võib olla midagi sellist nagu „Kuidas toode 113045 veebruaris toimis? Joonistage selle trend ajas.“ Lõpuks helistate CreateThreadAndRun, mis loob nii lõime kui ka käivitab jooksu.
Kuna käivitused on oma olemuselt asünkroonsed, küsitleb konsoolirakendus tavaliselt käivitust, kuni staatuseks saab terminal. Pärast seda tõmmatakse lõimesõnumid kasvavas järjekorras ja korratakse neid: prinditakse abitekst, väljastatakse failiviidete või genereeritud failide märkused ja laaditakse failikliendi abil alla pildiväljundid, et saaksite koodiinterpretaatori loodud diagramme kettale PNG-failidena salvestada.
Lõpptulemuseks on iseseisev C# konsoolirakendus, kus üks assistent saab otsida struktureeritud müügiandmeid, teha arvutusi koodi abil ning tagastada nii tekstilisi teadmisi kui ka visuaalseid graafikuid täisautomaatses tsüklis. See muster skaleerub hästi veebiserveritesse või taustateenustesse, kui lisada püsivus ja autentimine.
Tugeva agendi arhitektuuri loomine C#-s
Demost päris rakenduseni liikudes on agentide struktuuril sama suur tähtsus kui valitud mudelil. Hea arhitektuur lihtsustab lahenduse testimist, skaleerimist, turvamist ja arendamist, ilma et see lõpetaks hooldamatu küsimuste ja tagasihelistuste sasipuntraga.
Tõestatud strateegia on käsitleda agente spetsialiseerunud komponentidena, mitte üheainsa „kõike tegeva“ ajuna. Näiteks võite määratleda ühe agendi, mis keskendub teabe otsimisele ja kontrollimisele, teise agendi, mis on pühendunud sisu kirjutamisele ja kokkuvõtmisele, ning kolmanda, mille ainus ülesanne on suhtlemine väliste API-de või andmebaasidega. See eraldamine võimaldab sihipäraseid ühikteste, sõltumatuid juurutusi ning peenemaid turvalisuse ja tokenipiiranguid.
Seisund ja mälu muutuvad kiiresti pudelikaelaks, kui neid käsitleda järelmõttena. Vestluste ajalugu kasvab aja jooksul ja kogu transkripti pimesi mudelile saatmine iga kord suurendab nii latentsust kui ka kulusid. Praktiliste strateegiate hulka kuuluvad eelnevate sõnumite perioodiline kokkuvõtete tegemine, vestluste segmenteerimine eraldi lõimedeks kasutaja või kasutusjuhtumi järgi ning semantilise tähtsuse põhiste tihenduspoliitikate rakendamine, et säilitada detailselt ainult mineviku kõige olulisemad osad.
Tootmisstsenaariumides on vaja ka püsivat mälusalvestust, et vestlused jääksid ellu protsesside taaskäivitamise, tõrgete või ümberpaigutamise korral. Agentiraamistikud, näiteks Microsoft Agent Framework, muudavad seansid serialiseeritavaks. JsonElement, mille saate edastada SQL Serverisse, Redisesse või mis tahes NoSQL-i poodi. Sama funktsioon võimaldab auditeerimisjälgi ja regulatiivset vastavust, kuna saate täpselt rekonstrueerida agendi oleku otsuse tegemise ajal.
Tööriistad ja funktsioonikõned on kohad, kus agendid lõpetavad passiivsuse ja hakkavad tegema kasulikku tööd. Natiivsete C#-meetodite avaldamine tööriistadena võimaldab mudelil käivitada selliseid käitumisviise nagu CRM-i päringute esitamine, andmete analüüsimine või töövoogude käivitamine. Iga tööriist peaks olema märgistatud selgete metaandmetega (kirjeldused ja parameetrite dokumentatsioon), et õigusteaduse assistent teaks, millal ja milliste argumentidega seda kutsuda.
Kuna valesti toimiv tööriist võib terve interaktsiooni katkestada, vajate selle ümber tugevat inseneritööd: sisendi valideerimine, ajalõpud, erandite käsitlemine ja piirded. Ärge eeldage, et mudel edastab alati ideaalseid argumente; valideerige parameetreid ja desinfitseerige kõik välised kõned. Mõelge ka iga tööriista kvootidele ja kiirusepiirangutele, et vältida liigseid kulusid või allavoolu süsteemide juhuslikku ülekoormust.
Ambitsioonikate stsenaariumide korral võib mitme agendiga orkestreerimine avada võimalusi, mida on ühe monoliitse agendiga raske saavutada. Saate ühendada „uurija“ agendi, kes kogub ja kontrollib teavet, „analüütiku“, kes tõlgendab tulemusi, ja „kirjutaja“, kes muudab need aruanneteks, kusjuures igaüks neist suhtleb struktureeritud sõnumite kaudu ja jagab tööpinda (nagu jagatud dokument või teadmistebaas). See muster suurendab spetsialiseerumist ja muudab otsustusprotsessi jälgitavaks, kui teil on hiljem vaja tulemusi üle vaadata või auditeerida.
Semantilisest kernelist ja AutoGenist Microsoft Agent Frameworkini
Microsoft on koondanud oma .NET-i agentide tööriistu, koondades Semantic Kerneli ja AutoGeni projekti ideed uude, ühtsesse Microsoft Agent Frameworki (MAF). Selle raamistiku eesmärk on pakkuda teile ettevõtte tasemel stabiilsust ja funktsioone, lihtsustades samal ajal mitme pöördega agentide ja graafipõhiste töövoogude loomist.
MAF on praegu avalikus eelvaates ja saadaval nii .NET-i kui ka Pythoni jaoks MIT-litsentsi alusel. Kuigi mõned API-d on veel väljalaskekandidaatide vahel arenemisjärgus, on üldine suund selge: AIAgents intelligentse käitumise jaoks, AgentSessions oleku haldamiseks ja graafikutel ja täitjatel põhinev töövoo süsteem deterministlikumate torujuhtmete jaoks.
Raamistik eristab oma põhiolemuses agente ja töövooge, millest igaüks on mõeldud erinevat tüüpi probleemide jaoks. Agendid on dünaamilised süsteemid, mis kasutavad LLM-e sisendi tõlgendamiseks, tööriistade valimiseks ja vastuste genereerimiseks. Nad säravad ettearvamatutes valdkondades, näiteks tehnilise toe vestlustes, kus kasutajad võivad küsida mida iganes. Töövood seevastu on selged sammude järjestused, mis on ühendatud graafikutena ja mida kasutatakse siis, kui on vaja deterministlikku, täpselt määratletud töötlemist, näiteks andmekanalite või kinnitusahelate jaoks.
Ametliku juhise saab kokku võtta järgmiselt: „Kui saate ülesande standardfunktsioonina rakendada, pole teil selle jaoks tõenäoliselt agenti vaja.“ Teisisõnu, reserveerige agendid valdkondadele, kus te ei saa kõiki samme eelnevalt määratleda, ning tuginege korduvate, deterministlike voogude jaoks töövoogudele või klassikalisele koodile. Mõlema õiges kohas kombineerimine on hooldatavate süsteemide loomise võti.
Selle konkreetsemaks muutmiseks kujutage ette tugiteenuse vestlusrobotit, mis on ehitatud ASP.NET Core 10 API-na, kasutades Microsoft Agent Frameworki. Agent kasutab oma arutlusmootorina vestlusklienti (mida toetab Azure OpenAI või OpenAI) ja selle peamine eesmärk on vastata küsimustele Markdowni failides talletatud sisemise dokumentatsiooni kohta, säilitades samal ajal konteksti sama kasutaja mitme sõnumi vahel.
Huvitaval kombel saab näites RAG-i manustuste puhul tahtlikult vahele jätta, jäädes siiski realistlikuks, kasutades lähtepunktina märksõnaotsingut lamefailide kaudu. See hoiab fookuse sellel, kuidas MAF agenti, tööriistu ja seansse struktureerib, selle asemel, et vektorandmebaasi konfiguratsioonis ära eksida, toetades samal ajal väga usutavaid tugiinteraktsioone.
Microsoft Agent Frameworki viis põhimõistet
MAF-i ametlikud õpetused jagavad õppimise viieks progressiivseks ideeks, mis sobivad hästi kokku sellega, kuidas C# arendajad juba teenustest ja olekutest mõtlevad. Nende kontseptsioonidega harjumine annab sulle kindla aluse iga agendi jaoks, mida .NET-il ehitad.
Esmalt tuleb teie esialgne agent: AIAgent loodud vestluskliendist, juhistest ja nimest. Sa suunad agendi AzureOpenAIClienti või OpenAI pakutava vestlusmudeli juurde, annad süsteemitasandi juhiseid („oled abivalmis tugiassistent“) ja seejärel helistad. RunAsync kasutaja sisendiga. Oluline detail on see, et agendi eksemplar on olekuta ja saab korraga teenindada mitut sõltumatut vestlust.
Teiseks on tööriistad, mis on lihtsalt C# meetodid, mis on kaunistatud atribuudid ja teisendatakse kutsutavateks funktsioonideks AIFunctionFactory.Create(). Agendi käivitamisel saab LLM nendest atribuutidest tuletatud skeemi ja saab autonoomselt otsustada, millal ja kuidas iga tööriista, sealhulgas argumente, kutsuda. Siin saavad teie enda äriloogika ja välised integratsioonid osaks agendi tegevusruumist.
Kolmandaks on mitmepöördeline vestlustugi, millega MAF tegeleb AgentSession objektid. Sest AIAgent ise ei mäleta midagi, iga käimasolev vestlus elab seansi sees, mis on loodud CreateSessionAsync()Sa edastad selle seansi järgmiste kõnede ajal tagasi, võimaldades agendil jälgida varasemaid sõnumeid, kasutaja eelistusi ja lahendamata probleeme.
Neljandaks on mälu ja püsivus, mida võimaldab asjaolu, et seansse saab serialiseerida JsonElement. See teeb nende salvestamise mällu, Redisesse, SQL-tabelisse või muusse eelistatud salvestusse ja seejärel nende rekonstrueerimise lihtsaks DeserializeSessionAsync()Tugiteenuste puhul tähendab see, et kasutaja saab brauseri sulgeda ja hiljem sama vestlust jätkata või saab pärast taaskäivitamist sujuvalt üle võtta mõni muu teenuseeksemplar.
Viiendaks on töövood, mis on üles ehitatud WorkflowBuilder kui teil on vaja selgesõnaliselt korraldada mitu agenti või järjestikuseid töötlemisetappe. Sa defineerid täitjad töötlusüksustena, ühendad need servade kaudu ja lased töövoo mootoril hallata marsruutimist ja üleminekuid. Paljudes vestlusjuhtudes ei vaja sa töövooge üldse, kuid need on äärmiselt kasulikud, kui soovid struktureeritud marsruutimist, klassifitseerimist või inim-silmusega samme oma agentide ümber.
Tõelise tugiroboti rakendamine MAF-i, tööriistade ja seansside abil
Konkreetne näide ülaltoodud kontseptsioone illustreerib SupportBot API, mida toetab ASP.NET Core 10 projekt. See teenus avaldab HTTP-lõpp-punkti, mis võtab vastu kasutajasõnumeid ja seansi identifikaatorit, delegeerib arutluskäigu AIAgentile ning säilitab seansi, et kontekst säiliks kõigis päringutes.
Selle stsenaariumi keskne tööriist on dokumentatsioonitööriist (DocumentationTool), mis oskab otsida sisemisi Markdown-faile. Selle ülesanne on leida asjakohaseid juhendeid, KKK-sid või moodulite käsiraamatuid ja tagastada tekstisegmente, mis aitavad agendil vastust koostada. Selle meetoditele rakendatud atribuudid ei ole dekoratiivsed; MAF kasutab neid LLM-i loetava funktsiooniskeemi loomiseks ja nende kirjelduste selgus mõjutab oluliselt seda, kui tõhusalt mudel tööriista valib ja kutsub.
Selle tööriista pragmaatiline disainivalik on tagastada kõik dokumendid, kui miski ei vasta piisavalt hästi taotletud teemale. Selle asemel, et jätta agent ilma igasuguse materjalita, on parem anda liiga palju konteksti ja lasta mudelil parimad palad valida, selle asemel, et lasta sel vaakumis hallutsineerida. See „turvalise varuvariandi“ muster ilmneb sageli robustsete agentide rakendustes.
Seejärel ühendab SupportAgentFactory kõik omavahel, võttes AzureOpenAIClient, vestluskliendi ekstraheerimine kaudu GetChatClient(), kohandades seda AsIChatClient() ja seejärel muutes selle AIAgent koos AsAIAgent(). Selle viimase etapi käigus saavad registreeritud tööriistadest ja juhistest osa iga vestluse jaoks kasutatavast agendi konfiguratsioonist. Tavaliselt registreeritakse see loodud agent DI-konteineris üksikobjektina, et see saaks samaaegselt teenindada paljusid seansse.
Seansihaldus on abstraktne tagapool InMemorySessionStore arenduse ajal, mis korraldab seansse järgmiselt: JsonElement väärtused. Lõimekindel ConcurrentDictionary piisab siin käsitsi lukustamise vältimiseks. Tegelikus juurutuses vahetaksite selle rakenduse Redis-toega või andmebaasiga toetatud salvestusruumi vastu, säilitades liidese puutumata, kuid saavutades vastupidava salvestusruumi ja horisontaalse skaleeritavuse.
API pind Program.cs on tahtlikult lihtne: üks POST /chat lõpp-punkt, mis aktsepteerib seansi ID-d ja kasutajasõnumit. Päringukäitleja laadib või loob seansi, käivitab agendi, serialiseerib uuendatud seansi asünkroonselt (pange tähele, et SerializeSessionAsync on RC1-s asünkroonne, isegi kui varased dokumendid soovitasid teisiti), säilitab selle ja tagastab assistendi vastuse kliendile. Frontendi seisukohast tähendab „samas vestluses püsimine“ lihtsalt sama seansi ID saatmist iga kõne puhul.
Kui käivitate API-t ja vestlete sellega, saate jälgida, kuidas agent edastab konteksti vahetuste vahel, täpselt nagu inimtugiteenindaja. Esimene sõnum võib kirjeldada sisselogimisprobleemi; teine küsimus, mis saadetakse sama seansi ID-ga, võib viidata „samale veale uuesti“ ilma kõiki üksikasju kordamata, ja agent vastab ikkagi sidusalt, kuna olek on seotud seansi salvestusega.
Töövood hakkaksid end ära teenima alles siis, kui lisaksite selliseid funktsioone nagu automaatne kavatsuste klassifitseerimine, suunamine spetsialiseeritud agentidele (arveldamine, juurdepääs, aruandlus) või eskaleerimine inimpersonalile. Seejärel saaksite töövoo graafiku ette lisada klassifitseerimise täidesaatja ja ühendada selle teemapõhiste agentidega või lisada inimese kaasamise sõlme, mis peatab automatiseerimise ja annab konteksti inimesele üle, kui usaldus on madal.
Töövood, orkestreerimisrežiimid ja mitme agendi koostöö
Isegi väljaspool MAF-i on kasulik mõelda, kuidas agente sisaldavaid töövooge korraldatakse, sest nende struktuur mõjutab latentsust, kulusid ja jälgitavust. Projektide ja raamistike lõikes ilmneb mitu levinud mustrit.
Järjestikune orkestreerimine tähendab, et agendid tegelevad ülesannetega üksteise järel, edastades väljundeid edasi. Näiteks kogub otsinguagent kõigepealt asjakohase dokumentatsiooni ja edastab selle analüüsiagendile, kes omakorda edastab oma leiud aruandlusagendile. Seda on lihtne põhjendada ja siluda, kuid see suurendab otsast lõpuni latentsust.
Samaaegne orkestreerimine käitab paralleelselt mitut agenti, kellest igaüks keskendub probleemi erinevale aspektile. Üks agent võib arvutada mõõdikuid, teine otsida hiljutisi intsidente ja kolmas hinnata vastavusele mõju – kõik samal ajal. Kui nad on lõpetanud, koondab koordinaator nende tulemused üheks vastuseks. See muster vähendab latentsusaega, kuid nõuab hoolikat ressursside kontrolli ja konfliktide lahendamist.
Üleandmisvood muudavad ülesande omandiõigust ühelt agendilt teisele tingimuste või vahetulemuste põhjal. Kui tugiteenuse agent tuvastab, et küsimus on tegelikult müügiga seotud, saab ta vestluse üle anda spetsialiseerunud müügiagendile, säilitades valikuliselt vestluste ajaloo ja metaandmed. See on eriti kasulik keerukate klienditeekondade puhul, kus vastutus liigub meeskondade vahel õiguspäraselt.
Grupivestluse stiilis seadistused võimaldavad mitmel agendil teha koostööd jagatud vestluskanalis, vahetades sõnumeid reaalajas. Iga agent toob kaasa oma vaatenurga või tööriistakomplekti ning keskne orkestreerija või LLM-moderaator saab vestlust hallata nii, et see koondub, mitte ei tsükli lõputult. See muster on võimas, kuid nõuab tugevaid piirdeid, et vältida müra ja ebavajalikke kulusid.
Lõpuks, magnetiline orkestreerimine paneb ühe „juhi“ või dirigendi vastutama teiste juhtimise eest. Juhtiv agent jagab ülesande osadeks, saadab alamülesanded õigetele spetsialistidele ja seejärel sünteesib nende väljundid. See sarnaneb insenerijuhiga, kes koordineerib arendajate meeskonda, ning suudab keerukates valdkondades luua selgeid ja auditeeritavaid vooge.
Testimine, jälgitavus, kulude kontroll ja turvalisus
Tehisintellekti agentide tootvasse keskkonda saatmine ilma testimise, jälgimise, kulude ja turvalisuse plaanita on retsept ebameeldivate üllatuste tekkeks. Sama rangus, mida rakendate iga kriitilise .NET-teenuse puhul, peab laienema ka teie agentide tasemele, lihtsalt kohandatuna õigusteaduse magistriõppe tõenäosusliku olemusega.
Enne mudeli käitumise pärast muretsemist alusta tööriistade ja orkestreerimisteede testimisest klassikaliste ühik- ja integratsioonitestidega. Iga C# funktsioon, mida agent saab kutsuda, peaks olema iseseisvalt testitav, deterministlike sisendite ja väljunditega. Seejärel kujunda kontrollitud vestlusskriptid, mis katsetavad täielikke interaktsiooniteid, kontrollides mitte ainult lõppvastust, vaid ka seda, milliseid tööriistu kutsuti ja kuidas olek arenes.
Jälgitavus peaks jälgima latentsusaega, märkide tarbimist ja edukuse määra erinevate täitmismarsruutide lõikes. Äärmiselt kasulik on mõõta nii viipa- kui ka lõpuleviimise märke interaktsiooni kohta, jaotatuna töövoo, tööriista või kasutajatüübi järgi, et saaksite märgata regressioone ja kulude hüppeid. Pikemad vestlused on eriti kallid, seega investeerige automaatsesse kokkuvõttesse ja intelligentsetesse kärpimisstrateegiatesse, et hoida kontekstid lihtsad.
Turvalisus ei ole enam läbiräägitav, kui teie agendid puutuvad kokku tundlike või kliendiandmetega. Peaksite kehtestama range juurdepääsukontrolli selle üle, milliseid tööriistu ja andmekogumeid agent näeb, logima auditeerimise eesmärgil iga tööriista kutsumise ja läbima kõik välised kõned puhastuskihtide kaudu. Volitusi ei tohiks kunagi koodi manustada; tuleks tugineda hallatud identiteetidele, salajastele salvestuskohtadele ja tavapärastele pilveturbepraktikatele, mida te juba rakendate tehisintellektivälistele mikroteenustele.
Vastavusnõuded mõjutavad ka vestluste ajaloo salvestamist ja töötlemist. Kuna seansid ja teemad võivad sisaldada isikuandmeid või konfidentsiaalset sisu, tuleks säilituspoliitikad, anonüümimisstrateegiad ja andmete minimeerimise reeglid varakult kindlaks määrata. Agentide seansside serialiseerimise ja deserialiseerimise võimalus on võimas, kuid see peab olema tasakaalustatud juriidiliste ja regulatiivsete kohustustega.
Kulude osas ärge alahinnake isegi väikeste ebaefektiivsuste mõju mastaabis. Väikesed muutused päringute suuruses, tööriistakutsete sageduses või samaaegsete agentide arvus võivad kaasa tuua suuri igakuiseid arveid. Süsteemi instrumenteerimine, telemeetria regulaarne ülevaatamine ja päringute häälestamine, mälupoliitikad ja mudelivalikud on olulised kulude jätkusuutlikkuse tagamiseks aja jooksul.
Juurutamine ja skaleerimine on lihtsamad, kui eraldate juhtimistasandi (kus konfigureerite agente ja töövooge) järeldustasandist (kus tegelikud mudelikõned toimuvad). Konteineripõhine orkestreerimine, pikalt töötavate toimingute sõnumijärjekorrad ja hallatavad pilveteenused LLM-i majutamiseks aitavad kõik kaasa vastupidavusele. Tulemused saab seejärel edastada armatuurlaudadele või ärianalüütika tööriistadesse, näiteks Power BI, et sulgeda analüütilise tagasiside ahel ja näidata äriväärtust.
Integreeritud tööriistad, näiteks AI Toolkit ja Azure AI Foundry laiendused Visual Studio Code'ile, saavad seda elutsüklit oluliselt lihtsustada. Redaktorist saate uurida mudelikatalooge, juurutada GitHubi majutatud või kohalikke mudeleid Ollama kaudu, võrrelda väljundeid kõrvuti, luua ja käivitada hindajaid, visualiseerida tulemusi Data Wrangleris, kujundada agente süsteemiviipadega, ühendada MCP-servereid tööriistade integreerimiseks ja agentide interaktsioonide silumiseks. Azure AI Foundry lisab visuaalsed disainerid, YAML-i sünkroniseerimise, koodi genereerimise Azure'i mudelitele juurdepääsuks ja esmaklassilise tööriistade, näiteks Bing Searchi ja koodiinterpretaatorite integratsiooni.
Kui need koostisosad kokku liita – kindel agendi arhitektuur, läbimõeldud olekuhaldus, töökindlad tööriistad, vajadusel graafipõhised töövood, sügav jälgitavus ja pilvepõhine juurutamine –, saadakse C# tehisintellekti agendid, mis pole lihtsalt nutikad demod, vaid usaldusväärsed osad suurematest ettevõttesüsteemidest. Hoolika disaini ja Azure OpenAI abiliste ning Microsoft Agent Frameworki õige kasutamise korral saavad need agendid mõõdetavalt parandada teie organisatsiooni tõhusust, teabe kvaliteeti ja automatiseerimist, jäädes samal ajal hooldatavaks ja turvaliseks.
