Goose：把 AI Agent 從程式碼建議推進到可執行的工作台

我最近在看 AI coding agent 時，越來越覺得「能不能幫我補一段程式碼」已經不是最有區別度的問題。真正影響工作流程的，是代理能不能理解目前的專案、呼叫合適的工具、執行一連串操作，最後把結果交付回來。這也是我認為 Goose 值得觀察的原因：它不是只提供 IDE 裡的一個聊天視窗，而是把 AI agent 做成可以在桌面、終端機與 API 中運作的開源工作台。

Goose 的官方定位是通用型 AI agent。它可以用在程式開發，也可以延伸到研究、寫作、自動化與資料分析。專案同時提供 macOS、Linux、Windows 的桌面應用程式、完整 CLI，以及可以嵌入其他系統的 API；核心以 Rust 開發，並支援多個模型供應商與透過 Model Context Protocol（MCP）連接的擴充功能。這種設計讓我看到的重點不是「又一個聊天機器人」，而是把模型、工具、工作階段與權限邊界組成一個可操作的執行層。

先講結論：Goose 的價值在於把代理放進真實工作流

如果你的需求只是問問題、產生一小段程式碼，Goose 可能顯得太重；直接使用模型聊天介面或 IDE 外掛就足夠。但如果你希望代理能夠進入工作目錄、建立檔案、修改程式、執行測試，再根據結果繼續下一輪工作，Goose 的設計就有清楚的吸引力。

我會把它的價值整理成三個層次。第一層是互動介面：你可以選擇桌面應用程式，也可以在終端機透過 goose session 開始工作。第二層是工具連接：內建與外接的 extensions 讓代理不只生成文字，而是能使用瀏覽器、檔案系統或 MCP 工具。第三層是模型彈性：官方 README 列出 15 個以上的 providers，也支援透過 Agent Client Protocol（ACP）使用既有的 Claude Code 或 ChatGPT 訂閱。

這三層組合起來，才是 Goose 和一般「AI 聊天加程式碼複製貼上」流程的差別。它把代理從回答者推向操作者，但也因此必須更認真處理權限、認證、可重現性與失敗復原。

Goose 的架構可以怎麼理解

1. 模型只是決策核心，不是完整產品

Goose 不綁死單一模型。首次設定時，使用者需要選擇 provider 與模型，之後由模型理解需求、決定下一個工具呼叫，再把工具結果納入後續推理。這種架構的好處是可以依任務更換模型：日常修改可以使用成本較低的模型，複雜重構或分析再切換到能力更強的模型。

但模型彈性也帶來一個常被忽略的現實：不同 provider 對工具呼叫、上下文長度、速率限制與認證方式的支援不完全相同。因此，Goose 的使用體驗不能只用模型名稱評估。真正要觀察的是「模型能否穩定完成一個包含多步驟工具呼叫的工作」。

2. Extensions 是把 agent 接到外部世界的介面

Goose 以 extensions 管理額外能力，並可透過 MCP 連接外部服務。這讓代理可以從單純讀寫文字，延伸到查資料、操作瀏覽器、呼叫 API 或使用團隊既有工具。官方 quickstart 以 Computer Controller 為例，示範如何讓代理開啟瀏覽器並操作剛剛建立的網頁遊戲。

我認為這裡最重要的觀念，是不要把 extension 當成「多裝幾個外掛」而已。每增加一個工具，代理可以做的事情變多，風險面也同步擴張。實際導入時，應該先從唯讀工具開始，再逐步開放寫檔、執行命令與對外部系統產生副作用的能力。若團隊沒有清楚的權限分層，工具越多不一定越有效率。

3. Session 是可持續的工作單位

Goose 把一次連續對話包裝成 session。CLI 使用者可以在工作目錄中執行 goose session 開始新的工作，完成一個初步任務後，再透過設定 extension 或重新載入 session 繼續操作。這個概念比單次 prompt 更接近真實開發：需求、檔案變更、測試結果與錯誤訊息都會在同一個工作脈絡中累積。

