Agent Bucket: En Agent-ursprunglig lagringsbunke i biljonklassen
Agent Bucket: En Agent-ursprunglig lagringsbunke i biljonklassen
I dagens läge, där AI-agenter dyker upp som svampar ur jorden, bygger utvecklare fantasifulla intelligenta applikationer i en aldrig tidigare skådad takt. Från programmeringsassistenter som hjälper dig att skriva kod, till kreativa verktyg som genererar en film från en enda mening, till personliga intelligenta assistenter som alltid är redo, omformar agenter vårt sätt att interagera med den digitala världen. Bakom denna våg blir en konsensus allt tydligare: Med hjälp av Serverless-arkitektur (som Lambda), stora språkmodeller (LLM) och molnlagring (som S3, TOS), i kombination med Vibe Coding, kan vem som helst snabbt bygga sin egen AI-agent på 30 minuter.
För att gå från att vara \Varför verkar dessa till synes grundläggande behov vara lite "tunga" för Agent-utvecklare att implementera på objektlagring? En djupare undersökning visar att det finns ett stort vakuum mellan "objektlagring" som S3/TOS och traditionella "filsystem" i den nuvarande molnbaserade arkitekturen. Objektlagringens (S3/TOS) kärna är "utplattad", och den ursprungliga designen var för enkel lagring av enorma datamängder, som ett stort lager. Även om kapaciteten är nästan obegränsad, är den logiska strukturen extremt enkel. Den saknar inbyggd avancerad kataloghantering, finkornig metadata-kontroll och äkta hyresgästmedvetenhet. När utvecklare försöker simulera ett "tredimensionellt" filsystem för flera hyresgäster på den "utplattade" S3 genom att hårdkoda prefix, använder vi faktiskt en "statisk KV-lagring" för att hantera ett "katalogsemantiskt, starkt isolerat" sätt för Agent-applikationer att komma åt filer. Det vill säga, Agent måste spendera ytterligare tokens för att hantera filer och kontrollera och lösa behörigheter och isolering för flera hyresgäster. Dessa extra tokens indikerar alla att S3:s definierade enkla lagringstjänst inte är tillräckligt enkel för Agent.
I S3-bloggen från 2025, 《Design patterns for multi-tenant access control on Amazon S3》, beskrivs S3 Access Point ytterligare. Detta innebär att flera virtuella nätverksanslutningspunkter kan skapas, och en anpassad åtkomstpunktsprincip kan konfigureras för varje anslutningspunkt, vilket ger vissa lösningar på nätverksplaneringsnivå för scenarier med flera hyresgäster.
Agent Wonderland
En idealisk Agent-utvecklare kan, när de utvecklar en AI Agent, bygga en helt serverlös Agent baserat på "Agent SDK + lagring + MaaS-tjänst":
-
Agent kan köras helt serverlöst
-
Kan kombinera befintliga produktfunktioner för att bygga Agent genom Vibe Coding
-
Behöver bara underhålla python-skriptet för "ADK"
-
Lagring använder objektlagring
-
AI-kapacitet använder Doubao (exempel på en AI-tjänst)
-
Teoretiskt sett inga ECS eller andra instansbaserade produkter
Samtidigt måste lagringen tillhandahålla följande funktioner:
-
Agent kan ha en lagring med objektsemantik (spara filer), tillhandahålla åtkomstkapacitet för flera hyresgäster, börja med miljontals och kan utökas till hundratals miljoner
-
Agent kan tillhandahålla ett oberoende utrymme för varje användare (mellan flera tjänster kan tjänster eller uid ha samma namn)
-
Agent kan direkt konfigurera bandbredden för varje användare och konfigurera den totala maximala objektstorleken för användaren
-
Agent kan fakturera, övervaka och observera baserat på användare
-
Agent kan konfigurera åtkomstpolicyer för varje användares filer
Agent Bucket: Injicera "inbyggda gener för flera hyresgäster" i AI Agent
För att fundamentalt lösa detta problem har vi föreslagit ett helt nytt paradigm för objektlagring – Agent Bucket. Dess kärninnovation är att introducera en ny inbyggd resursnivå mellan de traditionella "buckets" och "objekt": objektuppsättningar.
Kärnidéen bakom denna design är extremt enkel: matcha varje slutanvändare med en dedikerad ObjectSet. Du kan tänka på ObjectSet som ett "dataskåp" eller "personligt molnutrymme" skapat exklusivt för varje användare. Logiskt sett tillhör det din (utvecklarens) Bucket, men fysiskt och administrativt har det sin egen oberoende "personlighet" och "livscykel".Agent Bucket stöder 100 miljoner ObjectSet per bucket, vilket innebär att du enkelt kan betjäna hundratals miljoner slutanvändare som om varje slutanvändare "lever" i sitt eget oberoende lagringsutrymme, utan att behöva oroa dig för hantering av lagring för flera hyresgäster.
ObjectSet-design – Agentvänliga funktioner
ObjectSet i Agent Bucket är inte bara en extra nivå, utan förvandlar också de mest knepiga behoven i scenarier med flera hyresgäster till färdiga, inbyggda funktioner. När dataägarskapet har fastställts på ObjectSet-nivån blir en rad funktioner som tidigare var svåra att implementera en självklarhet.
-
Inbyggd isolering: På ObjectSet-nivån kan du ställa in oberoende QPS-, bandbreddsbegränsningar och kapacitetskvoter för varje användare. Upplevelsen för betalande användare kan garanteras, och gratisanvändares onormala beteende kommer inte att påverka andra. Detta är verklig feldomänisolering, vilket gör att "grannar" inte längre stör varandra.
-
Inbyggda behörigheter: Varje ObjectSet kan ha ett oberoende domännamn. Det betyder att du kan ge användare A en exklusiv åtkomstadress user-a.yourapp.com, istället för att exponera hela lagrings-bucketens domännamn. Ännu smartare är designen med "två lås": Det första låset är en tillfällig åtkomsttoken (STS) utfärdad av molntjänstleverantören, som styr åtkomstbehörigheterna på applikationsnivå; det andra låset är ObjectSets oberoende domännamn, som låser åtkomstförfrågningar till användarens eget datautrymme från nätverksnivå. Detta förbättrar datasäkerheten avsevärt.
-
Inbyggd övervakning: På övervakningspanelen kan du inte längre bara se en översikt över hela bucketen. Du kan bryta ner övervakningsdiagrammen by-ObjectSet och tydligt se vilken slutanvändare som gör ett stort antal åtkomster, vilket gör att du kan fatta exakta drifts- och optimeringsbeslut.
-
Inbyggd kapacitetsnedbrytning: Policyer som tidigare bara kunde ställas in på bucket-nivå kan nu brytas ner till varje användare. Du kan ställa in olika datalivscykler för olika nivåer av användare, eller använda olika krypteringsnycklar för varje ObjectSet, för att uppnå mer detaljerad och säkrare datahantering.
-
Inbyggd mätning: Vill du veta hur mycket lagringsutrymme varje användare använder? Vill du fördela lagringskostnaderna exakt till varje användare? Nu är det enkelt. Agent Bucket kommer automatiskt att samla in kapaciteten och användningen för varje ObjectSet, vilket gör din fakturering och fördelning tydlig.
-
Inbyggd fakturering: Utvecklare kan enkelt implementera kostnadsfördelning och exakt spåra kostnaderna som genereras av lagring tillbaka till varje slutanvändare. Till exempel, differentiera prissättningen baserat på kostnadsfördelningen mellan olika användare A, B och C, vilket ger datastöd för Agent-kommersialisering.
-
Inbyggd kapacitetsgräns: För att kontrollera driftskostnaderna för Agent kan du ställa in en kvot (kapacitetsgräns) för varje ObjectSet. När det förinställda värdet har uppnåtts kommer systemet att begränsa användaren från att generera nya filer, vilket förhindrar resursmissbruk i scenarier med flera hyresgäster från grunden.
-
Inbyggd intelligens: Agent Bucket låter Agent bryta sig loss från de traditionella begränsningarna av enkel "lagring och hämtning" av filer, vilket ger Object inbyggd intelligens och stöder mer effektivt Agent-utveckling på ett enda ställe. ObjectSet kan aktivera smart indexering med ett klick, vilket ger Agent inbyggda vänliga multimodala frågefunktioner, vilket ersätter den mekaniska driften av traditionell Object CRUD; det stöder till och med aktivering av Agentself-läge med ett klick, kopplar samman vektorer, kunskap, modeller och prompter, och exponerar direkt scenariobaserade sub-Agent-funktioner, vilket gör att överordnade Agent-utvecklare kan fokusera på skapandet av huvudsakliga affärsarbetsflöden och fullt ut frigöra effektiviteten av intelligent intäktsgenerering.
Tekniska utmaningar som orsakas av applikationsskalans explosion
Agent Bucket ger applikationsutvecklare ett elegant och effektivt sätt att hantera data för hundratals miljoner slutanvändare genom att introducera det inbyggda konceptet ObjectSet. Varje användares digitala tillgångar lagras säkert i sin egen exklusiva ObjectSet, vilket naturligtvis realiserar isolering, fakturering och kvothantering.
Med den snabba expansionen av applikationsskalan blir komplexiteten i hanteringen av massiva Set, isoleringssvårigheter och fysiska flaskhalsar uppenbara samtidigt:
-
Problem med hierarkisk hantering av massiva användare: När applikationer differentierat hanterar resurser och funktioner för ett stort antal användare av olika nivåer, måste de själva designa och implementera hierarkisk metadata för användare och associera objektlagringsfunktionsomkopplare. Att hjälpa utvecklare att elegant hantera användarhierarkier på det inbyggda konceptet Set är viktigt för att påskynda applikationsimplementeringen.- Enkelklusterkapacitetsflaskhals: Även om Agent Bucket logiskt sett kan expanderas obegränsat, lagras dess metadata som standard i ett enda fysiskt kluster. När det totala antalet objekt i en bucket når hundratals miljarder eller till och med biljoner, blir den fysiska kapaciteten hos ett enda kluster en oöverstiglig gräns.
-
Problem med delad åtkomstpunkt: Mångfalden av Agenter och det stora antalet användare innebär större säkerhetsrisker och explosionsradier för själva åtkomstpunkten. Hur man gör dynamisk schemaläggning baserat på skillnaderna mellan ett stort antal olika verksamheter och användare, och uppnår differentierad säkerhet, isolering och accelerationsförmåga, är en utmaning.
Set Tagging: Taggningshantering för användarklassificering
ObjectSet tillhandahåller ett inbyggt taggningshanteringssätt, vilket gör att Agent-utvecklare enkelt kan använda set tagging-funktioner för att slutföra användarklassificeringsstyrning. Utvecklare kan definiera en tagg för varje definierad användarnivå och aktivera olika kvoter och funktioner för varje tagg. Alla ObjectSet som är taggade med denna tagg kommer att tillämpa motsvarande kvoter och funktioner. Ta V1, V2 och V3 som exempel:
-
V1: Standardnivå, gratisanvändare, standardtaggen för alla ObjectSet, kan konfigureras för att lagra maximalt 1 GiB data, den offentliga nätverksdistributionen får inte överstiga 100 mbps bandbredd, och nedladdningshastigheten för enstaka strömmar styrs till 1 mbps;
-
V2: Grundläggande betalande medlemmar, konfigurerade för att lagra maximalt 10 GiB data, den offentliga nätverksdistributionen får inte överstiga 10 gbps bandbredd, och nedladdningshastigheten för enstaka strömmar styrs till 10 mbps;
-
V3: Avancerade betalande medlemmar, förutom att tillhandahålla större lagrings- och offentliga nätverksdistributionskvoter, stöder de också konfigurationen för att aktivera ytterligare offentlig nätverksacceleration för svaga nätverk och högpresterande medieaccelerationsfunktioner;
Agent-utvecklare kan flexibelt använda V1/V2/V3-taggning för att hantera de resurser och mervärdesfunktioner som dessa användare kan använda, med hänsyn till olika utvecklingscykler för olika användare.
Set Slice: Inbyggd isolering av massiva användardata
När antalet Set i en Agent Bucket når hundratals miljoner och antalet objekt når hundratals miljarder eller biljoner, kommer själva faktumet att "alla metadata för en enda Bucket är koncentrerade i ett KV-kluster" att medföra dubbla risker för kapacitet och prestanda.
Set Slice tillhandahåller ett sätt att tänka "logiskt odelat, fysiskt delat":
-
Ur ett logiskt perspektiv hanterar du fortfarande bara en Agent Bucket.
-
Fysiskt sett, baserat på omfattningen av Set och objektnamnen i Set, delas metadata upp i flera Slice (skivor). Varje Slice kan lagras på olika kluster. Flera Set är naturligt isolerade och enstaka Set kan expanderas horisontellt.
Set Slice är en ytterligare förlängning och garanti av ObjectSet-kapaciteten. Det löser det underliggande problemet med obegränsad expansion av fysisk kapacitet, samtidigt som det säkerställer stabiliteten och konsistensen i den övre ObjectSet-hanteringsmodellen.
-
Stabil hanteringsgräns: Även om data i en Agent Bucket sträcker sig över flera fysiska kluster, är ObjectSet fortfarande den enda grundläggande enheten för behörigheter, kvoter, fakturering och övervakning. Strategier som utvecklare konfigurerar för ObjectSet (som åtkomstkontroll, kapacitetsgränser) träder automatiskt i kraft på alla relaterade Slices, utan att behöva oroa sig för distributionen av underliggande data.
-
Enstaka Set kan expanderas linjärt: När datamängden för en viss ObjectSet växer snabbt, kommer dess data naturligt att distribueras till flera Slices. Med expansionen av det övergripande klustret växer också kapaciteten för detta ObjectSet sömlöst och linjärt. Utvecklare behöver inte utföra några destruktiva operationer som delning eller migrering av själva ObjectSet.
-
Resursisolering mellan Set: Genom att distribuera objekt inom olika intervall på olika fysiska kluster realiserar SetSlice en högre dimension av resursisolering. I kombination med ObjectSet:s kvothantering kan det effektivt förhindra att datatillväxten för en viss "superstor" ObjectSet tränger undan alla resurser i ett enda kluster, vilket påverkar stabiliteten hos andra ObjectSet, vilket gör den totala kapacitetsrisken kontrollerbar.- Logisk enhetlighet och kompatibilitet: För företag och utvecklare är det alltid en logiskt enhetlig Agent Bucket de möter, oavsett hur många Slice det finns underliggande. Alla operationer på bucket, ObjectSet och objekt förblir oförändrade, vilket uppnår fullständig transparens för fysisk expansion för applikationer på högre nivå.
Set AccessPoint: Isolera varje användares åtkomstpunkt
Agent Bucket stöder att aktivera oberoende åtkomstpunkter (oberoende domäner) för varje ObjectSet, och utöka differentierade säkerhets-, isolerings- och accelerationsfunktioner på åtkomstpunkten. Systemet behöver därför stödja schemaläggning av miljarder oberoende åtkomstpunkter och differentierade konfigurationsmöjligheter.
Oberoende åtkomstdomän {$apid}.tos-objectset-ap.volces.com: Två nivåer av säkerhetsskydd
-
Första nivån Obscurity (doldhet): Oberoende underdomän per användare/ObjectSet, apid hög entropihashning, extremt låg kollisionssannolikhet, det är omöjligt att gissa och uttömma en specifik användares ingång från åtkomstdomänen;
-
Andra nivån Containment (inneslutning): Agent-utvecklare använder sts för att distribuera ObjectSet-nivå åtkomstbehörigheter, även om sts läcker kan dess åtkomstomfång kontrolleras och begränsas till en viss ObjectSets begränsade giltighetstid;
Heuristiskt schemaläggningssystem: Beräkning av schemaläggningsstrategi för miljarder domäner
-
Differentierad åtkomststrategi per användare/ObjectSet:tag
-
Flera användare/ObjectSet sprids automatiskt över olika offentliga nätverksingångar, antalet användare som påverkas av ett enda ingångsfel är kontrollerat
-
Elastisk schemaläggning i hela regionen, automatiskt slutförande av trafikpackning och flytt vid fel/överbelastning av en enskild ingång
-
Användare av offentlig nätverksaccelerationsdistribution, tagga med offentlig nätverkstransmissionsacceleration, automatisk schemaläggning av accelerationsingång
-
Användare av offentlig nätverksrisk, tagga med risk, automatisk schemaläggning av offentlig nätverksisoleringsingång och minska bandbreddskvoten för det offentliga nätverket
-
Användare av intern nätverksövergripande domän, tagga med övergripande domän, automatisk schemaläggning av dedikerad intern nätverksaccelerationsväg
-
Användare av lokal domänaccelerator, tagga med accelerator, automatisk montering av lokal domänaccelerator
Från programmeringsassistent till AI-molndisk, Agent Buckets obegränsade möjligheter
Agent Bucket tillhandahåller en komplett lösning för Agent, och designapplikationsscenarierna för ObjectSet är långt ifrån begränsade till detta. Det kan enkelt utökas till alla applikationer som behöver tillhandahålla tjänster till ett stort antal slutanvändare:
-
Kodförråd: Tidigare, när företag eller individer hostade kod i molnet, behövde de ofta bygga ett - Modellhanteringsplattform: I scenarier för hantering av stora modeller är varje modell inte bara stor i storlek, utan kan också ha olika versioner, vikter och inferenskonfigurationer. Genom att skapa ett ObjectSet för varje modell kan modellvikter, Tokenizer, konfigurationsfiler och relaterade utvärderingsdata paketeras och hanteras i samma utrymme. Driftsidan kan ställa in differentierade krypteringspolicyer, säkerhetskopieringspolicyer och bandbreddskontroll för olika modeller. Samtidigt kan den faktiska användningskostnaden för varje modell beräknas genom inbyggd mätning, vilket ger en grund för fakturering och resursallokering per modell.
-
Data SaaS-tjänst: Data distributionsplattformar som vänder sig till ett stort antal slutanvändare behöver ofta ansluta till många dataleverantörer samtidigt. Det är viktigt att säkerställa tydliga datagränser för alla parter och att undvika prestandarisken med att "en stor tunna drar ner alla". Med hjälp av Agent Bucket kan varje dataleverantör ha sitt eget ObjectSet för att hantera rådata och bearbetningsresultat på ett enhetligt sätt. Genom oberoende domäner och bandbredd, QPS-kvoter kan differentierad servicegaranti och begränsning av flödet utföras för olika leverantörer, vilket realiserar en datadistributionsinfrastruktur med "en plattform, flera leverantörer, isolerade från varandra men med kontrollerbart samarbete".
Referens:
