Agent Infra 實踐復盤：Kimi 如何搭建 Agent 背后的 Database 服務

本篇內容轉載自「我世界的源代碼」。 作者黃東旭，是 PingCAP 的聯合創始人兼 CTO。

Agent 到底需要什么樣的 infrastructure，今年業界一直有很多探討，PingCAP 聯合創始人黃東旭此前也發過多篇討論文章，不過當時都是一些猜想。隨著 agent 今年的爆發，大規模落地的案例出現了。

TiDB Cloud 成為了 Kimi Agent 的服務商，黃東旭也將他們合作的一些細節進行了復盤和整理，對于今天諸多 Agent 創業者來說，絕對值得一讀。

轉載時 FP 對文章結構做了一些調整。

??關注 Founder Park，最及時最干貨的創業分享

超 19000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的 AI 產品曝光渠道

我前幾個月寫了幾篇關于 Agent 需要什么樣的 infrastructure 的文章：，，這幾篇文章受到了很多朋友的喜愛，但它主要還是停留在理論層面，主要是提出了一些猜想。后來這幾個月發生的事情大家也看見了，確實整個行業的發展正如同那兩篇文章所寫的一樣，包括 Agent 的爆發（以 OpenClaw 和 Hermes 為代表），以及相關的 Agent Infra 的火爆，包括 Sandbox 和文件系統的復興等等，不過所以如果說那幾篇文章缺了什么的話，我覺得缺一個大規模的落地的例子。

最近有一件事讓我挺開心的：首先，TiDB Cloud 正式成為了 Kimi K2.6 的供應商，為 Kimi Agent 建站服務提供動態的大規模的 Agent Database 支持。我因此有這樣一個機會，能夠跟 Kimi 團隊深入合作，將之前那些看上去天馬行空的想法真正落地了。下面我稍微說一說這個合作的一些細節（得到了 Kimi 團隊的授權，比心??）。

01Agent infra 面向的是大眾用戶，而不是開發者

先介紹一下 Kimi K2.6 的 Agent 場景。這個場景其實就是最典型的，由 Agent 幫助人類去完成端到端（End-to-End）在線應用的構建（生成代碼），并形成一個真實可用的在線服務。

這個服務和其他的 AI 建站應用（例如眾所周知的 Loveable）有所不同，Kimi K2.6 是從前端到后端都完全接管/托管，作為用戶不用關心任何技術細節也不用有任何技術背景，只需要用文字表達需求。

這正是我在這篇文章中描述過的那種完全由 Agent 負責一切的場景，對于這類 Agent 應用，挑戰其實并不在于代碼生成的部分，而是在于后面的 hosting 的成本。

為什么這么說？如果這個應用的受眾不是面向開發者，那用戶群會變大非常多，因為不需要任何技術背景，門檻一下就低了很多。但是對于服務的提供方，其實更樂于看見這樣的局面，原因在于：現在大多數 AI 模型服務的計費模式一般都是按月付費（訂閱制），你可以想象一下：如果是一個重度消耗 Token 的用戶，每一次請求都需要調用 LLM 來動態生成，這就會產生很大的算力消耗，對于模型廠商來說，從客戶那里收到的訂閱費，很大一部分都要轉手支付給算力成本。

但對于網站托管，或者是類似 Kimi K2.6 這種一次性生成代碼并持續在線提供服務的場景來說：

1. 算力的消耗其實主要集中在創建和生成代碼的那幾下。

2. 服務運行起來以后，廠商仍然可以按月收客戶的錢。

3. 托管應用所要支付的基礎設施（主要是 web 服務器，帶寬和數據庫）成本比起算力的成本，廠商利潤空間就大了很多。

所以在這種背景下，主要的挑戰在于用戶的數量以及支撐這種自助服務的 Infra 成本，比如在短短一周時間內，可能就有上千萬個站點被創建出來，如果按照傳統的云服務或者數據庫的定價，像這些獨立的、靈活的站點，不可能為每一個網站都提供一個真實的實例去 host 一個 Postgres 或者 RDS，這樣整體的成本肯定是算不下來的。但是如果你使用像類似 SQLite 這樣的嵌入式數據庫，雖然可以降低一些門檻，但也需要花很多的時間精力去處理備份、恢復、高可用等等，在成百上千萬規模的小型的由 agent 動態創建的網站應用的行為下，維護這些 SQLite 不是一件簡單的事情。

可能大家會說，為什么 Kimi 選擇 TiDB，并沒有選擇名氣更大的 NeonDB 和 Supabase 這類名氣可能更大的 Serverless 的 Database 方案，歸根結底，使用這套方案還是成本問題。例如像 Supabase 這種模式，唯一的問題在于，如果每一個 Agent 配一個 Supabase 的 PostgreSQL，想象下上百萬個實例的情況下，成本會直接爆炸。

另外一方面，Kimi 團隊也試過用一個大型的 PostgreSQL 實例，然后在內部通過多 Schema 的方式來進行租戶的隔離，根據實際的測試結果，單個實例大概在萬級規模時就扛不住了，更不用說復雜的流控，故障半徑控制和數據隔離問題。

其實我去年下半年就反復想這件事：Agent-native 時代的數據 Infra 競爭，跟過去 30 年都不太一樣，過去比的是單點性能：誰的 TPS 高、誰的延遲低，誰支持單數據庫更大的容量……

