本篇內(nèi)容轉(zhuǎn)載自「我世界的源代碼」。 作者黃東旭，是 PingCAP 的聯(lián)合創(chuàng)始人兼 CTO。

Agent 到底需要什么樣的 infrastructure，今年業(yè)界一直有很多探討，PingCAP 聯(lián)合創(chuàng)始人黃東旭此前也發(fā)過多篇討論文章，不過當(dāng)時都是一些猜想。隨著 agent 今年的爆發(fā)，大規(guī)模落地的案例出現(xiàn)了。

TiDB Cloud 成為了 Kimi Agent 的服務(wù)商，黃東旭也將他們合作的一些細(xì)節(jié)進(jìn)行了復(fù)盤和整理，對于今天諸多 Agent 創(chuàng)業(yè)者來說，絕對值得一讀。

轉(zhuǎn)載時 FP 對文章結(jié)構(gòu)做了一些調(diào)整。

??關(guān)注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

超 19000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進(jìn)群后，你有機(jī)會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

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

• 最精準(zhǔn)的 AI 產(chǎn)品曝光渠道

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

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

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

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

這個服務(wù)和其他的 AI 建站應(yīng)用（例如眾所周知的 Loveable）有所不同，Kimi K2.6 是從前端到后端都完全接管/托管，作為用戶不用關(guān)心任何技術(shù)細(xì)節(jié)也不用有任何技術(shù)背景，只需要用文字表達(dá)需求。

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

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

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

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

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

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

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

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

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

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

但現(xiàn)在不是，現(xiàn)在比的是當(dāng)：

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

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

3. 需要應(yīng)對無法預(yù)測的爆發(fā)流量

4. 讓 AI 在秒級別隨時動態(tài)創(chuàng)建/銷毀，以及動態(tài)生成訪問的 SQL

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

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

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

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

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

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

2：對 Agent 生成服務(wù)所使用的技術(shù)棧盡可能統(tǒng)一

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

3：極致的低成本

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

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

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

這樣的架構(gòu)轉(zhuǎn)變將整個數(shù)據(jù)庫平臺的彈性能力提升了一個臺階，換來的是在 Agent 場景的數(shù)據(jù)使用成本的數(shù)量級規(guī)模的下降。

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

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

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

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

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

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

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker