演講嘉賓｜陳亮

編輯 ｜Kitty

策劃 ｜QCon 全球軟件開發(fā)大會

隨著大模型快速發(fā)展，以 AI Agents 驅(qū)動的新一代 AI 原生應(yīng)用快速發(fā)展，取得巨大成功。AI 原生應(yīng)用以大模型為基礎(chǔ)，通過各類 Agents 和應(yīng)用數(shù)據(jù)交互，智能地完成各類任務(wù)。AI Agents 驅(qū)動的應(yīng)用開發(fā)迭代迅速，同時(shí)維護(hù)多種模態(tài)的數(shù)據(jù)，不同模態(tài)數(shù)據(jù)的訪問模式和流量差別巨大，這些特點(diǎn)給底層數(shù)據(jù)平臺提出了新的挑戰(zhàn)。未來 AI Agents 驅(qū)動的原生應(yīng)用需要怎樣的數(shù)據(jù)基座？

在 InfoQ 舉辦的 QCon 全球軟件開發(fā)大會（北京站）上，晨章數(shù)據(jù)創(chuàng)始人、首席架構(gòu)師陳亮帶來了題為《面向 AI Agents 的高性能數(shù)據(jù)基座：架構(gòu)和工程實(shí)踐》的演講，分享了關(guān)于 AI 時(shí)代數(shù)據(jù)基座架構(gòu)的思考，如何通過該架構(gòu)解決 AI 原生應(yīng)用的數(shù)據(jù)挑戰(zhàn)，以及在云計(jì)算、新硬件環(huán)境下實(shí)現(xiàn)高性能數(shù)據(jù)基座的工程實(shí)踐。

以下是演講實(shí)錄（經(jīng) InfoQ 進(jìn)行不改變原意的編輯整理）。

AI Agent 驅(qū)動的 AI 原生應(yīng)用

今天，AI Agent 正在引領(lǐng)整個(gè)軟件范式的變革。在 AI 時(shí)代之前，我們討論的是 SaaS，彼時(shí)軟件作為工具實(shí)際上是構(gòu)建了一個(gè)工作流程，在這個(gè)工作流程中幫助人來完成某些工作。而 SaaS 變成 AI 驅(qū)動后就會發(fā)生范式變化，軟件變得更加智能，變成了智能體，可以執(zhí)行非常復(fù)雜的任務(wù)，甚至可以有一定的自我演化和改進(jìn)的能力。從這個(gè)角度來說，它不再是個(gè)幫助人的軟件工具，它自己就變成一個(gè)智能體，可以直接提供一個(gè)服務(wù)。

在 SaaS 時(shí)代，SaaS 軟件會有工作流，用戶會提供一個(gè)輸入，工作流幫助用戶完成某些任務(wù)。工作流中間會收集很多數(shù)據(jù)，很多狀態(tài)，這些狀態(tài)會記錄在某個(gè)數(shù)據(jù)庫里，很多時(shí)候它是結(jié)構(gòu)化數(shù)據(jù)。這里有一個(gè)顯著的特性，就是第一個(gè)數(shù)據(jù)是由這個(gè)軟件生成出來的，或者我們認(rèn)為說數(shù)據(jù)是軟件的一個(gè)排放。所以在這樣的一個(gè)架構(gòu)下，大家對數(shù)據(jù)會有一些比較簡化的期待。

第一個(gè)數(shù)據(jù)的格式往往是軟件開發(fā)人員定義的。因?yàn)檫@是我寫的軟件，所以我想定義這個(gè)數(shù)據(jù)有什么屬性，大概以什么格式，到底是個(gè)表格還是個(gè)圖，這個(gè)是我開發(fā)者來定義的。同時(shí)數(shù)據(jù)也是在軟件的運(yùn)行過程中不斷收集的，意味著我的數(shù)據(jù)量是隨著我的軟件規(guī)模和用戶互動慢慢在增長，總的來說是可控的。

