AutoGPT 的 PR 评论闭环处理：pr-address 技能从抓取评论到 CI 全绿的全流程实战

本文以 AutoGPT 仓库内置的 pr-address Agent 技能（SKILL.md）为核心，系统讲解如何自动化地处理 Pull Request 评审意见：如何绕过 GraphQL 分页的经典陷阱抓取全部评论、如何保证"修复 → 提交 → 推送 → 回复 → 解决"这一有效闭环不被假解决破坏、如何在 CI 轮询循环中同时跟踪构建状态与新评论，以及遭遇 GitHub 三级速率限制时的 REST 降级方案。读完本文，你将掌握一套可在 gh CLI 上直接复制运行的 PR 收尾工作流，并理解 AutoGPT 团队（codecov.yml、orval.config.ts 等配套配置）对该流程的硬性质量约束。

技能定位：一个可被用户直接调用的 PR 收尾流程

pr-address 是 AutoGPT 仓库 .claude/skills/ 目录下的一组开发协作技能之一，其 frontmatter 声明了触发条件与调用方式：

name: pr-address
description: Address PR review comments and loop until CI green and all comments resolved.
             TRIGGER when user asks to address comments, fix PR feedback, respond to reviewers,
             or babysit/monitor a PR.
user-invocable: true
argument-hint: "[PR number or URL] — if omitted, finds PR for current branch."
metadata:
  author: autogpt-team
  version: "1.0.0"

也就是说，当用户要求"处理 PR 评论""修复评审反馈"或"盯着这个 PR"时触发，且参数可以省略——省略时自动根据当前分支查找对应 PR。它与同目录的 open-pr、pr-test、pr-review 构成 PR 生命周期链路，并作为步骤名被上层多 Agent 编排技能 orchestrate 引用：编排器通过 CHECKPOINT:pr-address 与 ORCHESTRATOR:DONE 标记跟踪该流程的完成度，并会用 GraphQL 复核"0 未解决线程 + CI 全绿"后才回收工作区。本文按技能文档的流程顺序展开。

第一步：定位 PR 并读懂描述

处理评论之前必须先锁定 PR。技能文档给出的做法是按当前分支查 PR，再查看 PR 详情：

gh pr list --head $(git branch --show-current) --repo Significant-Gravitas/AutoGPT
gh pr view {N}

然后先读 PR 描述再动手——技能明确要求理解描述中的 Why / What / How，因为上下文决定修复方向：

gh pr view {N} --json body --jq '.body'

这里有一个隐含依赖：gh pr view 底层走的是 GraphQL API，一旦 GraphQL 配额耗尽该命令会失败。技能文档为此专门准备了 REST 降级（见"GitHub 速率限制"一节），可用等价的 REST 调用替代：

gh api repos/Significant-Gravitas/AutoGPT/pulls/{N} --jq '.body'      # 等价于 --json body
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N} --jq '.base.ref'  # 等价于 --json baseRefName
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N} --jq '.mergeable' # 等价于 --json mergeable

注意两者 mergeable 字段语义差异：REST 返回 true|false|null，GraphQL 返回 MERGEABLE|CONFLICTING|UNKNOWN；REST 的 null 对应 GraphQL 的 UNKNOWN（GitHub 仍在计算合并性），处理方式为"当作 UNKNOWN，等下个轮询周期再看"。

抓取评论：三个来源，一条铁律

来源一：内联评审线程（GraphQL，主信源）

这是可执行反馈项的主要来源。技能文档在此处放了一段醒目的警告，指出了 Agent 处理 PR 时最常见的失败模式：

reviewThreads(first: 100) 每页最多返回 100 条线程，且按最旧优先排序。对于一个经历多轮评审的 PR（例如 373 条线程），最旧的一两百条往往来自早已结束的历史评审周期、全部已解决。若在第一页就用 select(.isResolved == false) 客户端过滤，会得到 0 条结果——尽管第 2～4 页仍有大量来自最新评审周期的未解决线程。文档给出的真实案例：一个 142 条线程的 PR，第 1 页过滤后为 0，而第 2～3 页有 111 条未解决；另一个 373 条、跨 4 页的 PR 同样是第 1 页全部已解决。

