安裝
curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash適合誰
- 適合想在自有基礎設施裡使用 AI 協作能力的開發團隊：Curie 是開源、可自行架設的平台，跑在你自己的基礎設施裡，把編碼代理變成可分派任務、可驗收產出的同事。
- 核心情境是「把 GitHub issue 委派出去，收回一個待審查的實作」：Curie 負責 issue 的實作與審查，回傳一個等待團隊接受的 pull request 或 merge request。
- 也適合 Kubernetes 營運協作：唯讀的 Kubernetes 檢查可以立即執行，設定過的變更類操作會請求人工核准，適合把巡檢、診斷這類低風險的例行工作交給它。
- 適合要求核准環節留在人手裡的團隊：設定過的變更操作要人工重新核准，哪些動作需要先核准可由你自己設定。
- 已經維護著自己編碼代理的團隊，可用官方的
curie init --adopt ./my-existing-agent收編現有代理。 - 不適合的情況：機器跑不動 Docker，或拿不到 Anthropic 或 OpenRouter 的模型憑證——官方列出的執行前提缺一不可。
3 分鐘完成第一次嘗試
前提：一台 Docker 已在執行的機器，裝好 kind、kubectl 與 Helm，並準備一個 Anthropic 或 OpenRouter 模型憑證。任何一項缺失都無法按官方說明啟動。
在終端機執行官方安裝指令稿：
curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash
指令稿來自 Curie 儲存庫的 main 分支；管線式指令會以你的使用者權限直接執行遠端指令稿，若介意可先下載審查內容再執行。
第一次嘗試選低風險路徑：挑一個描述清楚、影響範圍小的儲存庫 issue，委派給 Curie 做實作與審查。它完成後會回傳一個 pull request 或 merge request，等待你的團隊接受。成功訊號很明確：你在程式碼託管平台上收到它回傳的 PR/MR，並能逐一檢視其中的變更內容。
安裝之後如何輸入模型憑證、如何串接程式碼託管帳號，官方說明未提供逐步指引，請以指令稿輸出提示與儲存庫文件為準。
使用案例
案例一：把 issue 變成待審 PR。情境：團隊儲存庫裡積壓了一個邊界清楚的實作類 issue，一直沒有人手及時處理。發起方式：把這個 issue 委派給 Curie，對應官方描述的「委派 issue 實作並審查」流程。過程與結果：它完成後交回 PR/MR，你在自己的託管平台上逐一審查變更；可確認的終點是拿到一個等待團隊接受的 PR/MR。
案例二：Kubernetes 唯讀巡檢。情境：需要了解叢集目前狀況，又不想為一次例行的狀態檢查走完整的變更核准。發起方式：向 Curie 提出唯讀的 Kubernetes 檢查請求，用到的正是官方說明的唯讀 Kubernetes 工具。過程與結果：唯讀操作立即執行，不需要額外核准；如果接著要求執行設定過的變更類操作，它會先請求一次全新的人工核准再進行。首次巡檢保持在唯讀範圍內就不會遇到核准等待；想觀察核准環節，再補一條變更類請求即可看到核准提示。具體提供哪些唯讀工具、如何呼叫，官方說明未逐一列出。
使用邊界
- 環境前提：Docker 處於執行狀態，kind、kubectl、Helm 齊備，並持有 Anthropic 或 OpenRouter 模型憑證；作業系統與硬體架構要求官方未說明。
- 副作用與確認點：唯讀 Kubernetes 工具立即執行；設定過的變更操作每次都會請求一次全新的人工核准；委派實作的產出為等待團隊接受的 PR/MR。安裝指令稿會在你的機器上建立什麼、佔用哪些目錄，官方未逐一說明，執行前可先審查指令稿內容。
- 執行位置：自行架設的平台，跑在你自己的基礎設施中。
- 收編現有代理：官方提供
curie init --adopt ./my-existing-agent指令；該指令會保留既有代理的哪些內容，官方說明未提及。除此之外的初始化與設定流程，官方說明未展開。 - 行動前應到儲存庫核實的資訊：安裝後的憑證設定步驟、程式碼託管帳號的串接方式、可用唯讀工具與可設定變更操作的完整清單、除這兩家之外是否支援其他模型提供方，以及可對接編碼代理的準確名單。動手前請逐項以儲存庫文件為準。