AI Agent 的操作系統(tǒng)時刻

2025 年，編程 Agent 大爆發(fā)。Claude Code 能幫你寫代碼、跑測試、修 Bug，自主完成復(fù)雜工程任務(wù)， 堪稱 ChatGPT 橫空出世后的第二次史詩級大地震。

但仔細觀察這些 Agent 的工作方式，你會發(fā)現(xiàn)一個驚人的事實：它們的底層操作極其 “原始”。 它直接操作你的文件系統(tǒng)和終端，雖然有一些內(nèi)置的確認機制，但本質(zhì)上仍依賴 “信任模型” 而非 “隔離模型”。 這就像早期程序可以隨意覆寫任何內(nèi)存地址一樣 —— 系統(tǒng)的安全邊界，取決于程序員的自覺。

這讓我想起了 1980 年代的 DOS。

DOS 也能用——你可以在上面寫程序、編輯文檔、玩游戲。但它缺乏現(xiàn)代操作系統(tǒng)的一切： 沒有內(nèi)存保護，沒有多任務(wù)，沒有標準化的設(shè)備接口。 每個應(yīng)用都直接操作硬件，程序員要自己處理所有底層細節(jié)。

現(xiàn)在，AI Agent 正站在同一個起點。

我們花了 30 年才從 DOS 演化到現(xiàn)代操作系統(tǒng)，而 Agent 生態(tài)正在壓縮式地重演這段歷史。 本文的核心論點是：用操作系統(tǒng)的演化歷史來理解 Agent 基礎(chǔ)設(shè)施的未來。 這個類比不僅能幫我們理解現(xiàn)狀，還能預(yù)測接下來 2-3 年最關(guān)鍵的技術(shù)方向——以及最大的機會。

一、核心框架：Agent OS 的五大子系統(tǒng)

在傳統(tǒng)計算機中，CPU 是算力來源，RAM 是臨時存儲，磁盤是持久存儲。在 Agent 世界中，我們可以找到精確的對應(yīng)： LLM 是新 CPU，Context Window 是新內(nèi)存，數(shù)據(jù)庫是新磁盤，Agent 是應(yīng)用。

LLM 的上下文窗口與內(nèi)存一模一樣——每次推理完成后，所有狀態(tài)都消失了。關(guān)掉電源（結(jié)束會話），一切歸零。 這種"失憶癥"意味著：所有狀態(tài)管理都必須外部化 —— 這正是我們需要"操作系統(tǒng)"的根本原因。

在應(yīng)用與資源中間的抽象，正是我們所熟悉的"操作系統(tǒng)"。 操作系統(tǒng)是什么？是一個管理資源、提供抽象、協(xié)調(diào)各組件的系統(tǒng)，它由幾個重要的子系統(tǒng)組成：

這五大子系統(tǒng)構(gòu)成了 Agent OS 的核心骨架。接下來，我將按重要性逐一展開。

二、內(nèi)存管理：最復(fù)雜也最重要的戰(zhàn)場

操作系統(tǒng)類比能帶給我們的最重要洞察是什么？——內(nèi)存管理（Context Engineering）將是最復(fù)雜的戰(zhàn)場，也是最大的機會所在。

歷史的教訓(xùn)：640KB 夠用嗎？

1981 年，IBM PC 的設(shè)計者們認為 640KB 內(nèi)存 “應(yīng)該夠用了”。這成為計算機歷史上最著名的錯誤預(yù)言。今天，當我們說 128K 上下文“已經(jīng)很大了”時，正在犯同樣的錯誤。

上下文窗口（Context Window） 是 LLM 最稀缺的資源。128K tokens 看起來很大，但考慮到各種開銷占用： 系統(tǒng)提示詞占用 10-20K，工具定義占用 10-20K，上下文文檔占用 50-80K …… 留給實際對話的空間可能只剩小幾十K。這就像 1980 年代的 640KB 限制一樣窘迫。

虛擬內(nèi)存：操作系統(tǒng)的革命性創(chuàng)新

回顧操作系統(tǒng)歷史，虛擬內(nèi)存是 Unix 最重要的創(chuàng)新之一。

