AutoGPT Platform GitHub Pull Requests 块全指南：PR 的创建、读取、审查与合并自动化

本指南围绕 AutoGPT Platform 内置的 GitHub Pull Requests 集成块展开，系统讲解 PR 列表查询、创建、内容读取、审阅人分配/解除、合并等 7 个 Block 的能力边界、输入输出约定与底层实现。读完你可以在可视化流程中串联出「依赖提交 → 自动建 PR → 分配审阅人 → 汇总变更并合并」的完整开发自动化链路。

背景：GitHub PR 操作块与集成机制

Pull Requests 块位于 GitHub 集成族中，覆盖协作开发的核心动作。它们全部归属 BlockCategory.DEVELOPER_TOOLS，所有块实例的注册代码集中在 pull_requests.py。所谓"块"，是平台中对输入 Schema 执行变换、产出结构化输出的可复用组件，可直接拖入工作流并在块之间连线传值。

PR 读取 → PR 审阅人分配 → 人工确认 → 合并

其中每个输入框（如 pr_url、repo_url、reviewer）都源于 Block 的 Input Schema；run() 方法将输入送入对应静态 API 封装函数并逐项产出（yield）输出字段；如果调用失败则捕获异常并产出 error 输出，驱动下游错误处理。从源码可确认每个 Block 有全局唯一的 id，便于在持久化的流程中被稳定引用。审阅相关块如 Assign/List/Unassign 实际调用的是 GitHub 的 requested_reviewers 端点，而 Read 块巧妙复用 Issue API。

认证前提：OAuth 或 API Key

PR 块所需凭据统一由 GithubCredentialsField 注入：

• OAuth2（默认平台配置了 github_client_id/secret 时提供，见 _auth.py）
• API Key（fine-grained PAT），需要足以支撑所用块操作的权限 scope

每个块声明了它需要的授权 scope，例如 Assign Reviewer 声明 repo 相关权限；该 scope 作为 required 字段参与凭据校验。实际 HTTP 通信在 _api.py 中的 get_api()：Requests 客户端把 https://github.com/... 的网页 URL 自动转换为 https://api.github.com/...，并附加 Authorization 与 GitHub v3 JSON 的 Accept 头。所以你在界面里填写的 PR 链接是普通网页形式，块内部会替你完成转换。

---

Github List Pull Requests：列出仓库的拉取请求

What it is：列出指定 GitHub 仓库中的 pull requests，输出 PR 标题与链接。

How it works：核心实现是 list_prs：

api = get_api(credentials)
pulls_url = repo_url + "/pulls"          # https://github.com/owner/repo → /pulls
response = await api.get(pulls_url)
data = response.json()
pull_requests = [{"title": pr["title"], "url": pr["html_url"]} for pr in data]

对照 GitHub API 语义，pulls 列表端点 默认返回处于 open 状态的 PR，因此该块天然适用于监控待合并的变更。run() 会先整体产出一次 pull_requests（完整列表），再逐个 yield 单个 pull_request，兼顾"一次性拿到全部"和"逐条流式处理"两种下游消费方式。

Inputs

Input	描述	类型	必填
repo_url	GitHub 仓库 URL	str	Yes

Outputs

Output	描述	类型
pull_request	单个 PR（title + url）	Pull Request
pull_requests	PR 列表（title + url）	List[PRItem]
error	请求失败时的错误信息	str

可选用途（摘自原文档）：

• PR 看板：聚合多个仓库的 open PR，形成跨仓库开发总览
• 合并队列监控：跟踪待处理 PR，为代码评审排优先级、识别瓶颈
• Stale PR 探测：配合时间判断找出长期未动、需要跟进的 PR

---

Github Make Pull Request：创建拉取请求

What it is：在指定仓库上创建一个新的 pull request。

How it works：调用 create_pr 向 GET /pulls 端点发起 POST：

data = {"title": title, "body": body, "head": head, "base": base}
response = await api.post(pulls_url, json=data)
pr_data = response.json()
return pr_data["number"], pr_data["html_url"]

• head 是你的变更所在分支（源分支）；跨仓库 PR（同一 fork 网络内）需以 username:branch 形式命名 head
• base 是变更要合入的目标分支
• 两个分支必须真实存在且存在分叉提交，PR 才能创建成功；在仓库下称 fork 用户推送前应等待其远端就绪

该 Block 的 __init__ 中给出了演示输入：head="feature-branch"、base="main"，测试期望输出为 PR number=1、url="https://github.com/owner/repo/pull/1"。

Inputs

Input	描述	类型	必填
repo_url	GitHub 仓库 URL	str	Yes
title	PR 标题	str	Yes
body	PR 描述正文	str	Yes
head	变更所在分支名；跨仓库 PR 需 username:branch	str	Yes
base	目标分支名	str	Yes

Outputs

