OpenClaw 拉取请求审查流程Barnacle 与 ClawSweeper 自动分流、AI 审查与作者跟进指南【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本指南完整讲解 OpenClaw 仓库在 PRPull Request打开或更新之后的自动化审查流程Barnacle 如何做确定性的队列分流ClawSweeper 如何做 AI 辅助审查作者如何根据反馈改进 PR、请求复审以及当自动化静默或卡住时如何排查。读完本文你将掌握 Barnacle 的触发规则与标签体系、ClawSweeper 的队列机制与命令用法、六步 PR 改进清单、证据提交规范以及 stale 自动关闭与故障排查的完整实操方案。Barnacle 与 ClawSweeper 是 OpenClaw 仓库维护者用来保持审查队列可用性的两道自动化防线。二者均不替代维护者的判断Barnacle 提供确定性的 GitHub 分流ClawSweeper 提供 AI 辅助的审查与维护而合并决策始终由维护者做出。本文基于 docs/reference/pull-request-review-flow.md 展开并结合仓库中的自动化源码scripts/github/barnacle-auto-response.mjs、scripts/github/real-behavior-proof-policy.mjs、scripts/pr-lib/clawsweeper-review-gate.mjs与 CONTRIBUTING.md 佐证实现细节。一、整体流程两道自动化如何协同一次典型的 PR 生命周期是这样的作者打开 PR或把 draft 标记为 ready for review。Barnacle确定性分流立刻对 PR 做结构化检查PR 描述是否为空、是否有证据、变更是否属于 docs/test/refactor/CI/infra、是否应归属 ClawHub 或插件、分支是否夹带无关改动、作者是否超过 20 个开放 PR 等然后打标签、留评论必要时自动关闭。ClawSweeperAI 辅助审查收到转发后先贴一条简短的回执评论审查本身进入队列等待槽位轮到时对 PR 做审查、评估证据、留下持久审查评论并可为维护者执行受保护的 repair 或 automerge 流程。作者根据反馈更新分支、PR 描述与证据然后通过评论clawsweeper re-review请求新一轮审查。维护者结合自动化结果做最终合并决策。关键区别在于Barnacle 是规则引擎确定性、可预测、无 AIClawSweeper 是AI 审查员需要队列、有推理、能留审查对话。信任边界Barnacle 运行在受信任的仓库工作流代码中不会检出或运行贡献者的代码。ClawSweeper 的转发桥clawsweeper-dispatch.yml同样不检出、不执行不可信的 PR 代码——它只把规范化的元数据通过repository_dispatch投递给openclaw/clawsweeper见 docs/ci/scheduled-workflows.md 的 ClawSweeper activity forwarding 一节。当某个受信任工作流需要运行不可信的贡献者代码时自动化会主动回避改由维护者走正常审查或更安全的工作流。二、Barnacle确定性 GitHub 分流Barnacle 的核心实现在 scripts/github/barnacle-auto-response.mjs文件头部注释直接说明了它的定位Barnacle owns deterministic GitHub triage and auto-response behaviorBarnacle 负责确定性的 GitHub 分流与自动响应。2.1 触发场景Barnacle 可能在以下场景采取行动PR 描述基本为空或缺少问题上下文PR 没有有用的证据纯 docs、纯 test、纯 refactor、纯 CI 或纯 infra 变更缺少关联的维护者上下文变更看起来应该归属 ClawHub 或插件而非核心仓库分支夹带无关工作dirty PR作者在仓库中开放的 PR 超过 20 个源码中const activePrLimit 20硬编码了该阈值。大多数路由标签是维护者或自动化信号贡献者通常不需要自己打标签。2.2 规则表与标签体系源码中维护了一张结构化的规则表rules每条规则包含标签、是否关闭、回复消息与评论触发器标签行为说明r: skill关闭新技能应发布到 ClawHub核心仓库保持精简r: support关闭支持请求应去 Discord#help或支持文档r: false-positive关闭误报或仅重新分类的报告非可操作的 bugr: no-ci-pr关闭仅为追逐 main 上已知 CI/测试失败而开的 PRr: too-many-prs关闭作者活跃 PR 超过 20 个r: too-many-prs-override为维护者覆盖标签r: testflight关闭TestFlight 相关问题不在本仓库讨论评论触发词testflightr: third-party-extension关闭第三方插件/能力应发布到 ClawHubr: bluebubbles关闭BlueBubbles 已弃用改用imsg或 ClawHub 插件触发词bluebubbles/blue bubblesr: moltbook关闭并锁定Moltbook 与 OpenClaw 无关触发词moltbook锁定理由 off-topicr: spam关闭并锁定垃圾信息dirty关闭维护者打标分支太脏/无关改动过多bad-barnacle抑制在该 issue/PR 上抑制 Barnacle 自动化trigger-response触发维护者用来重跑 Barnacle 自动响应的触发标签2.3 候选标签candidate labels除了直接关闭的规则Barnacle 还会通过classifyPullRequestCandidateLabels对 PR 进行结构化分类产生一组triage:前缀的候选标签作为需维护者复核的信号源码中的candidateLabelstriage: blank-template—— PR 模板基本未填写triage: needs-pr-context—— 外部 PR 描述缺少必要的问题上下文或证据triage: low-signal-docs—— 纯文档变更信号过低triage: docs-discoverability—— 文档发现性/社区插件列表类变更可能归属别处triage: test-only-no-bug—— 仅测试变更未关联 bug 或行为证据triage: refactor-only—— 纯重构/清理无维护者上下文triage: dirty-candidate—— 变更面过广可能需要拆分或清理triage: risky-infra—— infra/CI/release 变更需维护者审查triage: external-plugin-candidate—— 插件/能力可能应归属 ClawHub。这些候选标签本身不会直接关闭 PR但会配合候选动作规则candidateActionRules在特定条件下执行关闭动作。分类逻辑会分析 PR 的文件列表全部为 docs/markdown 文件判定为 docs-only全部为 test/fixture/snapshot 判定为 test-only命中.github/workflows、scripts/、Dockerfile、pnpm-lock.yaml等判定为 infra 类涉及 4 个及以上 surfacesrc/gateway、src/plugins、extensions、apps、ui、docs等且无清晰设计上下文时标记为 dirty 候选。维护者优先权源码中通过createMaintainerChecker查询组织maintainer团队的成员关系和hasPrivilegedRepositoryRoleadmin/maintain/write角色判断操作者是否特权。维护者创作的 PR 会跳过自动响应检查涉及维护者的评论也会跳过 Barnacle 的评论检查。这就是维护者参与的项自动化保持安静的代码级原因。三、ClawSweeperAI 辅助审查与维护机器人ClawSweeper 是 OpenClaw 仓库的 AI 辅助审查与维护机器人可以审查 PR、评估证据、留下持久审查评论并协助维护者执行受保护的 repair 或 automerge 流程。3.1 重要前提ClawSweeper 的正面结果是佐证不是维护者批准。是否以及何时合并仍由维护者决定。ClawSweeper 基于队列打开非 draft PR 或把 draft 标记为 ready 时它立刻贴一条简短回执评论但审查本身仍在队列中等待槽位。不要在打开 PR、推送提交或添加审查请求后期待立即得到审查。ClawSweeper 运行后的标签更新同样可能延迟。3.2 命令与权限矩阵新 PR 进入 ClawSweeper 审查队列。维护者还可以通过标签或命令排队 review、repair 或 automerge 流程。对普通贡献者的更新正确做法是只有在你更新了分支、PR 描述、证据或代码之后再以一条新的 PR 评论请求复审clawsweeper re-review命令权限如下命令可用者说明clawsweeper re-reviewPR 作者在更新完成后请求新一轮审查clawsweeper re-runPR 作者重跑作者可用clawsweeper review仅维护者普通 review 命令是维护者专用拥有仓库写权限的用户可以对任何开放项使用前两个命令。耐心是美德在要求的修改还没出现前反复请求只会给队列增加噪音。从源码看ClawSweeper 的审查门禁非常严格。scripts/pr-lib/clawsweeper-review-gate.mjs 是一个独立可执行脚本clawsweeper-review-gate.mjs PR head-sha它会从标准输入读取 GitHub issue 评论分页 JSON只信任来自clawsweeper[bot]Bot 类型、固定 ID且带有规范完成标记的评论校验reviewed_at、reviewed_sha、source_revision、lease_owner、lease_comment_id等字段的格式与取值拒绝未来日期、拒绝 12 小时以上的过期审查、拒绝重复完成标记并校验最新完成的reviewed_sha是否等于当前 head。这套机制保证了审查确实完成、且针对当前提交这一事实可以机器可验证——这正是它被用作合并门禁的依据。3.3 与人协作的边界当有人类贡献者或维护者接管了 PR 并正在积极工作时不要同时召唤 ClawSweeper 或在 PR 上并行操作——先让人工审查或 repair 完成。如果活动停止检查作者是否被要求提供证据或做其他更新。当 ClawSweeper 留下审查对话时把它当作普通审查反馈对待按下面的跟进清单处理。3.4 事件转发架构ClawSweeper 的接入不是直连 webhook而是通过目标端桥接详见 docs/ci/scheduled-workflows.md 的 ClawSweeper activity forwarding.github/workflows/clawsweeper-dispatch.yml用CLAWSWEEPER_APP_PRIVATE_KEY创建 GitHub App token然后向openclaw/clawsweeper投递紧凑的repository_dispatch载荷分三条 laneclawsweeper_item—— 精确的 issue / PR 审查请求clawsweeper_comment—— issue 评论中的显式 ClawSweeper 命令github_activity—— 供 ClawSweeper agent 检视的常规 GitHub 活动。github_activitylane 只转发规范化元数据事件类型、动作、actor、仓库、条目号、URL、标题、状态、评论/审查的短摘录刻意不转发完整 webhook 体。main 分支推送只是github_activity观察不产生托管式逐提交报告或 Check Run。整条路径上GitHub 标题、评论、正文、审查文本、分支名和提交信息都被视为不可信数据是摘要与分流summarization and triage的输入而非工作流或 agent 运行时的指令。四、如何在审查期间改进 PR一旦 Barnacle、ClawSweeper 或维护者给出响应就把反馈当作该 PR 的下一步行动清单把 ClawSweeper 的Rank-up moves:和Proof guidance:当作该 PR 的行动清单。评分和标签是审查信号不是固定的合并目标。推送要求的代码或文档改动当问题、解决方案、用户影响或证据发生变化时同步更新 PR 描述。补充要求的证据使用与变更匹配的证据类型。自己解决已回应的审查对话。只有需要维护者或审查者判断时才回复并保持对话开启。在分支、PR 描述、证据和相关 CI 结果都是最新状态后再请求复审。作者、维护者与 ClawSweeper 之间多轮更新-复审循环是正常的。尽量把讨论留在 PR 上。仅当 PR 需要维护者协调、自动化看起来被阻塞、或下一个决定难以在 GitHub 评论中敲定时才转到 Discord 的#clawtributors并附上 PR 链接、当前状态、以及具体问题或剩余证据。保持 PR 描述最新。评论有助于讨论但 PR 描述才是维护者与自动化反复回看的持久摘要。CONTRIBUTING.md 中对此有呼应当 ClawSweeper、Barnacle 或维护者要求更多上下文或证据时编辑 PR 描述而不是只在新评论中回复保持What Problem This Solves、Why This Change Was Made、User Impact和Evidence各节最新。status: ⏳ waiting on author表示下一步行动在 PR 作者身上先更新分支、PR 描述、证据或回复缺失的上下文再请求下一轮审查。五、证据Proof规范有用的证据包括聚焦的测试输出、CI 结果、截图、录屏、终端输出、真实环境观察、脱敏日志或产物链接。视觉类变更应尽量提供前后对比截图。证据文件链接优先链接 CI 产物、GitHub 上传的截图或录屏、或一小段脱敏日志摘录。不要提交生成的证据文件除非它们本身就是 docs、tests 或产品变更的一部分。脱敏是贡献者的责任发布证据前移除 secrets、tokens、私有 URL、用户数据和不相关的日志。从源码看证据策略是被机器评估的。scripts/github/real-behavior-proof-policy.mjs 实现了共享的 PR 上下文与证据策略定义了 ClawSweeper 拥有的标签proof: override、proof: sufficient与triage: needs-pr-context识别占位值正则n/a、none、tbd、unknown、-、空引用链接等识别空模板hasMostlyBlankTemplate会检测新旧两版模板的关键字段是否填写通过hasConcreteBehaviorContext判断是否有具体行为上下文关联 issue/PR、填写了 Problem/Why it matters/What changed、或包含 repro/regression/root cause/crash 等信号词通过hasClearDesignContext判断是否有设计上下文RFC、design、architecture、maintainer request 等。clawsweeper_exact_head_pass这一审查结论状态则代表ClawSweeper 对精确 head 的审查通过。这些函数共同支撑 Barnacle 的标签决策与 ClawSweeper 的证据评估——也就是说证据不足不是主观印象而是可复现的文本与结构分析。六、Stale 自动关闭机制OpenClaw 还使用独立的 stale 自动化未分配的 issue 与 PR连续 14 天无活动后标记为 stale再闲置 7 天后关闭。已分配的 PR打开 27 天后无论之后是否有更新标记为 stale再经过 7 个 stale 日无活动后关闭。如果已分配的 PR 仍然活跃请与正在处理它的维护者协调。此外docs/ci/scheduled-workflows.md 还提到 Barnacle 会把标记为 bug 的 issue 当作验证候选而非闲置关闭候选Barnacle 可以给它打上stale标签这会触发一次精确的 ClawSweeper 审查但不能关闭该 issueClawSweeper 随后可能给出基于证据的结论——在最新 main 上被证实修复的按 completed 关闭仍存在或证据不足的保持打开。stale 工作流还会审计最近的关闭事件发现 Barnacle 身份将 bug 以not_planned关闭时即失败。七、当自动化保持安静时自动化可能保持安静的原因维护者已经在处理该项review 或 repair 请求仍在排队事件属于常规事件routineClawSweeper 的 lane 未配置对应请求的动作。另一个重要情形当受信任工作流需要运行不可信的贡献者代码时自动化会回避行动此时维护者改用正常审查或更安全的工作流。八、故障排查如果 ClawSweeper 没有立即响应先等待再重试。服务基于队列重复评论或反复改动标签只会让线程更难审查并不会让队列变快。向他人求助前先检查以下清单PR 描述是否最新最新提交是否包含要求的改动CI 是否已完成或 PR 描述是否解释了剩余失败与 PR 无关最新审查请求是否以 PR 评论形式发出clawsweeper re-review是否没有维护者或贡献者正在积极处理该 PR最新请求是否仍在 ClawSweeper 正常的队列延迟窗口内。如果 PR 已是最新状态后数小时仍无 ClawSweeper 响应或 PR 看起来被自动化阻塞请到 Discord#clawtributors求助并附上PR 链接、你期望的行为、你发起请求的时间、以及自上次 bot 评论以来发生了什么变化。九、复用或分叉这套自动化希望获得类似审查自动化的项目可以参考或分叉 ClawSweeper 项目及其文档。在本仓库内可以研究的核心参考实现包括scripts/github/barnacle-auto-response.mjs —— 确定性分流规则表、候选标签分类、标签同步与自动响应主流程scripts/github/real-behavior-proof-policy.mjs —— PR 上下文与证据策略的共享实现scripts/pr-lib/clawsweeper-review-gate.mjs —— 审查完成标记的机器验证门禁docs/ci/scheduled-workflows.md —— ClawSweeper 事件转发架构与 lane 设计。需要注意这套自动化的设计与 OpenClaw 的仓库治理强相关PR 模板结构、Evidence 要求、20 PR 上限、维护者团队权限模型等分叉时应同步调整规则表与模板解析逻辑。十、贡献者速查清单结合 CONTRIBUTING.md 与本文向 OpenClaw 提交 PR 时的关键动作如下填写 PR 模板的What Problem This Solves与Evidence描述具体的用户、产品或运维问题保持单一职责一个 PR 只做一件事关联 issueCloses #issue或Related: #issue视觉变更提供前后截图其他变更提供聚焦测试输出、CI 结果、录屏、脱敏日志或产物链接收到 Barnacle/ClawSweeper/维护者反馈后按四、如何在审查期间改进 PR的六步清单行动先更新分支与 PR 描述再以评论clawsweeper re-review请求复审不要把纯 refactor、为追逐已知 main CI 失败而开的 test-only PR 提交到核心仓库这类 PR 会被自动关闭活跃 PR 保持在 20 个以内需要超限的协调变更集先到#clawtributors与维护者沟通。Barnacle 与 ClawSweeper 共同构成了 OpenClaw 的分流 审查双引擎前者用确定性的规则守住队列入口后者用 AI 能力提供深度审查与证据评估而两者之上永远是维护者的最终判断。理解这套流程既能让你在贡献 PR 时少走弯路也为搭建类似的开源协作自动化提供了完整的参考蓝本。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenClaw 拉取请求审查流程：Barnacle 与 ClawSweeper 自动分流、AI 审查与作者跟进指南
OpenClaw 拉取请求审查流程Barnacle 与 ClawSweeper 自动分流、AI 审查与作者跟进指南【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本指南完整讲解 OpenClaw 仓库在 PRPull Request打开或更新之后的自动化审查流程Barnacle 如何做确定性的队列分流ClawSweeper 如何做 AI 辅助审查作者如何根据反馈改进 PR、请求复审以及当自动化静默或卡住时如何排查。读完本文你将掌握 Barnacle 的触发规则与标签体系、ClawSweeper 的队列机制与命令用法、六步 PR 改进清单、证据提交规范以及 stale 自动关闭与故障排查的完整实操方案。Barnacle 与 ClawSweeper 是 OpenClaw 仓库维护者用来保持审查队列可用性的两道自动化防线。二者均不替代维护者的判断Barnacle 提供确定性的 GitHub 分流ClawSweeper 提供 AI 辅助的审查与维护而合并决策始终由维护者做出。本文基于 docs/reference/pull-request-review-flow.md 展开并结合仓库中的自动化源码scripts/github/barnacle-auto-response.mjs、scripts/github/real-behavior-proof-policy.mjs、scripts/pr-lib/clawsweeper-review-gate.mjs与 CONTRIBUTING.md 佐证实现细节。一、整体流程两道自动化如何协同一次典型的 PR 生命周期是这样的作者打开 PR或把 draft 标记为 ready for review。Barnacle确定性分流立刻对 PR 做结构化检查PR 描述是否为空、是否有证据、变更是否属于 docs/test/refactor/CI/infra、是否应归属 ClawHub 或插件、分支是否夹带无关改动、作者是否超过 20 个开放 PR 等然后打标签、留评论必要时自动关闭。ClawSweeperAI 辅助审查收到转发后先贴一条简短的回执评论审查本身进入队列等待槽位轮到时对 PR 做审查、评估证据、留下持久审查评论并可为维护者执行受保护的 repair 或 automerge 流程。作者根据反馈更新分支、PR 描述与证据然后通过评论clawsweeper re-review请求新一轮审查。维护者结合自动化结果做最终合并决策。关键区别在于Barnacle 是规则引擎确定性、可预测、无 AIClawSweeper 是AI 审查员需要队列、有推理、能留审查对话。信任边界Barnacle 运行在受信任的仓库工作流代码中不会检出或运行贡献者的代码。ClawSweeper 的转发桥clawsweeper-dispatch.yml同样不检出、不执行不可信的 PR 代码——它只把规范化的元数据通过repository_dispatch投递给openclaw/clawsweeper见 docs/ci/scheduled-workflows.md 的 ClawSweeper activity forwarding 一节。当某个受信任工作流需要运行不可信的贡献者代码时自动化会主动回避改由维护者走正常审查或更安全的工作流。二、Barnacle确定性 GitHub 分流Barnacle 的核心实现在 scripts/github/barnacle-auto-response.mjs文件头部注释直接说明了它的定位Barnacle owns deterministic GitHub triage and auto-response behaviorBarnacle 负责确定性的 GitHub 分流与自动响应。2.1 触发场景Barnacle 可能在以下场景采取行动PR 描述基本为空或缺少问题上下文PR 没有有用的证据纯 docs、纯 test、纯 refactor、纯 CI 或纯 infra 变更缺少关联的维护者上下文变更看起来应该归属 ClawHub 或插件而非核心仓库分支夹带无关工作dirty PR作者在仓库中开放的 PR 超过 20 个源码中const activePrLimit 20硬编码了该阈值。大多数路由标签是维护者或自动化信号贡献者通常不需要自己打标签。2.2 规则表与标签体系源码中维护了一张结构化的规则表rules每条规则包含标签、是否关闭、回复消息与评论触发器标签行为说明r: skill关闭新技能应发布到 ClawHub核心仓库保持精简r: support关闭支持请求应去 Discord#help或支持文档r: false-positive关闭误报或仅重新分类的报告非可操作的 bugr: no-ci-pr关闭仅为追逐 main 上已知 CI/测试失败而开的 PRr: too-many-prs关闭作者活跃 PR 超过 20 个r: too-many-prs-override为维护者覆盖标签r: testflight关闭TestFlight 相关问题不在本仓库讨论评论触发词testflightr: third-party-extension关闭第三方插件/能力应发布到 ClawHubr: bluebubbles关闭BlueBubbles 已弃用改用imsg或 ClawHub 插件触发词bluebubbles/blue bubblesr: moltbook关闭并锁定Moltbook 与 OpenClaw 无关触发词moltbook锁定理由 off-topicr: spam关闭并锁定垃圾信息dirty关闭维护者打标分支太脏/无关改动过多bad-barnacle抑制在该 issue/PR 上抑制 Barnacle 自动化trigger-response触发维护者用来重跑 Barnacle 自动响应的触发标签2.3 候选标签candidate labels除了直接关闭的规则Barnacle 还会通过classifyPullRequestCandidateLabels对 PR 进行结构化分类产生一组triage:前缀的候选标签作为需维护者复核的信号源码中的candidateLabelstriage: blank-template—— PR 模板基本未填写triage: needs-pr-context—— 外部 PR 描述缺少必要的问题上下文或证据triage: low-signal-docs—— 纯文档变更信号过低triage: docs-discoverability—— 文档发现性/社区插件列表类变更可能归属别处triage: test-only-no-bug—— 仅测试变更未关联 bug 或行为证据triage: refactor-only—— 纯重构/清理无维护者上下文triage: dirty-candidate—— 变更面过广可能需要拆分或清理triage: risky-infra—— infra/CI/release 变更需维护者审查triage: external-plugin-candidate—— 插件/能力可能应归属 ClawHub。这些候选标签本身不会直接关闭 PR但会配合候选动作规则candidateActionRules在特定条件下执行关闭动作。分类逻辑会分析 PR 的文件列表全部为 docs/markdown 文件判定为 docs-only全部为 test/fixture/snapshot 判定为 test-only命中.github/workflows、scripts/、Dockerfile、pnpm-lock.yaml等判定为 infra 类涉及 4 个及以上 surfacesrc/gateway、src/plugins、extensions、apps、ui、docs等且无清晰设计上下文时标记为 dirty 候选。维护者优先权源码中通过createMaintainerChecker查询组织maintainer团队的成员关系和hasPrivilegedRepositoryRoleadmin/maintain/write角色判断操作者是否特权。维护者创作的 PR 会跳过自动响应检查涉及维护者的评论也会跳过 Barnacle 的评论检查。这就是维护者参与的项自动化保持安静的代码级原因。三、ClawSweeperAI 辅助审查与维护机器人ClawSweeper 是 OpenClaw 仓库的 AI 辅助审查与维护机器人可以审查 PR、评估证据、留下持久审查评论并协助维护者执行受保护的 repair 或 automerge 流程。3.1 重要前提ClawSweeper 的正面结果是佐证不是维护者批准。是否以及何时合并仍由维护者决定。ClawSweeper 基于队列打开非 draft PR 或把 draft 标记为 ready 时它立刻贴一条简短回执评论但审查本身仍在队列中等待槽位。不要在打开 PR、推送提交或添加审查请求后期待立即得到审查。ClawSweeper 运行后的标签更新同样可能延迟。3.2 命令与权限矩阵新 PR 进入 ClawSweeper 审查队列。维护者还可以通过标签或命令排队 review、repair 或 automerge 流程。对普通贡献者的更新正确做法是只有在你更新了分支、PR 描述、证据或代码之后再以一条新的 PR 评论请求复审clawsweeper re-review命令权限如下命令可用者说明clawsweeper re-reviewPR 作者在更新完成后请求新一轮审查clawsweeper re-runPR 作者重跑作者可用clawsweeper review仅维护者普通 review 命令是维护者专用拥有仓库写权限的用户可以对任何开放项使用前两个命令。耐心是美德在要求的修改还没出现前反复请求只会给队列增加噪音。从源码看ClawSweeper 的审查门禁非常严格。scripts/pr-lib/clawsweeper-review-gate.mjs 是一个独立可执行脚本clawsweeper-review-gate.mjs PR head-sha它会从标准输入读取 GitHub issue 评论分页 JSON只信任来自clawsweeper[bot]Bot 类型、固定 ID且带有规范完成标记的评论校验reviewed_at、reviewed_sha、source_revision、lease_owner、lease_comment_id等字段的格式与取值拒绝未来日期、拒绝 12 小时以上的过期审查、拒绝重复完成标记并校验最新完成的reviewed_sha是否等于当前 head。这套机制保证了审查确实完成、且针对当前提交这一事实可以机器可验证——这正是它被用作合并门禁的依据。3.3 与人协作的边界当有人类贡献者或维护者接管了 PR 并正在积极工作时不要同时召唤 ClawSweeper 或在 PR 上并行操作——先让人工审查或 repair 完成。如果活动停止检查作者是否被要求提供证据或做其他更新。当 ClawSweeper 留下审查对话时把它当作普通审查反馈对待按下面的跟进清单处理。3.4 事件转发架构ClawSweeper 的接入不是直连 webhook而是通过目标端桥接详见 docs/ci/scheduled-workflows.md 的 ClawSweeper activity forwarding.github/workflows/clawsweeper-dispatch.yml用CLAWSWEEPER_APP_PRIVATE_KEY创建 GitHub App token然后向openclaw/clawsweeper投递紧凑的repository_dispatch载荷分三条 laneclawsweeper_item—— 精确的 issue / PR 审查请求clawsweeper_comment—— issue 评论中的显式 ClawSweeper 命令github_activity—— 供 ClawSweeper agent 检视的常规 GitHub 活动。github_activitylane 只转发规范化元数据事件类型、动作、actor、仓库、条目号、URL、标题、状态、评论/审查的短摘录刻意不转发完整 webhook 体。main 分支推送只是github_activity观察不产生托管式逐提交报告或 Check Run。整条路径上GitHub 标题、评论、正文、审查文本、分支名和提交信息都被视为不可信数据是摘要与分流summarization and triage的输入而非工作流或 agent 运行时的指令。四、如何在审查期间改进 PR一旦 Barnacle、ClawSweeper 或维护者给出响应就把反馈当作该 PR 的下一步行动清单把 ClawSweeper 的Rank-up moves:和Proof guidance:当作该 PR 的行动清单。评分和标签是审查信号不是固定的合并目标。推送要求的代码或文档改动当问题、解决方案、用户影响或证据发生变化时同步更新 PR 描述。补充要求的证据使用与变更匹配的证据类型。自己解决已回应的审查对话。只有需要维护者或审查者判断时才回复并保持对话开启。在分支、PR 描述、证据和相关 CI 结果都是最新状态后再请求复审。作者、维护者与 ClawSweeper 之间多轮更新-复审循环是正常的。尽量把讨论留在 PR 上。仅当 PR 需要维护者协调、自动化看起来被阻塞、或下一个决定难以在 GitHub 评论中敲定时才转到 Discord 的#clawtributors并附上 PR 链接、当前状态、以及具体问题或剩余证据。保持 PR 描述最新。评论有助于讨论但 PR 描述才是维护者与自动化反复回看的持久摘要。CONTRIBUTING.md 中对此有呼应当 ClawSweeper、Barnacle 或维护者要求更多上下文或证据时编辑 PR 描述而不是只在新评论中回复保持What Problem This Solves、Why This Change Was Made、User Impact和Evidence各节最新。status: ⏳ waiting on author表示下一步行动在 PR 作者身上先更新分支、PR 描述、证据或回复缺失的上下文再请求下一轮审查。五、证据Proof规范有用的证据包括聚焦的测试输出、CI 结果、截图、录屏、终端输出、真实环境观察、脱敏日志或产物链接。视觉类变更应尽量提供前后对比截图。证据文件链接优先链接 CI 产物、GitHub 上传的截图或录屏、或一小段脱敏日志摘录。不要提交生成的证据文件除非它们本身就是 docs、tests 或产品变更的一部分。脱敏是贡献者的责任发布证据前移除 secrets、tokens、私有 URL、用户数据和不相关的日志。从源码看证据策略是被机器评估的。scripts/github/real-behavior-proof-policy.mjs 实现了共享的 PR 上下文与证据策略定义了 ClawSweeper 拥有的标签proof: override、proof: sufficient与triage: needs-pr-context识别占位值正则n/a、none、tbd、unknown、-、空引用链接等识别空模板hasMostlyBlankTemplate会检测新旧两版模板的关键字段是否填写通过hasConcreteBehaviorContext判断是否有具体行为上下文关联 issue/PR、填写了 Problem/Why it matters/What changed、或包含 repro/regression/root cause/crash 等信号词通过hasClearDesignContext判断是否有设计上下文RFC、design、architecture、maintainer request 等。clawsweeper_exact_head_pass这一审查结论状态则代表ClawSweeper 对精确 head 的审查通过。这些函数共同支撑 Barnacle 的标签决策与 ClawSweeper 的证据评估——也就是说证据不足不是主观印象而是可复现的文本与结构分析。六、Stale 自动关闭机制OpenClaw 还使用独立的 stale 自动化未分配的 issue 与 PR连续 14 天无活动后标记为 stale再闲置 7 天后关闭。已分配的 PR打开 27 天后无论之后是否有更新标记为 stale再经过 7 个 stale 日无活动后关闭。如果已分配的 PR 仍然活跃请与正在处理它的维护者协调。此外docs/ci/scheduled-workflows.md 还提到 Barnacle 会把标记为 bug 的 issue 当作验证候选而非闲置关闭候选Barnacle 可以给它打上stale标签这会触发一次精确的 ClawSweeper 审查但不能关闭该 issueClawSweeper 随后可能给出基于证据的结论——在最新 main 上被证实修复的按 completed 关闭仍存在或证据不足的保持打开。stale 工作流还会审计最近的关闭事件发现 Barnacle 身份将 bug 以not_planned关闭时即失败。七、当自动化保持安静时自动化可能保持安静的原因维护者已经在处理该项review 或 repair 请求仍在排队事件属于常规事件routineClawSweeper 的 lane 未配置对应请求的动作。另一个重要情形当受信任工作流需要运行不可信的贡献者代码时自动化会回避行动此时维护者改用正常审查或更安全的工作流。八、故障排查如果 ClawSweeper 没有立即响应先等待再重试。服务基于队列重复评论或反复改动标签只会让线程更难审查并不会让队列变快。向他人求助前先检查以下清单PR 描述是否最新最新提交是否包含要求的改动CI 是否已完成或 PR 描述是否解释了剩余失败与 PR 无关最新审查请求是否以 PR 评论形式发出clawsweeper re-review是否没有维护者或贡献者正在积极处理该 PR最新请求是否仍在 ClawSweeper 正常的队列延迟窗口内。如果 PR 已是最新状态后数小时仍无 ClawSweeper 响应或 PR 看起来被自动化阻塞请到 Discord#clawtributors求助并附上PR 链接、你期望的行为、你发起请求的时间、以及自上次 bot 评论以来发生了什么变化。九、复用或分叉这套自动化希望获得类似审查自动化的项目可以参考或分叉 ClawSweeper 项目及其文档。在本仓库内可以研究的核心参考实现包括scripts/github/barnacle-auto-response.mjs —— 确定性分流规则表、候选标签分类、标签同步与自动响应主流程scripts/github/real-behavior-proof-policy.mjs —— PR 上下文与证据策略的共享实现scripts/pr-lib/clawsweeper-review-gate.mjs —— 审查完成标记的机器验证门禁docs/ci/scheduled-workflows.md —— ClawSweeper 事件转发架构与 lane 设计。需要注意这套自动化的设计与 OpenClaw 的仓库治理强相关PR 模板结构、Evidence 要求、20 PR 上限、维护者团队权限模型等分叉时应同步调整规则表与模板解析逻辑。十、贡献者速查清单结合 CONTRIBUTING.md 与本文向 OpenClaw 提交 PR 时的关键动作如下填写 PR 模板的What Problem This Solves与Evidence描述具体的用户、产品或运维问题保持单一职责一个 PR 只做一件事关联 issueCloses #issue或Related: #issue视觉变更提供前后截图其他变更提供聚焦测试输出、CI 结果、录屏、脱敏日志或产物链接收到 Barnacle/ClawSweeper/维护者反馈后按四、如何在审查期间改进 PR的六步清单行动先更新分支与 PR 描述再以评论clawsweeper re-review请求复审不要把纯 refactor、为追逐已知 main CI 失败而开的 test-only PR 提交到核心仓库这类 PR 会被自动关闭活跃 PR 保持在 20 个以内需要超限的协调变更集先到#clawtributors与维护者沟通。Barnacle 与 ClawSweeper 共同构成了 OpenClaw 的分流 审查双引擎前者用确定性的规则守住队列入口后者用 AI 能力提供深度审查与证据评估而两者之上永远是维护者的最终判断。理解这套流程既能让你在贡献 PR 时少走弯路也为搭建类似的开源协作自动化提供了完整的参考蓝本。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