在虛擬內(nèi)存出現(xiàn)之前，程序員必須自己管理物理內(nèi)存分配。如果程序需要的內(nèi)存超過物理內(nèi)存，就只能崩潰或手動實現(xiàn)復(fù)雜的換入換出邏輯。虛擬內(nèi)存改變了這一切——它給每個程序一個"幻覺"，好像它擁有整個地址空間。操作系統(tǒng)在背后自動處理頁面置換，把不常用的數(shù)據(jù)換出到磁盤，需要時再換入。

這個抽象釋放了巨大的生產(chǎn)力——程序員不再需要關(guān)心物理內(nèi)存的限制。

在 Agent 世界，我們正需要同樣的革命。

Manus 的啟示：上下文至關(guān)重要

Manus 是 2025 年最成功的通用 Agent 之一，他們的團隊在博客 Context Engineering for AI Agents[1] 中分享了一個核心結(jié)論：

"大多數(shù) Agent 的失敗不是模型的失敗——而是 Context 的失敗。"

這不是空談。Manus 團隊為此重寫了四次框架，通過反復(fù)試錯，總結(jié)出幾個關(guān)鍵實踐：

**KV-Cache 命中率是最重要的指標。緩存命中 ≈ 模型不用重復(fù) “重新讀一遍整本書”。 在 Claude 上，緩存命中的 token 成本是未命中的 1/10，這意味著 Context 的組織方式至關(guān)重要，直接決定了 Agent 的成本和延遲。

文件系統(tǒng)作為外部記憶。 Manus 把文件系統(tǒng)當作"無限 Context"的外掛存儲。Agent 可以隨時寫入和讀取文件，相當于一個低成本的"虛擬內(nèi)存"。這是對 swap 的天然映射——當 RAM 不夠時，把不常用的數(shù)據(jù)換出到磁盤。

Todo List 作為注意力操控。 他們發(fā)現(xiàn)讓 Agent 在每一步開始時"復(fù)述"當前的 todo list，可以有效防止目標漂移。這本質(zhì)上是一種緩存預(yù)熱技巧——把重要信息預(yù)熱到高速緩存里，增加其被注意到的概率。

DeepSeek 的啟示：內(nèi)存層次結(jié)構(gòu)

DeepSeek 在 2026 年 1 月發(fā)表的 Engram 論文[2] 提供了另一個關(guān)鍵視角：存儲層次結(jié)構(gòu)。

他們發(fā)現(xiàn)了一個"U 型曲線"——最優(yōu)的資源分配是 75-80% 給"Brain"（計算），20-25% 給"Book"（記憶）。這個比例揭示了一個深刻洞察： Agent 不應(yīng)該把所有信息都塞進 Context（全放 RAM），也不應(yīng)該完全依賴外部檢索（全放磁盤），而是需要一個智能的分層架構(gòu)。

這就與計算機的存儲層級體系能完美對上

關(guān)鍵洞察是：越往上越快、越貴、越小；需要自動管理（就像 CPU 不需要程序員手動管理 L1/L2 Cache）；需要智能換入換出。

有人會說："長上下文"難道不能解決這個問題嗎？——內(nèi)存不夠，加錢就好了。但即使 Context Window 變成 10M tokens，我們?nèi)匀恍枰悄艿膬?nèi)存管理。

就像 64GB RAM 的電腦仍然需要虛擬內(nèi)存 —— 高效的資源管理本身就是 OS 的核心價值。

老馮的 64G 筆記本被 Word 吃了 200G 內(nèi)存，竟然沒立即死掉

當我們討論內(nèi)存管理時，一個自然的問題浮現(xiàn)：換出去的數(shù)據(jù)存在哪里？

在傳統(tǒng)操作系統(tǒng)中，答案是磁盤。在 Agent OS 中，目前通常是文件系統(tǒng)上的 Markdown 文檔，但最終的答案一定是數(shù)據(jù)庫。如果說 Context Engineering 是最復(fù)雜的技術(shù)戰(zhàn)場，那么數(shù)據(jù)庫則是確定性最高的商業(yè)機會。

