你選擇的基礎架構，決定你能長成什么樣的 AI 公司

當 Agent 走向生產，云與數據庫需要被一起重新考慮。

作者｜李粒、王黎黎、吳嘉程、魯超

編輯｜鄭玄、Cynthia

你有沒有想過一個問題：一次大模型問答只需 15 秒，可為何一個執行了 20 輪思考的 Agent，完成一項任務有時卻要半小時乃至數小時，甚至中途直接失敗？

答案是：用戶在等模型響應，而模型在等 CPU 調度的一系列 Infra 組件。

行業的多份分析顯示，當一個 Agent 在執行任務時，核心推理雖然由 GPU 承擔，但端到端延遲中，CPU 側調度的工具調用、數據庫讀寫、任務編排、文件處理、I/O 等待、狀態恢復與記憶檢索帶來的延遲占比，可以高達 50%-90%。

各種 AI Infra 組件中，承載狀態的數據庫層影響尤為突出。用戶在 TiDB Cloud 新創建的數據庫實例中，如今有近 90% 由 Agent 直接發起，而不是來自人類工程師。因此任何一次數據庫讀寫失敗、延遲抖動、召回不足等問題，都可能引發任務重啟、執行失敗，甚至將錯誤結果留存至模型記憶中，污染整條 Agent 鏈路。

隨著模型能力逐步完善、不同廠商之間趨同，AI Infra 的建設，正在成為決定下一階段 Agent 體驗的全新課題。

Agent 時代，當模型不再是唯一的變量，AI Infra 就成了拉開差距的地方。而數據庫正在從存儲系統，變成承載 Agent 狀態的關鍵基礎設施。

01

數據庫，

為什么成了 Agent 狀態的核心底座

有多少人在用 AI 的時候，會真的打開它的「思考過程」，去觀察一個典型的 Agent 是如何執行任務的？

例如，一個復雜任務可能在 30 秒內調用 12 次工具、寫入 4 次記憶、檢索 8 次向量、回查 3 次狀態。在傳統架構里，這意味著 12 次跨系統調用、4 次數據同步、8 次向量檢索、3 次狀態查詢——每一次都可能是潛在的失敗點。

更麻煩的是，Agent 的錯誤會被指數級放大。一個人類工程師寫錯一次代碼，影響的是一個服務。一個 Agent 的錯誤嘗試，可能會被寫入記憶，影響后續一系列 Agent 行為，甚至影響成千上萬個終端用戶。

因此 Agent 時代的數據庫問題，從來不只是「數據量變大了」。而是數據形態、使用方式、流量特征與系統邊界，都與傳統應用存在本質差異，狀態本身變復雜了。

第一，數據形態變得復雜，傳統架構的系統拼接模式，讓 Agent 出錯概率和運維成本一起飆升。

過去的數據庫系統主要處理訂單、賬戶、交易、商品、庫存等這類結構化數據，而 Agent 應用的數據類型更為多元和復雜：

它有 Memory（用戶偏好、項目背景、長期目標、歷史決策）；有 Context（對話歷史、工具返回、中間狀態、文件摘要）；有 State（Agent 做到哪一步、哪些工具調用成功、下一步從哪里恢復）；有 Vector（語義檢索和相似任務召回）；有 Trace（記錄工具調用、SQL、API、權限、成本和結果之間的關系）。

各類數據存在強關聯特性。例如，當 Agent 需要查詢「某用戶在對應項目中過往的相似決策」時，不能僅依靠向量檢索或單張關系表查詢，而要同時理解用戶權限、項目 ID、時間范圍、任務狀態、歷史決策和語義相似度。

如果繼續沿用「MySQL 存業務狀態、Redis 存短期狀態、對象存儲放文件、向量數據庫存放向量數據、日志系統記錄追蹤信息、數倉做分析」的拼接式老路，Agent 狀態就會被拆散在多個系統里，意味著每新增一套系統，都會疊加一次數據同步、多一層權限映射、多一處數據一致性補償、多一段審計對接的工作量。

