Simi Studio
文章 标签 分类
Simi Studio

目录

OpenClaw 使用 Copilot CLI 最佳实践

 收录于 AI
   约 5263 字   预计阅读 11 分钟 

OpenClaw 可以通过 ACP Agents 调用外部 coding harness，而 GitHub Copilot CLI 已经从“终端辅助工具”演进成带 plan、delegate、review、autopilot 和 subagent 的 agentic CLI。

把两者接在一起，关键不在于尽可能放大自治权限，而在于先把接入方式、权限边界、会话边界和认证方式分清楚。

先分清两条路线：Provider 和 ACP 不是一回事

这是最容易混淆的地方。

OpenClaw 里和 GitHub Copilot 相关，至少有两种完全不同的接法：

  1. 模型 provider 模式：OpenClaw 自己直接把 GitHub Copilot 当模型提供方使用，走的是 openclaw models auth login-github-copilot 这一套。
  2. ACP harness 模式：OpenClaw 通过 ACP 会话启动外部 Copilot CLI，让 Copilot CLI 自己去读代码、改文件、跑命令。

这篇文章讨论的是第二种，也就是 OpenClaw 通过 ACP 使用 Copilot CLI。

官方文档现在写得很明确：

  • OpenClaw 的 ACP Agents 文档说明，ACP 会话可以运行包括 Copilot 在内的外部 coding harness。
  • acpx 仓库当前列出的内置 harness alias 里，已经包含 copilot，对应的原生命令是 copilot --acp --stdio。

这意味着，OpenClaw 在这里扮演的是会话编排器，Copilot CLI 才是实际干活的 coding agent。

官方基线：先确认 OpenClaw 的 ACP 运行面是通的

稳定使用这套组合时，不建议一上来就在聊天里丢一个大需求。

OpenClaw 官方对 ACP 的建议启动顺序更像这样：

  1. 先确认 ACP 功能已启用。
  2. 先跑一次 /acp doctor。
  3. 再 spawn 一个具体 harness。
  4. 再决定是绑定当前会话，还是单独开 thread。

OpenClaw 文档里给出的典型操作是：

/acp doctor
/acp spawn copilot --bind here

或者：

/acp spawn copilot --mode persistent --thread auto

这里的区别很重要：

  • --bind here：保留当前聊天面，把后续消息都路由到同一个 Copilot ACP 会话。
  • --thread auto：给这次任务单独开线程，更适合中长任务或并行任务。

如果经常在 Telegram、Discord、Slack 之类的渠道里远程跟进任务，--thread auto 更适合作为默认选择，因为它天然更容易把任务隔离开。

先把 Copilot CLI 认证做好，不要混用 OpenClaw 的 provider 登录流

这也是一个高频误区。

如果走的是 ACP harness 路径，那么真正需要登录的是 Copilot CLI 自己，不是 OpenClaw 的 GitHub Copilot provider。

GitHub 官方最新命令参考里提到，Copilot CLI 支持两类常见认证方式：

  • 直接执行 copilot login
  • 通过环境变量提供 token，优先级是 COPILOT_GITHUB_TOKEN、GH_TOKEN、GITHUB_TOKEN

官方还特别说明：

  • 支持 fine-grained PAT（需要 Copilot Requests 权限）
  • 支持 Copilot CLI app 的 OAuth token
  • 支持 gh app 的 OAuth token
  • 不支持经典 ghp_ PAT

如果 OpenClaw 部署场景带有远程、后台、非交互式特征，环境变量方式通常比手动 device flow 更稳。

这一点和 OpenClaw 自己的 provider 文档要分开看：OpenClaw 的 login-github-copilot 文档当前仍然强调 device-login flow，而且社区已经有人在 issue 里提到，这会让完全自动化的 headless setup 变得比较别扭。
但 ACP 模式下实际调用的是 Copilot CLI，本质上应该按 Copilot CLI 的认证模型来准备宿主机。

最重要的实践：把 OpenClaw 当编排层，把 Copilot CLI 当执行层

真正好用的组合方式，不是让 OpenClaw 和 Copilot CLI同时“都很聪明”，而是让它们职责清晰。

一个更稳的职责分层是：

  • OpenClaw：负责聊天入口、线程绑定、会话持久化、远程跟进、背景任务编排
  • Copilot CLI：负责仓库探索、计划、编码、测试、review、提交建议

