开发者让 Agent 干的活里，有一半最后都落在 GitHub 上：读 Issue、看代码、修 bug、提 PR。很多朋友问 OpenClaw 怎么接 GitHub——配好了，你的 Agent 就能在真实仓库里干活，而不是只在聊天框里说说。
这篇讲 OpenClaw 接入 GitHub 的完整流程：先讲前置准备（最小权限 Token），再讲怎么通过 MCP 把仓库挂给 Agent，然后是常用操作和「自动提 PR」的实战流程，最后是代码审查场景和安全清单。全程照着做就行。
前置准备：申请最小权限 Token
接入 GitHub 第一步不是装东西，是先想清楚「要给 Agent 多大权限」。这一步想错了，后面全是坑。
强烈建议申请 fine-grained token（细粒度 Token），而不是一把梭的经典 Token：在 GitHub 设置里进入 Fine-grained tokens，选择要让 Agent 访问的仓库，然后按需勾选权限——比如只读代码就只给 Contents: Read；要提 PR 才给 Contents: Write + Pull requests: Write。别给 Admin，别用全仓库全权限的 Token。
为什么要抠这么细？Agent 密钥边界 里反复强调：Token 一旦泄露，权限有多大、损失就有多大。最小权限不只是安全洁癖，是 Agent 出问题时你能把损失关进笼子的最后一道闸。
接入：通过 MCP 把 GitHub 挂给 Agent
OpenClaw 接外部服务最标准的方式就是接 MCP（OpenClaw 怎么接 MCP 工具 有完整教程），GitHub 官方提供了 MCP server，配置三步走：
第一步，生成好上面的 Token（记下 GITHUB_TOKEN）；第二步，在 OpenClaw 配置里注册 GitHub MCP server，把 Token 填进环境变量；第三步，重启 OpenClaw，问它「看看我有哪些仓库」，能列出来就说明接上了。
接上后，Agent 就获得了对仓库的读写能力：读 Issue、读 PR、列文件、看 diff、建分支、提交代码、开 PR，全都能通过对话直接指挥。
常用操作：读 Issue、建分支、提 PR
日常最常用的三组操作，先跑熟：
读 Issue。「看看 repo 里 open 的 issue 有哪些」「这个 issue 的完整描述是什么」——让 Agent 帮你先建立对任务的理解。这是最安全的操作，权限只读就够。
看代码。「这个文件里处理异常的逻辑在哪」「帮我找一下这个函数的调用方」——Agent 能直接拉取文件内容分析，等于一个随时待命的代码讲解员。
建分支 + 改代码。「基于 main 建一个分支 fix-xxx，然后修复这个 bug」——Agent 会建分支、改文件、提交。注意第一次跑建议加个约束：「先给我看 diff，我确认了再提交」，给 Agent 建立「提交前确认」的习惯。
这三组操作跑顺了，再往上加复杂工作流就水到渠成。
实战：让 Agent 自动提一个 PR
自动提 PR 是 OpenClaw 接 GitHub 最爽的场景，完整流程长这样：
第一步，喂需求：「看 issue #12 描述的问题，在分支 fix-login-timeout 上修复，提交后开 PR，PR 描述写清楚改动内容和测试方法」。第二步，Agent 自动执行：读 issue → 拉代码 → 定位问题 → 改代码 → 提交 → 开 PR。第三步，你只需要在 PR 页做 review 和合并。
这里有两个建议：一是第一次让 Agent 走「先展示改动再提交」模式，你审一眼它改得靠不靠谱；二是把常用的提 PR 流程固化成技能（OpenClaw 自定义技能开发 有讲法），下次一句话「按老规矩修这个 issue」就能触发整套流程。跑熟之后，批量小修 bug、补测试、改文档这种活，基本可以交给 Agent 干，你只做最终验收。
进阶：用 Agent 做代码审查
除了写代码，Agent 在「审代码」上更值钱——毕竟看代码不用写，出错成本也低。
你可以让 Agent「review 这个 PR 的 diff，找出潜在的 bug、安全隐患、不符合项目风格的地方，按严重程度列出来」。它还能结合 Issue 上下文判断改动是否真正解决了问题，甚至检查测试有没有覆盖关键路径。这跟 Claude 自动维护 388 个 PR 的实验是同一个思路：写代码变便宜之后，审代码成了新瓶颈，而 Agent 恰好能当那个不知疲倦的审稿人。
注意：Agent 的 review 结论当「第一道筛子」用，重要改动还是得人最后拍板——模型有幻觉，AI Agent 幻觉治理 的原则在代码审查上同样适用。
安全清单：Token、审查、别乱 push
接 GitHub 的 Agent 是高风险目标，几条硬规矩：
Token 最小化（上面说过，只给需要的仓库、需要的权限）；Token 别明文写进配置文件——用 OpenClaw 的密钥管理或环境变量，权限管理 的底线是不能让密钥躺在配置文件里裸奔；先只读再写——第一次接入先用只读权限跑几天，确认行为正常再放开写权限；重要仓库开保护分支——main 分支设置 PR 审核才能合并，Agent 再能干也推不进去。
还有一条容易被忽略：告诉 Agent 什么不能做。在技能或系统提示词里写清楚「不允许 force push、不允许删除分支、不允许修改历史」——这类红线靠模型自觉不靠谱，写死约束才靠谱。
优缺点与适合人群
这套方案的好处：配置标准化（MCP 一条路）、Token 权限可控、能覆盖「读—改—审—提」全链路，把 Agent 从聊天工具升级成仓库里的同事；代价：第一次配置要花半小时理解权限模型，且 Agent 改代码的质量需要人工 review 兜底，不是全自动甩手。
适合：个人开发者（让 Agent 处理自己仓库的 issue 和琐碎 PR）、开源维护者（批量 triage issue、自动补文档）、小团队（让 Agent 当第二双眼睛审代码）。不适合：对合规要求极严、代码绝不允许第三方工具触碰的企业核心仓库——那种场景先把 OpenClaw 部署到服务器 做内网化再说。
总结
OpenClaw 接 GitHub 就三步：最小权限 Token + MCP 接入 + 从只读操作开始跑熟。最值得上的两个场景是「自动提 PR」（把琐碎修复交给 Agent）和「代码审查」（让 Agent 当第一道筛子）。记住三条安全规矩：Token 最小化、密钥不裸奔、红线写进提示词。配好了，你的 Agent 就是仓库里一个干活靠谱、随叫随到的新同事——但记住，重要的事还得你拍板。
