Agent Bucket: Оригинален сторидж бъкет за трилиони Agent-и

В днешния ден, когато AI Agent-ите изникват като гъби след дъжд, разработчиците изграждат интелигентни приложения с въображение с безпрецедентна скорост. От помощници за програмиране, които могат да ви помогнат да пишете код, до инструменти за създаване, които генерират филм от едно изречение, до лични интелигентни асистенти, които са винаги на разположение, Agent-ите преобразяват начина, по който взаимодействаме с дигиталния свят. Зад тази вълна все повече се оформя консенсус: с помощта на Serverless архитектура (като Lambda), големи езикови модели (LLM) и облачен сторидж (като S3, TOS), комбинирани с Vibe Coding, всеки може бързо да създаде свой собствен AI Agent за 30 минути.

От "използваем" до "лесен за използване", разработчиците на Agent-и все още трябва да преодолеят трудностите, за да преминат от "играчка" към "приложение от производствен клас". С разрастването на бизнеса към огромен брой потребители, разработчиците трябва да се изправят пред изключително сложна задача: как да изградят цялостно решение за съхранение на данни за огромен брой крайни потребители в обектен сторидж? За повечето разработчици това е не само техническа бариера, но и пропаст, която възпрепятства мащабното разпространение на Agent-и. Agent Bucket има за цел да опрости напълно процеса на изграждане на многоклиентски системи чрез AI-ориентиран дизайн на сториджа, осигурявайки по-удобни Agent възможности.

Когато милиарди потребители нахлуят, традиционният обектен сторидж "не е достатъчен"

Представете си, че сте разработили хитово AIGC приложение. Всеки потребител ще генерира и съхранява голям брой снимки, видеоклипове и временни файлове. Като разработчик, естествено ще изберете зрели и мащабируеми услуги за обектен сторидж като S3 и TOS. Но ето го и въпросът: как да управлявате данни за огромен брой потребители?

Блогът на S3 от 2022 г. 《Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3》описва два начина: "използване на отделни S3 бъкети за всеки клиент" и "споделен S3 бъкет, изолиран на базата на префикси":

• Създаване на отделен "бъкет" (Bucket) за всеки потребител: Това е възможно, когато броят на потребителите е малък, но когато броят на потребителите нарасне до десетки хиляди или милиони, броят на бъкетите ще експлодира бързо, а разходите за управление и ограниченията на ресурсите ще станат непоносими. S3 предоставя обща квота от 10 000 бъкета за целия регион, но за горещите AI възможности 10 000 далеч не са достатъчни.

• Разграничаване на потребителите с "префикси" в един и същ бъкет: Това се превърна в основно решение. Например, файловете на потребител A започват с user-a/, а файловете на потребител B започват с user-b/, точно както управлявате файлове с папки на компютър. Въпреки това, в обектния сторидж няма оригинални папки. Това решение разграничава много клиенти чрез "общ префикс" (Prefix) в системата за съхранение "K-V".

Това решение, базирано на "бъкет" или "префикс", е широко използвано през последните десет години. Но има следните проблеми:

• Изолация на много клиенти: Данните на всички потребители са смесени в един и същ бъкет. Необичайно високочестотен достъп от един потребител може да повлияе на всички останали потребители, което води до "ефект на съседа". Не може да се говори за изолация на производителността или изолация на грешки.

• Контрол на разрешенията: Сложните политики за разрешения (IAM Policy) са трудни за поддръжка и е лесно да се появят грешки в конфигурацията, което води до неочакван достъп до потребителски данни, особено когато е необходимо взаимодействие с други облачни услуги, рискът е по-голям.

• Яснота на разходите: Трудно е да се знае точно колко място за съхранение е консумирал всеки потребител и колко такси за трафик са генерирани. Когато искате да таксувате платени потребители въз основа на използването, таксуването и измерването се превръщат в неясна сметка.Защо тези привидно основни изисквания са толкова "тежки" за разработчиците на Agent при реализацията им върху обектно хранилище? Дълбокото проучване на причината е, че в настоящата облачна архитектура съществува огромна празнина между "обектното хранилище" като S3/TOS и традиционната "файлова система". Същността на обектното хранилище (S3/TOS) е "уравняване", а първоначалната цел на дизайна е просто съхранение на огромни количества данни, като огромен склад. Въпреки че капацитетът е почти неограничен, логическата структура е изключително проста. Липсват му вградено разширено управление на директории, фино зърнест контрол на метаданните и истинско възприемане на наемателите. Когато разработчиците се опитват да симулират "триизмерна" многонаемателска файлова система върху "плосък" S3 чрез твърдо кодиране на префикси, ние всъщност използваме "статично KV хранилище", за да носим "директорийна семантика, силна изолация" начин на достъп до файлове на Agent приложение. С други думи, Agent трябва да консумира допълнителни токени, за да управлява файлове и да контролира и разрешава разрешенията и изолацията на много наематели. Тези допълнителни консумирани токени показват, че простата услуга за съхранение, дефинирана от S3, не е достатъчно проста за Agent.