更准确的心智模型是：OpenClaw 是远程调度面板，Copilot CLI 是本地工程执行器。

这时，最有效的提示词策略也会更清楚：不要只说“帮我改一下”，而要把任务直接写成 Copilot CLI 官方推荐的那种可执行任务。

例如：

先阅读当前仓库里和支付重试相关的文件，不要立即修改代码。
然后给出一个最小实现计划，说明会改哪些文件、不会改哪些文件、
需要跑哪些测试。等确认后再开始实现。

这个写法本质上就是把 GitHub 官方的 explore → plan → code → verify 工作流，借由 OpenClaw 的聊天面转发给 Copilot CLI。

复杂任务默认先 Plan，不要让 OpenClaw 直接把大需求推给 Copilot CLI

GitHub 官方现在把 /plan 明确列为 Copilot CLI 的核心工作模式之一，而且在最佳实践文档里直接推荐 explore → plan → code → commit 流程。

这套流程放到 OpenClaw 里尤其重要，因为任务经常来自手机、IM 或远程线程。操作者不在终端前时，任务边界一旦没说清，返工成本会更高。

推荐默认流程：

  1. 在 OpenClaw 里 spawn 一个 Copilot CLI 会话。
  2. 第一条消息只让它读代码并解释现状。
  3. 第二条消息要求它生成 plan。
  4. 确认边界后，再让它实现。
  5. 最后要求它跑测试、总结 diff、列出风险。

如果任务是中大规模改动，可以直接在消息里要求：

先进入 plan 模式，不要写代码。
先解释当前实现，再给出最小变更方案和验证命令。

这样做的价值，不只是减少错误修改，还能显著降低远程跟进时的上下文噪音。

Rubber Duck：把 second opinion 放在高价值审查点

GitHub 官方文档把 Rubber Duck 定义为 Copilot CLI 内置的 critic agent：主 agent 可以把当前 plan、design、implementation 或 tests 交给 Rubber Duck 审查，由它发现盲点、设计问题和实质性风险，再把具体反馈交回主 agent。

GitHub 在 2026 年 4 月 6 日发布的官方 blog 里进一步解释了它的底层思路：Rubber Duck 提供的是跨模型家族的 “second opinion”。也就是说，主会话模型和审查模型刻意不同，用来减少单一模型在 plan、复杂实现或测试阶段的自我确认偏差。

随后 GitHub 又在 2026 年 5 月 7 日的 changelog 里补充说明：

  • Claude 会话可以配 GPT-5.5 作为 Rubber Duck reviewer
  • GPT 会话也可以反过来拿 Claude reviewer
  • 开启方式仍然是 /experimental on

Rubber Duck 的边界也要说清楚：它不是另一个会直接改文件的 coding agent，而是审查 proposed changes 的 critic。主 agent 仍然决定是否采纳反馈、如何继续执行。

在 OpenClaw + Copilot CLI 场景下，Rubber Duck 适合放在这些时机使用：

  1. plan 刚生成之后，让它先挑设计漏洞
  2. 涉及 3 个以上文件的改动之后，让它挑跨文件冲突
  3. 写完测试之后，让它补测试盲区
  4. 高风险任务在提交前，再做一次 second opinion

如果只把 Copilot CLI 当“代码生成器”，Rubber Duck 的价值有限；但如果把它当长任务 coding agent，Rubber Duck 就应该进入默认审查流程。

Infinite sessions 有价值，但会话仍然要聚焦

GitHub 官方文档提到 Copilot CLI 具备 “infinite sessions”，会自动做上下文压缩；但官方同一页也强调，长会话不等于应该把所有任务塞进一个会话。

官方给出的建议很明确：

  • 无关任务之间使用 /clear 或 /new
  • 保持单个 session 聚焦
  • 把它当成“和同事开一条新的工作线程”

这在 OpenClaw 场景下更应该照做。

更稳的会话策略是：

  • 一个 repo / 一个 feature / 一个 bug，尽量一条 ACP 线程
  • 不要把“修 CI”“写文档”“重构核心模块”混在同一个绑定会话里
  • 用 --thread auto 给明显独立的任务分线程
  • 需要延续上下文时再继续复用原来的绑定 session

换句话说，Copilot CLI 的 session 虽然可以很长，但 OpenClaw 侧的聊天线程设计仍然应该刻意做窄。

