GitHub不认你的Copilot PR批准，笔记本却认：AI编码的职责分离缺口

你在GitHub上给Copilot云代理分配一个issue，几分钟后收到一个PR。你读完diff，觉得没问题，点了Approve。但合并规则会忽略这次点击：GitHub文档明确写道，「如果你的仓库要求PR批准，你对Copilot PR的批准不会计入所需数量」。必须另有评审者批准才能合并。

CI也在等待。默认情况下，Copilot向PR推送更改时，GitHub Actions工作流不会自动运行——需要有人先点击「Approve and run workflows」。

现在，在笔记本上做同样的事：你提示Claude Code或Codex，阅读diff，然后运行git merge。请求更改的人、评审更改的人、发布更改的人，三者合一。没有任何机制把计数变成二。

我的观点是：GitHub这条规则是对的，而且它不应该止步于github.com。职责分离必须跟随代理工作延伸到你的笔记本上。

GitHub如何处理代理的拉取请求

GitHub的云代理风险和缓解措施页面读起来像一份谨慎团队会提出的清单：

• 只有对仓库有写权限的用户才能触发代理，无写权限用户的评论永远不会传递给代理。
• 对于新工作，代理获得一个全新的copilot/分支，并且只能推送到该分支。
• 它「不能将其拉取请求标记为‘Ready for review’，也不能批准或合并拉取请求」。
• 它「受工作仓库的任何分支保护和必需检查约束」。
• 工作流会等待「具有写权限的用户点击Approve and run workflows按钮」。
• 页面列出的缓解措施还包括：GitHub「阻止请求Copilot云代理创建拉取请求的用户批准该PR」。

最后一条是最有趣的选择。Copilot是提交的作者，而请求更改的开发者被标记为共同作者。GitHub本可以将你视为机器人工作的外部评审者，但它没有。它把你放在了作者这一边。

这与GitHub对人类的既有规则一致。在必需评审页面上：「拉取请求作者不能批准自己的拉取请求。」同一页面还指出，如果「是你将Copilot分配给该issue」，你就不能批准Copilot发起的PR。编写提示的人被视为作者。

工作流这一半有一个退出选项。自2026年3月13日的更新日志起，仓库管理员可以为代理关闭「Require approval for workflow runs」。设置页面在旁边警告：这样做「可能允许Copilot编写的未经审查的代码」获得对仓库的写权限或触及Actions机密。批准默认保持开启。

分支保护规则（Branch Protection Rules） 是 GitHub 仓库管理员为特定分支设定的合并前置条件集合，常见项包括：要求至少一个批准、要求状态检查通过、禁止强制推送、要求线性历史等。规则通过仓库 Settings → Branches 配置，可针对分支名模式批量生效。其核心作用是让“合并”从个人操作变成受策略约束的流程。文章提到的“必需评审”“必需状态检查”均属此类。需要注意的是，规则默认对仓库管理员不生效，除非显式开启“Do not allow bypassing the above settings”，这也是后文“管理员缺口”的根源。

必需状态检查（Required Status Checks） 指分支保护中要求特定 CI 作业必须以成功状态结束才能合并的机制。检查由 GitHub Actions 或其他 CI 系统上报，与分支的最新提交 SHA 绑定；新推送会使旧检查失效。把测试作业设为必需检查，意味着“通过测试”从建议变成合并的硬门槛，即使评审者批准，检查未过也无法合并。这为没有第二个人工评审者的场景提供了一种可自动执行的第二方约束。

在笔记本上，你同时是三个人

NIST的术语表将职责分离定义为：「不应给任何用户足够的权限来独自滥用系统。」NIST给出的例子是两人规则。GitHub将其应用于代理拉取请求，而本地代理会话没有等价物。

在终端运行编码代理，它的提交会以你的git身份进入。它甚至可能是GitHub的代理：Copilot CLI「可以代表你执行任务，例如执行或修改文件，或运行shell命令」。同一供应商，同类工作。一旦这些提交属于你，并且你在本地合并它们，GitHub上就没有规则知道是代理写的。

不过，对笔记本公平一点。如果main受到保护并要求评审，直接推送会被拒绝：在启用必需评审的情况下，「协作者只能通过拉取请求将更改推送到受保护分支」。队友仍然必须批准。缺口出现在三个地方：

• 本地合并。 将git merge agent/fix-login合并到你部署的分支，或合并到一个稍后以大PR形式提交的分支，代理的部分被匆匆略过。
• 管理员。 「默认情况下，分支保护规则的限制不适用于对仓库有管理员权限的人。」在小团队中，运行代理的人通常就是管理员。
• 感觉像评审的评审。 你确实仔细阅读了代理的diff。但根据GitHub对Copilot PR的规则，你的阅读不算数，因为工作是你要求的。笔记本却把它算作唯一的评审。