微軟 CEO 納德拉早就看到了這個終局 —— 數(shù)據(jù)庫是 IT 的核心，所有的應(yīng)用本質(zhì)上都是數(shù)據(jù)庫的封裝層">數(shù)據(jù)庫是 IT 的核心，所有的應(yīng)用本質(zhì)上都是數(shù)據(jù)庫的封裝層。 AI 會重做一切應(yīng)用與流程軟件，但這也離不開數(shù)據(jù)庫——Agent 最終會替代掉所有的包裝，直接操作數(shù)據(jù)庫。

數(shù)據(jù)庫在 Agent 架構(gòu)中的多重角色

數(shù)據(jù)庫在 Agent 架構(gòu)中要扮演什么角色？答案是：遠不只是“存數(shù)據(jù)”。

1.長期記憶存儲：Agent 的"海馬體"——對話歷史、學(xué)到的知識、用戶偏好2.狀態(tài)持久化：Agent 的"硬盤"——Checkpoint/快照、任務(wù)狀態(tài)、恢復(fù)點3.向量索引：Agent 的"頁表"——語義檢索、相似度匹配、Context 換入決策4.協(xié)調(diào)服務(wù)：Agent 的"IPC 機制"——分布式鎖、任務(wù)隊列、事件通知5.審計日志：Agent 的"黑匣子"——所有操作的不可篡改記錄、合規(guī)、可重放

對于需要同時承擔(dān)上述五重角色的 Agent 存儲層，PostgreSQL 是目前最有競爭力的選項，原因有二：

統(tǒng)一的數(shù)據(jù)平面。 關(guān)系模型、向量嵌入（pgvector）、全文搜索、JSON、時序數(shù)據(jù)——可以在單一數(shù)據(jù)庫中使用 ACID / SQL 統(tǒng)一處理，不需要維護多套系統(tǒng)與膠水組件。

模型的原生熟悉度。PostgreSQL 是全世界最流行的數(shù)據(jù)庫，前沿 LLM 在海量 PostgreSQL 文檔上訓(xùn)練過，Agent 調(diào)用 psql 工具或者寫 PG 的 SQL 幾乎不需要額外 Schema 提示。這不是玄學(xué)，是訓(xùn)練數(shù)據(jù)分布決定的。

市場也在驗證這個方向：2025 年 、Snowflake 收購 Crunchy Data，。 Neon 披露的一個數(shù)據(jù)尤其值得注意：他們 80% 的數(shù)據(jù)庫是由 AI Agent 而非人類創(chuàng)建的。

PostgreSQL 的上限在哪里？

一種更激進，更有趣的可能性是：PostgreSQL 不只扮演存儲，而成為 Runtime 本身。 PostgreSQL 極致的可擴展性與繁榮的擴展生態(tài)，讓它已經(jīng)具備了一個 完整 Runtime 所需的幾乎所有原語。

理論上 psql 命令行功能是 bash 的超集，未必就沒有機會成為 Yet another runtime —— 這時候數(shù)據(jù)庫就不再扮演一個外部存儲，而成為編排核心。 這條路能走多遠還需要驗證，但 “Database as Runtime” 這個方向確實很有趣，這也是老馮正在探索的道路。

進程管理：表面紅海，深水無人

當前所有 Agent 框架的核心，幾乎都是同一個 while loop。

while not done:
thought = llm.think(context)
action = llm.decide(thought)
result = tools.execute(action)
context.update(result)

Think → Act → Observe → Repeat。LangGraph、CrewAI、AutoGen …… 剝開花哨的外衣，內(nèi)核驚人地相似。 Braintrust 的工程師直接撰文宣稱："The canonical agent architecture is a while loop with tools"。

當核心抽象簡單到任何本科生都能實現(xiàn)時，它就不可能成為護城河。 更致命的是，模型廠商天然擁有最好的 Runtime：OpenAI 的 Assistants API、Anthropic 的 Claude Code 本身就是頂級的 Agent 執(zhí)行環(huán)境。 云廠商也在收割：Azure Agent Loop、Google ADK、AWS Bedrock Agents——當 Runtime 成為平臺標配，獨立框架公司還能賣什么？