當(dāng)然隨著軟件越來越復(fù)雜，收集數(shù)據(jù)越來越多，最終數(shù)據(jù)的格式可能會變得更加復(fù)雜，我需要更加智能的分析，但這個(gè)過程是一個(gè)相對緩慢的過程，這個(gè)過程是隨著我的軟件越來越流行，用戶量越來越大而發(fā)展的?？赡芎芏嘬浖]有爆款，它對數(shù)據(jù)的需求也就并沒有那么高。

在 Agent 時(shí)代會有什么變化？首先在 Agent 場景中，它的工作流就不再是工作流，開發(fā)更多關(guān)注在 Agent 的編排上，我們可能會有很多個(gè) Agent。當(dāng)然核心是大模型，我們怎么用大模型去驅(qū)動不同的 Agent？這里有一個(gè)很不一樣的點(diǎn)，就是說在今天我們剛開始開發(fā)應(yīng)用時(shí)就需要有數(shù)據(jù)，數(shù)據(jù)可能來自知識庫，可能來自外部的某些結(jié)構(gòu)化數(shù)據(jù)，這個(gè)數(shù)據(jù)實(shí)際是作為 Agent 的燃料，就像汽車?yán)鋯有枰剂弦粯?。大模型更多像一個(gè)驅(qū)動引擎，因?yàn)榇竽Ｐ椭荒芴峁┮恍┍容^通識性的東西，我要去實(shí)現(xiàn)一些非常領(lǐng)域特定的任務(wù)實(shí)際是有困難的，所以我需要很多數(shù)據(jù)，而且是行業(yè)的數(shù)據(jù)。但這個(gè)數(shù)據(jù)是外部來的，所以數(shù)據(jù)的格式、數(shù)據(jù)的規(guī)?？赡懿皇俏宜芡耆瓶氐?。

AI 與用戶不斷交互還會產(chǎn)生更多數(shù)據(jù)，同樣它會生成底層的數(shù)據(jù)。我們接觸了很多 Agent 開發(fā)的項(xiàng)目，我發(fā)現(xiàn)它們在第一天的時(shí)候就考慮數(shù)據(jù)的反哺，換句話說我不但要收集數(shù)據(jù)，還要用數(shù)據(jù)豐富我的知識庫。最終我提供的就是一個(gè)服務(wù)，用戶看到的是一個(gè)整體的服務(wù)，它不再是幫助人的工具，這時(shí)它自己可能就變成了一個(gè)智能體。

舉一個(gè)具體的例子，這是一個(gè)金融的場景。

這里有 4 個(gè) Agent，有一個(gè) Agent 主要負(fù)責(zé)市場分析，一個(gè) Agent 要關(guān)注風(fēng)控，等等。從數(shù)據(jù)的視角來看，在這個(gè) App 里我們可能需要很多種不同的數(shù)據(jù)庫。我可能需要有用戶的信息，用戶的信息一般是存在表格里的。我可能會有財(cái)報(bào)，往往是一種半結(jié)構(gòu)化的數(shù)據(jù)，里面可能有一些結(jié)構(gòu)化的東西可以抽出來。如果外部的知識庫很大，包括很多日志，它可能也是要放入 Mongo 的。

Pinecone 和 Elastic 大家比較熟悉，因?yàn)樵诖竽Ｐ蜁r(shí)代你的文本是很重要的事情。當(dāng)我們提到文本搜索時(shí)，實(shí)際上向量和全文往往是要一起做的，同時(shí)可能還要搭配一個(gè) Ranker。當(dāng)然可能還會有知識庫，有些知識庫是通過圖來表示的，因?yàn)橛脩粲胁粩嗟姆答伒臅r(shí)候，這個(gè)時(shí)候你的 Agent 往往需要一些對話的信息，而且延時(shí)要求很短，所以我需要一些基于內(nèi)存的數(shù)據(jù)庫。

