Agent Bucket: Stocare nativă de tip Bucket pentru Agent la scară de trilioane

În ziua de azi, când Agenții AI apar ca ciupercile după ploaie, dezvoltatorii construiesc cu o viteză fără precedent aplicații inteligente pline de imaginație. De la asistenți de programare care te ajută să scrii cod, la instrumente de creație care generează un film dintr-o singură propoziție, până la asistenți personali inteligenți mereu la dispoziție, Agenții remodelează modul în care interacționăm cu lumea digitală. În spatele acestui val, un consens devine din ce în ce mai clar: cu ajutorul arhitecturii Serverless (cum ar fi Lambda), a modelelor lingvistice mari (LLM) și a stocării în cloud (cum ar fi S3, TOS), combinat cu Vibe Coding, oricine poate construi rapid propriul Agent AI în 30 de minute.

De la "utilizabil" la "ușor de utilizat", dezvoltatorii de Agenți încă trebuie să depășească dificultăți în trecerea de la "jucării" la "aplicații de nivel de producție". Pe măsură ce afacerea se îndreaptă către un număr mare de utilizatori, dezvoltatorii trebuie să facă față unei provocări extrem de complexe: cum să construiască o soluție completă de stocare pentru un număr mare de utilizatori finali pe stocarea de obiecte? Pentru majoritatea dezvoltatorilor, aceasta nu este doar o barieră tehnică, ci și o prăpastie care împiedică distribuția la scară a Agenților. Agent Bucket își propune să simplifice complet procesul de construire a sistemelor multi-tenant prin designul de stocare nativ AI, oferind o capacitate de Agent mai prietenoasă.

Când miliarde de utilizatori se înghesuie, stocarea tradițională de obiecte "nu mai este suficientă"

Imaginează-ți că ai dezvoltat o aplicație AIGC extrem de populară. Fiecare utilizator va genera și stoca un număr mare de imagini, videoclipuri și fișiere temporare. Ca dezvoltator, vei alege în mod natural servicii de stocare de obiecte mature și scalabile, cum ar fi S3 și TOS. Dar apare o problemă: cum gestionezi datele pentru un număr mare de utilizatori?

În blogul S3 din 2022, "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3", sunt descrise două metode, "utilizarea unui bucket S3 independent pentru fiecare tenant" și "bucket S3 partajat bazat pe izolarea prefixului":

• Crearea unui "bucket" independent pentru fiecare utilizator: Acest lucru este fezabil atunci când există un număr mic de utilizatori, dar pe măsură ce numărul de utilizatori crește la zeci de mii, milioane, numărul de bucket-uri va exploda rapid, iar costurile de gestionare și limitele de resurse vor deveni insuportabile. S3 oferă o cotă totală de 10000 de bucket-uri în toată regiunea, dar pentru capacitățile AI populare, 10000 nu sunt nici pe departe suficiente.

• Utilizarea unui "prefix" pentru a distinge utilizatorii în același bucket: Aceasta a devenit soluția principală. De exemplu, fișierele utilizatorului A încep cu user-a/, iar cele ale utilizatorului B încep cu user-b/, ca și cum ai gestiona fișierele cu foldere pe un computer. Cu toate acestea, stocarea de obiecte nu are foldere native, iar această soluție distinge multi-tenant prin "prefixul comun" (Prefix) în sistemul de stocare "K-V".

Această soluție bazată pe "bucket" sau "prefix" a fost adoptată pe scară largă în ultimii zece ani. Dar există următoarele probleme:

• Izolare multi-tenant: Datele tuturor utilizatorilor sunt amestecate în același bucket, iar o vizită anormală de înaltă frecvență a unui utilizator poate afecta toți ceilalți utilizatori, generând un "efect de vecinătate". Izolarea performanței și izolarea defecțiunilor sunt imposibile.

• Controlul permisiunilor: Politicile complexe de permisiuni (IAM Policy) sunt dificil de menținut și este ușor să apară erori de configurare, ceea ce duce la accesarea accidentală a datelor utilizatorilor, mai ales atunci când este necesară interacțiunea cu alte servicii cloud, expunerea la risc este mai mare.

