GitLab 开发代理

解决什么问题

团队把需求、缺陷和合并请求都放在 GitLab 上，但自动化往往停在“读”的层面：机器人能看 issue、能看流水线状态，真正要开分支、写描述、点合并时，要么得人工确认，要么得自己拼一堆 glab、git 命令，还容易漏掉 MR 讨论的后续分页。这个技能把执行侧补全：它以开发者身份运行，把 GitLab 日常操作固化成可重复的流程，配置中已允许它在无确认的情况下执行 clone、push、建 MR 等写操作。

它是如何工作的

核心约束很简单：GitLab 内一切可写操作都走 glab CLI，不借助 Workboard 之类的内部工具，也不维护旁路状态。典型流程分三段：

• 接活：拉取指派给自己的 issue 和 open MR；判断是否为重复 issue 并关联原始单；分析问题后给出 1–3 步具体计划和验收标准，直接写进 MR 描述。
• 动手：git clone 后按 feat/*、fix/* 前缀开分支，提交并创建 MR；MR 必须挂在 work item 所属的 project 下并关联对应 issue；自己认领 assignee，但不在创建时拉 maintainer reviewer。
• 跟流水线：检查 MR 流水线，失败则定位根因修复，成功则等合并；按当前状态切换 workflow 状态标签，如 workflow::in-progress、workflow::review；标签缺失时自行通过 label 组件补建。

几个容易踩的细节：先看项目里已在跑的 pipeline 数量，超过 3 个就跳过当前 MR；查看 MR 讨论必须翻完所有分页，未解决的可 resolve 讨论和 reviewer 的顶层评论都算待办，只看第一页就宣称 discussion-clean 是不行的；流水线全绿且无事可做时，才把 maintainer 加为 reviewer，并记一笔 time tracking。

适用边界与注意点

它面向权限受控的隔离环境：设计上假设写操作可逆、允许出错，同时明确禁止 push 到 protected branch。需要留意：

• 所有外部不可逆动作（clone、push、建 MR）都会自动执行，授权来自 owner 创建代理时授予的权限，不要把它挂到生产项目上。
• 修 bug 要求先找根因再动手，禁止用 allow_failure: true、skip 或 bypass 把 CI 刷绿；确属可选/手动任务时必须写清原因。
• 严禁修改 AGENTS.md；新建 CI/CD 流水线应使用 GitLab CI Tools Components Catalog。
• 命令一律以当前 GitLab 用户身份认证，不在 git 目录时要显式指定 --repo owner/repo 或完整 URL。