當數據庫的主要用戶不再是人類：我們在 AI Agent 場景下的架構實踐與思考

作者 | 黃東旭, TiDB 聯合創始人 & CTO ｜TiDB 工程師團隊

1 一個讓我們重新審視數據庫的數字

過去一年，我們在 TiDB Cloud 上觀察到一個趨勢性變化：每天新創建的數據庫集群中，超過 90% 不是由人類創建的，而是由 AI Agent 自動發起的。

這不是某個極端客戶的個例，而是正在成為常態。Agent 創建數據庫、生成 schema、寫 SQL、跑實驗、銷毀數據庫——全程不需要 DBA 介入，甚至不需要人類知道它發生過。

這個數字迫使我們重新審視一個根本問題：當數據庫的主要用戶從人類變成 AI Agent 時，過去二十年我們圍繞"人類使用數據庫"所構建的一切假設——容量規劃、schema 設計、運維流程、定價模型——還能成立嗎？

這篇文章不打算做產品介紹。我想分享的是過去一年里，我們在服務幾家 AI 公司時遇到的真實挑戰、做出的架構決策、以及踩過的坑。這些經驗或許對正在構建 AI Agent 應用的團隊有參考價值。

2 Agent 工作負載的四個特征：為什么傳統數據庫會被打穿

在深入案例之前，先把我們觀察到的 Agent 工作負載特征做一個歸納。這不是理論推演，而是從真實生產環境中反復出現的模式。

特征一：海量短命實例

傳統應用的數據庫是"一個產品一個庫"或"一個租戶一個 schema"。但在 Agent 場景下，粒度變成了"一個 Agent / 一個 session 一個邏輯數據庫"。我們見過一個客戶三個月創建了近百萬個數據庫租戶，其中約 99% 是一次性使用的。

如果按傳統云數據庫的定價模型——最小實例每月十幾到二十美元——百萬實例意味著天文數字的月賬單。問題不是數據庫貴，而是貴到商業模式算不過來。

特征二：數據庫成了 Agent 的工作臺，不是存儲倉庫

Agent 不是把數據"存進去就完了"。以一個典型的數據分析任務為例：Agent 先從網上抓取原始資料，結構化存入數據庫表，然后用 SQL 做清洗、統計、聚類、離散分析，最后生成報告。如果數據只停留在 Markdown 或純文本里，后續處理只能繼續依賴大模型"泛泛看一眼"，分析質量完全交給模型幻覺。落到數據庫里，SQL 是確定性的、代碼是可審計的，分析才真正可工程化。

更激進的是建站類場景：Agent 直接幫用戶搭建一個網站，網站要持續運營、持續收費。這意味著 Agent 創建的數據庫不是臨時的，而是一個真正的生產系統。而且——schema 也是 AI 寫的。一旦 schema 由 AI 動態生成，"一個 Agent 一個庫"就不僅是隔離問題，而是控制爆炸半徑：寫錯了只影響當前 Agent，不波及其他租戶。

特征三：上下文即數據，而且越來越長

在很多復雜 Agent 系統中，為了實現可恢復、可審計和跨 session 的檢索，關鍵上下文需要被持久化。持久化的載體可以是文件索引、日志存儲或數據庫——但當 Agent 需要對上下文做結構化查詢、跨任務關聯分析時，數據庫的優勢就會顯現出來。我們服務的幾家客戶最終都走向了這個方向。

而且上下文在變長。我們有客戶的單條 context 達到 30MB-50MB，內容包括文本和音頻。這已經遠遠超出傳統 OLTP 數據庫的舒適區。

特征四：流量不可預測，但成本必須可控

Agent 不像人類按工作時間使用數據庫。它們可能在凌晨三點突然發起一波密集查詢，也可能連續幾小時完全沉默。如果為這種"間歇性活躍"長期維持整套計算資源，客戶和服務方都會雙輸。

3 案例一：當數據庫成本決定產品能不能上線

第一個案例是某全球知名 AI Agent 平臺。