所以在搭建 Agent 應(yīng)用的第一天，可能就會涉及到很多種數(shù)據(jù)庫了。而外部來的數(shù)據(jù)規(guī)模你是不可管控的，如果規(guī)模很大怎么辦？這個(gè)時(shí)候你就得用一個(gè)有擴(kuò)展性的選擇。同時(shí)從性能要求來說，因?yàn)橛行I(yè)務(wù)是和用戶要交互的，所以延時(shí)要求天生比較嚴(yán)苛，所以我一定會有一個(gè)純內(nèi)存的東西。

上圖展示了今天常見的一個(gè) Agent 的工作流。它一般是一個(gè)網(wǎng)絡(luò)服務(wù)，用戶會登錄進(jìn)來，登錄之后你會有用戶的信息，這時(shí)你就要訪問一些關(guān)系型數(shù)據(jù)庫了。

Agent 里有一個(gè)很重要的，我們叫 Agent Loop 或者叫一個(gè)環(huán)。因?yàn)榻换ネ皇且惠喌模枰芏嗳瞬粩嗟?。這個(gè) Agent 它自己可能會調(diào)大模型，獲取一些信息，還會有很多外部調(diào)用。外部調(diào)用可能來自網(wǎng)絡(luò)搜索，可能外部有某個(gè)計(jì)算服務(wù)。當(dāng)然還有一個(gè)很重要的方式就是 RAG，可能會有全文知識庫的 RAG。

這里還有短期和長期的記憶，有不同的延時(shí)需求。短期記憶可能要放在一個(gè)基于內(nèi)存的東西，長期的規(guī)模比較大的就放在一個(gè)相對持久的數(shù)據(jù)庫里。所以不同的數(shù)據(jù)都需要自己對應(yīng)的數(shù)據(jù)庫，而且在應(yīng)用交互的過程中還會不斷生成新的數(shù)據(jù)。

簡單總結(jié)一下，互聯(lián)網(wǎng)時(shí)代和 Agent 時(shí)代從數(shù)據(jù)角度來看的第一個(gè)區(qū)別就是前者的數(shù)據(jù)是由應(yīng)用生成的，意味著數(shù)據(jù)是可控的。但在 AI 時(shí)代就不一樣了，因?yàn)榭赡軙泻芏嗤獠康臄?shù)據(jù)進(jìn)來，這個(gè)東西不是你完全可控的，而且規(guī)模也可能會很大。另外 AI 時(shí)代還會有大量非結(jié)構(gòu)化數(shù)據(jù)，所以今天幾乎所有的數(shù)據(jù)庫都要發(fā)展向量的能力，因?yàn)樗阉髯兊迷絹碓街匾Ｗ詈笠稽c(diǎn)就是 Agent 是會互相交互，會跟外部交互的，交互時(shí)它是要把內(nèi)容記錄下來，所以數(shù)據(jù)量很快就會積累起來。

AI 原生應(yīng)用面臨的數(shù)據(jù)挑戰(zhàn)

從系統(tǒng)的角度來說，AI 時(shí)代的這些特點(diǎn)會給數(shù)據(jù)庫管理帶來很多挑戰(zhàn)。第一個(gè)挑戰(zhàn)就是我們希望數(shù)據(jù)庫會有多模態(tài)。第二個(gè)是當(dāng)我們有很多個(gè)數(shù)據(jù)庫，數(shù)據(jù)的同步和數(shù)據(jù)一致性總是要考慮的。比如說我們在聊天里可能有短期記憶，最終總是要把它變成長期記憶的，同時(shí)應(yīng)用輸出的內(nèi)容也總要反饋到原來的各種數(shù)據(jù)模型下，就會有一個(gè)數(shù)據(jù)的環(huán)。第三點(diǎn)，應(yīng)用中不同數(shù)據(jù)庫對性能、規(guī)模等屬性的要求各不一樣。最后就是多系統(tǒng)的運(yùn)維和管理。今天的 AI 時(shí)代我們可以快速開發(fā)一個(gè)應(yīng)用，可能 3 個(gè)人的團(tuán)隊(duì) 6 個(gè)月就可以快速搭建 1 個(gè) App，但我要運(yùn)維 App 反倒變成了一個(gè)很大的成本，因?yàn)閿?shù)據(jù)要不斷積累，這是你的核心價(jià)值。

