一份原檔先被拆成了三份：AI Agent 的檔案儲存，是一套被設計過的分工介面

回顧 2026 年 10 月 4 日，掘金作者「snow來了」發布了一篇題為「ai agent --- 文件存儲」的技術長文。文章從一個日常場景談起：我們在與 AI 對話時，總會丟給它一堆檔案，圖片、Word、Excel、PDF。對話結束後，要如何在歷史會話裡把這些檔案找回來，答案指向一個不起眼卻關鍵的設計決策：物件儲存。

三個資料庫，各管一件事

文章最有意思的部分，是它把一套看似複雜的架構拆成了一張清楚的分工地圖。原文強調：MinIO 裡存的是文件原件，向量資料庫 Milvus 存的是檔案切塊後的向量值，而檔案區塊與元資料則放在 MySQL 裡。

換句話說，同一份使用者上傳的 PDF，在系統裡其實同時以三種形態存在：原始位元組、結構化的描述欄位、以及被嵌入模型轉譯過的數學表示。取用時的動線也一樣清楚：使用者提問，問題先被轉成向量，到 Milvus 裡做餘弦相似度比對，找到相似區塊後，憑 id 回 MySQL 查元資料，再依儲存位置去 MinIO 取回原檔。

這種分工本身就是一種介面設計。每一種資料庫只被問它擅長回答的問題，向量庫負責「像不像」，關聯庫負貾「是什麼、在哪裡」，物件庫負責「原件本身」。這與我們先前觀察過的私有化 RAG 知識庫「辭溯」的可信介面設計有相似的邏輯：可信的問答體驗，往往建立在後端職責被乾淨切開的前提上。

為什麼 MySQL 裝不下你的 PDF

文章對物件資料庫的解釋相當直白。MySQL 是關聯式資料庫，一行一行存資料；你可以把圖片轉成 base64 塞進去，但大文件很快就會撐爆這條路。物件儲存的價值就在這裡：它天生為非結構化的檔案而生。

在選型上，作者給了三條路：業務跑在公有雲、想省運維力氣，選阿裏雲 OSS；小型本地自建知識庫、追求低成本快速落地，選 MinIO；海量音視頻或大型集團的國產化專案，選 RustFS。前兩者是雲端與本地的對照，第三個則帶出了替代方案的選項。這種按場景而非按規格的選法，其實比任何效能比較表都更誠實，因為多數專案的儲存選型，最終取決於營運條件而非常技術極限。

儲存架構是一種閱讀介面

文章後半段附上了阿裏雲 OSS 的實際操作流程與 Node.js 程式碼，從控制臺建 bucket、上傳檔案、拿到 URL，到安裝 ali-oss 套件、設定 region 與金鑰。這些步驟瑣碎，卻點出一件事：檔案儲存在 AI Agent 裡從來不是隱形的背景設施，它決定了歷史會話能不能被回溯、RAG 檢索能不能溯源到原件。

一份架構文件的價值，往往在於它讓讀者看見原本看不見的分流。這篇文章做到的，是把「丟給 AI 一個檔案」這個毫秒級的動作，攤開成一條跨越三種資料庫的完整動線。對設計者而言，這條動線上的每一個交接點，都是未來除錯與擴充時要面對的介面。檔案存得好不好，使用者永遠不會稱讚；但存得不好，第一次找不到歷史附件時就會被記住。