前幾堂課建立了 review 機制(L10)和核准閘門(L11),這堂課把它們接進 CI/CD pipeline——讓 Claude 在 pipeline 裡非互動式執行,做判斷、做修正、做部署,但永遠停在 production gate 前面。
課程怎麼教
從唯讀開始,逐步加寫入
課程的實作路徑很務實——不是一步到位,而是分階段升級 agent 在 pipeline 裡的權限:
第一步:唯讀判斷。Platform engineer 用 claude -p 在 pipeline job 裡做 build 失敗分類、摘要 flaky test、產出 changelog 草稿。這些都是唯讀操作,風險趨近於零。
課程提供的 pipeline step 範例:
- name: Triage failed build
if: failure()
run: >
claude -p "Read the build log at out/build.log. Identify the most
likely cause, say whether the failure looks flaky or real, and write a
three-line summary for the PR thread." >> triage.md
第二步:受閘門保護的寫入。修 lint 問題、更新產生的文件、回應 review comment。Agent 的寫入透過 PR 進來,branch protection 確保不會直接推到 main。
第三步:沙箱化執行。Agent job 跑在容器裡,受 network policy 限制,使用短期憑證,預設沒有 production credentials。
透過 MCP 暴露部署工具
這是這堂課最有意思的架構設計——不是讓 agent 執行部署腳本,而是把 deploy、status、rollback 包裝成 MCP tools,每個環境各自設定 scope。
這樣做的好處是:agent 的部署能力變成一份白名單,而不是一堆帶著 credentials 的 shell script。平台團隊控制白名單裡有什麼,agent 只能透過這些 tool 操作。
按環境分層授權
| 環境 | Agent 權限 |
|---|---|
| Development | 自由部署 |
| Staging | 中間地帶(依團隊定義) |
| Production | 必須有 release manager 核准 |
這個分層跟 L11 的 hooks 搭配——production deploy hook 在沒有 RELEASE_APPROVAL 的情況下擋住動作。
反覆演練 Rollback
課程特別強調 rollback 應該是 pipeline 裡「最常練習的路徑」。原因很直接:L13(Closing the loop on metrics)會講到當監控指標超出控制帶時,agent 需要觸發 rollback。如果 rollback 路徑沒有提前驗證過,緊急時刻根本不敢用。
治理原則
整堂課的治理原則濃縮成一句話:
"The agent may act up to the production gate and cannot pass it."
用三個機制落實:
- Branch protection:agent 的寫入變成 PR,沒有直接推 main 的路徑
- Production deploy hook:擋到 release manager 核准為止
- Per-environment permission tiers:定義 agent 在每個環境能做什麼
實戰對照
我們在一個中型專案裡還沒有用 Claude 做 CI pipeline 內的 triage,但已經在用 hook 做 pre-commit gate。我們的 pnpm verify 作為 pre-commit hook 跑 lint、reference check、skills sync 驗證——不通過就不能 commit。這跟課程講的「唯讀判斷」是同一個概念的不同實作:用自動化檢查降低人工 review 的負擔。
我們的治理分層概念也跟課程的環境分層對應:
| 我們的 Tier | 對應 |
|---|---|
| Tier 0(自主執行) | Development 環境的自由操作 |
| Tier 1(過閘門) | commit 前跑 verify,對應 branch protection |
| Tier 2(先問再做) | schema 變更、deploy、改 CI,對應 production gate |
| Tier 3(禁止) | 繞過檢查、無來源寫事實,對應 managed settings 的硬封鎖 |
我們還沒做的是「透過 MCP 暴露部署工具」——目前的部署還是人工觸發。但課程的 MCP 架構確實是更好的做法:把部署能力從 shell script 抽象成有 scope 的 tool,比直接給 agent shell access 安全得多。
給讀者的起步建議
- 從 build 失敗 triage 開始:加一個
if: failure()step,讓 Claude 讀 build log 產出三行摘要。零風險,但馬上能看到價值 - 不要跳過沙箱:agent 在 CI 裡跑一定要有容器隔離和短期憑證。不要偷懶用工程師自己的 API key
- rollback 先練:不要等到真的出事才第一次跑 rollback。先在 staging 練到手熟,再讓 agent 有觸發它的權限
- MCP 優於 shell script:如果你正在設計 agent 的部署路徑,用 MCP tool 包裝比給 shell access 好。白名單比黑名單安全
參考資料
Loading...