Cloudflare把AI代码审查做成CI编排系统
7个审查智能体、3分39秒中位耗时，Cloudflare把AI代码审查嵌进CI并控制成本与风险。
Cloudflare用7个专项智能体把AI代码审查接进了CI流程。
这份清单看完，你会知道 5 个关键设计点，足以判断一套 AI 代码审查能不能进生产、该怎么降成本，以及哪里必须保留人工兜底。Cloudflare 的数据也说明，这不是概念展示，而是已经跑进大规模 CI 的系统。
| 项目 | 并发审查器 | 中位审查耗时 | 平均单次成本 |
|---|---|---|---|
| Cloudflare AI 审查编排 | 最多 7 个 | 3 分 39 秒 | 1.19 美元 |
| 低风险审查 | 约 2 个 | 更短 | 0.20 美元 |
| 完整高风险审查 | 7 个 | 更长 | 1.68 美元 |
1. 不做单体智能体，改做调度编排
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Cloudflare 先放弃的是“一个模型包办所有审查”的思路。复杂仓库里，单模型容易给出空泛建议、重复意见和误报，最后只会让工程师更快失去耐心。
他们改成把审查拆成多个专项智能体，再交给协调器统一汇总。这样做的重点不是让模型更强，而是让系统更像工程系统，输出也更像可执行的审查结果。
- 安全审查：找可利用风险和明确漏洞
- 性能审查：找可量化退化
- 代码质量审查：找逻辑问题与可维护性问题
- 文档、版本、AGENTS.md：处理非代码信号
2. 插件化架构把平台、模型和规范拆开
他们没有把 GitLab、模型服务和内部规范硬编码进主流程，而是做成插件架构。入口模块只负责组装配置，具体怎么跑审查、接哪个平台、接哪家模型服务商，都交给插件完成。
这种拆分的好处是边界清楚。GitLab 插件不会看到 Cloudflare AI Gateway 配置，Cloudflare 插件也不会碰 GitLab 令牌，后续换平台或换模型时，改动范围会小很多。
- 配置入口：
ci-config.ts统一收口 - 核心产物：
opencode.json - 上下文对象：只给插件可控操作，不直接暴露最终配置
3. OpenCode 负责会话，JSONL 负责流式输出
Cloudflare 选 OpenCode 作为核心编码智能体，不只是因为它开源，还因为它是服务端优先架构，适合从程序里创建会话、发送提示词、并发收集结果。协调器通过 Bun.spawn 启动 OpenCode，审查器则在内部通过 SDK 再拉起多个子会话。
更值得借鉴的是输出格式。他们不用单一 JSON 直接承载长任务结果，而是改用 JSONL 做结构化日志，每行都是独立对象。这样即使进程中途退出，也不会把整份结果写坏。
step_finish -> 记录 token 用量
error -> 触发重试
reason: "length" -> 说明输出被截断4. 专项模型分层，比全员上顶配更省钱
他们没有让所有任务都调用最贵的模型，而是按任务复杂度分层。协调器用顶级模型，负责读其他审查器的输出、去重和最终裁决；代码质量、安全、性能这类高负载任务用标准模型；文档、版本和 AGENTS.md 这类文本密集任务则交给更轻量的模型。
这种分层直接体现在成本上。首月总 Token 约 1,200 亿，缓存命中率达到 85.7%，平均单次审查成本 1.19 美元，中位数 0.98 美元，P99 也只有 4.45 美元。对大规模 CI 来说，把高成本模型只留给最需要的环节，才有长期可持续性。
- 顶级模型：协调器裁决
- 标准模型：主力子审查器
- 轻量模型：文档和版本检查
5. 熔断、回退和 break glass 让系统敢上生产
把 AI 接进发布链路，最大的难点不是能不能跑，而是出故障时会不会拖垮交付。Cloudflare 为每个模型层级都做了熔断器和故障恢复链，遇到速率限制或服务中断时，会自动切换到同系列的健康替代模型。
更重要的是，他们保留了人工兜底。只要真人审查者添加 break glass 注释，系统就会强制放行。也就是说，AI 在这里不是裁判，而是高质量过滤器和风险提示器，最终控制权仍在工程流程里。
6. 重新审查和 AGENTS.md 让上下文保持新鲜
CI 里的审查不是一次性的。开发者推新提交后，系统会做增量重新审查，识别已修复、未修复和用户已解决的发现，避免重复打扰。协调器还能读取历史评论和内联 DiffNote 线程，让后续审查接着上次的结论继续。
另一个实用点是 AGENTS.md 审查器。它会提醒团队在测试框架、构建工具、包管理器或 CI/CD 流程变化后更新指引文件，防止 AI 继续按旧规范生成错误建议。
- 已修复的发现：自动省略
- 未修复的发现：继续保留
- 用户已解决：按状态认可
哪种适合你
如果你的团队只有少量仓库、审查规则也比较固定，先从单一 AI 审查或轻量插件开始更合适。但如果你已经面对多仓库、多模型、多平台和严格 CI 门禁，这套做法更值得参考。
真正该学的不是“接一个更强的模型”，而是把审查拆成专项智能体，把配置做成插件，把失败处理和人工兜底提前设计好。这样 AI 才有机会稳定进入代码发布流程。