Блогът на S3 от 2025 г. 《Design patterns for multi-tenant access control on Amazon S3》 допълнително обяснява S3 Access Point. Това означава, че могат да бъдат създадени множество виртуални мрежови точки за достъп и за всяка точка за достъп може да бъде конфигурирана персонализирана политика за достъп, която има някои решения за сценарии с много наематели на ниво мрежово планиране.

Agent Wonderland

Един идеален разработчик на Agent може да изгради напълно serverless Agent, базиран на "Agent SDK + хранилище + MaaS услуга", когато разработва AI Agent:

• Agent може да работи напълно serverless

• Може да се конструира Agent чрез комбиниране на съществуващи продуктови възможности чрез Vibe Coding

• Трябва да се поддържа само python скриптът на "ADK"

• Хранилището използва обектно хранилище

• AI възможностите използват Doubao (豆包 - име на AI услуга)

• Теоретично няма ECS или други продукти от тип инстанция

В същото време хранилището трябва да предоставя следните възможности:

• Agent може да има хранилище със семантика на обект (запазване на файлове), предоставяйки възможност за достъп на много наематели, започвайки от милиони и разширявайки се до стотици милиони

• Agent може да предостави независимо пространство за всеки потребител (между множество услуги, имената на услугите или uid могат да бъдат дублирани)

• Agent може директно да конфигурира честотната лента на всеки потребител и да конфигурира горната граница на общия размер на обекта на потребителя

• Agent може да таксува, наблюдава и наблюдава според потребителя

• Agent може да конфигурира политики за достъп за файловете на всеки потребител

Agent Bucket: Инжектиране на "многонаемателски вградени" гени в AI Agent

За да разрешим този проблем фундаментално, ние предлагаме напълно нова парадигма на обектно хранилище - Agent Bucket. Основната му иновация е въвеждането на ново ниво на вградени ресурси между традиционните "кофи" и "обекти": колекция от обекти.

Основната идея на този дизайн е изключително проста: съпоставете всеки краен потребител със специален ObjectSet. Можете да си представите ObjectSet като "сейф за данни" или "лично пространство в облака", създадено специално за всеки потребител. Логически принадлежи към вашата (на разработчика) Bucket, но във физически и управленски план има своя собствена независима "индивидуалност" и "жизнен цикъл".## Дизайн на ObjectSet – възможности, ориентирани към Agent

В Agent Bucket ObjectSet не е просто добавяне на ниво, а превръща най-трудните нужди в сценарии с много клиенти в готови за употреба основни възможности. След като собствеността върху данните бъде изяснена на ниво ObjectSet, редица възможности, които бяха трудни за реализиране в миналото, стават естествени.

• Естествена изолация: На ниво ObjectSet можете да зададете независими QPS, ограничения на честотната лента и квоти за капацитет за всеки потребител. Изживяването на платените потребители може да бъде гарантирано, а необичайното поведение на безплатните потребители няма да засегне другите. Това е истинска изолация на домейна на повреда, така че "съседите" вече не си пречат.

• Естествени разрешения: Всеки ObjectSet може да има независим домейн. Това означава, че можете да дадете на потребител A ексклузивен адрес за достъп user-a.yourapp.com, вместо да излагате домейна на целия контейнер за съхранение. По-умният дизайн е "две ключалки": първата ключалка е временен идентификатор за достъп (STS), издаден от доставчика на облачни услуги, който контролира разрешенията за достъп на ниво приложение; втората ключалка е независимият домейн на ObjectSet, който заключва заявките за достъп в собственото пространство за данни на потребителя от мрежово ниво. Това значително подобрява сигурността на данните.

• Естествен мониторинг: На таблото за мониторинг вече не можете да виждате само общите данни за целия контейнер. Можете да разделите графиките за мониторинг по ObjectSet, за да получите ясна представа кой краен потребител извършва голям брой достъпи, за да вземете точни решения за работа и оптимизация.

