凌晨三點，數(shù)據(jù)庫告警炸了。

你嘗試把告警信息甩給一個 “頂級” DBA Agent。它見多識廣，熟讀 PostgreSQL 文檔，能寫出漂亮的診斷 SQL，對每一個內(nèi)核參數(shù)的含義倒背如流。

它愣住了：集群拓撲是什么樣的？主從都在哪些服務器上？監(jiān)控面板怎么看？日志哪里找？上次類似故障怎么解的？我該用什么工具執(zhí)行什么操作？

什么都不知道。

而隔壁那個用普通模型、但深度接入了完整運維環(huán)境的 Agent，已經(jīng)定位到根因、完成了切換重啟、發(fā)出了復盤報告。原理很樸素 ——

一個熟悉環(huán)境的普通人，會比來到陌生環(huán)境的天才更能干。

沒有上下文的智力，是空轉(zhuǎn)的。沒有 Runtime 的 Agent，是虛浮的。

強龍不壓地頭蛇。

OtterTune：一個價值 1200 萬美元的教訓

2020 年，CMU 數(shù)據(jù)庫網(wǎng)紅教授 Andy Pavlo 帶著學生創(chuàng)辦了 OtterTune —— 用 AI 做數(shù)據(jù)庫自動調(diào)優(yōu)。 頂級學術(shù)團隊、拿了 1200 萬美元投資、瞄準 PostgreSQL 和 MySQL 兩大主流數(shù)據(jù)庫，背景不可謂不豪華。

產(chǎn)品邏輯概括一下： 給我一個數(shù)據(jù)庫連接串，AI 就能幫你調(diào)優(yōu)。

2024 年 6 月，OtterTune 宣布關門。表面原因是收購交易破裂。 但在老馮看來，根本的問題是： 一個連接串能做的事情，價值實在太少了。

通過連接串，你能看到 pg_stat_statements 里的慢查詢、 pg_settings 里的配置參數(shù)、幾個系統(tǒng)視圖的統(tǒng)計信息。然后呢？調(diào)幾個 knob，優(yōu)化幾條 SQL。僅此而已。

但真正的數(shù)據(jù)庫運維遠不止這些。一個連接串連的是一個 PostgreSQL 實例，但現(xiàn)實中你面對的是什么？ 一個集群包含多個實例——主庫、從庫、離線副本、同步備份；集群之上還有水平分片；頂層可能有上百套集群分屬不同業(yè)務組。 除了數(shù)據(jù)庫自身的指標，你還需要備份狀態(tài)、高可用組件狀態(tài)、連接池指標、主機 CPU/內(nèi)存/磁盤/網(wǎng)絡指標。這些東西 全部在連接串的外面 。

一個只拿到連接串的 Agent，就像一個只能通過貓眼觀察房間的人 —— 視野極其有限。 更尷尬的是：連接串里能做的那些事，恰恰是大模型裸聊就能做得不錯的事。 你讓 Claude 或 GPT 直接看一條慢 SQL，它給出的優(yōu)化建議已經(jīng)相當靠譜了。 你做的事情 LLM 直接就能做，那你的壁壘在哪？

OtterTune 踩的坑，本質(zhì)上是一個 Runtime 問題： 它試圖在沒有運行時環(huán)境的情況下做運維。 面對一個抽象的裸 PostgreSQL 做優(yōu)化 —— 它有一個強大的大腦，但沒有手，沒有眼睛，甚至沒有身體，這就像請霍金表演體操一樣荒誕。

PS: 我知道他們開始第二輪創(chuàng)業(yè)了，這次還是做 PostgreSQL 調(diào)優(yōu)，希望他們這次能走上正路

如果 OtterTune 是反面教材，那 Manus 就是正面案例。

2025 年 3 月，Manus 橫空出世，迅速成為現(xiàn)象級產(chǎn)品。很多人研究它為什么成功，把注意力放在它積累的那些 Markdown 提示詞上，或者放在它用了哪個大模型上。

盯錯地方了

Manus 真正的核心不是提示詞，也不是大模型。它的核心是那個 虛擬機沙箱 —— 每個用戶會話都運行在一個獨立的云端 Linux 虛擬機中， 里面有完整的文件系統(tǒng)、瀏覽器、Shell 終端、代碼解釋器。Agent 在這個確定性的環(huán)境中工作，能讀寫文件、執(zhí)行代碼、瀏覽網(wǎng)頁、部署應用。