• Costuri clare: Este dificil să știi cu exactitate cât spațiu de stocare a consumat fiecare utilizator și câte taxe de trafic au fost generate. Când vrei să percepi taxe utilizatorilor plătitori în funcție de utilizare, facturarea și măsurarea devin o afacere confuză.De ce implementarea cerințelor aparent de bază este oarecum "grea" pentru dezvoltatorii de agenți în stocarea obiectelor? O analiză profundă a motivelor este că, în arhitectura cloud-nativă actuală, există un vid uriaș între "stocarea obiectelor" de tip S3 și "sistemul de fișiere" tradițional. Esența stocării obiectelor (S3/TOS) este "aplatizarea", iar intenția inițială de proiectare este stocarea simplă a unor cantități masive de date, ca un depozit uriaș. Deși capacitatea este aproape infinită, structura logică este extrem de simplă. Îi lipsesc gestionarea avansată nativă a directoarelor, controlul granular al metadatelor și percepția reală a chiriașilor. Când dezvoltatorii încearcă să simuleze un sistem de fișiere multi-chiriaș "tridimensional" pe S3 "aplatizat" prin codificarea dură a prefixelor, folosim de fapt un "stocare KV statică" pentru a suporta o metodă de acces la fișiere a unei aplicații Agent "cu semantică de director și izolare puternică". Adică, Agent-ul trebuie să consume jetoane suplimentare pentru a gestiona fișierele și a controla rezolvarea permisiunilor și a izolării multi-chiriaș. Aceste jetoane suplimentare consumate indică faptul că serviciul de stocare simplu definit de S3 nu este suficient de simplu pentru Agent.

Blogul S3 din 2025, 《Design patterns for multi-tenant access control on Amazon S3》, explică în continuare S3 Access Point. Aceasta înseamnă că pot fi create mai multe puncte de acces virtuale de rețea și poate fi configurată o politică de punct de acces personalizată pentru fiecare punct de acces, existând unele soluții la nivel de programare a rețelei pentru scenarii multi-chiriaș.

Agent Wonderland

Un dezvoltator Agent ideal, atunci când dezvoltă un AI Agent, poate construi un Agent complet serverless bazat pe "Agent SDK + stocare + serviciu MaaS":

• Agent-ul poate rula complet serverless

• Poate combina capacitățile produselor existente pentru a construi Agent-ul prin Vibe Coding

• Trebuie doar să mențină scriptul python al "ADK"

• Stocarea utilizează stocarea obiectelor

• Capacitatea AI utilizează Doubao

• Teoretic, nu există ECS sau alte produse de tip instanță

În același timp, stocarea trebuie să ofere următoarele capacități:

• Agent-ul poate avea o stocare cu semantică de obiect (salvarea fișierelor), oferind capacitate de acces multi-chiriaș, începând cu un milion și scalând până la sute de milioane

• Agent-ul poate oferi spațiu independent pentru fiecare utilizator (între mai multe servicii, serviciile sau uid-urile pot avea același nume)

• Agent-ul poate configura direct lățimea de bandă a fiecărui utilizator, configura limita superioară a dimensiunii totale a obiectelor utilizatorului

• Agent-ul poate factura, monitoriza și observa în funcție de utilizator

• Agent-ul poate configura politici de acces pentru fișierele fiecărui utilizator

Agent Bucket: Injectarea genelor "native multi-chiriaș" în AI Agent

Pentru a rezolva fundamental această problemă, am propus un nou model de stocare a obiectelor - Agent Bucket. Inovația sa de bază este introducerea unui nou nivel de resurse native între "bucket-ul" și "obiectul" tradițional: colecția de obiecte.

Ideea centrală a acestui design este extrem de simplă: potriviți fiecărui utilizator final un ObjectSet exclusiv. Puteți considera ObjectSet ca pe o "cutie de valori de date" sau un "spațiu personal cloud" creat special pentru fiecare utilizator. Aparține logic Bucket-ului dvs. (dezvoltator), dar din punct de vedere fizic și de gestionare, are propria sa "personalitate" și "ciclu de viață" independent.Agent Bucket suportă 100 de milioane de ObjectSet-uri per bucket, ceea ce înseamnă că poți oferi cu ușurință servicii pentru sute de milioane de utilizatori finali, ca și cum fiecare utilizator final ar "trăi" în propriul spațiu de stocare independent, fără a mai fi nevoie să te mai stresezi cu gestionarea stocării multi-tenant.