工作流门禁也没有笔记本对应物。在GitHub上，默认情况下，代理对.github/workflows/的更改不会运行，直到有人批准，文档建议你「特别警惕」这类更改。在本地，代理编辑的测试命令会在你或代理下次调用时，在你选择的任何权限模式下于你的shell中运行。

git 身份（user.name / user.email） 是提交元数据中的作者与提交者字段，默认读取本地 git 配置，并不校验真实操作者。编码代理在本地运行时通常继承你的配置，因此它产生的提交在 GitHub 看来与你的手工提交无异，不会携带“由代理生成”的标记，也不会触发针对 Copilot 云代理的特殊规则。这正是本地会话能够绕过 GitHub 职责分离的技术原因：平台侧的所有代理约束都依赖“能识别出这是代理行为”，而本地提交在身份层面与人类提交不可区分。若希望事后追溯，可使用 Co-authored-by 尾注或提交签名，但这些都属于自愿约定，不构成强制门禁。

让第二把钥匙跟随代理

规则：代理分支作为拉取请求落地，由队友批准，并且你编写的检查决定工作何时完成。

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

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

--fill从提交中获取标题和正文，因此代理的提交信息成为评审者首先阅读的PR描述。如果它们含糊不清，请编辑它们。

然后在GitHub端为main的分支保护规则关闭缺口：

• 要求拉取请求评审，至少一个批准。
• 开启「Do not allow bypassing the above settings」，移除管理员豁免。
• 开启「Require approval of the most recent reviewable push」。根据受保护分支文档，「最近的可评审推送必须由推送者以外的人批准」。
• 要求状态检查通过，并将你的测试作业设为其中之一。

并为高风险路径指定所有者。Code owners「当有人打开修改他们拥有的代码的拉取请求时，会自动被请求评审」，而「Require review from Code Owners」使他们的批准成为强制性的：

**CODEOWNERS** 是仓库根目录、`docs/` 或 `.github/` 下的文本文件，按路径模式将代码区域映射到用户或团队。当 PR 修改匹配路径时，对应所有者会被自动请求评审；配合分支保护中的“Require review from Code Owners”，其批准成为合并的必要条件。匹配规则遵循“最后一个匹配模式优先”，因此通配行应放在前面、具体路径放在后面，否则通配行会覆盖后面的精细规则。CODEOWNERS 并不强制所有者本人推送，只强制其评审，因此适合为高风险目录（如工作流、部署脚本、认证模块）设置额外的人工关卡。
# .github/CODEOWNERS
*                   @acme/backend
.github/workflows/  @acme/platform

顺序很重要：「最后一个匹配模式具有最高优先级」，因此工作流行放在全匹配行之后。

在Hermes中连接这些

我构建了Hermes IDE，请带着这一点权衡本节。Hermes在各自的终端、各自的hermes/<task>分支和工作树上运行每个代理（Claude Code、Codex、Copilot CLI等），依据其README。

Review Desk（⌘G，Windows和Linux上为Ctrl+Shift+G）是你按轮次或按文件阅读代理工作的地方。这种阅读很有用，但按照GitHub的逻辑，它并不能使你成为第二个人。

所以关键部分是Land。根据README，Land「一步提交、打开拉取请求或本地合并，合并到任务开始的分支，并且可以撤销」。选择拉取请求，批准发生在GitHub上，你的分支规则适用。

同一README行补充道：「你自己的检查可以决定任务何时完成。」在那里运行与CI中必需状态检查相同的命令，以便本地的「完成」和GitHub的「可合并」一致。

Hermes不做什么：它不能强迫任何人批准任何事。必需评审是GitHub的职责，如果你选择本地合并，Hermes仍然会在本地合并。Hermes是免费的，基于BSL 1.1源代码可用，支持macOS、Windows和Linux，并且不隶属于Nous Research、Anthropic、OpenAI或GitHub。

这种做法的代价

独立开发者没有第二个人。那么你编写的检查就是第二方：它不知道谁请求了更改，也不关心代理听起来有多自信。跳过必需评审，将检查设为必需状态检查，并关闭你自己仓库的管理员绕过，这样连你自己也要经过它。

在团队中，代价是延迟：每个代理分支现在都要等待队友，就像Copilot云代理PR在github.com上已经做的那样。

你允许代理分支本地合并，还是代理写的所有内容都通过其他人批准的PR？