總結(jié)來說，AI Agent 驅(qū)動的應(yīng)用在早期就會面臨傳統(tǒng)大廠才會有的數(shù)據(jù)挑戰(zhàn)，同時(shí)數(shù)據(jù)飛輪在 AI Agent 時(shí)代迭代更加迅速，加劇了數(shù)據(jù)庫系統(tǒng)的壓力。

多模態(tài)數(shù)據(jù)基座

在這樣的背景下，我們的思考就是我們應(yīng)該做哪些事情，能不能有一個(gè)統(tǒng)一的數(shù)據(jù)架構(gòu)來做這樣的事情。最終的方向就是多模態(tài)的數(shù)據(jù)基座。

我們的設(shè)計(jì)目標(biāo)有三點(diǎn)，第一點(diǎn)就是支持多種數(shù)據(jù)模態(tài)。在 AI 時(shí)代，可能一個(gè)應(yīng)用就會面臨多模態(tài)支持的問題。我們想特別強(qiáng)調(diào)兩個(gè)方面，第一就是我們希望它的 API 是原生兼容的。比如說我有個(gè) Json 的 API，至少應(yīng)該是跟 Mongo 兼容；我是個(gè) SQL API，應(yīng)該可以和 MySQL 兼容，這是一個(gè)很重要的點(diǎn)。因?yàn)殚_發(fā)人員希望我的系統(tǒng)是可擴(kuò)展的，可遷移的，有的時(shí)候我可能想在云上部署，有可能我想在私有化部署，私有化部署甚至還可能有很多限制，所以你用標(biāo)準(zhǔn)的 API 變得非常關(guān)鍵。我當(dāng)然可以自己定一個(gè) API，但如果讓大家來我這邊建立 App，未來就會有很大的風(fēng)險(xiǎn)。第二個(gè)我想強(qiáng)調(diào)的是性能。性能和成本永遠(yuǎn)是長期的考量，我覺得這可能是最關(guān)鍵的，對系統(tǒng)開發(fā)人員來說可能是最重要的點(diǎn)。用戶在選擇的時(shí)候，如果你的系統(tǒng)性能比別人慢，你說我的價(jià)值來自多模態(tài)，這個(gè)論述就變得非常弱了。

第二點(diǎn)設(shè)計(jì)目標(biāo)就是動態(tài)伸縮，自動管理。這是和今天云原生的趨勢是很吻合的。

第三點(diǎn)目標(biāo)是跨模態(tài)訪問和一致性。模態(tài)之間是有數(shù)據(jù)的相互同步，同樣有一致的訪問。我并不希望比如我有 8 個(gè)數(shù)據(jù)庫，大家各干各的。數(shù)據(jù)庫之間的壁壘要消融掉，是多模態(tài)很重要的點(diǎn)。我并不需要一個(gè)中間件或者一個(gè)代理，把所有的數(shù)據(jù)庫連接起來，然后統(tǒng)一提供接口，這個(gè)意義并沒有很大，你沒有降低它的管理成本。同時(shí)在有些應(yīng)用里，從長期記憶到短期記憶，從我的結(jié)果到抽取回知識庫里，很多時(shí)候都是跨模態(tài)的訪問。

在講多模態(tài)數(shù)據(jù)架構(gòu)之前，我先簡單回顧一下數(shù)據(jù)庫架構(gòu)的演化歷史。