作為一個通用型 AI Agent 平臺，發布 waitlist 后迅速積累了兩百萬以上的等待用戶。但從發布 waitlist 到真正開放，中間隔了將近兩個月。這段時間不是產品沒準備好——Agent 控制層已經是無狀態的，可以隨時拉起和銷毀。真正卡住他們的，是數據庫。

問題的本質：不是做不出 Demo，而是 Demo 無法規模化

它的產品形態里，一個 session 就是一個 Agent。同一 session 內任務連續、上下文連貫；跨 session 通常意味著業務目標不同，需要一個新的獨立環境。所以他們的需求不是"一個產品一個庫"，而是"一百萬個 Agent 需要一百萬個邏輯數據庫"。

他們最早評估的方案，最小實例月成本大約十幾到二十美元。單看不貴，但乘以百萬，商業模式直接崩盤。

這就是這個案例最有力量的地方：數據庫方案不是性能優化項，而是決定業務能不能上線的前提條件。

我們是怎么解的

解法可以概括成三層。

第一層：一個物理集群承載海量邏輯租戶。不是每個 Agent 一套獨占實例，而是共享基礎設施 + 邏輯隔離。多租能力本身，就是成本被打下來的基礎。

但多租的前提是元數據能扛住。這里有一個背景：我們之前有一個做插件生態的客戶，插件數 × 租戶數的乘積把數據庫元數據規模推到了千萬級別。這逼著團隊做了大量 meta 層優化，最終在測試中跑到了兩千萬張表以上的量級。正因為這個能力已經就緒，第一個案例那種百萬級 Agent 的場景才是可承接的。

第二層：存算分離，做到更極致的彈性，把成本進一步壓下去。底層以對象存儲作為全量數據的持久化層，上層疊緩存處理熱數據；計算層彈性調度，在 Agent 場景下可以接近 scale-to-zero。Agent 不是 24 小時持續高活，很多用戶一天只活躍幾次。如果為間歇性活躍長期維持整套計算資源，成本是沒有意義的。

第三層：接受合理的 trade-off。彈性不是零代價的。計算節點喚起時會有冷啟動延遲，大約百毫秒。但在 Agent 場景里，這通常是可接受的——大模型推理本身就是秒級的，LLM 生成的查詢也不是高度優化的毫秒級 SQL。省下的是數量級的成本，付出的只是用戶幾乎無感的一點啟動延遲。

還有一個容易被忽視的點：資源隔離。海量租戶共用基礎設施時，最怕的不是平均負載高，而是某一個 Agent 把資源打爆、拖垮整池。所以除了多租和彈性，還必須把 resource control 做到位，讓每個 Agent 的資源消耗有清晰的邊界。

一個關鍵教訓：測試你的真實工作負載，不要測基準

客戶從 MySQL 遷移到 TiDB，因為 MySQL 協議兼容，幾乎沒有代碼改動，整個過程在兩周內完成。但切換上線時，仍然花了大約三小時做查詢計劃調優。原因是：標準 TPCC 基準測試并不能反映 客戶 Agent 實際生成的查詢模式——那些查詢是復雜的上下文重建，需要不同于常規事務的索引策略。

這是一個值得所有 AI 應用團隊記住的經驗：AI Agent 生成的 SQL 和人類寫的 SQL 不一樣，標準基準跑得再好，也不代表生產沒問題。

4 案例二：30MB 的上下文到底該存在哪里

第二個案例是 Plaud，一家 AI 硬件公司，產品是 AI 筆記硬件，全球超過 150 萬用戶。

如果說案例一講的是"Agent 數量與成本模型"，Plaud 講的則是"長上下文和多媒體數據的存儲架構"。

問題的本質：不是沒地方存，而是存儲架構太繞

Plaud 的 context 很長，最長大約 30MB 到 50MB，主要是文本和音頻。按照傳統做法，這類大對象不會直接進數據庫，而是進對象存儲（S3），數據庫只存元數據。

但一旦原始數據和元數據分開，工程問題就排著隊來了：

一致性問題。數據在 S3，索引在數據庫，任何修改、覆蓋、刪除都要自己保證兩邊一致。實際上，很多線上故障就死在這個環節。

性能問題。S3 吞吐高但延遲也高，于是業務不得不再加一層緩存。但緩存并不能消滅問題，因為很多查詢仍然會穿透。再加上 bucket 文件越多，枚舉和查詢越慢，長尾延遲會變得非常難看。

最終你得到的是一套"對象存儲 + 元數據庫 + 緩存層 + 一致性補償"的復雜鏈路。能跑，但脆弱。

范式變化：把長上下文收回數據庫

我們給 Plaud 的方案不是"繼續優化這條鏈路"，而是改變范式：很多長 context 可以直接存在數據庫字段里。

在真實生產中，TiDB 的單字段可以支撐到 100MB 量級。這意味著用戶的整段交互上下文——包括音頻轉寫文本——都可以直接落在數據庫中。事務性、一致性、SQL 查詢能力全部保留，那套復雜的 S3 + Meta 拼接鏈路就可以大幅簡化。

這里需要強調一點：重要的不只是"能存長"，而是"在能存長的同時，仍保留 SQL 和事務能力"。如果只是換成某種偏 AP 的系統，當然也能塞大對象，但事務性和查詢語義就得自己補——這不是白得來的。

一個被低估的傳統能力：在線 DDL

Plaud 還驗證了一個傳統數據庫能力在 AI 時代的價值：在線 schema 變更。

AI 原生應用的數據結構比傳統業務更不穩定，schema 變更頻率高得多。如果每次改表都要等鎖表、等停機窗口，發布節奏就會被迫堆積，研發為了趕窗口把多個變更一起上，質量反而更差。不鎖表的 DDL 讓業務發布和 schema 發布可以同步推進，這在 AI 產品的快速迭代中格外重要。

5 案例三：分庫分表做到第二十個分片之后

第三個案例是某國內頭部大模型公司。

他們的產品形態更接近傳統的高頻對話場景，和前兩個案例相比并不算"極端"。但量一大，傳統方案也會碰壁。

問題：維護復雜度先于性能崩潰

他們基于 PostgreSQL 做了大量分庫分表，最終做到了十幾到接近二十個分片。按理說分片加下去性能還能撐，但團隊先扛不住了——跨分片查詢越來越復雜，schema 變更要逐片執行，監控和告警要乘以分片數，新人入職的學習成本越來越高。

這是一個很重要的判斷：AI 流量不一定首先死在模型成本上，也可能先死在數據層的架構復雜度上。

順帶驗證的一件事

他們的單條 context 沒有 Plaud 那么長，大約幾 MB 級別，但原來也是放在對象存儲上的。遷移到 TiDB 后，把其中一部分 context 收回了數據庫，目的很簡單：簡化架構。

這和 Plaud 的故事互相印證了：即便不是極端長上下文，只要 context 大到讓"對象存儲 + 元數據 + 分片數據庫"的組合開始變笨重，把更多內容收回數據庫也是合理的演進方向。

6 從數據庫到記憶層：Agent 基礎設施的下一個需求

在服務這幾家客戶的過程中，我們還觀察到一個更深層的需求正在浮現。

前面三個案例講的，主要還是 Agent 對數據庫層的需求：結構化存儲、上下文持久化和多租戶隔離。但當 Agent 開始跨 session、跨設備、跨任務連續工作時，問題就不再只是"把數據存下來"，而是"如何把過去的信息在合適的時候、以合適的形式重新帶回模型上下文"。傳統數據庫當然可以保存用戶偏好、歷史決策和項目資料；真正缺少的是一層面向 Agent 的記憶機制，去完成記憶的沉淀、索引、檢索、篩選和注入。否則，即使數據仍然在庫里，Agent 在新 session 中也很難低成本地恢復到上一次的工作狀態，看起來就像每次都要從零開始。

這個觀察促成了 mem9 的誕生。

mem9 是一個開源的 AI Agent 持久記憶基礎設施（Apache 2.0），底層用 TiDB 做持久化和向量搜索。它以一層 REST API 暴露給 Agent 框架，提供記憶的寫入、混合搜索（向量 + 關鍵詞）、跨 session 恢復等能力。Agent 框架只需對接這一層 API，不需要關心底層的存儲、索引和搜索實現。

