AI Coding 正在重走作業系統演化之路

Knowledge Comic 系列 — 最大技術深度，最少文字。

論點

AI Coding 工具沒有在發明新架構。它們在以 10 倍速重新發現作業系統的概念，而且順序完全一樣。

這不是隱喻。這是一個結構性的預測框架。

完整時間線

 Unix / OS 演化                               AI Coding 演化
 (1969 — 2020，約 50 年)                       (2022 — 203?，約 10 年)
 ═══════════════════                          ═══════════════════

 Phase 1: 單一 Process                        Phase 1: 單一 Session
 ────────────────────                         ───────────────────
 1969  Unix V1                                2022 Q4  ChatGPT + code
       一個終端                                         一個 context window
       一次一個 process                                 一段對話
       ed/ex 編輯器                                     Chat 作為介面
       Flat 檔案系統                                    無持久化

 Phase 2: 多 Process                          Phase 2: 多 Agent
 ──────────────────                           ────────────────
 1975  fork() + exec()                        2025 Q3  Sub-agents (Task tool)
       背景 process (&)                                 背景任務
       Pipes (A | B)                                    Agent → 結果 → main
       信號處理                                          專門化 agents
       工作控制 (fg, bg, jobs)                           Explore、code-reviewer 等

 Phase 3: IPC 與多使用者                       Phase 3: Agent Teams 與訊息
 ──────────────────────                        ──────────────────────────
 1980  BSD sockets                            2026 Q1  Agent Teams ■ 我們在這裡
       TCP/IP 堆疊                                     SendMessage（mailbox）
       Named pipes、message queues                     共享 task lists
       多使用者登入                                     Team Lead + teammates
       NFS（共享檔案系統）                               共享檔案系統

 Phase 4: 記憶體管理                           Phase 4: Context 管理
 ──────────────────                            ────────────────────
 1985  虛擬記憶體 (demand paging)              2026 Q1  Context Compaction
       Swap to disk                                    CMS checkpoint（swap to JSON）
       Page tables                                     1M context window
       記憶體保護                                       Effort tuning（資源分配）
       OOM killer                                      Max turns 限制

 Phase 5: 檔案系統成熟                         Phase 5: 狀態持久化升級
 ──────────────────────                        ──────────────────────
 1990  ext2 → ext3（journaling）               2026 H2  ??? 預測中
       File locking (flock)                             原子性 checkpoint 寫入
       Access control (ACLs)                            訊息送達保證
       /proc（process 內省）                             並行 agent 狀態存取
       Symbolic links                                   Agent 內省 API
       fsck（檔案系統檢查）                              狀態垃圾收集

 Phase 6: 資料庫層                             Phase 6: 可查詢的 Agent 歷史
 ────────────────                              ────────────────────────────
 1995  Berkeley DB（嵌入式）                    2027 H1  ??? 預測中
       Syslog（集中式日誌）                              嵌入式 DB 儲存 agent 狀態
       LDAP（目錄服務）                                  每個決策的審計追蹤
       cron（排程任務）                                  跨 session 學習
                                                        排程 agent 執行

 Phase 7: 標準化                              Phase 7: Agent 協議標準
 ─────────────                                ──────────────────────
 1998  POSIX 標準                             2027 H2  ??? 預測中
       RPM、dpkg（套件管理）                             Agent 介面標準
       共享函式庫 (.so)                                  Skill 市集
       FHS（目錄標準）                                   Skill 版本管理 + 相依性
       man pages                                        Agent 能力發現

 Phase 8: 虛擬化                              Phase 8: Agent 沙箱
 ─────────────                                ──────────────────
 2003  VMware、Xen                            2028     ??? 預測中
       虛擬檔案系統                                     沙箱化 agent 環境
       資源隔離                                         每個 agent 的 token 預算
       快照 + 還原                                      Agent 狀態快照
       chroot → jails → cgroups                        基於能力的安全性

 Phase 9: 容器與雲端                           Phase 9: 可攜式 Agent 平台
 ──────────────────                            ──────────────────────────
 2013  Docker                                 2029     ??? 預測中
       容器映像檔                                       Agent 定義（可攜式）
       Registry (Docker Hub)                            Agent 註冊表
       Cloud-native (12-factor)                         Provider-agnostic agents
       CI/CD pipelines                                  Agent CI/CD

 Phase 10: 編排                               Phase 10: Agent 編排
 ─────────────                                ──────────────────
 2014  Kubernetes                             2030     ??? 預測中
       Service mesh (Istio)                             Agent mesh
       自動擴展                                         自動擴展 agent 池
       滾動更新                                         熱交換 agent 能力
       健康檢查 + 自我修復                               Agent 健康 + 自動恢復