• Естествено понижаване на възможностите: Политиките, които преди можеха да бъдат зададени само на ниво контейнер, вече могат да бъдат понижени до всеки потребител. Можете да зададете различни жизнени цикли на данните за потребители от различни нива или да използвате различни ключове за криптиране за всеки ObjectSet, за да постигнете по-фино и по-сигурно управление на данните.

• Естествено измерване: Искате да знаете колко място за съхранение използва всеки потребител? Искате да разпределите точно разходите за съхранение на всеки потребител? Сега е лесно. Agent Bucket автоматично ще събира статистически данни за капацитета и използването на всеки ObjectSet, което прави вашето таксуване и споделяне на приходи ясни.

• Естествено таксуване: Разработчиците могат лесно да реализират споделяне на разходите и точно да върнат разходите, генерирани от съхранението, на всеки краен потребител. Например, таксувайте диференцирано според действителните пропорции на разходите, генерирани от различни потребители A, B и C, за да предоставите поддръжка на данни за комерсиализацията на Agent.

• Естествен лимит на капацитета: За да контролирате оперативните разходи на Agent, можете да зададете Quota (лимит на капацитета) за всеки ObjectSet. След като бъде достигната предварително зададената стойност, системата ще ограничи потребителя да продължи да генерира нови файлове, като по този начин ще избегне злоупотреба с ресурси в сценарии с много клиенти от самото начало.

• Естествен интелект: Agent Bucket позволява на Agent да излезе отвъд традиционните прости "съхранение и извличане" на файлове, давайки на Object естествен интелект и по-ефективно поддържа еднократното разработване на Agent. ObjectSet може да бъде включен с едно щракване за интелигентно индексиране, за да предостави на Agent естествено приятелски възможности за многомодални въпроси и отговори, за да замени механичните операции на традиционния Object CRUD; той дори поддържа включване на режим Agentself с едно щракване, свързване на вектори, знания, модели и подкани, директно разкриване на сценирани функции на под-агент, позволявайки на разработчиците на Agent от горно ниво да се съсредоточат върху създаването на основен бизнес работен поток и напълно да освободят ефективността на монетизацията на интелигентността.

Технически предизвикателства, породени от експлозивния растеж на приложенията

Agent Bucket предоставя на разработчиците на приложения елегантен и ефективен начин за управление на данни на стотици милиони крайни потребители чрез въвеждането на основната концепция за ObjectSet. Цифровите активи на всеки потребител са сигурно съхранени в неговия ексклузивен ObjectSet, като естествено се реализира изолация, таксуване и управление на квоти.

С бързото разширяване на мащаба на приложението, сложността на управлението на масивни Set, трудността на изолацията и физическите ограничения се появяват едновременно:

• Проблем с йерархичното управление на масивни потребители: Когато приложението диференцирано управлява ресурсите и характеристиките на голям брой потребители от различни нива, то трябва да проектира и реализира свои собствени метаданни за йерархията на потребителите и да свърже превключвателите на функциите за съхранение на обекти. Подпомагането на разработчиците да управляват елегантно йерархията на потребителите на базата на основната концепция на Set е важно за ускоряване на внедряването на приложения. - Ограничения на капацитета на един клъстер: Въпреки че Agent Bucket може логически да се разширява неограничено, неговите метаданни по подразбиране се съхраняват в един физически клъстер. Когато общият брой обекти в кофата достигне стотици милиарди или дори трилиони, физическият капацитет на един клъстер се превръща в непреодолим лимит.

• Проблеми със споделянето на точки за достъп: Разнообразието на услугите на Agent и огромният брой потребители носят по-големи рискове за сигурността и радиус на експлозия за самата точка за достъп. Как да се извърши динамично планиране според различията на голям брой различни услуги и потребители, за да се постигнат диференцирани възможности за сигурност, изолация и ускорение, се превръща в трудност.

Set Tagging: Управление на потребителските нива чрез етикетиране

ObjectSet предоставя естествен метод за управление чрез етикетиране, позволявайки на разработчиците на Agent лесно да използват възможностите за set tagging, за да завършат управлението на потребителските нива. Разработчиците могат да съпоставят всяко дефинирано потребителско ниво с таг и да активират различни квоти и характеристики за всеки таг. Всички ObjectSet, маркирани с този таг, ще прилагат съответните квоти и характеристики. Да вземем за пример три нива: V1, V2 и V3:

• V1: Ниво по подразбиране, безплатни потребители, таг по подразбиране за всички ObjectSet, може да бъде конфигуриран да съхранява максимум 1GiB данни, публичното разпространение не може да надвишава 100mbps честотна лента, а скоростта на изтегляне на един поток е ограничена до 1mbps;

• V2: Платени членове от начално ниво, конфигурирани да съхраняват максимум 10GiB данни, публичното разпространение не може да надвишава 10gbps честотна лента, а скоростта на изтегляне на един поток е ограничена до 10mbps;

• V3: Платени членове от висок клас, в допълнение към предоставянето на по-голям капацитет за съхранение и квоти за публично разпространение, те също така поддържат конфигуриране на допълнително ускорение на слаба мрежа и възможности за ускорение на високопроизводителни медии;

Разработчиците на Agent могат гъвкаво да използват V1/V2/V3 tagging, за да управляват ресурсите и допълнителните функции, които тези потребители могат да използват, в различните етапи на развитие на различните потребители.

Set Slice: Естествена изолация на данни за огромен брой потребители

Когато броят на Set в Agent Bucket достигне стотици милиони, а броят на обектите достигне стотици милиарди или трилиони, фактът, че "всички метаданни на един Bucket са централизирани в един KV клъстер" сам по себе си ще доведе до двойни рискове за капацитета и производителността.

Set Slice предоставя идея за "логическо неразделяне, физическо разделяне":

• От логическа гледна точка, вие все още управлявате само един Agent Bucket.

• Физически, според обхвата на Set и имената на обектите в Set, метаданните се разделят на множество Slice (фрагменти), всеки Slice може да се съхранява в различни клъстери, множество Set са естествено изолирани, а единичен Set се разширява хоризонтално.

Set Slice е по-нататъшно разширение и гаранция за възможностите на ObjectSet. Той решава проблема с неограниченото разширяване на физическия капацитет в основата, като същевременно гарантира стабилността и последователността на горния модел за управление на ObjectSet.

• Стабилна граница на управление: Дори ако данните на Agent Bucket обхващат множество физически клъстери, ObjectSet все още е единствената основна единица за разрешения, квоти, таксуване и наблюдение. Политиките, конфигурирани от разработчиците за ObjectSet (като контрол на достъпа, ограничение на капацитета), автоматично ще влязат в сила върху всички свързани Slices, без да е необходимо да се притеснявате за разпределението на основните данни.

• Единичен Set може да се разширява линейно: Когато обемът на данните на даден ObjectSet расте бързо, неговите данни естествено ще бъдат разпределени в множество Slices. С разширяването на целия клъстер, капацитетът на този ObjectSet също се увеличава безпроблемно и линейно. Разработчиците не трябва да извършват никакви разрушителни операции като разделяне или миграция на самия ObjectSet.

• Изолация на ресурси между Set: Чрез разпределяне на обекти с различни обхвати в различни физически клъстери, SetSlice постига по-високо ниво на изолация на ресурси. В комбинация с управлението на квоти на ObjectSet, може ефективно да се предотврати нарастването на данните на даден ObjectSet "супер голям потребител" да изтласка всички ресурси на един клъстер, като по този начин се повлияе на стабилността на други ObjectSet, което прави общия риск от капацитет контролируем.- Логическа унификация и съвместимост: За бизнеса и разработчиците, независимо колко Slice има отдолу, те винаги се изправят пред логически унифицирана Agent Bucket. Всички операции, насочени към кофи, ObjectSet и обекти, остават непроменени, реализирайки пълна прозрачност на физическото разширение за горните приложения.

Set AccessPoint: Изолиране на входната точка за достъп на всеки потребител

Agent Bucket поддържа отварянето на независими точки за достъп (независими домейни) за всеки ObjectSet и разширява диференцирани възможности за сигурност, изолация и ускорение на точките за достъп. За тази цел системата трябва да поддържа планиране на независими точки за достъп от порядъка на стотици милиони и диференцирани възможности за конфигуриране.

Независим домейн за достъп {$apid}.tos-objectset-ap.volces.com: Двустепенна защита

• Първо ниво Obscurity (скриване): Независим поддомейн By User/ObjectSet, apid с висока ентропия, изключително ниска вероятност за колизии, невъзможност за отгатване и изчерпване на конкретен потребителски вход от гледна точка на домейна за достъп;

• Второ ниво Containment (ограничаване): Agent разработчиците използват sts за разпространение на разрешения за достъп на ниво ObjectSet. Дори sts да изтече, той може да контролира обхвата на достъп, ограничен до ограничен срок на валидност на определен ObjectSet;

