ci: PR AI 审查 job timeout 30 → 60 分钟

[ExWang]

问题

PR AI 审查（pr-review.yml 的「AI 审查并按严重度门禁」步骤）读整个 PR diff 评审，时长随 diff 增大。较大的 PR 一轮审查会超过 job 的 timeout-minutes: 30，被 GitHub 强制 cancel → 检查 fail（是超时、非发现问题），拿不到审查结论。/review 命令走的 pr-review-command.yml 同样 30 分钟、同一审查脚本，一样会超时。

改动

两个 review workflow 的 AI 审查 job timeout-minutes: 30 → 60：

• .github/workflows/pr-review.yml（pull_request_target 自动触发）
• .github/workflows/pr-review-command.yml（/review 命令触发）

说明

• 止血为主：给足余量让大 PR 的审查能跑完；审查时长仍随 diff 增长，治本是控制单 PR 体量。
• 只改 timeout，不动审查逻辑 / 门禁口径。

为什么 60 而不是 90

.ci/pr-review-gate.sh 主模型失败时会换备用模型从头再审一轮、两轮共用同一 job 时钟，故有「60 折半 = 30 仍不够」的顾虑。实测不成立：同一个 PR（#460，61 文件 / +6.8k 行）本轮审查 8m54s 跑完，此前撞 30 分钟是 AI 负载波动的特例，60 对单轮是 2 倍余量。

「两轮都跑满」只在「主模型故障 + 超大 PR」同时发生时出现，属罕见叠加、代价也只是重跑一次，不值得为此把上限翻倍。更精确的单轮预算（给每轮套 timeout）需同时按 exit code 124/137 拆分门禁描述，超出本 PR scope，留后续。

[github-actions]

👋 感谢提交 PR @ExWang！维护者会尽快 review。

提交前请确认：

• CI 全绿（test / lint / build）
• 改动聚焦单一主题，便于审阅
• 若改动了依赖（lockfile / pyproject.toml / package.json），需维护者评论 /allow-dependencies-change <当前 head SHA> 放行（之后再 push 需重新放行）

[github-actions]

