Copilot PR Autopilot 步骤 10 深度解析收敛后的过期线程批量清理Cleanup Outdated【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读在 copilot-pr-autopilot 技能的十步自动化审阅循环中步骤 10 是收敛Converged之后唯一执行一次、由父级 Agentparent负责的终态清理步骤。它运行 10-cleanup-outdated.ps1批量解决那些已被后续提交修复、却从未显式 resolve的过期isOutdatedCopilot 审查线程充当防止残留未解决线程污染 PR 界面的安全网。读完本文你将掌握步骤 10 的定位、脚本的全部安全守卫awaiting-reply 守卫、human-in-thread 守卫、参数语义-DryRun、-Force、GraphQL 分页细节与失败隔离策略并能安全地在自己的 PR 循环中运行它。步骤 10 在循环中的位置终态清理而非常规机制整个 autopilot 的核心是 1→9 步的循环请求审查 → 等待 → 列出线程 → 分类 → 修复 → 构建测试 → 提交推送 → 回复解决 → 收敛验证。只有 09-convergence.md 返回Converged: true之后父级 Agent 才会运行步骤 10 一次然后调用task_complete结束循环见 orchestration.md 的循环拓扑与委托表。10-cleanup.md 明确了三个关键属性Ownerparent无 sub-agent因为所有变更型操作mutation都由父级持有这与步骤 7提交推送、步骤 8发布回复/解决的mutation 归父级原则一致Budgetn/a——它是一个一次性轻量步骤不需要子代理时间盒执行时机收敛之后且仅一次绝不能在每个轮次中都跑。更重要的定位是大多数循环收敛时根本没有可清理的东西。为什么因为过期的线程在步骤 3 列出开放线程时照样会出现Unresolved is the source of truth未解决状态才是 PR 界面上的真相来源见 03-list-threads.md它们应该和任何其他开放线程一样在步骤 8 中通过 08-reply-and-resolve.ps1 被回复 解决见 08-reply-resolve.md。步骤 10 的存在只为一个目的接住漏网之鱼safety net兜底那些被后续 commit 修复过、但因种种原因未被显式 resolve 的陈旧线程。为什么需要专门清理过期但未解决的线程GitHub 的审查线程有三种状态维度isResolved是否已解决isOutdated是否过期——代码后续提交发生了变动导致该线程锚定的位置不再是 HEAD 上的实际代码isOpen的呈现形式在 PR 界面中只要未解决isResolved: false线程就会一直显示为 open。一个典型的残留场景Copilot 在 round N 对某一行代码提出意见Agent 在 round N1 通过新的 commit 修复了该处但该 commit 恰好改动了线程锚定的代码块GitHub 自动把线程标记为isOutdated: true——线程不再指向任何现存代码但它在 PR UI 上依然是未解决的。如果步骤 8 只处理了当时可见的开放线程这类过期但未解决的线程就会留在界面上让合并者误以为还有待办事项。10-cleanup-outdated.ps1 就是针对这一状态组合做最后清扫找到isOutdated: true且isResolved: false的 Copilot 线程并在满足全部安全守卫的前提下批量 resolve。运行方式与参数基本调用pwsh ./scripts/10-cleanup-outdated.ps1 -PrNumber n脚本位于 skills/copilot-pr-autopilot/scripts/10-cleanup-outdated.ps1从 10-cleanup.md 中的命令pwsh ./scripts/10-cleanup-outdated.ps1 -PrNumber n可直接对应当前仓库中的真实路径。参数一览参数类型必填默认值语义-PrNumberint是无目标 PR 编号-Ownerstring否gh repo view解析的当前仓库 owner仓库属主org 或用户-Repostring否gh repo view解析的当前仓库名仓库名-DryRunswitch否关只打印将要 resolve 哪些线程不执行任何 GraphQL mutation-Forceswitch否关覆盖最后一条评论者必须是当前认证用户的守卫不能覆盖 human-in-thread 守卫参数设计的两个细节值得注意-Owner与-Repo必须同时传或都不传。Resolve-RepoCoords定义于 scripts/_lib.ps1实现了 both-or-neither 契约只传其中一个会被显式拒绝因为混用调用者提供的 owner 与本地探测的 repo或反之会静默构造出一个不存在或非预期的Owner/Repo组合。-DryRun是显式开关而不是 PowerShell 的-WhatIf机制。注释中解释了原因_lib.ps1的Invoke-Gh内部用2重定向捕获 stderr而 PowerShell 的2会经由 Out-FileOut-File 会尊重调用方作用域的$WhatIfPreference——若用SupportsShouldProcess会打印一串无意义的 Performing the operation Output to File 噪音。用显式 switch 彻底绕开这条链路。-Force的范围是受限的它只覆盖最后一条评论者是当前用户的守卫。human-in-thread 守卫永远不可被-Force覆盖详见下一节。前置条件继承自整个技能脚本 dot-source scripts/_lib.ps1后者在加载时执行Assert-GhReady若gh未安装或gh auth status失败脚本会在做任何工作之前以一条可操作的错误信息终止给出winget install/brew install gh/gh auth login等指引。此外脚本会调用gh api user --jq .login获取当前认证用户登录名——这是-Force未开启时判断我们是否已经回复过该线程的依据。候选线程的四个筛选条件脚本对每个线程依次施加以下条件10-cleanup-outdated.ps1 的foreach ($thread in $threads)循环isOutdated: true——线程已过期被后续提交覆盖isResolved: false——线程仍处于未解决状态首条评论作者是 Copilot——匹配copilot-pull-request-reviewer或copilot-pull-request-reviewer[bot]两种登录形式GraphQL 的不同表面会返回这两种写法统一由_lib.ps1中的$CopilotReviewerLoginRegex(?i)^copilot-pull-request-reviewer(\[bot\])?$处理最后一条评论作者是当前认证用户即我们已经回复过该线程——这是awaiting-reply 守卫如果 Copilot或除我们之外的任何人说了最后一句话说明该线程还在等待我们的回复直接 resolve 会隐藏一个尚待处理的可操作发现。此守卫可用-Force覆盖。不可覆盖的 human-in-thread 守卫脚本中最强的安全承诺是含有人类信号的线程永远不被触碰文档原文threads from human reviewers are never touched。它体现在 human-in-thread 守卫上遍历线程的全部评论作者注意不是只看第一条或最后一条若存在任何既不是 Copilot、也不是当前认证用户的作者即人类或其他 bot 在 Copilot 开场之后插话线程被跳过该守卫不受-Force影响——自动 resolve 一条携带人类信号的线程等于静默隐藏尚未被回应的关切这在设计上是不可接受的。为了兑现无论人类评论在什么位置这一承诺脚本特意用allComments: comments(first: 100)取回线程首屏 100 条评论的完整作者列表而不仅仅是首尾各一条。这意味着即使是Copilot 开场、人类中途插话的混合作者线程也会被正确跳过——文档中人类审查线程永不被触碰的承诺同时覆盖了纯人类作者线程与混合作者线程两类情形。幽灵/已删除用户的 fail-safe 处理作者集合中可能出现$nullGitHub 对已删除/幽灵用户返回的 author.login。脚本将其单独归类为unknownAuthorInThread并跳过线程当作者身份无法确认时宁可漏掉一条过期的 bot 线程也绝不自动 resolve 一条可能藏有人类信号的线程。这一策略被注释明确表述为 fail-safe并在汇总输出中与skippedHumanInThread分开计数便于区分人类碰过与我们无法判断谁碰过。完整评论作者可见性GraphQL 分页兜底单个线程的评论数可能超过外层查询的 100 条窗口。脚本通过Get-AllThreadAuthors辅助函数解决当外层allComments.pageInfo.hasNextPage为真时用node(id:)二次查询按页拉取剩余评论的作者分页循环设有MaxPages默认 200硬上限最多覆盖 201 页 × 100 条 20,100 条评论超过真实 PR 线程的合理量级三个数量级防止服务器返回游标永不前进的畸形响应导致死循环三重防线页数超限抛错、node(id:)返回 null线程被删抛错、游标未推进抛错——保证任何异常都会显式暴露而不是静默产生不完整作者列表按线程隔离 try/catch单条线程的分页瞬时故障限流、游标异常、线程中途消失只跳过该线程不会中断整轮清理——与下方 resolve mutation 的隔离策略一致。外层reviewThreads(first: 100, after: $after)查询本身也按游标分页do/while ($page.pageInfo.hasNextPage)会拉取 PR 上全部审查线程后再进入筛选确保不会因为线程数超过 100 而漏扫。执行阶段逐个 resolve 失败隔离 汇总退出码筛选完成后若$targets.Count -eq 0输出No outdated Copilot threads to clean up.并正常返回——这正是大多数循环无物可清的常态路径否则对每个目标线程执行 GraphQL mutationmutation($tid: ID!) { resolveReviewThread(input: { threadId: $tid }) { thread { isResolved } } }执行细节逐线程 try/catch单条 mutation 失败限流、瞬时 GraphQL 错误、线程在循环中被删除不会中止整轮清理其余过期线程仍会被处理失败会汇总并反映到退出码结束时输出Cleanup summary: resolved... failed... skippedAwaitingReply... skippedHumanInThread... skippedUnknownAuthorInThread... skippedPaginationError...只要有任何失败就列出失败线程及其错误并以exit 1退出供父级 Agent 感知部分失败而不是误判为全部成功-DryRun模式下只打印Would resolve id (DryRun)且不输出汇总、不设置退出码。与整个循环的联动什么时候该跑、什么时候不该跑收敛后跑一次步骤 10 是终态步骤其唯一输入是收敛 PR 的PrNumber无返回值——运行后循环结束父级调用task_complete并附上收敛证明HeadOid、LatestCopilotReview.commitOid、submittedAt、OpenThreadsAwaitingReply: 0以及未解决的手工移交线程清单见 09-convergence.md不能在收敛前滥用在循环未收敛时直接跑步骤 10awaiting-reply 守卫最后评论者必须是认证用户会跳过绝大多数线程-Force虽可强制清理但注释明确警告这只应在故意绕过收敛循环、清掉陈旧的过期 Copilot 线程时使用它取代不了步骤 8正常路径下过期线程在步骤 3 出现、在步骤 8 被回复解决resolve 是fix/decline处置后的条件动作而escalate-to-user的线程必须保持开放并交给人类合并者见 08-reply-resolve.md 的-NoResolve用法。步骤 10 只接住遗漏者且受限于两条守卫绝不会去动人类线程或升级给用户的线程。小结安全网的三条设计原则从 10-cleanup.md 的契约和 10-cleanup-outdated.ps1 的实现可以看出这个只有安全网功能的步骤把安全性做到了极致可归纳为三条原则宁可漏不可误伤awaiting-reply 守卫、human-in-thread 守卫、未知作者 fail-safe、分页失败 fail-safe全部朝跳过倾斜——自动 resolve 造成的信息丢失隐藏人类关切远比残留一条过期 bot 线程严重强制可审计逐线程成功/失败统计、-DryRun预演、非零退出码 失败线程明细让父级 Agent 和用户都能精确知道清理做了什么、跳过什么、为何跳过机制归机制判断归判断-Force只覆盖等待回复这一条机械性守卫绝不覆盖涉及人类信号的判断性守卫——把是否该清理含人类信号的线程留给人类而不是交给脚本。对任何运行 copilot-pr-autopilot 的仓库来说步骤 10 是循环收尾的最后一颗定心丸它保证收敛 干净的 PR 界面这一最终用户体验同时用两道不可逾越的守卫确保自动化清理永远不会掩盖任何真实关切。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考