你让Copilot写的PR，GitHub不认你的批准

你给Copilot云端代理指派了一个issue。几分钟后，一个pull request出现了。你读完diff，看着没问题，点了Approve。但到了合并规则这一步，这一下点击被无视了。

GitHub文档写得很直白：如果仓库要求pull request审批，你对Copilot提交的PR的批准，不会计入所需数量。必须另有评审人点头，它才能合进去。CI也在等——默认情况下，Copilot向PR推送改动时，GitHub Actions工作流不会自动运行，得有人先点“Approve and run workflows”。

现在把同样的活搬到你的笔记本上。你在终端里给Claude Code或Codex下指令，读完diff，敲下git merge。提出改动的人、评审改动的人、发布改动的人，全是同一个。没有任何环节数到了二。

GitHub这条规则是对的，而且不该止步于github.com。职责分离必须跟着代理工作一起，落到你的笔记本上。

GitHub对代理PR做了什么

GitHub为云端代理列出的风险与缓解措施，读起来像一份谨慎团队会提的要求清单：

• 只有对仓库有写权限的用户才能触发代理，无写权限用户的评论永远不会传给它。
• 新任务会拿到一个全新的copilot/分支，代理只能往这个分支推。
• 它“不能把自己的pull request标记为Ready for review，也不能批准或合并pull request”。
• 它“受工作仓库的任何分支保护和必需检查约束”。
• 工作流会等待“有仓库写权限的用户点击Approve and run workflows按钮”。
• 页面把“GitHub阻止要求Copilot云端代理创建pull request的用户批准它”列为一项缓解措施。

最后一条是有意思的选择。Copilot是提交的作者，提出改动的开发者被标记为共同作者。GitHub本可以把你当成机器人工作的外部评审人，但它没有，它把你放到了作者那一侧。

这和GitHub对真人早就有的规则一致：pull request作者不能批准自己的PR。同一页面还写明，如果指派Copilot的人是你，你就不能批准它创建的PR。写提示词的人，算作者。

工作流那一半有个退出选项。自2026年3月13日的更新日志起，仓库管理员可以关掉针对代理的“工作流运行需审批”。设置页在旁边放了警告：这么做“可能让未经评审的Copilot代码”获得仓库写权限，或触达你的Actions密钥。审批默认是开着的。

GitHub想在代理的PR上装第二把钥匙。只拿提示词作者那把，开不了门。

在笔记本上，你一个人演三个角色

NIST的术语表把职责分离浓缩成一句：任何用户都不应拥有足以独自滥用系统的权限。它举的例子是双人规则。GitHub把它用在了代理PR上，而本地的代理会话没有对应物。

在终端里跑编码代理，它的提交落在你的git身份下。它甚至可能就是GitHub的代理：Copilot CLI“可以代表你执行任务，比如执行或修改文件、运行shell命令”。同一家厂商，同一类工作。一旦这些提交算你的，而你在本地合并了它们，GitHub上没有任何规则知道有代理写过它们。

不过也得对笔记本公平一点。如果main分支受保护且要求评审，直接推送会被拒绝：开启必需评审后，“协作者只能通过pull request向受保护分支推送改动”。队友仍然得批准。缺口开在三个地方：

• 本地合并。把agent/fix-login合进你部署用的分支，或合进一个之后打包成一个大PR、代理那部分被草草扫过的分支。
• 管理员。“默认情况下，分支保护规则的限制不适用于拥有仓库管理员权限的人。”小团队里，跑代理的人往往就是管理员。
• 看起来像评审的评审。你确实仔细读了代理的diff。可按GitHub对Copilot PR的规则，你的阅读不算数，因为活是你要求的。笔记本却把它当成唯一会有的那次评审。

工作流那道闸在本地也没有孪生兄弟。在GitHub上，默认情况下代理对.github/workflows/的改动要等人批准才会运行，文档提醒你对这类改动要“格外警惕”。本地呢，代理改过的测试命令，下次你或代理调用它时，就在你的shell里跑起来了，权限模式取决于你当初选的那个。

让第二把钥匙跟着代理走

规则可以这样定：代理分支以pull request的形式落地，由队友批准，再由你写的检查判定工作是否完成。

用GitHub CLI推分支、开PR，而不是直接合并：

git push -u origin agent/fix-login
gh pr create --base main --fill

--fill会从提交里取标题和正文，于是代理的提交信息成了评审人最先读到的PR描述。如果写得含糊，就改一改。

然后在GitHub侧补上缺口，改main的分支保护规则：

• 要求pull request评审，至少一个批准。
• 打开“不允许绕过上述设置”，去掉管理员豁免。
• 打开“要求批准最近一次可评审的推送”：最近一次可评审的推送，必须由推送者以外的人批准。
• 要求状态检查通过，把你的测试任务设为其中之一。

再给高风险路径指定负责人。代码负责人“在有人打开修改其所属代码的pull request时会被自动请求评审”，配合“要求代码负责人评审”，他们的批准就是强制的：

# .github/CODEOWNERS
* @acme/backend
.github/workflows/ @acme/platform

顺序有讲究：最后匹配的模式优先级最高，所以workflows那行要放在通配行之后。

代理报告说完成了。由你写的检查来拍板。

代价落在哪里

单人开发者没有第二个人。这时你写的检查就是第二方：它不知道是谁要求的改动，也不在乎代理听起来多自信。跳过必需评审，把检查设为必需状态检查，在自己仓库上关掉管理员绕过，连你自己也得走一遍。

在团队里，代价是延迟：每个代理分支现在都要等队友，就像github.com上的Copilot云端代理PR本来就要等一样。

你是让代理分支在本地直接合并，还是代理写的一切都得走一个由别人批准的PR？