面向 AI Agents 的高性能數(shù)據(jù)基座：架構和工程實踐

演講嘉賓｜陳亮

編輯 ｜Kitty

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

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

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

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

AI Agent 驅動的 AI 原生應用

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

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

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

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

在 Agent 時代會有什么變化？首先在 Agent 場景中，它的工作流就不再是工作流，開發(fā)更多關注在 Agent 的編排上，我們可能會有很多個 Agent。當然核心是大模型，我們怎么用大模型去驅動不同的 Agent？這里有一個很不一樣的點，就是說在今天我們剛開始開發(fā)應用時就需要有數(shù)據(jù)，數(shù)據(jù)可能來自知識庫，可能來自外部的某些結構化數(shù)據(jù)，這個數(shù)據(jù)實際是作為 Agent 的燃料，就像汽車冷啟動需要燃料一樣。大模型更多像一個驅動引擎，因為大模型只能提供一些比較通識性的東西，我要去實現(xiàn)一些非常領域特定的任務實際是有困難的，所以我需要很多數(shù)據(jù)，而且是行業(yè)的數(shù)據(jù)。但這個數(shù)據(jù)是外部來的，所以數(shù)據(jù)的格式、數(shù)據(jù)的規(guī)模可能不是我所能完全掌控的。

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

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

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

Pinecone 和 Elastic 大家比較熟悉，因為在大模型時代你的文本是很重要的事情。當我們提到文本搜索時，實際上向量和全文往往是要一起做的，同時可能還要搭配一個 Ranker。當然可能還會有知識庫，有些知識庫是通過圖來表示的，因為用戶有不斷的反饋的時候，這個時候你的 Agent 往往需要一些對話的信息，而且延時要求很短，所以我需要一些基于內(nèi)存的數(shù)據(jù)庫。

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

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

Agent 里有一個很重要的，我們叫 Agent Loop 或者叫一個環(huán)。因為交互往往不是一輪的，需要很多人不斷迭代。這個 Agent 它自己可能會調(diào)大模型，獲取一些信息，還會有很多外部調(diào)用。外部調(diào)用可能來自網(wǎng)絡搜索，可能外部有某個計算服務。當然還有一個很重要的方式就是 RAG，可能會有全文知識庫的 RAG。

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

簡單總結一下，互聯(lián)網(wǎng)時代和 Agent 時代從數(shù)據(jù)角度來看的第一個區(qū)別就是前者的數(shù)據(jù)是由應用生成的，意味著數(shù)據(jù)是可控的。但在 AI 時代就不一樣了，因為可能會有很多外部的數(shù)據(jù)進來，這個東西不是你完全可控的，而且規(guī)模也可能會很大。另外 AI 時代還會有大量非結構化數(shù)據(jù)，所以今天幾乎所有的數(shù)據(jù)庫都要發(fā)展向量的能力，因為搜索變得越來越重要。最后一點就是 Agent 是會互相交互，會跟外部交互的，交互時它是要把內(nèi)容記錄下來，所以數(shù)據(jù)量很快就會積累起來。

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

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

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

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

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

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

第二點設計目標就是動態(tài)伸縮，自動管理。這是和今天云原生的趨勢是很吻合的。

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

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

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

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

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

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

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

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

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

最后我們還有一個容錯和恢復的協(xié)議。

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

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

面向未來的工程實踐

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

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

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

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

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

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

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

總結和展望

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

嘉賓介紹

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

會議推薦

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

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