數(shù)據(jù)庫在很早以前實(shí)際上就一臺機(jī)器，后來數(shù)據(jù)庫演化就分叉了，分成了 OLAP 和 OLTP。到了云時(shí)代，之前 OLAP 數(shù)據(jù)庫的無共享架構(gòu)就不是特別理想，于是就有了新的做法叫存算分離。OLTP 一開始也有無共享架構(gòu)，但后來它的演化就沒那么簡單。因?yàn)?TP 和 AP 之間有一個(gè)很大的不同，AP 里不太在意內(nèi)存緩存。因?yàn)樗粩鄴呙璐罅繑?shù)據(jù)，內(nèi)存肯定放不下，最后總是要掃描磁盤的。可在線的 TP 就不一樣了，因?yàn)樾枰撩爰壍难舆t，所以內(nèi)存緩存非常重要，是保證延時(shí)最重要的手段。而無共享架構(gòu)下計(jì)算和緩存不在一塊，每次訪問都要走網(wǎng)絡(luò)，那么在 Agent 時(shí)代這個(gè)延遲就很難保證。所以業(yè)界提出了 Aurora 的架構(gòu)，把緩存提上去，計(jì)算和緩存在一塊，然后下面有個(gè)存儲，我們叫共享存儲架構(gòu)，這樣它的延時(shí)可以保證。

我們的思路是，在計(jì)算和存儲之間會有一個(gè)數(shù)據(jù)的基層，在基層里我最強(qiáng)調(diào)的就是緩存，緩存是保證在線數(shù)據(jù)庫延時(shí)里最重要的一個(gè)事。而且在線數(shù)據(jù)的所有模態(tài)，不管是做向量搜索、全文搜索還是做 graph，最重要的都是緩存，不在緩存里的東西延時(shí)是很難有保證的。

我們的數(shù)據(jù)基座里上面會有計(jì)算，下面會有存儲。計(jì)算引擎是可以換的，什么樣的引擎都可以，我們可以和很多開源組件原生兼容。中間我們會有一個(gè)數(shù)據(jù)基層，它抽象出來了在線數(shù)據(jù)庫里最核心的一些功能，其中最重要的就是緩存。同時(shí)我們希望能用統(tǒng)一的緩存格式來彌合或消除不同數(shù)據(jù)模態(tài)之間的壁壘，使得數(shù)據(jù)在統(tǒng)一訪問，或者在跨模態(tài)訪問時(shí)可以高效。

另外在我們這里緩存和計(jì)算是邏輯解耦，物理耦合的。物理耦合指的是緩存盡量放在機(jī)器本地內(nèi)存上，減少跨網(wǎng)絡(luò)讀取。邏輯解耦是想用它來消除不同模態(tài)之間的差別，通過緩存實(shí)現(xiàn)和原生系統(tǒng)一樣的性能。

提到緩存，大家可能第一反應(yīng)就是一個(gè)傳統(tǒng)的哈希表。但因?yàn)槲覀兊臄?shù)據(jù)是想支持不同模態(tài)的，所以我要努力支持更加復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，這個(gè)結(jié)構(gòu)是隨著我的模態(tài)而變的。所以緩存的設(shè)計(jì)并不是一個(gè)簡單的 key 和 value 的映射，我們希望有一個(gè)能支持更加復(fù)雜數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)。

總的來說我們會有一個(gè)邏輯上的分布式哈希表，它不是簡單的 string，是一種復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。

緩存和存儲之間還會有互動，當(dāng)數(shù)據(jù)做更改之后，緩存會用異步的方式把它存到存儲上，實(shí)時(shí)操作只會更新到日志里，不會觸發(fā)持久化存儲。

最后我們還有一個(gè)容錯(cuò)和恢復(fù)的協(xié)議。

我們這樣的融合數(shù)據(jù)庫，希望能通過一個(gè)數(shù)據(jù)基層，在融合緩存上裝配各種計(jì)算引擎。因?yàn)榫彺婧陀?jì)算是物理耦合的，所以性能可以做到和原生一樣好。同時(shí)我的協(xié)議也是完全兼容原生的。

這樣我就可以支持多種模態(tài)，兼容現(xiàn)有標(biāo)準(zhǔn)，同時(shí)滿足性能需求，并做到統(tǒng)一的運(yùn)維管理。

面向未來的工程實(shí)踐

