GitLab Duo 修复 CI/CD 流水线：让 Agent 自动诊断与修失败作业
GitLab Duo 修复 CI/CD 流水线：让 Agent 自动诊断与修失败作业
CI/CD 流水线的失败是每个研发团队都绕不开的日常。一个拼写错误的 script 关键字、一条遗漏的依赖声明、一次镜像拉取超时，都可能让整条流水线卡在红色状态。更麻烦的是，排查过程往往意味着在数百行甚至数千行日志里翻找错误片段，反复切换浏览器标签页对比 .gitlab-ci.yml 的修改历史，最后手动创建一个修复分支再提合并请求。
极狐GitLab Duo 的修复 CI/CD 流水线流程（Fix CI/CD Pipeline Flow）把这套繁琐的手动排查，交给了 Agent 智能体来自动完成。它不是在流水线失败后简单地告诉你"某一步错了"，而是主动读取日志、定位根因、生成修复补丁，并以合并请求的形式提交候选方案。开发者只需要 review、确认或调整，就能把修复合并进主干。
01 这不是一个通知机器人，而是一个会动手修的 Agent
很多团队已经习惯了流水线失败时收到一条飞书或邮件通知，附带一个指向失败作业的链接。这类通知的价值止于"告知"，后续的排查和修复仍然完全依赖人工。
修复 CI/CD 流水线流程的区别在于，它不只是读取日志然后给出一段文字分析。Agent 会：
解析失败日志和错误信息：从作业输出中提取异常堆栈、退出代码和关键报错。
识别配置与语法问题：检查
.gitlab-ci.yml的语法结构、阶段定义、依赖关系是否合理。根据失败类型建议具体修复：不是泛泛地说"检查配置"，而是给出可落地的 YAML 修改或脚本调整。
创建包含修复的合并请求：把改动打包成 MR，开发者可以直接在代码评审流程中处理。
根据官方文档，该流程目前可以自动修复的流水线问题类型包括：
语法和配置错误：例如 YAML 缩进错误、未定义的阶段、缺少必要关键字。
常见作业失败：例如命令不存在、权限不足、环境变量缺失导致的脚本退出码非零。
依赖关系和工作流问题：例如
needs指向了不存在的作业、阶段顺序导致任务无法按预期触发。
这意味着，过去需要工程师花上几十分钟甚至数小时才能定位并修复的问题，现在 Agent 可以在几分钟内给出候选方案。
02 启用之前：先确认这几项前提
修复 CI/CD 流水线流程并非开箱即用，需要满足一组明确的前提条件。团队在启用前应逐一核对，否则 Agent 可能无法正常运行或无法创建修复 MR。
权限与角色
使用该流程的用户必须在项目中拥有开发者、维护者或所有者角色。如果权限不足，界面上不会显示"使用 Duo 修复流水线"按钮。
流水线状态
该流程只针对已失败的流水线生效。正在运行或已成功完成的流水线不会触发修复逻辑。这一点设计得很合理——Agent 的输入之一就是失败作业的日志和输出，没有失败就没有需要修复的对象。
功能开关
在极狐GitLab 18.4 中，修复 CI/CD 流水线流程作为实验功能引入，带有两个功能标志：duo_workflow_in_ci（默认启用）和 ai_duo_agent_fix_pipeline_button（默认禁用）。到了 18.5，两个功能标志在 JihuLab.com 和私有化部署上均已默认启用。18.8 版本 GA 后，ai_duo_agent_fix_pipeline_button 标志被移除，duo_workflow_in_ci 在 18.9 中移除。18.10 起，JihuLab.com 上的基础版用户也可以通过极狐GitLab 积分使用该功能。
因此，如果你运行的是 18.8 及以上版本，功能本身已经可用；只需要在顶级群组设置中确认允许内置任务流和修复 CI/CD 流水线两项均已开启。
服务账号权限
Agent 需要以极狐GitLab Duo 服务账号的身份创建分支和提交。如果服务账号缺少写入权限，会话会卡在"已创建"状态而无法推进。管理员需要确保 Duo 服务账号在目标项目或群组中具备创建合并请求的必要权限。
03 两种使用场景：MR 内修复与独立流水线修复
根据流水线失败是否与合并请求关联，修复流程提供了两个入口。
场景一：合并请求中的流水线失败
这是最常见的场景。开发者在 MR 中提交了代码变更，触发的 CI/CD 流水线失败了。此时修复流程的操作路径如下：
打开对应的合并请求。
在概览选项卡的失败流水线下方，点击使用 Duo 修复流水线；或者切换到流水线选项卡，在最右侧列中点击同一按钮。
在顶部导航栏的 AI > 会话 中监控 Agent 的推理进度。
会话完成后，MR 评论区会出现一条新评论，内含指向修复 MR 的链接，或者描述后续需要人工处理的步骤。
这个流程把"失败 → 排查 → 修复 → 评审"的闭环压缩在了合并请求的工作界面内，开发者不需要跳转到其他页面或工具。
场景二：未关联合并请求的流水线失败
有些流水线失败并不发生在 MR 上下文中，例如定时触发的 nightly build、手动运行的流水线，或者因外部依赖变更导致的既有分支构建失败。这类流水线同样可以交给 Agent 修复：
进入构建 > 流水线，找到失败的流水线记录。
在流水线详情页右上角，点击使用 Duo 修复流水线。
同样在 AI > 会话 中查看进度，等待评论区的结果反馈。
两种场景的核心逻辑是一致的：Agent 读取失败日志和仓库上下文，推理出修复方案，打包成 MR 或给出明确的人工后续指引。
04 Agent 到底在分析什么
理解 Agent 的输入范围，有助于开发者判断哪些问题它能自动修复，哪些仍需要人工介入。
根据官方文档，修复 CI/CD 流水线流程会检查以下四类信息：
流水线日志：包括错误信息、失败作业的完整输出和退出代码。这是 Agent 判断"哪里坏了"的首要依据。
合并请求更改：如果失败发生在 MR 流水线中，Agent 会对比变更内容，识别是否由新引入的代码、配置修改或依赖升级导致的失败。
当前仓库内容：用于识别语法错误、代码检查工具报错、导入路径问题等。例如，
.gitlab-ci.yml中引用了一个不存在的模板文件，Agent 可以通过扫描仓库目录发现这一问题。脚本错误：包括命令失败、缺少可执行文件、权限不足等运行时问题。
这四类信息的组合，让 Agent 既有"静态分析"的能力（检查配置和代码结构），也有"动态分析"的能力（理解日志和运行时行为）。
05 日志截断的现实限制与应对
需要特别提醒的是，修复 CI/CD 流水线流程存在一个与日志处理相关的已知限制：AI 网关仅处理作业日志的最后 150 KiB。
如果你的作业输出非常冗长——例如开启了详细模式（verbose）的构建工具、打印了大量进度条或调试信息的测试套件——那么真正导致失败的关键错误信息可能远在 150 KiB 截断点之前，Agent 就无法捕获到它。
官方文档给出了几条务实的规避建议：
减少冗余输出：关闭构建工具的进度指示器和调试日志，只保留关键步骤的输出。
重定向非关键输出：在脚本中使用 shell 重定向（
> /dev/null）把无关信息隐藏掉。添加摘要步骤：在脚本末尾或
after_script中回显关键错误信息，确保最重要的诊断内容落在日志尾部。拆分冗长作业：把一个大而全的作业拆成多个更小、更专注的作业，每个作业的日志量自然下降，Agent 也更容易定位问题。
这个限制本质上是成本与效果之间的权衡。150 KiB 对于大多数标准 CI/CD 作业已经足够，但对于日志量极大的场景，团队需要有意识地优化输出策略。
06 人类复核：Agent 是助手，不是责任人
尽管 Agent 可以自动生成修复方案并提交 MR，但官方文档明确没有把它包装成"全自动无人值守"的解决方案。Agent 的输出需要经过人类评审，原因很直接：
AI 可能遗漏上下文：Agent 基于日志和代码做推理，但它不了解业务背景。例如，一个测试失败可能是因为环境配置变更，而非代码本身有问题，Agent 可能会给出"修复测试代码"的建议，而正确的做法其实是调整环境。
修复方案可能过度或不足：Agent 倾向于给出最直接让流水线变绿的修改，但"让流水线通过"和"正确解决问题"并不总是等价的。为了绕过失败，Agent 可能提议跳过某些检查，而人工评审需要判断这是否合理。
安全与合规要求：涉及权限变更、密钥引用、镜像源替换等敏感修改，必须由人审核。
因此，最佳实践是把修复 CI/CD 流水线流程纳入已有的代码评审流程：Agent 生成的修复 MR 与开发者自己写的 MR 走同样的评审门禁，由至少一名维护者批准后才能合并。
07 与持续依赖扫描等自愈能力的联动思路
修复 CI/CD 流水线流程解决的是"已发生的问题"，而极狐GitLab 平台上还有一类能力专注于"预防问题"和"持续监测"，例如持续依赖扫描（Continuous Dependency Scanning）。两者结合，可以形成更完整的安全与质量闭环：
事前：持续依赖扫描在新 CVE 披露时自动重扫，提前捕获依赖漏洞，避免问题代码进入主干。
事后：如果漏洞还是导致了构建或测试失败，修复 CI/CD 流水线流程可以快速生成升级依赖或调整配置的候选方案。
人工复核：两端都由人类做最终把关，确保自动化的速度与人工判断的质量并存。
这种"预防 + 修复 + 复核"的三层结构，比单纯依赖任何单一工具都更稳健。
写在最后
CI/CD 流水线的失败排查从来不是一件让人愉快的事。它打断开发节奏、消耗工程师的注意力，而且很多时候修复本身只是一行配置的微调，真正耗时的是定位那一行配置的过程。
极狐GitLab Duo 修复 CI/CD 流水线流程的价值，正在于把定位过程自动化。Agent 读取日志、比对变更、扫描配置、提交修复，把工程师从重复的排查劳动中解放出来，让他们把精力集中在更有价值的评审和决策上。
但自动化不等于放任。日志截断限制提醒我们优化输出策略，人类复核机制确保修复方案的质量与安全性。只有把 Agent 当作一个高效的助手，而不是替代者，才能真正从这项技术中获益。
让 Agent 去翻日志、找根因、提补丁。工程师的角色，是确保这些补丁真正值得被合并。
