代码审查是软件交付流程中最难规模化的一环。随着仓库体积增长、合并请求涉及的文件数量变多人工审查很容易陷入看不过来的困境 reviewer 要么只扫一眼就通过留下隐患要么被大量重复性问题拖住关键变更反而没时间细看。更棘手的是不同 reviewer 对编码标准、安全规范、性能陷阱的理解并不一致导致同一段代码在不同 MR 里得到完全不同的反馈。极狐GitLab Duo 的代码审查流程Code Review Flow试图用 Agent 智能体把这个问题收敛起来。它不是给出一个笼统的代码质量评分而是在合并请求内部执行基于代码上下文的审查留下具体、可操作的评论同时通过mr-review-instructions.yaml让团队把自有编码规范注入 Agent 的审查标准实现AI 初筛 人类把关的协作模式。01 Code Review FlowAgent 版本的代码审查在极狐GitLab Duo 的能力矩阵里代码审查有两个实现一个是面向 GitLab Duo Enterprise 附加组件用户的非 Agentic 版本另一个是本文要介绍的Code Review Flow它属于 GitLab Duo Agent Platform 的内置任务流之一。官方文档明确区分了这两者Code Review Flow 会启动一个会话Agent 会分析代码变更、理解仓库结构与跨文件依赖再给出详细的审查评论。根据官方信息该流程在极狐GitLab 18.7 中作为测试版引入功能标志为duo_code_review_on_agent_platform18.8 正式发布并移除功能标志18.10 起JihuLab.com 基础版用户可以通过极狐GitLab Credits 使用。私有化部署实例同样支持前提是完成极狐GitLab Duo 自部署模型的配置。Code Review Flow 的输入不再是简单的 diff 文本而是包括代码变更本身MR 中新增、删除、修改的文件及其内容。仓库结构与跨文件依赖Agent 会尝试理解变更文件在仓库中的位置、与其他模块的引用关系。项目自定义审查指令通过.gitlab/duo/mr-review-instructions.yaml注入的团队规范。用户与 Agent 的交互历史在 MR 讨论线程中回复或 GitLabDuo 可以追问替代方案。这种设计让它区别于传统的静态规则扫描工具它不是机械地检查是否违反了某条规则而是在更宏观的代码上下文里判断这段变更是否合理。02 如何触发一次 Agent 审查触发 Code Review Flow 的方式非常简单本质上就是把 GitLabDuo 分配为合并请求的审查者。具体操作有两种在合并请求页面的 Reviewers 区域将 GitLabDuo 添加为审查者。在 MR 评注中使用快速操作/assign_reviewer GitLabDuo。请求提交后极狐GitLab 会启动一个 Agent 会话用户可以在AI 会话中查看审查进度。会话完成后MR 讨论区会出现 Agent 留下的审查评论包括对具体代码行的逐条反馈。除了主动请求审查团队还可以开启自动审查。开启后每当创建新的合并请求时Agent 会自动对其进行一次初始审查前提是MR 不是草稿状态Draft/WIP。MR 至少包含一个文件变更。项目开启了自动审查开关或所属群组/应用级设置了自动审查。自动审查的配置入口位于设置 合并请求 极狐GitLab Duo 代码审查需要项目维护者及以上角色才能开启。群组级自动审查则需要群组所有者或管理员权限设置会从应用级联到群组再到项目更具体的设置会覆盖更宽泛的设置。03 审查评论不是打分而是可操作的反馈Agent 输出的不是代码质量 85 分这种难以落地的结论而是类似人类 reviewer 的逐条评论指出某一行或某一段代码的问题、说明原因、给出修改建议。这些评论会出现在 MR 的讨论线程中开发者可以逐条回复、追问或标记为已解决。特别有价值的是对跨文件依赖的识别。在大型仓库中一个文件的修改往往会触发其他文件中调用方、接口实现、测试用例的变化。人工 reviewer 如果对模块边界不够熟悉很容易遗漏这些隐性影响。Agent 会尝试把变更放在仓库结构里理解并在发现潜在依赖风险时给出提示。如果开发者对某条评论有不同意见可以直接在该评论的线程中回复或者在任意讨论线程中 GitLabDuo 提出后续问题。这种交互不会直接影响其他合并请求的审查结果——官方文档明确说明当前反馈还不会跨 MR 传递但已经有一个功能请求在跟踪这个方向。04 用 mr-review-instructions.yaml 把团队规范写进 Agent再智能的 Agent 也不了解你的团队内部约定某个项目为什么坚持用某种错误处理模式、哪些 API 是禁止直接调用的、测试覆盖率最低要求是多少。这些规则如果不明确告诉 Agent审查结果就会偏通用化。极狐GitLab Duo 的解决方案是.gitlab/duo/mr-review-instructions.yaml文件。它用 glob 模式匹配文件并为不同文件类型定义审查指令让 Agent 在标准审查之外追加项目特定的检查点。配置方式在仓库根目录创建.gitlab/duo/目录然后新建mr-review-instructions.yaml。文件格式如下instructions: - name: Go Service Layer fileFilters: - **/*.go - !**/*_test.go instructions: | 1. 检查是否显式处理 error避免裸返回。 2. 禁止在业务层直接调用外部 HTTP 客户端统一通过 internal/client 包。 3. 复杂逻辑必须添加注释说明设计意图。 - name: Python Data Processing fileFilters: - etl/**/*.py - !etl/tests/**/* instructions: | 1. Pandas DataFrame 操作必须校验空值与类型。 2. 避免硬编码数据库连接字符串统一从环境变量读取。 3. 日志使用项目统一日志格式禁止直接 print。关键规则fileFilters是必填项使用 glob 语法。一个文件可以匹配多个指令组Agent 会合并应用。由自定义指令触发的评论会带有前缀根据 instruction_name 中的自定义指令[反馈评论]。标准极狐GitLab Duo 评论不使用这个前缀。Code Review Flow 不会引用AGENTS.md和SKILL.md文件。最佳实践官方文档对编写自定义审查指令给出了几条建议具体且可执行避免写出好代码这种空泛要求改为所有公共函数必须包含 docstrings。对指令进行编号便于开发者和 Agent 都按条阅读。优先关注最重要的标准不要一次性塞入几十条规则先从最容易出问题的 3–5 条开始。解释为什么在指令中说明背后的工程理由Agent 更容易在评论中传递正确意图。为了让自定义指令文件本身也受到审查建议通过 CODEOWNERS 文件为其指定负责人[极狐GitLab Duo] .gitlab/duo default-owner tech-lead05 常见报错DCR4000 系列排查速查表Code Review Flow 在实际使用过程中可能会返回一系列以 DCR 开头的错误代码。官方文档给出了从 DCR4000 到 DCR5000 的完整解释这里把最常见、最容易踩到的几条汇总如下错误码含义常见原因与处理DCR4000代码审查流程未开启顶级群组管理员没有开启允许基础流和代码审查。DCR4001服务账号未就绪服务账号仍在创建中等待几分钟后重试或联系管理员验证账号状态。DCR4002Credits 已用完当前计费周期内极狐GitLab Credits 耗尽需购买或等待下一个周期重置。DCR4003无流水线创建权限用户在该项目中没有创建 CI/CD 流水线的权限需管理员调整角色。DCR4004未设置默认 Duo 命名空间在个人偏好设置里设置默认的极狐GitLab Duo 命名空间。DCR4005认证令牌获取失败通常是私有化部署的极狐GitLab Duo 配置不正确或瞬时网络问题。DCR4006服务账号无法加入项目群组成员锁定启用或服务账号缺少项目访问权限。DCR4007项目不可用或流程被禁用验证流程已在项目/群组开启且必要配置已就位。DCR4008无法创建 CI/CD 流水线Runner 不可用或内部配置问题建议重试或联系管理员。DCR4009无法获取源分支临时性问题通常重新请求审查即可解决。DCR5000Agent Platform 内部错误等待后重试若持续出现需联系管理员排查。如果以上错误码都无法解释问题官方文档还提供了一个配置诊断脚本可以检查 Code Review Flow 所需的完整配置链包括所有 GitLab Duo Agent Platform 功能的前置条件。06 权限、版本与计费Code Review Flow 的版本可用性需要关注JihuLab.com基础版从 18.10 起可通过 Credits 使用专业版与旗舰版原生支持。私有化部署专业版与旗舰版可用需要配置极狐GitLab Duo 自部署模型。角色要求请求审查的用户至少需要项目开发者角色开启自动审查需要维护者及以上。计费方面Code Review Flow 消耗极狐GitLab Credits。自动审查每次创建 MR 时都会触发一次审查并消耗 Credits因此团队需要在覆盖全面性和Credits 消耗之间做权衡。草稿状态的 MR 不会触发自动审查这是天然的节流阀。07 落地建议不要指望 Agent 替代 reviewerAgent 审查再强大也只是把明显问题提前拦截。它不能替代人类对业务语义、架构权衡、用户体验的判断。比较稳妥的落地方式是Agent 做初筛在 MR 创建后立即运行 Code Review Flow把低级错误、规范违规、跨文件依赖风险先抛出来。人类做最终把关把 Agent 的评论当作 reviewer 的 checklist 补充关键 MR 仍需人类维护者批准。持续优化指令每周或每月回顾 Agent 的评论质量根据误报和漏报调整mr-review-instructions.yaml。结合流水线门禁把 Agent 审查、CI/CD 检查、代码所有者CODEOWNERS等机制串起来形成多层质量网。写在最后代码审查的瓶颈从来不是有没有人愿意看而是人能不能在有限时间里看全面。极狐GitLab Duo 的 Code Review Flow 给出了一个新思路让 Agent 智能体承担重复、可模式化的审查劳动把人类 reviewer 的注意力释放到真正需要判断力和经验的地方。它不是要取代 reviewer而是要成为 reviewer 的第一道滤网。通过GitLabDuo触发审查、通过mr-review-instructions.yaml注入团队规范、通过讨论线程持续追问团队可以在不增加人力的前提下让每一次代码审查都更一致、更深入、更可追溯。最终代码质量的责任仍在人身上但有了 Agent 当审查员人类可以把精力放在那些只有人类才能做出的决定上。
让 Agent 智能体当审查员：极狐GitLab Duo 代码审查实战
代码审查是软件交付流程中最难规模化的一环。随着仓库体积增长、合并请求涉及的文件数量变多人工审查很容易陷入看不过来的困境 reviewer 要么只扫一眼就通过留下隐患要么被大量重复性问题拖住关键变更反而没时间细看。更棘手的是不同 reviewer 对编码标准、安全规范、性能陷阱的理解并不一致导致同一段代码在不同 MR 里得到完全不同的反馈。极狐GitLab Duo 的代码审查流程Code Review Flow试图用 Agent 智能体把这个问题收敛起来。它不是给出一个笼统的代码质量评分而是在合并请求内部执行基于代码上下文的审查留下具体、可操作的评论同时通过mr-review-instructions.yaml让团队把自有编码规范注入 Agent 的审查标准实现AI 初筛 人类把关的协作模式。01 Code Review FlowAgent 版本的代码审查在极狐GitLab Duo 的能力矩阵里代码审查有两个实现一个是面向 GitLab Duo Enterprise 附加组件用户的非 Agentic 版本另一个是本文要介绍的Code Review Flow它属于 GitLab Duo Agent Platform 的内置任务流之一。官方文档明确区分了这两者Code Review Flow 会启动一个会话Agent 会分析代码变更、理解仓库结构与跨文件依赖再给出详细的审查评论。根据官方信息该流程在极狐GitLab 18.7 中作为测试版引入功能标志为duo_code_review_on_agent_platform18.8 正式发布并移除功能标志18.10 起JihuLab.com 基础版用户可以通过极狐GitLab Credits 使用。私有化部署实例同样支持前提是完成极狐GitLab Duo 自部署模型的配置。Code Review Flow 的输入不再是简单的 diff 文本而是包括代码变更本身MR 中新增、删除、修改的文件及其内容。仓库结构与跨文件依赖Agent 会尝试理解变更文件在仓库中的位置、与其他模块的引用关系。项目自定义审查指令通过.gitlab/duo/mr-review-instructions.yaml注入的团队规范。用户与 Agent 的交互历史在 MR 讨论线程中回复或 GitLabDuo 可以追问替代方案。这种设计让它区别于传统的静态规则扫描工具它不是机械地检查是否违反了某条规则而是在更宏观的代码上下文里判断这段变更是否合理。02 如何触发一次 Agent 审查触发 Code Review Flow 的方式非常简单本质上就是把 GitLabDuo 分配为合并请求的审查者。具体操作有两种在合并请求页面的 Reviewers 区域将 GitLabDuo 添加为审查者。在 MR 评注中使用快速操作/assign_reviewer GitLabDuo。请求提交后极狐GitLab 会启动一个 Agent 会话用户可以在AI 会话中查看审查进度。会话完成后MR 讨论区会出现 Agent 留下的审查评论包括对具体代码行的逐条反馈。除了主动请求审查团队还可以开启自动审查。开启后每当创建新的合并请求时Agent 会自动对其进行一次初始审查前提是MR 不是草稿状态Draft/WIP。MR 至少包含一个文件变更。项目开启了自动审查开关或所属群组/应用级设置了自动审查。自动审查的配置入口位于设置 合并请求 极狐GitLab Duo 代码审查需要项目维护者及以上角色才能开启。群组级自动审查则需要群组所有者或管理员权限设置会从应用级联到群组再到项目更具体的设置会覆盖更宽泛的设置。03 审查评论不是打分而是可操作的反馈Agent 输出的不是代码质量 85 分这种难以落地的结论而是类似人类 reviewer 的逐条评论指出某一行或某一段代码的问题、说明原因、给出修改建议。这些评论会出现在 MR 的讨论线程中开发者可以逐条回复、追问或标记为已解决。特别有价值的是对跨文件依赖的识别。在大型仓库中一个文件的修改往往会触发其他文件中调用方、接口实现、测试用例的变化。人工 reviewer 如果对模块边界不够熟悉很容易遗漏这些隐性影响。Agent 会尝试把变更放在仓库结构里理解并在发现潜在依赖风险时给出提示。如果开发者对某条评论有不同意见可以直接在该评论的线程中回复或者在任意讨论线程中 GitLabDuo 提出后续问题。这种交互不会直接影响其他合并请求的审查结果——官方文档明确说明当前反馈还不会跨 MR 传递但已经有一个功能请求在跟踪这个方向。04 用 mr-review-instructions.yaml 把团队规范写进 Agent再智能的 Agent 也不了解你的团队内部约定某个项目为什么坚持用某种错误处理模式、哪些 API 是禁止直接调用的、测试覆盖率最低要求是多少。这些规则如果不明确告诉 Agent审查结果就会偏通用化。极狐GitLab Duo 的解决方案是.gitlab/duo/mr-review-instructions.yaml文件。它用 glob 模式匹配文件并为不同文件类型定义审查指令让 Agent 在标准审查之外追加项目特定的检查点。配置方式在仓库根目录创建.gitlab/duo/目录然后新建mr-review-instructions.yaml。文件格式如下instructions: - name: Go Service Layer fileFilters: - **/*.go - !**/*_test.go instructions: | 1. 检查是否显式处理 error避免裸返回。 2. 禁止在业务层直接调用外部 HTTP 客户端统一通过 internal/client 包。 3. 复杂逻辑必须添加注释说明设计意图。 - name: Python Data Processing fileFilters: - etl/**/*.py - !etl/tests/**/* instructions: | 1. Pandas DataFrame 操作必须校验空值与类型。 2. 避免硬编码数据库连接字符串统一从环境变量读取。 3. 日志使用项目统一日志格式禁止直接 print。关键规则fileFilters是必填项使用 glob 语法。一个文件可以匹配多个指令组Agent 会合并应用。由自定义指令触发的评论会带有前缀根据 instruction_name 中的自定义指令[反馈评论]。标准极狐GitLab Duo 评论不使用这个前缀。Code Review Flow 不会引用AGENTS.md和SKILL.md文件。最佳实践官方文档对编写自定义审查指令给出了几条建议具体且可执行避免写出好代码这种空泛要求改为所有公共函数必须包含 docstrings。对指令进行编号便于开发者和 Agent 都按条阅读。优先关注最重要的标准不要一次性塞入几十条规则先从最容易出问题的 3–5 条开始。解释为什么在指令中说明背后的工程理由Agent 更容易在评论中传递正确意图。为了让自定义指令文件本身也受到审查建议通过 CODEOWNERS 文件为其指定负责人[极狐GitLab Duo] .gitlab/duo default-owner tech-lead05 常见报错DCR4000 系列排查速查表Code Review Flow 在实际使用过程中可能会返回一系列以 DCR 开头的错误代码。官方文档给出了从 DCR4000 到 DCR5000 的完整解释这里把最常见、最容易踩到的几条汇总如下错误码含义常见原因与处理DCR4000代码审查流程未开启顶级群组管理员没有开启允许基础流和代码审查。DCR4001服务账号未就绪服务账号仍在创建中等待几分钟后重试或联系管理员验证账号状态。DCR4002Credits 已用完当前计费周期内极狐GitLab Credits 耗尽需购买或等待下一个周期重置。DCR4003无流水线创建权限用户在该项目中没有创建 CI/CD 流水线的权限需管理员调整角色。DCR4004未设置默认 Duo 命名空间在个人偏好设置里设置默认的极狐GitLab Duo 命名空间。DCR4005认证令牌获取失败通常是私有化部署的极狐GitLab Duo 配置不正确或瞬时网络问题。DCR4006服务账号无法加入项目群组成员锁定启用或服务账号缺少项目访问权限。DCR4007项目不可用或流程被禁用验证流程已在项目/群组开启且必要配置已就位。DCR4008无法创建 CI/CD 流水线Runner 不可用或内部配置问题建议重试或联系管理员。DCR4009无法获取源分支临时性问题通常重新请求审查即可解决。DCR5000Agent Platform 内部错误等待后重试若持续出现需联系管理员排查。如果以上错误码都无法解释问题官方文档还提供了一个配置诊断脚本可以检查 Code Review Flow 所需的完整配置链包括所有 GitLab Duo Agent Platform 功能的前置条件。06 权限、版本与计费Code Review Flow 的版本可用性需要关注JihuLab.com基础版从 18.10 起可通过 Credits 使用专业版与旗舰版原生支持。私有化部署专业版与旗舰版可用需要配置极狐GitLab Duo 自部署模型。角色要求请求审查的用户至少需要项目开发者角色开启自动审查需要维护者及以上。计费方面Code Review Flow 消耗极狐GitLab Credits。自动审查每次创建 MR 时都会触发一次审查并消耗 Credits因此团队需要在覆盖全面性和Credits 消耗之间做权衡。草稿状态的 MR 不会触发自动审查这是天然的节流阀。07 落地建议不要指望 Agent 替代 reviewerAgent 审查再强大也只是把明显问题提前拦截。它不能替代人类对业务语义、架构权衡、用户体验的判断。比较稳妥的落地方式是Agent 做初筛在 MR 创建后立即运行 Code Review Flow把低级错误、规范违规、跨文件依赖风险先抛出来。人类做最终把关把 Agent 的评论当作 reviewer 的 checklist 补充关键 MR 仍需人类维护者批准。持续优化指令每周或每月回顾 Agent 的评论质量根据误报和漏报调整mr-review-instructions.yaml。结合流水线门禁把 Agent 审查、CI/CD 检查、代码所有者CODEOWNERS等机制串起来形成多层质量网。写在最后代码审查的瓶颈从来不是有没有人愿意看而是人能不能在有限时间里看全面。极狐GitLab Duo 的 Code Review Flow 给出了一个新思路让 Agent 智能体承担重复、可模式化的审查劳动把人类 reviewer 的注意力释放到真正需要判断力和经验的地方。它不是要取代 reviewer而是要成为 reviewer 的第一道滤网。通过GitLabDuo触发审查、通过mr-review-instructions.yaml注入团队规范、通过讨论线程持续追问团队可以在不增加人力的前提下让每一次代码审查都更一致、更深入、更可追溯。最终代码质量的责任仍在人身上但有了 Agent 当审查员人类可以把精力放在那些只有人类才能做出的决定上。