串接 PR-Agent：GitHub Action、模型金鑰，以及 Token 成本

本頁要回答的問題並不是什麼是 PR 代理——那是另一篇文章——而是從你決定要在自己的儲存庫上使用 PR-Agent，到讓它審查一個拉取請求之間，究竟會發生什麼事。這兩點之間的差距大約就是一個 YAML 檔案和一個模型金鑰，而人們常弄錯的部分，正是沒有人記錄下來的那些：哪條安裝路徑才是目前適用的、預設模型每次審查要花多少錢，以及為什麼單一拉取請求可能讓你被收十次費用。

PR-Agent 是 CodiumAI 打造、後來捐贈給社群的開源工具。它現在位於自己的 GitHub 組織中，是 Qodo 由社群維護的遺留專案，採用 MIT 授權，約有 12.6k stars 與 1.7k forks。它免費；但它所發出的模型呼叫並非免費，而這是這套配置中唯一會隨你的團隊規模增長的數字。

三種安裝路徑，以及你實際上想要的是哪一種

• GitHub Action — 一個工作流程檔案，會執行 code>the-pr-agent/pr-agent@main/code>，並由提取請求事件觸發。這是建議的路徑，也是應先從它開始的方式：它不需要伺服器、不需要 webhook 端點，而且除了模型金鑰和 GitHub 已提供給此動作的權杖之外，不需要任何祕密。

• 命令列工具 — code>pip install pr-agent/code>，然後code>pr-agent --pr_url <url> review/code>。適合在進行任何串接之前，先對現有 PR 試跑一次審查，也適合從筆記型電腦或非 GitHub Actions 的 CI 工作執行同一個引擎。

• 容器與 Webhook — Docker 映像，或是 GitLab、Bitbucket、Azure DevOps 和 Gitea 的託管 Webhook 路徑。當你的儲存庫不在 GitHub 上，或需要審查在你自己的網路邊界內執行時，請選擇此項。

在從教學文章複製版本號之前，有一點值得留意：專案自身的文件指出，已發佈的code>pip/code> 套件目前仍落後於最新版本，並建議需要最新程式碼的使用者改用 GitHub 標籤安裝。這是穩定狀態下的問題，而非突發事件，但這意味著「文件叫我用 pip install」和「我擁有的是最新版本」並不是同一句話。

模型鍵才是實際的決策

PR-Agent 內建的模型支援刻意保持開放。發布說明列出 GPT-5.6 為新的預設模型，同時支援 Gemini 3.6 以及 Claude Opus 5 與 Claude Sonnet 5 系列，而 DeepSeek 與 Mistral 則透過同一個設定區塊運作。無論你選擇哪一個，金鑰都由你提供，審查也在你自己的帳號上執行。

這就是開源取捨的一句話總結：你擁有底層管線——金鑰、密鑰、正常運行時間與帳單——換來與席次無關的每次審查成本。五人開發團隊使用按席次計費的託管工具時，無論每月合併十個還是上千個拉取請求，付費都相同。若採用按 token 計價的方式，費用會隨你實際審查的量變動；忙碌時更划算，不忙時則更不划算。

有兩個配置選擇比模型選擇更能影響那個數字：

• 每個拉取請求執行一次，而非每次推送執行一次。有些工具預設會審查每一次提交。一個歷經十次推送的 PR 會變成十次審查執行、十次模型呼叫，帳單也變成十倍，只為了九次審查早已不存在的程式碼。無論你在哪裡部署，請先檢查這項設定。

• 為 diff 設定上限。這些工具每一個都會在 diff 送到模型之前先將其壓縮，因為 2,000 行的變更放進提示詞後，就沒有空間可以思考了。PR-Agent 的 PR 壓縮策略是標準實作。自動產生的檔案、lockfile 或 vendored 依賴可能佔據大部分的 diff 與成本，卻不包含任何審閱者會讀的內容——請將它們排除。

這些指令的作用，以及每一項的成本

安裝後，這個工具會回應 Pull Request 上的斜線指令。每次通常是一次模型呼叫，因此回應會在數十秒內送達，成本只需幾分之一美分：

