Duo CLI 把 Agent 搬进终端，杂活才算真交出去
Duo CLI 把 Agent 搬进终端，杂活才算真交出去
先明确一件事：极狐GitLab Duo CLI 是 Duo 智能体的终端入口，和浏览器里的对话、编辑器里的插件是同一个智能体的三种壳。它有两种模式：交互模式（在终端里对话，支持构建、计划、自动三种权限模式）和无人值守模式（在 Runner、脚本、自动化流程里非交互执行）。Tier 为专业版与旗舰版，JihuLab.com 与私有化部署均可用。
为什么终端这一环绕不过去
过去一年，团队引入 AI 智能体的路径高度一致：先在网页里问几句，再装个编辑器插件，让它补全和改函数。走到这一步，能省的都省了，剩下的却卡住了。
卡住的地方有个共同特征：活儿不在编辑器里。
有人早上第一件事是翻昨天的流水线失败日志，一条条看是哪一步挂的。
有人要把散在几十个仓库的
Dockerfile里的基础镜像版本对齐。有人得把 ESLint 输出、测试报告、依赖告警这些机器生成的文本，翻译成能下手的修复动作。
这些活的输入是命令行输出，产出是文件改动，全程没有人写新功能。它们占了工程师一天里相当可观的碎块时间，却恰恰是网页对话最难承接的部分——你在浏览器里问得再清楚，最后复制粘贴回终端的还是你自己。
终端入口的价值就在这：智能体和你的工具链待在同一个工作目录里，能读文件、跑命令、看 Git 分支状态、查当前项目的合并请求与流水线。它的判断依据不再是你描述的场景，而是它自己看到的东西。
交互模式：三种权限模式顶三种活
启动命令有两种写法，取决于安装方式：
# 通过 glab 安装
glab duo cli
# 独立安装
duo进入后终端出现 > 提示符，按 Enter 提交。要中断正在生成的响应，按 Escape；按 ↑ 回看历史提示，Control+R 搜索历史。
真正决定它能不能干活的是权限模式，用 Tab 键在提示符下切换，当前模式会显示在 > 旁边：
模式 | 权限 | 适合的场景 |
|---|---|---|
构建模式（默认） | 读写，可执行任务并改动项目 | 让它真正落地代码改动 |
计划模式 | 只读，只分析和产出计划 | 摸清一个陌生仓库、评估改动影响面 |
自动模式 | 读写，且使用工具前不请求审批 | 一次性批处理类任务，需先由管理员开启 |
实际用法是把两个模式串起来：先在计划模式里让它读代码、说清楚准备改哪几个文件、为什么这么改；方案认可后按 Tab 切到构建模式，让它执行。这个顺序不是形式主义——只读阶段暴露出来的误判，比改完再回滚便宜得多。
自动模式需要额外的开关，并且默认关闭：实例、群组、项目三级都可以设「默认开启 / 默认关闭 / 始终关闭」，父级设成始终关闭时下级锁定无法开启。它由功能标志控制，需要 Duo CLI 9.22.0 及以上版本。开启方式是按 Tab 直到提示符显示 auto，且不跨会话保持——每个新会话都从构建模式重新开始。
还有一组斜杠命令，值得记住的几个：
/review：调用代码评审子 Agent 审当前改动，不用切到网页/goal：启动一个朝目标推进的会话（需 19.3 及以上）/mcp：查看已配置的 MCP 服务器状态/compact：压缩对话历史，省上下文/skills：列出当前项目可用的 Agent Skills/doctor：环境诊断，出问题时先跑它
/review 是最容易被低估的一个。它把「提交前自查」从一件需要主动想起的事，变成一条随手敲的命令。
无人值守模式：把杂活塞进流水线
交互模式解决的是「你坐在电脑前」的活。无人值守模式解决的是「你不在」的活——它用 run 子命令发起一次性任务，跑完退出：
# glab 安装
glab duo cli run --goal "Fix these lint errors: $eslint_output"
# 独立安装
duo run --goal "把 src/legacy 下的 console.log 全部清掉，其余不动"选模型走 --model 参数或 GITLAB_DUO_MODEL 环境变量，无人值守模式下模型不跨会话保持，每次都得显式给。
接进流水线最自然的用法，是让它处理那些「机器能看懂、人不想看」的失败。例如夜间跑完静态检查，把告警汇总成一个目标描述，交给智能体产出修复分支：
nightly-lint-fix:
stage: fix
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
script:
- npm run lint -- --format json > lint.json || true
- |
duo run --goal "读取 lint.json，修复其中的 error 级问题，只改必要文件，不要动测试快照" \
--model "$GITLAB_DUO_MODEL"
- git checkout -b "chore/lint-fix-$CI_PIPELINE_ID"
- git commit -am "chore: auto fix lint errors"
- git push -o merge_request.create -o merge_request.target=$CI_DEFAULT_BRANCH origin HEAD
artifacts:
when: always
paths: [lint.json]这段配置的关键不在 YAML 本身，而在两个约束：一是只处理 error 级，把 warning 挡在外面，否则改动面会失控；二是必须走合并请求，不要让它直推默认分支——无人值守模式会绕过所有工具审批，自动批准每次工具调用，且不保留上一轮的上下文。官方对它的措辞是「请谨慎使用，并在受控的沙盒环境中使用」，这句话应当原样抄进团队规范。
四个容易踩的坑
一、把它当成长期驻留的服务。 无人值守模式每次 run 都是全新工作流，没有上一轮的对话记忆。指望它「记住昨天怎么修的」，只会得到一次次的重新摸索。要沉淀经验，靠的是项目内的 AGENTS.md 一类说明文件和自定义斜杠命令，不是靠对话历史。
二、自动模式忘了关。 自动模式不跨会话保持，每个新会话都回到构建模式——这既是保护也是陷阱：有人在长会话里开了一次自动模式，之后二十轮都以为还在受审批约束。状态栏和提示符旁的 auto 字样要养成扫一眼的习惯。
三、忘了它能看到的比你描述的多。 状态栏会显示当前工作目录、Git 分支、识别到的项目、当前分支的开放合并请求及流水线状态。这意味着提示词不必再复述背景，但也意味着工作目录搞错，它就会照着错误的分支和项目干活。多仓库环境里，先 cd 到正确目录再启动。
四、把图片上下文当默认能力。 图片读取由功能标志控制，需 9.27.0 及以上、且必须使用极狐GitLab 托管的模型，自托管模型不支持；格式限 PNG/JPEG/WebP，单张不超过 10 MB，宽高均不超过 8000 像素。提示里也不能直接上传图片，只能指定仓库内路径（如 docs/architecture.png）或议题附件引用（如 /uploads//screenshot.png）。
常见问题
Q：Duo CLI 和编辑器插件是两套能力吗？
不是。它们是同一个智能体的不同入口，权限模式、斜杠命令、MCP 配置、Agent Skills 的思路一致。差别在运行位置：终端入口和你的构建脚本、Git 命令、Runner 处在同一环境里，能直接读到命令输出。
Q：无人值守模式会不会在没人看着的时候改坏东西？
有这个可能，所以要设边界：只在可信仓库、可丢弃分支上跑；产出必须经合并请求评审；敏感凭据不要放在该设备的 shell 环境里。工具治理里设为「始终拒绝」的工具，即使在自动模式下也会被拦住。
Q：私有化部署能用吗？
可以。Duo CLI 的 Offering 包含私有化部署，Tier 为专业版与旗舰版。自动模式、图片上下文这类由功能标志控制的能力，需按实例版本与管理员配置确认可用性。
下一步：想看交互模式与无人值守模式的完整命令清单，可查阅官方文档中心的 Duo CLI 章节；如果你的团队正在把 AI 智能体往流水线里塞，建议先从「夜间静态检查自动修复」这类低风险场景试水，跑顺了再往上游扩。