Output	描述	类型
number	创建出的 PR 编号	int
url	创建出的 PR 链接	str
error	创建失败时的错误信息	str

可选用途：

• 自动发版：release 分支就绪时自动对 main 发 PR
• 依赖更新：测试通过后程序化地为依赖升级建 PR
• Feature Flags：自动打开配置文件中功能开关的 PR

---

Github Read Pull Request：读取 PR 详情与代码变更

What it is：读取指定 PR 的正文、标题、作者，并可选的完整代码改动。

How it works：实现分两层（read_pr 与 read_pr_changes）：

issue_url = pr_url.replace("/pull/", "/issues/")

read_pr 用 PR 的 issue 视图取得 title、body、user.login（作者），并对缺失字段提供兜底默认值（"No title found" 等）。read_pr_changes 则请求 pulls/{number}/files，逐个文件取 status 与 patch，重建类 unified diff 的头部：重命名/修改显示 --- 旧文件名 与 +++ 新文件名，新增文件省略旧名、被删除文件只保留旧名；最后所有文件 diff 用空行拼接成一份便于 LLM/评审消费的完整文本。

注意：include_pr_changes 是 bool，默认 False（见源码 SchemaField(default=False)）；开启后才会在 run() 中追加产出 changes。

Inputs

Input	描述	类型	必填
pr_url	PR 链接（如 https://github.com/owner/repo/pull/1）	str	Yes
include_pr_changes	是否返回 PR 的文件改动 diff	bool	No

Outputs

Output	描述	类型
title	PR 标题	str
body	PR 正文	str
author	PR 创建者用户名	str
changes	PR 的代码改动内容	str
error	读取失败时的错误信息	str

可选用途：

• 自动化代码评审：读取 PR 内容与改动后交给 AI 做代码分析
• Changelog 生成：抽取标题与描述自动汇编版本更新记录
• PR 摘要：为相关方生成 PR 进展摘要

---

Github Assign PR Reviewer：指派审阅人

What it is：为指定 PR 指派一名 code reviewer。

How it works：发送一个请求把目标用户名加入 PR 的 requested reviewers 列表，触发对该用户的评审通知。底层在 assign_reviewer：

reviewers_url = prepare_pr_api_url(pr_url=pr_url, path="requested_reviewers")
data = {"reviewers": [reviewer]}
await api.post(reviewers_url, json=data)

审阅人必须具备仓库访问权限。组织成员通常可被指派到他们至少有只读访问权限的任意仓库。

prepare_pr_api_url 是全文共用 URL 转换助手（源码）：用正则提取 scheme/host/repo/pull 编号 后拼接出 https://…/pulls/{编号}/{path}。测试文件 test_github_blocks.py 覆盖了它的各种输入：http/https 保留、无 scheme 默认补全 https://、以及 URL 格式不合法时原样返回以保证安全兜底。

Inputs

Input	描述	类型	必填
pr_url	GitHub PR 链接	str	Yes
reviewer	要指派的审阅人用户名	str	Yes

Outputs

Output	描述	类型
status	指派操作的状态（成功时如 "Reviewer assigned successfully"）	str
error	指派失败时的错误信息	str

可选用途：

• 自动评审分配：根据改动文件或 PR 作者自动决定审阅人
• 轮询评审（Round-Robin）：在团队成员间均衡分配评审负载
• 按专长路由：把 PR 指派给被改动代码领域的专家

---

Github List PR Reviewers：列出 PR 的审阅人

What it is：列出某个 PR 的全部审阅人。

How it works：查询 list_reviewers，请求 requested_reviewers 端点并从响应 users 数组中提取 login（用户名）与 html_url（主页 URL）：

reviewers = [{"username": r["login"], "url": r["html_url"]} for r in data.get("users", [])]

值得注意的是，GitHub 的 requested_reviewers 端点返回的是"待处理的评审请求"；而针对"已提交评审的用户"应使用 reviews 端点——平台上分别有 reviews.md 对应的评审块。不过按块内"How it works"的官方描述，该块返回的范围既包括 pending review 请求也包括已提交评审的用户（对已有提交会同时出现于该列表中）。为精确起见：若你要跟踪"谁真正提交了 review"，请结合 Reviews 集成使用。

Inputs

Input	描述	类型	必填
pr_url	GitHub PR 链接	str	Yes

Outputs

Output	描述	类型
reviewer	单个审阅人（username + url）	ReviewerItem
reviewers	审阅人列表	List[ReviewerItem]
error	请求失败时的错误信息	str

可选用途：

• 评审状态监控：确认谁被指派、给未响应者发提醒
• 工作流校验：合并前验证必需审阅人已指派
• 团队看板：跨多个 PR 展示评审负载，提升团队可视性

---

Github Unassign PR Reviewer：移除审阅人

What it is：把某个审阅人从 PR 的 review request 列表中移除。