所以表面上看，這是一片紅海。但這里有一個認知陷阱：大家卷的那個 "Agent Loop"，根本不是真正的"進程管理"。 如果認真用操作系統(tǒng)來類比，進程管理遠不止一個 while loop。它至少包括：

?并發(fā)調(diào)度：多個 Agent 同時運行，誰先用 GPU？誰先調(diào) API？資源如何分配？?狀態(tài)持久化：Agent 跑到一半崩了，怎么從斷點恢復(fù)？?進程間通信：Agent A 的輸出要傳給 Agent B，用什么協(xié)議？共享狀態(tài)怎么同步？?優(yōu)雅終止：怎么讓 Agent "安全退出"而不是直接 kill -9？

這些問題，目前的框架幾乎都沒有好答案。原因很簡單：現(xiàn)在大多數(shù) Agent 應(yīng)用還停留在 “單 Agent、短任務(wù)、一次性執(zhí)行” 的階段 —— 就像 DOS 時代的單任務(wù)程序，根本不需要復(fù)雜的進程管理。弄個 Happy / IM 軟件 對接一下，聊天派活可能也就夠了。

但這個階段不會持續(xù)太久。當 Agent 開始變成長時間運行的后臺服務(wù)——比如一個 7×24 監(jiān)控數(shù)據(jù)庫的 DBA Agent，或者一個持續(xù)處理工單的客服 Agent —— 真正的進程管理需求就會浮現(xiàn)。屆時，誰能提供可靠的調(diào)度、恢復(fù)、通信機制，誰就能在這片"偽紅海"中找到真正的藍海。

I/O 管理：協(xié)議之爭的表象與本質(zhì)

工具調(diào)用是 Agent 與外部世界交互的接口，相當于傳統(tǒng) OS 的設(shè)備驅(qū)動。這個領(lǐng)域正在火爆，但表面的“協(xié)議之爭”可能掩蓋了更本質(zhì)的問題。 MCP 在采用度上取得了巨大成功。 Anthropic 稱已有超過 10,000 個活躍 MCP 服務(wù)器，每月 9,700 萬次 SDK 下載，并于 12 月捐贈給了 Linux 基金會。

One Year of MCP, Anthropic[3]

但采用度不等于技術(shù)先進性。MCP 的成功很大程度上是因為它填補了一個“易用性”的空白 —— 讓非技術(shù)用戶也能給 Agent 接入工具。 然而從架構(gòu)視角看，它可能走了彎路：

?Token 開銷驚人：MCP 服務(wù)器僅工具元數(shù)據(jù)就可能消耗上萬 tokens[4]，而等效的 CLI 方案可能只需要幾百?重新發(fā)明輪子：MCP 試圖解決的"工具發(fā)現(xiàn)、調(diào)用、組合"問題，Unix CLI 已經(jīng)優(yōu)雅地做了 55 年

CLI 的優(yōu)勢被嚴重低估了。 所有前沿模型都在海量的 CLI 文檔、man pages、Stack Overflow 上訓(xùn)練過。 當你讓 Claude 用 grep、psql、curl，它幾乎不需要額外的 Schema 定義 —— 這些工具的用法已經(jīng)"內(nèi)化"在模型權(quán)重里了。 更重要的是，CLI 天然符合 Unix 哲學(xué)：文本流、管道組合、單一職責(zé)。這正是 Agent 需要的可組合性。 Unix 生態(tài)已經(jīng)有了 55 年的積累，我們應(yīng)該站在巨人的肩膀上，而不是另起爐灶。

但 CLI 也不是完美的終點。 它有幾個致命問題：輸出格式不一致（有的 JSON、有的表格、有的純文本）、錯誤處理五花八門、缺乏標準化的發(fā)現(xiàn)機制。 這就是為什么 Skills 作為一種"CLI 使用指南"出現(xiàn)了 —— 它本質(zhì)上是在彌補 CLI 文檔不夠 Agent-friendly 的問題。