證據：Phase 1-4 已經發生了

Phase 1 → 2: 單一到多重

Unix 1975:
  $ command1          → 執行、結束
  $ command1 &        → 背景
  $ command1 | command2  → pipe 輸出

Claude Code 2025:
  "做這個任務"                       → 執行、結束
  Task(run_in_background=true)      → 背景
  Task(prompt="...") → result → main  → pipe 輸出

Sub-agents 就是 processes。Task tool 就是 fork()。結果回傳就是 pipe。

Phase 2 → 3: 多 Process 到 IPC

Unix 1980:
  socket() → bind() → listen() → accept()
  send(fd, message) → recv(fd, buffer)

Claude Code 2026:
  TeamCreate(team_name="dev")
  SendMessage(recipient="backend-dev", content="API 準備好了嗎？")
  // 訊息寫入 inboxes/backend-dev.json

SendMessage 就是 socket write。Inbox 就是 message queue。Mailbox 就是 /var/spool/mail。

Phase 3 → 4: IPC 到記憶體管理

Unix 1985:
  Process 需要的 RAM 超過實體記憶體
  → Page fault → 將 page swap 到 disk → 載入需要的 page
  → Process 不知道發生了什麼

Claude Code 2026:
  Agent 需要的 context 超過 window 容量
  → Context Compaction → 摘要舊 context
  → CMS: 將整個 context swap 到 checkpoint → 全新 process
  → 新的迭代不知道前一個的存在

Context Compaction 就是 demand paging。CMS 就是 swap。Checkpoint 就是 swap file。

Phase 5 正在崩壞

我們正處於 Phase 3-4（Agent Teams + Context Compaction 剛剛落地）。Phase 5 的問題已經浮現：

問題 1: 非原子寫入

Unix（journaling 之前）:
  寫入時斷電 → 檔案損壞
  重開機 fsck → 也許能救

AI Coding（現在）:
  Agent 在寫 checkpoint.json 時崩潰 → JSON 損壞
  Resume → 解析錯誤 → 從頭開始
  沒有 fsck 等價物存在

問題 2: 沒有 File Locking

Unix（flock 之前）:
  兩個 process 寫同一檔案 → 資料損壞
  Race condition → 靜默資料丟失

AI Coding（現在）:
  兩個 teammate 同時 TaskUpdate 同一 task → 後寫入者贏
  沒有 MVCC、沒有 locking、沒有衝突偵測
  Race condition → 靜默狀態損壞

問題 3: 沒有送達保證

Unix（reliable sockets 之前）:
  send() 回傳成功 → 但接收者可能已死
  應用層沒有 ACK 機制

AI Coding（現在）:
  SendMessage 回傳 success: true → 永遠
  即使接收者 process 10 分鐘前就死了
  訊息放在 inboxes/name.json → 永遠成為孤兒

問題 4: 沒有垃圾收集

Unix（tmpwatch/systemd-tmpfiles 之前）:
  /tmp 被孤兒檔案填滿
  死掉的 process 留下 pid 檔案
  沒有自動清理

AI Coding（現在）:
  ~/.claude/teams/ 累積死掉的 team configs
  inboxes/ 有來自死掉 agents 的未讀訊息
  .cms-iterate/backups/ 無限增長
  沒有清理機制

問題 5: 沒有內省