Manus 自己也說得很清楚："The power of Sandbox lies in its completeness."

正是這個完備且確定的沙箱，讓大模型的能力得以充分釋放。沒有這個沙箱，同樣的模型只是一個聊天機器人。有了這個沙箱，它變成了一個能真正完成任務的 Agent。而且 Manus 換過好幾次底層模型——從 GPT 到 Claude——效果一直在線。因為真正兜底的不是模型，是 Runtime。，脫離了這些本地環(huán)境的手腳，它就只是又一個普通的聊天機器人而已。

Manus 和 OpenClaw 的成功驗證了同一件事：

LLM 是大腦，但真正重要的是身體。

大腦、身體和確定性

Manus 的啟示可以再往下推一層。

生物學上，智能的實現(xiàn)依賴三個要素：傳感器（感知環(huán)境）、決策器（處理信息）、執(zhí)行器（作用于環(huán)境）。一個只有大腦沒有身體的生物，不叫智能體，只是缸中之腦。

Agent 也是一樣。大模型是決策器，但你還需要傳感器和執(zhí)行器 —— 也就是 可觀測性 和 可控制性。三者構(gòu)成了 Agent 的 身體。而這個身體要能正常工作，需要一個前提：確定性。

你不能把大腦丟到一個陌生的環(huán)境里，讓它操縱一條奇形怪狀的機械臂。大腦必須 “認識” 自己的身體，知道發(fā)出什么信號會產(chǎn)生什么動作，接收什么反饋意味著什么狀態(tài)。大腦和身體之間需要一套穩(wěn)定的、可預期的協(xié)議。

這就是 Runtime 的本質(zhì)：Agent 的確定性身體。

以 DBA Agent 為例，一個完整的 Runtime 意味著：

傳感器——完整的可觀測性。不只是一個連接串能看到的那點東西，而是從主機指標、連接池狀態(tài)、高可用組件心跳、備份任務進度到數(shù)據(jù)庫內(nèi)部統(tǒng)計的全棧監(jiān)控，這些信息有機地融合在一起，提供從單實例到整個數(shù)據(jù)平臺的層層視角。

執(zhí)行器——完整的可操控性。配置變更、高可用切換、備份恢復、滾動升級。不是調(diào)用別人的 API，而是直接掌控基礎設施的"形狀"。如果你只是調(diào)云廠商的接口，你的 Agent 永遠被原作者的想象力所限制。

確定性——可預測的行為和可追溯的記錄。同樣的操作，同樣的條件，同樣的結(jié)果。每一步都有記錄，每一次變更都可回滾。不確定的環(huán)境里跑不出確定的結(jié)果。

五年前老馮做 PostgreSQL 監(jiān)控的時候就發(fā)現(xiàn)了這個問題 _如果想做最好的監(jiān)控系統(tǒng)，不能只靠一個連接串。連接串確實能做一些事，但離 “做好” 差得太遠。要把可觀測性做到極致，你必須直接掌控 Runtime，直接控制基礎設施的形狀。這也是 Pigsty 從一個 PostgreSQL 監(jiān)控系統(tǒng)項目，演變?yōu)橐粋€完整的 PostgreSQL 發(fā)行版的關鍵契機。監(jiān)控如此，管控亦然，智能更是如此。

OtterTune 有大腦，沒有身體。結(jié)局是注定的。Manus 造了一個確定性的身體（沙箱），大腦的能力才得以釋放。

DBA Agent 的身體，只有三個選擇

讓我們用一個具體的 Agent 場景為例 —— DBA Agent。

什么是 DBA Agent 的身體？誰能提供 DBA Agent 的身體

第一條路：云廠商。 RDS、Cloud SQL、Azure Database——監(jiān)控、告警、備份、高可用都有。但這是別人的身體。 你的 Agent 只能在廠商畫好的圈子里活動，運維知識沉淀在廠商平臺上與 Vendor 綁定，換個云就清零。 如果你像 OtterTune 那樣寄生在云廠商的接口上做 Agent，你的設計天花板就是云廠商 API 的天花板。這不是身體，這是籠子。