[PR #471]: ci: PR AI 审查 job timeout 30 → 60 分钟

作者: ExWang
范围: ci/raise-pr-review-timeout → main

修改方案

把两条 AI 审查通道的 job 时间上限从 30 分钟抬到 60 分钟——一条是 PR 推送时自动跑的（pr-review.yml:26），一条是维护者评论 /review 手动触发的（pr-review-command.yml:75）。审查逻辑与门禁口径一律不动，diff 就是 2 个文件各 1 行。

diff 与上轮 ci-bot 审查时完全一致（仍是 2 文件 × 1 行，commit bdfcf80 未 amend，PR 描述也未改），所以上轮三条 🔵 全部延续。本轮的增量是把证据面从「PR #460 一个 PR」扩到全仓最近 60 次审查 run，结论有两处需要修正——一处纠正我上轮自己的表格，一处推翻作者与我共同接受的因果假设。

核实一：撞墙不是「大 PR」现象——19 文件的 PR 也撞穿了 30 分钟

我上轮把 run 30518768945（/review 通道，29m44s 撞墙）算进了 PR #460 的轮次表里。这条归属是错的，它的 display_title 与 issue.number 指向的是 PR #398（feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关）：

$ gh api /repos/XiaoMi/xiaomi-miloco/actions/runs/30518768945
{"event":"issue_comment",
 "display_title":"feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关",  ← 不是 #460
 "conclusion":"cancelled"}
$ gh pr list --head feat/web-perception-toggles --json number,additions,deletions,changedFiles
{"number":398,"additions":1002,"deletions":1260,"changedFiles":19}          ← 19 文件

把全仓最近 60 次 pr-review.yml run + 全部 pr-review-command.yml run 的 job 时长排序后，job 时长恰好落在 1802s（= 30m02s，即 timeout 签名）的一共 3 条，分属 3 个不同的 PR：

撞墙 run	通道	目标 PR	该 PR 体量	审查 step 时长
30518768945	/review	#398	19 文件 / +1002 −1260	29m44s ⏱
30520948488 att1	自动	#460	63 文件 / +7330 −56	29m45s ⏱
30546242536	自动	#472	39 文件 / +5536 −124	29m47s ⏱

三条都排除了 concurrency 取消的可能：30546242536 之后该分支没有更新的 run（?branch=feat/mac-launchagent-lnp 只有它是最新），30518768945 之后 pr-review-cmd-398 组也没有第二次 /review；加上时长精确等于 30m02s，只能是 job timeout。

对本 PR 的意义（两个方向都有）：

1. 问题比作者描述的更普遍 —— 撞墙已发生在 3 个不同 PR 上，其中 30546242536（PR Feat/mac launchagent lnp #472）发生在 13:47，也就是我上轮审查结束后 45 分钟、作者写下「撞 30 分钟是特例」之后约 6 小时。这不是特例，是每天都在发生的常态。
2. 但「diff 大」不是原因 —— feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398 只有 19 文件 / 2262 行改动，比 feat(pet): 宠物识别（实验性） #460 小一个数量级，同样跑穿了 30 分钟。反过来，feat(pet): 宠物识别（实验性） #460 那份 7330 行的 diff 有一轮只花 8m31s。同一份 diff 的 7 轮实测在 8m31s ~ >30min 之间摆动（3.5 倍以上），同 PR 内的方差已经大于跨 PR 的方差——主因是模型响应速度波动，不是 diff 体量。

PR #460（feat/pet-recognition）剔掉误归属的那条、补上我上轮之后新增的一轮（30543251486，12:36，20m38s）后的完整 7 轮：

#	run	step 时长	结果
1	30510906193	10m15s	完成
2	30515053087	26m38s	完成
3	30520948488 att1	29m45s	⏱ 撞墙
4	30520948488 att2	26m42s	完成
5	30528420312	8m31s	完成
6	30540662714	17m03s	完成
7	30543251486	20m38s	完成（新增，我上轮没有这条）

修正后 #460 的中位数是 20m38s，不是我上轮写的 26m38s（上轮那个数是把 #398 的 29m44s 混进来抬上去的）。作者原始三个数据点（8m54s / 30m02s / 30m03s，job 级）我仍然逐个对到了 run 上，全部精确成立。

核实二：没有第三个闸门、没有过期文档

• git grep timeout-minutes -- .github 全仓 10 处，只有这两处属审查通道，其余（codeql 30 / opengrep 20 / docs 15 / install-smoke 20 / dependency-guard 5）与审查无关，没有漏改的第三个 30 分钟闸门。
• .ci/pr-review-gate.sh 里 grep timeout|max-turns 零命中——脚本内部没有任何第二道时间限制，单轮时长完全由模型响应速度决定。
• git grep '30 分钟' -- '*.md' 命中的全是 knowledge/ 与 plugins/skills/ 里的业务文案（久坐提醒、巡检周期），没有任何文档写着「AI 审查 30 分钟」需要跟着改，不存在过期反向引用。

下面四条 🔵 都不反对这个改动。第一、二条是上轮 🔵 的延续（未修，且本轮拿到了更强/需修正的证据），第三条是上轮 🔵 的实测确证 + 更可靠的修法，第四条是本轮新发现。

问题

🔵 建议（可选优化）

• .github/workflows/pr-review.yml — commit message 与 PR 描述都把「diff 大」当成超时原因，实测已推翻；两处对同一组 run 的频率描述还互相矛盾

  • 背景: 这条 PR 全靠「什么情况下会撞 30 分钟」立论，所以这个因果判断是它唯一的事实基础，也直接决定后来人要不要继续抬。时间线解释了矛盾怎么来的：06:10（feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398）与 06:52（feat(pet): 宠物识别（实验性） #460）两轮连续撞满 30 分钟，作者 07:39:34Z 提交 commit，此刻看到的确实像"稳定"；08:52 feat(pet): 宠物识别（实验性） #460 那轮 8m54s 跑完之后，他在 PR 描述里改口成"特例"。两次都是当时的诚实快照，拼在一起就自相矛盾了。
  • 问题: 两个层面都不成立。① 因果错：commit message 写「大 PR(diff 大)时 AI 审查一遍会超过 30 分钟」「审查时长由 diff 大小驱动」，PR 描述写「时长随 diff 增大」——但上表里 PR feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398 只有 19 文件 / 2262 行改动，照样跑穿 30 分钟；反向地，feat(pet): 宠物识别（实验性） #460 那份 7330 行 diff 有一轮只用 8m31s，同一份 diff 7 轮摆动 8m31s ~ >30min。diff 体量当然有影响，但它不是决定"会不会撞墙"的那个变量，模型响应速度波动才是。后来人 git blame 到 timeout-minutes: 60 只看得到「大 PR 才会超时」这个结论，遇到小 PR 超时时会以为是别的 bug，往错方向查。② 频率描述打架：commit 说「一个 61 文件 / +6.8k 行的 PR 稳定卡 30 分钟」（实测 1/7），PR 描述说「8m54s 跑完，撞 30 分钟是特例」（8m31s 恰是 7 轮里最快那轮，它才是离群点，而且 6 小时后 Feat/mac launchagent lnp #472 又撞了一次）。另外 61 文件 / +6.8k 行 这个体量数字已经过期（feat(pet): 宠物识别（实验性） #460 现在是 63 文件 / +7330），我上轮建议改成 63 文件 / +7.2k 同样会过期——只要 PR 还开着，任何硬编码的体量数字都会漂。
  • 改进: 只有 1 个 commit，git commit --amend + force-push 成本很低。把因果换成"波动"、把体量换成"不分大小"、不引用具体 PR 体量数字：

    ci: PR AI 审查 job timeout 30 → 60 分钟
    
    AI 审查单轮时长随模型响应速度大幅波动,同一份 diff 实测可在 8 分钟到 30 分钟以上
    之间摆动;撞 30 分钟上限被 job timeout 强制取消、拿不到结论(是超时、非发现问题)的
    情况今天已在 3 个 PR 上各发生 1 次,其中最小的一个只有 19 文件 / 2262 行改动——
    即 diff 体量有影响但不是决定性变量,不能靠"拆小 PR"规避。先给
    pull_request_target(pr-review.yml) 与 /review 命令(pr-review-command.yml) 的
    AI 审查 job 提到 60 分钟余量;只改 timeout、不动审查逻辑与门禁口径。
    

    PR 描述里「问题」段的「时长随 diff 增大」与「为什么 60 而不是 90」段的「特例」同步改成"随模型负载波动、与 diff 体量弱相关"即可，三处口径对齐。

• .ci/pr-review-gate.sh:46-58 — 「60 对单轮是 2 倍余量」这个结论建立在右截断样本上，双轮路径的余量实际没测到

  • 背景: 门禁脚本主模型失败时会换备用模型 / endpoint 从头重审一轮，两轮共用同一个 job 时钟，脚本内部没有任何单轮预算划分——pr-agent 两次调用都是裸调、没有 timeout 包裹：

    REVIEW_OK=0
    if /usr/local/bin/pr-agent "/review-pr $PR_NUMBER --ci" < /dev/null; then   # ← 无时间上限
      REVIEW_OK=1
    elif [ -n "${ANTHROPIC_FALLBACK_API_KEY:-}" ] && [ -n "${PR_AGENT_FALLBACK_MODEL:-}" ]; then
      # ...
      if /usr/local/bin/pr-agent "/review-pr $PR_NUMBER --ci" < /dev/null; then # ← 同样无上限，共用 job 时钟

    这就是我上轮那条 🟡 的由来。
  • 问题: 作者的反驳是「60 对单轮是 2 倍余量」，但全仓 60 次 run 里有 3 次是在 30 分钟被 cancel 的——这 3 次的真实时长永远不知道（可能 32 分钟，也可能 50 分钟），样本在 30 分钟处被右截断了。也就是说「单轮最长要多久」这个数至今没有测到过，拿截断样本算"2 倍"，倍数是虚的。落到双轮路径：用测得到的最长完成轮 26m42s 算，两轮 53m24s，距 60 分钟只剩 6m36s；只要单轮真实尾部超过 30 分钟（已有 3 次疑似），双轮必然破 60 → job 被 cancel → 走到下面第三条的 status 悬空。另外作者「两轮都跑满只在超大 PR 才出现」的前提也被 feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398 推翻了（19 文件也能跑满一轮），所以罕见性没有"体量门槛"兜着，只剩"主模型故障"这一个条件。我仍同意这是 🔵 不是 🟡：代价只是重跑一次；只是「2 倍余量」这个说法建议别写进结论，它给人的安全感比数据支持的要多。
  • 改进: 想要确定性的单轮预算，给每轮套 timeout 即可（作者已说明按 exit code 124/137 拆分门禁描述超出本 PR scope，那就纯留后续，这里只给形状）：

    # 单轮预算：主备各 25 分钟，双轮最坏 50 分钟仍在 60 分钟 job 时钟内，且能测到真实尾部
    PER_ROUND_TIMEOUT="${PR_REVIEW_ROUND_TIMEOUT:-25m}"
    REVIEW_OK=0
    if timeout "$PER_ROUND_TIMEOUT" /usr/local/bin/pr-agent "/review-pr $PR_NUMBER --ci" < /dev/null; then
      REVIEW_OK=1
    elif [ -n "${ANTHROPIC_FALLBACK_API_KEY:-}" ] && [ -n "${PR_AGENT_FALLBACK_MODEL:-}" ]; then
      echo "[WARN] 主模型不可用或单轮超时，尝试降级到备用模型"
      # ...（原有 export 不变）
      if timeout "$PER_ROUND_TIMEOUT" /usr/local/bin/pr-agent "/review-pr $PR_NUMBER --ci" < /dev/null; then
        REVIEW_OK=1
      fi
    fi

    退而求其次：直接 90，理由写「单轮尾部未测到，双轮各留 45 分钟」，比现在的「2 倍余量」更站得住。

• .github/workflows/pr-review.yml:70 / pr-review-command.yml:127 — 撞 timeout 时 pr-review commit status 不回写；/review 通道零痕迹（上轮为推演，本轮实测确证）

  • 背景: job 被 timeout cancel 时，AI 审查并按严重度门禁 整个 step 一起 cancelled，写 status 的 gh api 在该 step 的最后、永远执行不到。上轮我只能推演后果，本轮 PR Feat/mac launchagent lnp #472 提供了可直接对账的样本。

  • 问题: 拿 PR Feat/mac launchagent lnp #472 同一个分支的两个 sha 对比，pr-review status 的有无一目了然：

    sha	对应 run	结果	commit statuses
    aafefc78	30536133888	跑完	license/cla + pr-review=success
    50ecf599	30546242536	30m02s 被 timeout cancel	只有 license/cla，pr-review 完全缺失

    两条通道的观感差别很大：自动通道因为 pull_request_target 的 job 本身就是 PR check，rollup 里还能看到 pr-review = CANCELLED（PR Feat/mac launchagent lnp #472 现在就是这个状态，mergeStateStatus: BLOCKED），维护者至少知道审查没跑完；/review 通道的 run 是 issue_comment 触发、根本不是 PR 的 check，commit status 是它唯一的输出通道，所以 06:10 那次超时（PR feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398，pinned sha c9550cb0）在 PR 页面上什么都没留下——维护者只会觉得 /review 没反应，30 分钟白等。本 PR 把 30 抬到 60 降低了撞墙概率，等于间接缓解，盲区还在。

  • 改进: 我上轮建议加 if: cancelled() 兜底 step，但job 级 timeout 触发的是取消流程，if: cancelled() 的 step 能否在 grace period 内跑完并不确定。更可靠的形状是把时间上限下移到 step 级（低于 job 级），让超时落在 step 上、job 不被 cancel，后续 if: always() step 就有确定的执行机会。pr-review.yml 改成：

      - name: AI 审查并按严重度门禁
        id: review
        # 比 job 的 60 分钟低 5 分钟：让超时落在 step 上（job 不被 cancel），
        # 下面 if: always() 的回写才有确定的执行机会，不依赖 cancellation 的 grace period
        timeout-minutes: 55
        run: |
          git fetch origin main
          if git show origin/main:.ci/pr-review-gate.sh \
            | bash -s -- "${{ github.event.pull_request.number }}" "${{ github.repository }}"; then
            echo "state=success" >> "$GITHUB_OUTPUT"
            echo "desc=未发现严重/重要问题" >> "$GITHUB_OUTPUT"
          else
            echo "state=failure" >> "$GITHUB_OUTPUT"
            echo "desc=发现严重/重要问题" >> "$GITHUB_OUTPUT"
          fi
    
      - name: 回写 pr-review commit status
        if: always()
        env:
          # step 超时时 outputs 为空（gate 没返回就没写 GITHUB_OUTPUT），兜底成 failure + 可辨认的描述
          STATE: ${{ steps.review.outputs.state || 'failure' }}
          DESC: ${{ steps.review.outputs.desc || '审查未完成（超时或异常），请重跑 /review' }}
        run: |
          gh api "repos/${{ github.repository }}/statuses/${{ github.event.pull_request.head.sha }}" \
            -f state="$STATE" -f context="pr-review" -f description="$DESC" >/dev/null
          [ "$STATE" = success ]

    pr-review-command.yml 里同一形状，把 SHA 换成 $HEAD_SHA（即 needs.authorize.outputs.head_sha）。这条与本 PR 正交，可另开 PR；因为它同时兼顾了「审查逻辑不动」和「超时也有痕迹」，优先级建议排在继续抬上限之前。

• .github/workflows/pr-review.yml:11-13 / pr-review-command.yml:16-18 — 两条通道的 concurrency group 互不覆盖，同一 PR 可并行跑两轮审查、争抢同一条 review-pr-ci 评论；抬到 60 分钟把重叠窗口拉长

  • 背景: 两个 workflow 各有自己的 concurrency group，名字不同 → 不会互相取消：

    # pr-review.yml:12
    group: pr-review-${{ github.event.pull_request.number }}
    # pr-review-command.yml:17
    group: pr-review-cmd-${{ github.event.issue.number }}      ← 不同前缀，同一 PR 也不互斥

    两条通道跑的是同一条命令 /review-pr <n> --ci，都会「找到那条 <!-- review-pr-ci --> 评论 → PATCH 它」，也都往同名 pr-review context 写 status。
  • 问题: 这不是推演，PR feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398 上已经真实并发过一次：维护者 06:10:29 发 /review（run 30518768945，钉死 sha c9550cb0），作者 06:14:40 推了新 commit 6beecd63 触发自动审查（run 30518986914）——两条通道 06:14:52 ~ 06:32:19 共并行了 17.5 分钟，各自审的还是不同的 sha。这次侥幸：自动通道 06:32 先写完评论，命令通道 06:40 撞墙被 kill、没能覆盖。但顺序反过来（命令通道后完成）就会用已被 push 取代的旧 sha 的审查结论盖掉新 sha 的结论，PR 上只剩一条描述"已经不存在的代码"的评论，作者对着看不懂。此外命令通道明知 head 已经前进（校验 head 未被偷换 只在 checkout 那一刻校验一次）还继续烧满时钟，抬到 60 分钟后这段无用重叠最长可达 60 分钟。
  • 改进: 让两条通道共用一个 group，后触发的取消先触发的（同一 PR 只保留最新一轮审查，与 pr-review.yml 现有注释「同一 PR 连续 push 时取消上一次审查，只留最新」的意图一致）。两个文件都改成同一个表达式：

    # pr-review.yml
    concurrency:
      # 与 pr-review-command.yml 共用同一 group：同一 PR 上「push 自动审查」与「/review 手动审查」
      # 也互相取消，避免两轮并发 PATCH 同一条 review-pr-ci 评论时后写者用旧 sha 结论覆盖新结论
      group: pr-review-${{ github.event.pull_request.number }}
      cancel-in-progress: true

    # pr-review-command.yml —— group 表达式必须与上面逐字符相同，只是取号字段不同
    concurrency:
      group: pr-review-${{ github.event.issue.number }}
      cancel-in-progress: true

    同样与本 PR 正交，可另开 PR。注意它与上一条有依赖关系：合并 group 后被取消的那一轮同样会留下悬空 status，所以上一条的 if: always() 回写应当先落地。

结论

LGTM — 2 个文件各 1 行，把两条审查通道从同一个已被实测撞穿的值（30 分钟）抬到 60 分钟。改动方向没有疑问：撞墙今天已在 3 个不同 PR（#398 / #460 / #472）上各发生一次，最近一次是 13:47（我上轮审查结束后 45 分钟），且没有第三个 30 分钟闸门、没有过期文档引用漏改。作者原始三个数据点全部精确成立。

四条 🔵 都不构成合并阻塞：

1. commit message 与 PR 描述把超时归因于「diff 大」，被 19 文件的 feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398 撞墙推翻，且两处对频率的描述（「稳定」vs「特例」）互相矛盾、硬编码的 PR 体量数字已过期——建议 amend 成"随模型负载波动、与体量弱相关"（只有 1 个 commit，成本很低）。
2. 「60 对单轮是 2 倍余量」是在被 30 分钟截断的样本上算出来的，双轮路径实测余量只剩 6m36s；作者已明确把单轮预算划分留作后续，我同意这个 scope 划分。
3. 超时导致 commit status 悬空——本轮用 PR Feat/mac launchagent lnp #472 两个 sha 的 status 对比实测确证，/review 通道确实零痕迹；同时修正我上轮给的 if: cancelled() 方案，改为更可靠的「step 级 timeout + if: always() 回写」。
4. 新发现：两条通道 concurrency group 不互斥，PR feat(web): PerceptionDeviceTable 独立摄像头视频/音频开关 #398 上已并行跑过 17.5 分钟，抬到 60 分钟会拉长这段重叠——建议两个 workflow 共用同一 group。

第 3、4 条与本 PR 正交，建议另开一个 PR 一并处理（先 3 后 4）。

---

_{由 review-pr skill v1.6 生成}

[ExWang]

ci-bot 的 🟡 我看过：它按「主备两轮共用 job 时钟」把 60 折半算成 30。实践中不成立——同一个 PR（#460，61 文件 / +6.8k 行）本轮审查 8m54s 跑完，此前撞 30 分钟是 AI 负载波动的特例；60 对单轮是 2 倍余量。

「两轮都跑满」只在「主模型故障 + 超大 PR」同时发生时出现，属罕见叠加、代价也只是重跑一次，不值得为它把上限翻倍。单轮预算划分（给每轮套 timeout）需要同时按 exit code 124/137 拆分门禁描述，超出本 PR scope，留后续。

维持 60，请 reviewer 判断是否放行。

[ExWang]

/review

[Molly-3000]

LGTM

[idootop]

/review

[ExWang]

/review

[ExWang]

ci-bot审查卡住，且本PR仅更新延长等待时间的阈值（30min→60min），足以通过这个解决个别ci审查等待时间较长的case，故先merge