人手一個數據庫，Kimi背后這套AI基建到底有多能扛？

“幫我搭個讀書筆記網站，帶登錄和搜索，能導出的那種。”

如果你最近在Kimi K2.6的Agent模式里敲下這句話，5分鐘后，你拿到的不再是一堆需要自己調試的Python代碼，也不是一個只能看的靜態Demo。

而是一個真實可訪問的URL。

前端、后端、獨立數據庫、用戶賬號體系……全套齊備。你可以直接把鏈接甩給朋友，他注冊后存入的數據，會穩穩地停留在你這套系統的獨立數據庫里。

比起v0或Lovable這些AI建站工具，Kimi實際上接管了用戶從開發到托管、再到數據庫運維的全生命周期。

但在這種體驗背后，真正的工程算力挑戰才剛剛開始：

如果有100萬個用戶隨口說了這句話，就意味著后臺要瞬間承載100萬個獨立的生產級數據庫——被真實用戶長期讀寫。

在傳統數據庫的產品形態下，這種工作負載量幾乎無法被承接。

那么Kimi究竟是如何在成本、規模與性能的“不可能三角”中，實現這種“人手一個數據庫”的奢侈配置？

為什么“傳統答案”都不成立

AI建站這一類場景，對模型廠商來說有一個基本的經濟結構：

算力消耗集中在Agent生成代碼的那幾下，服務上線后是按月收訂閱費。

一旦運行起來，托管的基礎設施成本（web服務器、帶寬、數據庫）相對算力成本要低得多，廠商的利潤空間主要靠這一部分。

但這套商業模式有一個前提：基礎設施成本必須能壓得下來。

把Kimi K2.6這個場景的工程約束拆解開，有三條特別刺眼的要求。

第一條：數據庫實例的粒度，是“每終端用戶一個”

十萬用戶，就是十萬個數據庫。一百萬用戶，就是一百萬個。

而且絕大多數實例會長期處于極低活躍，用戶建完一個站之后，可能很久不再打開。

按傳統云數據庫的定價模型，一個最小實例大約每月十幾到二十美元。乘以百萬，賬單天文數字。問題不是數據庫貴，是商業模型無法規模化。

第二條：數據庫的schema是LLM現場生成的

（注：schema指數據庫模式，是定義數據怎么存的邏輯結構。）

過去二十年，schema設計是一個需要DBA（數據庫管理員）、需要review、需要版本管理的慢決策流程。

在Kimi K2.6這里，schema是LLM對用戶一句自然語言的翻譯，例如“讀書筆記需要什么字段？”“評分存整數還是文本？”，瞬間就能決定。

更棘手的問題是，用戶會繼續對話。

下一次用戶說“幫我加一個收藏功能”，Agent又要動一次表結構。

這時候數據庫里已經有了真實用戶數據。Schema一旦改錯，輕則查詢失敗、用戶報錯，重則寫入紊亂、數據不可恢復。

第三條：負載分布是“零-峰兩極”

大多數站建完就閑置。但只要有一個站被小紅書推薦、被X平臺熱轉，瞬間并發可以跳到百倍以上。

所以，數據庫必須同時扛住“絕大多數近乎零、少數瞬間爆量”的極端曲線，而且要做到爆量租戶不能拖垮其他所有租戶。

這三條合在一起，在傳統數據庫的產品形態下，幾乎是做不出來的：

• 路徑A：單實例+schema隔離
• 幾百個租戶行，幾萬個直接打爆查詢規劃器。爆款站還會連累所有鄰居。Kimi工程團隊也實際測過這條路：用一個大型PostgreSQL實例做多Schema隔離，單實例在萬級規模時就開始扛不住，更不用說復雜的流控、故障半徑控制、數據隔離這些更深一層的問題。
• 路徑B：一個用戶一個RDS（托管關系型數據庫服務）實例
• 不管是RDS還是Neon/Supabase這種Serverless PG包裝，本質都是為每個用戶分配一個真實的PostgreSQL實例；到百萬級租戶，單是實例存在的基礎月費就已不可接受。

Kimi的選擇，以及為什么是這個選擇

Kimi后端最終落在了TiDB Cloud上。

Kimi工程團隊做了三個關鍵決策，每一個都對應解決上面三條約束中的一條。

決策一：極致低成本——用Serverless Cluster的多租戶能力，承接“每個用戶一個獨立數據庫”

既然問題出在“每用戶一個真實實例”，TiDB Cloud在這層走了另一條路：引入一層“虛擬數據庫界面”。

長尾的、絕大多數時間沒請求的租戶，平臺并不真實分配數據庫實例；只在Agent/終端用戶實際發起請求的瞬間，由一個常駐的DB Session Gateway維持數據庫連接，其他資源全部走彈性供給。

落到Kimi K2.6的場景里，這意味著“百萬用戶的建站后端”在單位經濟上跑得通。

為了更直觀地呈現這種技術代差，我們將這一架構與以Supabase為代表的典型Serverless數據庫，進行了對比：