Design ObjectSet - Capacități prietenoase pentru Agent

În Agent Bucket, ObjectSet nu este doar un nivel suplimentar, ci transformă cele mai dificile cerințe din scenariile multi-tenant în capacități native, gata de utilizare. Odată ce dreptul de proprietate asupra datelor este clar definit la nivelul ObjectSet, o serie de capacități care erau dificil de realizat în trecut devin naturale.

• Izolare nativă: La nivelul ObjectSet, poți seta limite independente de QPS, lățime de bandă și cote de capacitate pentru fiecare utilizator. Experiența utilizatorilor plătitori poate fi garantată, iar comportamentul anormal al utilizatorilor gratuiti nu va afecta pe alții. Aceasta este o adevărată izolare a domeniului de eroare, astfel încât "vecinii" să nu se mai interfereze reciproc.

• Permisiuni native: Fiecare ObjectSet poate avea un nume de domeniu independent. Aceasta înseamnă că poți oferi utilizatorului A o adresă de acces exclusivă user-a.yourapp.com, în loc să expui întregul nume de domeniu al bucket-ului de stocare. Mai inteligent este designul "două încuietori": prima încuietoare este un certificat de acces temporar (STS) emis de furnizorul de servicii cloud, care controlează permisiunile de acces la nivelul aplicației; a doua încuietoare este numele de domeniu independent al ObjectSet, care blochează cererile de acces în spațiul de date al utilizatorului de la nivelul rețelei. Acest lucru îmbunătățește semnificativ securitatea datelor.

• Monitorizare nativă: Pe panoul de bord de monitorizare, nu mai poți vedea doar datele generale ale întregului bucket. Poți descompune graficele de monitorizare by-ObjectSet, observând clar ce utilizator final efectuează un număr mare de accesări, astfel încât să poți lua decizii precise de operare și optimizare.

• Coborârea nativă a capacităților: Politicile care puteau fi setate doar la nivel de bucket în trecut pot fi acum coborâte la fiecare utilizator. Poți seta cicluri de viață diferite ale datelor pentru utilizatori de diferite niveluri sau poți utiliza chei de criptare diferite pentru fiecare ObjectSet, realizând o gestionare a datelor mai granulară și mai sigură.

• Măsurare nativă: Vrei să știi cât spațiu de stocare ocupă fiecare utilizator? Vrei să împarți cu precizie costurile de stocare fiecărui utilizator? Acum devine ușor. Agent Bucket va calcula automat capacitatea și utilizarea fiecărui ObjectSet, făcând facturarea și împărțirea veniturilor clare și transparente.

• Facturare nativă: Dezvoltatorii pot realiza cu ușurință împărțirea costurilor, împingând cu precizie costurile generate de stocare către fiecare utilizator final. De exemplu, poți percepe taxe diferențiate în funcție de proporția costurilor efective generate de diferiți utilizatori A, B și C, oferind suport de date pentru comercializarea Agent.

• Limită nativă de capacitate: Pentru a controla costurile de operare ale Agent, poți seta o Quota (limită de capacitate) pentru fiecare ObjectSet. Odată ce valoarea prestabilită este atinsă, sistemul va restricționa utilizatorul să mai genereze fișiere noi, evitând abuzul de resurse în scenariile multi-tenant de la sursă.

• Inteligență nativă: Agent Bucket permite Agent să iasă din limitările tradiționale de simplă "stocare și accesare" a fișierelor, oferind Object inteligență nativă, sprijinind mai eficient dezvoltarea one-stop a Agent. ObjectSet poate activa indexarea inteligentă cu un singur clic, oferind Agent o capacitate nativă și prietenoasă de întrebări și răspunsuri multimodale, înlocuind operațiunile mecanice tradiționale Object CRUD; chiar și suport pentru activarea modului Agentself cu un singur clic, conectând vectori, cunoștințe, modele și prompt-uri, dezvăluind direct funcții de sub-Agent contextualizate, permițând dezvoltatorilor Agent de nivel superior să se concentreze pe crearea fluxurilor de lucru de afaceri principale, eliberând pe deplin eficiența monetizării inteligente.

Provocările tehnice aduse de explozia scării aplicațiilor