在 AI 產品高速迭代、用戶飛速增長的情況下，工程團隊光是處理不同系統之間的數據同步，就足以拖慢整支團隊的節奏。

第二，Agent 特有的「長尾爆量」流量，會擊穿傳統成本模型。

過去數據庫講多租戶，租戶往往是企業客戶、團隊或 Workspace。Agent 場景里，租戶粒度會小得多，但總量卻可以呈指數級別增長。一個用戶就可能創建十個 Agent，一個 Agent 平臺也可能很快積累百萬、千萬，甚至數億級的邏輯租戶。關鍵的是，這種租戶規模雖然接近互聯網業務，但流量結構卻和傳統互聯網大相徑庭。

過去，無論是雙十一還是春晚，用戶規模有上限，即便存在流量高峰，但浪涌趨勢可預測。Agent 卻不一樣——它可能因為一次社媒傳播突然涌入百萬級用戶，也可能新增的百萬用戶里有 99% 都是低頻使用者。整體數據呈現出一種極端長尾模式：大量租戶長期零 QPS，少數租戶突然爆量。

傳統的資源分配模式也隨之失效。如果給每個 Agent 或每個應用都分配一個獨立的數據庫實例，即便單實例每月只要十幾美元，乘上百萬級租戶，也會變成一個難以承受的數據庫賬單；如果反過來把所有租戶塞進一個大庫，隔離、計量、爆炸半徑、Schema 演進和故障定位又會一齊失控。

某種程度上，Agent 時代需要的是一套能承載海量 Agent 狀態的數據庫底座：上層每個應用看起來「都有自己的數據庫」，底層卻能做到資源池化、按需調度、成本復用與統一治理。

這種「One Agent, One Sandbox, One Storage, One Database」的范式，正在成為頭部模型與 Agent 公司不約而同收斂到的同一架構終點。

第三，記憶從「對話切片」升級為「需要被治理的數據資產」。

當 Agent 真的開始長期服務一個用戶，記憶就會逐步顯出它的真面目——它不是會話窗口，也不是簡單的向量切片，而是一類需要被長期治理、檢索、更新和保護的數據資產。

過去很多產品把「記憶」等同于「本地文件 + 對話切片丟進向量庫」：哪些信息該記住、哪些信息更重要、哪些信息又需要被覆蓋，需要業務方手動維護；什么內容適合什么檢索方式，要團隊自行摸索；每次數據更新，都要重建一次索引。這種做法在 Demo 階段尚可，一旦真的長跑，就會迅速變成產品的隱性債務。

一個值得關注的方向，是把「記憶」做成數據庫內置的一等公民，讓它成為狀態底座的一部分。行業里近期出現的 Mem9 這類 Agent Memory 能力，就把記憶從應用層下沉到了數據庫一側——持久記憶零配置、混合檢索、跨設備同步，搭配一套 Context Engine，用戶不必手動配置記憶規則與召回方式，就能開箱獲得權限隔離與可視化審計。

記憶層正在從「應用層的小聰明」，回歸到「數據庫層的基礎能力」。這是 Agent 時代數據庫范式重寫中，最具代表性的一步。

第四，Agent 的全球化運營會不斷抬高對數據庫的要求。

AI 產品天然面向全球用戶。這意味著數據庫面對的不只是存儲問題，還包括數據就近訪問、跨區域部署、合規分區、企業審計、安全加密和彈性峰谷調度。

用戶在不同國家和地區，數據訪問不能全部繞回單一區域；不同市場有不同監管要求，數據邊界不能事后再補；企業客戶還會要求私網連接、加密、權限、審計和運維流程；Agent 流量峰谷不確定，底層資源也必須能快速彈性伸縮。

這些問題疊加，意味著「一個業務庫 + 一個緩存 + 一個向量庫 + 一套日志系統」的傳統拼接式方案，會越用越吃力。

然而，Agent 需要的數據庫，既要像應用數據庫一樣支持事務與狀態，又要像向量數據庫一樣支持語義檢索，還要像云原生系統一樣支持極端彈性、多租戶隔離和全球部署。