但現在不是，現在比的是當：

1. 海量長尾租戶，盡管請求量不大，但是全都要求在線

2. LLM 即席改 Schema，必須支持分支和多版本

3. 需要應對無法預測的爆發流量

4. 讓 AI 在秒級別隨時動態創建/銷毀，以及動態生成訪問的 SQL

這四件事同時發生的時候，誰能提供最順暢的體驗？這是個完全不一樣的賽道。

02要最小化 Agent 使用 infra 工具的摩擦

我們過去幾個月和 Kimi 工程團隊合作中學到了很多，總結一下，Kimi K2.6 Agent 建站的項目能做成，大概是三個最核心的戰略決策：

1：最小化 Agent 使用 Infra 工具時的摩擦

每個任務和站點獨立隔離，由 Agent 創建和使用，用的時候能秒級創建。這一條成立，后面才有得聊。TiDB Cloud 的 Warm Pool + Scale-To-zero，讓 Agent 在 1 秒內拿到 fully prepared 的數據庫實例。

Agent 生成應用，整個交付鏈路本身就是幾分鐘的事——用戶輸入需求、Agent 寫代碼、調用數據庫、寫數據、啟動應用。如果數據庫 provisioning 占去其中幾分鐘，Agent 就得在自己代碼里寫 retry / poll / wait 那一套。這個負擔其實不該由 Agent 來扛。

2：對 Agent 生成服務所使用的技術棧盡可能統一

人類工程師覺得方便，對 LLM 來說這直接關系到生成代碼的成功率，少跨一個系統就少一類 bug，多用 Skill 中寫好的技術棧（例如開發框架的建議和腳手架）和最佳實踐，而不是每次靠思考和抽卡，也大大提升了生成的代碼變成服務的穩定性。

3：極致的低成本

因為放棄了類似 Supabase 和 Neon 那樣的真實的數據庫實例的分配和管理，TiDB 其實引入了一層虛擬數據庫界面，因為這類 Agent 的建站場景大量的請求是長尾的，事實上沒有請求的事情，是不需要真實的分配數據庫實例的，只需要讓這個 Agent / 終端用戶有請求的時候，我「假裝」后端是一個獨立的數據庫即可，最極端的情況下，其實整個平臺只需要一個常駐的 DB Session Gateway 服務負責維持數據庫連接即可，其他所有的資源都可以變成彈性的。下面是這個架構和 Supabase 等傳統 Serverless 數據庫的架構對比：

這個是傳統的 Serverless 數據庫面對 Agent 場景的架構：每個 Sandbox 分配一個真實的數據庫實例，為了成本控制，冷卻的時候會被回收，很難保證 7x24 永遠在線，而且由于是真實的數據庫實例，數量大了成本也很難控制（想象一下，幾千萬個 Supabase？）

這是 TiDB Cloud 的架構，并沒有真實的數據庫實例存在，一切都是虛擬的，但是在 Sandbox 中的 Agent 看來它仍然是擁有一個個完整的獨立的數據庫，實際上在物理層面，數據是由底層的一個大型的封裝了對象存儲的分布式 KV 數據庫提供存儲服務，這個底層的大型數據庫在邏輯層面上自動處理了數據可見性的隔離和冷熱分離。這樣在 Agent 層面就不會有類似實例被回收，休眠或者連接中斷等不好的體驗。

這樣的架構轉變將整個數據庫平臺的彈性能力提升了一個臺階，換來的是在 Agent 場景的數據使用成本的數量級規模的下降。

最后的結果也很美妙，在寫本文的時候我隨手給我家做了個簡單的家庭留言板，大概不到 10 分鐘，從前端到后端，從開發到托管上線，一切順滑如絲。

Kimi 對 TiDB Cloud 的評價也很高：選 TiDB 的核心原因不在某一個單點指標的極致——而在于「per-tenant 多租隔離、統一棧、即時彈性」這三件事同時做到位時，它是少數幾個把每一項都"夠用且順手"的系統。

03行業層面：這不是孤例，It's happening

過去 12 個月，我們陪跑過國內外很多 AI Agent 團隊的基建選型。我們發現以前一個產品和服務扛億級用戶，一個 app 扛的是億級會話。現在模式變了：一個用戶身邊可能有 10 個 甚至 100 個 Agent 在跑，每個都需要自己的狀態和數據……但是包括 Kimi 在內的一些 AI Agent 作為商業模式的團隊采用的架構都收斂到同一個范式：one agent, one sandbox，one storage，one database。

Agent 商業化的場景才是剛剛開始，上半場大家在討論誰的模型更聰明、誰的 Agent 推理更長。下半場是我認為競爭的核心是： Agent 交付出來的東西和結果，在真實用戶面前能不能穩定跑起來，持續的交付。Kimi 和 TiDB 的合作就是一個絕佳的例子，模型廠商如何通過好的基礎設施服務，快速/高效的提供更多的價值。

當然 TiDB Cloud 只是數據庫的場景，也許下次就是 TiDB Filesystem 或者 TiDB Sandbox？當下的時代，真的是一切皆有可能，也請拭目以待吧。

轉載原創文章請添加微信：founderparker