权限策略不要图省事：默认保守，隔离环境里再放开

权限策略最容易被“图快”带偏。

OpenClaw ACP 文档当前写得非常直白：

  • permissionMode 控制 harness 能否自动执行写文件和 shell 命令
  • 默认是 approve-reads
  • 默认 nonInteractivePermissions=fail

官方还专门提醒：在非交互式 ACP 会话里，如果写操作或执行操作触发 permission prompt，可能直接报 AcpRuntimeError: Permission prompt unavailable in non-interactive mode。

这意味着两件事：

  1. 如果需要 Copilot CLI 真正自动改代码、跑测试、装依赖，就必须认真设计权限模式。
  2. 如果不打算给高权限，就应该把 nonInteractivePermissions 调整成更可预期的降级策略，避免任务在非交互 prompt 上直接中断。

更稳的做法通常是：

  • 日常宿主机：保守权限，只读优先
  • 隔离工作区 / 临时仓库 / 沙箱机：再考虑更高自治
  • 公开或多人共享入口：不要给写权限和 shell 权限

社区里最近关于 Copilot CLI 的讨论也非常一致：如果要开 --yolo 或接近全自动的权限模型，最好放进隔离环境里，比如 disposable container、Docker Sandbox 或专门的开发机，而不是直接在主力工作机上裸跑。

成本和额度约束下，最稳的是“双层模型分工”

长期使用 OpenClaw 时，很快会碰到一个现实问题：Copilot CLI 不适合承担所有日常对话。

原因很简单：

  • 它有额度和 premium request 成本约束。GitHub 官方文档当前说明，Copilot CLI 默认模型下每个 prompt 消耗 1 个 premium request，其他模型会按 multiplier 计费
  • 它的强项是编码执行，不是低成本日常闲聊
  • 把所有普通聊天都压到 Copilot，会浪费最贵的那层能力

还要注意一个时间点：GitHub 的 Copilot plans 和 usage 文档都提示，2026 年 6 月 1 日起 Copilot 会从 request-based billing 迁移到 usage-based billing。因此这里的原则不应绑定某个固定额度数字，而应该绑定更稳定的策略：把高成本编码 agent 放在高价值编码节点使用。

OpenClaw 官方 multi-agent 文档强调，一个 agent 是完整的 per-persona scope，拥有各自的 workspace、auth profile、model registry 和 session store。换句话说，OpenClaw 适合把“日常交互”和“编码执行”拆成不同 agent 或不同会话。

更稳的生产方案是：

  1. 日常交互 agent：默认模型设成性价比更高的常用模型，比如 MiniMax、Qwen、DeepSeek，或者通过 OpenRouter 走 openrouter/auto
  2. 编码执行 agent：只在需要改代码时，才通过 ACP spawn copilot
  3. 高风险总结点：让 Copilot CLI 在 plan、实现、review 这些关键节点上出手，而不是参与全部对话

也就是说：

  • OpenClaw 里的主对话模型负责需求澄清、任务拆解、总结、追踪
  • Copilot CLI 只负责仓库级探索、计划、编码、测试、review

这套组合的好处有四个：

  1. 更省额度：Copilot 只用在最值得的编码环节
  2. 更低延迟：普通聊天由便宜模型承担，响应更快
  3. 更好隔离：编码权限只在专用 ACP 会话里出现
  4. 更稳上下文：日常聊天和代码执行不会混成一锅

一个实用工作流如下：

模式 A：便宜模型常驻，Copilot 按需出场

  1. 先和 OpenClaw 的日常 agent 讨论需求
  2. 让日常 agent 把任务整理成结构化执行说明
  3. 当需要真正改代码时，再 spawn copilot
  4. Copilot CLI 完成 plan、实现、测试、review
  5. 结果再回到日常 agent，由它总结、记录、继续跟踪

模式 B：便宜模型做 PM，Copilot 做 coder

如果 OpenClaw 已经按 agent 拆角色，可以进一步固定成：

  • chat agent：便宜模型，负责对话与调度
  • code agent：专门绑定仓库和 Copilot CLI harness

这种方式最适合长期远程使用，因为它把“说话的脑”和“写代码的手”拆开了。

一句话总结：不要让 Copilot CLI 成为 OpenClaw 的默认大脑；让它成为 OpenClaw 的专职编码器。

