![]()
Kursuse selleks hetkeks oled ehitanud agente, kes töötavad sinu sülearvutis, märkmetes, juhituna az login ja mõne keskkonnamuutujaga. See on täiesti õige viis õppimiseks. See pole aga õige viis agenti käivitada, kellele tuhanded kliendid sõltuvad kell 3 öösel.
See õppetund käsitleb lõhet „see töötab minu masinas“ ja „see töötab usaldusväärselt ja taskukohaselt tootmises“ vahel. Sulgeme selle lõhe, kasutades Microsoft Foundry ja Microsoft Foundry Agent Service teenuseid, ning teeme seda, luues tõelise klienditoe agendi, millel on tööriistad, otsing, mälu, hinnang ja seire.
See õppetund käsitleb:
Pärast selle õppetunniga lõpetamist oskad:
Eeldatakse, et oled lõpetanud varasemad õppetunnid ja oled mugav järgmistes:
Sul on vaja ka:
az login).requirements.txt.Prototüüp-agent ja tootmisagent jagavad sama põhitsüklit — mõtlemine, tööriistade kutsumine, vastamine. Muu kõrvutav on aga erinev. Mudel moodustab tootmisagendist ehk 20%, ülejäänud 80% on operatiivne karkass.
| Teema | Prototüüp | Tootmine |
|---|---|---|
| Majutamine | Jookseb sinu märkmetes | Jookseb majutatud teenusena, versioonitud ja välja lastud |
| Identiteet | Sinu az login token |
Hallatud identiteet koos ulatusliku RBAC-iga |
| Olek | Mälus, kaob taaskäivitusel | Välise teenuse poolt hallatud (niidipood, mäluteenistus) |
| Rikked | Näed virna tagasikutset | Taaskatsed, varuplaanid, surnukirjad, hoiatused |
| Kulu | „See on paar senti“ | Jälgitakse iga päringu kohta, marsruuditakse, vahemällu salvestatakse, eelarvestatakse |
| Kvaliteet | Silmaga kontrollid väljundit | Hinnatakse automaatselt iga väljaande eel |
| Usaldus | Sa kiidad iga toimingu heaks | Poliitika + inimtõendusega riskantsete toimingute jaoks |
Hoia seda tabelit meeles. Alljärgnevad jaotised vastavad ühele selle tabeli reale.
Sa kasutad kolme mustrit, sageli koos:
Agent elab sinu rakenduse protsessis. Sinu kood kutsub mudeli pakkujat otse; mõtlemistsükkel jookseb sinu teenuses. Kõik varasemad õppetunnid on töötanud nii.
Agent registreeritakse Microsoft Foundry ressurssina. Foundry majutab mõtlemistsükli, salvestab niidid, tagab sisuturvalisuse ja RBAC-i ning teeb agendi nähtavaks Foundry portaalis. Sinu rakendus muutub õhukeseks kliendiks, mis loob niite ja loeb vastuseid.
Mitmed agendid (ja tööriistad) on koondatud graafikusse selge kontrollvooga — järjestikused sammud, haruvalikud, inimtõenduse sõlmed ja vastupidavad kontrollpunktid, mis võivad peatuda ja jätkata. See on Microsoft Agent Frameworki Workflows võimekus, rakendatuna juurutusmastaabis.
flowchart TB
subgraph P1[Klient-hostitud]
A1[Sinu rakenduse protsess] --> M1[Mudeli pakkuja]
end
subgraph P2[Hostitud agent]
A2[Õhuke klient] --> F2[Foundry agendi teenus]
F2 --> M2[Mudel + Tööriistad + Jutulõimede pood]
end
subgraph P3[Agendi töövoog]
A3[Orkestreerija] --> S1[Tripeerimise agent]
S1 --> S2[Lahendaja agent]
S2 --> H[Inimese kinnituse sõlm]
H --> S3[Tegevusagent]
end
Agendi juurutamine ei ole ühekordne push. See on tsükkel, mis sarnaneb väga tarkvara väljaandetsükliga, sest see ongi täpselt see.
flowchart LR
Create[Loo / Autor] --> Version[Versioon]
Version --> Evaluate[Hinda võrguühenduseta]
Evaluate -->|läbib värava| Deploy[Paigalda majutatud]
Evaluate -->|ei läbi väravat| Create
Deploy --> Observe[Jälgi veebis]
Observe --> Improve[Kogu tõrked]
Improve --> Create
Deploy --> Retire[Võta vanem versioon kasutusest maha]
Põhiidee, mis on võetud üle õppetunnist 10: offline hindamine on värav, mitte mõttetu samm. Uut agenti ei tarnita, kui see ei läbi sinu hindamiskünniseid. Veebi jälgitavus toob siis reaalsete vigade tagasiside sinu offline testikomplektile. See ongi kogu tsükkel.
Agendi skaleerimine erineb olekuta veebipõhise API skaleerimisest, sest iga päring võib esile kutsuda mitu kulukat mudeli ja tööriista kutsumist. Neli tehnikat kannavad enamikku koormusest.
Olekuta päringute töötlemine. Ära hoia protsessi mälus ühtki kasutaja spetsiifilist olekut. Säilita vestlusniidid Foundry niidipoes või mäluteenistuses, nii et iga näidis saab igat päringut töödelda. See võimaldab sul horisontaalselt skaleerida — lisa näidiseid, ilma kleepuvate sessioonideta.
Mudeli marsruutimine. Igas päringus ei ole vaja kasutada kõige võimekamat (ja kõige kallimat) mudelit. Suuna lihtsad päringud — kavatsuse klassifitseerimine, lühikesed faktilised vastused — väikesele ja kiirusele mudelile ning suurem mudel reserveeri tõelisele mõtlemisele. Foundry Model Router suudab seda sinu eest teha, või saad ise ehitada kergekaalulise klassifikaatori. Laboris ehitad selle DIY versiooni.
Vastuse vahemällu salvestamine. Paljud tugipäringud on peaaegu topeltpäringud („kuidas ma oma parooli resetin?“). Vahemälu ühistele küsimustele ja serveeri vastuseid ilma mudelit üldse kutsumata. Isegi tagasihoidlik vahemälu tabamuse määr vähendab oluliselt kulusid ja latentsust.
Samaaegsus ja tagasurve. Mudelite pakkujatel on kiiruspiirangud. Piira oma samaaegsust, kasuta eksponentsiaalset tagasipöördega katsetamist ja ebaõnnestumisel käitu väärikalt (järjekorda pandud „me töötame selle kallal“ vastus on parem kui 500 veateade).
flowchart LR
Q[Kasutaja päring] --> C{Vahemälu tabamus?}
C -->|jah| R[Tagasta vahemälus olev vastus]
C -->|ei| Router{Kompleksus?}
Router -->|lihtne| SLM[Väike mudel]
Router -->|keeruline| LLM[Suur mudel]
SLM --> Out[Vastus]
LLM --> Out
Out --> Store[Vahemälu + jälg]
Sa ei saa juhtida, mida sa ei näe. Nagu õppetunni 10 alguses käsitleti, Microsoft Agent Framework eraldab loomupäraselt OpenTelemetry jälgi — iga mudeli kutse, tööriista kutsumine ja orkestreerimisaste muutub jälgialaks. Tootmises ekspordid need jäljed Microsoft Foundry (või mõne OTel-ühilduva tagasuunaga), et saaksid:
from agent_framework.observability import get_tracer
tracer = get_tracer()
with tracer.start_as_current_span("support_request") as span:
span.set_attribute("customer.tier", "enterprise")
span.set_attribute("routed.model", "gpt-5-nano")
# agendi täitmist jälgitakse selles ulatuses automaatselt
Atribuudid nagu customer.tier ja routed.model muudavad jälgede kogumi vastatavateks küsimusteks („kas ettevõttekliendid suunatakse liiga sageli väikesele mudelile?“).
Tootmisagentide kulusid mõjutavad domineerivalt sümbolid (tokens). Kolm hoobasid, mõjususjärjestuses:
Hindamisväravad ja kulude kontroll on sama distsipliini kaks vaadet: hindamine ütleb kvaliteedi põranda, marsruutimine ja vahemälu hoiavad sind võimalikult selle põranda kulu lähedal.
Juhtimine. Hosted Agents pärivad Foundry RBAC, sisuturvalisuse ja auditeerimislogimise. Iga agendi jaoks anna hallatud identiteet vähima õigusega, mida vaja — lugemisõigus teadmistebaasile, piiritletud ligipääs piletite API-le, mitte midagi rohkemat.
Inimene kaasatud. Mõned toimingud on liiga tagajärjerikkad automaatseks tegutsemiseks — tagasimakse tegemine, konto kustutamine, õigusmeeskonnale eskaleerimine. Microsoft Agent Framework toetab heakskiidu nõudvaid tööriistu: agent teeb ettepaneku, täideviimine peatub, inimene kiidab heaks või lükkab tagasi ning töövoog jätkub. Seda primitiivi nägid sa õppetunnis 6; siin sa seda juurutad.
MCP tootmises. MCP lubab agentidel tarbida väliseid tööriistu standardliidese kaudu. Tootmises käsitle iga MCP serverit kui usaldamatut piiri: paiguta serveri versioon, käivita see piiratud identiteediga, valideeri väljundid ja ära kunagi avalikusta talle saladusi. MCP server on sõltuvus, mida parandatakse, auditeeritakse ja millele kehtestatakse kiiruspiirangud.
flowchart TB
subgraph Dev[Arenduse arhitektuur]
D1[Märkmik] --> D2[Agendi raamistik]
D2 --> D3[Mudelipakkuja]
D2 --> D4[Kohalikud tööriistad]
end
subgraph Deploy[Paigaldusarhitektuur]
E1[CI torujuhe] --> E2[Hinnangulukk]
E2 -->|läbimise| E3[Foundry agenditeenus]
E3 --> E4[Versioonitud majutatud agent]
end
subgraph Run[Käituse arhitektuur]
F1[Kliendi rakendus] --> F2[Majutatud agent]
F2 --> F3[Mudeliraouter]
F2 --> F4[Azure AI otsing RAG]
F2 --> F5[Mälu teenus]
F2 --> F6[MCP tööriistad]
F2 --> F7[OTel -> Foundry jälgimine]
F2 --> F8[Inimese heakskiit]
end
Need kolm diagrammi — arendus, juurutus, jooksvaaja — kujutavad sama agenti kolme elufaasi. Järgmine labor juhendab sind selle ehitamise juures.
Ava code_samples/16-python-agent-framework.ipynb ja tee see lõpuni läbi. Koostatakse Contoso klienditoe agent, mille iga tootmisküsimus on lahendatud:
Märkmik on organiseeritud nii, et iga tootmisküsimus on iseseisev jooksutatav plokk. Selle süda on marsruutimise- ja vahemälu päringukäsitleja:
async def handle_support_request(query: str, customer_id: str) -> str:
# 1. Teenindage vahemälust, kui saame.
cached = response_cache.get(normalize(query))
if cached:
return cached
# 2. Marsruutige keerukuse järgi kulude kontrollimiseks.
model = "gpt-5-nano" if is_simple(query) else "gpt-5-mini"
# 3. Käivitage agent jälgimisalal jälgitavuse jaoks.
with tracer.start_as_current_span("support_request") as span:
span.set_attribute("routed.model", model)
span.set_attribute("customer.id", customer_id)
response = await support_agent.run(query, model=model)
# 4. Vahemälu ja tagasta.
response_cache.set(normalize(query), response.text)
return response.text
Hindamisvärav, mis kaitseb väljaannet, näeb välja selline:
async def evaluation_gate(agent, test_cases, threshold: float = 0.8) -> bool:
passed = 0
for case in test_cases:
result = await agent.run(case["input"])
if score_response(result.text, case["expected"]) >= 0.8:
passed += 1
pass_rate = passed / len(test_cases)
print(f"Evaluation pass rate: {pass_rate:.0%} (gate: {threshold:.0%})")
return pass_rate >= threshold # rakenda ainult siis, kui värav läbib
Loe iga rida läbi — märkmik hoiab primitiivid tahtlikult väikestena, nii et miski pole raamistikukutse taha peidetud.
Ülaltoodud hindamisvärav jookseb offline sinu agentobjekti vastu. Kui agent on juurutatud Hosted Agentina, vajad veel üht veel odavamat kontrolli: kas juurutatud lõpp-punkt vastab tegelikult?
„Õnnestunud“ juurutamine tõestab ainult, et juhtimistasand aktsepteeris definitsiooni — see ei tõesta, et agent vastab. Puuduv sõltuvus, halb mudelimarsruut või aegunud ühendus võivad jätta rohelist valmimist, mis ei tagasta midagi. Suitsutest tabab selle sekunditega, iga juurutuse järel, ilma täishindamise kuluta.
See hoidla sisaldab kasutusvalmis suitsutesti torujuhtme, mis põhineb AI Smoke Test GitHub Actionil:
tests/lesson-16-smoke-tests.json sisaldab küsimusi ja väiteid Contoso tugiteenuse agendi kohta (toetatud poliitikavastused, tellimuste otsing, teemast kinni pidamine ja mitme intervjuu niidi järjepidevus). Teiste õppetundide agentide kataloogid asuvad selle kõrval — vaata tests/README.md..github/workflows/smoke-test.yml logib sisse Azure OIDC-ga ja POSTitab iga küsimuse agendi Responses lõpp-punkti, ebaõnnestudes töö igal tõrkel.- name: Smoke-test hosted agent
uses: JFolberth/ai-smoketest@v1
with:
project_endpoint: $
agent_name: ContosoSupportAgent
tests_file: tests/lesson-16-smoke-tests.json
Käivitage see vahekaardilt Tegevused (Actions), kui teie agent on juurutatud, andes sisse oma Foundry projekti lõpp-punkti ja agendi nime. Föderaalne identiteet vajab Foundry projekti ulatuses rolli Azure AI kasutaja. Mõelge kihtidele kui püramiidile: suitsutestid (kas on ligipääsetav ja reageerib?) jooksevad iga juurutuse korral, võrguühenduseta hindamine (kas piisav saatmiseks?) jookseb enne edutamist ja võrguhindamine (kuidas see metsikus toimib?) jookseb pidevalt.
Testige oma arusaamist enne ülesandega edasi liikumist.
1. Umbes kui suur osa tootmisagendist on “mudel” ja mis on ülejäänu?
2. Millal valiksite majutatud agendi kliendiagenti asemel?
3. Miks peab mastaapiv agent olema oma protsessimälus seisundita?
4. Millist probleemi lahendab mudelite marsruutimine ja kuidas see seostub hindamisega?
5. Mis on “hindamisvärav” ja kus see elutsüklis asub?
6. Miks peaks MCP serverit tootmiskeskkonnas käsitlema usaldamatuna piirinahana?
7. Milline üksik muudatus avaldab tavaliselt suurimat mõju tootmisagendi kuludele ja miks?
8. Millist rolli mängivad jälgimisomadused nagu customer.tier ja routed.model jälgitavuses?
Võtke laborist klienditoe agent ja tugevdage seda konkreetseks stsenaariumiks: tellijaarvestuse tugipersonal SaaS ettevõttele.
Teie esituses peaks olema:
get_subscription_status, get_invoice ja issue_credit (krediidid üle 50 dollari nõuavad inimheakskiitu).Kirjutage lühike lõik (markdowni lahtrisse), selgitades, millise mudelite marsruutimise reegli valisite ja kuidas te selle reaalse liiklusega valideeriksite. Õigeid vastuseid pole üks; teid hinnatakse selle järgi, kas tootmisküsimused on sidusalt kokku seotud.
Selles õppetükis viisite agendi prototüübist tootmisse Microsoft Foundry abil:
Järgmine õppetükk läbib vastupidise tee: selle asemel, et agendi pilve üles skaleerida, toote selle alla ühe arendajamasina peale ja käivitate täielikult lokaalselt.
Arvutikasutusagentide ehitamine (CUA)
Lokaalsete tehisintellekti agentide loomine
Lahtiütlus: See dokument on tõlgitud kasutades AI tõlketeenust Co-op Translator. Kuigi me püüdleme täpsuse poole, palun pange tähele, et automatiseeritud tõlgetes võib esineda vigu või ebatäpsusi. Originaaldokument selle emakeeles tuleks pidada autoriteetseks allikaks. Olulise teabe puhul soovitatakse kasutada professionaalset inimtõlget. Me ei vastuta selle tõlkega seotud eksimustest või valesti mõistmistest.