下面是TiDB Cloud的多租戶：

決策二：統一技術棧——vector+SQL+JSON把Agent的“寫代碼”難度壓下來

Kimi K2.6建站Agent里，LLM寫出來的典型查詢經常在一條SQL里同時做多件事——按用戶過濾、按標簽篩選（JSON字段）、按向量相似度排序、按時間倒序。

在分離的棧里，同樣的需求要LLM協調三個client、自己做事務、自己做結果合并……這在LLM寫代碼的場景下，錯誤率會指數級疊加。

而在TiDB里，這是一條SQL。

統一棧在這里的價值不是“性能更好”，而是讓Agent有機會把代碼寫對的前提條件。

決策三：最小化摩擦——Warm Pool+scale-to-zero讓Agent在1秒內拿到完全準備好的數據庫實例

Agent生成應用時，數據庫的創建不能是一個需要等待幾分鐘的provisioning流程。

它應該像運行時資源一樣：需要時立刻可用，用完后成本足夠低。

TiDB Cloud通過Warm Pool預先維護一批已經完成底層準備的Starter實例。

Kimi需要新實例時，不再走完整創建鏈路，而是直接從預熱池中分配；再疊加Starter scale-to-zero的能力，閑置實例的計算成本可以壓到很低。

這讓一用戶一實例不僅在隔離和成本上成立，也在體驗上成立——

Agent可以在1秒內拿到fully prepared instance，繼續生成schema、寫入數據、啟動應用，而不需要把等待、輪詢、失敗重試寫進自己的代碼。

這不是Kimi一家的選擇

Kimi K2.6的這次選型，如果是孤立事件，只是一則產品新聞。

但放在更大的坐標系里看，它是一條正在形成的行業曲線上的一個點。

一個平臺側的數據可以先交代：今天在TiDB Cloud上新建的集群里，超過90%是由AI Agent直接創建的，而不是由人類工程師創建的。這個比例一年前還遠沒有這么高。

數字背后是一批AI Agent團隊在各自做完基建選型后，不約而同地走向了同一類架構。幾個關鍵數據點值得放在一起看：

去年，某全球知名AI Agent平臺的AI Agent選擇TiDB作為其核心數據層，并在其技術博客和開發者社區公開了架構細節。

當時講的是“Agent用數據庫作為工作臺”。

更早，Dify這家做LLMOps的低代碼平臺公司，過去為每個開發者租戶分配獨立數據庫容器，規模做到一定程度后扛不住運維，最終把所有租戶合并到一套TiDB Cloud上：基礎設施成本降80%、運維負擔降90%。

△來自Dify官網

今年，Kimi K2.6把TiDB用到了更復雜的場景——Agent直接向終端用戶交付數據庫驅動的完整應用。

幾個團隊各自做完工程評估，得到的答案差不多。

這種聚合本身就是一種行業信號，通常意味著底層工程約束已經穩定到一定程度。

把視角再拉遠一層，每一代AI基礎設施其實對應著一種新的“計算單位”。

Web時代是用戶，一個產品要扛幾億人同時來。

移動時代是會話，一個App要扛幾億個并發會話。

Agent時代是Agent自己，每個真實用戶身邊可能有10個、100個獨立運行的Agent實例，每個都要有自己的狀態、記憶、數據。

△圖片由AI生成

Agent在跑起來時需要的不僅僅是數據庫，還需要一個獨立的sandbox來執行代碼、一份獨立的storage來存它的工作產物。

One agent, one sandbox; one storage, one database，這套“每個Agent一份獨立運行環境”的架構，正在成為Agent原生應用唯一可行的假設。

Kimi、Dify、Plaud以及全球各地不斷涌現的Agent團隊，都不約而同地做出了相同的判斷。

新的默認標準正在形成。過去一年，TiDB的產品演進，正是在將這些共識逐一落實到具體產品中。

Kimi等團隊的選型，正是這一趨勢的獨立驗證。

當然，TiDB團隊的目標，遠不止數據庫這一層。

△圖片由AI生成

Agent作為新一代應用的核心計算單位，它需要的不只是一個數據庫，還需要持久化工作產物的storage、維持跨session上下文的memory層，未來還會有更多組件。

TiDB正在沿著這條線，為Agent這一代應用補齊一整套通用的運行時基礎設施：

• mem9：是這條線上已經落地的第一個組件。Agent每次重啟不應該從零開始，mem9為Agent提供持久、跨session可檢索的memory層。
• drive9：是第二個組件，Agent的sandbox可以隨時創建和銷毀，但工作成果不能跟著消失。drive9為Agent Sandbox提供持久、共享、可掛載的workspace。

后續還會有更多組件落地。Agent-native應用的標準運行時，正在一塊一塊成型。

AI應用的上半場比模型，下半場比地基。

當Agent進入“為終端用戶交付應用”的階段，模型能力本身已經不是決定勝負的唯一變量。

能不能選對一套數據底座，讓交付出去的東西在真實用戶面前穩定跑起來，正在變成模型廠商的核心運營能力。