為 AI 代理的 Review 動(dòng)作編寫(xiě) Cedar 審批門(mén)控策略review-agent-governance 策略編寫(xiě)實(shí)戰(zhàn)指南【免費(fèi)下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項(xiàng)目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文面向需要為 Claude Code 等 AI 代理配置「審查面review-surface門(mén)控」的團(tuán)隊(duì)系統(tǒng)講解如何基于 Cedar 授權(quán)語(yǔ)言編寫(xiě)、擴(kuò)展與審計(jì) review-governance 策略把 AI 代理發(fā)布 PR 評(píng)論、審批合并、編輯 CI 配置等高危動(dòng)作牢牢關(guān)在人類(lèi)審批這道門(mén)之后并借助 Ed25519 簽名收據(jù)鏈實(shí)現(xiàn)可離線驗(yàn)證的審計(jì)證據(jù)。一、為什么需要「審查面門(mén)控」本文要解決的故障模式AI 代理一旦擁有對(duì) GitHub CLI 或 GitHub API 的無(wú)限制訪問(wèn)權(quán)限就可能出現(xiàn)一系列嚴(yán)重后果發(fā)布幻覺(jué)式 review 評(píng)論、以虛構(gòu)的理由審批 PR、錯(cuò)誤地關(guān)閉 issue或悄悄改寫(xiě) workflow 文件從而繞過(guò)其他安全控制。這類(lèi)事故的特點(diǎn)是即時(shí)、可見(jiàn)且往往被歸責(zé)到運(yùn)行代理的那個(gè)賬號(hào)頭上——這正是 review-agent-governance 插件中review-policy-author代理定義于 agents/review-policy-author.md所針對(duì)的核心故障模式。review-policy-author是一個(gè)專(zhuān)門(mén)負(fù)責(zé)編寫(xiě)、審計(jì)和擴(kuò)展 Cedar 審查面門(mén)控策略的專(zhuān)家代理。它的職責(zé)范圍是決定 AI 代理在未經(jīng)人類(lèi)審批的情況下是否被允許發(fā)布 review、評(píng)論 issue、合并 PR、修改 CI 配置。審查面門(mén)控review-surface gating正是防止這一類(lèi)事故的通用模式。二、審查面由哪些「命令模式與路徑」構(gòu)成要寫(xiě)出有效的門(mén)控策略必須先完整枚舉各大平臺(tái)的審查面命令模式。review-policy-author明確了以下幾類(lèi)必須被門(mén)控的路徑GitHub通過(guò)ghCLIgh pr review、gh pr comment、gh pr merge、gh pr close、gh pr edit、gh pr ready、gh issue comment、gh issue close、gh issue edit、gh release create、gh release edit、gh api repos/.../comments、gh api repos/.../reviews、gh api repos/.../pulls/.../mergeGitLab通過(guò)glabglab mr comment、glab mr approve、glab mr merge、glab mr close、glab issue comment、glab issue close、glab release createBitbucket通過(guò)bbCLI 或直接 API 調(diào)用。必須人工門(mén)控的 CI/CD 路徑.github/workflows/、.github/CODEOWNERS、.gitlab-ci.yml、.circleci/config.yml、buildkite/pipeline.yml、Jenkinsfile、azure-pipelines.yml必須門(mén)控的保護(hù)分支main、master、release、production、prod、stable通知面容易放大幻覺(jué)的傳播渠道Slack webhookshooks.slack.com、Discord webhooks、Teams webhooks、PagerDuty 事件、任何郵件 API這些枚舉不是空談——插件自帶的默認(rèn)策略 review-agent-governance.cedar 就把其中的核心子集落成了可執(zhí)行的forbid規(guī)則詳見(jiàn)下文第四節(jié)。三、編寫(xiě) review-governance 策略的六條原則review-policy-author給出了編寫(xiě)策略時(shí)的六條操作準(zhǔn)則這也是把「審查面」落成 Cedar 策略的標(biāo)準(zhǔn)流程1. 從插件的默認(rèn)策略起步。將plugins/review-agent-governance/policies/review-agent-governance.cedar復(fù)制到項(xiàng)目根目錄的./review-governance.cedar再開(kāi)始編輯。默認(rèn)策略已覆蓋 GitHub / GitLab、保護(hù)分支與 CI 路徑是一個(gè)可靠的基線。2. 針對(duì)項(xiàng)目特有的審查面做擴(kuò)展。如果團(tuán)隊(duì)使用 Linear、Jira、Notion 或自研 review 工具為這些工具用到的 CLI 命令模式或 WebFetch 主機(jī)補(bǔ)充forbid規(guī)則。3. 絕不門(mén)控只讀操作。gh pr view、gh issue list、API GET 請(qǐng)求都允許代理無(wú)人值守地執(zhí)行門(mén)控只針對(duì) write / post / merge / close 這類(lèi)寫(xiě)動(dòng)作。4. 按分支名而非路徑門(mén)控分支。使用context.target_branch in [main, ...]而不是context.resource_path starts with refs/heads/main——分支名才是人類(lèi)推理的依據(jù)。5. 必須包含通知面。Slack 與 Discord webhook 是 review-bot 幻覺(jué)被放大的地方要門(mén)控對(duì)這些主機(jī)的 POST 請(qǐng)求。6. 不要?jiǎng)臃?review 動(dòng)作。該策略聚焦于審查面在末尾放一條寬松的permit (principal, action, resource);讓其余一切放行。如需更廣泛的策略強(qiáng)制與protect-mcp插件組合使用。四、默認(rèn)策略逐條拆解審查面門(mén)控的落地實(shí)現(xiàn)默認(rèn)策略 review-agent-governance.cedar 是理解這套門(mén)控體系的最佳入口它包含 5 條forbid規(guī)則與 1 條兜底permit。每條規(guī)則的作用域與實(shí)現(xiàn)要點(diǎn)如下規(guī)則 1門(mén)控ghCLI 的審查面動(dòng)作forbid ( principal, action Action::Bash, resource ) when { [gh pr review, gh pr comment, gh pr close, gh pr merge, gh pr edit, gh issue comment, gh issue close, gh issue edit, gh release create, gh release edit, gh api repos].contains(context.command_pattern) };注意gh api repos是刻意保留的通配前綴它攔截任意 GitHub REST 調(diào)用防止代理用gh api repos/X/Y/pulls/42/reviews繞過(guò)基于命令模式command-pattern的規(guī)則。規(guī)則 2門(mén)控 GitLab / Bitbucket CLIforbid ( principal, action Action::Bash, resource ) when { [glab mr comment, glab mr approve, glab mr merge, glab issue comment].contains(context.command_pattern) };規(guī)則 3門(mén)控對(duì)保護(hù)分支的 git pushforbid ( principal, action Action::Bash, resource ) when { [git push, git push --force, git push -f].contains(context.command_pattern) context has target_branch [main, master, release, production].contains(context.target_branch) };注意context has target_branch這一存在性判斷——只有命令上下文確實(shí)攜帶目標(biāo)分支信息時(shí)才觸發(fā)判斷。規(guī)則 4門(mén)控對(duì) CI/CD 配置文件的直接寫(xiě)入forbid ( principal, action in [Action::Write, Action::Edit], resource ) when { [.github/workflows/, .github/CODEOWNERS, .gitlab-ci.yml, .circleci/config.yml, buildkite/pipeline.yml].contains(context.path_starts_with) };修改這些文件等于讓代理改變未來(lái)構(gòu)建與 review 的運(yùn)行方式從而繞過(guò)其他所有防護(hù)因此必須無(wú)條件要求人類(lèi)審批。規(guī)則 5門(mén)控對(duì)已知 review / 聊天平臺(tái)的 WebFetch POSTforbid ( principal, action Action::WebFetch, resource ) when { context.method POST [api.github.com, api.gitlab.com, api.bitbucket.org, hooks.slack.com, discord.com].contains(context.url_host) };兜底規(guī)則放行一切其他動(dòng)作permit (principal, action, resource);這印證了review-policy-author的原則 6該插件聚焦審查面非 review 動(dòng)作原樣放行如需通用工具調(diào)用策略強(qiáng)制可并排安裝 protect-mcp。策略的 Schema 契約與策略配套的 review-agent-governance.cedarschema 定義了策略引用的實(shí)體與動(dòng)作上下文類(lèi)型它決定了每條規(guī)則可用的context字段entity User; entity Resource; action Bash appliesTo { principal: [User], resource: [Resource], context: { command_pattern: String, target_branch?: String } }; action Write appliesTo { principal: [User], resource: [Resource], context: { path_starts_with: String } }; action Edit appliesTo { principal: [User], resource: [Resource], context: { path_starts_with: String } }; action WebFetch appliesTo { principal: [User], resource: [Resource], context: { method: String, url_host: String } };可以看到Bash動(dòng)作攜帶command_pattern與可選的target_branchWrite/Edit攜帶path_starts_withWebFetch攜帶method與url_host。默認(rèn)策略中的 5 條 forbid 規(guī)則正是精確消費(fèi)這些上下文字段——這也是為什么審計(jì)策略時(shí)必須保證 schema 與實(shí)際使用的 context 屬性一致。一個(gè)值得警惕的語(yǔ)言陷阱in-on-String 會(huì)被靜默丟棄倉(cāng)庫(kù)的測(cè)試 test/README.md 與 run-tests.sh 專(zhuān)門(mén)防護(hù)了一個(gè) Cedar 語(yǔ)言陷阱對(duì)應(yīng)上游 issue #598在forbid規(guī)則里寫(xiě)context.attr in [ ... ]形式Cedar 會(huì)靜默丟棄該規(guī)則導(dǎo)致門(mén)控悄悄失效。正確寫(xiě)法是[ ... ].contains(context.attr)。測(cè)試腳本的 Part A只需要grep任何環(huán)境都能跑做兩件事一是斷言策略中不存在context.attr in [的 bug 形態(tài)先扁平化空白防止跨行換行繞過(guò)檢查二是斷言策略確實(shí)使用了[ ... ].contains(context.attr)的修正寫(xiě)法。Part B 則僅在安裝了cedarCLI 時(shí)運(yùn)行cedar validate --policies ... --schema ...利用 schema 中 context 屬性為String類(lèi)型這一事實(shí)在加載期拒絕in-on-String 形式、接受.contains()形式。默認(rèn)策略中大量.contains(context.command_pattern)寫(xiě)法正是這一防御的直接體現(xiàn)。五、三類(lèi)典型擴(kuò)展把默認(rèn)策略適配到你的項(xiàng)目review-policy-author給出了三個(gè)可直接復(fù)制的擴(kuò)展模板。5.1 使用 Linear 做 issue 分診的團(tuán)隊(duì)禁止代理用 CLI 操作 Linear并禁止對(duì)api.linear.app發(fā)起寫(xiě)型 WebFetchforbid ( principal, action Action::Bash, resource ) when { context.command_pattern starts with linear }; forbid ( principal, action Action::WebFetch, resource ) when { context.method POST context.url_host api.linear.app };5.2 使用自研內(nèi)部 review bot 的團(tuán)隊(duì)forbid ( principal, action Action::WebFetch, resource ) when { context.method in [POST, PUT, PATCH, DELETE] context.url_host in [ review-bot.internal.company.com, code-review.internal.company.com ] };5.3 允許專(zhuān)用 bot 賬號(hào)、禁止個(gè)人賬號(hào)當(dāng)團(tuán)隊(duì)希望讓運(yùn)行在專(zhuān)屬「automation」身份下的代理執(zhí)行 review而不允許開(kāi)發(fā)者個(gè)人賬號(hào)執(zhí)行時(shí)可用「精確permit 兜底forbid」的組合permit ( principal Principal::gh-bot-reviewer, action Action::Bash, resource ) when { context.command_pattern in [gh pr comment] }; forbid ( principal, action Action::Bash, resource ) unless { principal Principal::gh-bot-reviewer || context.human_approved true };注意這個(gè)forbid ... unless結(jié)構(gòu)除 bot 賬號(hào)外其余主體只有攜帶human_approved true上下文時(shí)才能通過(guò)。六、審計(jì)一份既有策略的五個(gè)檢查點(diǎn)當(dāng)需要審查一份review-governance.cedar時(shí)review-policy-author建議按以下順序逐項(xiàng)核對(duì)命令覆蓋確認(rèn)團(tuán)隊(duì)使用的每一條審查面 CLI 命令都有對(duì)應(yīng)的forbid規(guī)則。API 覆蓋缺口檢查gh api repos這類(lèi)通配規(guī)則是否在。缺少它代理可以用gh api repos/X/Y/pulls/42/reviews繞過(guò)所有基于命令模式的規(guī)則。保護(hù)分支覆蓋驗(yàn)證保護(hù)分支的git push規(guī)則覆蓋了倉(cāng)庫(kù)設(shè)置中實(shí)際處于保護(hù)狀態(tài)的所有分支。CI/CD 路徑匹配確認(rèn) CI/CD 路徑規(guī)則與本項(xiàng)目真正起門(mén)控作用的文件一致例如有些團(tuán)隊(duì)用deployment/而非.github/workflows/。默認(rèn)放行規(guī)則不覆蓋先前的 forbid檢查末尾的默認(rèn)放行規(guī)則不會(huì)覆蓋更早的forbid。Cedar 中forbid是權(quán)威的后續(xù)的permit無(wú)法解除它。七、門(mén)控體系如何運(yùn)轉(zhuǎn)從策略到鉤子到收據(jù)鏈策略本身只是一半另一半是運(yùn)行時(shí)執(zhí)行機(jī)制。該插件通過(guò)兩個(gè)鉤子定義于 hooks/hooks.json包住 Claude Code 的每一次工具調(diào)用PreToolUse 鉤子門(mén)控決策if [ -f ${REVIEW_APPROVAL_FLAG:-./.review-approved} ]; then exit 0; fi; \ npx protect-mcp0.7.4 evaluate --policy ${REVIEW_GOVERNANCE_POLICY:-./review-governance.cedar} \ --tool $TOOL_NAME --input $TOOL_INPUT --fail-on-missing-policy false若存在./.review-approved審批標(biāo)記文件或REVIEW_APPROVAL_FLAG指定的替代路徑直接exit 0放行否則調(diào)用protect-mcp evaluate用 Cedar 策略評(píng)估該工具調(diào)用Cedar 判定 deny 時(shí)工具調(diào)用以退出碼 2 結(jié)束Claude Code 隨即阻止它。PostToolUse 鉤子簽名取證npx protect-mcp0.7.4 sign --tool $TOOL_NAME --input $TOOL_INPUT --output $TOOL_OUTPUT \ --receipts ${REVIEW_GOVERNANCE_RECEIPTS:-./review-receipts/} \ --key ${REVIEW_GOVERNANCE_KEY:-./review-governance.key}無(wú)論該次工具調(diào)用被批準(zhǔn)、拒絕還是跳過(guò)都會(huì)產(chǎn)生一條 Ed25519 簽名收據(jù)收據(jù)鏈精確記錄了什么動(dòng)作在何時(shí)被授權(quán)。審批窗口的打開(kāi)與關(guān)閉審批窗口通過(guò)兩種方式打開(kāi)方式一標(biāo)記文件最簡(jiǎn)touch ./.review-approved # 讓代理執(zhí)行被批準(zhǔn)的動(dòng)作 rm ./.review-approved方式二斜杠命令Claude Code 內(nèi)/approve-review Posting the code review for #123/approve-review實(shí)現(xiàn)見(jiàn) commands/approve-review.md創(chuàng)建./.review-approved并把審批理由寫(xiě)入文件與./review-receipts/approvals/下的時(shí)間戳 JSON 條目。關(guān)于審批日志的重要提醒./review-receipts/approvals/*.json是明文 JSON 記錄不是簽名收據(jù)。它們不經(jīng)過(guò)protect-mcp sign因此veritasacta/verify不覆蓋它們審批日志屬于「操作者信任」——它記錄人類(lèi)意圖批準(zhǔn)什么但事后被編輯也無(wú)法被偵測(cè)。真正具備防篡改能力的是 PostToolUse 為每次動(dòng)作無(wú)論放行還是拒絕生成的./review-receipts/*.json工具調(diào)用收據(jù)它們才是權(quán)威審計(jì)線索。對(duì)于受監(jiān)管環(huán)境需要簽名審批記錄的場(chǎng)合可改用npx protect-mcplatest sign --tool approve-review --input ...直接簽名。查看被拒動(dòng)作/list-pending實(shí)現(xiàn)見(jiàn) commands/list-pending.md遍歷./review-receipts/收據(jù)鏈打印最近的decision: deny條目默認(rèn)最近 10 條可用--last N調(diào)整展示工具名、命令模式與時(shí)間戳并提示可配合/approve-review人工放行后重試。一個(gè)完整的「拒絕 → 批準(zhǔn) → 放行」會(huì)話以代理想在 PR 上發(fā)布 review 評(píng)論為例。未批準(zhǔn)時(shí)$ agent: gh pr review 42 --comment --body LGTM → PreToolUse hook 運(yùn)行 → 無(wú) ./.review-approved 文件策略被評(píng)估 → Cedar: 對(duì) context.command_pattern gh pr review 判 forbid → 退出碼 2Claude Code 阻止該工具調(diào)用 → PostToolUse 運(yùn)行簽名一條 decisiondeny 的收據(jù)批準(zhǔn)后$ touch ./.review-approved $ agent: gh pr review 42 --comment --body LGTM → PreToolUse hook 運(yùn)行 → 檢測(cè)到 ./.review-approvedexit 0 → 工具調(diào)用執(zhí)行 → PostToolUse 簽名收據(jù)decisionallow, reasonhuman_approved $ rm ./.review-approved關(guān)于簽名鏈的一個(gè)審計(jì)預(yù)期當(dāng)審批標(biāo)記存在時(shí)PreToolUse 鉤子短路為exit 0不會(huì)調(diào)用protect-mcp evaluate。因此被批準(zhǔn)動(dòng)作對(duì)應(yīng)的 PostToolUse 收據(jù)會(huì)是decision: allow但沒(méi)有policy_digest字段因?yàn)闆](méi)有評(píng)估任何 Cedar 策略。審計(jì)人員遍歷收據(jù)鏈時(shí)應(yīng)預(yù)期這一現(xiàn)象被批準(zhǔn)的工具調(diào)用顯示為帶簽名的收據(jù)、reason: human_approved、無(wú)策略引用而被拒絕的工具調(diào)用與非 review 動(dòng)作它們確實(shí)經(jīng)過(guò) Cedar則照常攜帶policy_digest。八、收據(jù)鏈的離線驗(yàn)證與組合使用驗(yàn)證整條鏈npx veritasacta/verify ./review-receipts/*.json退出碼語(yǔ)義0表示每條收據(jù)都真實(shí)且鏈完整1表示某條收據(jù)被篡改2表示收據(jù)格式損壞。任何持有公鑰的一方都能離線驗(yàn)證不依賴(lài)操作者。與 protect-mcp 組合該插件聚焦審查面若要對(duì)所有 Claude Code 工具調(diào)用做通用策略強(qiáng)制可并排安裝 protect-mcp。兩個(gè)鉤子都會(huì)運(yùn)行、都會(huì)產(chǎn)出收據(jù)可配置不同的收據(jù)目錄如./receipts/與./review-receipts/保持鏈條分離。任一策略判 deny工具調(diào)用即被阻止。九、技術(shù)選型依據(jù)為什么是 Cedar Ed25519 收據(jù)CedarAWS 的開(kāi)源授權(quán)引擎以聲明式、形式化的方式表達(dá)策略審查者閱讀策略即可精確了解什么被門(mén)控?zé)o需讀代碼策略可通過(guò)cedar validate做類(lèi)型檢查策略變更可 diff。Ed25519 收據(jù)RFC 8032 簽名、RFC 8785 JCS 確定性規(guī)范化、hash-chained提供不依賴(lài)操作者的防篡改證據(jù)。任何篡改都會(huì)導(dǎo)致驗(yàn)證退出碼 1。涉及的完整標(biāo)準(zhǔn)棧Ed25519RFC 8032、JCSRFC 8785、CedarAWS、IETF 草案 draft-farley-acta-signed-receipts收據(jù)格式。十、參考資料與進(jìn)一步閱讀策略作者代理定義plugins/review-agent-governance/agents/review-policy-author.md插件默認(rèn)策略plugins/review-agent-governance/policies/review-agent-governance.cedar策略 Schemaplugins/review-agent-governance/policies/review-agent-governance.cedarschema運(yùn)行時(shí)鉤子配置plugins/review-agent-governance/hooks/hooks.json插件完整說(shuō)明含安裝步驟、審批窗口、示例會(huì)話plugins/review-agent-governance/README.md一次性安裝與每會(huì)話工作流plugins/review-agent-governance/skills/review-agent-setup/SKILL.md策略語(yǔ)言陷阱防護(hù)測(cè)試plugins/review-agent-governance/test/run-tests.sh通用策略強(qiáng)制插件可與本插件組合plugins/protect-mcp實(shí)際安裝時(shí)可先執(zhí)行claude plugin install wshobson/agents/review-agent-governance隨后將默認(rèn)策略復(fù)制到項(xiàng)目根目錄./review-governance.cedar并按第四節(jié)、第五節(jié)的方法定制最后按第七節(jié)的方式投入運(yùn)行。如需強(qiáng)制所有工具調(diào)用都走策略評(píng)估禁用審批旁路可設(shè)置REVIEW_APPROVAL_FLAG./.never-approve——這在 CI 或鎖定的審計(jì)運(yùn)行中尤為有用。【免費(fèi)下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項(xiàng)目地址: https://gitcode.com/GitHub_Trending/agents24/agents創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考