How it works：unassign_reviewer 与 Assign 对称，只是 HTTP 动词改为 DELETE 且 payload 保持 {"reviewers": [reviewer]}。移除后 GitHub 不再向该用户发送评审通知，适用于改派或处理不可用的评审人。

Inputs

Input	描述	类型	必填
pr_url	GitHub PR 链接	str	Yes
reviewer	要移除的审阅人用户名	str	Yes

Outputs

Output	描述	类型
status	移除操作的状态（如 "Reviewer unassigned successfully"）	str
error	移除失败时的错误信息	str

可选用途：

• 评审改派：把不可用的评审人替换为在线的团队成员
• 负载均衡：解除待办评审过多的评审人
• 休假代班：自动移除处于休假状态、无法响应的评审人

---

Github Merge Pull Request：合并拉取请求

What it is：用 merge / squash / rebase 三种方式之一合并 PR。

How it works：merge_pr 调用 GitHub Merge API（对 pulls/{number}/merge 发 PUT）：

data = {"merge_method": merge_method}
if commit_title:   data["commit_title"] = commit_title
if commit_message: data["commit_message"] = commit_message
response = await api.put(merge_url, json=data)
return result["sha"], result["merged"], result["message"]

三种 merge 方式的语义区别：

merge_method	行为
merge	产生一个常规 merge commit，保留分支历史
squash	将 PR 全部提交压缩为一个 commit（默认）
rebase	把提交逐个重放到 base 分支之上

commit_title / commit_message 为可选，仅对 merge 与 squash 生效；传空字符串（默认）时不包含在请求中，交由 GitHub 按默认策略生成。返回内容为合并 commit 的 SHA、是否合并成功（bool）、状态 message。

关键安全设计：该块在注册时设置了 is_sensitive_action=True（源码）——平台会将其识别为敏感操作，需要额外的执行确认环节，防止流程误触合并。此外，测试套件专门验证了错误路径：当 merge_pr 抛出异常时，run() 产出 error，最终由框架转换为 BlockExecutionError（见 test_merge_pr_error_path）。这提示你在编排时，应在 Merge 块之后接错误分支，捕获合并失败（如冲突、非可合并状态）并自动通知。

Inputs

Input	描述	类型	必填
pr_url	GitHub PR 链接	str	Yes
merge_method	合并方式："merge" / "squash" / "rebase"	Literal	No（默认 merge）
commit_title	merge/squash 时的合并 commit 标题（可选）	str	No
commit_message	merge/squash 时的合并 commit 信息（可选）	str	No

Outputs

Output	描述	类型
sha	合并 commit 的 SHA	str
merged	PR 是否已合并	bool
message	合并状态消息	str
error	合并失败时的错误信息	str

可选用途：

• CI/CD 流水线：所有检查通过并取得必要审批后自动合并
• 发版自动化：release 分支以 squash 合入 main，保持提交历史整洁
• 依赖更新：测试通过后自动合并机器人创建的次要依赖升级 PR

---

组装实战：把 7 个块串成 PR 工作流

综合上述块能力，一个典型的"开发运维 Agent"工作流可以这样连：

1. Github Multi-File Commit / repo_files 块 提交代码到特性分支（相关能力见 commits.md）；
2. Github Make Pull Request 以 head=特性分支、base=main 自动建 PR，输出 number/url；
3. Github Assign PR Reviewer 按改动文件或作者规则自动指派审阅人；
4. Github Read Pull Request（开启 include_pr_changes）把 PR 摘要与 diff 喂给 LLM 做静态审查；
5. 人工闸门 + Github Merge Pull Request（squash 并携带规范 commit 信息）完成合并，成功/失败消息推送到通知渠道。

其中第 2 步生成的 PR 链接可直接作为第 3/4 步的 pr_url，第 4 步输出可再做条件分支。对"谁尚未评审"的跟踪则用 Github List PR Reviewers，必要时用 Github Unassign PR Reviewer 改派。

边界与前置条件小结

• 权限 scope：所有块都要求 GitHub 凭据具备相应权限（如对 repo 的读取与 PR 写权限）；OAuth 与 fine-grained PAT 均可，但需满足 GithubCredentialsField 声明的最小 scope。
• URL 约定：块输入统一接受网页形式 URL（…/pull/1 或 …/owner/repo）；底层 _api.py 会自动转换为 api.github.com 端点，你无需手动改写。
• 分支约束：Make Pull Request 要求 head/base 分支存在且历史出现分叉；跨 fork 时必须用 username:branch 形式的 head。
• 敏感动作：Merge 块被标记为敏感操作，实际运行时通常需要人工确认步骤；错误路径（冲突、401、超出速率限制等）一律从 error 输出捕获。

可继续阅读同族文档深入扩展：commits.md（提交）、reviews.md（评审记录）、checks.md（CI 检查）、triggers.md（触发类块）；底层实现细节见 pull_requests.py 与其测试 test_github_blocks.py。