MCP

Archestra 企業 AI 平台：適合誰與第一次 Docker 啟動指南

想在自架環境統一承接 MCP 接入的團隊，適合先用 Archestra 的 Docker quickstart 試一次；但啟動命令會掛載宿主機 /var/run/docker.sock 並寫入本地資料卷，archestra/platform:latest 通常執行 release candidate，試之前先接受這兩點。

官方來源 · Archestra

安裝

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

適合誰

  • 官方定位是「一體化開源企業 AI 平台」：同時承擔 MCP registry、gateway 與 orchestrator，而不是單一用途的 MCP server。適合的形態是：團隊在自己機器上自架一套平台，把使用者、agent 以及 Claude / Codex / Cursor 用戶端統一指向同一個 URL，工具呼叫由平台統一承接，用戶端只認一個入口。
  • 它的 MCP gateway 採用 OAuth + On-Behalf-Of，讓工具以使用者本人身分執行，而不是共享服務帳號；在意每次呼叫歸屬到人的團隊是明確受益者。
  • 判斷口徑：如果你的問題只是「某個用戶端缺一個工具」，先找單一 MCP server 就夠了；要統一管理多個服務、多個用戶端、多種身分時，才輪到平台層。
  • 適合的環境：本機或內網可跑 Docker，且願意評估 socket 掛載代價的團隊；quickstart 把埠綁在回送位址，適合先在單機試，確認能接受副作用後再長期跑。
  • 執行前提：本機要有 Docker。證據沒有給出最低資源配置、支援的作業系統範圍，也沒有提 Docker 以外的執行方式，這些尚未確認。

3 分鐘完成第一次嘗試

  • 動作前先確認你接受兩個官方明示的副作用：其一，命令會掛載宿主機的 /var/run/docker.sock，容器因此可以操控宿主機的 Docker daemon；其二，映像檔的 latest 標籤指向最新的 release，通常執行的是 release candidate。這兩點寫在官方說明裡，評估時就要算進去，不是部署後才處理的細節。
  • 首次啟動也不是唯讀操作：具名卷 archestra-postgres-data 與 archestra-app-data 會把資料庫資料和應用資料寫進本機 Docker 卷；官方沒有給出對應的清理或撤銷命令，重複實驗之間舊資料是否影響新啟動，證據也未說明，別在存有重要資料的宿主機上隨手試。
  • 接受後再執行官方快速啟動命令：
docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest
  • 成功訊號能確認到這一層：容器保持運行，兩個埠只綁定在 127.0.0.1 的本機回送位址；quickstart 明確要求的設定就是 ARCHESTRA_QUICKSTART=true 加這組埠與掛載。埠只綁在回送位址，預設只有本機能存取；遠端接入要怎麼設定，證據未提及。
  • 下一步是把 Claude / Codex / Cursor 指向這一個 URL；URL 的具體取值命令裡沒有包含，要等平台啟動後從平台側確認。首次登入怎麼完成，同樣證據未提及。

使用案例

  • 案例一：多用戶端統一入口。場景：團隊裡同時有人用 Claude、Codex 與 Cursor，不想為每個用戶端分別接入 MCP。做法：按上文快速啟動平台，把用戶端指向 Archestra 的同一個 URL。可期待：工具呼叫經 MCP gateway 按使用者本人身分執行，同一套工具在三個用戶端走同一個入口。邊界：平台側具體能接哪些服務，證據沒有給清單，接入前先確認你要用的服務在其中。
  • 案例二：不落共享服務帳號。場景：團隊不接受所有工具呼叫都記在一個共享服務帳號名下。用的是 gateway 的同一套身分機制。做法：接入後核對工具是否以使用者本人身分執行；如果現在用共享帳號跑自動化，可以前後對比。能確認到的：官方說法即如此；帳號設定介面與呼叫日誌長什麼樣，證據沒有提到，不要預設它們存在。
  • 兩個案例的差別：案例一驗證入口統一，案例二驗證身分歸屬，可以先後各試一次。

使用邊界

  • 讀寫性質：首次啟動即寫入本地狀態（兩個具名卷）；socket 掛載讓容器具備操控宿主機容器的能力，這是最重的副作用，評估時要單獨考慮。
  • 憑證與身分：gateway 依賴 OAuth，提供方如何設定、是否必須先接入身分來源，證據未說明，尚未確認。
  • 用戶端與平台的關係：官方說法是讓使用者、agent 或用戶端指向一個 URL，其餘由平台承接；各用戶端需要什麼版本或外掛程式，證據未提及。
  • 版本邊界：官方說法是生產部署應固定確切版本標籤，latest 通常對應 release candidate，不要拿它直接承擔正式負載。
  • 動作順序：先接受 socket 掛載與版本兩件事，再執行命令；首試優先在本機回送環境完成，不要直接對外開放。
  • 尚未確認的關鍵資訊：資源佔用、升級與回滾步驟、資料備份方式、平台內各 MCP 工具的讀寫聲明、初始憑證策略，證據均未覆蓋；首試環境不要放入真實資料。沒有找到說明不等於沒有風險，結論以官方文件為準。