可當下這個時代階段，真的存在這樣的產品嗎？

02

兩個公司，同一個答案

真正先撞上數據庫新問題的，有兩類用戶：一類是大模型，一類是 Agent 平臺。

前者的代表是 Kimi——擁有億級用戶、支持多 Region 部署的自研大模型；后者的代表是某辦公 Agent——新一代的企業級 Agent，能夠生成完整可用的應用、執行長期任務、記住用戶的偏好與歷史經驗。

一個從模型走向 Agent，一個從 Agent 一端反推回數據底座。雖然兩者業務側重不同，但它們在底層狀態與數據庫選型上，幾乎不約而同走到了同一條路。——這是一個值得行業留意的信號。

Kimi視角：模型公司用一年時間替行業趟了一遍路

沒有人會比一家大模型公司自己更懂 Agent，也沒有人比他們更清楚，當 Agent 從測試走向生產時，底層數據庫會需要解決哪些潛在的挑戰。

以 Kimi K2.6 Agent 為例：用戶只需用一句自然語言描述需求，Agent 就會自己完成代碼生成、部署、以及后續的持續在線托管，整條鏈路在分鐘量級完成。它和「由 Agent 調用外部部署平臺」那類產品不同——K2.6 端到端擁有整條托管鏈路，也就意味著，當上百萬個用戶各自生成一堆 Agent 應用時，所有站點的數據庫、狀態、事務、訪問，都要由 Kimi 自己的這套底座扛下來。這種「Agent 自己造應用」的產品形態，天然把數據庫推入過去從未遇到過的極限——一個 Agent 平臺，同時需要托管起千萬級、乃至更多量級的、由 Agent 生成的獨立站點。

Kimi 團隊設想與嘗試過多種路徑。他們積累下的 Agent 場景數據庫選型經驗，對行業而言，或許是一個值得借鑒的參考。

比如，針對海量用戶的多租戶問題，有幾種選擇：

1）給每個應用一個獨立的關系型實例。邏輯上最清晰，隔離也非常直接，但當租戶規模進入百萬級、甚至更高時，物理實例會隨著邏輯租戶一起線性增長，閑置站點也照樣吞掉計算資源，成本曲線完全無法用訂閱模型收回。對一個每分鐘都在誕生新 Agent 站點的平臺來說，這條路從第一天就走不通。

2）用一個大型集中式數據庫加多 Schema。前期效率高，但 Kimi 團隊評估之后發現，這條路的實際天花板大約就落在「萬級租戶」這個量級——繼續往上加租戶，連接數、流控、租戶隔離、Schema 演進、擴容和故障半徑就會一起劣化，沒有一條能擴展到 Agent 平臺所需要的規模。

3）走嵌入式輕量方案。它很輕量，但備份、高可用、擴容、審計、跨區域容災都會變成平臺自己的負擔。對測試環境友好，然而對要求業務連續性的生產環境，卻并不友好。

Kimi 最終選擇了阿里云上的 TiDB(TiDB on Alibaba Cloud)——用一套底座，同時承接一家模型公司在高速發展過程中最難同時滿足的幾件事——把「邏輯上每個 Agent 都有自己的數據庫」和「物理上共享一套彈性底座」真正拆開來做。

從近期 Kimi 與 TiDB 聯合披露的公開案例來看，這套底座在架構上大致沿著三個方向展開。

1）用一層「虛擬數據庫」去替換掉傳統的「真實實例」：底層由一套跑在對象存儲之上的分布式 KV 層承擔數據持久化，上層則讓每一個 Agent 看到的都是一份完整、獨立、隨時可用的數據庫形態，實例回收、休眠、連接中斷等事件不會傳導到應用層。

2）把「數據庫開通」從 Agent 的交付關鍵路徑上摘掉。據公開信息，TiDB Cloud 通過 Warm Pool 維持一批預初始化好的 Starter 實例，配合 Scale-to-Zero，實現閑時收縮、有載展開，Agent 發起任務時能在秒級內拿到一套可用的數據庫。

