MCP: trūkstama grandis tarp DI ir jūsų verslo

DI licencija suteikia mąstymą, bet ne rankas. Sužinokite, kaip MCP serveriai saugiai sujungia jūsų įmonės duomenis ir įrankius su agentiniu DI.

Cover image for MCP: trūkstama grandis tarp DI ir jūsų verslo

Galite nusipirkti pažangiausią rinkoje esantį modelį, ir jis vis tiek nesugebės perskaityti jūsų sąskaitų, atnaujinti kliento įrašo ar ištraukti skaičiaus iš jūsų ERP sistemos. Tarp galingo modelio ir naudingo agento glūdi integracijos problema, kurią dar visai neseniai kiekviena įmonė spręsdavo nuo nulio. Model Context Protocol yra standartas, supaprastinantis šį iššūkį.

Atotrūkis tarp „turime DI" ir „DI dirba mums naudingą darbą"

Pažangiausio modelio prenumerata suteikia jums mąstymą, bet ne rankas. Modelis geba planuoti, apibendrinti ir nuspręsti; ko jis pats negali - tai pasiekti jūsų sistemas ir imtis veiksmų. Viskas, kas asistentą paverčia agentu, glūdi ryšyje tarp modelio ir jūsų duomenų, o šį ryšį reikia sukurti.

Anksčiau jis būdavo kuriamas prastai. Kiekvienai dirbtinio intelekto programai, norėjusiai prisiliesti prie duomenų šaltinio, reikėjo savo atskiros jungties, o kiekvienas naujas šaltinis darbą padaugindavo. Senuoju būdu sujunkite M programų su N sistemų - ir gausite M×N individualių integracijų, kurias reikia sukurti ir prižiūrėti. Tai yra vadinamoji M×N problema.

Kiekviena jungtis - tai kodas, kurį kažkas turi parašyti, apsaugoti ir palaikyti veikiantį, kai keičiasi pati sistema. Būtent dėl to tiek daug DI bandomųjų projektų sustoja ties demonstracijos faze. Izoliuotoje aplinkoje modelis daro įspūdį, o paskui susiduria su realybe: daugybe vidinių sistemų ir jokio standartinio kelio prie jų.

Model Context Protocol šią problemą supaprastina. Sukurkite jungtį vieną kartą - ir ja galės naudotis bet kuri standartą atitinkanti DI programa.

Kas yra MCP

MCP - Model Context Protocol - tai atviras standartas, jungiantis DI programas su išoriniais duomenimis, įrankiais ir darbo procesais. Jį sukūrė „Anthropic" ir atvirai paskelbė 2024 m. lapkričio 25 d. Pati „Anthropic" MCP trumpai vadina „USB-C jungtimi dirbtiniam intelektui": vienas standartizuotas lizdas, kad bet kuris modelis galėtų prisijungti prie bet kurios sistemos be atskiro kabelio kiekvienai porai.

Svarbu, kad MCP nepriklauso tik vienam tiekėjui. 2025 m. kovą „OpenAI" pritaikė MCP savo produktuose, tarp jų ir „ChatGPT" darbalaukio programoje; 2025 m. balandį tą patį padarė „Google DeepMind". Trys organizacijos, kuriančios pirmaujančius modelius, dabar kalba ta pačia integracijų kalba - todėl MCP yra saugus pagrindas kurti integracijas jau šiandien.

Kaip veikia MCP

Architektūros schema su srautu iš kairės į dešinę: įmonės sistemos - programos, duomenų bazės, failai ir API - jungiasi į vieną MCP serverį, kuris atveria įrankius, išteklius ir šablonus; serveris jungiasi prie valdymo sluoksnio, esančio kelyje tarp serverio ir DI agentų, o valdymo sluoksnis - su katalogu, valdymu, stebėjimu, sąnaudų priskyrimu ir naudojimo analitika - kontroliuoja prieigą ir jungiasi prie daugelio DI agentų, tad agentai serverį pasiekia tik per valdymo sluoksnį.

Sekoje pavaizduotas valdymo sluoksnis - tai neprivalomas „Kern Mind" kuriamas sluoksnis, o ne bazinio MCP protokolo dalis; apie jį - žemiau, skyriuje „Kur dirba Kern Mind".

