Codex Cloud 现在已经能接 GitLab。OpenAI 8 月 19 日把 GitLab Support 放进 Beta可以连接 GitLab Project、为项目创建 Codex Cloud Environment从 Issue 或 Merge Request 里通过codex发起任务也可以做一次性或自动 Merge Request Review。真正值得工程团队注意的不是“终于支持 GitLab”这件事而是官方明确写出的一个限制如果 GitLab 省略了 collapsed diff 或 oversize diffCodex 就无法完成完整 Review。这句话非常关键。因为它揭示了所有 AI Code Review 系统都会遇到的一个边界模型没有看到的代码 不可能被可靠审查但很多团队最后只看一个AI Review PASS却没记录它到底看到了多少 DiffReview Coverage必须是一级指标假设一个 MRChanged Files: 42 Changed Lines: 5800GitLab 为了性能折叠了一些大文件。Codex 实际看到Files: 31 Lines: 3600如果最终只输出No critical issues found.这句话非常容易被误解成5800 行全部审过所以每次 AI Review 应该附带Coverage例如{changed_files:42,reviewed_files:31,changed_lines:5800,reviewed_lines:3600,collapsed_files:7,oversize_files:4}然后算file_coverage 31 / 42 73.8%不到阈值Review 不应该标成PASS而应该INCOMPLETE我会把Review状态拆成四种publicenumReviewStatus{PASS,FAIL,INCOMPLETE,ERROR}INCOMPLETE和PASS不是一回事。例如PASS: 已经覆盖所有要求审查的文件未发现阻断问题 INCOMPLETE: 存在未获取的 Diff不能给出完整结论UI 里也应该用不同颜色。GitLab的大Diff为什么会消失大型代码平台为了避免页面和 API 请求过重会对超大文件 生成文件 二进制 大规模变更做折叠或截断。所以 Coding Agent 不能只依赖Merge Request Diff API如果权限和工作流允许Review Worker 最好有第二条路径Checkout Repository ↓ Base Commit ↓ Head Commit ↓ git diff自己在工作区里算完整 Diff。例如gitfetch origin merge-requests/1842/head:mr-1842gitdiff\origin/main...mr-1842\--.这样至少不受 UI 折叠影响。但“自己checkout”又引入了新的安全边界如果 MR 来自不可信分支不要直接执行代码Review 阶段只需要read repository parse diff static analysis不要因为 Agent 想“验证一下”就自动npminstallnpmtest外部贡献的package.json postinstall Makefile test script都可能执行任意命令。所以 Review Environment 最好分两级Level 1: Read-only Diff Review Level 2: Sandboxed Validation只有 Level 2 才允许运行构建和测试。Webhook是另一个容易忽略的攻击面OpenAI 的 GitLab 集成说明里提到GitLab-triggered activity 需要权限配置相应 Webhook对于 GitLab Self-Managed 或 DedicatedWorkspace Admin 需要先配置连接而且 Webhook Activity 要求GitLab 19.0一旦接上 Webhook就意味着外部事件 可以触发 Agent所以必须验证Webhook Signature Project ID Event Type Branch Actor不能只看 JSON 里写{object_kind:merge_request}就启动 Codex Task。Webhook必须先去重GitLab 重试 Webhook 是正常行为。如果同一个 MR Event触发两次 Agent两个 Review 两份评论 两次成本所以需要Inbox例如EntitypublicclassGitLabWebhookInbox{IdprivateStringdeliveryId;privateStringprojectId;privateStringeventType;privateInstantreceivedAt;}处理前deliveryId 已存在 → ACK → 不重复执行自动Review不能绑定“每次push都全量重跑”一个 MR 可能连续 Push10 次如果每次都完整仓库 Review成本很快上升。可以做 Incremental Reviewprevious_reviewed_sha ↓ current_head_sha ↓ git diff old...new只审新增变化。但安全相关规则可以全量重新跑。例如Secret Scan Permission Change Dependency Change Workflow Change这几类应该每次重新检查。我会把Review拆成三层Layer 1确定性规则Secret Dependency License Protected Path Schema Generated File BinaryLayer 2静态分析CodeQL Compiler Lint Type CheckLayer 3LLM Review逻辑 可维护性 边界条件 设计问题这样不会把可以确定性发现的问题全部交给模型。MR Review的上下文也不能无限塞如果 5000 行 Diff 全交给模型上下文很贵 注意力也会稀释更合理是先建立 File Risk Score。例如risk0iffileinprotected_paths:risk5iftouches_auth:risk5ifchanges_sql:risk4iflines_changed500:risk2iftest_file:risk-1优先让 Agent 深审高风险文件低风险格式化变更减少 Token。一个MR ManifestpublicrecordMergeRequestManifest(StringprojectId,longmergeRequestIid,StringbaseSha,StringheadSha,intchangedFiles,intchangedLines,SetStringcollapsedFiles,SetStringoversizeFiles,StringdiffHash){}Review Report 必须绑定baseSha headSha diffHash否则 MR 新 Push 后旧 Review 很容易继续显示通过实际上已经过期。Review必须有Stale状态当current_head_sha ! reviewed_head_sha立即STALE不要把旧 AI Review 当成当前版本结论。publicbooleanisStale(ReviewReportreport,StringcurrentHeadSha){return!report.headSha().equals(currentHeadSha);}自动评论不要无限刷线程AI Code Review 很容易生成大量“建议考虑……”如果每个小问题都单独发评论MR 会被淹没。我会设置review:max_inline_comments:8min_severity:MEDIUMlow_severity:summary_onlyCritical/HighInlineLow汇总Review建议还需要“可验证”好的建议AuthFilter.java:91 在 token 为空时这里会 NPE 因为 line 87 的 getClaim() 可返回 null。 建议新增 test: missing_subject_claim差的“建议提高代码健壮性。”生产 Review Agent 应该要求File Line Evidence Failure Mode Suggested Test没有 Evidence 的评论降级。自动Review不能拥有Merge权限我不建议第一阶段让 Review Agentreview merge放在同一个权限主体。更合理Reviewer Agent 只产出 Review Decision Merge Controller 读取 CI Human Approval Policy 再决定 Merge避免模型同时当裁判 执行人一个最小MR Gatemerge-gate:ai-review:required:trueminimum-file-coverage:0.95allow-incomplete:falseci:required:truesecurity:critical-findings:0human:approvals:1如果 Diff Coverage 只有73%AI Review 就算没有发现问题也不能满足 Gate。GitLab Self-Managed还要多一个版本检查官方说明Webhook activity requires GitLab 19.0 or later所以 Connector 初始化时就应该检查Server Version不满足直接提示Webhook-triggered Codex tasks unavailable不要等上线后才发现自动触发不工作。我会做的12个测试1. 正常 MR 2. Oversize Diff 3. Collapsed Diff 4. MR Push 后旧 Review 变 Stale 5. Webhook 重复投递 6. Webhook 签名错误 7. 外部 Fork 不执行构建脚本 8. 5000 行大 Diff 9. Protected Path 修改 10. 自动评论上限 11. GitLab 19.0 12. AI Review PASS 但 Coverage 不足Codex 支持 GitLab 以后最容易产生的误区是“MR 已经有 AI 自动 Review 了。”真正应该问的是AI 看到了多少 Review 对应哪个 Commit 有没有被折叠的 Diff Webhook 是否重复 不可信代码有没有被执行OpenAI 明确写出“collapsed 或 oversize diff 会让 Codex 无法完成 Review”反而是一件好事。它提醒我们Code Review 的第一指标不应该是模型写了多少评论而是 Review Coverage 到底是多少。没有覆盖率的“自动审查通过”只能算一个建议不能算一个发布门禁。