Agent Bucket oferă dezvoltatorilor de aplicații o modalitate elegantă și eficientă de a gestiona datele a sute de milioane de utilizatori finali prin introducerea conceptului nativ de ObjectSet. Activele digitale ale fiecărui utilizator sunt stocate în siguranță în ObjectSet-ul său exclusiv, realizând în mod natural izolarea, facturarea și gestionarea cotelor.

Odată cu extinderea rapidă a scării aplicațiilor, complexitatea gestionării unui număr mare de Set-uri, dificultatea izolării și blocajele fizice devin evidente simultan:

• Problema gestionării ierarhice a unui număr mare de utilizatori: Atunci când o aplicație gestionează diferențiat resursele și caracteristicile unui număr mare de utilizatori de diferite niveluri, trebuie să proiecteze și să implementeze singură metadatele ierarhice ale utilizatorilor și să asocieze comutatoarele de caracteristici de stocare a obiectelor. Ajutarea dezvoltatorilor să gestioneze elegant ierarhizarea utilizatorilor pe baza conceptului nativ de Set este importantă pentru accelerarea implementării aplicațiilor.- Blocaj de capacitate al unui singur cluster: Deși Agent Bucket se poate extinde logic la infinit, metadatele sale sunt stocate implicit într-un singur cluster fizic. Când numărul total de obiecte din bucket atinge sute de miliarde sau chiar trilioane, capacitatea fizică a unui singur cluster devine o limită de netrecut.

• Probleme de partajare a punctelor de acces: Diversitatea afacerilor Agentului și numărul mare de utilizatori aduc riscuri de securitate mai mari și o rază de explozie mai mare punctelor de acces în sine. Cum să se realizeze o programare dinamică bazată pe diferențele dintre un număr mare de afaceri și utilizatori diferiți și să se realizeze capacități diferențiate de securitate, izolare și accelerare devine o dificultate.

Set Tagging: Gestionarea etichetată a clasificării utilizatorilor

ObjectSet oferă o metodă nativă de gestionare etichetată, permițând dezvoltatorilor Agent să utilizeze cu ușurință capacitatea de set tagging pentru a finaliza guvernarea clasificată a utilizatorilor; dezvoltatorii pot defini un tag pentru fiecare nivel de utilizator definit și pot activa cote și caracteristici diferite pentru fiecare tag. Toate ObjectSet-urile care sunt etichetate cu acest tag vor aplica cotele și caracteristicile corespunzătoare. Luați ca exemplu cele trei niveluri V1, V2 și V3:

• V1: Nivel implicit, utilizatori gratuiti, tag implicit pentru toate ObjectSet-urile, poate fi configurat pentru a stoca maximum 1GiB de date, distribuția publică nu poate depăși 100mbps lățime de bandă, iar viteza de descărcare a unui singur flux este controlată la 1mbps;

• V2: Membru plătitor de nivel de bază, configurat pentru a stoca maximum 10GiB de date, distribuția publică nu poate depăși 10gbps lățime de bandă, iar viteza de descărcare a unui singur flux este controlată la 10mbps;

• V3: Membru plătitor avansat, pe lângă furnizarea unei capacități de stocare mai mari și a unei cote de distribuție publică, acceptă și configurarea pentru a activa accelerarea suplimentară a rețelei slabe publice și capacitatea de accelerare a mediilor de înaltă performanță;

Dezvoltatorii Agent pot utiliza în mod flexibil tagging-ul V1/V2/V3 pentru a gestiona resursele și caracteristicile cu valoare adăugată pe care acești utilizatori le pot utiliza, orientându-se către diferite cicluri de dezvoltare ale diferiților utilizatori.

Set Slice: Izolarea nativă a datelor pentru utilizatori masivi

Când numărul de Set-uri dintr-un Agent Bucket atinge sute de milioane, iar numărul de obiecte atinge sute de miliarde sau trilioane, faptul că "toate metadatele dintr-un singur Bucket sunt concentrate într-un singur cluster KV" în sine va aduce riscuri duble de capacitate și performanță.

Set Slice oferă o idee de "nedescompunere logică, descompunere fizică":

• Din punct de vedere logic, gestionați în continuare doar un singur Agent Bucket.

