dotnet/skills PR 分诊架构详解批处理编排器与单PR Worker如何协同【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skillsdotnet/skills是一个为 AI 编码代理提供 .NET 与 C# 技能skills的开源仓库。为了让大量涌入的 Pull Request 无需人工催促就能持续流转它设计了一套PR 分诊PR Triage自动化架构由一个每小时运行的批处理编排器Batch Orchestrator计算每个 PR 的确定状态再分发给单 PR Worker执行标签、评估触发与维护者提醒等动作。本文将用最通俗的方式带你完整看懂这套编排器 Worker协同体系。️ PR 分诊自动化全景三个核心组件整个体系由三个 GitHub Actions 工作流组成各司其职组件文件角色触发方式批处理编排器.github/workflows/pr-triage-batch.yml每小时枚举所有非草稿 PR计算确定性状态并分发任务cron: 17 * * * *每小时单 PR Worker.github/workflows/pr-triage.yml针对单个 PR 复核状态、调整标签、触发评估或提醒workflow_dispatch被编排器分发恶意代码扫描器.github/workflows/pr-malicious-scan.agent.md对不可信贡献者的 PR 做静态 diff 审查workflow_dispatch被编排器分发设计文档在 docs/design/pr-triage-workflows.md完整描述了架构与状态机。 批处理编排器详解只算账不动手每小时扫描枚举 PR 并计算确定性状态编排器每小时避开整点防止与评估流水线的00:00cron 撞车醒来一次用gh pr list拉取最多 200 个未合并、非草稿的 PR逐个读取关键信号作者身份是否为 Bot是否是 OWNER / MEMBER / COLLABORATOR即受信任贡献者合并状态mergeable_state是否已确定是否存在冲突dirty评审进度评审决定是CHANGES_REQUESTED还是APPROVED是否有未解决的评论线程评估状态当前 head 提交上evaluation-status的检查结果是成功、失败还是进行中关键点编排器完全不调用大模型只做确定性的 API 读取与规则判断。它唯一会写的东西是一条幂等标记评论后文详述。每轮运行还会输出一张漂亮的分诊计划表Triage plan到运行摘要中列出每个 PR 的状态与将要采取的动作透明度极高。分发策略Worker 与扫描器二选一根据计算出的状态编排器决定每个 PR 的去处needs-malicious-scan非受信任贡献者、且该 head 上还没有扫描标记→ 分发恶意代码扫描器其他所有需要处理的状态→ 分发单 PR Worker并附上自己算出的intended_state供参考为了防止重复扫描编排器在触发扫描器之前会先在 PR 上发一条带有隐藏标记的评论!-- pr-malicious-scan:dispatchedsha7 --这条预分发标记是该提交已启动过扫描的唯一事实来源——即使扫描器因 PAT 故障或完整性拦截而启动失败也不会被重复调度而作者一旦推送新提交新 SHA扫描会自然重新触发。此外每轮分发数量受max_dispatches默认 30硬上限保护避免单轮失控。 单 PR Worker 详解复核、对齐标签、做且仅做一件事Worker 为什么不信任编排器Worker 收到的intended_state只是参考信息。从被分发到真正执行之间可能过去了数分钟PR 状态可能已变化。因此 Worker 脚本 pr-triage-act.sh 会独立地重新拉取 GitHub API 数据、重新计算状态以运行时实况为准。这种编排器算一遍、Worker 复核一遍的双重校验是分布式自动化中防止竞态条件的经典做法。8 状态状态机每个 PR 该走哪条路Worker 按固定优先级、首条命中即止的规则为 PR 定性优先级条件简述状态对应标签动作1草稿或mergeable_state未知skip—不处理2非受信任贡献者且未扫描needs-malicious-scan—分发扫描器3要求修改 / 有未解决线程 / 有冲突needs-author-attentionwaiting-on-author提醒作者4评估成功 已批准ready-for-mergeready-to-merge提醒维护者5评估成功 待评审ready-for-reviewwaiting-on-review提醒维护者6评估成功 其他评审决定in-reviewpr-state/in-review仅对齐标签7评估进行中当前 head 有运行evals-in-progresspr-state/evals-in-progress仅对齐标签8其余情况ready-for-evalpr-state/ready-for-eval触发评估Worker 每次运行最多执行一个动作对齐那唯一的状态标签把 8 种状态标签互斥地对齐并顺带清理历史遗留标签、触发评估、提醒作者、或提醒维护者。职责单一行为可预测。冷却机制4 天内绝不重复打扰提醒类动作作者 ping / 维护者 ping会在评论里写入隐藏 HTML 指纹标记例如!-- pr-triage:fingerprintauthor-ping:{sha7}:{yyyy-mm-dd} --Worker 下次运行时会先检索这些历史标记同一变体在 4 天冷却期默认内已有标记→ 新提醒被抑制避免轰炸作者和维护者首提门控PR 创建后 30 分钟内的首次提醒也会被抑制刚开的 PR 可能只是没来得及评审打上no-stale标签的 PR 可完全退出提醒与自动关闭。️ 不可信 PR 的特殊通道恶意代码扫描器对外部非受信任贡献者的 PR架构走一条更谨慎的路径先由编排器分发静态 diff 审查。扫描器只阅读 diff、从不执行 PR 中的代码、更不用写权限 checkout head 分支发现问题以代码扫描告警 一条维护者提醒评论的形式上报。这套先安检、后评估的顺序状态机优先级 2 高于其他所有状态保证了不可信代码在进入评估流水线之前就被审查过。 顺带的周报清洁工Stale PR 清扫编排器还内嵌了一个确定性任务stale-sweep每周一 04:17 UTC 运行 pr-stale-sweep.sh——没有模型调用、不花任何 token30 天内创建或仍有活动的 PR → 跳过3037 天无人非 Bot活动 → 发一次陈旧警告有标记防重复超过 37 天无活动 → 直接关闭并留言。注意它只统计非 Bot的评论与评审Bot 自己发的警告永远不会续命。no-stale标签与特定维护 Bot 的 PR 则完全豁免。 从状态到合并评估的四个入口当 Worker 判定 PR 处于ready-for-eval时它会分发 evaluation.yml。整个系统共有 4 个入口能喂给评估流水线的gate任务且全部共享每 PR 一个并发组重叠触发会折叠为一次运行并始终绑定到某个具体的已评审提交而非分支实时头/evaluate sha斜杠命令评论中需显式提供 SHA已提交 PR 评审中的/evaluate推荐路径自动绑定被评审的 commit人工添加evaluate-now标签gate消费后即移除可再次触发Worker 通过workflow_dispatch直接分发——因为 Bot 添加的标签事件受 GitHub 防递归保护不会启动工作流workflow_dispatch恰好豁免该限制评估完成后PR 上会张贴类似如下的评估结果评论来自 Vally 评估引擎 仓库判定策略评估状态回写到evaluation-status检查后下一小时编排器扫描时自然会把 PR 推进到ready-for-review或ready-for-merge状态——闭环完成全程无人工催促。 设计亮点速览确定性优先编排器零模型调用行为可完全推演成本可忽略双重复核编排器算状态只是建议Worker 运行时重算杜绝竞态幂等标记即事实来源预分发标记让扫描器启动失败也不至于重复调度最小惊讶原则4 天冷却 30 分钟首提门控 单动作原则自动化永远温和安全分层不可信 PR 先过静态安检再进评估且评估用受信构建产物隔离执行。想亲手验证这套架构打开 docs/design/pr-triage-workflows.md 对照 .github/workflows/pr-triage-batch.yml 与 .github/workflows/pr-triage.yml 逐行阅读再配合 pr-triage-act.sh 中的状态机实现即可完整还原编排器 Worker如何像钟表齿轮一样精密协同。️【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 dotnet/skills PR 分诊架构详解：批处理编排器与单PR Worker如何协同？
dotnet/skills PR 分诊架构详解批处理编排器与单PR Worker如何协同【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skillsdotnet/skills是一个为 AI 编码代理提供 .NET 与 C# 技能skills的开源仓库。为了让大量涌入的 Pull Request 无需人工催促就能持续流转它设计了一套PR 分诊PR Triage自动化架构由一个每小时运行的批处理编排器Batch Orchestrator计算每个 PR 的确定状态再分发给单 PR Worker执行标签、评估触发与维护者提醒等动作。本文将用最通俗的方式带你完整看懂这套编排器 Worker协同体系。️ PR 分诊自动化全景三个核心组件整个体系由三个 GitHub Actions 工作流组成各司其职组件文件角色触发方式批处理编排器.github/workflows/pr-triage-batch.yml每小时枚举所有非草稿 PR计算确定性状态并分发任务cron: 17 * * * *每小时单 PR Worker.github/workflows/pr-triage.yml针对单个 PR 复核状态、调整标签、触发评估或提醒workflow_dispatch被编排器分发恶意代码扫描器.github/workflows/pr-malicious-scan.agent.md对不可信贡献者的 PR 做静态 diff 审查workflow_dispatch被编排器分发设计文档在 docs/design/pr-triage-workflows.md完整描述了架构与状态机。 批处理编排器详解只算账不动手每小时扫描枚举 PR 并计算确定性状态编排器每小时避开整点防止与评估流水线的00:00cron 撞车醒来一次用gh pr list拉取最多 200 个未合并、非草稿的 PR逐个读取关键信号作者身份是否为 Bot是否是 OWNER / MEMBER / COLLABORATOR即受信任贡献者合并状态mergeable_state是否已确定是否存在冲突dirty评审进度评审决定是CHANGES_REQUESTED还是APPROVED是否有未解决的评论线程评估状态当前 head 提交上evaluation-status的检查结果是成功、失败还是进行中关键点编排器完全不调用大模型只做确定性的 API 读取与规则判断。它唯一会写的东西是一条幂等标记评论后文详述。每轮运行还会输出一张漂亮的分诊计划表Triage plan到运行摘要中列出每个 PR 的状态与将要采取的动作透明度极高。分发策略Worker 与扫描器二选一根据计算出的状态编排器决定每个 PR 的去处needs-malicious-scan非受信任贡献者、且该 head 上还没有扫描标记→ 分发恶意代码扫描器其他所有需要处理的状态→ 分发单 PR Worker并附上自己算出的intended_state供参考为了防止重复扫描编排器在触发扫描器之前会先在 PR 上发一条带有隐藏标记的评论!-- pr-malicious-scan:dispatchedsha7 --这条预分发标记是该提交已启动过扫描的唯一事实来源——即使扫描器因 PAT 故障或完整性拦截而启动失败也不会被重复调度而作者一旦推送新提交新 SHA扫描会自然重新触发。此外每轮分发数量受max_dispatches默认 30硬上限保护避免单轮失控。 单 PR Worker 详解复核、对齐标签、做且仅做一件事Worker 为什么不信任编排器Worker 收到的intended_state只是参考信息。从被分发到真正执行之间可能过去了数分钟PR 状态可能已变化。因此 Worker 脚本 pr-triage-act.sh 会独立地重新拉取 GitHub API 数据、重新计算状态以运行时实况为准。这种编排器算一遍、Worker 复核一遍的双重校验是分布式自动化中防止竞态条件的经典做法。8 状态状态机每个 PR 该走哪条路Worker 按固定优先级、首条命中即止的规则为 PR 定性优先级条件简述状态对应标签动作1草稿或mergeable_state未知skip—不处理2非受信任贡献者且未扫描needs-malicious-scan—分发扫描器3要求修改 / 有未解决线程 / 有冲突needs-author-attentionwaiting-on-author提醒作者4评估成功 已批准ready-for-mergeready-to-merge提醒维护者5评估成功 待评审ready-for-reviewwaiting-on-review提醒维护者6评估成功 其他评审决定in-reviewpr-state/in-review仅对齐标签7评估进行中当前 head 有运行evals-in-progresspr-state/evals-in-progress仅对齐标签8其余情况ready-for-evalpr-state/ready-for-eval触发评估Worker 每次运行最多执行一个动作对齐那唯一的状态标签把 8 种状态标签互斥地对齐并顺带清理历史遗留标签、触发评估、提醒作者、或提醒维护者。职责单一行为可预测。冷却机制4 天内绝不重复打扰提醒类动作作者 ping / 维护者 ping会在评论里写入隐藏 HTML 指纹标记例如!-- pr-triage:fingerprintauthor-ping:{sha7}:{yyyy-mm-dd} --Worker 下次运行时会先检索这些历史标记同一变体在 4 天冷却期默认内已有标记→ 新提醒被抑制避免轰炸作者和维护者首提门控PR 创建后 30 分钟内的首次提醒也会被抑制刚开的 PR 可能只是没来得及评审打上no-stale标签的 PR 可完全退出提醒与自动关闭。️ 不可信 PR 的特殊通道恶意代码扫描器对外部非受信任贡献者的 PR架构走一条更谨慎的路径先由编排器分发静态 diff 审查。扫描器只阅读 diff、从不执行 PR 中的代码、更不用写权限 checkout head 分支发现问题以代码扫描告警 一条维护者提醒评论的形式上报。这套先安检、后评估的顺序状态机优先级 2 高于其他所有状态保证了不可信代码在进入评估流水线之前就被审查过。 顺带的周报清洁工Stale PR 清扫编排器还内嵌了一个确定性任务stale-sweep每周一 04:17 UTC 运行 pr-stale-sweep.sh——没有模型调用、不花任何 token30 天内创建或仍有活动的 PR → 跳过3037 天无人非 Bot活动 → 发一次陈旧警告有标记防重复超过 37 天无活动 → 直接关闭并留言。注意它只统计非 Bot的评论与评审Bot 自己发的警告永远不会续命。no-stale标签与特定维护 Bot 的 PR 则完全豁免。 从状态到合并评估的四个入口当 Worker 判定 PR 处于ready-for-eval时它会分发 evaluation.yml。整个系统共有 4 个入口能喂给评估流水线的gate任务且全部共享每 PR 一个并发组重叠触发会折叠为一次运行并始终绑定到某个具体的已评审提交而非分支实时头/evaluate sha斜杠命令评论中需显式提供 SHA已提交 PR 评审中的/evaluate推荐路径自动绑定被评审的 commit人工添加evaluate-now标签gate消费后即移除可再次触发Worker 通过workflow_dispatch直接分发——因为 Bot 添加的标签事件受 GitHub 防递归保护不会启动工作流workflow_dispatch恰好豁免该限制评估完成后PR 上会张贴类似如下的评估结果评论来自 Vally 评估引擎 仓库判定策略评估状态回写到evaluation-status检查后下一小时编排器扫描时自然会把 PR 推进到ready-for-review或ready-for-merge状态——闭环完成全程无人工催促。 设计亮点速览确定性优先编排器零模型调用行为可完全推演成本可忽略双重复核编排器算状态只是建议Worker 运行时重算杜绝竞态幂等标记即事实来源预分发标记让扫描器启动失败也不至于重复调度最小惊讶原则4 天冷却 30 分钟首提门控 单动作原则自动化永远温和安全分层不可信 PR 先过静态安检再进评估且评估用受信构建产物隔离执行。想亲手验证这套架构打开 docs/design/pr-triage-workflows.md 对照 .github/workflows/pr-triage-batch.yml 与 .github/workflows/pr-triage.yml 逐行阅读再配合 pr-triage-act.sh 中的状态机实现即可完整还原编排器 Worker如何像钟表齿轮一样精密协同。️【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考