3）把前端、后端、數據庫盡量收斂到同一套技術基座上，讓 Agent 在每次生成應用時都能復用一致的腳手架和最佳實踐。

這套架構落到最終的賬單和體驗上，是幾組非常具體的結果：

• 新建站點的數據庫開通時間穩定在一秒以內，Agent 不再需要在生成的代碼里寫重試和輪詢邏輯；

• 閑置站點的持續計算開銷被顯著壓縮，落到數千萬 Agent 租戶的規模上, 單個租戶身上的成本-收入模型，被真正改寫了；

• 單集群橫向支撐起數千萬級的 Agent 站點，用戶任何時候回訪，一次點擊就能喚醒；

• 租戶之間的爆炸半徑、流控、數據隔離——過去在「單庫多 Schema」方案里到幾萬租戶就會集中爆發的問題，被留在了架構窗口之外。

對 Kimi 而言，最終選擇這套底座的原因，不是任何一個單點指標最優，而是「多租戶隔離、統一技術棧、極致彈性」這三件事被同一套系統同時解決——放眼當下的數據庫產品，這樣的組合并不多見。

某辦公 Agent 視角：Agent 平臺如何解決「交付」和「成長」兩個核心問題

該辦公 Agent 在構建一個 AI Agent 平臺，目標是讓 Agent 真正「替用戶完成數字工作」——做數據分析、生成文檔、網頁研究、操作瀏覽器、生成圖片視頻、部署網站、執行定時監控任務。

隨著場景深入，它撞上了 Agent 產品從 Demo 走向真實使用時最核心的兩個問題。

問題一：Agent 生成的東西「看起來像應用」，但不是一個真正能用的應用——數據無法保存、刷新頁面就丟、沒有真實業務邏輯、不能多人同時使用。像一間漂亮的樣板房，沒有水電、門禁、管道，看著像房子，但不能真的住人。

問題二：Agent 每次執行任務都像一個新員工第一天上班——聰明，卻沒有經驗積累，用戶的格式偏好、歷史決策、試過的工具，下一次任務開始時又要從零講一遍。

解決這兩個問題，需要的并不是更強的模型，而是一套能支撐應用、狀態和記憶的數據基礎設施。而該辦公 Agent 交出了答案：

1）Full Stack Application，讓 Agent 生成的不只是漂亮的前端，而是帶后端邏輯、數據庫和真實業務狀態的完整應用；

2）Mem9，讓 Agent 擁有可持續、可搜索、可復用的長期記憶，不必每一次都從零開始。

這兩類能力的共同地基，正是同一套數據庫底座——阿里云上的 TiDB (TiDB on Alibaba Cloud)。前者要求每一個 Agent 生成的應用都有「自己的數據庫」形態，底層卻能高度池化、按需調度；后者要求把記憶做成數據庫內置的一等公民，內置混合檢索、跨會話同步、權限隔離與可視化審計。

這兩類能力和 Kimi 的答案落在同一處：一套底座——阿里云上的 TiDB。

Full Stack Application 解決「交付問題」；Mem9 解決「成長問題」。

Agent 從一次性工具，走向持續工作的 AI 員工——靠的是同一套數據底座。

共性需求，共同主張

Kimi 和 該辦公 Agent 的業務側重不同，但他們對底層狀態和數據庫能力的價值主張趨同。

首先，成本，成本，還是成本。針對多租戶帶來的無規律流量和成本問題，成本模型必須接近真實使用。阿里云上的 TiDB會將計算與存儲解耦，數據可以長期保留在低成本存儲層，計算按需啟動。這樣，冷數據不會長期占用計算資源，熱數據又能在請求到來時快速拉起。讓最終的賬單結構更接近「按調用計費」。

第二，需要解決多類型數據帶來的系統割裂。阿里云上的 TiDB在架構層做了統一：把 HTAP 一體、分布式事務、向量能力、半結構化與全文檢索，把「記憶、檢索、事務、分析」盡量收斂到一套引擎里，從根上減少數據搬運和一致性補償。