Евристична система за планиране: Изчисляване на стратегия за планиране на домейни от порядъка на стотици милиони

• Диференцирана стратегия за достъп By user/ObjectSet:tag

• Автоматично разпръскване на множество user/ObjectSet в различни публични входове, контролиран брой потребители, засегнати от повреда на единичен вход

• Еластично планиране в цялата област, автоматично завършване на преместване на трафика при повреда/претоварване на произволен единичен вход

• Потребители от клас за ускорено публично разпространение, маркиране с tag за ускорение на публичния трансфер, автоматично планиране на вход за ускорение

• Потребители от клас публичен риск, маркиране с tag за риск, автоматично планиране на вход за изолация на публичната мрежа и намаляване на квотата за честотна лента на публичната мрежа

• Потребители от клас вътрешно-мрежово кръстосано домейн, маркиране с tag за кръстосано домейн, автоматично планиране на ускорен път на вътрешно-мрежова специализирана линия

• Потребители на локален ускорител, маркиране с tag за ускорител, автоматично монтиране на локален ускорител

От помощник за програмиране до AI облачен диск, безкрайните възможности на Agent Bucket

Agent Bucket предоставя цялостни решения за Agent и сценариите на приложение на дизайна на ObjectSet са далеч отвъд това. Той може лесно да бъде разширен до всички приложения, които трябва да предоставят услуги на огромен брой крайни потребители:

• Хранилище за код: В миналото, когато предприятия или физически лица хостваха код в облака, те често трябваше да изградят слой "система за наематели" върху хранилището за обекти, за да постигнат изолация на акаунти и контрол на разрешенията. Сега, на всеки разработчик може да бъде присвоен ексклузивен ObjectSet, който да обедини хранилището за код, артефактите за изграждане и зависимостите. Agent Skills също естествено се адаптира към ObjectSet. Качването, изтеглянето и разпространението на Skills се осигурява от ObjectSet със силна изолация, за да се избегне смущение от съседи по време на изпълнение на Agent.

• Корпоративен албум/облачен диск: Традиционните услуги за албуми или облачни дискове често смесват снимките на всички потребители в една и съща кофа, като разграничават потребителите чрез префикси. Това е не само сложно за управление, но и предразположено към "ефект на съседство". Въз основа на ObjectSet, снимките и видеоклиповете на всеки потребител попадат в собствените им Set, пиковете на достъп не си пречат един на друг и могат да бъдат зададени горни граници на капацитета, стратегии за архивиране и методи за криптиране според потребителя, за да се постигне наистина "всеки има безопасен и контролируем облачен албум".

• Hadoop хранилище за данни: В корпоративно хранилище за данни различни бизнес линии и различни бази данни често споделят ресурси на една и съща основна памет. Чрез картографиране на всяка база данни към ObjectSet, предприятията могат да реализират изолация и контрол на квотите на база данни върху унифицирана памет. По-специално, ObjectSet предоставя допълнителен слой разрешения в TOS, за да осигури изолация и контрол на разрешенията за бази данни и таблици, съхранени в TOS, без да се променя съществуващият Proton on TOS. - Платформа за хостване на модели: В сценарии за хостване на големи езикови модели, всеки модел е не само обемен, но може да има и различни версии, тегла и конфигурации за извод. Създаването на ObjectSet за всеки модел позволява пакетирането и хостването на теглата на модела, Tokenizer, конфигурационни файлове и свързани данни за оценка в едно и също пространство. От страна на операциите, могат да бъдат зададени диференцирани политики за криптиране, политики за архивиране и контрол на честотната лента за различни модели. В същото време, чрез вградените възможности за измерване, може да се изчисли реалната цена на използване на всеки модел, което да осигури основа за таксуване и планиране на ресурсите на базата на модел.

• Data SaaS услуги: Платформите за разпространение на данни, насочени към огромен брой крайни потребители, често трябва да се свързват с много доставчици на данни едновременно. Необходимо е да се гарантира ясна граница между данните на всяка страна и да се избегне риска от производителност "един голям контейнер да забави всички". С помощта на Agent Bucket, всеки доставчик на данни може да има свой собствен ObjectSet, за да управлява унифицирано необработените данни и резултатите от обработката. Чрез независими домейни и честотна лента, както и квоти за QPS, може да се осигури диференцирана гаранция за обслужване и ограничаване на трафика за различни доставчици, реализирайки инфраструктура за разпространение на данни "една платформа, много доставчици, изолирани един от друг и контролирано сътрудничество".

Reference:

• 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/