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 и традиционной "файловой системой". Суть объектного хранилища (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 при разработке AI Agent может построить полностью serverless Agent на основе "Agent SDK + хранилище + MaaS сервис":

• Agent может работать полностью serverless

• Можно комбинировать существующие возможности продукта для создания Agent с помощью Vibe Coding

• Нужно только поддерживать python скрипт "ADK"

• Хранилище использует объектное хранилище

• AI возможности используют 豆包 (Dòubāo - китайский AI сервис)

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

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

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

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

• Agent может напрямую настраивать пропускную способность каждого пользователя, настраивать верхний предел общего размера объектов пользователя

• Agent может выставлять счета, отслеживать и наблюдать за пользователем

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

Agent Bucket: внедрение гена "многопользовательского происхождения" в AI Agent

Чтобы принципиально решить эту проблему, мы предложили совершенно новую парадигму объектного хранилища — Agent Bucket. Его основная инновация заключается во введении нового уровня собственных ресурсов между традиционными "корзинами" и "объектами": набора объектов.

Основная идея этого дизайна чрезвычайно проста: сопоставьте каждому конечному пользователю эксклюзивный ObjectSet. Вы можете представить ObjectSet как "сейф для данных" или "личное облачное пространство", созданное специально для каждого пользователя. Логически он принадлежит вашей (разработчика) Bucket, но физически и управленчески он имеет свою собственную независимую "индивидуальность" и "жизненный цикл".Agent Bucket поддерживает 100 миллионов ObjectSet на каждый бакет, что означает, что вы можете уверенно обслуживать сотни миллионов конечных пользователей, как если бы каждый конечный пользователь "жил" в своем собственном независимом хранилище, и вам больше не нужно беспокоиться об управлении хранилищем для нескольких арендаторов.

Дизайн 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 одним щелчком мыши, связывая векторы, знания, модели и prompt, чтобы напрямую раскрывать сценарные функции под-Agent, позволяя разработчикам Agent верхнего уровня сосредоточиться на создании основного бизнес-процесса и в полной мере раскрыть эффективность монетизации интеллекта.

Технические проблемы, вызванные взрывным ростом масштаба приложений

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

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

• Проблема иерархического управления огромным количеством пользователей: Когда приложение дифференцированно управляет ресурсами и функциями большого количества пользователей разных уровней, ему необходимо самостоятельно разрабатывать и реализовывать метаданные иерархии пользователей и связывать переключатели функций хранения объектов. Помощь разработчикам в элегантном управлении иерархией пользователей на основе изначальной концепции Set является важным фактором ускорения внедрения приложений. - Узкое место однокластерной емкости: Хотя Agent Bucket логически может быть расширен бесконечно, его метаданные по умолчанию хранятся в одном физическом кластере. Когда общее количество объектов в 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 для управления ресурсами и дополнительными функциями, которые могут использовать эти пользователи, в зависимости от различных этапов развития различных пользователей.

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 по разным общедоступным точкам входа, количество пользователей, затронутых сбоем одной точки входа, контролируется

• Эластичное планирование по всем регионам, автоматическое завершение перемещения трафика при любом сбое/перегрузке одной точки входа

• Пользователи класса распространения общедоступного ускорения, добавление тега ускорения общедоступной передачи, автоматическое планирование точки входа ускорения

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

• Пользователи класса межсетевого домена внутренней сети, добавление тега межсетевого домена, автоматическое планирование пути ускорения выделенной линии внутренней сети

• Пользователи локального ускорителя, добавление тега ускорителя, автоматическое подключение локального ускорителя

От помощника по программированию до AI Cloud Disk, безграничные возможности Agent Bucket

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

• Репозиторий кода: В прошлом, когда предприятия или частные лица размещали код в облаке, им часто приходилось строить «систему арендаторов» поверх объектного хранилища, чтобы обеспечить изоляцию учетных записей и контроль разрешений. Теперь каждому разработчику можно выделить эксклюзивный ObjectSet, чтобы унифицировать хранилище кода, артефакты сборки и зависимости. Agent Skills также естественным образом адаптируется к ObjectSet. Загрузка, скачивание и распространение Skills обеспечиваются ObjectSet с сильной изоляцией, чтобы избежать помех во время выполнения Agent.

• Корпоративный фотоальбом/облачный диск: Традиционные фотоальбомы или облачные диски часто смешивают фотографии всех пользователей в одной корзине и различают пользователей по префиксу. Это не только сложно в управлении, но и подвержено «эффекту соседа». На основе ObjectSet фотографии и видео каждого пользователя попадают в свои собственные Set, пики доступа не мешают друг другу, и можно установить верхний предел емкости, стратегии резервного копирования и методы шифрования для каждого пользователя, чтобы действительно добиться «у каждого есть безопасный и контролируемый облачный фотоальбом».

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

• Data SaaS Service: Платформа распространения данных, ориентированная на огромное количество конечных пользователей, часто требует одновременного подключения к многочисленным поставщикам данных. Необходимо обеспечить четкие границы данных для каждой стороны и избежать риска снижения производительности "одна большая бочка тянет всех вниз". С помощью 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/