原文：https://indieseek.co/zh/blogs/qwen-code-0-21-1-event-driven-ci-finalizer-checklist/
Qwen Code 0.21.1：别让 AI 审查 Agent 在对话里轮询 CI
快速结论
Qwen Code 0.21.1 对仓库 Triage 工作流做了一项很值得复用的调整：AI Reviewer 不再占用 Agent Turn 轮询 CI，也不会在必要检查仍处于 Pending 时提前审批。它只记录一次当前被审 Commit 和已有证据；CI 完成后，再由确定性的 GitHub Actions Finalizer 唤醒、刷新事实并落定结果。
可复用的模式是：
- 让 Agent 分析改动并给出暂定结论。
- 把结论和证据绑定到唯一的 Head Commit。
- 必要 Checks 尚未完成时，只记录范围严格的“全绿后可审批”意图，不立即 Approve。
- 通过
workflow_run唤醒不调用模型的 Finalizer。 - 重新读取 PR 状态、Head SHA、Check Suite 和已有 Review。
- 仅当证据集合已经闭合且全部通过时审批；其他情况继续等待或 Fail Closed。
这不是面向所有仓库开放的 Qwen Code 新开关。官方稳定版展示的是 Qwen Code 自己的 Triage 实现。你可以复用这种架构，但仍需为自己的仓库实现并审计工作流。
适合谁
这篇指南适合在 GitHub Actions 上构建 AI PR Reviewer、Autofix Bot 或 Coding Agent 流水线的维护者。当 Agent 比 CI 更早完成分析时，轮询只会浪费资源，或在最慢检查完成前耗尽等待预算。
如果当前首要问题是证明 Agent 到底完成了什么，先使用 Qwen Goal 证据检查表。如果 Issue 会自动触发 Agent 工作，则应在任何写操作前保留置信度与审批门禁。
更新内容及其意义
Qwen Code 0.21.1 Release Notes 明确写到：Triage 流程停止在 Agent 内轮询 CI，并在 CI 完成后再落定证据与审批。已合并实现记录了旧问题：Agent 最多轮询约 10 分钟，而长单测约需 30 分钟；官方案例中的审批早于该单测完成。
新方案把“推理”与“等待”拆开。Agent 只拉取一次 Check Run，如实记录仍在 Pending 的检查。CI 状态变化后，确定性 Finalizer 再更新受控证据区域，并且只有在重新核对当前状态后，才允许发出绑定 Commit 的审批。
这项拆分之所以重要，是因为“等待”不是智能问题。Model Turn 不是好用的 Scheduler，过期的对话上下文也不应成为 CI 当前状态的事实来源。
双通道架构
| 通道 | 职责 | 禁止事项 |
|---|---|---|
| Agent 审查通道 | 理解意图、检查 Diff、识别风险、运行可用探针并给出暂定结论 | Sleep 等待 CI，或把 Pending 写成已通过 |
| 确定性 Finalizer | 由 CI 事件唤醒、读取 GitHub 当前状态、执行不变量并完成被允许的终态写入 | 重新解释代码改动，或扩大 Agent 权限 |
交接内容必须是受限标识符，而不是“把 PR 收尾”：仓库、PR、被审 SHA、必要 Checks、暂定结论和证据记录。
六阶段 Finalizer 工作流
1. 固定审查 Revision
Agent 阅读 Diff 前先记录 PR Head SHA，并把所有证据和待定审批绑定到它。Head 一旦移动，旧意图立即过期。
2. 只读取一次 CI
Agent Turn 内只读取一次相关 Workflow Run 和 Check Suite，区分 success、failure、cancelled、skipped 与 pending。只要有必要检查仍在 Pending，就停止等待并进入 Deferred。
3. 写入范围严格的交接记录
写入可认证、幂等的记录，它只能表达：“如果指定证据全部转绿，这个被审 SHA 可以审批。”任意 PR 评论不能制造权限；Qwen 只接受自己的 Bot Marker。
4. 由 workflow_run 唤醒
Finalizer 应使用完成状态的 workflow_run；GitHub 要求对应 Workflow 文件已存在于默认分支。按 PR 或 SHA 串行化，避免多个 Checks 争抢证据区域或重复发出 Review。
5. 重新核对所有终态不变量
任何写操作前，都要重新读取 PR 并验证：
- PR 仍然 Open，且不是 Draft；
- 当前 Head SHA 仍等于被审 SHA；
- 交接记录来自预期身份；
- 该 SHA 的全部必要 Checks 都存在且已稳定；
- 没有必要结果失败、取消或缺失；
- 该 SHA 尚未存在相同审批；
- 仓库特有护栏仍然允许审批。
通过 GitHub Review API 的 commit_id 字段把审批绑定到被审 Commit。评论中写“批准 abc123”的约束力，弱于真正携带该 SHA 的 API Review。
6. 只落入一个终态
最终只写入 approved、failed、stale、guarded 或 still_pending 之一。保留周围证据，并让重复事件收敛。
可复制的 Finalizer 契约
agent_ci_handoff:repository: "owner/repo"pull_request: 123reviewed_head: "完整 commit SHA"provisional_verdict: "approve_if_green"required_workflows:- "unit"- "integration"evidence_record: "Bot 写入的评论或 Artifact ID"terminal_checks:require_open_pr: truereject_draft: truerequire_same_head: truerequire_closed_green_set: truepin_review_to_commit: trueoutcomes:- approved- failed- stale- guarded- still_pending
这是一份架构契约，不是 Qwen Code 配置。
八项验收测试
| 测试 | 预期结果 |
|---|---|
| 一项必要检查仍在运行 | 不审批，保持 Pending |
| 必要检查失败或取消 | Fail Closed，并记录结果 |
| 审查后 PR Head 发生变化 | 标记 Stale，要求重新审查 |
| 第三方复制交接 Marker | 忽略 |
| Finalizer 事件触发两次 | 只写一次终态，结果一致 |
| PR 已关闭或变成 Draft | 不审批 |
| Check 数据为空或不完整 | 保留原证据，继续等待 |
| 被审 SHA 的全部必要检查通过 | 只发出一次绑定 Commit 的审批 |
常见错误
在 Model Turn 内轮询。 它不会提高审查质量，却会消耗资源并制造预算边界竞态。
让高权限 Finalizer 执行不可信代码。 GitHub 建议最小权限并谨慎处理不可信 Checkout。Finalizer 通常只需读取 API 并执行一个受限写入，不应运行 PR 分支。
把所有 Check Run 都当成必要证据。 应明确可信集合，否则 Bot 编排、已替代 Suite 和 Finalizer 自己都可能污染门禁。
FAQ
Qwen Code 0.21.1 会自动给我的仓库安装这个 Finalizer 吗？
不会。稳定版包含的是 Qwen Code 自己 Triage 流程中的实现。除非你使用的具体 Qwen 工作流明确安装了等价自动化，否则应把它视为经过验证的参考实现和架构模式。
来源
- Qwen Code v0.21.1 Release
- Qwen Code PR：停止在 Agent 内轮询 CI
- GitHub Actions：workflow_run 事件
- GitHub Actions 安全使用参考
- GitHub Actions Concurrency
- GitHub REST API：Pull Request Reviews