• Din punct de vedere fizic, metadatele sunt împărțite în mai multe Slice-uri (felii) în funcție de Set și de intervalul numelor de obiecte din Set. Fiecare Slice poate fi stocat pe clustere diferite, mai multe Set-uri fiind izolate în mod natural, iar un singur Set fiind extins orizontal.

Set Slice este o extensie și o garanție suplimentară a capacității ObjectSet. Acesta rezolvă problema extinderii infinite a capacității fizice la nivelul de bază, asigurând în același timp stabilitatea și consistența modelului de gestionare ObjectSet de nivel superior.

• Stabilitatea limitei de gestionare: Chiar dacă datele unui Agent Bucket se întind pe mai multe clustere fizice, ObjectSet este încă singura unitate de bază pentru permisiuni, cote, facturare și monitorizare. Politicile configurate de dezvoltatori pentru ObjectSet (cum ar fi controlul accesului, limita de capacitate) vor intra automat în vigoare pe toate Slice-urile relevante, fără a fi nevoie să vă faceți griji cu privire la distribuția datelor de bază.

• Un singur Set poate fi extins liniar: Când volumul de date al unui anumit ObjectSet crește rapid, datele sale vor fi distribuite în mod natural în mai multe Slice-uri. Odată cu extinderea generală a clusterului, capacitatea ObjectSet-ului crește, de asemenea, fără probleme și liniar. Dezvoltatorii nu trebuie să efectueze nicio operațiune distructivă, cum ar fi descompunerea sau migrarea ObjectSet-ului în sine.

• Izolarea resurselor între Set-uri: Prin distribuirea obiectelor cu intervale diferite pe clustere fizice diferite, SetSlice realizează o dimensiune mai mare a izolării resurselor. În combinație cu gestionarea cotelor ObjectSet, poate preveni în mod eficient creșterea datelor unui anumit ObjectSet "super-mare" de a aglomera toate resursele unui singur cluster, afectând astfel stabilitatea altor ObjectSet-uri și făcând riscul general de capacitate controlabil.## Arhitectură de izolare multi-tenant la scară largă

• Unitate logică și compatibilitate: Pentru afaceri și dezvoltatori, indiferent de câte Slice-uri există la nivelul de bază, aceștia se confruntă întotdeauna cu un Bucket Agent unitar din punct de vedere logic. Toate metodele de operare pentru bucket-uri, ObjectSet-uri și obiecte rămân neschimbate, realizând o transparență completă a extinderii fizice pentru aplicațiile de nivel superior.

Set AccessPoint: Izolarea punctului de acces al fiecărui utilizator

Bucket Agent acceptă activarea punctelor de acces independente (domenii independente) pentru fiecare ObjectSet și extinderea capacităților diferențiate de securitate, izolare și accelerare pe punctele de acces. Sistemul trebuie să suporte programarea punctelor de acces independente la nivel de miliarde și capacitatea de configurare diferențiată.

Domeniu de acces independent {$apid}.tos-objectset-ap.volces.com: Protecție de securitate pe două niveluri

• Primul nivel Obscurity (obscuritate): Subdomeniu independent By User/ObjectSet, dispersie de înaltă entropie apid, probabilitate de coliziune extrem de scăzută, imposibil de ghicit și enumerat intrarea unui anumit utilizator din perspectiva domeniului de acces;

• Al doilea nivel Containment (limitare): Dezvoltatorii Agent folosesc sts pentru a distribui permisiuni de acces la nivel de ObjectSet, chiar dacă sts este divulgat, domeniul său de acces poate fi controlat și limitat la o anumită perioadă de valabilitate a ObjectSet-ului;

Sistem euristic de programare: Calculul strategiei de programare a domeniilor la nivel de miliarde

• Strategie de acces diferențiată By user/ObjectSet:tag

• Multi user/ObjectSet sunt dispersate automat în diferite puncte de intrare publice, numărul de utilizatori afectați de o singură defecțiune a punctului de intrare este controlat

• Programare elastică la nivel de regiune, defecțiunea/supraîncărcarea oricărui punct de intrare unic finalizează automat mutarea traficului

• Utilizatorii de tip distribuție accelerată publică, marchează cu tag-ul de accelerare a transmisiei publice și programează automat intrarea de accelerare

• Utilizatorii de tip risc public, marchează cu tag-ul de risc, programează automat intrarea de izolare publică și reduc cota de lățime de bandă publică

