先讲一个我自己的翻车现场。去年做一个AI陪练Agent功能不复杂用户登录后和Agent对话Agent需要记住上次聊到哪、用户的偏好、上传过的文档。第一版我用了最朴素的方案——会话状态放Redis用户文件丢S3向量检索走Milvus。看起来每个组件都在该在的位置结果一上线就出事。用户会话一多恢复一次对话要拼五六次查询S3里的文件路径靠手写拼接时间一长根本分不清哪个文件属于哪次会话。最要命的是一旦文件被误删整个会话的上下文就断了。你说这是个存储问题吗是也不是。它本质上是AI Agent应用的数据访问模式跟传统存储模型根本不匹配。这篇文章想聊的就是我在这个过程中解决的问题为什么AI Agent应用需要一套新的存储抽象以及从S3到Agent Bucket这条路到底怎么走。我会把完整的思路、选型依据、代码实现和踩坑记录都摊开讲目标是让看完的人能在30分钟内搭出一套支撑百万级用户规模的Agent存储底座。适合正在做AI Agent应用、或者准备把现有应用改造成Agent形态的开发者参考。1. 为什么AI Agent应用会倒逼存储架构变革1.1 传统存储模型和Agent应用之间的根本矛盾传统应用的数据访问模式是“以记录为中心”用户表、订单表、日志表CRUD搞定一切。存储层只需要保证单条记录的读写可靠、查询走索引、事务满足ACID就行。但AI Agent应用不是这个玩法。Agent应用的数据访问模式是“以会话与记忆为中心”每一次交互都围绕一段对话、一个任务、一份上下文快照展开数据之间有强烈的时序、归因和派生关系。举个例子用户问Agent“帮我分析一下上个月的账单”Agent需要拉取历史账单文件、读取用户此前的消费偏好、调用工具做计算最后把结果写回会话。这里涉及对象文件、向量索引、结构化元数据、工具调用记录四种不同形态的数据但是它们必须作为一个整体被保存和恢复。传统存储架构下这些数据散落在不同系统里业务层要自己维护它们之间的关联复杂度全部堆积在应用代码里。这就是Agent Bucket要解决的第一个问题把散落的存储资源抽象成“Agent视角的统一存储空间”让Agent的记忆、会话、附件、工具状态都具备统一的读写、检索和生命周期管理能力。1.2 Agent工作负载的四个新特征从实际运营角度看Agent应用给存储层带来的压力远不止“多存点数据”这么简单我整理了四个显著特征高度状态化。每次对话都会有会话状态、上下文快照、临时中间结果。用户中断对话再回来说“继续刚才的”系统必须能把完整的记忆状态重建出来。这意味着存储层不能只保存最终结果还要保存过程状态。多模态内容。文本、图片、音频、PDF、结构化JSON可以同时出现在一条消息里。你既要把原始文件存下来又要能按内容和语义去检索它们。语义检索需求。“帮我找上次聊过的那份产品需求文档”这类请求本质上是模糊语义查询靠文件名前缀匹配完全不够必须配合向量索引。生命周期管理。Agent的记忆不是越多越好有短期记忆、长期记忆、过期遗忘的区分。存储层需要支持精细化的自动归档与清理策略。这四个特征叠加后传统对象存储的“存文件”模式就显得太单薄了。S3可以放心地把文件存进去但它不关心这个文件属于哪段对话、承载了什么记忆、在什么条件下应该被遗忘——这些语义必须由上层补全。1.3 为什么S3单独扛不住Agent场景S3作为对象存储的标准本身没有任何问题强一致性、高持久性、全球规模这些能力都是经过实战检验的。但在Agent场景里单独用S3会撞上几个很现实的墙扁平命名空间的表达力有限。S3只有“桶前缀对象”这一层组织方式而Agent数据天然有“用户-会话-消息-记忆-附件”的多层归属关系。虽然可以用users/{user_id}/sessions/{session_id}/这种方式硬编码出层级但查询任何一层关系都要走 List 接口对象一多性能就崩而且这种解析逻辑散落在业务代码里维护成本极高。缺少语义层。S3不知道什么是“用户A的长期记忆”、什么是“某次工具的调用快照”。要做记忆召回必须业务层自己维护一份单独的元数据索引还要保证它和S3里的对象永远一致。小对象场景成本感人。Agent消息大多是几KB的JSON或者Markdown片段一次上传要付出一次请求成本标准存储按容量计费的同时还要为百万级的小对象交额外费用。我做过一个粗略估算100万用户每人每天20条交互就是每天2000万个对象写入光PUT请求费用一天就能消耗掉可观的预算这个在后面的成本章节我会展开算。所以S3依然是很好的底层存储引擎但它需要被包一层“语义壳”。Agent Bucket就是这层壳。2. Agent Bucket的设计逻辑与核心能力拆解2.1 Agent Bucket到底是个什么东西先明确一点Agent Bucket不是一个闭源商业产品也不是某个大厂新发布的服务名称。它是存储社区里正在形成的一类实践模式本质是一个“面向Agent应用的对象存储抽象层”。你可以把它理解为S3之上的一个语义中间层物理文件仍然存放在S3及兼容对象存储里但应用读写的不再是“文件”而是“记忆”“会话”“消息”这些Agent业务概念。这个抽象层的价值类比一下就很清楚没有它的时候Agent应用像一间杂货铺所有东西直接堆在地上找东西全靠人肉记忆有了它之后铺子装上了货架、贴上了标签、做了入库登记任何时候都能快速定位和取用。对于存储而言“货架”就是划分清晰的命名空间“标签”就是语义索引“入库登记”就是元数据管理。我在项目中实践的Agent Bucket方案由四层构成层次职责典型实现语义API层提供记忆读写、会话恢复、语义检索接口自研SDK如 put_memory / search_memory / restore_session元数据索引层记录对象归属、会话关联、时间线、重要度PostgreSQL或MySQL向量检索层支持语义级召回pgvector、Milvus、Qdrant对象存储层保存实际文件内容S3、MinIO、OSS、R2你完全可以在不改变底层对象存储的前提下把这套抽象层搭建起来这也是我认为Agent Bucket最具落地价值的一点。2.2 数据模型的重新抽象设计Agent Bucket的第一件事是把数据模型从“文件模型”切换成“记忆模型”。我在实际项目中定义了这样几类核心实体Agent。一个具体的AI Agent实例有自己的配置、知识库和默认记忆范围。Session。一次完整的对话会话包含一组按时间排序的消息记录。Message。单条交互消息可以是用户输入、Agent输出或工具调用结果可携带附件。Memory。跨会话的持久记忆可以是用户偏好、历史事实、任务结论是语义召回的基本单元。Attachment。消息中携带的原始文件独立存储消息体里只保存引用关系。这个模型对应到S3的Key设计一般是s3://agent-bucket/users/{user_id}/agents/{agent_id}/ ├── sessions/{session_id}/messages/{message_id}.json ├── sessions/{session_id}/attachments/{attachment_id}.bin └── memories/{memory_id}.json和直接在S3上堆文件的思路比起来区别在于这种路径不再是给人类看的“文件名”而是给Agent语义层用的“地址簿”。所有检索和恢复动作都优先查元数据库拿到地址再精准访问对象不需要遍历整个桶。2.3 三大核心能力语义索引、时间线感知、自动遗忘一个合格的Agent Bucket至少要具备三个核心能力。第一是语义索引。所有写入的记忆消息在存储原文件之外都要转换为向量存入向量库支撑“语义相似度召回”。比如用户说“找一下我上次让你看的那个方案”系统能根据向量相似度匹配到正确的记忆对象。第二是时间线感知。会话和记忆都要带准确的时间维度支持按时间范围回溯。我通常会在所有元数据表里保留created_at、updated_at和session_start_at三个时间字段这能解决很多模糊查询问题。第三是自动遗忘。长期运行之后记忆会越来越多如果不加控制检索质量和存储成本都会恶化。Agent Bucket需要支持按重要度、活跃时间维护“记忆热度”把寒冷记忆自动迁移到低成本存储层或直接清理。S3原生Lifecycle策略可以按月龄转换存储级别但这里要强调的是遗忘的决策逻辑应该在语义层完成存储层只负责执行归档和删除。3. 落地选型与整体架构方案3.1 底层对象存储怎么选Agent Bucket对底层对象存储的核心要求是S3 API兼容、可靠性高、成本可预期。我把市面上的常见选项对比过一轮这里直接给结论方案优势需要注意的点AWS S3功能最全、生态最好、生命周期策略成熟国内访问延迟偏高费用要精细控制阿里云OSS国内访问快与云生态集成好部分高级能力与S3 API存在差异Cloudflare R2免流量费、全球边缘节点、价格便宜冷门功能支持相较于S3少MinIO完全自托管、S3兼容度高、适合私有化需要自己运维集群、高可用要下功夫我的建议如果目标用户在国内优先选OSS或者兼容S3协议的云服务商如果在做全球化产品S3或R2更顺手如果是企业内部私有化部署MinIO是最稳的选择。选型的基本原则是尽量选S3 API兼容性高的因为Agent Bucket语义层希望屏蔽底层差异API越兼容适配成本越低。3.2 语义索引层的核心设计语义索引层是Agent Bucket的大脑我通常用PostgreSQL承载结构化元数据用pgvector或者独立的Milvus承载向量索引。这两者不是二选一的关系而是分工协作结构化元数据负责回答“这个对象属于谁、什么时间、什么类型”——例如“用户A在7月15日上午10点的会话里上传过一个PDF”向量索引负责回答“哪些记忆在语义上和用户当前的问题最相关”——例如“用户现在问的是账单分析历史记忆里讨论过消费习惯的条目优先被召回”。元数据表结构不用设计得太复杂我参考的简化版本是CREATE TABLE agent_memories ( id UUID PRIMARY KEY, user_id VARCHAR(64) NOT NULL, agent_id VARCHAR(64) NOT NULL, session_id UUID NOT NULL, memory_type VARCHAR(32), -- message / memory / tool_result content_ref VARCHAR(512), -- S3对象地址 content_summary TEXT, -- 简洁摘要用于列表展示 importance_score FLOAT DEFAULT 0.5, created_at TIMESTAMPTZ DEFAULT now(), last_accessed_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_memories_user_time ON agent_memories (user_id, created_at DESC); CREATE INDEX idx_memories_agent_type ON agent_memories (agent_id, memory_type);这套表结构非常简单但已经能支撑绝大多数场景的查询需求。向量字段不直接放进主表我建议用独立的向量表或者在pgvector的列式存储里单独建向量列避免拖慢主表的写入性能。3.3 整体架构长什么样把各层拼起来后整个系统架构是这样的客户端请求先打到Agent服务Agent服务通过Agent Bucket SDK进行数据读写。SDK内部完成三件事更新PostgreSQL元数据、写入或读取S3对象、同步向量索引。在Agent服务前面还有一层Redis缓存用来缓存最近活跃会话的完整消息列表避免每次都回源S3。写入路径上的关键是“双写一致”。对象写入S3、元数据写入PostgreSQL、向量写入向量库这三个动作天然不是原子操作所以要么用事务性发件箱模式要么用基于版本号的补偿机制。我选择的方式是以PostgreSQL业务表为主记录S3对象和向量都通过异步任务最终一致查询时如果发现向量缺失会触发自动重建。读取路径上的关键是“缓存优先”。resume一个会话时先查Redis命中就直接返回没命中再走元数据定位S3对象同时把结果回填到Redis。这个缓存策略能把会话恢复的P99延迟从几百毫秒降到几十毫秒。4. 30分钟实操构建一个可用的Agent Bucket4.1 第一步定义数据模型和命名空间规范动手编码之前先把命名空间和数据模型定下来。这套规范后续很难改改一次就意味着存量对象要迁移务必一次到位。我实际使用的S3 Key规范是{bucket}/{env}/users/{user_id}/agents/{agent_id}/sessions/{session_id}/messages/{message_id}.json {env}/users/{user_id}/agents/{agent_id}/sessions/{session_id}/attachments/{attachment_id}.bin {env}/users/{user_id}/agents/{agent_id}/memories/{memory_id}.json注意桶的第一层放的是{env}也就是环境名prod/staging/dev。这一点很多人会忽略。如果不分环境测试数据会污染生产数据清理起来极其痛苦。我吃过这个亏后来重构时花了整整两天做数据迁移。消息JSON的内部结构我是这样定义的{ message_id: msg_001, role: user, content: 请分析我的月度账单, content_type: text, created_at: 2025-06-01T10:00:00Z, attachments: [ { attachment_id: att_001, storage_path: prod/users/u001/agents/a001/sessions/s001/attachments/att_001.bin, mime_type: application/pdf, size_bytes: 245760 } ] }消息体只保存附件的引用路径不内联附件内容这是避免消息JSON膨胀的关键——热词里那条expected , or ] after array element的报错我怀疑就是消息体里嵌入了超大JSON导致的序列化问题后面排查章节细说。4.2 第二步搭建语义索引查询层模型定义好后下一步是把核心读写逻辑实现出来。我建议不要一开始就追求完整SDK先实现四个最核心的方法写入会话消息、恢复完整会话、追加记忆、语义检索记忆。足够覆盖最常见的Agent应用场景。这是一个用Python实现的最小可运行版本import json import uuid import boto3 from datetime import datetime, timezone class AgentBucket: def __init__(self, bucket, prefixprod): self.bucket bucket self.prefix prefix self.s3 boto3.client(s3) # 伪代码实际项目中在这里注入 PostgreSQL 连接与向量库客户端 self.db None self.vector_store None def _object_key(self, user_id, agent_id, session_id, message_id): return (f{self.prefix}/users/{user_id}/agents/{agent_id}/ fsessions/{session_id}/messages/{message_id}.json) def put_message(self, user_id, agent_id, session_id, role, content, attachmentsNone): message_id fmsg_{uuid.uuid4().hex} message { message_id: message_id, role: role, content: content, created_at: datetime.now(timezone.utc).isoformat(), attachments: attachments or [] } key self._object_key(user_id, agent_id, session_id, message_id) self.s3.put_object( Bucketself.bucket, Keykey, Bodyjson.dumps(message, ensure_asciiFalse), ContentTypeapplication/json ) # 写元数据伪代码insert into agent_memories(...) # 写向量伪代码embed content and upsert to vector db return message_id def restore_session(self, user_id, agent_id, session_id): # 伪代码先从 Redis 查命中则直接返回 # 再从 PostgreSQL 查出该会话所有 message 的引用 message_refs self.db.query( SELECT message_id FROM agent_memories WHERE user_id%s AND session_id%s ORDER BY created_at, (user_id, session_id) ) messages [] for ref in message_refs: key self._object_key(user_id, agent_id, session_id, ref[message_id]) obj self.s3.get_object(Bucketself.bucket, Keykey) messages.append(json.loads(obj[Body].read())) return messages def search_memories(self, user_id, agent_id, query, top_k5): # 伪代码query - embedding - vector search - 返回 memory_id 列表 # 然后按 memory_id 从元数据表补全内容 hit_ids self.vector_store.search( user_id, agent_id, query, top_k ) return [self.db.fetch_memory(mid) for mid in hit_ids]这套代码很朴素但已经具备了Agent Bucket的骨架。put_message负责写入restore_session负责时间线恢复search_memories负责语义召回。实际的线上版本无非是加上连接池、重试、幂等和监控核心逻辑就是这几条。4.3 第三步接入向量检索与缓存在代码骨架基础上最重要的一步是把语义检索真正做通。我用的方案是embedding模型负责把文本转成向量Milvus负责存向量和做相似度检索。这里有一个技术选型上的心得如果项目规模不大完全不用引入独立向量数据库直接用PostgreSQL的pgvector插件就可以。只有当数据量超过千万级、查询并发很高时再把向量独立到Milvus或Qdrant。embedding模型的选择上中文场景建议用BGE系列或通义系列的embedding模型英文场景可以考虑OpenAI的embedding接口。模型输出维度不用太纠结常见的是1024维或者1536维。对于Agent记忆这种大部分是短文本的场景我还建议在向量索引建立时额外存一个summary字段用一句话概括记忆内容这样列表展示页不需要全文解析JSON性能好很多。缓存层的接入也很关键。我使用Redis缓存最近活跃会话缓存内容的格式是session:{session_id}:messagesvalue是消息列表的JSON序列化结果key设置24小时过期。这样用户从昨天中断的地方继续对话时绝大多数情况是直接从Redis恢复压根不会打到S3上。4.4 第四步配置存储生命周期策略最后一步是配置冷热分层与清理策略。S3和OSS都支持生命周期规则针对不同前缀设置转换和过期策略。我这里用的是典型的三层策略{ Rules: [ { Id: hot-to-warm, Status: Enabled, Filter: {Prefix: prod/users/}, Transitions: [ {Days: 30, StorageClass: STANDARD_IA} ] }, { Id: inactive-memory-cleanup, Status: Enabled, Filter: {Prefix: prod/users/}, Expiration: { Days: 180, ExpiredObjectDeleteMarker: true } } ] }但这里必须强调一个容易踩的坑生命周期规则是按对象的物理访问时间或创建时间判断的不是按Agent记忆的“重要度”判断的。所以规则只能处理那些确定可以删除的冷数据比如超过180天没更新的会话附件。对于记忆重要度这种需要业务判断的清理逻辑必须由Agent Bucket的元数据库驱动算出哪些memory_id该删除再调用存储API精确删除对象。两条线路并行缺一不可。5. 百万级用户场景下的性能与成本优化5.1 性能瓶颈到底在哪百万级用户听起来很吓人但拆开算一算真正的压力点就清楚了。假设100万日活用户每人每天发20条消息每天新增2000万条消息。每条消息的JSON平均1KB附带一个临时向量每天新增原始数据约20GB。存储容量的压力不大一年才7.2TB真正吃力的是两个地方一是对象数量。一年下来就是70多亿个对象。S3的List接口在这种规模下基本不可用任何需要遍历桶的代码都会超时——所以我在前面强调绝对不要用List前缀的方式找消息所有定位都必须走元数据库。二是请求QPS。2000万条写入分摊到业务峰值每秒可能有上千次PUT请求。S3的吞吐能力没有问题但每次PUT都走公网会有延迟抖动所以写入链路上一定要加异步批处理把多条消息打包后合并上传。我在实际项目中验证过的性能参数单次put_message全链路耗时约30-50ms其中S3 upload占大头restore_session从Redis命中时P99约40ms回源S3时P99约200mssearch_memories的P99约100ms。这些指标对Agent对话场景足够用。5.2 缓存策略与读写路径优化Agent存储的读写比例非常不均衡。“写入一次、读取多次”是常态所以缓存的价值特别大。我总结了几条行之有效的策略会话维度的最近N条消息强缓存到Redis。用户恢复会话时优先返回这N条让对话能立刻开始再异步加载更早的历史消息。记忆对象的向量检索结果做短TTL缓存。同一个用户短时间内用相近表述反复问同一个问题应该命中缓存而不是每次重新检索。附件文件通过预签名URL直传直下。上传和下载都让客户端直接和对象存储交互不经过Agent服务中转这是消解服务器带宽压力的关键。这里有个容易忽略的点S3预签名URL是有有效期的默认几十分钟到几小时。如果业务里需要用户长时间访问同一个小文件比如产品文档生成后要预览几天建议为长期分享场景单独生成带长时间有效期的URL或者干脆走CDN域名。5.3 成本控制请求费比容量费更值得关注很多人估算存储成本时只看容量费实际在Agent场景里这是典型的“算错账”。再看这个数据100万用户每日2000万条消息按对象存储每1000次PUT请求约0.005美元计算光写请求一天的账单就是100美元一个月3000美元而对应的容量费一个月可能不到100美元。请求费远超容量费。控制请求费用的手段主要有三个第一是合并写入。多条工具调用日志、多条流式片段在业务层攒够一定数量或者达到时间阈值后打包成一个JSON数组再写入S3。这样对象数量减少、请求次数大幅降低。代价是读取单条消息时要多一层解析但这个开销完全可以接受。第二是合理的生命周期转储。超过30天的冷会话数据迁移到低频访问存储存储单价降低的同时请求费也会降低。超过180天的会话附件可以直接过期删除。第三是控制向量库存量。向量数据是按条数和维度收费的Agent运行越久向量越多。我的做法是定期对记忆去重和压缩高度相似的记忆合并成一条不活跃用户的向量降维或者迁移到冷存储。这个清理任务用定时任务跑每个月一次就够。6. 常见问题与排查技巧实录6.1 元数据与对象不一致会话恢复时缺数据这是Agent Bucket最常见的故障我在开发阶段就重复踩过好多次。典型场景是对象成功写入S3但因为网络抖动等原因元数据写入PostgreSQL失败导致这个对象永远“隐身”了。解决方案是采用事务性发件箱模式把“会话消息元数据”和“待同步事件”放在同一个数据库事务里后台任务负责把待同步事件推送给向量库和对象存储。如果推送失败则重试直到成功。这样即使进程在推送中途崩溃恢复后仍然能从发件箱里找到未完成任务。6.2 消息JSON解析报错超大对象导致序列化问题热词里出现过expected , or ] after array element in JSON这种报错我在生产环境也见过。排查到最后基本原因都是同一个消息JSON里内联了过大的数组字段比如直接把整个附件Base64编码放进消息体或者把工具返回的超长JSON文本原样内嵌。序列化端看起来没问题但解析端一遇到超长字符串就报错。根治办法是设计时就定规矩消息体只保存元数据和引用任何超过几KB的内容一律存为独立对象用storage_path字段指向S3。这条经验要前置到团队规范里不能指望事后补救。6.3 预签名URL过期用户访问附件报403这个问题的特征很明确用户上传附件时没问题几个小时后打开附件链接就开始报403 Forbidden。原因就是预签名URL是有时效的很多Agent服务在生成URL时习惯用默认有效期导致长时间会话中的附件访问失败。排查方法是看响应头的x-amz-expiration字段确认过期时间。解决方法是按业务场景区分有效期会话内附件用30分钟短链接即可需要持久访问的文件生成独立的长效链接并且要记录URL生成时间在过期前主动刷新或重新生成。6.4 会话恢复慢前台长时间等待会话恢复接口慢大部分情况不是S3慢而是应用做了同步List操作或者对每个消息文件串行GET。解决思路很简单一是彻底移除List直接用元数据库定位对象二是把串行GET改成并发GET比如用Python的asyncio或者线程池同时拉取多个消息文件三是加Redis缓存。我实测过串行恢复一个50条消息的会话耗时约5秒改成并发后降到1秒以内加了缓存后直接到几十毫秒。6.5 常见问题速查表问题现象可能原因优先排查动作会话恢复少消息元数据与对象不一致查发件箱任务是否积压补跑同步任务1073741824权限错误预签名URL过期或Policy过长检查URL签发时间与有效期消息列表加载慢每次List S3前缀改为元数据库分页查询JSON解析报错消息体内联超大字段检查是否有附件Base64内嵌向量检索结果不准记忆摘要与原文偏离检查embedding模型与摘要策略存储容量突增冷热分层策略未生效检查生命周期规则是否覆盖新前缀写在最后的一点个人体会从S3裸奔到Agent Bucket这套抽象层最大的改变不是技术架构而是思维方式的转变。以前我写Agent应用脑子里只有“把这段数据存到哪里、怎么取出来”现在我会先想“Agent需要怎样的记忆模型”。这个转变花了我不少时间也交了不少学费。如果你正在做一个有状态的Agent应用我建议不要先在基建上堆料先把这篇文章里的最小闭环跑通——建表、写对象、建向量、配缓存四个步骤做完你已经超过大多数停留在概念阶段的团队了。后面再加权限、再扩展多租户、再上分布式都是一条线往前走的事。存储没有银弹但Agent Bucket这个思路确实能让复杂问题变得清晰很多。
Agent Bucket：为AI Agent应用打造的统一存储抽象层
先讲一个我自己的翻车现场。去年做一个AI陪练Agent功能不复杂用户登录后和Agent对话Agent需要记住上次聊到哪、用户的偏好、上传过的文档。第一版我用了最朴素的方案——会话状态放Redis用户文件丢S3向量检索走Milvus。看起来每个组件都在该在的位置结果一上线就出事。用户会话一多恢复一次对话要拼五六次查询S3里的文件路径靠手写拼接时间一长根本分不清哪个文件属于哪次会话。最要命的是一旦文件被误删整个会话的上下文就断了。你说这是个存储问题吗是也不是。它本质上是AI Agent应用的数据访问模式跟传统存储模型根本不匹配。这篇文章想聊的就是我在这个过程中解决的问题为什么AI Agent应用需要一套新的存储抽象以及从S3到Agent Bucket这条路到底怎么走。我会把完整的思路、选型依据、代码实现和踩坑记录都摊开讲目标是让看完的人能在30分钟内搭出一套支撑百万级用户规模的Agent存储底座。适合正在做AI Agent应用、或者准备把现有应用改造成Agent形态的开发者参考。1. 为什么AI Agent应用会倒逼存储架构变革1.1 传统存储模型和Agent应用之间的根本矛盾传统应用的数据访问模式是“以记录为中心”用户表、订单表、日志表CRUD搞定一切。存储层只需要保证单条记录的读写可靠、查询走索引、事务满足ACID就行。但AI Agent应用不是这个玩法。Agent应用的数据访问模式是“以会话与记忆为中心”每一次交互都围绕一段对话、一个任务、一份上下文快照展开数据之间有强烈的时序、归因和派生关系。举个例子用户问Agent“帮我分析一下上个月的账单”Agent需要拉取历史账单文件、读取用户此前的消费偏好、调用工具做计算最后把结果写回会话。这里涉及对象文件、向量索引、结构化元数据、工具调用记录四种不同形态的数据但是它们必须作为一个整体被保存和恢复。传统存储架构下这些数据散落在不同系统里业务层要自己维护它们之间的关联复杂度全部堆积在应用代码里。这就是Agent Bucket要解决的第一个问题把散落的存储资源抽象成“Agent视角的统一存储空间”让Agent的记忆、会话、附件、工具状态都具备统一的读写、检索和生命周期管理能力。1.2 Agent工作负载的四个新特征从实际运营角度看Agent应用给存储层带来的压力远不止“多存点数据”这么简单我整理了四个显著特征高度状态化。每次对话都会有会话状态、上下文快照、临时中间结果。用户中断对话再回来说“继续刚才的”系统必须能把完整的记忆状态重建出来。这意味着存储层不能只保存最终结果还要保存过程状态。多模态内容。文本、图片、音频、PDF、结构化JSON可以同时出现在一条消息里。你既要把原始文件存下来又要能按内容和语义去检索它们。语义检索需求。“帮我找上次聊过的那份产品需求文档”这类请求本质上是模糊语义查询靠文件名前缀匹配完全不够必须配合向量索引。生命周期管理。Agent的记忆不是越多越好有短期记忆、长期记忆、过期遗忘的区分。存储层需要支持精细化的自动归档与清理策略。这四个特征叠加后传统对象存储的“存文件”模式就显得太单薄了。S3可以放心地把文件存进去但它不关心这个文件属于哪段对话、承载了什么记忆、在什么条件下应该被遗忘——这些语义必须由上层补全。1.3 为什么S3单独扛不住Agent场景S3作为对象存储的标准本身没有任何问题强一致性、高持久性、全球规模这些能力都是经过实战检验的。但在Agent场景里单独用S3会撞上几个很现实的墙扁平命名空间的表达力有限。S3只有“桶前缀对象”这一层组织方式而Agent数据天然有“用户-会话-消息-记忆-附件”的多层归属关系。虽然可以用users/{user_id}/sessions/{session_id}/这种方式硬编码出层级但查询任何一层关系都要走 List 接口对象一多性能就崩而且这种解析逻辑散落在业务代码里维护成本极高。缺少语义层。S3不知道什么是“用户A的长期记忆”、什么是“某次工具的调用快照”。要做记忆召回必须业务层自己维护一份单独的元数据索引还要保证它和S3里的对象永远一致。小对象场景成本感人。Agent消息大多是几KB的JSON或者Markdown片段一次上传要付出一次请求成本标准存储按容量计费的同时还要为百万级的小对象交额外费用。我做过一个粗略估算100万用户每人每天20条交互就是每天2000万个对象写入光PUT请求费用一天就能消耗掉可观的预算这个在后面的成本章节我会展开算。所以S3依然是很好的底层存储引擎但它需要被包一层“语义壳”。Agent Bucket就是这层壳。2. Agent Bucket的设计逻辑与核心能力拆解2.1 Agent Bucket到底是个什么东西先明确一点Agent Bucket不是一个闭源商业产品也不是某个大厂新发布的服务名称。它是存储社区里正在形成的一类实践模式本质是一个“面向Agent应用的对象存储抽象层”。你可以把它理解为S3之上的一个语义中间层物理文件仍然存放在S3及兼容对象存储里但应用读写的不再是“文件”而是“记忆”“会话”“消息”这些Agent业务概念。这个抽象层的价值类比一下就很清楚没有它的时候Agent应用像一间杂货铺所有东西直接堆在地上找东西全靠人肉记忆有了它之后铺子装上了货架、贴上了标签、做了入库登记任何时候都能快速定位和取用。对于存储而言“货架”就是划分清晰的命名空间“标签”就是语义索引“入库登记”就是元数据管理。我在项目中实践的Agent Bucket方案由四层构成层次职责典型实现语义API层提供记忆读写、会话恢复、语义检索接口自研SDK如 put_memory / search_memory / restore_session元数据索引层记录对象归属、会话关联、时间线、重要度PostgreSQL或MySQL向量检索层支持语义级召回pgvector、Milvus、Qdrant对象存储层保存实际文件内容S3、MinIO、OSS、R2你完全可以在不改变底层对象存储的前提下把这套抽象层搭建起来这也是我认为Agent Bucket最具落地价值的一点。2.2 数据模型的重新抽象设计Agent Bucket的第一件事是把数据模型从“文件模型”切换成“记忆模型”。我在实际项目中定义了这样几类核心实体Agent。一个具体的AI Agent实例有自己的配置、知识库和默认记忆范围。Session。一次完整的对话会话包含一组按时间排序的消息记录。Message。单条交互消息可以是用户输入、Agent输出或工具调用结果可携带附件。Memory。跨会话的持久记忆可以是用户偏好、历史事实、任务结论是语义召回的基本单元。Attachment。消息中携带的原始文件独立存储消息体里只保存引用关系。这个模型对应到S3的Key设计一般是s3://agent-bucket/users/{user_id}/agents/{agent_id}/ ├── sessions/{session_id}/messages/{message_id}.json ├── sessions/{session_id}/attachments/{attachment_id}.bin └── memories/{memory_id}.json和直接在S3上堆文件的思路比起来区别在于这种路径不再是给人类看的“文件名”而是给Agent语义层用的“地址簿”。所有检索和恢复动作都优先查元数据库拿到地址再精准访问对象不需要遍历整个桶。2.3 三大核心能力语义索引、时间线感知、自动遗忘一个合格的Agent Bucket至少要具备三个核心能力。第一是语义索引。所有写入的记忆消息在存储原文件之外都要转换为向量存入向量库支撑“语义相似度召回”。比如用户说“找一下我上次让你看的那个方案”系统能根据向量相似度匹配到正确的记忆对象。第二是时间线感知。会话和记忆都要带准确的时间维度支持按时间范围回溯。我通常会在所有元数据表里保留created_at、updated_at和session_start_at三个时间字段这能解决很多模糊查询问题。第三是自动遗忘。长期运行之后记忆会越来越多如果不加控制检索质量和存储成本都会恶化。Agent Bucket需要支持按重要度、活跃时间维护“记忆热度”把寒冷记忆自动迁移到低成本存储层或直接清理。S3原生Lifecycle策略可以按月龄转换存储级别但这里要强调的是遗忘的决策逻辑应该在语义层完成存储层只负责执行归档和删除。3. 落地选型与整体架构方案3.1 底层对象存储怎么选Agent Bucket对底层对象存储的核心要求是S3 API兼容、可靠性高、成本可预期。我把市面上的常见选项对比过一轮这里直接给结论方案优势需要注意的点AWS S3功能最全、生态最好、生命周期策略成熟国内访问延迟偏高费用要精细控制阿里云OSS国内访问快与云生态集成好部分高级能力与S3 API存在差异Cloudflare R2免流量费、全球边缘节点、价格便宜冷门功能支持相较于S3少MinIO完全自托管、S3兼容度高、适合私有化需要自己运维集群、高可用要下功夫我的建议如果目标用户在国内优先选OSS或者兼容S3协议的云服务商如果在做全球化产品S3或R2更顺手如果是企业内部私有化部署MinIO是最稳的选择。选型的基本原则是尽量选S3 API兼容性高的因为Agent Bucket语义层希望屏蔽底层差异API越兼容适配成本越低。3.2 语义索引层的核心设计语义索引层是Agent Bucket的大脑我通常用PostgreSQL承载结构化元数据用pgvector或者独立的Milvus承载向量索引。这两者不是二选一的关系而是分工协作结构化元数据负责回答“这个对象属于谁、什么时间、什么类型”——例如“用户A在7月15日上午10点的会话里上传过一个PDF”向量索引负责回答“哪些记忆在语义上和用户当前的问题最相关”——例如“用户现在问的是账单分析历史记忆里讨论过消费习惯的条目优先被召回”。元数据表结构不用设计得太复杂我参考的简化版本是CREATE TABLE agent_memories ( id UUID PRIMARY KEY, user_id VARCHAR(64) NOT NULL, agent_id VARCHAR(64) NOT NULL, session_id UUID NOT NULL, memory_type VARCHAR(32), -- message / memory / tool_result content_ref VARCHAR(512), -- S3对象地址 content_summary TEXT, -- 简洁摘要用于列表展示 importance_score FLOAT DEFAULT 0.5, created_at TIMESTAMPTZ DEFAULT now(), last_accessed_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_memories_user_time ON agent_memories (user_id, created_at DESC); CREATE INDEX idx_memories_agent_type ON agent_memories (agent_id, memory_type);这套表结构非常简单但已经能支撑绝大多数场景的查询需求。向量字段不直接放进主表我建议用独立的向量表或者在pgvector的列式存储里单独建向量列避免拖慢主表的写入性能。3.3 整体架构长什么样把各层拼起来后整个系统架构是这样的客户端请求先打到Agent服务Agent服务通过Agent Bucket SDK进行数据读写。SDK内部完成三件事更新PostgreSQL元数据、写入或读取S3对象、同步向量索引。在Agent服务前面还有一层Redis缓存用来缓存最近活跃会话的完整消息列表避免每次都回源S3。写入路径上的关键是“双写一致”。对象写入S3、元数据写入PostgreSQL、向量写入向量库这三个动作天然不是原子操作所以要么用事务性发件箱模式要么用基于版本号的补偿机制。我选择的方式是以PostgreSQL业务表为主记录S3对象和向量都通过异步任务最终一致查询时如果发现向量缺失会触发自动重建。读取路径上的关键是“缓存优先”。resume一个会话时先查Redis命中就直接返回没命中再走元数据定位S3对象同时把结果回填到Redis。这个缓存策略能把会话恢复的P99延迟从几百毫秒降到几十毫秒。4. 30分钟实操构建一个可用的Agent Bucket4.1 第一步定义数据模型和命名空间规范动手编码之前先把命名空间和数据模型定下来。这套规范后续很难改改一次就意味着存量对象要迁移务必一次到位。我实际使用的S3 Key规范是{bucket}/{env}/users/{user_id}/agents/{agent_id}/sessions/{session_id}/messages/{message_id}.json {env}/users/{user_id}/agents/{agent_id}/sessions/{session_id}/attachments/{attachment_id}.bin {env}/users/{user_id}/agents/{agent_id}/memories/{memory_id}.json注意桶的第一层放的是{env}也就是环境名prod/staging/dev。这一点很多人会忽略。如果不分环境测试数据会污染生产数据清理起来极其痛苦。我吃过这个亏后来重构时花了整整两天做数据迁移。消息JSON的内部结构我是这样定义的{ message_id: msg_001, role: user, content: 请分析我的月度账单, content_type: text, created_at: 2025-06-01T10:00:00Z, attachments: [ { attachment_id: att_001, storage_path: prod/users/u001/agents/a001/sessions/s001/attachments/att_001.bin, mime_type: application/pdf, size_bytes: 245760 } ] }消息体只保存附件的引用路径不内联附件内容这是避免消息JSON膨胀的关键——热词里那条expected , or ] after array element的报错我怀疑就是消息体里嵌入了超大JSON导致的序列化问题后面排查章节细说。4.2 第二步搭建语义索引查询层模型定义好后下一步是把核心读写逻辑实现出来。我建议不要一开始就追求完整SDK先实现四个最核心的方法写入会话消息、恢复完整会话、追加记忆、语义检索记忆。足够覆盖最常见的Agent应用场景。这是一个用Python实现的最小可运行版本import json import uuid import boto3 from datetime import datetime, timezone class AgentBucket: def __init__(self, bucket, prefixprod): self.bucket bucket self.prefix prefix self.s3 boto3.client(s3) # 伪代码实际项目中在这里注入 PostgreSQL 连接与向量库客户端 self.db None self.vector_store None def _object_key(self, user_id, agent_id, session_id, message_id): return (f{self.prefix}/users/{user_id}/agents/{agent_id}/ fsessions/{session_id}/messages/{message_id}.json) def put_message(self, user_id, agent_id, session_id, role, content, attachmentsNone): message_id fmsg_{uuid.uuid4().hex} message { message_id: message_id, role: role, content: content, created_at: datetime.now(timezone.utc).isoformat(), attachments: attachments or [] } key self._object_key(user_id, agent_id, session_id, message_id) self.s3.put_object( Bucketself.bucket, Keykey, Bodyjson.dumps(message, ensure_asciiFalse), ContentTypeapplication/json ) # 写元数据伪代码insert into agent_memories(...) # 写向量伪代码embed content and upsert to vector db return message_id def restore_session(self, user_id, agent_id, session_id): # 伪代码先从 Redis 查命中则直接返回 # 再从 PostgreSQL 查出该会话所有 message 的引用 message_refs self.db.query( SELECT message_id FROM agent_memories WHERE user_id%s AND session_id%s ORDER BY created_at, (user_id, session_id) ) messages [] for ref in message_refs: key self._object_key(user_id, agent_id, session_id, ref[message_id]) obj self.s3.get_object(Bucketself.bucket, Keykey) messages.append(json.loads(obj[Body].read())) return messages def search_memories(self, user_id, agent_id, query, top_k5): # 伪代码query - embedding - vector search - 返回 memory_id 列表 # 然后按 memory_id 从元数据表补全内容 hit_ids self.vector_store.search( user_id, agent_id, query, top_k ) return [self.db.fetch_memory(mid) for mid in hit_ids]这套代码很朴素但已经具备了Agent Bucket的骨架。put_message负责写入restore_session负责时间线恢复search_memories负责语义召回。实际的线上版本无非是加上连接池、重试、幂等和监控核心逻辑就是这几条。4.3 第三步接入向量检索与缓存在代码骨架基础上最重要的一步是把语义检索真正做通。我用的方案是embedding模型负责把文本转成向量Milvus负责存向量和做相似度检索。这里有一个技术选型上的心得如果项目规模不大完全不用引入独立向量数据库直接用PostgreSQL的pgvector插件就可以。只有当数据量超过千万级、查询并发很高时再把向量独立到Milvus或Qdrant。embedding模型的选择上中文场景建议用BGE系列或通义系列的embedding模型英文场景可以考虑OpenAI的embedding接口。模型输出维度不用太纠结常见的是1024维或者1536维。对于Agent记忆这种大部分是短文本的场景我还建议在向量索引建立时额外存一个summary字段用一句话概括记忆内容这样列表展示页不需要全文解析JSON性能好很多。缓存层的接入也很关键。我使用Redis缓存最近活跃会话缓存内容的格式是session:{session_id}:messagesvalue是消息列表的JSON序列化结果key设置24小时过期。这样用户从昨天中断的地方继续对话时绝大多数情况是直接从Redis恢复压根不会打到S3上。4.4 第四步配置存储生命周期策略最后一步是配置冷热分层与清理策略。S3和OSS都支持生命周期规则针对不同前缀设置转换和过期策略。我这里用的是典型的三层策略{ Rules: [ { Id: hot-to-warm, Status: Enabled, Filter: {Prefix: prod/users/}, Transitions: [ {Days: 30, StorageClass: STANDARD_IA} ] }, { Id: inactive-memory-cleanup, Status: Enabled, Filter: {Prefix: prod/users/}, Expiration: { Days: 180, ExpiredObjectDeleteMarker: true } } ] }但这里必须强调一个容易踩的坑生命周期规则是按对象的物理访问时间或创建时间判断的不是按Agent记忆的“重要度”判断的。所以规则只能处理那些确定可以删除的冷数据比如超过180天没更新的会话附件。对于记忆重要度这种需要业务判断的清理逻辑必须由Agent Bucket的元数据库驱动算出哪些memory_id该删除再调用存储API精确删除对象。两条线路并行缺一不可。5. 百万级用户场景下的性能与成本优化5.1 性能瓶颈到底在哪百万级用户听起来很吓人但拆开算一算真正的压力点就清楚了。假设100万日活用户每人每天发20条消息每天新增2000万条消息。每条消息的JSON平均1KB附带一个临时向量每天新增原始数据约20GB。存储容量的压力不大一年才7.2TB真正吃力的是两个地方一是对象数量。一年下来就是70多亿个对象。S3的List接口在这种规模下基本不可用任何需要遍历桶的代码都会超时——所以我在前面强调绝对不要用List前缀的方式找消息所有定位都必须走元数据库。二是请求QPS。2000万条写入分摊到业务峰值每秒可能有上千次PUT请求。S3的吞吐能力没有问题但每次PUT都走公网会有延迟抖动所以写入链路上一定要加异步批处理把多条消息打包后合并上传。我在实际项目中验证过的性能参数单次put_message全链路耗时约30-50ms其中S3 upload占大头restore_session从Redis命中时P99约40ms回源S3时P99约200mssearch_memories的P99约100ms。这些指标对Agent对话场景足够用。5.2 缓存策略与读写路径优化Agent存储的读写比例非常不均衡。“写入一次、读取多次”是常态所以缓存的价值特别大。我总结了几条行之有效的策略会话维度的最近N条消息强缓存到Redis。用户恢复会话时优先返回这N条让对话能立刻开始再异步加载更早的历史消息。记忆对象的向量检索结果做短TTL缓存。同一个用户短时间内用相近表述反复问同一个问题应该命中缓存而不是每次重新检索。附件文件通过预签名URL直传直下。上传和下载都让客户端直接和对象存储交互不经过Agent服务中转这是消解服务器带宽压力的关键。这里有个容易忽略的点S3预签名URL是有有效期的默认几十分钟到几小时。如果业务里需要用户长时间访问同一个小文件比如产品文档生成后要预览几天建议为长期分享场景单独生成带长时间有效期的URL或者干脆走CDN域名。5.3 成本控制请求费比容量费更值得关注很多人估算存储成本时只看容量费实际在Agent场景里这是典型的“算错账”。再看这个数据100万用户每日2000万条消息按对象存储每1000次PUT请求约0.005美元计算光写请求一天的账单就是100美元一个月3000美元而对应的容量费一个月可能不到100美元。请求费远超容量费。控制请求费用的手段主要有三个第一是合并写入。多条工具调用日志、多条流式片段在业务层攒够一定数量或者达到时间阈值后打包成一个JSON数组再写入S3。这样对象数量减少、请求次数大幅降低。代价是读取单条消息时要多一层解析但这个开销完全可以接受。第二是合理的生命周期转储。超过30天的冷会话数据迁移到低频访问存储存储单价降低的同时请求费也会降低。超过180天的会话附件可以直接过期删除。第三是控制向量库存量。向量数据是按条数和维度收费的Agent运行越久向量越多。我的做法是定期对记忆去重和压缩高度相似的记忆合并成一条不活跃用户的向量降维或者迁移到冷存储。这个清理任务用定时任务跑每个月一次就够。6. 常见问题与排查技巧实录6.1 元数据与对象不一致会话恢复时缺数据这是Agent Bucket最常见的故障我在开发阶段就重复踩过好多次。典型场景是对象成功写入S3但因为网络抖动等原因元数据写入PostgreSQL失败导致这个对象永远“隐身”了。解决方案是采用事务性发件箱模式把“会话消息元数据”和“待同步事件”放在同一个数据库事务里后台任务负责把待同步事件推送给向量库和对象存储。如果推送失败则重试直到成功。这样即使进程在推送中途崩溃恢复后仍然能从发件箱里找到未完成任务。6.2 消息JSON解析报错超大对象导致序列化问题热词里出现过expected , or ] after array element in JSON这种报错我在生产环境也见过。排查到最后基本原因都是同一个消息JSON里内联了过大的数组字段比如直接把整个附件Base64编码放进消息体或者把工具返回的超长JSON文本原样内嵌。序列化端看起来没问题但解析端一遇到超长字符串就报错。根治办法是设计时就定规矩消息体只保存元数据和引用任何超过几KB的内容一律存为独立对象用storage_path字段指向S3。这条经验要前置到团队规范里不能指望事后补救。6.3 预签名URL过期用户访问附件报403这个问题的特征很明确用户上传附件时没问题几个小时后打开附件链接就开始报403 Forbidden。原因就是预签名URL是有时效的很多Agent服务在生成URL时习惯用默认有效期导致长时间会话中的附件访问失败。排查方法是看响应头的x-amz-expiration字段确认过期时间。解决方法是按业务场景区分有效期会话内附件用30分钟短链接即可需要持久访问的文件生成独立的长效链接并且要记录URL生成时间在过期前主动刷新或重新生成。6.4 会话恢复慢前台长时间等待会话恢复接口慢大部分情况不是S3慢而是应用做了同步List操作或者对每个消息文件串行GET。解决思路很简单一是彻底移除List直接用元数据库定位对象二是把串行GET改成并发GET比如用Python的asyncio或者线程池同时拉取多个消息文件三是加Redis缓存。我实测过串行恢复一个50条消息的会话耗时约5秒改成并发后降到1秒以内加了缓存后直接到几十毫秒。6.5 常见问题速查表问题现象可能原因优先排查动作会话恢复少消息元数据与对象不一致查发件箱任务是否积压补跑同步任务1073741824权限错误预签名URL过期或Policy过长检查URL签发时间与有效期消息列表加载慢每次List S3前缀改为元数据库分页查询JSON解析报错消息体内联超大字段检查是否有附件Base64内嵌向量检索结果不准记忆摘要与原文偏离检查embedding模型与摘要策略存储容量突增冷热分层策略未生效检查生命周期规则是否覆盖新前缀写在最后的一点个人体会从S3裸奔到Agent Bucket这套抽象层最大的改变不是技术架构而是思维方式的转变。以前我写Agent应用脑子里只有“把这段数据存到哪里、怎么取出来”现在我会先想“Agent需要怎样的记忆模型”。这个转变花了我不少时间也交了不少学费。如果你正在做一个有状态的Agent应用我建议不要先在基建上堆料先把这篇文章里的最小闭环跑通——建表、写对象、建向量、配缓存四个步骤做完你已经超过大多数停留在概念阶段的团队了。后面再加权限、再扩展多租户、再上分布式都是一条线往前走的事。存储没有银弹但Agent Bucket这个思路确实能让复杂问题变得清晰很多。
