會自己判斷「什麼時候不該出手」的 GitHub 自動化代理

這個 bot 做什麼

這份範例打造的是一個自主運作的 GitHub Actions bot，包含四項工作：issue 分類、pull request 審查、AI 劣質內容（AI-slop）偵測，以及自動開修 bug 的 PR。整套流程跑在 OpenCode 上、以 Muse Spark 作為模型，靠的是 Model API 對現有 agent CLI 的隨插即用相容性。所有東西都在你自己儲存庫的 Actions 裡執行，不必依賴別人的基礎設施。

「克制」是設計需求，不是加分項

這份範例和天真的「把 LLM 接上 webhook」專案最大的差別，在於它花了大量篇幅在教 agent 不要出手。審查 agent 內建一份明確的「NOT slop」清單——列出哪些變更不准被標記，避免它對正當的程式碼模式狼來了亂叫。issue 分類永遠不會關閉 issue，那是保留給人類的決定。修 bug 的 agent 如果無法先重現問題，就不會開 PR。Meta 的說法很直接：過度觸發被當成一種失敗模式（failure mode）來對待，而不是可有可無的小細節。

引用紀律也是一環：問答功能只能根據儲存庫裡的檔案回答，每個主張都要附上檔案與章節的出處，答案不在儲存庫裡時就必須拒答、不得捏造。對一個代表你的專案在公開討論串發言的 bot 來說，「有憑有據，否則閉嘴」是唯一站得住腳的原則。

AGENTS.md：一個檔案管全隊

範例中的每個 agent 都會自動載入一份共用的 AGENTS.md，裡面放著儲存庫脈絡——讓 agent 不必用猜的去揣測專案慣例——以及所有 agent 一體適用的安全規則。Meta 說這是整份範例裡最需要改寫成你自己專案版本的檔案：內附的版本是針對 Python/pytest/uv 技術堆疊的完整範例，本來就是要被改寫的，但 SECURITY 段落必須一字不動照抄。

分階段上線，寫入權限要用實績換

部署建議是一道四階段的信任階梯。第一階段：PR 審查與 issue 分類，唯讀——用真實流量驗證品質，零波及範圍。第二階段：明確的 /oc 指令，讓維護者刻意地呼叫 agent 幹活。第三階段：以 label 把關的自動修 bug。第四階段：強化——分支保護、CODEOWNERS、CI 關卡。寫入權限靠實績一步步賺來，絕不在第一天就發放。這和 Muse Code 自身的可稽核性設計是同一套哲學：自主性擴張的速度，永遠不能超過驗證能力。

Meta 怎麼驗證這套範例

有個細節很值得抄：這份範例的驗證方式，是拿腳本化的 issue 與 PR 情境，headless 驅動真實的 agent 跑一遍——重建 Action 的 prompt、在 PATH 上放一個假的 gh，確保完全不會碰到真實儲存庫——然後逐一檢視它們的產出。測你的 bot，就該像測任何不受信任的自動化一樣：先關進罐子裡，再放進正式環境。可直接執行的範例收錄在 cookbook 的 use cases 底下。