规则因此只有一条：无论每页有多少未解决项，都必须分页翻到 hasNextPage == false，绝不能因为某页返回 0 条未解决就提前停止。

文档将整个抓取过程拆成三步。

Step 1 — 先取总数并抽查最新线程（last: 100 按最新优先返回，仅作健康信号）：

# Get total count and the newest 100 threads (last: 100 returns newest-first)
gh api graphql -f query='
{
  repository(owner: "Significant-Gravitas", name: "AutoGPT") {
    pullRequest(number: {N}) {
      reviewThreads { totalCount }
      newest: reviewThreads(last: 100) {
        nodes { isResolved }
      }
    }
  }
}' | jq '{ total: .data.repository.pullRequest.reviewThreads.totalCount, newest_unresolved: [.data.repository.pullRequest.newest.nodes[] | select(.isResolved == false)] | length }'

若 total > 100，说明存在多页，必须执行下面的完整分页循环，newest_unresolved 只是参考信号。

Step 2 — 跨全部分页累积所有未解决线程 ID：

# Accumulate all unresolved threads — loop until hasNextPage == false
CURSOR=""
ALL_THREADS="[]"
while true; do
  AFTER=${CURSOR:+", after: \"$CURSOR\""}
  PAGE=$(gh api graphql -f query="
  {
    repository(owner: \"Significant-Gravitas\", name: \"AutoGPT\") {
      pullRequest(number: {N}) {
        reviewThreads(first: 100${AFTER}) {
          pageInfo { hasNextPage endCursor }
          nodes {
            id
            isResolved
            path
            line
            comments(last: 1) {
              nodes { databaseId body author { login } }
            }
          }
        }
      }
    }
  }")
  # Append unresolved nodes from this page
  PAGE_THREADS=$(echo "$PAGE" | jq '[.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false)]')
  ALL_THREADS=$(echo "$ALL_THREADS $PAGE_THREADS" | jq -s 'add')
  HAS_NEXT=$(echo "$PAGE" | jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage')
  CURSOR=$(echo "$PAGE" | jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor')
  [ "$HAS_NEXT" = "false" ] && break
done

# Reverse so newest threads (last pages) are addressed first — GitHub returns oldest-first
ALL_THREADS=$(echo "$ALL_THREADS" | jq 'reverse')

echo "Total unresolved threads: $(echo "$ALL_THREADS" | jq 'length')"
echo "$ALL_THREADS" | jq '[.[] | {id, path, line, body: .comments.nodes[0].body[:200]}]'

几个实现细节值得注意：

• 为什么要 reverse？ GraphQL 按最旧优先返回线程且不暴露 orderBy 选项。373 条线程的 PR 跨 4 页，最新一轮评审周期的评论落在最后几页——那才是真正阻塞 approve 的内容。倒序处理保证"最新、最阻塞"的评论先被处理，靠前的页面大多是过时线程。
• comments(last: 1) 取线程中最新一条评论作为行动依据，它代表评审者的最终诉求；
• 线程的 Relay 全局 id 用于跨轮询周期跟踪同一条线程；
• 跳过 isResolved: true 的线程。

Step 3 — 逐条处理 ALL_THREADS 后再 resolve。 只有分页循环跑完（所有页已抓取、计数已确认）之后才开始写修复代码。

来源二：顶层 Review（REST，必须分页）

gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews --paginate

这一路是纯 REST，不受 GraphQL 限速或故障影响——即使 GraphQL 配额耗尽也应照常轮询。

关键约束：必须加 --paginate。 Reviews 默认每页 30 条，而 PR 可能有 80～170 条 review（其中大量是空正文的解决事件）。不分页就会漏掉第 30 条之后的 review——包括 autogpt-reviewer 的结构化评审，它通常在几轮 CI 之后才发布，位置远在第一页之后。

需要提取两类信息：

• 总体状态：查找 CHANGES_REQUESTED 或 APPROVED 类型的 review；
• 可执行反馈：只看非空正文。空正文的 review 是线程解决事件，表示进展但没有可行动内容。

文档还列出了各类评审者的发布位置，决定去哪里找它们的意见：

评审者	发布位置	处理方式
autogpt-reviewer	顶层 review（"Blockers" / "Should Fix" / "Nice to Have" 结构化清单）	并非每个 PR 都有；出现的条目全部处理
sentry[bot]	内联线程（bug 预测）	真 bug 就修，误报要解释原因
coderabbitai[bot]	顶层 review（摘要）+ 内联线程（可执行项）	处理可执行项
人类评审者	任意位置	处理所有非空反馈

来源三：PR 对话区评论（REST）

gh api repos/Significant-Gravitas/AutoGPT/issues/{N}/comments --paginate

同样是 REST，不受 GraphQL 限速影响。该区域大多是机器人摘要（coderabbitai[bot]）、CI/冲突检测（github-actions[bot]）和作者自己的进度更新。需要回应的是非空、非机器人、非 PR 作者的消息。

有效解决序列：fix → commit → push → reply → resolve

技能文档对此用了"CRITICAL"级别的措辞：唯一合法的序列是 fix → commit → push → reply → resolve，绝不允许在没有真实代码提交的情况下 resolve 线程。

原因是：用 resolveReviewThread 在没有任何实际修改的情况下把线程标记为已解决，是最常见的失败模式——未解决计数确实下降了，但没有任何真实变更，产生"完成"的假信号。只有在评论确属误报（无需改代码）时，才可以回复解释原因后再 resolve；否则必须完整走一遍序列，且逐条处理：

1. 阅读被引用的代码，做出修复（或回复解释为何不需要改）；
2. 提交并推送修复；
3. 以内联回复（而不是新开顶层评论）引用修复提交——这是机器人评审者（coderabbitai、sentry）判定对话已解决的方式；
4. 最后才调用 resolve。

回复模板要求使用 markdown 提交链接让 GitHub 渲染成可点击引用，并且 SHA 必须在提交后用 git rev-parse HEAD 现场取全量值——绝不能复制历史提交的 SHA 或硬编码：

FULL_SHA=$(git rev-parse HEAD)
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments/{ID}/replies \
  -f body="🤖 Fixed in [${FULL_SHA:0:9}](https://github.com/Significant-Gravitas/AutoGPT/commit/${FULL_SHA}): <description>"

按评论类型选择回复端点：

评论类型	回复方式
内联评审（pulls/{N}/comments）	gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments/{ID}/replies -f body="🤖 Fixed in abc1234: <description>"
对话区（issues/{N}/comments）	gh api repos/Significant-Gravitas/AutoGPT/issues/{N}/comments -f body="🤖 Fixed in abc1234: <description>"

什么才算"有效解决"

只有两种情况允许调用 resolveReviewThread：

1. 真实代码修复：改了代码、提交并推送、回复中附了 SHA。且提交 diff 必须真正回应了该问题——仅仅"碰了同一个文件"不算；
2. 确凿的误报：评审者的关切不适用于这段代码，且能给出具体技术理由（文档示例："sdk_cwd 在到达该点前已被 _make_sdk_cwd() 做 normpath + 前缀断言校验，不适用"）。

同时列出了看似解决、实则没有的反模式，明令禁止：

• "Accepted, tracked as follow-up" —— 这是延期，不是修复，问题仍然开着，不许 resolve；
• "Acknowledged" / "Same as above" —— 是确认收到，不是修复，不许 resolve；
• "Fixed in abc1234" 但 abc1234 并没有改动被标记的行/逻辑 —— 文档称之为"不诚实"，发布前必须用 git show abc1234 -- path/to/file 验证确实改对了地方；
• 不回复就 resolve —— 评审者根本不知道发生了什么。

拿不准时的原则：如果需要改代码，就改。 被延期的问题意味着线程保持打开，直到后续 PR 合入。

Codecov 覆盖率：80% 的 patch 目标

技能文档指出 Codecov 的 patch 目标是变更行的 80%，且该 check 是 informational（不阻塞）但应当保持绿色。这一点与仓库根目录的 codecov.yml 完全吻合：

coverage:
  status:
    patch:
      platform-backend:
        target: 80%
        flags: [platform-backend]
      platform-frontend:
        target: 70%
        flags: [platform-frontend]
      autogpt-libs:
        target: 80%
        informational: true
        flags: [autogpt-libs]
      classic:
        target: 80%
        informational: true
        flags: [autogpt-agent]

可以看到后端 patch 目标正是 80%，前端为 70%，且按 flags 将 autogpt_platform/backend/、autogpt_platform/frontend/src/、autogpt_platform/autogpt_libs/ 与 classic/ 四个组件分账统计，全部开启 carryforward: true。

本地跑覆盖率

后端（在 autogpt_platform/backend/ 下）：

poetry run pytest -s -vv --cov=backend --cov-branch --cov-report term-missing

前端（在 autogpt_platform/frontend/ 下）：

pnpm vitest run --coverage

codecov/patch 失败时的排查路径

1. 找出未覆盖的文件：git diff --name-only $(gh pr view --json baseRefName --jq '.baseRefName')...HEAD
2. 对每个未覆盖文件——把内联逻辑抽到 helpers.ts / helpers.py 并为它们写测试（投入产出比最高）。测试文件按仓库约定就近放置：后端 *_test.py，前端 __tests__/*.test.ts；
3. 本地跑覆盖率验证，提交，推送。

此外文档还给了针对单模块的快速验证命令：

cd autogpt_platform/backend
poetry run pytest --cov=. --cov-report=term-missing {path/to/changed/module}

查看标记为 miss 的行即未覆盖行，并为此前写的任何新代码补测试。配套规则有三条：新增代码必须有测试；修评论时不得顺手删已有测试；如果评审者要求删除某段代码，其测试一并删除，但要验证剩余行的覆盖率没有下降。

格式化与提交：改完先格式化，API 变了要重生成客户端

修复完成后，按仓库既有命令格式化改动代码——这些命令都能在仓库配置中逐一找到出处：

• 后端（autogpt_platform/backend/）：poetry run format。对应 pyproject.toml 中定义的 Poetry 脚本 format = "scripts.linter:format"；
• 前端（autogpt_platform/frontend/）：pnpm format && pnpm lint && pnpm types。对应 package.json 中的脚本：format 为 next lint --fix; prettier --write .，lint 为 next lint && prettier --check .，types 为 tsc --noEmit。

如果 API 路由有改动，必须重新生成前端客户端，技能文档给出了完整的守护脚本（起临时后端服务、轮询 health、生成、清理）：

cd autogpt_platform/backend && poetry run rest &
REST_PID=$!
trap "kill $REST_PID 2>/dev/null" EXIT
WAIT=0; until curl -sf http://localhost:8006/health > /dev/null 2>&1; do sleep 1; WAIT=$((WAIT+1)); [ $WAIT -ge 60 ] && echo "Timed out" && exit 1; done
cd ../frontend && pnpm generate:api:force
kill $REST_PID 2>/dev/null; trap - EXIT

这条链路的每一步都有仓库配置佐证：

• poetry run rest 来自 pyproject.toml 的 rest = "backend.rest:main" 入口；
• pnpm generate:api:force 对应 package.json 中的 npx --yes tsx ./scripts/generate-api-queries.ts --force && orval --config ./orval.config.ts；
• 生成位置由 orval.config.ts 决定：以 ./src/app/api/openapi.json 为输入，输出到 ./src/app/api/__generated__/endpoints 与 ./__generated__/models，采用 tags-split 模式、react-query 客户端 + msw mock。

因此文档才有那条禁令：永远不要手改 src/app/api/__generated__/ 下的任何文件——它们是 orval 的生成产物，手改会在下次生成时被覆盖。

提交方面文档要求：立即提交并立即推送，不要把多个修复攒成一批再推——每个修复应立刻在 GitHub 可见，CI 才能开始跑、评审者才能看到进展；绝不推送空提交（git commit --allow-empty）来重触发 CI 或机器人检查——检查失败时应去排查根因（PR checklist 未勾、评审评论未处理、代码问题）并直接修复，空提交只会污染 git 历史。在 worktree 中的后端提交则使用 poetry run git commit 以走 pre-commit 钩子。

主循环：30 秒一拍的 CI + 评论双重轮询

推送之后进入收尾循环，整体形态是：

address comments → format → commit → push
→ wait for CI (while addressing new comments) → fix failures → push
→ re-check comments after CI settles
→ repeat until: all comments addressed AND CI green AND no new comments arriving

轮询的要点是在一个循环里同时盯 CI 状态和新评论，且文档明确警告：不要使用 gh pr checks --watch——它会阻塞整个工具调用，导致 CI 运行期间无法响应新评论。gh pr checks --watch --fail-fast 同样诱人但同样阻塞，所以必须手动轮询。

每 30 秒执行一次，共 4 个动作：

1. 检查 CI 状态：

gh pr checks {N} --repo Significant-Gravitas/AutoGPT --json bucket,name,link

解析规则：所有 check 的 bucket 均为 "pass" 或 "skipping" 则 CI 全绿；任一为 "fail" 则 CI 失败；其余情况视为仍在 pending。

2. 检查合并冲突：

gh pr view {N} --repo Significant-Gravitas/AutoGPT --json mergeable --jq '.mergeable'

"CONFLICTING" 表示有合并冲突，转入下文流程；"UNKNOWN" 表示 GitHub 仍在计算合并性，等下个周期再查。

3. 检查新/变评论（三个来源全查）：

• 内联线程——重跑"抓取评论"里的 GraphQL 查询，为每个未解决线程记录基线 {thread_id, last_comment_databaseId}。轮询时出现新情况即需行动：出现基线外的新线程 id（新线程），或已有线程的 last_comment_databaseId 变化（线程内新回复）；
• 对话区评论——gh api repos/Significant-Gravitas/AutoGPT/issues/{N}/comments --paginate，对比总数与最新 id 相对基线的变化，过滤掉空消息、机器人和作者自更；
• 顶层 review——gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews --paginate，盯新的非空 review（带正文的 CHANGES_REQUESTED 或 COMMENTED）。

4. 按以下优先级响应（先匹配先生效）：

发生了什么	动作
检测到合并冲突	转入"解决合并冲突"流程
合并性为 UNKNOWN	GitHub 仍在计算。睡 30 秒后从头重启轮询
检测到新评论	处理它们（fix → commit → push → reply）。推送后重新抓取全部评论更新基线，再从头重启轮询（新提交会使 CI 状态失效）
CI 失败（bucket == "fail"）	用 gh pr checks {N} ... --json bucket,link --jq '.[] | select(.bucket == "fail") | .link' 取失败检查链接；从链接中提取 run ID（格式 .../actions/runs/<run-id>/job/...）；用 gh run view <run-id> --repo Significant-Gravitas/AutoGPT --log-failed 读日志；修复 → commit → push → 重启轮询
CI 全绿 + 无新评论	不要立刻退出。 机器人（coderabbitai、sentry）常在 CI settle 后立刻发 review。CI 转绿后继续轮询 2 个周期（60 秒），连续 2 次"绿且安静"才允许退出
CI pending + 无新评论	睡 30 秒再轮询

循环的退出条件是三者同时满足：CI 完全全绿 + 所有评论已处理 + CI 稳定后连续 2 次轮询无新评论。最后一条是针对机器人评审节奏的经验规则——CI 刚转绿时往往是 autogpt-reviewer 或 sentry[bot] 即将落子的时刻，过早退机会漏掉最后一轮反馈。

解决合并冲突

# 1. 确定 PR 的目标分支与远程
gh pr view {N} --repo Significant-Gravitas/AutoGPT --json baseRefName --jq '.baseRefName'
git remote -v   # 找指向 Significant-Gravitas/AutoGPT 的远程：fork 场景通常是 'upstream'，直接贡献者是 'origin'

# 2. 以三路合并拉取最新基线分支
git pull {base-remote} {base-branch} --no-rebase

# 3. 解决冲突文件后，验证无冲突标记残留
if grep -R -n -E '^(<<<<<<<|=======|>>>>>>>)' <conflicted-files>; then
  echo "Unresolved conflict markers found — resolve before proceeding."
  exit 1
fi

# 4. 暂存并推送
git add <conflicted-files>
git commit -m "Resolve merge conflicts with {base-branch}"
git push

# 5. 从头重启轮询循环 —— 新提交会重置 CI 状态

GitHub 速率限制：三种限制、三套恢复策略

自动化流程最大的环境风险是 GitHub 的速率限制。文档将三者区分得很清楚——成因、错误形态、恢复时间都不同：

错误	HTTP 码	成因	恢复
{"code":"abuse"}	403	次级限制——短时间内写操作（评论、mutation）过密	等 2～3 分钟，60 秒往往不够
{"message":"API rate limit exceeded"}	429	主 REST 限制——每用户 5000 次/小时	等到 X-RateLimit-Reset 头的时间戳
GraphQL: API rate limit already exceeded for user ID ...	stderr 403，gh 退出码 1	GraphQL 专属的每用户限制，独立于 REST 的 5000/小时和 abuse 次级限制；因按查询点数计费，比 REST 更快触发	等到 GraphQL 窗口重置（通常距窗口内首次调用约 1 小时）；期间 REST 仍可用，用下述降级方案

预防手段：单次线程回复之间 sleep 3；批量发超过 20 条回复时加大到 sleep 5。

探测配额

gh 在 stderr 上以精确字符串 GraphQL: API rate limit already exceeded for user ID <id> 呈现 GraphQL 超限并退出 1——此时任何 gh api graphql ... 或 gh pr view ... 都会失败。用 REST 的 rate_limit 端点（该调用本身走 REST，在 GraphQL 限速甚至完全宕机时依然可用）查看当前配额与重置时间：

gh api rate_limit --jq '.resources.graphql'   # { "limit": 5000, "used": 5000, "remaining": 0, "reset": 1729...}
# 人类可读的重置时间：
gh api rate_limit --jq '.resources.graphql.reset' | xargs -I{} date -r {}

remaining > 0 时重试。若需要更早继续，睡 2～5 分钟再探测——该限制按用户计而非按机器计，同一 token 下的并发 Agent 会共同消耗配额。

GraphQL 不可用时，什么还能动

• 仍可用（REST）：顶层 review 抓取、对话区评论抓取、所有内联评论回复、CI 状态（gh pr checks）、gh api rate_limit 探测；
• 降级：内联线程列表——退回扁平的 /pulls/{N}/comments REST 接口，失去线程分组、isResolved 和 Relay 线程 ID，但仍能拿到评论正文与 databaseId（作为 id），足够"读 + 回复"：

gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments --paginate \
  | jq '[.[] | {id, path, line, user: .user.login, body: .body[:200], in_reply_to_id}]'

用这个降级模式把 fix → reply 循环往前推，等 GraphQL 限额重置后再回来做 resolveReviewThread；

• 完全阻塞：gh pr view、resolveReviewThread mutation 以及任何新的 gh api graphql 查询——只能等配额重置。

resolveReviewThread 没有 REST 等价物，GitHub 不暴露线程解决的 REST 端点。正确做法是把待解决的线程 ID 排队，等 GraphQL 限额重置后批量执行 resolve mutation（按次级限制的建议，每次调用之间 sleep 3）。

从次级限制（403 abuse）恢复

1. 立即停止所有 API 写操作；
2. 至少等 2 分钟（不是 60 秒——次级限制更严格）；
3. 恢复后每次调用之间保持 sleep 3；
4. 若 2 分钟后仍 403，再等 2 分钟重试。

永远不要把回复挤在紧密循环里一次性发完——必须拉开间隔。

批量场景：按文件分组 + 并发回复

当一个 PR 有 10 条以上未解决线程时，"一线程一提交"太慢。文档给出的提速策略是按文件分组、每文件一批提交：

1. 将 ALL_THREADS 按 path 排序——同一文件内的线程可以共享一个提交；
2. 修完一个文件里的全部线程 → git commit → git push → 用同一个 SHA 回复该文件的所有线程 → 全部 resolve；
3. 移到下一个文件组，重复。

这把 N 次提交压缩到"涉及文件数"次，通常从 15～30 次降到 3～5 次。

对真正相互独立的线程组（不同文件、无共享逻辑），还可以用后台子 shell 并发发回复，但写操作之间仍必须拉开间隔：

# Post replies to a batch of threads concurrently, 3s apart
(
  sleep 3
  gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments/{ID1}/replies \
    -f body="🤖 Fixed in [${FULL_SHA:0:9}](https://github.com/Significant-Gravitas/AutoGPT/commit/${FULL_SHA}): ..."
) &
(
  sleep 6
  gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments/{ID2}/replies \
    -f body="🤖 Fixed in [${FULL_SHA:0:9}](https://github.com/Significant-Gravitas/AutoGPT/commit/${FULL_SHA}): ..."
) &
wait  # wait for all background replies before resolving

回复并发、resolve 串行（GraphQL mutation 逐个执行）：

for THREAD_ID in "$THREAD1" "$THREAD2" "$THREAD3"; do
  gh api graphql -f query="mutation { resolveReviewThread(input: {threadId: \"${THREAD_ID}\"}) { thread { isResolved } } }"
  sleep 3
done

再次强调：单个 API 写操作之间永远 sleep 3——GitHub 次级限制（403）在短时间 >20 次写操作时触发；单批超过 20 条回复时提高到 sleep 5。

收尾：resolveReviewThread 与 ORCHESTRATOR:DONE 前的最终核验

resolveReviewThread 只能在提交已推送、回复已发出之后调用：

gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "THREAD_ID"}) { thread { isResolved } } }'

绝不能在提交修复之前调用该 mutation。 文档还点出了与上层编排器的协作契约：在输出 ORCHESTRATOR:DONE 之后，编排器会用 GraphQL 独立复核真实的未解决数量——假解决会被发现并触发重新简报（re-brief）。这正是 orchestrate 技能中 verify-complete.sh 的校验逻辑："checkpoints ✓ + 0 unresolved threads + CI green + 无新的 CHANGES_REQUESTED"，四者全过才允许回收工作区。

因此在宣称"0 未解决线程"之前，必须直接查询 GitHub 而非依赖自己的记账，并且分页翻完所有页——单条 first: 100 查询会漏掉第 1 页之后的线程：

# Step 1: get total thread count
gh api graphql -f query='
{
  repository(owner: "Significant-Gravitas", name: "AutoGPT") {
    pullRequest(number: {N}) {
      reviewThreads { totalCount }
    }
  }
}' | jq '.data.repository.pullRequest.reviewThreads.totalCount'

# Step 2: paginate all pages, count truly unresolved
CURSOR=""; UNRESOLVED=0
while true; do
  AFTER=${CURSOR:+", after: \"$CURSOR\""}
  PAGE=$(gh api graphql -f query="
  {
    repository(owner: \"Significant-Gravitas\", name: \"AutoGPT\") {
      pullRequest(number: {N}) {
        reviewThreads(first: 100${AFTER}) {
          pageInfo { hasNextPage endCursor }
          nodes { isResolved }
        }
      }
    }
  }")
  UNRESOLVED=$(( UNRESOLVED + $(echo "$PAGE" | jq '[.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved==false)] | length') ))
  HAS_NEXT=$(echo "$PAGE" | jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage')
  CURSOR=$(echo "$PAGE" | jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor')
  [ "$HAS_NEXT" = "false" ] && break
done
echo "Unresolved threads: $UNRESOLVED"

只有当这个循环报告 0 时，才输出 ORCHESTRATOR:DONE。

小结：这套流程背后的三条工程经验

通读 pr-address 技能 全文，它其实沉淀了 AutoGPT 团队让 Agent 稳定" babysit PR"的三条核心经验，每一条都对应了文档中的一个关键设计：

1. 外部系统不能信任"看起来完成"——GraphQL 最旧优先的分页顺序会制造"第 1 页 0 条未解决"的假象，所以规则是"无条件翻到 hasNextPage == false"，收尾时还要用同一段分页代码向 GitHub 复核真实计数，而不是信 Agent 自己的台账；
2. "解决"必须由不可伪造的产物背书——resolve 只能跟在"可验证的提交 + 内联回复"之后，且明确列出了四种"看起来解决了"的反模式，因为编排器会独立复核，假解决必然被识破；
3. 自动化的最大敌人是平台限速——文档把 abuse 次级限制、REST 主限制、GraphQL 专属限制三者的错误形态与恢复策略做成对照表，并为每一类 GraphQL-only 操作（gh pr view、resolveReviewThread）都预置了 REST 降级路径，保证任何单一限额耗尽都不至于让整个流程停摆。

配合 codecov.yml 中 80% 的 patch 覆盖底线、pyproject.toml 的 format/rest 脚本、orval.config.ts 的 API 客户端再生成链路，pr-address 实际上把"一个 PR 从收到评论到可以合并"的全部动作固化成了可执行、可复核、可审计的步骤集——这正是 AutoGPT 用 orchestrate 调度多个 Claude Agent 并行开发、再统一收尾的工作流基础。