Phantom：把一台電腦交給 AI 之後，你要面對的架構取捨
An AI co-worker with its own computer. Self-evolving, persistent memory, MCP server, secure credential collection, email identity. Built on the Claude Agent SDK.
秒懂
- 它是什麼？
- Phantom 是一個跑在專屬主機上的 AI 協作者，透過 Slack、網頁聊天與 email 對外溝通，並在自身的 Docker 環境裡安裝軟體、建立資料管線、產生新工具。它的價值與風險來自同一個設計決定：容器掛載了 /var/run/docker.sock。
- 適合誰用？
- 如果你需要的是一個長期駐留、能自行安裝套件與累積記憶的協作者，而且你手上有一台可以犧牲的獨立 VM，Phantom 的架構是對的：docker-compose.user.yaml 加上 .env 就能起步，health 端點在 http://localhost:3100/health。如果你只有個人工作站，或無法接受容器對 Docker daemon 具備 root 等效權限，就不要用預設的 compose 檔。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 91 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「每次對話都從第一天開始」
多數 agent 的狀態活在對話串裡。關掉分頁，上下文就沒了，下一次見面等於重新自我介紹。Phantom 的解法不是把對話紀錄存得更久，而是給 agent 一台自己的機器：README 的說法是 give the AI its own computer，你的筆電維持是你的，agent 的工作區是它自己的。
這個定位決定了它的適用對象。它適合需要一個長期存在、會隨時間累積工作成果的角色，例如持續盯著某個資料集、某套基礎設施，或某個固定流程的人。它不適合只想問答、不想維運任何服務的人，因為 Phantom 不是一個函式庫，而是一組會持續佔用 CPU、記憶體與磁碟的常駐服務。
README 舉了三個「production Phantom 實際做過的事」：在自家 VM 上安裝 ClickHouse、載入 2007 到 2021 年的 Hacker News 資料集共 2,870 萬列，並把查詢 API 註冊成 MCP 工具；被問到能否在 Discord 上對話時，它先說沒有支援，接著說明 Discord Bot API 的流程、提供安全提交 token 的連結，最後自己起了容器上線；以及發現一個只有 3 顆星的開源監控專案 Vigil，把它接進既有的 ClickHouse，做出每 30 秒同步一次的儀表板。這三段的共同點不是「AI 很強」，而是 agent 有能力在自己的機器上留下可重複使用的基礎設施。
機制：Claude Agent SDK、MCP 工具與 Qdrant 記憶
從 repository 的組成可以看出三層。最底層是執行環境，Docker 容器內跑 TypeScript 寫的 agent 主體，旁邊還有 Qdrant 負責記憶、Ollama 負責拉 embedding 模型。中間層是 Claude Agent SDK，agent 的推理與工具呼叫走這條路。最上層是介面，Slack、Telegram、Email、Webhook 四種 channel 出貨時就有，網頁聊天在 /chat。
MCP 在這裡的角色值得單獨看。README 描述 ClickHouse 那段時說，agent 把自建的 REST API 註冊為 MCP 工具，理由是「未來的 session 可以用，其他 agent 也可以查」。這句話點出 Phantom 的自我演化不是改自己的程式碼，而是把成果包成工具掛回工具清單。工具一旦註冊，就成為跨 session 的資產，記憶與能力分開存放。
provider 的抽象放在模型這一側。README 說出貨支援七家：Anthropic 為預設，另有 Z.AI、OpenRouter、Ollama、vLLM、LiteLLM，以及任何相容 Anthropic Messages API 的自訂端點。關鍵句是「主 agent 與每一個 evolution judge 都走同一個 provider」。也就是說，自我演化的評審流程與主要對話共用同一個大腦，換模型是整體更換，不是局部替換。
部署：三個 curl、一個 .env、一個 health 端點
官方推薦 Docker 路線，步驟寫得很直白：
curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/docker-compose.user.yaml -o docker-compose.yaml curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/.env.example -o .env docker compose up -d
接著編輯 .env，填入 ANTHROPIC_API_KEY、Slack token 與 OWNER_SLACK_USER_ID。README 說明啟動後 Qdrant 會起來負責記憶，Ollama 會拉 embedding 模型，agent 隨後開機，健康檢查在 http://localhost:3100/health。Slack 設定完成的話，它準備好時會主動 DM 你。要寄信則再加 RESEND_API_KEY。
模型切換是 YAML 層級的事。phantom.yaml 裡指定 model 與 provider 區塊，例如 type: zai、api_key_env: ZAI_API_KEY，再用 model_mappings 把 sonnet 對應到 glm-5.1，然後把 ZAI_API_KEY 放進 .env 重啟。README 強調 Anthropic 仍是預設，既有部署不需改設定。
這裡有個容易被忽略的細節：model_mappings 用的是角色名稱（sonnet）而非具體型號，所以換供應商時改的是映射表，不是散落在程式各處的模型字串。對多環境部署來說這是實務上的好處。
Docker socket：整個設計裡最需要停下來想的十秒
docker-compose.yaml 把 /var/run/docker.sock 掛進 Phantom 容器，理由是它需要生成兄弟容器，例如執行沙箱化的程式碼。README 自己把代價寫清楚了：這個 socket 等於給容器對 Docker daemon 的 root 等效權限，被入侵的 Phantom 行程可以建立、修改或銷毀主機上的任何容器。
官方給的緩解方式是跑在專屬機器或 VM 上，不要放在個人工作站。這個建議是對的，但它同時說明了一件事：Phantom 的安全邊界不在容器內，而在容器外那台機器的隔離程度。你把 Phantom 放在哪裡，決定了它出事時波及的範圍。
這裡沒有任何中介層。沒有代理 socket 的守門程式，沒有容器建立的許可清單，README 也沒有提到這類機制。所以「agent 未經許可就建立基礎設施」既是賣點也是風險面：同一個能力讓它能自己裝 ClickHouse，也讓它在被操縱時能對主機做同樣的事。要採用就得接受這個等價交換，而不是期待有設定可以把它關掉。
什麼情況下 Phantom 是錯的工具
第一種是單次、無狀態的工作。如果你的需求是「讀這份文件、產出摘要」，Phantom 的常駐服務、Qdrant 索引與 Ollama embedding 全是額外成本，換來的持久記憶你用不到。
第二種是無法提供獨立主機的環境。既然官方明確要求專屬機器或 VM，那麼在共用工作站、CI runner 或與其他服務混跑的節點上部署，等於同時違反官方建議又放大了 socket 的爆炸半徑。
第三種是對行為可預測性要求很高的流程。README 描述的行為模式是 agent 自行判斷什麼有用就去做，ClickHouse 那段寫得很直接：「沒有人要求它建這些，它判斷分析有用，就把整個技術棧建起來。」對探索型任務這是優點，對需要逐字審批的合規流程就不是。
還有一個材料本身留下的空白：README 沒有提供升級路徑。專案版本標示為 0.20.2，這種 0.x 階段的常駐服務，資料格式與設定鍵都可能變動，但文件沒有說明既有部署該怎麼升。這件事在決定長期使用前必須自己查證。
跟單純的聊天型 agent 差在哪裡
常見的替代做法是把 agent 接進既有的聊天工具，用對話歷史或外部向量資料庫保存記憶，工具則由開發者事先寫好、註冊進框架。這種架構的優點是邊界清楚：agent 只能呼叫你給它的工具，跑在你的應用程式行程裡，出事時影響範圍大致等於那個應用程式。
Phantom 走的是另一條路。工具不是事先寫好的，agent 可以在自己的機器上安裝軟體、寫 API、再把 API 註冊成 MCP 工具。記憶不是外掛的向量庫，而是伴隨服務 Qdrant。介面不是你的應用程式，而是 Slack、Telegram、Email、Webhook 與 /chat。
差別的核心是「誰擁有執行環境」。傳統做法裡執行環境是你的，agent 是訪客；Phantom 裡執行環境是它的，你只是透過 Slack 跟它說話。這個反轉帶來的能力上限明顯更高，但同時把維運責任從「管一個應用程式」變成「管一台會自己動的機器」。選擇哪一邊，取決於你要的是可控性還是累積性，這兩者在這個設計裡無法同時最大化。
授權、維運成本與採用判斷
授權是 Apache-2.0，寬鬆授權，允許商用與修改，附帶專利授權條款。README 沒有提到任何額外限制或商業授權分岔，但也沒有說明商標使用規範，這部分若有對外品牌需求要自行確認。本文不構成法律意見。
維運成本要從服務數量算。一個 Phantom 部署至少牽涉三個常駐元件：agent 本體、Qdrant、Ollama。再加上它自己生成的兄弟容器，以及像 ClickHouse 這類它可能安裝的資料庫，實際佔用會隨使用時間上升。README 沒有給資源規格建議，這是評估時要自己量的第一件事。
升級方面，材料只給了版本號 0.20.2 與 Docker image 的拉取方式，沒有 changelog 或遷移指南可查。對一個會累積記憶與自建工具的系統來說，這代表升級風險集中在資料層而非程式層，備份 Qdrant 的資料量與確認工具註冊表的格式，會比讀 release note 更實際。
判斷的收斂點很簡單：Phantom 把「AI 有自己的電腦」這件事做成了可部署的產品，代價是你要真的給它一台電腦，並且接受那台電腦上的 Docker daemon 對它是敞開的。能接受這個前提，它的持久記憶與自我擴充就是真實可用的；不能接受，任何設定都補不回來。
編輯結論
如果你需要的是一個長期駐留、能自行安裝套件與累積記憶的協作者，而且你手上有一台可以犧牲的獨立 VM，Phantom 的架構是對的：docker-compose.user.yaml 加上 .env 就能起步，health 端點在 http://localhost:3100/health。如果你只有個人工作站，或無法接受容器對 Docker daemon 具備 root 等效權限，就不要用預設的 compose 檔。導入前先確認三件事：Phantom 是否真的跑在隔離主機上；provider 區塊指向哪個模型與 api_key_env；以及 Qdrant 與 Ollama 這兩個伴隨服務的資源佔用是否符合你的機器規格。README 沒有提供升級路徑與版本遷移說明，這是要自己驗證的部分。
社群筆記