MCP ryšį sudaro trys komponentai. Pagrindinė programa (host) - tai pati DI programa - agentas. Jos viduje veikia vienas ar keli klientai, po vieną kiekvienam ryšiui. Kiekvienas klientas bendrauja su MCP serveriu, kuris suteikia agentui prieigą prie realios sistemos jam suprantama forma. Pagrindinė programa ir serveris keičiasi žinutėmis per JSON-RPC 2.0 - lengvą, gerai žinomą nuotolinio procedūrų iškvietimo protokolą, tad pati perdavimo logika sąmoningai yra labai paprasta.

Serveris atveria trijų rūšių galimybes. Įrankiai (tools) - tai veiksmai, kuriuos agentas gali atlikti: sukurti sąskaitą, išsiųsti el. laišką, nuskaityti užsakymo būseną. Ištekliai (resources) - tai duomenys, kuriuos agentas gali skaityti: dokumentas, duomenų bazės įrašas, failas. Šablonai (prompts) - tai serverio siūlomi daugkartinio naudojimo darbo procesai užduočiai atlikti. Šis žodynas sąmoningai mažas - būtent tai leidžia vienam agentui dirbti su dešimtimis serverių be atskiros individualios integracijos.

Labai svarbus aspektas - saugumas. Įsitvirtinanti praktika yra OAuth 2.1 su aiškia, apribota prieiga: pavyzdžiui raktas, leidžiantis konkrečiam agentui skaityti sąskaitas, neleidžia jam trinti klientų. Būtent per prieigos apimtis (scopes) pasiekiama ir kelių naudotojų izoliacija (multi-tenant isolation), kad A komandos agentas niekada nepasiektų B komandos duomenų, o šią ribą užtikrina pats serveris.

Autorizacija - tik pusė sprendimo. Realūs serveriai vėluoja, riboja užklausų dažnį ir kartais grąžina klaidas, o agentas, kuris nutrūkusią užklausą palaiko sėkme, gali tyliai sugadinti jūsų duomenis - todėl pakartotiniai bandymai ir užklausai skirti fiksuoti laikai yra būtini. Taip pat reikia ir matomumo (observability): kiekviena įrankio užklausa užregistruota ir atsekama, kad galėtumėte atsakyti „kuris agentas ką padarė, kuriai sistemai ir kada", o ne bandyti atkartoti veiksmų istoriją iš atminties incidento metu.

Protokolas standartizuoja techninę „santechniką". Jis nenusprendžia, kam leidžiama ką atlikti, kaip tai audituosite ar kaip seksite kaštus - o didelėje sistemoje būtent šie klausimai yra labai svarbūs.

Kur dirba Kern Mind

Mūsų darbą sudaro du sluoksniai. Pirma, mes projektuojame, įgyvendiname ir prižiūrime pačius MCP serverius - kuriame individualius serverius jūsų vidinėms sistemoms ir prijungiame oficialius ar SaaS serverius. Būtent šis sluoksnis paverčia jūsų ERP, CRM, duomenų bazes ir skaičiuokles tuo, ką agentas iš tiesų gali naudoti - su iš anksto paruošta, o ne vėliau prilipdytu saugumu ir kontrole.

Antra, galime suprojektuoti ir sukurti valdymo sluoksnį (control plane) - valdomus vartus, už kurių stovi serveriai, kad kiekvienas agentas jūsų sistemas pasiektų per vieną prižiūrimą ir kontroliuojamą kelią. Tai vykdomasis sluoksnis, atsakantis į tikrąjį techninio direktoriaus (CTO) klausimą: kaip visa tai saugiai valdyti tarp komandų ir agentų, nepametant kontrolės? Kuriame jį pritaikytą tam, ko klientui reikia - su daugiau ar mažiau galimybių, pagal poreikį.

Valdymo sluoksnio galimybių sąrašas iš penkių kortelių: Katalogas, Valdymas, Stebėjimas, Sąnaudų priskyrimas ir Naudojimo analitika, kiekviena su piktograma ir vienos eilutės aprašymu, ką ji daro.

Viršuje esantis sąrašas įvardija penkias galimybes, kurios techniniam direktoriui yra reikalingos visos kartu. Katalogas ir Valdymas atsako į klausimą „kam ką leidžiama kviesti" ir paverčia OAuth prieigos apimtis kontroliuojama saugos politika. Stebėjimas ir Sąnaudų priskyrimas užtikrina, jog kiekviena užklausa bus audituojama ir DI išlaidoms bus priskirtas savininkas bei biudžetas. Naudojimo analitika išlaiko katalogą tvarkingą, kad jame nesikauptų niekieno nenaudojami serveriai, kurie tik be reikalo eikvoja biudžetą.