• code>/describe/code> — 僅根據 diff 撰寫 PR 標題、摘要、逐步說明與標籤。

• code>/review/code> — 掃描錯誤、安全性問題與可維護性問題，並提供嚴重性標籤與評分。

• code>/improve/code> — 建議可提交的程式碼變更，而非僅提供評論。

• code>/ask/code> — 根據 diff 回答問題，這是審查者一旦信任此工具後最常使用的指令。

• code>/update_changelog/code> — 重新產生此拉取請求的變更記錄項目。

大多數團隊想要的自動行為，就是在 pull request 開啟時只執行一次 code>/review/code>。其餘的一切都可以留給一則留言來處理，這樣成本可預測，也不會讓 agent 妨礙到已經在閱讀的審查者。

沒有人警告過你的失敗模式

• 動作成功，但沒有發布任何內容。 通常是權限問題：工作流程權杖可以讀取差異，但無法寫入留言。在偵錯模型之前，請先檢查動作的日誌，確認留言呼叫是否出現 403。

• 它審查了錯誤的差異。Fork pull request 預設會以受限的權杖執行，而尚未為其設定好的工作流程會審查空白或不完整的差異，並回報未發現任何問題。沉默並不代表一切正常。

• 這則審查自信滿滿，卻是錯的。每個由模型驅動的審查器，偶爾都會描述不在 diff 中的程式碼。緩解方式屬於結構性，而非提示詞層級：要求工具引用它所抱怨的程式碼行，並把未引用的發現視為評論，而不是把關關卡。

• 成本悄悄攀升。不是因為價格變動，而是因為範圍擴大：更多儲存庫、每個 PR 更多推送、更大的差異。為你為此用途發行的金鑰設定每月預算，並將警示視為一種訊號：是你的工作流程出了變化，而不是模型變了。

路由器適用之處，以及不適用之處

PR 代理是少數在執行途中切換模型確實很有用的 AI 工作負載之一：低成本的第一輪檢查能抓出格式與明顯瑕疵，而只有通過這關的 pull request 才需要動用昂貴的模型。這正是 OrcaRouter 的 OrcaCode Review 產品所實現的形態——由便宜的前沿模型進行快速檢查，當篩檢發現問題時再升級到更強的模型——你也可以用 PR-Agent 自行近似做到這點：將其設定指向閘道，並依 PR 大小進行路由。

路由器做不到的，是讓審查本身變得正確。它的價值在於：用同一把金鑰就能呼叫你可能拿來比較的每一個模型、以供應商標價提供而不額外加價，以及當供應商在你的合併佇列進行到一半卻狀況百出時能容錯切換。Claude Opus 5.5 和 Claude Sonnet 5.5、GPT-5.6 以及 Gemini 系列，全都可透過同一個 OpenAI 相容端點呼叫，這讓「由哪個模型來審查我們的程式碼」變成改一項設定，而不是一場採購作業。

本週該做什麼

• 在單一儲存庫上安裝 GitHub Action，而不是在全部儲存庫上安裝。單一儲存庫能告訴你審查品質與每個 PR 的成本；全部儲存庫則只會把這兩者除以一個未經測量的分母。

• 以實測而非口碑來決定模型。執行 code>/review/code> 在你最近二十個已合併的 pull request 上，使用兩個不同模型，並比較人類認同的發現。那個數字才是這裡唯一重要的基準。

在設定其他任何項目之前，先設定「每個拉取請求一次」，並為金鑰設定預算。

• 保留人工把關。一個會阻擋合併的 PR 代理，你的團隊不到一個月就會找到繞過它的方法。

來源說明：PR-Agent 的起源、授權條款、星標數、安裝途徑、指令集、模型預設值，以及 pip 套件落後於最新發行版的說明，均取自該專案自身的儲存庫與文件，閱讀日期為 2026 年 11 月 4 日。託管替代方案的按席位與按使用額度計價，取自這些供應商公開的頁面，僅供對比。Grok 與模型名稱僅作為組態範例使用；OrcaRouter 閘道上的模型識別碼已於同日對照即時模型清單查核。這些故障模式取自這些工具在工作流程權杖權限範圍不足時的行為，而非來自特定事件報告。