不過，session 不代表所有工作都能自動恢復。ACP provider 的官方文件明確列出限制：目前 ACP session 不支援 Goose 的 session fork 或 resume，而且 ACP session ID 與 Goose session ID 不同，遙測欄位不一定能直接對上。這些細節提醒我，代理工作流不能只看「成功完成的示範」，也要先想好中斷後如何接手、如何重跑，以及如何留下人工可讀的變更紀錄。

實際上手：先完成一個可驗證的小任務

下面這條路徑是我認為比較穩妥的第一次嘗試。重點不是立刻讓 Goose 接管整個專案，而是先用一個可以快速檢查結果的任務，確認安裝、模型、工具與權限都正常。

第一步：安裝 CLI

官方 README 提供桌面版與 CLI 兩種入口。以終端機工作流為例，可以依官方安裝文件執行安裝腳本：

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

安裝完成後，先確認 goose 已經在 PATH 中。如果 shell 找不到指令，先不要急著重新安裝；優先檢查安裝腳本的輸出、目前 shell 的 PATH，以及是否需要重新開啟終端機。官方 quickstart 也提醒，部分平台可能出現 PATH warning，必須先處理好才能執行後續設定。

如果你不想在第一次測試時執行遠端腳本，也可以從官方 releases 下載對應平台的套件，或使用官方文件列出的 Homebrew 與桌面版安裝方式。無論選哪條路，第一次都應該以官方文件的版本與平台說明為準，不要混用不同版本的安裝指令。

第二步：設定模型供應商

在 CLI 中執行：

goose configure

接著選擇 Configure Providers，按照畫面設定 provider、認證資訊與模型。不要把 API key 直接寫進文章、shell history 或團隊共用的設定檔；應依 provider 的官方建議使用環境變數、作業系統 keyring 或登入流程。

如果你使用的是 ACP provider，概念會稍微不同：Goose 透過 ACP adapter 連接既有的 coding agent。官方 ACP 文件列出 Claude ACP、Codex ACP、Amp ACP 與 Pi ACP 等路徑，並要求先安裝對應的 CLI 或 adapter，再完成各自的登入。這種方式的優點是可以沿用既有訂閱，限制則是外部 agent 的狀態與 Goose session 不一定完全一致。

第三步：建立乾淨的測試目錄

不要第一次就把 Goose 放進最重要的產品倉庫。先建立一個空目錄，讓代理完成一個範圍小、結果容易檢查的任務：

mkdir goose-demo
cd goose-demo
goose session

接著輸入一個有明確驗收條件的需求，例如：

建立一個使用 JavaScript 的瀏覽器井字遊戲，包含 HTML 頁面、遊戲邏輯與基本樣式，並在完成後說明如何啟動與驗證。

這個任務的價值不在於遊戲本身，而在於它能同時驗證幾件事：代理是否能建立多個檔案、是否理解工作目錄、是否能執行或說明驗證步驟，以及產出的結果是否真的可在瀏覽器中運作。若代理只回答一段程式碼，卻沒有留下可執行檔案，就代表工具或權限設定還沒有完成。

第四步：逐步啟用 extension

完成第一個純檔案任務後，再設定 Computer Controller 或其他 MCP extension。官方 quickstart 示範的流程是中止目前 session，執行 goose configure，選擇 Add Extension，再加入內建的 Computer Controller，最後用 goose session -r 載入先前的工作。

這個順序很重要。我不建議一開始就把所有 extension 一次打開，因為當任務出錯時，你會很難判斷問題來自模型、provider、工作目錄、工具本身，還是權限設定。每增加一項能力，就安排一個獨立的驗證任務，並記錄它實際能讀取、修改與執行哪些資源。

Goose 最適合哪些場景

第一類是需要多步驟修改的開發任務，例如建立小型功能、補測試、執行測試後修正錯誤，或把一組重複性的檔案變更交給代理處理。這些任務的共同點是，成果不只是一段文字，而是工作目錄中的一組可檢查變更。

