MCP įrankių dizainas: agentui negalima duoti šveicariško peilio be taisyklių
AWS liepos 9 d. aptarė praktinius MCP įrankių dizaino pasirinkimus ir kompromisus DI agentams.
Šiame straipsnyje · 6 dalys
- Kas yra MCP? Model Context Protocol – būdas DI agentams jungtis prie išorinių įrankių ir duomenų.
- Kodėl svarbus įrankių dizainas? Nes blogai aprašyti arba per platūs įrankiai didina klaidų ir saugumo riziką.
- Ką daryti pirmiausia? Susiaurinti agento įrankius iki konkrečių, lengvai tikrinamų veiksmų.
MCP įrankių dizainas skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?
AWS liepos 9 d. paskelbė tekstą apie MCP įrankių dizainą. Skamba kaip programuotojų tema, bet verslui čia labai praktiškas klausimas: kokius įrankius duodame agentui ir kaip nepadarome iš jo šveicariško peilio be instrukcijos.
Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?
Kas nutiko
MCP leidžia DI agentams jungtis prie išorinių įrankių, duomenų ir sistemų per standartizuotą sąsają. AWS tekste aptariama, kaip kurti įrankius, kokio dydžio funkcijas duoti agentui ir kokius kompromisus rinktis.
Kai žmogui duodi įrankį, jis bent jau mato, ką laiko rankoje. Agentui įrankis yra aprašymas, schema ir leidimas veikti. Jei aprašymas prastas, agentas gali naudoti įrankį ne taip, kaip jūs tikėjotės.
Kodėl tai svarbu
MCP įrankių dizainas svarbus todėl, kad agento kokybė priklauso ne tik nuo modelio. Ji priklauso nuo to, ar įrankiai aiškūs, siauri, patikrinami ir su geromis klaidų žinutėmis.
DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.
Ką tai reiškia verslui
Verslui tai reiškia, kad DI projektams reikės procesų savininkų ir techninės komandos dialogo. Vieni žino darbą, kiti žino sistemas. Agentui reikia abiejų.
- kurti siaurus įrankius konkrečioms užduotims
- aiškiai aprašyti įvestis ir išvestis
- grąžinti suprantamas klaidas
- neduoti rašymo teisių, jei užtenka skaitymo
Pavyzdys: vietoj vieno įrankio „tvarkyk klientą“ geriau turėti atskirus veiksmus: rasti klientą, gauti sąskaitas, paruošti juodraštį, paprašyti patvirtinimo.
Kur pasislėpusi rizika
Rizika – per daug abstraktus įrankis. Tada agentas lyg ir gali viską, bet kai suklysta, niekas nebesupranta, kuriame žingsnyje.
Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.
Ką pasidaryti šią savaitę
Jei kuriate agentą, peržiūrėkite jo įrankius ir paklauskite: ar kiekvienas jų turi vieną aiškų darbą?
Rašome apie dirbtinį intelektą lietuviškai. Kiekvienas straipsnis parengtas pagal nurodytą šaltinį, o nuorodą į originalą rasite kortelėje „Šaltinis“.
