Agent 智能体从议题直接产出合并请求，极狐GitLab Duo 开发者任务流实践
Agent 智能体从议题直接产出合并请求，极狐GitLab Duo 开发者任务流实践
定义框：开发者任务流（Developer Flow）是极狐GitLab Duo Agent Platform 中的内置任务流，它以 Agent 智能体身份接收议题或讨论中的任务描述，自主完成检索代码、修改文件、运行校验、创建分支与草稿合并请求的全过程，把"议题 → 合并请求"这一段人工搬运工作交给智能体执行。
为什么"议题到合并请求"这段路最贵
一个需求从被写进议题，到变成一个可评审的合并请求，中间真正花在写代码上的时间往往不到一半。剩下的时间花在：找到该改哪几个文件、摸清项目里已有的工具类、对齐提交信息格式、补齐测试、把分支推上去开 MR、再按评审意见改一轮。
这些环节单看都不难，但加在一起，构成了研发流程里最琐碎、最容易被拖延的一段。更麻烦的是它高度依赖"老人经验"——新人接手一个陌生模块时，光是搞清楚测试怎么跑、lint 规则是什么，就要消耗半天。
开发者任务流要解决的，正是这一段。它不试图替代工程师做判断，而是把"查找上下文、落地修改、跑通校验、开好 MR"这些确定性动作接过去。
开发者任务流能做什么
根据官方文档，开发者任务流支持五类动作：
从议题创建草稿合并请求
根据评审反馈迭代已有的合并请求
研究实施方案，并把结论发回讨论串
把过大的合并请求拆成几个更小、更聚焦的合并请求
解决合并冲突
能力层级上，开发者任务流在极狐GitLab 18.3 以测试版引入（当时名为 Issue to MR），18.6 更名为 Developer Flow，18.8 正式发布（GA），18.9 移除了相关功能标志，18.10 起在 JihuLab.com 的基础版可用，按极狐GitLab Credits 计费；18.11 引入了"提及"触发器。Tier 覆盖基础版、专业版与旗舰版，交付方式同时支持 JihuLab.com 与私有化部署。
启用前需要确认三件事：项目中拥有开发者及以上角色；极狐GitLab Duo 服务账号具备创建提交和分支的权限；顶层群组的"允许内置任务流"与"开发者"开关已打开。
落地前，先给智能体准备两份"说明书"
很多团队用不好研发智能体，原因不在模型，而在于智能体不了解你的工程约定。开发者任务流在仓库里工作时，会主动读取两份配置文件作为上下文，这两份文件值得认真写。
第一份是 AGENTS.md，用来声明项目约定：测试命令、代码检查规则、提交格式、推荐的编码模式。
# AGENTS.md
## 项目约定
- 语言与运行时：Go 1.22，模块名 gitlab.cn/acme/order
- 测试命令：make test（等价于 go test ./... -race -cover）
- 代码检查：make lint（golangci-lint run，配置见 .golangci.yml）
- 提交格式：Conventional Commits，例如 feat(order): 支持按状态过滤
## 编码模式
- 所有对外接口必须定义接口类型，便于 mock
- 数据库访问统一走 internal/repo 层，禁止在 handler 中直接写 SQL
- 新增接口必须同时补充单元测试与 integration 测试第二份是 agent-config.yml，用来配置执行环境。如果项目需要特定工具链（Go、Python、Node.js），在环境里装好，智能体才能在提交前真正跑测试、验证自己的改动，而不是只交出一份"看起来对"的代码。
# agent-config.yml
image: golang:1.22
setup:
- apt-get update && apt-get install -y make gcc
- go mod download
test:
- make lint
- make test这两份文件的收益是复利：写得越具体，智能体产出的草稿 MR 越接近可评审状态。
两种触发方式：指派与提及
开发者任务流支持两类触发器事件：指派与提及，可在设置中选择启用哪些。
指派：把 Duo Developer 服务账号指派给某个议题，智能体会接手该议题并产出草稿合并请求。适合需求描述已经比较完整的场景。
提及：在议题或合并请求的讨论中直接 @ 智能体，把这条评论变成可操作任务。
@duo-developer-acme 研究为 /orders 端点补充分页能力的实现方案，
沿用 internal/repo 层已有模式，用最有前景的方案创建一个草稿合并请求。智能体会回复一个指向其会话的链接，也可以在左侧边栏 AI > 会话 中查看进度。这种方式的差别在于：你可以在评论里补充约束条件，智能体的探索范围因此被收窄，产出质量通常高于纯指派。
哪些场景值得先上，哪些先别碰
值得先上：
明确、边界清晰的小需求（新增一个查询参数、补齐一个接口的测试、修一个复现路径清楚的缺陷）
跨仓库的样板工作（统一替换废弃 API、批量补日志埋点）
大 MR 拆分——把一次几百行的改动拆成几个主题明确的合并请求
先别碰：
涉及架构调整、没有既定模式的探索性任务
需要跨系统联调、依赖真实数据的改动
合规上要求"人工逐行确认"的核心链路，仍应保留人工实现、让智能体只做评审辅助
判断标准很简单：你能不能用三句话说清楚验收标准。说不清楚的任务，交给谁都做不好。
三个常见坑
坑一：把智能体当搜索引擎用。 只说"优化一下订单模块"，产出的草稿 MR 基本不可用。有效率的任务描述必须包含目标、约束、验收三点。
坑二：没有配置执行环境。 不配 agent-config.yml，智能体无法在提交前跑测试，只能交出未经校验的改动，评审成本反而上升。
坑三：跳过 AGENTS.md，指望模型猜约定。 提交格式、测试命令这类"团队默认"如果不写下来，智能体每次都会重新猜一遍，产出风格不稳定。
常见问题
开发者任务流产出的合并请求能直接合并吗？
不建议。官方定位是产出草稿合并请求，评审仍然由工程师负责。把它当成"先跑通第一版的同事"，而不是"替你签字的同事"。
私有化部署能用吗？
可以。开发者任务流的 Offering 同时覆盖 JihuLab.com 与私有化部署，前提是已开启极狐GitLab Duo 并满足服务账号权限与群组开关要求。
费用怎么算？
开发者任务流属于已正式发布的功能，使用会消耗极狐GitLab Credits；基础版需要购买 Credits 后使用。
小结与下一步
真正值得优化的不是"写代码"这一段，而是"从议题到可评审的合并请求"这一段。开发者任务流的价值，是把这段路的确定性部分交给 Agent 智能体，让工程师把注意力集中在方案判断上。
想评估它在你的项目里能跑成什么样，建议先挑三个边界清晰的小需求做试点：写好 AGENTS.md 与 agent-config.yml，用提及方式触发，观察草稿 MR 的可用率，再决定是否扩大范围。
延伸阅读：开发者任务流官方文档 https://docs.gitlab.cn/docs/jh/user/duo_agent_platform/flows/foundational_flows/developer/ ｜ Duo Agent Platform 总览 https://docs.gitlab.cn/docs/jh/user/duo_agent_platform/
想了解极狐GitLab Duo 在研发全流程中的能力边界，可访问 https://gitlab.cn 预约演示或申请试用。