我的判斷是：最終的贏家不會是 MCP，也不會是裸 CLI，而是 “Agent-native CLI” —— 輸出結(jié)構(gòu)化、錯誤碼標準化、自帶發(fā)現(xiàn)機制的命令行工具。 設(shè)想一下：每個命令都有 --json 輸出選項，錯誤碼遵循統(tǒng)一的語義（如 HTTP 狀態(tài)碼）， 自帶 --desc 參數(shù)輸出機器可讀的能力描述。 這不需要發(fā)明新協(xié)議，只需要讓現(xiàn)有工具變得更規(guī)范 —— 就像 RESTful API 沒有發(fā)明 HTTP，只是讓它更有章法。

老馮昨天發(fā)布了 PostgreSQL 的 CLI 工具 v1.0，以及收錄/介紹 PG 擴展能力的 ，在 PG 生態(tài)里踐行這條道路。

安全與可觀測性：信任基礎(chǔ)設(shè)施

當前 Agent 生態(tài)最大的安全隱患是什么？Prompt Injection（提示詞注入）——但這只是冰山一角。更深層的問題是：我們?nèi)绾涡湃我粋€會自主行動的系統(tǒng)？

Prompt Injection 是 AI 時代的 Buffer Overflow。 傳統(tǒng)的緩沖區(qū)溢出是因為程序沒有區(qū)分 “指令” 和 “數(shù)據(jù)”，攻擊者可以在數(shù)據(jù)區(qū)寫入指令讓 CPU 執(zhí)行。Prompt Injection 本質(zhì)上是同樣的問題：LLM 沒有在架構(gòu)層面區(qū)分 “System Prompt（指令）” 和 “User Input（數(shù)據(jù)）” 。一個惡意的用戶輸入——甚至是 Agent 讀取的一個惡意網(wǎng)頁——就可以劫持 Agent 的行為。

這個類比揭示了一個殘酷的現(xiàn)實：Buffer Overflow 花了幾十年才有了硬件級別的緩解方案（NX bit、ASLR、Stack Canary）。Prompt Injection 目前沒有任何架構(gòu)級別的解決方案——我們只能靠“請不要做壞事”的 prompt 和各種啟發(fā)式檢測。這不是一個穩(wěn)定的平衡態(tài)。

沙箱是必要的，但遠遠不夠。 E2B 已經(jīng)被 88% 的 Fortune 100 公司使用[5]，F(xiàn)irecracker 微虛擬機被 Manus 等產(chǎn)品采用。沙箱的邏輯是"即使 Agent 被騙了，它也造不成太大傷害"。這是對的，但它解決的是"限制能力"，而不是"理解行為"。這就是為什么可觀測性可能比沙箱更重要。

想象一個場景：你的 Agent 在沙箱里安全地運行了一周，沒有觸發(fā)任何告警。但你完全不知道它做了什么決策、為什么做這些決策、有沒有被惡意輸入試探過。這種"安全"是虛假的——你只是不知道自己不知道什么。真正的信任需要三層基礎(chǔ)設(shè)施：

可觀測性的核心是 “決策溯源”：Agent 看到了什么輸入？它的 reasoning 過程是什么？它為什么選擇了這個 action 而不是那個？ 這些信息不僅對安全至關(guān)重要，對調(diào)試和改進同樣不可或缺。當 Agent 出錯時，你需要能夠回放整個決策過程，就像數(shù)據(jù)庫的 WAL 讓你可以重放事務(wù)一樣。

審計日志是合規(guī)剛需。 金融、醫(yī)療、政府——這些行業(yè)對審計有嚴格要求。當一個 Agent 替客戶做了交易決策，當一個 Agent 給出了醫(yī)療建議，監(jiān)管機構(gòu)會問： 它為什么這么做？依據(jù)是什么？這不是可選項，而是市場準入的門檻。

我預(yù)測：2026-2027 年，“Agent 可觀測性” 會成為一個獨立的賽道，就像 APM（應(yīng)用性能監(jiān)控）在云原生時代的爆發(fā)一樣。誰能提供完整的 Agent trace——從輸入到推理到行動到結(jié)果——誰就能在企業(yè)市場占據(jù)關(guān)鍵位置。

沙箱解決的是"不信任"的問題，可觀測性解決的是"建立信任"的問題。兩者缺一不可，但后者的商業(yè)價值可能更大。

老馮最近剛為 ，可以看到它決策操作的完整詳情。

結(jié)語：缺失的內(nèi)核