談到工程實(shí)踐，我們先來看看 AI 時(shí)代基礎(chǔ)設(shè)施環(huán)境是什么樣子的。我們會有云計(jì)算、高速網(wǎng)絡(luò)、高速存儲設(shè)備，還有 GPU 這樣的新型計(jì)算設(shè)備提供巨大的算力。

過去十年來，CPU 的性能增長了一倍半，而存儲性能增長了 11 倍以上，網(wǎng)絡(luò)性能有 20 倍的增長。按照這個(gè)趨勢發(fā)展，未來我們的存儲或數(shù)據(jù)基座設(shè)備會變成 CPU 瓶頸，因?yàn)?IOPS 在快速增長，CPU 的增長卻很緩慢。所以如果今天我們什么都不做的話，未來 IOPS 這一塊我們會看不到任何性能提升，因?yàn)?CPU 沒有提升。這也就意味著傳統(tǒng)數(shù)據(jù)庫系統(tǒng)的性能無法隨著 IO 設(shè)備的迭代而增長。

針對這個(gè)問題我們做了很多事情，比如說我們所有的執(zhí)行都是協(xié)程，比如說我們都是要異步編程，比如說我們每個(gè)核心只有一個(gè)線程，最后我們希望能采用一些緩存友好的數(shù)據(jù)結(jié)構(gòu)。這些都是為了降低 CPU 的負(fù)載。

我們公司還做了一個(gè)試驗(yàn)性的存儲，它是一個(gè) k-v 存儲，是多讀單寫的。我們每個(gè)查詢做一個(gè)協(xié)程，提交后切換協(xié)程。

然后我們做了簡單的測試，就是我們有個(gè) 16 核的機(jī)器，故意把緩存設(shè)成了 4GB，就是為了看數(shù)據(jù)不是全部緩存在內(nèi)存里是什么表現(xiàn)。

結(jié)果發(fā)現(xiàn)在同樣的 CPU 下，我們的設(shè)計(jì)可以做到接近理論上線，比 RocksDB 高出很多。

這也就證明傳統(tǒng)的數(shù)據(jù)庫架構(gòu)會遇到 CPU 的瓶頸，出現(xiàn)這種瓶頸時(shí)單純更換 IO 設(shè)備是很難有增長的。

總結(jié)和展望

總的來說，我覺得 AI Agent 時(shí)代會帶來軟件范式的變革，軟件范式變革必然會讓數(shù)據(jù)管理產(chǎn)生巨大的變化?？偨Y(jié)起來就是我們希望有多模態(tài)的支持，有原生 API 的支持，有高性能的支持，我們希望擴(kuò)縮容更加方便，從管理來講會更加易用。最后結(jié)合工程實(shí)踐，我們在性能方面也有一些新的思考。希望這次的分享能給大家?guī)韱l(fā)，謝謝。

嘉賓介紹

陳亮，北京晨章數(shù)據(jù)科技有限公司創(chuàng)始人，首席架構(gòu)師。前微軟亞洲研究員首席研究員。數(shù)據(jù)庫領(lǐng)域頂級專家。微軟 SQL Server XML 索引發(fā)明人和架構(gòu)師，微軟 Cosmos DB 圖數(shù)據(jù)庫架構(gòu)師。曾在 SIGMOD、VLDB、 ICDE 等國際頂級會議上發(fā)表多篇學(xué)術(shù)論文。

會議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產(chǎn)，Agentic AI 的探索也將從局部試點(diǎn)邁向體系化工程建設(shè)！

QCon 北京 2026 已正式啟動，本屆大會以“Agentic AI 時(shí)代的軟件工程重塑”為核心主線，推動技術(shù)探索從「AI For What」真正落地到可持續(xù)的「Value From AI」。從前沿技術(shù)雷達(dá)、架構(gòu)設(shè)計(jì)與數(shù)據(jù)底座、效能與成本、產(chǎn)品與交互、可信落地、研發(fā)組織進(jìn)化六大維度，系統(tǒng)性展開深度探索。QCon 北京 2026，邀你一起，站在拐點(diǎn)之上。