AI Agent 的操作系統時刻

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

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

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

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

現在，AI Agent 正站在同一個起點。

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

一、核心框架：Agent OS 的五大子系統

在傳統計算機中，CPU 是算力來源，RAM 是臨時存儲，磁盤是持久存儲。在 Agent 世界中，我們可以找到精確的對應： LLM 是新 CPU，Context Window 是新內存，數據庫是新磁盤，Agent 是應用。

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

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

這五大子系統構成了 Agent OS 的核心骨架。接下來，我將按重要性逐一展開。

二、內存管理：最復雜也最重要的戰場

操作系統類比能帶給我們的最重要洞察是什么？——內存管理（Context Engineering）將是最復雜的戰場，也是最大的機會所在。

歷史的教訓：640KB 夠用嗎？

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

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

虛擬內存：操作系統的革命性創新

回顧操作系統歷史，虛擬內存是 Unix 最重要的創新之一。

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

這個抽象釋放了巨大的生產力——程序員不再需要關心物理內存的限制。

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

Manus 的啟示：上下文至關重要

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

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

這不是空談。Manus 團隊為此重寫了四次框架，通過反復試錯，總結出幾個關鍵實踐：

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

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

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

DeepSeek 的啟示：內存層次結構

DeepSeek 在 2026 年 1 月發表的 Engram 論文[2] 提供了另一個關鍵視角：存儲層次結構。

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

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

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

有人會說："長上下文"難道不能解決這個問題嗎？——內存不夠，加錢就好了。但即使 Context Window 變成 10M tokens，我們仍然需要智能的內存管理。

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

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

當我們討論內存管理時，一個自然的問題浮現：換出去的數據存在哪里？

在傳統操作系統中，答案是磁盤。在 Agent OS 中，目前通常是文件系統上的 Markdown 文檔，但最終的答案一定是數據庫。如果說 Context Engineering 是最復雜的技術戰場，那么數據庫則是確定性最高的商業機會。

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

數據庫在 Agent 架構中的多重角色

數據庫在 Agent 架構中要扮演什么角色？答案是：遠不只是“存數據”。

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

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

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

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

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

PostgreSQL 的上限在哪里？

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

理論上 psql 命令行功能是 bash 的超集，未必就沒有機會成為 Yet another runtime —— 這時候數據庫就不再扮演一個外部存儲，而成為編排核心。 這條路能走多遠還需要驗證，但 “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 …… 剝開花哨的外衣，內核驚人地相似。 Braintrust 的工程師直接撰文宣稱："The canonical agent architecture is a while loop with tools"。

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

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

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

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

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

I/O 管理：協議之爭的表象與本質

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

One Year of MCP, Anthropic[3]

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

?Token 開銷驚人：MCP 服務器僅工具元數據就可能消耗上萬 tokens[4]，而等效的 CLI 方案可能只需要幾百?重新發明輪子：MCP 試圖解決的"工具發現、調用、組合"問題，Unix CLI 已經優雅地做了 55 年

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

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

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

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

安全與可觀測性：信任基礎設施

當前 Agent 生態最大的安全隱患是什么？Prompt Injection（提示詞注入）——但這只是冰山一角。更深層的問題是：我們如何信任一個會自主行動的系統？

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

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

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

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

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

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

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

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

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

結語：缺失的內核

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

—— 唯獨缺少一個內核。

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

就在這時，一個芬蘭大學生在郵件列表里發了一個帖子：

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

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

2025 年的 Agent 生態，正處在同樣的時刻。

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

但我們缺少一個新的 “Agent OS Kernel” —— 一個真正能把這一切粘合起來的操作系統層： 統一的上下文調度、可恢復的進程狀態、標準化的 I/O 接口、完整的信任基礎設施與可觀測性。

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

歷史的劇本已經寫好：

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

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

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

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

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 服務器僅工具元數據就可能消耗上萬 tokens: https://www.anthropic.com/engineering/code-execution-with-mcp
[5] E2B 已經被 88% 的 Fortune 100 公司使用: https://venturebeat.com/ai/how-e2b-became-essential-to-88-of-fortune-100-companies-and-raised-21-million