“失败后自动拉起修复 Agent”的闭环流水线

可以把它设计成“失败后自动拉起修复 Agent”的闭环流水线。核心思路是门禁失败不是直接结束而是把错误日志、代码上下文、测试命令交给机器上的修复工具让它在受控环境里改代码、跑验证、提交 commit然后再次触发流水线直到通过或达到上限。推荐方案否是否且未超上限通过超过上限门禁流水线执行是否失败合入/通过收集日志、失败命令、环境信息拉起自动修复 Agent分析失败原因并修改代码本地执行测试/构建/静态检查是否通过提交 commit / 推送分支重新触发门禁停止并通知人工介入落地步骤在 Linux 机器上预置工具代码工具git、gh或 GitLab/Jenkins CLI。构建工具项目需要的maven、gradle、npm、pnpm、go、python、cargo等。检查工具pytest、eslint、ruff、mypy、go test、make test等。自动修复工具例如内部代码修复 Agent、Codex CLI、脚本化 LLM Agent或基于规则的 fix 工具。失败后收集上下文必须把这些信息传给修复工具失败日志。失败命令。当前分支、commit SHA。变更文件列表。项目测试命令。CI 环境变量、系统版本、依赖版本。让 Agent 在隔离 workspace 中修复不建议直接在主工作区改。每次修复应使用临时目录或干净分支gitcheckout-Bauto-fix/$BUILD_ID# 调用自动修复工具codex根据 ci.log 修复当前仓库代码运行测试直到通过本地验证通过后再提交Agent 修改代码后流水线执行固定验证命令maketestmakelintmakebuild通过后提交gitconfig user.nameci-fix-botgitconfig user.emailci-fix-botexample.comgitadd.gitcommit-mfix: repair gate pipeline failuregitpush origin auto-fix/$BUILD_ID支持迭代但要设置上限建议最多迭代 3 到 5 次MAX_RETRY5foriin$(seq1$MAX_RETRY);dorun_auto_fix run_testsbreakdone如果超过次数仍失败应自动创建 issue 或评论 PR附上失败日志和 Agent 的尝试摘要。可能问题与解决办法问题风险解决办法Agent 误改代码引入新 bug限制只改失败相关文件必须跑完整测试死循环修复浪费机器资源设置最大迭代次数、超时和 diff 大小限制环境不一致本地通过、CI 失败修复 Agent 使用和门禁一致的 Docker 镜像权限过大可能泄露密钥或破坏仓库使用最小权限 token只允许推送 bot 分支依赖下载失败修复误判区分代码失败、网络失败、缓存失败测试不稳定Agent 反复改错地方失败重跑一次标记 flaky testCommit 污染历史自动提交太多统一使用auto-fix/*分支人工确认后 squash安全问题Agent 可能修改敏感配置禁止修改密钥、部署脚本、权限文件或要求人工 review比较合理的策略不要让自动修复直接合入主干。更稳妥的是门禁失败。自动修复 Agent 新建auto-fix/xxx分支。修复并验证。自动提交 commit。创建 PR 或更新原 PR。门禁重新跑。通过后由人工或规则系统合入。这样既能自动迭代修复又不会让机器在没有审查的情况下直接改主干。对于企业门禁流水线这是安全性和效率比较平衡的做法。