Goose：原生支援 MCP、在你機器上執行、能與任何帶伺服器的服務對話的 AI 代理

👁️ — 次瀏覽

Goose 是一款採用 Apache-2.0 授權的通用型 AI 代理（CLI、桌面、API），在你自己的機器上執行。新能力來自 Model Context Protocol 擴充，而非封閉的外掛商店；其治理權現已歸屬於 Linux 基金會。

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

它是什麼

Goose 是一款通用型、在本機執行的 AI 代理，以 CLI、原生桌面應用，以及可嵌入的 API 三種形態提供。它不只是自動完成或一個聊天框：它會執行 shell 指令、編輯檔案、執行程式碼，並朝著你用自然語言給定的目標串起多步驟工作流程。其儲存庫上的一行標語是：「your native open source AI agent — desktop app, CLI, and API — for code, workflows, and everything in between.」

本專案以 Apache-2.0 授權開源，主要以 Rust 撰寫。它始於 Block（Square／Cash App 的母公司），代號為「goose」，但在一項值得注意的治理動作中，它後來已遷移至 Linux 基金會旗下的 Agentic AI Foundation（AAIF） —— 正式儲存庫現位於 aaif-goose/goose。撰文當下，該 GitHub 儲存庫約有 48,100 顆星，而最新版本 v1.37.0 的日期為 2026 年 6 月 3 日 —— 就在我查看的前幾天，所以這是一個活躍、快速演進中的專案。它連接廣泛的模型供應商（Anthropic、OpenAI、Google、Ollama、OpenRouter、Bedrock 等），而不會把你綁死在單一廠商。

這套架構為何有趣

它最關鍵的押注是：能力應該來自一個開放協定，而非專有的外掛目錄。Goose 是 Model Context Protocol（MCP）—— 用來把工具與資料暴露給代理的開放標準 —— 最早期、也最深入的採用者之一。其儲存庫宣稱可透過 MCP 連接 70 多個擴充，而其後果影響甚大：任何提供 MCP 伺服器的服務 —— GitHub、Jira、Slack、一個資料庫、一個監控儀表板 —— 都能被 Goose 使用，而維護者無須為每一個分別撰寫量身打造的整合。代理觸及的範圍會隨著生態系成長而成長，而非受限於某一家公司的路線圖。

第二個結構性選擇是治理。把專案移交給一個中立的基金會，意味著它的方向不再受制於單一廠商的商業優先順序 —— 如果你打算把基礎設施押注在某個代理上，這是一個實在的考量。比較這兩種姿態：

誠實的解讀：讓 Goose 強大的那份開放性，同時也擴大了它的波及範圍。一個會執行 shell 指令、並連接任意第三方 MCP 伺服器的代理，能觸及的東西相當多，這正是為何信任邊界值得深思。

安裝與執行

專案自己的網站與 README 上所列的安裝指令，是一段把 CLI 透過 curl 引導安裝的 bash：

# install the goose CLI (verbatim from goose-docs.ai / the repo README)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# then configure a provider + model and start a session
goose configure
goose session

一如所有的 curl | bash 安裝器，若你有任何不確定，在把它導入 shell 之前先讀一讀腳本 —— 它是從專案的 GitHub releases 抓取的，但這個習慣值得保持。

實務筆記

我實際上會這麼做：先用一組刻意精簡的 MCP 擴充把 Goose 架起來，而不是一口氣裝上整個目錄。讓人忍不住在第一天就把所有東西都接上去 —— GitHub、Slack、你的資料庫、你的雲端。我反而會先在一個可拋棄的分支上，從內建的 developer（shell + 檔案編輯）擴充開始，觀察代理如何規劃與行動，唯有等我搞懂某個遠端 MCP 伺服器需要哪些憑證與權限範圍後，才把它加進來。你每啟用一個擴充，就是新增一片攻擊面，以及一組新的祕密放進你的環境；對待「加一個 MCP 伺服器」要像對待新增一個相依套件一樣謹慎。可中斷的工作階段在此有幫助 —— 前幾次執行時請把手放在方向盤上，而不是讓它對任何要緊的東西放任自跑。

我會特別在一項任務橫跨多個工具、而不只是檔案時，動用這類代理：重現一次 CI 失敗、查詢一個真實的資料儲存、開出 PR、在某個頻道發個通知。這種跨工具的觸及範圍，正是 MCP 模型勝過純編輯程式碼代理之處。

被忽略的角度

標題是「開放的代理」，但更安靜、影響也更深遠的轉變在於：鎖定效應被搬到了哪裡。藉由把代理與任何單一模型廠商、以及任何單一外掛商店解耦，Goose 與其說消除了相依風險，不如說把它重新安置到了 MCP 生態系本身 —— 那些伺服器、它們的驗證模型，以及它們的維護健康度。一個把工作流程建構在十幾個第三方 MCP 伺服器之上的團隊，是用廠商鎖定換來了一種瀰散的供應鏈相依：每個伺服器都是別人發布的程式碼，有自己的更新節奏、安全態勢，以及淪為無人維護的機率。這可說是一個更好的處境 —— 開放標準勝過封閉標準 —— 但這並非毫無相依。在 Goose 上勝出的團隊，會把已啟用的 MCP 伺服器當成正式環境相依來對待：把它們鎖定版本、加以審查，並清楚知道哪些是自己離不開的。由基金會治理，解決的是代理本身的中立性；它對你栓在它上面那條長尾擴充的存續性，隻字未提。