Како направити моћне вештачке интелигенције помоћу алата у Csharp-у

Почетна » Питон » Како направити моћне вештачке интелигенције помоћу алата у Csharp-у

Изградња вештачке интелигенције помоћу алата у C# је прешла из истраживачког експеримента у веома практичан начин додавања праве интелигенције пословним апликацијама. Модерни оквири компаније Microsoft и најновији OpenAI и Azure OpenAI SDK-ови омогућавају да се иде далеко даље од једноставних четботова, повезујући велике језичке моделе са кодом, датотекама, токовима рада и пословним системима, а да се притом задржи контрола над безбедношћу, трошковима и поузданошћу.

Овај водич вас води кроз основне концепте, архитектонске одлуке и конкретне .NET примере који су вам потребни за дизајнирање агената спремних за продукцију у C#. Саставићемо идеје из Azure OpenAI асистената, Microsoft Agent Framework-а, образаца оркестрације, тестирања, видљивости и имплементације у облаку, објашњавајући како се све уклапа у кохезивну стратегију за апликације из стварног света.

Шта је заправо AI агент (и зашто је важан у .NET-у)

У .NET екосистему, AI агент се најбоље разуме као циљно вођена софтверска компонента коју покреће LLM (мастер лабораторија за учење) и која може да расуђује, бира алате и делује унутар ваше апликације. Уместо крутог скрипта који увек прати исту путању, агент прихвата отворене уносе, одлучује шта ће даље радити и користи ваш код и податке да би се кретао ка резултату.