第三，需要解決高增長帶來的多租戶冷熱不均的管理問題。邏輯獨立和物理獨立必須拆開。阿里云上的 TiDB能夠支持百萬級 Schema Per-Tenant 隔離，對上層 Agent 來說，它拿到的是獨立數據庫形態；對底層平臺來說，資源可以池化、調度和復用。真正實現 One Agent, One Sandbox, One Storage, One Database。

03

Agent 走向生產，

需要云與數據庫深度協同

如果只看數據庫本身，TiDB 的產品設計已經能解決很多問題。甚至對很多 Agent 應用來說，在早期階段，拼接式數據庫系統也可以勉強使用。

但 Agent 應用一旦進入生產，需要的就不再只是「一個數據庫」，而是模型平臺、對象存儲、日志、網絡、安全、數據同步、運維體系和全球區域能力一起工作。因此，阿里云上的 TiDB，體現出了云與數據庫深度協同之后的相性價值。

第一，存算分離和極致彈性

只有云上的分布式資源池，才能讓計算與存儲解耦、讓資源按需調度，讓「百萬級邏輯租戶」不等于「百萬個物理實例」。

對 Agent 應用來說，這一點尤其重要——它的負載不是穩定線性增長，而是大量長尾租戶與少量突發熱點并存。底層系統必須能讓冷數據低成本保留、讓熱任務快速拉起、讓資源在不同租戶之間高效復用。背后離不開阿里云上的對象存儲、彈性調度能力和 Serverless 資源模型。

第二，阿里云上的 TiDB，從來不是「單點能力」，而是 AI 全棧能力的一環。

Agent 跑在云上，就意味著我們需要以統一視角來審視模型、數據庫、對象存儲、日志、安全、網絡、區域等等技術要素。

在阿里云體系里，算力側可以接 PAI、靈駿，模型側可以調用阿里云百煉等能力；計算與沙箱側可以用 ACS Agent Sandbox、FC Sandbox；文件側用 OSS 承接文檔、圖片、音頻、代碼包和中間產物；緩存側可以疊加 Tair Vector；日志側用 SLS 記錄工具調用、錯誤鏈路和審計信息；網絡側則有 PrivateLink、VPC 對等連接、IP 白名單等私網能力，以及 CEN 骨干網和全球加速 GA。

Agent 跑在云上的真正價值，是讓模型、數據庫、對象存儲、日志、安全和網絡可以被放進同一套工程體系里思考——從模型訓練到部署、推理、數據落庫、RAG 檢索，可以在 VPC 內閉環，避免跨云出口流量費與數據合規的人為切割。

數據庫放在云上，不是裝上去，而是長進去。

這件事的價值，不僅在于讓團隊少接幾個系統，更能讓他們少花時間處理基礎設施之間的摩擦，把更多精力留給產品迭代和業務增長。在傳統軟件時代，團隊可以慢慢補齊這些工程能力。但在 Agent 時代，速度本身就是競爭力。

第三，阿里云加速 Agent 產品全球化

對于 Agent 類產品，出海/全球化幾乎是一門必修課。這其中就包括了如何實現底層數據庫區域資源調度和合規。

無論用戶在東南亞、歐洲、中東、日本還是北美，阿里云支持「用戶就近接入、數據就近合規、模型集中調度」的全球化部署。得益于阿里云在全球范圍 32 個公共云地域、105 個可用區，境外覆蓋中國香港、新加坡、印尼、馬來西亞、法國、德國、英國、阿聯酋、日本、韓國、美國、拉美等等關鍵節點。Agent 出海公司在新市場打開節奏可以從月級壓到周級，跨域延遲穩定在毫秒級。

合規方面，歐盟 GDPR、新加坡 PDPA、中東 DCA 和 PDPL、日本 APPI、印尼 PDP 等多區域法規法案疊加數據本地化、跨境傳輸、用戶記憶所有權，任何一項處理不好都可能是一票否決。能否在當地擁有完整的本地法人實體與合規資質，直接決定了出海公司「能不能落地」，而不只是「能不能接入」。