第二類是研究與資料整理。Goose 的定位並不侷限於寫程式；如果配置了合適的工具，它也可以把查詢、整理、產生檔案等步驟串成一個 session。這時需要特別注意來源追蹤，要求代理保存連結、輸入與輸出，而不是只接受一段看似完整的結論。

第三類是團隊想要試驗 agent 工作流，但又不想立刻鎖定單一模型或單一雲端平台。Goose 的 provider 與 extension 抽象層，提供一個可以比較不同模型、工具與認證方式的入口。這不代表所有 provider 都能無痛互換，但至少可以把比較工作放在相對一致的操作介面上。

不適合直接導入的地方

Goose 能夠執行操作，不等於應該被授予無限制權限。涉及刪除檔案、修改部署設定、寫入正式資料庫或對外發送訊息的任務，都應該加上人工確認、隔離環境與可回復機制。尤其當 extension 能夠同時操作檔案系統與網路時，prompt 中的一句模糊描述可能造成比預期更大的副作用。

第二個限制是可觀測性。代理完成任務時，看起來像是一段對話，但真正需要追蹤的是每一次模型決策、工具呼叫、檔案變更與錯誤重試。若要在團隊內使用，最好把任務拆成小步驟，要求它在每個階段回報即將執行的操作，並透過 Git diff、測試報告與工作紀錄驗證結果。

第三個限制是 session 與外部 agent 的邊界。ACP 可以讓使用者沿用既有的 Claude Code 或 ChatGPT 訂閱，但官方文件已經說明 session fork、resume 與識別碼對應仍有缺口。若工作不能中斷，或需要嚴格重現每一次執行，應先做失敗復原演練，再決定是否把 ACP 當成正式工作流的基礎。

最後是成本與模型差異。支援很多 provider 是彈性，不是品質保證。實際評估時，應建立自己的測試集，至少測量任務完成率、工具呼叫錯誤、需要人工介入的次數、執行時間與模型成本。不要因為某個 provider 在展示任務中表現很好，就直接推論它適合所有專案。

我會怎麼評估一次導入

我會先用三個小任務建立基線：一個純檔案建立任務、一個需要執行測試的修正任務，以及一個需要 MCP 或瀏覽器工具的整合任務。每個任務都要有明確輸入、驗收條件與失敗後的清理方式。

接著，我會把權限分成三層。第一層是唯讀：代理只能閱讀指定目錄與查詢資料。第二層是可修改：代理可以在隔離分支或暫存目錄寫檔，但不能碰正式環境。第三層才是需要人工核准的外部副作用，例如部署、發送訊息、付款或修改共享資料。這種分層比單純設定一個「安全模式」更容易和團隊流程對接。

最後，我會檢查代理的輸出是否能被其他人接手。好的 agent 工作流不應只留下「已完成」四個字，而應該包含修改了什麼、跑過哪些檢查、哪些地方仍不確定，以及下一步如何重現。如果 Goose 要成為團隊工具，這些紀錄的價值不會低於模型本身的回答品質。

結語：Goose 的重點不是替你聊天，而是替你完成一段工作

Goose 值得寫成一篇實作型文章，是因為它把 AI agent 的討論從模型能力拉回到工作流：如何設定 provider、如何管理 session、如何連接 extension、如何讓代理在真實目錄中完成任務，以及如何面對權限與復原問題。

我的判斷是，Goose 最適合拿來做「可控的代理工作台」實驗，而不是直接當成無人監督的自動化執行器。先從乾淨目錄與小任務開始，逐步開啟工具，保留 Git diff 與測試結果，再把成功的流程封裝成團隊規範。當你能回答「代理可以做什麼、不能做什麼、失敗後怎麼接手」這三個問題時，Goose 才真正從一個新鮮的 AI 工具，變成可以被工程團隊使用的基礎設施。

參考資料