一句话看懂：AI Agent 处理文件时，真正的难点不在“读文件”，而在会话结束后文件存哪、怎么查回来。这篇来自掘金的技术实践梳理了对象存储（MinIO、阿里云 OSS、RustFS）在 Agent 与 RAG 场景中的分工：原件进对象存储，元数据进 MySQL，向量进 Milvus。
事件核心：发生了什么
开发者“snow来了”在掘金发布了一篇面向 AI Agent 的文件存储实践文章。核心结论是：AI 会话中用户上传的图片、Word、Excel、PDF 等文件，不可能塞进 MySQL 这类关系型数据库（base64 只适合小图，大文档不现实），因此需要对象存储来承接原件。
文章给出的典型架构是三层分工：MinIO 存文档原件，MySQL 存文件名、大小、存储位置、上传时间等元数据以及切分后的文件块，Milvus 存文件块的向量值。RAG 检索时，先用嵌入模型把问题向量化，在 Milvus 做余弦相似度匹配，拿到 id 后回 MySQL 查元信息，再凭存储位置从 MinIO 取回原文件。文章还提到，也可以选择 PostgreSQL 把元数据、文件块和向量统一存放。
选型建议上，作者给出三条：公有云且不想运维选阿里云 OSS，小型本地知识库选 MinIO，海量音视频或大型集团国产化项目选 RustFS。
为什么重要
这是 AI 应用落地中容易被忽视但绕不开的工程环节。大模型本身不负责长期保存文件，多模态模型拿到的通常也只是 URL 而非文件字节。目前公开信息显示，MinIO、阿里云 OSS、RustFS 底层都遵循 S3 协议，因此可以用同一个 @aws-sdk/client-s3 包对接，也可以用 ali-oss、minio 各自的 SDK。这意味着存储层选型对上层 Agent 代码的耦合度较低，开发者不必被单一厂商绑定。
对用户/开发者/创作者的影响
对开发者而言，最实用的两点：一是别再把文件往关系型数据库里塞，把存储与检索拆开；二是如果已用 LangChain 之类的框架，多模态调用时传入 OSS 返回的图片 URL 即可，如文章示例中 qwen-vl-plus 通过 image_url 类型读取图片并输出描述。对使用云服务的小团队，阿里云 OSS 有低成本试用方案，适合快速验证；对自建知识库的团队，MinIO 部署门槛更低。值得注意的是，这套分层方案会引入额外的网络往返和一致性问题，文件删除、权限控制、URL 有效期都需要额外设计。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 S3 协议兼容是否真能覆盖各家全部能力，尤其是分片上传、生命周期管理和鉴权差异；二是 PostgreSQL 一体化方案（元数据 + 文件块 + 向量）在数据量增长后是否仍具性价比；三是 Agent 会话文件的合规与留存策略，涉及用户上传内容的存储期限和访问控制，目前公开信息显示文章未展开讨论。
来源：juejin