把數據庫能力和云上的區域、安全、網絡、合規能力放到同一套工程體系里，讓全球化擴張不會變成全球各地割裂的系統煙囪。

第四，Agent 時代的數據安全，不再只是數據庫自己的事。

對模型公司和 Agent 平臺來說, 最大的不是技術債，而是「數據被誰看見」的債。Agent 時代新增的風險面也比傳統應用更復雜——長記憶 = 長曝光、工具調用 = 橫向移動、向量泄露 = 語義反推。

與之對應，新一代云上數據庫正在把安全做成「內建」而非「外掛」：三層架構隔離（全局控制平面、區域控制平面、數據平面）。

阿里云全鏈路加密體系：數據傳輸、內部通信、落地存儲全程加密，用戶能自主掌管加密密鑰，全方位守護數據安全。

阿里云完善的合規能力：在國際范圍內通過了 150 多項安全合規認證，如 ISO27001 信息安全管理、ISO27017 云安全管理等全球通用合規認證、ISO42001 人工智能管理認證，以及歐盟、美國、中東、東南亞等區域或國家主流認證等。

阿里云上的 TiDB基于零信任網絡規則，配合阿里云私網鏈路與 IP 白名單等功能，在多租戶共用共享基礎設施中實現網絡、計算、存儲三層隔離，保障各租戶環境獨立安全。疊加 AI 驅動的安全運營與多層審計日志，大幅縮短安全事件的平均響應時間。

在 Agent 時代，數據庫的安全不再只是數據庫的事，它是云、引擎、應用三方共同簽名的承諾。

04

Agentic Database，

是數據庫范式的第三次重啟

過去幾十年，數據庫經歷過 OLTP、OLAP、HTAP、Cloud Native 等多次演進。在這條路上，行業一直朝著「更快、更便宜、更穩定」這些老命題不斷疾馳。

但 Agent 時代提出了新問題：數據不再僅僅是自然人在使用、數據的分布與形態與過往大相徑庭，全球化擴展也不再是公司后期才會考慮到的問題，而是 AI 產品從第一天就可能面對的現實。

如果說云原生數據庫是數據庫范式的第二次重啟，那么 Agentic AI Database，大概率會是第三次。

這些問題關系到 Agent 產品能不能從 Demo 走向生產，能不能從個人用戶走向企業客戶乃至全球，能不能在高速增長時仍然控制成本和風險。每一次數據庫切換，對企業來說都是一次基礎設施層面的傷筋動骨。如何降低切換的風險與成本，從來都是數據庫范式躍遷期的核心議題。

從近期行業的動作看，圍繞「Agent 團隊如何在架構窗口期低成本驗證新底座」，已經開始出現一些值得留意的嘗試。比如：

1、《TiDB × 阿里云 安全合規白皮書》近期已公開提供下載，把數據主權、跨境合規與多租戶隔離這些 Agent 團隊最容易踩雷的議題，拆成了一份可執行的清單；

2、面向中國模型出海公司、Agent 平臺與垂直 AI 應用開放的「Agent Database Starter Program 項目」，提供一定免費額度，由 PingCAP 資深工程師和阿里云產品解決方案架構師陪跑，幫助團隊完成架構評估、PoC、壓測、遷移建議和上線設計。后續滿意即轉商用，按實際用量計費。

這些工程化的「加速包」，本身已經在說一件事：Agent 時代的數據庫選型，不再是一道「我下個月能不能上線」的問題，而是一道「我能不能比對手早三個月跑到下一里程碑」的問題。

在速度決定一切的 Agent 時代，選對數據庫，從來不只是選一套基礎設施，而是為創新預留出真正發生的空間。

*頭圖來源：PingCAP

本文為極客公園原創文章，轉載請聯系極客君微信 geekparkGO

極客一問

你如何看待辦公 Agent ？