Keturi žemiau esantys ekranai yra iš mūsų valdymo sluoksnio prototipo; jie pateikiami kaip iliustracinis pavyzdys su pavyzdiniais duomenimis, atitinkančiais tipinio kliento sistemų mastą. Jie penkias aukščiau minėtas galimybes iš sąrašo paverčia funkcijomis, kurias komandos iš tiesų naudotų.

Serveriai: viena vieta, kurioje komanda gali pamatyti, kokie serveriai yra prijungti ir ar jie yra apsaugoti.

Iliustracinis pavyzdys - valdymo sluoksnio MCP serverių katalogo ekranas, kuriame matyti 12 registruotų serverių (10 veikiantys, 1 su sutrikimais, 1 neprisijungęs) su kortelėmis „Salesforce CRM", „PostgreSQL Analytics" ir „Slack Workspace", kiekvienoje nurodant jos įrankius, išteklius, užklausas, OAuth būseną ir 100% autorizacijos aprėptį.

Įrankiai ir ištekliai: čia galite stebėti kokius įrankius ir išteklius agentai gali naudoti ir ar jie yra apsaugoti.

Iliustracinis pavyzdys - valdymo sluoksnio įrankių ir išteklių ekranas: 45 įrankiai ir 22 ištekliai, 37 apsaugoti ir 12 neapsaugotų, ir atskirų įrankių lentelė su jų serveriu, kategorija, autorizacijos metodu, konfidencialumo / vidinio naudojimo klasifikacija, užklausų kiekiu ir klaidų dažniu.

Valdymas ir autorizacija: ekranas, kurį saugos audito metu atsidarote pirmiausia - jis parodo neapsaugotus įrankius/duomenis ir besibaigiančius galioti prieigos raktus, kurie ateityje sutrikdytų agentų veiklą.

Iliustracinis pavyzdys - valdymo sluoksnio valdymo ir autorizacijos ekranas: 82% autorizacijos aprėptis, 12 neapsaugotų išteklių, 8 ištekliai su atskleistais PII (asmens duomenimis) ir 3 netrukus baigsiantys galioti prieigos duomenys, su autorizacijos metodų pasiskirstymo diagrama ir prieigos duomenų būklės sąrašu, žyminčiu kritinius ir įspėjamuosius galiojimo terminus.

Stebėjimas: skirtas tiksliai atsakyti „kuris agentas ką atliko ir ar viskas veikia sklandžiai".

Iliustracinis pavyzdys - valdymo sluoksnio stebėjimo ekranas: 18,500 užklausų šią savaitę, 1.41% vidutinis klaidų dažnis, 124ms vidutinė delsa ir 10 aktyvių įrankių.

Paremta darbu, kurį jau atliekame

DI jungimas prie įmonės sistemų mums nėra nauja sritis - MCP tik standartizuoja šabloną, kurį jau taikome. Mūsų sąskaitų skaitmenizavimo projekte DI apdorojimo agentas ištraukia duomenis iš dokumentų ir tiesiogiai perduoda juos į kliento ERP per REST API. MCP aprašo būtent tokį sistemos ir agento ryšį - daugkartinio naudojimo forma, kurią gali perimti bet kuris standartą atitinkantis agentas.

Apibendrinimas

Licencija - tai protas. MCP - tai rankos, standartinis būdas suteikti agentui saugią, apribotą prieigą prie sistemų, kurių jam reikia, kad būtų naudingas. Valdymo sluoksnis - tai nervų sistema, kuri užtikrina kontrolę, stebėjimą ir saugumą plečiant organizacijos agentų ekosistemą.

Pirmasis praktinis žingsnis - ne platformos pirkimas. Tai sprendimas: kurios jūsų sistemos pirmiausia turėtų tapti prieinamos agentams ir kaip prieiga bus valdoma ir apsaugota nuo pirmos dienos. Jei būtent tokią diskusiją norėtumėte turėti, pasikalbėkime.

Norite sužinoti daugiau?
Aptarkime, kaip technologijos gali padėti jūsų verslui.

© 2026 Kern Mind