1991 年，GNU 項目已經(jīng)運轉(zhuǎn)了八年。Richard Stallman 和他的追隨者們構(gòu)建了一整套自由軟件工具： GCC 編譯器、Emacs 編輯器、Bash shell、coreutils……幾乎涵蓋了操作系統(tǒng)的方方面面。

—— 唯獨缺少一個內(nèi)核。

GNU 自己的內(nèi)核 Hurd 陷入了無盡的設(shè)計爭論，遲遲無法完成。所有的工具都已就位，卻缺少那個把一切粘合在一起的核心。

就在這時，一個芬蘭大學(xué)生在郵件列表里發(fā)了一個帖子：

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)..."

他寫的那個"業(yè)余愛好"，填補了最后一塊拼圖。GNU 的工具加上 Linux 的內(nèi)核，構(gòu)成了我們今天所說的 GNU/Linux —— 云時代的基石。

2025 年的 Agent 生態(tài)，正處在同樣的時刻。

我們有了大量的"工具"：LangChain、CrewAI、AutoGen 等框架解決了任務(wù)編排；MCP、Skills 解決了工具調(diào)用； PostgreSQL 解決了持久化存儲；各種 RAG 方案解決了知識檢索；E2B、Firecracker 解決了安全隔離……

但我們?nèi)鄙僖粋€新的 “Agent OS Kernel” —— 一個真正能把這一切粘合起來的操作系統(tǒng)層： 統(tǒng)一的上下文調(diào)度、可恢復(fù)的進程狀態(tài)、標準化的 I/O 接口、完整的信任基礎(chǔ)設(shè)施與可觀測性。

這個內(nèi)核也許正躲在某個人的 side project 里，就像 1991 年的 Linux 一樣——不起眼，沒有引發(fā)關(guān)注，被作者自己稱為 “只是個愛好”。但它將成為未來。

歷史的劇本已經(jīng)寫好：

?內(nèi)存管理將是最復(fù)雜的技術(shù)戰(zhàn)場——誰能讓 Context 像虛擬內(nèi)存一樣透明地換入換出，誰就能定義下一代基礎(chǔ)設(shè)施?數(shù)據(jù)庫是確定性最高的商業(yè)機會——PostgreSQL 不僅是存儲，更有潛力成為 Runtime?進程管理表面紅海，深水無人——當 Agent 成為長期運行的服務(wù)，真正的調(diào)度和恢復(fù)需求才會浮現(xiàn)?I/O 的終局不是新協(xié)議，而是 Agent-Native CLI —— 55 年的 Unix 哲學(xué)不會被輕易顛覆?信任層將成為企業(yè)市場的入場券 —— 沙箱是底線，可觀測性才是關(guān)鍵

真正的分水嶺不是模型變得更強，而是 系統(tǒng)能力的補齊 。這套東西一旦成型，Agent 才會從 “會寫代碼的玩具” 變成 “可以托付業(yè)務(wù)的進程”。

誰會寫出 Agent 時代的 Linux 內(nèi)核？我不知道。也許是某個小作坊， 說不定是石破天老爺子的 DBOS，或者是老馮的 Pigsty PG 集裝箱？ —— 這是一個充滿機會與可能性的時代，在歷史的轉(zhuǎn)折節(jié)點上，一切皆有可能。

1980 年代，有人在車庫里寫 DOS 程序；1990 年代，有人在宿舍里寫 Linux 內(nèi)核。 202x 的某個深夜，也許正有人在某個終端里，敲下 Agent OS 的第一行代碼。 誰在構(gòu)建這些基礎(chǔ)設(shè)施，誰就在定義下一個時代。

References

[1] Context Engineering for AI Agents: https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
[2] Engram 論文: https://github.com/deepseek-ai/Engram
[3] One Year of MCP, Anthropic: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
[4] MCP 服務(wù)器僅工具元數(shù)據(jù)就可能消耗上萬 tokens: https://www.anthropic.com/engineering/code-execution-with-mcp
[5] E2B 已經(jīng)被 88% 的 Fortune 100 公司使用: https://venturebeat.com/ai/how-e2b-became-essential-to-88-of-fortune-100-companies-and-raised-21-million