第二條路：Kubernetes。 K8s Operator 理論上也能提供自動化運維能力。但 K8s 給數(shù)據(jù)庫引入了大量不必要的復雜度——存儲編排、網(wǎng)絡策略、狀態(tài)管理、CRD 抽象層層疊疊。Agent 要在 K8s 上做數(shù)據(jù)庫運維，需要理解的概念比直接管理數(shù)據(jù)庫多出一個數(shù)量級。K8s 的抽象層產(chǎn)生了巨大的阻抗，讓 Agent 離它真正要管的東西——數(shù)據(jù)庫本身——越來越遠。 這不是在給 Agent 提供身體，這是在給它套上一層厚重的太空服。

第三條路：Pigsty。 一個開源的 PostgreSQL 發(fā)行版，直接基于原生 Linux 提供全家桶級的確定性 Runtime。完整的可觀測性體系覆蓋從主機到數(shù)據(jù)庫的全棧監(jiān)控，生產(chǎn)級的高可用和自動化備份恢復，444 擴展開箱可用，整套基礎設施使用 IaC 來管理。

Pigsty 與云廠商數(shù)據(jù)庫運行時的區(qū)別：這是一套開源免費，屬于你自己的身體。 Runtime 的每一層都是開放的——Agent 可以直接讀取監(jiān)控指標、查詢?nèi)罩?、調(diào)用標準運維接口。沒有黑盒，沒有圍墻。運維知識沉淀在你自己的基礎設施上?？梢栽谌魏卧骗h(huán)境，以及你自己的筆記本到數(shù)據(jù)中心上運行。

Pigsty 與 K8s 的區(qū)別：沒有不必要的抽象層。 Agent 直接面對數(shù)據(jù)庫和操作系統(tǒng)，操作路徑短，確定性高。用比喻來說：，設施齊全但規(guī)矩多、租金貴，演完了布景帶不走。，光學會怎么開燈就要三天。Pigsty 是你自己建的劇場——設施齊全，布局簡潔，演員可以自由發(fā)揮，積累的一切屬于你。

已經(jīng)有人上臺了

清華大學的數(shù)據(jù)庫團隊兩年前已經(jīng)在做這件事。他們的 D-Bot 項目在完整的 Pigsty 運維環(huán)境中，探索 Agent 自主診斷故障、分析根因、生成修復建議的能力。選擇很有說明性：不是拿一個連接串遠程試探，而是在一個有監(jiān)控、有工具、有知識庫、有操作接口的完整 Runtime 中工作。

學術(shù)研究需要可復現(xiàn)的環(huán)境，而基礎設施即代碼天然滿足這個需求。同樣的配置部署一百次，環(huán)境都一模一樣。這正是 Agent 所需要的確定性。與此同時，我也在開發(fā) DBA Agent。誰比基礎設施的建造者更了解自己的 Runtime？一個開放的 Runtime 上，學術(shù)團隊在探索邊界，基礎設施建造者在打磨核心，社區(qū)開發(fā)者在貢獻創(chuàng)意。生態(tài)正在形成。

如果您對 DBA 智能體感興趣，Pigsty 可能是最佳的演武場。它為你提供了真實企業(yè)環(huán)境中 PostgreSQL 服務所需的一切上下文。SOTA 的 ，PITR，以及 Best of Breed 的。

龍會換代，地不會變

回到凌晨三點。

同樣的告警，但這次 Agent 運行在完整的 Runtime 上——它自己的身體里。它看到了監(jiān)控面板上的異常曲線，從日志中定位到根因，確認了集群拓撲和主從狀態(tài)，按標準流程完成了故障切換，驗證了切換后的健康狀態(tài)，生成了復盤報告。全程自動，全程可追溯，全程可回滾。

模型可能是 GPT，可能是 Claude，可能是某個開源模型，這不重要。 Agent 本身可能就是幾個簡單的 Skills 和 Claude.md ，這也不重要。Agent 時代的護城河不是更聰明的大腦，而是更確定的身體。在這個確定性的身體中，一個簡單的 CLAUDE.md 文件，就足夠讓中等智能水準的 LLM 表現(xiàn)出 中級 DBA 的水平來。

OtterTune 用 1200 萬美元證明了：沒有身體的大腦走不通。Manus 用一個沙箱證明了：給大腦一個確定性的身體，它就能創(chuàng)造奇跡。強龍來了一條又一條，每條都比上一條更強。但地頭蛇在自己的地盤上深耕日久，根基深厚。龍會換代，地不會變。

而這，才是 Agent 時代真正的護城河。

數(shù)據(jù)庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群 QQ 619377403