Multi-tenant AgentCore: vienas agentas daug klientų, bet ne viena košė

·


Multi-tenant AgentCore architektūra atskirtiems klientams

Multi-tenant AgentCore 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 parodė, kaip kurti multi-tenant DI agentus su Amazon Bedrock AgentCore ir atskirti klientus bendroje infrastruktūroje. Skamba labai techniškai. Bet esmė ūkiška: vienas namas, daug butų, kiekvienam savo raktas.

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

Sprendimas aprašo trijų lygių hierarchiją – tier, tenant, user – ir rodo, kaip izoliuoti dokumentus, atmintį, modelio prieigą bei kaštų sekimą naudojant AWS valdomas paslaugas.

SaaS versle daug kas atrodo paprasta, kol vieno kliento duomenys netyčia neatsiduria kito kliento atsakyme. Tada romantika baigiasi per vieną minutę.

KODĖL TAI SVARBU

Multi-tenant AgentCore svarbus todėl, kad DI agentai SaaS produktuose turi aptarnauti daug klientų, bet negali maišyti konteksto, duomenų, atminties ar sąskaitų.

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 funkcijos produktuose turi būti projektuojamos su izoliacija nuo pirmos dienos. Ne po to, kai jau atsiranda problema.

  • atskirti klientų dokumentus ir atmintį
  • sekti kaštus pagal klientą
  • riboti modelio ir įrankių prieigą pagal planą
  • testuoti, ar agentas nepereina tenant ribų

Pavyzdys: klientų aptarnavimo SaaS agentas gali naudoti tik konkretaus kliento žinių bazę ir jokiu būdu nematyti kito kliento bilietų.

KUR PASISLĖPUSI RIZIKA

Rizika – pradėti nuo bendros atminties, nes taip greičiau. Greičiau šiandien, brangiau rytoj.

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 DI funkciją SaaS produkte, užrašykite, kur tiksliai prasideda ir baigiasi vieno kliento duomenų ribos.

Šaltinis: Amazon Web Services.

DUK

Kas yra multi-tenant agentas?

Tai agentas, aptarnaujantis daug klientų vienoje infrastruktūroje, bet išlaikantis duomenų atskyrimą.

Kodėl izoliacija svarbi?

Kad vieno kliento duomenys, atmintis ir kaštai nesimaišytų su kito.

Nuo ko pradėti?

Nuo aiškios tenant hierarchijos ir prieigos taisyklių.

Jei norite DI naudoti ne dėl mados, pradėkite nuo vieno proceso. Paimkite užduotį, kuri kartojasi kas savaitę, susirašykite žingsnius ir tik tada junkite įrankį. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.