Unix（/proc 之前）:
  「Process 1234 在做什麼？」→ 沒有標準方法問
  ps(1) 直接解析 kernel 記憶體

AI Coding（現在）:
  「Teammate backend-dev 在做什麼？」→ 沒有 API
  只能收到 idle notifications（4 個欄位）
  無法檢查 agent 的當前 context 或進度
  Lead 對 peer-to-peer 通訊是盲的

這些問題的每一個都在 1985-1995 年間的 Unix 中被解決了。 解法是已知的。AI Coding 生態系只是還沒建出來。

路徑分岔的地方

對應不是 1:1。五個根本差異會讓 AI Coding 的演化走上不同的路：

分岔 1: Kernel 不可靠

傳統 OS:
  Kernel 是確定性的
  同樣 input → 同樣 output → 永遠
  Kernel 是 trusted computing base
  Kernel 之上的所有東西可以不被信任

AI OS:
  "Kernel"（model）是隨機的
  同樣 prompt → 不同 output → 永遠
  Model 會幻覺、忘記、退化
  Kernel 本身需要監控

影響：AI OS 需要在每一層都有防禦性架構，不只是在應用程式邊界。Storage layer 變成 trust anchor — 唯一不會幻覺的組件。這讓 Phase 5-6（storage 升級）在 AI OS 中比在傳統 OS 中更關鍵。

分岔 2: 每個 CPU 週期都要錢

傳統 OS:
  買完硬體後 CPU 週期基本免費
  資源管理來得很晚（cgroups: 2006）
  浪費週期不會有財務痛感

AI OS:
  每個 token = API 呼叫 = 錢
  失控的 agent 燒的是美元，不只是週期
  資源管理現在就需要，不是 Phase 8

影響：Token 預算和成本追蹤會比 OS 歷史中的資源隔離更早到來。可能是 Phase 6，不是 Phase 8。

分岔 3: 第一天就多廠商

傳統 OS:
  每台機器一個 kernel（Linux 或 Windows）
  標準化在 Phase 7 才來（POSIX, 1998）
  單一廠商主導數十年

AI OS:
  多個 model 同時可用
  Claude + GPT + Gemini 已經共存
  MCP 已經是 interop 嘗試（Phase 3！）

影響：「POSIX 時刻」會更早到來。Agent 協議標準化可能是 Phase 6，不是 Phase 7。MCP 已經是早期嘗試。

分岔 4: Agent 能推理協調

傳統 OS:
  Process 是笨的執行者
  IPC 是機械式的（bytes 通過 pipes）
  不能協商或調整協議
  協調需要嚴格的規格

AI OS:
  Agent 理解 context
  訊息是自然語言
  Agent 可以即時協商 API 合約
  協調可以是湧現的

影響：網路/編排 phases（8-10）看起來更像人類組織而非 TCP/IP。不是嚴格的協議堆疊，agent 網路可能使用語義路由 — 「把這個送給能處理認證的人」而非「送到 192.168.1.5:8080」。

分岔 5: 沒有硬體邊界

傳統 OS:
  綁在實體機器上
  擴展 = 更多硬體
  Docker 的存在因為「在我的機器上能跑」
  雲端是一個典範轉移

AI OS:
  從第一天就是 API-based
  擴展 = 更多 API 呼叫
  「在我的機器上能跑」不是問題
  已經是 cloud-native

影響：容器/雲端 phases（9-10）可能被壓縮或看起來很不同。AI 的「Docker 時刻」可能不是關於打包環境，而是關於打包 agent 能力 — 可在任何 model provider 上運行的可攜式 skill 定義。

加入分岔的修正預測

Phase 5   (2026 H2)  Storage 升級           ← 跟 OS 相同，更緊急
Phase 6   (2027 H1)  DB + 成本追蹤          ← 合併：DB + 資源管理（更早）
Phase 6.5 (2027 H2)  協議標準               ← 比 OS 更早（多廠商壓力）
Phase 7   (2028)     Agent 沙箱             ← 跟 OS 類似
Phase 8   (2028-29)  可攜式 Agents          ← 壓縮：無硬體邊界
Phase 9   (2029-30)  語義編排               ← 分岔：不是 K8s，更像市場
Phase 10  (2030+)    自主 Agent 組織         ← 全新：OS 沒有對應物