• Utilizatorii de tip rețea internă cross-domain, marchează cu tag-ul cross-domain, programează automat calea de accelerare a liniei dedicate a rețelei interne

• Utilizatorii de acceleratoare locale, marchează cu tag-ul accelerator, montează automat acceleratorul local

De la asistent de programare la cloud disk AI, posibilitățile nelimitate ale Bucket Agent

Bucket Agent oferă o soluție completă pentru Agent, iar scenariile de aplicare ale designului ObjectSet depășesc cu mult acest lucru. Poate fi extins cu ușurință la toate aplicațiile care trebuie să ofere servicii pentru un număr mare de utilizatori finali:

• Depozit de cod: În trecut, atunci când companiile sau persoanele fizice găzduiau cod în cloud, adesea trebuiau să construiască un "sistem de chiriaș" deasupra stocării de obiecte pentru a realiza izolarea conturilor și controlul permisiunilor. Acum, fiecărui dezvoltator i se poate aloca un ObjectSet exclusiv, care să includă depozitul de cod, produsele de construcție și dependențele. Agent Skills se adaptează, de asemenea, în mod natural la ObjectSet. Încărcarea, descărcarea și distribuirea Skills prin ObjectSet oferă o izolare puternică, evitând interferențele cu vecinii în timpul execuției Agent.

• Album foto/cloud disk pentru întreprinderi: Serviciile tradiționale de albume foto sau cloud disk amestecă adesea fotografiile tuturor utilizatorilor în același bucket și disting utilizatorii prin prefixe, ceea ce nu numai că face gestionarea complexă, dar este și predispus la "efectul de vecinătate". Pe baza ObjectSet, fotografiile și videoclipurile fiecărui utilizator sunt stocate în propriul Set, iar vârfurile de acces nu interferează unul cu celălalt. De asemenea, puteți seta limite de capacitate, politici de backup și metode de criptare pentru fiecare utilizator, realizând cu adevărat "fiecare are un album foto cloud sigur și controlabil".

• Depozit de date Hadoop: În depozitul de date al întreprinderii, diferite linii de business și diferite baze de date partajează adesea resurse pe aceeași stocare de bază. Prin maparea fiecărei baze de date la un ObjectSet, întreprinderea poate realiza izolarea și controlul cotelor pe bază de bază de date pe o stocare unificată. În special, ObjectSet oferă un nivel suplimentar de permisiuni pe TOS, oferind izolare și control al permisiunilor pentru Database și Tables stocate pe TOS fără a schimba Proton on TOS existent. - Platformă de găzduire a modelelor: În scenariile de găzduire a modelelor mari, fiecare model nu este doar voluminos, dar poate corespunde și diferitelor versiuni, ponderi și configurații de inferență. Crearea unui ObjectSet pentru fiecare model poate împacheta și găzdui ponderile modelului, Tokenizer-ul, fișierele de configurare și datele de evaluare aferente în același spațiu. Partea de operațiuni poate seta politici de criptare diferențiate, politici de backup și control al lățimii de bandă pentru diferite modele. În același timp, prin capacitatea nativă de măsurare, se pot calcula costurile reale de utilizare ale fiecărui model, oferind o bază pentru facturarea și planificarea resurselor la nivel de model.

• Servicii Data SaaS: Platformele de distribuție a datelor orientate către un număr mare de utilizatori finali trebuie adesea să se conecteze simultan cu mulți furnizori de date. Trebuie să se asigure că granițele datelor fiecărei părți sunt clare și, de asemenea, să se evite riscul de performanță "un butoi mare trage pe toată lumea în jos". Cu ajutorul Agent Bucket, fiecare furnizor de date poate avea propriul ObjectSet, gestionând în mod unificat datele brute și rezultatele procesării. Apoi, prin domenii și lățime de bandă independente, cote QPS, se pot efectua garanții de servicii diferențiate și limitare a traficului pentru diferiți furnizori, realizând o infrastructură de distribuție a datelor "o platformă, mai mulți furnizori, izolați unul de celălalt și colaborare controlabilă".

Referință:

• https://aws.amazon.com/cn/blogs/apn/partitioning-and-isolating-multi-tenant-saas-data-with-amazon-s3/

• https://aws.amazon.com/cn/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/