Агенти постају знатно кориснији када додате три могућности поред генерисања обичног текста. Дајете им могућност расуђивања и доношења одлука (кроз LLM-ове, алгоритме за претрагу или планирање), могућност позивања алата (локалне C# функције, MCP сервери, API-ји, извршавање кода) и свест о контексту (историја ћаскања, нити, складишта вектора, графикони знања предузећа или претрага датотека). То је оно што једноставно довршавање ћаскања претвара у компоненту која може аутономно координирати рад у више корака.

Како ваши циљеви постају сложенији, ретко све покрећете као један огромни непрозирни промпт; посао разлажете на токове рада. Ток посла је низ или графикон корака потребних за постизање циља: на пример, прикупљање захтева, пројектовање, имплементација, тестирање и примена функције. Сваки корак може да садржи подзадатке и може се враћати уназад у зависности од грешака или нових информација, тако да оркестрација брзо постаје брига првог реда.

Када поставите агенте унутар ових токова рада, добијате агентски токови посла: токови где агенти сарађују како би извршавали, прилагођавали и оптимизовали задатке. Можда имате агента који анализира логове, другог који прави нацрте исправки кода и трећег који припрема извештаје заинтересованим странама. Важан део је како они преносе информације, како су координисани и како одржавате цео систем доступним за видљивост и ревизију.

Основни градивни блокови вештачке интелигенције асистената и агената

Већина модерних платформи за вештачку интелигенцију (AI agents platforms) усмерених на C# и .NET деле мали скуп основних компоненти, чак и ако се именовање мало разликује између Azure OpenAI асистената и Microsoft Agent Framework-а. Разумевање ових блокова вам помаже да дизајнирате сопствену архитектуру уместо да слепо копирате исечке.

Асистент или агент је централни AI клијент који користи LLM плус конфигурацију за обраду инструкција, управљање разговорима и позивање алата. У Azure OpenAI асистентима, овај објекат обухвата конфигурацију модела, инструкције и конфигурацију алата. У Microsoft Agent Framework-у, AIAgent Обавија клијента за ћаскање (OpenAI или Azure OpenAI) плус алате и упутства и намерно је без стања како би могао да опслужује више разговора истовремено.

Нит или сесија представља један разговор између корисника и агента, укључујући све поруке и релевантно стање. Azure OpenAI асистенти говоре о теме, који поседују поруке и обрађују аутоматско скраћивање како би се уклопили у контекст модела. Microsoft Agent Framework говори о Сесија агента, који садржи историју и може се серијализовати и чувати. Оба служе истој сврси: праћењу контекста током више потеза.

Поруке су појединачни доприноси унутар нити или сесије, које производе или корисници или асистент. Поруке могу да садрже обичан текст, слике или датотеке, а у API-јима помоћника се чувају као уређене листе унутар нити. На C# страни, обично их преузимате као колекције строго типизираног типа где можете да прегледате текст, напомене и референце на датотеке.

Покретање, извршавање или позивање је једнократна активација агента преко дате нити или сесије. Узимате постојећи контекст, шаљете га моделу заједно са алатима и конфигурацијом и чекате док извршавање не достигне терминално стање. Током извршавања, агент може да генерише нове поруке, позива алате и ажурира стање нити или сесије.

Кораци извршења формирају детаљан траг свега што се догодило током рада агента. Асистент може позвати алатку за претрагу датотека, покренути интерпретер кода или позвати прилагођену функцију више пута док образлаже задатак. Имати структурирани преглед ових корака је невероватно корисно за разумевање зашто је одређени одговор произведен и за касније отклањање грешака или ревизију понашања.

Креирање минималног C# конзолног агента помоћу Azure OpenAI асистента

Да бисте видели ове концепте у акцији, можете покренути минималну .NET конзолну апликацију која користи званичне OpenAI или Azure OpenAI SDK-ове за изградњу асистента који чита податке из датотека и генерише визуелизације. Идеја је да се повеже LLM са претрагом датотека и извршавањем кода, а затим да му се омогући да одговара на аналитичка питања на природном језику.

Први корак је подешавање пројекта: креирајте нову .NET конзолну апликацију и додајте NuGet пакете за OpenAI и Azure.AI.OpenAI. Затим креирате инстанцију главних клијената у Program.cs, било директно за OpenAI или за Azure OpenAI користећи акредитив као што је DefaultAzureCredentialОд OpenAI клијента добијате AssistantClient да управља асистентима и одвојеним OpenAIFileClient за отпремање датотека.

Затим припремате реалне податке са којима ће агент радити тако што ћете креирати документ у меморији, серијализовати га као JSON и стримовати га до клијента датотеке. У примеру, овај JSON кодира неколико месеци продаје производа за фиктивну компанију, мапирајући месеце на количине по производу. Отпремањем са Assistants сврху датотеке, означите је као материјал који агент може да претражује.

Када подаци постоје у систему, конфигуришете асистента путем AssistantCreationOptions да би се омогућила и претрага датотека и алатка за интерпретацију кода. Ви наводите име, скуп јасних упутстава („ви сте асистент који претражује податке о продаји и креира визуелизације када се то од вас затражи“), а затим додајете алате: а FileSearchToolDefinition тако да помоћник може да претражује датотеке, плус CodeInterpreterToolDefinition тако да може да пише и покреће код у заштићеном окружењу за анализу или генерисање графикона.

Да би претрага датотека заиста користила ваш отпремљени продајни документ, повежите га са новим векторским складиштем унутра ToolResources. Помоћник VectorStoreCreationHelper повезује ИД отпремљене датотеке са векторским складиштем које помоћник може семантички да упитује уместо да скенира сирови текст. Ово је лаган, али моћан начин за додавање понашања генерисања проширеног претраживањем.

Са опцијама на месту, креирате асистента тако што прослеђујете циљни модел (на пример gpt-4o) и конфигурацију, а затим покрећете нит разговора са почетном корисничком поруком. Тај први упит би могао бити нешто попут „Како се производ 113045 показао у фебруару? Прикажите његов тренд током времена.“ На крају, позивате CreateThreadAndRun, што истовремено креира нит и покреће извршавање.

Пошто су извршавања по природи асинхрона, конзолна апликација обично испитује извршавање док статус не постане терминалан. Након тога, повлачите поруке нити у растућем редоследу и понављате их: исписујете текст помоћника, приказујете напомене за цитате датотека или генерисане датотеке и преузимате излазе слика помоћу клијента датотека како бисте могли да сачувате графиконе које је произвео интерпретер кода на диск као PNG датотеке.

Крајњи резултат је самостална C# конзолна апликација где један асистент може да претражује структуриране податке о продаји, врши прорачуне помоћу кода и враћа и текстуалне увиде и визуелне графиконе у потпуно аутоматизованој петљи. Овај образац се лепо скалира у веб бекендове или позадинске сервисе када додате перзистентност и аутентификацију.

Дизајнирање робусне архитектуре агента у C#

Када прелазите са демо верзије на праву апликацију, начин на који структурирате своје агенте је подједнако важан као и модел који одаберете. Добра архитектура олакшава тестирање, скалирање, обезбеђивање и еволуцију вашег решења, а да се притом не створи неодржива гомила упита и повратних позива.

Доказана стратегија је третирање агената као специјализованих компоненти, а не као једног мозга који „ради све“. На пример, можете дефинисати једног агента фокусираног на претраживање и верификацију информација, другог агента посвећеног писању и сумирању садржаја, и још једног чији је једини посао интеракција са спољним API-јима или базама података. Ово раздвајање омогућава циљане јединичне тестове, независна имплементирања и прецизније безбедносне мере и ограничења токена.

Стање и меморија брзо постају уска грла ако их третирате као накнадну мисао. Историја разговора расте током времена, а слепо слање целог транскрипта моделу у сваком кораку повећава и латенцију и трошкове. Практичне стратегије укључују периодично сумирање претходних порука, сегментирање разговора у одвојене нити по кориснику или по случају употребе и имплементацију политика сабијања заснованих на семантичком значају тако да се само најрелевантнији делови прошлости детаљно сачувају.

У продукционим сценаријима такође желите трајно складиште меморије како би разговори могли да преживе поновна покретања процеса, кварове или поновна распоређивања. Агентски оквири попут Microsoft Agent Framework-а омогућавају сесије да се серијализују у JsonElement, које можете да унесете у SQL Server, Redis или било које NoSQL складиште. Иста та могућност омогућава ревизијске трагове и усклађеност са прописима јер можете тачно реконструисати какво је стање агент имао када је донео одлуку.

Алати и позиви функција су место где агенти престају да буду пасивни и почињу да обављају користан посао. Излагање изворних C# метода као алата омогућава моделу да позива понашање као што је упитивање CRM-а, покретање аналитике над подацима или покретање токова посла. Сваки алат треба да буде анотиран јасним метаподацима (описи и документација параметара), тако да LLM зна када да га позове и са којим аргументима.

Пошто алат који се не понаша правилно може да прекине целу интеракцију, потребан вам је робустан инжењеринг око њих: валидација уноса, временски ограничења, руковање изузецима и заштитне ограде. Не претпостављајте да модел увек прослеђује савршене аргументе; валидирајте параметре и „санитирајте“ све спољне позиве. Такође, размислите о квотама и ограничењима брзине по алату како бисте избегли прекомерне трошкове или случајно преоптерећење низводних система.

За амбициозне сценарије, вишеагентска оркестрација може откључати могућности које је тешко постићи са једним монолитним агентом. Можете повезати агента „истраживача“ који прикупља и проверава информације, „аналитичара“ који тумачи налазе и „писца“ који их претвара у извештаје, при чему сваки комуницира путем структурираних порука и дели радну површину (као што је дељени документ или складиште знања). Овај образац повећава специјализацију и чини путању доношења одлука пративном када касније треба да прегледате или ревидирате исходе.

Од семантичког језгра и аутоматског генерисања до Microsoft Agent Framework-а

Мајкрософт је обједињавао своје алате за агенте за .NET, обједињујући идеје из Semantic Kernel-а и AutoGen пројекта у нови, обједињени Microsoft Agent Framework (MAF). Овај оквир има за циљ да вам пружи стабилност и функције на нивоу предузећа, а истовремено поједностави начин на који креирате вишеструке агенте и токове рада засноване на графовима.

MAF је тренутно у јавној претпродаји и доступан је и за .NET и за Python под MIT лиценцом. Иако се неки API-ји још увек развијају између кандидата за издање, општи правац је јасан: AIAgents за интелигентно понашање, AgentSessions за управљање стањем и систем тока посла заснован на графовима и извршиоцима за детерминистичкије цевоводе.

У својој суштини, оквир прави разлику између агента и токова рада, од којих је сваки намењен различитим облицима проблема. Агенти су динамички системи који користе LLM-ове за интерпретацију уноса, одлучивање које алате да позову и генерисање одговора. Они се истичу у непредвидивим доменима попут разговора са техничком подршком где корисници могу да питају било шта. Токови посла, насупрот томе, су експлицитни низови корака повезани као графови и користе се када желите детерминистичку, добро дефинисану обраду као што су цевоводи података или ланци одобравања.

Званично упутство се може сумирати као „ако можете имплементирати задатак као стандардну функцију, вероватно вам за њега није потребан агент“. Другим речима, резервишите агенте за домене где заиста не можете унапред дефинисати све кораке и ослањајте се на токове рада или класични код за понављајуће, детерминистичке токове. Комбиновање оба на правим местима је кључно за изградњу одрживих система.

Да бисмо ово конкретизовали, замислите четбота за подршку направљеног као ASP.NET Core 10 API користећи Microsoft Agent Framework. Агент користи клијент за ћаскање (који подржава Azure OpenAI или OpenAI) као свој механизам за расуђивање, а његова главна сврха је да одговори на питања о интерној документацији сачуваној у Markdown датотекама, истовремено одржавајући контекст у више порука од истог корисника.

Занимљиво је да пример може намерно прескочити RAG са уграђивањима, а да и даље остане реалистичан користећи претрагу кључних речи преко равних датотека као почетну тачку. То задржава фокус на томе како MAF структурира агента, алате и сесије уместо да се изгуби у конфигурацији векторске базе података, а истовремено подржава веома вероватне интеракције подршке.

Пет кључних концепата у Microsoft Agent Framework-у

Званични туторијали за MAF организују учење у пет прогресивних идеја које се лепо уклапају у начин на који C# програмери већ размишљају о сервисима и стању. Упознавање са овим концептима вам даје солидну основу за било ког агента кога ћете градити на .NET-у.

Прво долази ваш почетни агент: AIAgent направљен од клијента за ћаскање, инструкција и имена. Упућујете агента на модел ћаскања који пружа AzureOpenAIClient или OpenAI, дајете смернице на нивоу система („ви сте користан асистент за подршку“), а затим позивате RunAsync са корисничким уносом. Кључни детаљ је да је инстанца агента без стања и да може да опслужује више независних разговора истовремено.

Друго су алати, који су једноставно C# методе украшене са атрибути и конвертовани у позивајуће функције путем AIFunctionFactory.Create(). Када се агент покрене, LLM прима шему изведену из тих атрибута и може аутономно да одлучи када и како да позове сваки алат, укључујући аргументе. Овде ваша сопствена пословна логика и екстерне интеграције постају део простора деловања агента.

Трећа је подршка за вишеструке разговоре, коју MAF обавља путем AgentSession објеката. јер AIAgent сам по себи не памти ништа, сваки текући разговор се налази унутар сесије креиране са CreateSessionAsync()Ту сесију враћате на наредне позиве, омогућавајући агенту да прати претходне поруке, корисничке преференције и нерешене проблеме.

Четврто је меморија и истрајност, омогућене чињеницом да се сесије могу серијализовати у JsonElement. То олакшава њихово чување у меморији, Редису, SQL табели или било којој другој меморији коју желите, а затим их реконструишете помоћу DeserializeSessionAsync()За сценарије подршке, то значи да корисник може затворити прегледач и касније наставити исти разговор или да друга инстанца сервиса може без проблема преузети контролу након поновног покретања.

Пети су токови рада, изграђени помоћу WorkflowBuilder када је потребно експлицитно оркестрирати више агената или узастопне кораке обраде. Дефинишете извршиоце као јединице за обраду, повезујете их преко ивица и дозвољавате механизму тока посла да обрађује рутирање и прелазе. У многим конверзационим случајевима вам токови посла уопште неће бити потребни, али они постају изузетно корисни када желите структурирано рутирање, класификацију или кораке „људски интеракција“ око ваших агената.

Имплементација правог бота за подршку са MAF-ом, алатима и сесијама

Конкретан пример који илуструје горе наведене концепте је SupportBot API који подржава ASP.NET Core 10 пројекат. Ова услуга открива HTTP крајњу тачку која прихвата корисничке поруке и идентификатор сесије, делегира образложење AIAgent-у и одржава сесију тако да се контекст сачува кроз све захтеве.

Централни алат у овом сценарију је DocumentationTool који зна како да претражује интерне Markdown датотеке. Његова одговорност је да пронађе релевантне водиче, често постављана питања или приручнике за модуле и врати сегменте текста који помажу агенту да формулише одговор. Атрибути примењени на његове методе нису декоративни; MAF их користи за изградњу шеме функција коју LLM чита, а јасноћа тих описа снажно утиче на то колико ефикасно модел бира и позива алат.

Прагматичан избор дизајна унутар овог алата је враћање свих докумената ако ништа не одговара довољно добро траженој теми. Уместо да оставите агента без икаквог материјала, радије бисте пружили превише контекста и пустили модел да одабере најбоље делове него да халуцинира у вакууму. Овај образац „безбедног повратка“ се често појављује у робусним имплементацијама агената.

SupportAgentFactory затим све повезује тако што узима AzureOpenAIClient, издвајање клијента за ћаскање путем GetChatClient(), прилагођавајући га AsIChatClient() а затим га претворити у AIAgent sa AsAIAgent(). Током овог последњег корака, регистровани алати и инструкције постају део конфигурације агента која се користи за сваку конверзацију. Обично региструјете овог конструисаног агента као синглтон у DI контејнеру тако да може истовремено да опслужује више сесија.

Управљање сесијама је апстрактно иза InMemorySessionStore током развоја, који одржава сесије као JsonElement вредности. Безбедан за нити ConcurrentDictionary је овде довољно да се избегне ручно закључавање. У стварном распоређивању бисте заменили ову имплементацију за складиште које подржава Redis или база података, задржавајући интерфејс нетакнутим, али добијајући трајно складиште и хоризонталну скалабилност.

API површина у Program.cs намерно је једноставан: једна ОБЈАВА /chat крајња тачка која прихвата ИД сесије и корисничку поруку. Руковалац захтева учитава или креира сесију, извршава агента, серијализује ажурирану сесију асинхроно (имајте на уму да SerializeSessionAsync је асинхрон у RC1, чак и ако је рана документација сугерисала другачије), задржава га и враћа одговор асистента клијенту. Са становишта фронтенда, „останак у истом разговору“ једноставно значи слање истог ИД-а сесије при сваком позиву.

Када покренете API и ћаскате са њим, можете гледати како агент носи контекст између потеза баш као и представник људске подршке. Прва порука може да описује проблем са пријављивањем; друго питање, послато са истим ИД-ом сесије, може да се односи на „поново ту грешку“ без поновног навођења свих детаља, а агент и даље одговара кохерентно јер је стање везано за складиште сесије.

Токови посла би почели да зарађују своје место тек када бисте додали функције попут аутоматске класификације намера, усмеравања ка специјализованим агентима (фактурисање, приступ, извештавање) или ескалације ка људском особљу. Затим бисте могли да уведете извршиоца класификације на почетак графа тока посла и повежете га са агентима специфичним за тему или да додате чвор „човек у петљи“ који зауставља аутоматизацију и предаје контекст особи када је поузданост ниска.

Токови посла, режими оркестрације и сарадња више агената

Чак и ван MAF-а, корисно је размислити о томе како су токови посла који садрже агенте оркестрирани, јер њихова структура утиче на латенцију, трошкове и могућност праћења. Постоји неколико уобичајених образаца који се појављују у различитим пројектима и оквирима.

Секвенцијална оркестрација значи да агенти обрађују задатке један за другим, прослеђујући излазе даље. На пример, агент за преузимање прво прикупља релевантну документацију, а затим је прослеђује агенту за анализу, који затим предаје своје налазе агенту за извештавање. Ово је једноставно за размишљање и лако за дебаговање, али по цену веће латенције од почетка до краја.

Истовремена оркестрација покреће више агената паралелно, сваки фокусиран на други аспект проблема. Један агент може израчунати метрике, други може претраживати недавне инциденте, а трећи може проценити утицај на усклађеност, све истовремено. Када заврше, координатор обједињује њихове резултате у један одговор. Овај образац смањује латенцију, али захтева пажљиву контролу ресурса и решавање сукоба.

Токови предаје задатака експлицитно мењају власништво над задатком са једног агента на другог на основу услова или међурезултата. Ако агент за подршку открије да је питање заправо везано за продају, може проследити разговор специјализованом продајном агенту, опционо чувајући историју ћаскања и метаподатке. Ово је посебно корисно у сложеним корисничким путовањима где се одговорност легитимно премешта између тимова.

Подешавања групног ћаскања омогућавају неколико агената да сарађују у заједничком каналу за разговор, размењујући поруке у реалном времену. Сваки агент доноси своју перспективу или скуп алата, а централни оркестратор или LLM модератор може управљати разговором тако да конвергира уместо да се понавља унедоглед. Овај образац је моћан, али захтева јаке заштитне ограде како би се избегла бука и непотребни трошкови.

Коначно, магнетна оркестрација ставља једног „вођу“ или диригента задуженог за усмеравање других. Водећи агент разлаже задатак, распоређује подзадатке одговарајућим стручњацима, а затим синтетише њихове резултате. Ово подсећа на инжењерског менаџера који координира тим програмера и може дати јасне, проверљиве токове у сложеним доменима.

Тестирање, видљивост, контрола трошкова и безбедност

Слање вештачке интелигенције агената у производњу без плана за тестирање, праћење, трошкове и безбедност је рецепт за непријатна изненађења. Иста ригорозност коју примењујете на било коју критичну .NET услугу мора се проширити и на ваш агентски слој, само прилагођена вероватносној природи LLM-ова.

Почните тестирањем алата и путања оркестрације помоћу класичних јединичних и интеграционих тестова пре него што се бринете о понашању модела. Свака C# функција коју агент може да позове треба да буде тестирана независно, са детерминистичким улазима и излазима. Затим дизајнирајте контролисане скрипте за разговор које вежбају комплетне путање интеракције, проверавајући не само коначан одговор већ и који су алати позвани и како се стање развијало.

Посматрачност треба да прати латенцију, потрошњу токена и стопе успеха на различитим рутама извршења. Изузетно је корисно мерити и токене за упите и токене за завршетак по интеракцији, разврстане по току рада, алату или типу корисника, како бисте могли да уочите регресије и скокове трошкова. Дужи разговори су посебно скупи, зато инвестирајте у аутоматско сумирање и интелигентне стратегије скраћивања како бисте одржали контексте једноставнијим.

Безбедност је неоспорна када ваши агенти дођу у контакт са осетљивим подацима или подацима купаца. Требало би да спроведете строгу контролу приступа над алатима и скуповима података које агент може да види, да евидентирате свако позивање алата у сврху ревизије и да покрећете све спољне позиве кроз слојеве за чишћење. Акредитиви никада не би требало да буду уграђени у код; ослањајте се на управљане идентитете, складишта тајних података и уобичајене праксе безбедности у облаку које већ примењујете на микросервисе који нису вештачка интелигенција.

Захтеви за усклађеност такође утичу на то како чувате и обрађујете историју разговора. Пошто сесије и нити могу да садрже личне податке или поверљив садржај, дефинишите политике задржавања, стратегије анонимизације и правила минимизирања података рано. Могућност серијализације и десеријализације сесија агента је моћна, али мора бити уравнотежена са законским и регулаторним обавезама.

Што се тиче трошкова, не потцењујте утицај чак и малих неефикасности на великим размерама. Мале промене у величини упита, учесталости позива алата или броју истовремених агената могу се претворити у велике месечне рачуне. Инструментација система, редован преглед телеметрије и подешавања упита, политике меморије и избор модела су неопходни за одржавање одрживих трошкова током времена.

Имплементација и скалирање су лакши када одвојите контролну раван (где конфигуришете агенте и токове рада) од равни закључивања (где се извршавају стварни позиви модела). Оркестрација заснована на контејнерима, редови чекања за дуготрајне операције и управљане услуге у облаку за LLM хостинг доприносе отпорности. Резултати се затим могу пренети у контролне табле или BI алате попут Power BI-ја како би се затворила петља повратних информација аналитике и показала пословна вредност.

Интегрисани алати као што су AI Toolkit и Azure AI Foundry екстензије за Visual Studio Code могу поједноставити велики део овог животног циклуса. Из уређивача можете истраживати каталоге модела, примењивати моделе хостоване на GitHub-у или локалне моделе путем Ollama-е, упоређивати излазе један поред другог, креирати и покретати евалуаторе, визуализовати резултате у Data Wrangler-у, дизајнирати агенте са системским упитима, повезивати MCP сервере за интеграцију алата и интеракције агената за отклањање грешака. Azure AI Foundry додаје визуелне дизајнере, YAML синхронизацију, генерисање кода за приступ Azure моделима и првокласну интеграцију алата као што су Bing Search и интерпретатори кода.

Када се саберу ови састојци – солидна архитектура агента, промишљено управљање стањем, робусни алати, токови рада засновани на графовима где је потребно, дубинска видљивост и cloud-native имплементација – добијају се C# AI агенти који нису само паметни демо модели већ поуздани делови већих пословних система. Пажљивим дизајном и правилном употребом Azure OpenAI асистената и Microsoft Agent Framework-а, ти агенти могу мерљиво побољшати ефикасност, квалитет информација и аутоматизацију у вашој организацији, а да притом остану одрживи и безбедни.

Повезани чланак:

Еволуција API-ја: Нове границе у интеграцији, безбедности и агентској вештачкој интелигенцији