让 Copilot CLI 负责 review，不要因为有 OpenClaw 就省略验收

OpenClaw 接入 Copilot CLI 之后，一个很常见的误判是：“反正已经有 OpenClaw 帮忙转发和管理会话了，只看最终结果就行。”

这通常不够。

GitHub 官方自己就在 Copilot CLI 里提供了 /review、/plan、/pr 等能力，社区用户也反复提到，/diff、/review 这类动作应该成为日常习惯，而不是可选项。

所以更稳的流程应该是：

  1. OpenClaw 接收任务并绑定到 Copilot CLI 会话。
  2. Copilot CLI 完成实现。
  3. 再要求它总结改动文件、输出风险点、运行测试，并做一轮 review。
  4. 最后再做人类验收。

把 OpenClaw 看成“远程入口”，而不是“质量保证层”，心智会更准确。

--bind here 和 --thread auto 怎么选

这个选择会直接影响后续使用体验。

适合 --bind here 的场景

  • 需要在当前聊天里持续和 Copilot CLI 来回迭代
  • 当前任务比较短
  • 不希望产生额外 thread
  • 当前会话本身就已经是一个干净的任务面

更适合 --thread auto 的场景

  • 任务会持续很久
  • 需要远程挂起，过一段时间再回来继续
  • 可能同时开多个改动流
  • 需要把“需求讨论”和“执行线程”分开

如果没有特别理由，--thread auto 更适合作为 OpenClaw 的默认值，因为它更接近 issue / PR / task 的工作方式。

一个足够稳的实际 runbook

如果只是想先跑通一套能长期复用的流程，可以从下面这套开始。

1. 宿主机准备

先在运行 Copilot CLI 的那台机器上完成：

copilot login
copilot

确认 Copilot CLI 本身能独立工作，再接入 OpenClaw。

2. OpenClaw 侧做健康检查

/acp doctor

如果这里没过，不要继续折腾 prompt。

3. 为具体任务创建会话

短任务：

/acp spawn copilot --bind here

中长任务：

/acp spawn copilot --mode persistent --thread auto

4. 第一条消息只做探索和计划

先阅读相关文件并解释当前实现，不要修改代码。
然后给出最小实现计划、影响范围和验证命令。

5. 第二条消息再授权实现

按刚才确认的计划实现。
改完后运行相关测试，给出 diff 摘要、风险和后续建议。

6. 结束时主动收口

完成后，要求它：

  • 列出改动文件
  • 列出未验证项
  • 做一轮自检或 /review
  • 必要时关闭 ACP 会话或保留线程等待下一轮

这套流程不花哨，但稳定。

常见坑

1. 把 OpenClaw provider 和 Copilot CLI harness 混为一谈

前者是 OpenClaw 自己接模型；后者是 OpenClaw 调外部 CLI。认证、权限、故障点都不一样。

2. 在非交互会话里保留了会触发 prompt 的权限策略

结果就是任务看起来启动了，但一遇到写文件或 exec 就直接失败。

3. 以为 infinite sessions 等于“不需要拆线程”

实际上长上下文只是能力，不是建议。独立任务仍然应该拆开。

4. 先开高权限，再补安全

这基本是最容易把本机环境搞脏的路径。正确顺序应该反过来。

5. 让它直接写，不让它先 plan

在 IM 或远程聊天面里，这个错误的代价比本地终端里更大。

相关阅读

一页结论

最重要的结论如下：

  1. 先分清使用的是 OpenClaw provider 还是 OpenClaw ACP + Copilot CLI。
  2. OpenClaw 负责会话编排，Copilot CLI 负责工程执行。
  3. 复杂任务默认先 explore 再 plan，再实现。
  4. Rubber Duck 很适合放在 plan、复杂实现和测试之后做 second opinion。
  5. infinite sessions 有价值，但任务线程仍然要聚焦。
  6. 非交互 ACP 会话里的权限策略必须单独设计。
  7. 成本敏感场景下，便宜模型负责日常交互，Copilot 只负责编码工作。
  8. 高自治只适合隔离环境，不适合默认跑在主力宿主机上。
  9. 最后一定要让 Copilot CLI 自己做测试和 review，再做人类验收。

参考链接

更新于 2026-05-14
 OpenClaw, GitHub Copilot, Copilot CLI, ACP, AI Agent
返回 | 主页