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

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

而是一個(gè)真實(shí)可訪問的URL。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下一次用戶說“幫我加一個(gè)收藏功能”，Agent又要?jiǎng)右淮伪斫Y(jié)構(gòu)。

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

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

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

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

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

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

Kimi的選擇，以及為什么是這個(gè)選擇

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

Kimi工程團(tuán)隊(duì)做了三個(gè)關(guān)鍵決策，每一個(gè)都對應(yīng)解決上面三條約束中的一條。

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

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

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

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

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

下面是TiDB Cloud的多租戶：

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

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

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

而在TiDB里，這是一條SQL。

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

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

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

它應(yīng)該像運(yùn)行時(shí)資源一樣：需要時(shí)立刻可用，用完后成本足夠低。

TiDB Cloud通過Warm Pool預(yù)先維護(hù)一批已經(jīng)完成底層準(zhǔn)備的Starter實(shí)例。

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

這讓一用戶一實(shí)例不僅在隔離和成本上成立，也在體驗(yàn)上成立——

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

這不是Kimi一家的選擇

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

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

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

數(shù)字背后是一批AI Agent團(tuán)隊(duì)在各自做完基建選型后，不約而同地走向了同一類架構(gòu)。幾個(gè)關(guān)鍵數(shù)據(jù)點(diǎn)值得放在一起看：

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

當(dāng)時(shí)講的是“Agent用數(shù)據(jù)庫作為工作臺(tái)”。

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

△來自Dify官網(wǎng)

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

幾個(gè)團(tuán)隊(duì)各自做完工程評估，得到的答案差不多。

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

把視角再拉遠(yuǎn)一層，每一代AI基礎(chǔ)設(shè)施其實(shí)對應(yīng)著一種新的“計(jì)算單位”。

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

移動(dòng)時(shí)代是會(huì)話，一個(gè)App要扛幾億個(gè)并發(fā)會(huì)話。

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

△圖片由AI生成

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

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

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

新的默認(rèn)標(biāo)準(zhǔn)正在形成。過去一年，TiDB的產(chǎn)品演進(jìn)，正是在將這些共識逐一落實(shí)到具體產(chǎn)品中。

Kimi等團(tuán)隊(duì)的選型，正是這一趨勢的獨(dú)立驗(yàn)證。

當(dāng)然，TiDB團(tuán)隊(duì)的目標(biāo)，遠(yuǎn)不止數(shù)據(jù)庫這一層。

△圖片由AI生成

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

TiDB正在沿著這條線，為Agent這一代應(yīng)用補(bǔ)齊一整套通用的運(yùn)行時(shí)基礎(chǔ)設(shè)施：

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

后續(xù)還會(huì)有更多組件落地。Agent-native應(yīng)用的標(biāo)準(zhǔn)運(yùn)行時(shí)，正在一塊一塊成型。

AI應(yīng)用的上半場比模型，下半場比地基。

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

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