自托管 AI OS 深度對比：CORE 的 Gateway 遠程執行模式架構拆解

如果你仲覺得 AI OS 係一個靚啲嘅 chatbot 界面，咁你可能睇漏咗最關鍵嘅一層——執行層。2026 年嘅今日，Agent OS 呢個類別已經從「模型 router」進化到「完整嘅個人基礎設施」。喺 AgentOS、OpenClaw、Letta 呢啲項目之外，CORE（RedPlanetHQ/core）提出咗一個值得深究嘅設計：Gateway 遠程執行模式。呢篇文會從四種交互方式、時序記憶架構、50+ connectors 嘅整合邏輯，拆解 CORE 點樣用一個 Gateway 打通雲端智能同本地執行嘅鴻溝。

Gateway：AI OS 嘅最後一公里

CORE 最反直覺嘅設計決定係：佢嘅智能層喺雲端，但執行層喺你屋企。呢個唔係缺憾而係刻意嘅 architecture choice。Gateway 係一個本地 Fastify HTTP 伺服器（預設 port 7787），運行喺你嘅 laptop、Docker host 或者 Raspberry Pi 上面。佢對外暴露四種能力：browser（CDP 控制真實瀏覽器）、coding（Claude Code 同 Codex 嘅遠程 session）、exec（shell 命令執行）同 folders（檔案系統存取）。每種能力都係 slot 式設計，可以獨立開關——熄咗嘅 slot 連 HTTP route 都唔註冊，就算 security key 洩漏都攻擊唔到。

呢個設計嘅高明之處在於將安全邊界放喺架構層面，而唔係依賴 prompt 隔離。Gateway 嘅 commands 要通過 allow/deny globs 驗證，加上 built-in deny list 封殺 unsafe primitives；folder scopes 確保 coding 同 exec 工具只能喺註冊嘅目錄入面活動；browser profile 嘅 auth state 永遠留喺本地 machine。CORE 智能層永遠掂唔到你嘅 machine——佢只係透過 authenticated HTTP + WebSocket 落指令。呢種 Zero Trust 模式比起將執行邏輯塞入 cloud runtime 嘅做法，安全模型清晰好多。

四種交互唔係單純嘅 UI 選擇，而係對應唔同嘅 latency 同 attention 場景：語音適合 hands-free，Scratchpad（Ctrl+Option 快速輸入）啱 flow state，WhatsApp/Slack/Telegram 覆蓋 mobile 同 async，Chat 做主控台深度操作。每種方式最終都透過同一套 Gateway API 落地，實現「一次指令，多通道執行」。

時序記憶：唔係 RAG，而係知識圖譜

記憶層係 AI OS 嘅持久化基石。CORE 用時序知識圖譜（temporal knowledge graph）而唔係傳統 vector RAG，呢個選擇值得留意。RAG 嘅問題係語義搜尋唔擅長處理時間維度——你問「上個禮拜我同 Vincent 傾過嘅 deployment plan 係咩？」RAG 會俾返一堆相關片段但唔知邊個最新、邊個已被取代。Temporal graph 將每條記憶標註時間戳、關係類型同狀態（active/archived/superseded），支援因果查詢同時間線回溯。LoCoMo benchmark 88.24% 嘅 accuracy 說明呢個方向對 persistent agent 係有效嘅。

呢個設計對 developers 嘅啟示係：如果你嘅 AI agent 需要跨 session 記住用戶偏好、project context 同決策歷史，vector store 唔夠——你需要結構化嘅時間感知記憶層。CORE 呢 part 嘅實現值得參考，尤其係佢點樣用 graph traversal 做 associative recall 而唔係純 cosine similarity。

50+ Connectors 嘅整合哲學

Connector 唔係越多越好，而係要有統一嘅 contract。CORE 嘅 50+ app connectors（GitHub、Linear、Slack、Gmail、Sentry、Notion 等）共享同一套 tool interface，呢個 design pattern 令 skills system 可以 declarative 咁定義觸發條件而唔使為每個 connector 寫 adapter glue code。Skills 係可重用嘅自動化規則——偵測到 Sentry error 就自動開 GitHub issue、Linear ticket 完成就通知 Slack——全部經由 connector interface + Gateway 執行，唔需要額外寫 backend service。

相對於其他 agent framework 要靠 plugin 系統來擴充工具（譬如 OpenClaw 嘅 plugin marketplace 或者 LangChain 嘅 toolkits），CORE 呢種 connector 即 tool 嘅做法好處係 latency 低啲（connector 直接行喺 Gateway 同一 process），壞處係 connector 數量多咗之後要小心 process 隔離同 resource management。

對開發者嘅實戰建議

如果你打算自托管一個 AI OS，有幾個具體嘢可以參考 CORE 嘅設計：

第一，Gateway 模式值得複用——尤其係你需要 AI 存取本地資源（codebase、browser、files）嘅時候。將執行層同智能層分離，唔單止安全，仲可以獨立 scale：智能層用 cloud 嘅彈性運算，執行層用你控制嘅 hardware。

第二，記憶層揀 temporal graph 定 vector RAG 取決於使用場景。如果你嘅 agent 主要做一次性問答（「呢個 function 係做咩嘅」），RAG 夠用。但如果 agent 需要記住你嘅 workflow 習慣、project 決策脈絡、跨 session 嘅 conversation context，temporal knowledge graph 係必要嘅 infrastructure investment。

第三，connector 數量唔係競爭力——connector 嘅 composability 先係。一個好嘅 AI OS 應該俾你組合 connectors 成 automation pipeline，而唔係逐個 app 獨立整合。CORE 嘅 skills system 喺呢個方向行得幾前，值得 tight integration 嘅場景參考。