Agenditööriistade juhtimine AI API lüüsi kaudu: ulatused, kinnitused, eelarved ja kontrolljäljed
Praktiline viitearhitektuur agentide tööriistade haldamiseks AI API lüüsi kaudu: tööriistade registrid, ulatusega võtmed, kinnitusväravad, tööriistapõhised eelarved, MCP lubade loendid ja ühendatud mudeli/tööriista kontrolljäljed.
Agendi risk ei piirdu enam mudeliviipaga. Tootmisagent võib otsida sisemisi faile, teha päringuid kliendikirjetest, helistada MCP-serverisse, käivitada koodi, avada brauseri, saata meili, värskendada CRM-i või käivitada arveldamise töövoo. Juhtimisküsimus on järgmine: millisel kasutajal, võtmel, mudelil, agendil ja tööriistal lubati millist toimingut teha, millise eelarve, kontrolljälje ja tagasipööramisteega?
Kui iga meeskond tegeleb tööriistadele juurdepääsuga oma SDK-koodis, hajub poliitika keskkonnamuutujate, pakkuja armatuurlaudade, rakenduste vahevara ja dokumenteerimata MCP-serverite vahel. Ohutum muster on käsitleda agendi tööriista täitmist juhttasandi probleemina ja jõustada seda AI API lüüsi või standardse tööriistakäivitusmähise kaudu, mida iga agent peab kasutama.
See artikkel eraldab faktid, soovitused ja ennustused. Faktid pärinevad praegustest avalikest juhistest: OWASPi LLM-i rakenduste top 10 sisaldab selliseid riske nagu tundliku teabe avalikustamine, tarneahela haavatavused ja liigne agentuur; NISTi generatiivne tehisintellekti profiil AI riskijuhtimise raamistiku jaoks rõhutab generatiivsete AI riskide kaardistamist, mõõtmist ja juhtimist; OpenAI agendi juhised soovitavad hinnata tööriista riski lugemis-/kirjutamisjuurdepääsu, pöörduvuse, lubade ja finantsmõju alusel; ja MCP autoriseerimisjuhised kasutavad tundlike ressursside ja toimingute jaoks reguleeritud autoriseerimiskontseptsioone. Allpool toodud soovitused on rakendusmustrid, mitte universaalsed nõuded.
Lugeja probleem: juurdepääs mudelile ja tööriistadele on segamini
Paljudes varajastes LLM-i rakendustes vastas API-võti ühele põhiküsimusele: kas see teenus saab kutsuda mudelit? Agendid teevad selle liiga jämedaks. Võti, mis võib saata vestluse lõpetamist, ei tohiks automaatselt eksportida kliendiandmeid, käivitada shellikäske, postitada Slacki, muuta pileteid, sirvida suvalisi veebisaite ega esitada maksemuudatusi.
Haldamiskiht peab vastama täpsematele küsimustele:
- Milline rentnik, tööruum, kasutaja, teenusekonto või edasimüüja klient käivitas?
- Millist mudelit, viipamalli, agendi versiooni ja tööriistaskeemi kasutati?
- Kas taotletud tööriist oli kirjutuskaitstud, pöörduv, pöördumatu, välisele suunatud, rahaline või privilegeeritud?
- Kas taotlejal oli nõutav ulatus?
- Kas hädaolukorrapoliitika nõudis heakskiitu, anti, keeldus, aegus või jäi sellest mööda?
- Mis tööriist maksis, mitu korda seda kutsuti ja kui suur kumulatiivne eelarve alles jäi?
- Millised tõendid on olemas silumise, vastavuse ülevaatuse ja tagasivõtmise kohta?
Altoodud arhitektuur eeldab, et lüüs võtab juba mudelikõnesid vastu. Tööriista täitmise saab seejärel suunata läbi sama lüüsi, külgkorvi teenuse või standardse teegi, mis annab lüüsile aru enne ja pärast iga tööriista kutset.
Viitearhitektuur: lüüsi tasemel tööriista halduskiht
Praktilise agendi juhtimissüsteemil on seitse komponenti:
- Tööriistaregister: heakskiidetud tööriistade, MCP-serverite, hostitud funktsioonide, kohalike täitmistööriistade ja sisemiste API-de autoriteetne loend.
- Identity ja võtmekiht: lüüsivõtmed, kasutajad, rentnikud, teenusekontod, meeskonnad ja edasimüüjate kliendid.
- Ulatusala mootor: eeskirjade kontrollimine, mis otsustab, kas võti või kasutaja saab konkreetse tööriista funktsiooni käivitada.
- Riski klassifikaator: metaandmed, mis kirjeldavad plahvatuse raadiust, andmete tundlikkust, pöörduvust, välismõju ja kokkupuudet kuludega.
- Kinnitamise töövoog: inimese või süsteemi heakskiit kõrge riskiga toimingute jaoks enne täitmist.
- Eelarve ja intressilimiidi pearaamat: tööriista- ja agendipõhised piirangud, mitte ainult mudelipõhised märgipiirangud.
- Auditeerimis- ja jälgimissalv: mudelikutsete, tööriistakutsete, kinnituste, vigade ja tulemuste ühendatud kirjed.
Oluline disainiotsus on muuta lüüsist poliitika otsustamise punkt, isegi kui tegelik tööriist töötab mujal. Näiteks võib brauseri tööriist käivitada liivakasti töötajas ja CRM-i kirjutamine võib käivituda siseteenuse sees. Lüüs hindab endiselt, kas kõne on lubatud, salvestab otsuse, jälgib kulusid ja tagastab allkirjastatud volitus- või keeldumisotsuse.
1. samm: looge tööriistade keskregister
Tööriistaregister on inventar, mis takistab "tundmatu agendi võimekuse" muutumist vaikeväärtuseks. Igal tööriistal peaks olema omanik, riskitasand ja töö metaandmed. Minimaalne registrikirje võib välja näha selline:
MCP-serverite puhul peaks register sisaldama ka serveri URL-i, reklaamitud tööriistu, skeemi versiooni, autoriseerimismeetodit, viimast ülevaatuse kuupäeva ja seda, kas uued tööriistad on vaikimisi keelatud. MCP parandab koostalitlusvõimet, kuid protokolli ühilduvus ei ole sama, mis tootmisluba. Tundlikud ressursid ja toimingud vajavad siiski selget ulatust, marsruudi kontrollimist ja rentnike isoleerimist.
Soovitatud registriväljad
- Tööriista nimi, kanooniline ID, omanik ja valvekontakt.
- Täitmise asukoht: hostitud pakkuja tööriist, MCP-server, sisemine API, brauseri töötaja, koodikäitaja, järjekorratöö või kohalik SDK tööriist.
- Lubatud rentnikud, meeskonnad, kasutajad, agendiversioonid ja mudeliprofiilid.
- Andmete klassifikatsioon: avalikud, sisemised, kliendi metaandmed, kliendi sisu, saladused, makseandmed, mandaadid, reguleeritud andmed.
- Riskitasand ja pöörduvus.
- Nõutavad ulatused ja kinnituseeskirjad.
- Ajalõpud, kiiruspiirangud, maksimaalne kõnede arv ühe jooksu kohta, käitamise kumulatiivne eelarve ja maksimaalne kõne hind.
- Logistamisrežiim: täielik kasulik koormus on keelatud, redigeeritud, räsitud, proovid võetud või selgesõnaliselt säilitatud.
- Tagastusjuhised ja eskalatsioonitee.
2. samm: eraldage mudeli ulatused tööriistade ulatustest
Tootmise lüüsi võti peaks väljendama seda, mida helistaja teha saab. Juurdepääs mudelile ja tööriistadele peaksid olema sõltumatud. Näiteks:
mudel:vestlus
mudel: manused
tool:docs.search_readonly
tool:crm.create_ticket
tool:email.send_requires_approval
tool:billing.refund_blocked
tool:code.execute_blockedSee hoiab ära madala riskitasemega vestlusrobotite muutumise juhuslikuks automatiseerimisagendiks. See toetab ka rollimalle:
- Arendaja assistent: mudelivestlus, dokumentatsiooniotsing, koodi selgitus, tootmise kirjutamise tööriistad puuduvad.
- Tugibot: klientide otsimine, piletite loomine, vastuse koostamine, välise saatmise jaoks vajalik kinnitus.
- Analüütik: kirjutuskaitstud andmelao päringud reapiirangutega, vaikimisi kliente ei ekspordita.
- Administraatori agent: kitsad privilegeeritud toimingud, tugev heakskiit, lühiajalised võtmed, täielik audit.
- Edasimüüja rentniku agent: rentniku ulatusega juurdepääs mudelile, rentniku ulatusega tööriistad, kliendipõhised eelarve ülemmäärad.
Soovitus on tõrgeteta sulgemine: tundmatud tööriistad keelatakse, puuduvad ulatused keelavad täitmise, äsja reklaamitud MCP-tööriistad on passiivsed kuni kinnitamiseni ja kohalikud tööriistad peavad kasutama hostitud tööriistadega sama poliitikaümbrist.
3. samm: klassifitseerige tööriistad plahvatuse raadiuse järgi
Iga tööriistakutse ei vaja inimese heakskiitu. Juhtimine peaks olema proportsionaalne riskiga. Kasulik klassifitseerimismudel on:
See klassifikatsioon peaks olema nähtav koodi ülevaatamisel ja administraatori kasutajaliideses. Tööriistakirjeldustest üksi ei piisa, sest agendid võivad käsitleda kirjeldusi kui juhiseid. Poliitikamootor peaks tuginema registri metaandmetele ja ulatustele, mitte ainult loomulike keelte tööriistanimedele.
4. samm: lisage kõrge riskiga toimingute heakskiitmisväravad
Kinnitus peaks olema suunatud. Kui iga tööriistakõne nõuab inimest, muutub agent kasutuskõlbmatuks. Kui ükski tööriistakutse ei nõua heakskiitu, võib süsteem anda liigse volituse.
Üldine kinnitusvoog:
- Agent taotleb tööriistakutset struktureeritud argumentidega.
- Lüüs hindab identiteeti, ulatust, riskitaset, eelarvet ja poliitikat.
- Kui kinnitus on nõutav, tagastab lüüs tööriista käivitamise asemel ootel kinnitamise sündmuse.
- Rakendus näitab kasutajale eelvaadet või saadab kinnituskanalile operatsiooniteate.
- Kinnitaja võib argumente kinnitada, tagasi lükata, redigeerida, kui eeskirjad lubavad, või nõuda selgitusi.
- Lüüs salvestab otsuse ja täidab ainult kinnitatud versiooni.
Kinnituskoormus peaks näitama toimingut inimlikult, mitte ainult töötlemata JSON-i:
Kinnitamine on kõige kasulikum välissuhtluseks, finantstoiminguteks, pöördumatuks kirjutamiseks, privilegeeritud haldamiseks ja ulatuslikuks andmete eksportimiseks. Tavaliselt pole see väikesemahulise avaliku dokumentatsiooni otsimiseks vajalik.
5. toiming: jälgige tööriistade eelarveid ja määrade piirmäärasid
Token-eelarvetest ei piisa. Odav mudel võib käivitada kulukaid otsinguid, brauseri seansse, koodikäitamist, kolmanda osapoole API-kõnesid või pikki tööriistasilmuseid. Lüüs peaks jälgima vähemalt nelja loendurit:
- Tööriistapõhine kõnede arv: maksimaalne kõnede arv käitamise, kasutaja, rentniku ja ajaakna kohta.
- Tööriista hind: otsesed kolmanda osapoole tasud, brauseri/käitusaja kulu, otsingukulu või sisemine tagasimakse prognoos.
- Agendi käitamise kumulatiivne kulu: mudelimärgid pluss tööriistakulud.
- Silmuse sügavus: mudel-tööriist-mudel iteratsioonide maksimaalne arv.
Kui piir on saavutatud, peaks lüüs võimaluse korral vältima vaikset rasket riket. Ohutumad halvenemismustrid hõlmavad edenemise kokkuvõtte tagastamist, jätkamiseks heakskiidu küsimist, otsingusügavuse vähendamist, taustatöö järjekorda seadmist või kirjutuskaitstud režiimile lülitumist. Range keelamine on endiselt sobiv blokeeritud tööriistade, puuduvate ulatuste, tundmatute MCP-võimaluste ja ohtlike toimingute puhul.
6. samm: ühendage mudeli ja tööriista telemeetria üheks auditikirjeks
Agendi silumine ebaõnnestub, kui mudelilogid asuvad ühes kohas ja tööriistalogid asuvad mujal. Auditikirje peaks ühendama kogu ahela:
- Üürnik, tööruum, kasutaja, teenusekonto ja lüüsi võti.
- Agendi ID, agendi versioon, viipamalli versioon ja mudeli ID.
- Tööriista nimi, registriversioon, serveri URL või täitmiskeskkond ja skeemi räsi.
- Tööriista sisendi räsi või redigeeritud sisend, vaikimisi mitte kunagi töötlemata tundlikke kasulikke koormusi.
- Kinnitusolek, kinnitaja identiteet, kinnitamise ajatempel ja kinnitatud argumendi räsi.
- Laitentsus, korduskatsed, pakkuja vead, tööriista vead, märgi maksumus, tööriista maksumus ja lõpptulemus.
- Tagasi viide, kui toimingu olekut muudeti.
OpenAI agentide SDK jälgimisdokumentatsioon sisaldab jälgi LLM-i põlvkondade jaoks, tööriistakutseid, üleandmisi, kaitsepiirdeid ja kohandatud sündmusi, mis toetab laiemat jälgitavuse põhimõtet: agendijäljed peaksid hõlmama tööriista tegevust, mitte ainult märgi kasutamist ja latentsust. Üks SDK konveier ei pruugi siiski katta kõiki hostitud tööriista, kohalikku täitmisteed või sisemist API-t. Lüüsitaseme audit aitab normaliseerida pakkujate ja raamistike kirjeid.
Privaatsus on oluline. Üksikasjalikud logid parandavad silumist ja vastavuse ülevaatamist, kuid töötlemata viipe ja tööriista kasuliku koormuse säilitamine võivad tekitada uue turbekohustuse. Redigeerige või räsige sisendeid, mis sisaldavad saladusi, mandaate, makseandmeid, isikuandmeid või omandiõigusega kaitstud dokumente. Salvestage toorkoormus ainult selgesõnaliste säilitamisreeglite, juurdepääsu juhtelementide ja kustutamisreeglite alusel.
7. samm: käsitlege MCP-servereid ja kolmanda osapoole tööriistu tarneahela sõltuvustena
MCP-serverid ja kolmanda osapoole tööriistad peaksid läbima sama ülevaatusprotsessi nagu teegid, veebihaagid ja infrastruktuuri sõltuvused. Soovitatavad juhtelemendid on järgmised:
- Hoidke lubatud MCP-serverite ja tööriistade lähtekohtade loendit.
- Võimalusel kinnitage versioonid ja salvestage skeemi räsid.
- Nõua omanikku igale serverile ja kõrge riskiga tööriistale.
- Enne lubamist vaadake üle tööriistade nimed, kirjeldused, skeemid ja loanõuded.
- Keela äsja lisatud tööriistad kuni ülevaatamiseni.
- Kinnitage nõutavad ulatused marsruudi või võimaluse kohta.
- Eraldage üürniku mandaadid ja vältige klientide vahel jagatud lubasid.
- Käitage ebausaldusväärseid või kõrge riskiga tööriistu võrgu- ja failisüsteemipiirangutega liivakastides.
Asjaolu, et tööriist avaldatakse standardprotokolli kaudu, ei muuda seda ohutuks. Halduskiht vajab endiselt kõige vähem privileege, selgesõnalist volitust, versioonikontrolli ja kontrollitavust.
Rakendamise kontroll-loend
Eeskirjade kujundus
- Määratlege tavaliste agendikasutajate ja teenusekontode jaoks rollimallid.
- Looge mudelikutsete ja tööriistakutsete jaoks eraldi ulatused.
- Klassifitseerige tööriistad andmete tundlikkuse, pöörduvuse, välismõju, finantsmõju ja privileegide taseme järgi.
- Määrake tundmatute tööriistade ja puuduvate ulatuste jaoks vaikimisi keelamine.
- Määratlege heakskiidureeglid ainult kõrge riskiga toimingute jaoks.
Lüüsi jõustamine
- Nõuge, et iga agent helistaks tööriistadele lüüsi või allkirjastatud poliitikaümbrise kaudu.
- Enne käivitamist kontrollige rentniku, kasutaja, võtme, agendi, mudeli, tööriista, ulatuse, eelarve ja kinnitusoleku olekut.
- Jõustage maksimaalne tööriistakutsingu sügavus ja kumulatiivne käitamiskulu.
- Salvestage iga kõne jaoks tööriista registriversioon ja skeemi räsi.
- Ebaõnnestunud sulgemine, kui poliitikamootor ei suuda otsust teha.
Audit ja toimingud
- Ühendage mudelikutsed ja tööriistakutsed ühe jälje või agendi käitamise ID all.
- Vaikimisi muutke või räsitundlikke tööriistasisendeid.
- Hoidke heakskiitmise tõendid koos lõpliku täitmiskirjega.
- Avaldage administraatoritele tööriistapõhiseid kulusid ja piirmäärade analüüse.
- Olekut muteerivate tööriistade tagasipööramise omanikud.
Oodata kompromisse
Järjepidevus versus integreerimispüüdlus. Lüüsitaseme juhtimine tagab järjepideva jõustamise mudelite, SDK-de ja meeskondade lõikes. Maksumus on kasutuselevõtt: arendajad peavad tööriista käivitamise suunama kinnitatud tee kaudu, selle asemel, et tööriistu otse rakenduse koodist välja kutsuda.
Vähimad privileegid versus poliitika keerukus. Peeneteralised ulatused vähendavad plahvatuse raadiust, kuid need nõuavad malle, nimetamise tavasid ja regulaarset puhastamist. Ilma mallideta võivad meeskonnad kiiremini liikumiseks lubasid üle anda.
Kinnitus versus autonoomia. Inimese heakskiit vähendab pöördumatute toimingute riski, kuid lisab latentsust. Kasutage kõrge riskiga tööriistade kinnitusi, mitte iga otsingu või otsingu puhul.
Auditatavus versus andmete eksponeerimine. Rikkalikud logid aitavad intsidentidele reageerida ja siluda. Toores kasuliku koormuse logimine võib paljastada saladusi ja isikuandmeid. Redigeerimine, räsimine, konfigureeritav säilitamine ja juurdepääsu ülevaatus ei ole valikulised üksikasjad.
Kõrvad piirangud versus ülesande lõpetamine. Tööriistapõhised kulupiirangud takistavad agentide põgenemist. Samuti võivad nad katkestada seadusliku pikaajalise töö. Esitage jätkamisteed, nagu kinnitamine jätkamiseks, taustajärjekorrad või summeeritud osatulemused.
Ennustused: kuhu see muster liigub
Ennustus: agendi juhtimine muutub identiteedikesksemaks. Meeskonnad küsivad harvemini: "millist mudelit see kasutas?" ja sagedamini "milline autentitud isik või teenus lubas selle tööriista toimingu?"
Prognoos: tööriistaregistrid muutuvad sama normaalseks kui mudeliregistrid. Kuna MCP-serverid, sisemised API-d ja hostitud tööriistad paljunevad, vajavad tootmismeeskonnad lubatud võimaluste, omanike, skeemide ja riskitasemete loendit.
Prognoos: kulude juhtimine liigub ainult märgipõhiselt aruandluselt tegevustasandi aruandlusele. Agendi käitamise kõige kallim osa võib olla pigem otsimine, brauseri automatiseerimine, koodi täitmine või kolmanda osapoole API-d, mitte mudeli kutse ise.
Tehtitav järeldus
Alustage ühe reegliga: mudeliklahv ei ole tööriistaklahv. Seejärel ehitage väljapoole. Looge heakskiidetud tööriistade register, määrake omanikud ja riskitasemed, nõudke selgesõnalisi ulatuseid, lisage kinnitusi ainult siis, kui toimingul on tähenduslik löögiraadius, jõustage tööriistapõhised eelarved ning ühendage mudeli ja tööriista sündmused üheks kontrolljäljeks.
Eesmärk ei ole muuta agente jõuetuks. Eesmärk on muuta nende võim loetavaks, reguleeritavaks, võimaluse korral pööratavaks ja vastutavaks. See on meeskonna API haldamise praktiline alus, kuna agendid liiguvad küsimustele vastamiselt meetmete võtmiseni.