從架構上看，這是 Agent 數據基礎設施的自然分層演進：

前兩層是數據系統的自然延伸，第三層是一個新的獨立需求。但它并不是脫離數據庫的——mem9 底層仍然依賴分布式數據庫的事務性、向量搜索和彈性擴展能力。這不是"數據庫不夠用了所以加一層"，而是"數據庫的能力通過一個專門為 Agent 設計的 API 層暴露出來"。

mem9 目前已經集成了 OpenClaw 生態，代碼在 GitHub 上開源：github.com/mem9-ai/mem9。

7 幾個實踐教訓

最后分享幾個跨案例的經驗總結。

1. 定價模型也需要為 Agent 重新設計。

如果每個 Agent 或 session 對應一個傳統云數據庫實例（哪怕是最小規格），會讓絕大多數商業模式難以維系。我們在案例一的場景中放棄了按實例定價，改為基于實際資源消耗的聚合計費模型。這不是可選的優化——對于 Agent 密度足夠高的場景，這是前提條件。

1. Agent 生成的 SQL 和人類寫的 SQL 是兩個物種。

不要用 TPCC 或 sysbench 的結果來預判 Agent 場景下的數據庫表現。Agent 的查詢模式是不規則的、多變的、且往往不是最優的。上線前必須用真實的 Agent 工作負載做壓測，否則一定會在切換當天遇到意料之外的慢查詢。

1. 簡化架構比優化架構更有價值。

在 AI 應用的快速迭代節奏下，維護一套"對象存儲 + 元數據庫 + 緩存層 + 分片 + 一致性補償"的復雜鏈路，運維成本和心智負擔會很快變成瓶頸。如果數據庫本身能承載長上下文和大對象，那么減少一層組件，比優化每一層的性能更有實際意義。

1. 記憶將成為 Agent 基礎設施的標配。

今天大多數 Agent 應用還在"無狀態"模式下運行——每次對話獨立，沒有跨 session 的連續性。但隨著 Agent 開始承擔更復雜、更長期的任務（比如持續運營一個網站、跟進一個客戶關系），跨 session 的持久記憶就會從"nice to have"變成剛需。這是我們啟動 mem9 的原因，也是我們認為 Agent 數據基礎設施下一個必須補上的能力。

8 寫在最后

過去一年的經歷讓我們形成了一個核心判斷：AI 時代的競爭優勢不在模型大小，而在數據基礎設施能否支撐 Agent 的工作方式。

當數據庫的主要用戶從人類變成 Agent，數據庫不再是一個被動的存儲系統，而是 Agent 的操作底座——它們在上面創建、查詢、分支、合并、銷毀，像使用一個可編程的基底。

這對數據庫行業是一次根本性的范式轉移。而我們的經驗是：不要試圖用舊架構"兼容"新需求，而是從 Agent 的工作方式出發，重新思考數據庫應該是什么樣的。

值得一提的是， TiDB Cloud 與即將上線的“平凱數據庫云服務”技術同源，平凱數據庫云服務面向中國市場，通過主流云廠商適配與本地化服務，讓中國客戶無需試錯，即可享受經全球頭部客戶考驗、百萬生產集群大規模長期驗證的云數據庫服務。二者體驗一致，無論企業是深耕國內市場還是開拓海外業務，都能以統一技術棧，高彈性伸縮來靈活應對海量數據處理與 AI 創新需求。平凱數據庫云服務將于 2026 年 4 月 1 日上線！

作者簡介

黃東旭，TiDB 聯合創始人兼 CTO，TiDB / TiKV 核心作者。在分布式系統和數據庫架構領域有超過 10 年經驗。近期關注 AI Agent 數據基礎設施方向，主導了開源項目 mem9（github.com/mem9-ai/mem9）和 db9（https://db9.ai）

參考資料

TiDB X 架構設計：The Making of TiDB X — Origins, Architecture, and What's to Come

mem9 開源倉庫：github.com/mem9-ai/mem9