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

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

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

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

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

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

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

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

在傳統(tǒng)數(shù)據(jù)庫的產(chǎn)品形態(tài)下，這種工作負載量幾乎無法被承接。

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

為什么“傳統(tǒng)答案”都不成立

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

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

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

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

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

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

十萬用戶，就是十萬個數(shù)據(jù)庫。一百萬用戶，就是一百萬個。

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

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

第二條：數(shù)據(jù)庫的schema是LLM現(xiàn)場生成的

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

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

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

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

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

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

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

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

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

這三條合在一起，在傳統(tǒng)數(shù)據(jù)庫的產(chǎn)品形態(tài)下，幾乎是做不出來的：

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

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

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

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

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

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

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

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

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

下面是TiDB Cloud的多租戶：

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

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

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

而在TiDB里，這是一條SQL。

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

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

Agent生成應用時，數(shù)據(jù)庫的創(chuàng)建不能是一個需要等待幾分鐘的provisioning流程。

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

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

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

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

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

這不是Kimi一家的選擇

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

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

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

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

去年，某全球知名AI Agent平臺的AI Agent選擇TiDB作為其核心數(shù)據(jù)層，并在其技術博客和開發(fā)者社區(qū)公開了架構細節(jié)。

當時講的是“Agent用數(shù)據(jù)庫作為工作臺”。

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

△來自Dify官網(wǎng)

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

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

這種聚合本身就是一種行業(yè)信號，通常意味著底層工程約束已經(jīng)穩(wěn)定到一定程度。

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

Web時代是用戶，一個產(chǎn)品要扛幾億人同時來。

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

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

△圖片由AI生成

Agent在跑起來時需要的不僅僅是數(shù)據(jù)庫，還需要一個獨立的sandbox來執(zhí)行代碼、一份獨立的storage來存它的工作產(chǎn)物。

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

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

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

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

當然，TiDB團隊的目標，遠不止數(shù)據(jù)庫這一層。

△圖片由AI生成

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

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

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

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

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

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

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