Phase 10 是類比完全斷裂的地方。 傳統 OS 從未到達 process 能形成組織、設定自己目標、互相雇用/解雇的地步。AI agents 可以。那是未知領域。

我們能超前建構什麼

基於這個路徑圖，以下是現在就能建的 vs 需要等平台的：

Phase  什麼                         現在能建？     怎麼建
─────  ────                         ──────────     ──────
 5     原子性 checkpoint 寫入        ✅ 100%       SQLite WAL mode
 5     訊息送達保證                  ✅ 100%       SQLite queue table + ACK
 5     並行狀態存取                  ✅ 100%       SQLite row-level locking
 5     狀態垃圾收集                  ✅ 100%       DB 上的清理查詢
 5     Agent 內省                    ✅ 80%        Status table + heartbeat

 6     可查詢歷史                    ✅ 100%       SQL on iteration/decision tables
 6     審計追蹤                      ✅ 100%       每個 model 決策 INSERT
 6     跨 session 學習               ✅ 90%        Self-Evolving Loop + DB queries
 6     Token 成本追蹤                ✅ 100%       每個 agent 每個 query() 計數
 6     排程 agent 執行               ✅ 100%       cron + IterationEngine

 6.5   Agent 介面標準                ⚠️ 50%        定義我們的，無法強制業界
 6.5   Skill 市集                    ⚠️ 60%        已有 skills 系統
 6.5   跨 provider interop           ⚠️ 30%        需要其他廠商參與

 7     沙箱環境                      ⚠️ 60%        Docker wrapper 包 agents
 7     Token 預算                    ✅ 80%        Budget class + per-query tracking
 7     Agent 快照                    ⚠️ 50%        Checkpoint + context dump

 8     可攜式 agent 定義             ⚠️ 40%        .claude/agents/ 是個開始
 8     Agent 註冊表                  ❌ 20%        需要生態系
 9     語義編排                      ❌ 10%        太早
 10    自主 agent 組織               ❌ 5%         未知領域

Phase 5-6 今天就有 90%+ 可建性。 那是領先平台 12-18 個月。

Phase 6.5（標準）是單一團隊能做的極限 — 可以以身作則，但標準化需要業界協調。

具體下一步

現在（2026 Q1）：
  Agent Teams 穩定化 + IterationEngine（SDK 遷移）
  └── Checkpoint class 抽象了持久化
  └── 無論後面是 JSON 還是 DB，介面不變

下一步（2026 H2）：
  Phase 5 的 SQLite 後端
  ├── iterations 表（取代 checkpoint.json）
  ├── messages 表（取代 inboxes/*.json）
  ├── agent_state 表（取代 team config）
  ├── decisions 表（審計追蹤 — Phase 6 預覽）
  └── WAL mode 開啟、原子寫入、並行存取

然後（2027 H1）：
  Phase 6 功能建在 DB 上
  ├── 跨 session 學習查詢
  ├── 每個 agent 的 token 成本追蹤
  ├── 排程執行（cron + IterationEngine）
  └── Agent 內省 API

2027 H2：
  Phase 6.5 — 發布 agent 介面規格
  ├── 文件化我們的 agent 協議
  ├── 開源 storage layer
  └── 邀請其他工具採用

2028：
  Phase 7 — agent 沙箱
  ├── Docker-wrapped agent 執行
  ├── Token 預算強制執行
  └── Agent 快照 + 還原

原則

歷史不會重複，但它會押韻。如果你知道旋律，就能提前唱出來。

Unix 演化路徑是一首 50 年的旋律。AI Coding 正以 10 倍速度哼著同一首曲子。音符一樣。順序一樣。問題一樣。

唯一的問題是：你等每個音符響起，還是在它到來之前就唱出來。

論點