📌 本文重點
- goose 是用 Rust 寫的開源 AI Agent 框架
- 讓 LLM 真的能跑指令、改檔案、寫測試而不只聊天
- 可接任意 LLM，並透過 workflow 自動化多步驟任務
- 很適合 DevOps / 開發者做日常開發與部署自動化
用一句話說清楚：goose 是一個用 Rust 寫的開源 AI Agent 框架，可以讓 LLM 不只聊天，而是真的幫你在電腦上安裝套件、跑指令、改程式碼、寫測試，變成一個可以自動執行任務的「全能小幫手」。
GitHub 專案：https://github.com/aaif-goose/goose
goose 和一般聊天機器人有什麼不同？
一般 ChatGPT / Claude 類工具，多半停在「給你建議」：
- 產生程式碼片段
- 幫你想測試案例
- 告訴你下一步可以怎麼做
goose 的差別在於：它可以自己動手做。
透過 goose，你可以讓模型：
- 在你的環境裡 執行殼層指令（shell commands）
- 直接修改專案檔案、重構程式碼
- 跑測試、根據結果再修正
- 用 plugin / tool 的形式接上你自己的 API 或腳本
換句話說，它比較像一個「可編程的 AI 工具人」，而不是純聊天機器人。
💡 關鍵： goose 不只回覆文字，而是能在你的實際環境中「讀檔案、下指令、改程式」，真正把建議變成動作。
核心功能：你可以拿 goose 來做什麼？
1. 調用殼層指令：讓 LLM 幫你按命令行上的按鈕
goose 內建「可以執行 shell 指令」的能力。
你可以叫 agent 做這些事：
- 安裝套件：
apt-get,brew,pip,cargo… - 拉專案：
git clone、切分支、pull 最新版 - 跑工具：
npm test、cargo test、pytest、make build
你要做的行動：
- 想一件你平常常打的一串指令（例如部署前要跑的 3–5 個步驟）
- 把它寫成一句自然語言任務，交給 goose，觀察它如何自己拆解並下指令
2. 程式碼編輯與測試：真的會改你專案的那種
goose 支援對檔案系統操作，讓 LLM 直接：
- 開啟 / 讀取專案中的檔案
- 修改檔案內容（插入、刪除、重構）
- 新增測試檔、更新
README
常見用法：
- 讓 agent 自動幫你 加 log / exception handling
- 要它針對某個 module 補齊單元測試
- 改 config、更新版本號、調整 CI 設定檔
你要做的行動：
- 選一個「可以放心被 AI 改壞」的小 side project
- 用 goose 給它一個任務，例如：「在這個 Rust 專案裡，新增一個 health check endpoint，並幫我補上測試」
3. 自訂工具擴充：把你自己的腳本、API 變成 agent 的能力
goose 的設計重點是 「可擴充的工具」。你可以：
- 把現有的 Python / Bash 腳本包裝成一個 tool
- 把團隊內部 API（如 issue tracker、部署服務）接進來
- 讓 agent 用「呼叫工具」的方式，連續完成更複雜的流程
實際效果：
- LLM 不用自己「想像」怎麼部署，而是呼叫你提供的
deploy_api - 你可以限制它只能用你認可的工具，控制風險
你要做的行動：
- 列出你工作中最常手動跑的 2–3 個腳本
- 想像它們如果變成一個
deploy_service/create_release的工具，agent 可以怎麼自動串起來
4. 接任意 LLM：OpenAI、DeepSeek、本地模型都行
goose 標榜 「with any LLM」，實際上就是可以在設定中自由切換 backend：
- OpenAI（如
gpt-4.1） - DeepSeek API（如
deepseek-coder） - 透過 OpenAI-compatible API 的本地模型（Ollama、LM Studio…）
這讓你可以：
- 開發時用免費 / 便宜模型測試流程
- 上線到正式環境時再換成更穩定的雲端模型
你要做的行動：
- 先挑一個你現有就有 API Key 的 LLM（例如 OpenAI 或 DeepSeek）
- 決定：
- 「實驗階段」用哪個模型
- 「正式跑自動化」時要不要升級到較貴的模型
💡 關鍵： 透過切換
GOOSE_MODEL等設定，你可以在成本（本地 / 便宜模型）與效果（雲端高階模型）之間彈性取捨。
適合誰用？三種典型場景
1. DevOps／SRE：日常腳本自動化
例如：
- 部署前：拉最新程式碼 → 跑測試 → build → health check
- 緊急修補：切 branch → 套 patch → 跑 smoke test → 發一版 hotfix
用 goose 的做法：
- 把這些步驟包成一個「任務腳本」（workflow）
- 讓 agent 自己決定下一步要跑哪個指令、根據輸出結果調整
2. 開發者：專案 boilerplate 生成與重構
適用情境：
- 開一個新服務：想要快速產生「專案骨架 + 基本路由 + CI 檔案」
- 老專案：想系統性把某種寫法換成新的 pattern
用 goose 可以這樣玩：
- 指定專案資料夾給 agent
- 給一個任務：「初始化一個 NestJS API 專案，幫我加上 Dockerfile 和 GitHub Actions CI」
3. 團隊工程流程：CI 前自動檢查與修修補補
在 CI 跑之前，先讓 goose 幫你：
- 檢查程式格式、lint 問題
- 嘗試自動修正簡單的錯誤
- 對 PR 產生簡短變更說明
做法：
- 在 CI pipeline 裡加入「goose agent 步驟」
- 給它權限在 CI runner 上修改檔案並 push（或開新 PR）
💡 關鍵： 把 goose 放進 CI / pre-commit，可以在錯誤進到主線分支之前，自動完成一輪整理與簡單修補。
怎麼開始：最快速的上手路徑
1. 用 Docker 跑起官方範例（最快測試）
前提：
- 已安裝 Docker
- 手邊有一個 LLM API Key（例：
OPENAI_API_KEY）
步驟：
# 1. 拉專案
git clone https://github.com/aaif-goose/goose.git
cd goose
# 2. 建一個 .env，放你的模型設定（簡化示意）
cat << 'EOF' > .env
OPENAI_API_KEY=your_key_here
GOOSE_MODEL=openai/gpt-4.1
EOF
# 3. 用 docker compose 跑起來（實際以 repo 裡的 compose 指令為準）
docker compose up --build
跑起來後，通常會有：
- 一個 CLI / HTTP 介面
- 你可以丟：
- 「在這個容器裡安裝 curl 並測試對 google.com 發送請求」
行動建議：先在容器內做「無害」的事情，例如安裝一個套件、建立一個測試檔案，確認 goose 真的有在動你環境。
2. 本機安裝（Rust 使用者）
前提：
- Rust toolchain（
rustup）
步驟：
# 1. 安裝依賴
cargo install --path . # 實際請以 README 為準
# 2. 設定環境變數
export OPENAI_API_KEY=your_key_here
export GOOSE_MODEL=openai/gpt-4.1
# 3. 跑 CLI
goose run
你可以在終端機裡對 agent 下指令，例如：
- 「列出目前資料夾的檔案，幫我找出所有含有 TODO 的檔案並列出行號」
3. 接上常見模型（OpenAI / DeepSeek / 本地 LLM）
以下是假設性的設定方向（實際請對照 goose README）：
OpenAI
export OPENAI_API_KEY=your_key
export GOOSE_MODEL=openai/gpt-4.1
DeepSeek
通常會提供 OpenAI 相容 API：
export OPENAI_BASE_URL=https://api.deepseek.com/v1
export OPENAI_API_KEY=your_deepseek_key
export GOOSE_MODEL=deepseek-chat
本地 LLM（以 Ollama 為例）
啟動 Ollama 後：
export OPENAI_BASE_URL=http://127.0.0.1:11434/v1
export OPENAI_API_KEY=dummy
export GOOSE_MODEL=ollama/llama3.1
行動建議：先用最簡單、你現在就有的 API Key 接上，確認 goose 的流程跑得通，再考慮搬到本地模型節省成本。
寫一個自己的「任務腳本」：讓 agent 連續完成幾個步驟
goose 的強項在於可以定義「多步驟任務」。概念上，你會有一個 workflow 設定（格式依官方為準，這裡用 pseudo-code 示意）：
# workflows/dev_check.toml
name = "dev_precommit_check"
[[steps]]
type = "shell"
command = "git status"
[[steps]]
type = "agent"
prompt = "閱讀 git status，決定要先格式化哪一些檔案，並執行對應指令。"
[[steps]]
type = "shell"
command = "cargo test"
[[steps]]
type = "agent"
prompt = "根據測試結果，如果有簡單錯誤可以直接修，並再次執行對應測試。"
用法：
goose run-workflow workflows/dev_check.toml
這樣，你可以一行命令啟動一個「會看情況調整動作」的前置檢查流程。
你要做的行動：
- 先定義一個超簡單的 workflow：
- Step1：
ls專案 - Step2：請 agent 根據專案結構生成一段簡短說明，寫入
PROJECT_SUMMARY.md
實戰：從零做一個小型自動化 workflow
目標：在一個現有專案裡，做「提交前自動整理 + 簡單修補」流程。
我們要達成：
- 檢查目前分支變更檔案
- 對變更檔案跑 formatter / linter
- 如果有明顯錯誤，由 agent 嘗試自動修改
- 重新跑測試
Step 1：準備專案與權限
- 找一個你熟悉、可以接受被改動的專案資料夾
- 新開一個分支，如
feat/goose-auto-fix - 確保 goose 有權限：
- 讀寫這個資料夾
- 執行必要的指令（例：
npm test、cargo test）
Step 2：定義 workflow（示意）
依 goose 支援的格式建立一個 workflow 檔（假設是 YAML）：
name: precommit-helper
steps:
- type: shell
command: git diff --name-only
- type: agent
prompt: |
你看到的是目前分支有變更的檔案清單。
目標：
1. 對這些檔案執行合適的 formatter / linter 指令（依照檔案類型判斷）。
2. 若 formatter/linter 回報可自動修復的問題，請修改檔案並重新執行檢查。
- type: shell
command: npm test # 或你專案的測試指令
- type: agent
prompt: |
根據測試輸出，
- 若是小型邏輯／型別錯誤，嘗試修改相關檔案後再次執行測試。
- 若錯誤較複雜，請產生簡短說明寫入 precommit_report.md。
Step 3：實際執行與調整
- 在專案根目錄跑：
bash
goose run-workflow precommit-helper.yaml
- 觀察它的行為：
- 有沒有亂跑你不想要的指令？
-
修改的檔案是否合理？
-
根據結果調整：
- 限制能用的指令範圍（例如只允許
npm test,npm run lint） - 在 prompt 裡多加一些「安全護欄」，例如「不要刪除檔案」。
完成後，你就有了一個：
- 可以在提交前幫你「整理 + 修補 + 產生報告」的小型 AI 助理
- 海豚式改進：遇到痛點就稍微改一下 workflow / 工具清單，越用越貼近你團隊習慣
小結：下一步可以怎麼玩？
如果你看到這裡，建議接下來這樣走：
- 先跑官方範例容器一次，確認 goose 在你機器上可以正常跑指令。
- 選一個專案資料夾，做一個超小 workflow：只做檔案摘要或自動補 README。
- 把你現有的一個腳本包成 tool，讓 agent 可以呼叫（例如部署或打包腳本）。
- 等你有信心後，再把它接進 CI / pre-commit 流程。
完整專案與最新用法請看：https://github.com/aaif-goose/goose
把 goose 想成一個「可編程的 ChatGPT + 指令列機器人」，先從最小、風險最低的自動化開始，你會很快找到適合自己工作流的用法。
🚀 你現在可以做的事
- 打開
<https://github.com/aaif-goose/goose>，用 Docker 照著 README 跑一次官方範例- 選一個 side project，讓 goose 幫你完成「新增一個 endpoint + 補上測試」的小任務
- 把日常最常用的一個部署或檢查腳本包成 tool，寫一個只包含 2–3 個步驟的簡單 workflow
