检查与评审

Agent 交来的改动，人不必逐行去审。交给你验收之前，Studio 组织两道关：代码仓库的 CI 检查，以及另一个模型的代码评审。两道都通过了，任务才进入「待验收」。

检查

检查由代码仓库自己的 CI 运行，例如 GitHub Actions、GitLab CI：代码规范、类型检查、测试、构建等。Studio 读取每个 PR 的检查结果，显示在任务的「代码与部署」分区。

• 检查失败或出现冲突：Studio 唤醒调度 Agent，由它安排修复，常见的做法是先请一个 Agent 读失败的日志，判断是改动造成的还是偶发的。
• 连续三次提交仍然失败：不再为此唤醒 Agent，通知任务负责人。
• 所有必需的检查通过：唤醒调度 Agent，安排评审或交付。

项目还没有接 CI 时，PR 没有检查结果。调度 Agent 会在交付前问任务负责人是否不经 CI 直接验收；也可以在任务描述里事先写明。接入 CI 见 连接 CI。

必需检查和参考检查

在「项目设置 › 分支规则」里，可以把某些检查设为参考检查，每行写一个检查的名称：

• 参考检查：失败只做提示，不唤醒 Agent，也不阻止在 Studio 里合并。适合不稳定或者只供参考的检查，例如性能基准。
• 必需检查：其余所有检查。失败时唤醒调度 Agent，并阻止在 Studio 里正常合并。

代码托管平台自己要求的检查和审查（例如 GitHub 的分支保护规则）仍然有效，平台不允许时，在 Studio 里也合并不了。

什么时候唤醒调度 Agent

「项目设置 › 分支规则」里有三个开关：

一般保持打开。关掉某个开关后，对应的情况要由人在任务里评论，调度 Agent 才会接着推进。

评审

检查通过后，调度 Agent 把代码交给另一个 Agent 评审：

• 优先交给另一家厂商的 Agent，例如 Claude 写的代码交给 Codex 评审；没有在线的，换同一家的另一个模型。写代码的模型不评审自己的代码。
• 评审按内置技能 studio-review 进行：看缺陷、安全、设计是否简洁、测试和它们的 CI 成本，问题分级，写明哪些会阻止合并。
• 评审提出的问题，交回写代码的 Agent 修改，改完再评审。
• 评审是只读的一步，在单独的副本里进行，可以和其他工作同时进行。

要让评审照团队自己的标准来，修改 studio-review 技能，或者给项目挂一个团队的评审技能，见 技能。

合并时的检查

任务负责人点「合并」时，Studio 会再向代码托管平台核对一次 PR 和检查结果：

Agent 不能合并 PR，也不能强制合并。