OpenClaw + Claude Code 怎么配合？一套基于 ACP 的长期协作实践

Claude Code 写代码很强。 但一旦你想让同一个任务隔天继续、换设备继续、在聊天线程里继续，问题就不再是“它会不会写”，而是：这条协作链怎么才能不断。

你在本地仓库里让 Claude Code 改了半天，换到手机就断了；想把同一个任务接进 Telegram/Discord 线程里继续，也容易掉上下文；再往前走一步，想把“谁来接任务、谁来续跑、在哪个话题里接着聊”稳定下来，单靠一个 CLI 很快就会开始吃力。

这也是 OpenClaw 值得看的地方： 它不是来替代 Claude Code 的，而是来补上“长期协作”这一层。

先说我的判断：

Claude Code 解决的是“在 repo 里怎么更快”，OpenClaw 解决的是“这套协作怎么别散、还能续上”。

如果再压缩成一句更适合圈内转发的话，就是：

Claude Code 把代码往前推，OpenClaw 把这条协作链条接起来。

别先问谁更强，先问你卡在执行层还是协作层

很多人一上来就问：OpenClaw 和 Claude Code 到底谁更强？

这个问题问错了。

Claude Code 本质上是一个很强的执行器。你可以把它理解成一个很能干的“写码搭子”：读代码、改文件、跑命令、修测试、快速迭代，这些它都很擅长。

OpenClaw 更像一个协作调度层。它关心的不是某一次补丁改得快不快，而是这次协作怎么接任务、怎么续上、怎么跨设备、怎么接进别的工具和聊天入口里。

所以别把它们放在同一个维度硬比。

更实用的理解是：Claude Code 解决“在 repo 里怎么快”，OpenClaw 解决“这套协作怎么活得久”。

这也是这篇文章最想说明的一点： 你不是要在两个工具里二选一，而是要先想清楚，自己现在缺的到底是“更强的写码能力”，还是“更顺手的协作方式”。

图 1：把这两个工具放在同一层比较，很容易聊乱；更实用的理解是，OpenClaw 负责编排层，Claude Code 负责执行层。

真正的分水岭，不是模型强弱，而是你开始不满足于“一次对话”了

这几年大家已经很习惯“让一个 AI 去开终端，然后盯着终端输出继续干活”。

这条路不是不能用，但一旦你想做多轮对话、任务恢复、排队执行、半路取消，或者把同一个任务接进聊天线程里继续，单纯靠抓终端输出就会越来越别扭。

acpx 这轮更新为什么值得看，不是因为它让 Claude Code 更聪明了，而是因为它把长期协作真正需要的那套能力补出来了：会话能保存、任务能排队、半路能取消、断了还能接着来、状态也更容易看清。

OpenClaw 官方文档现在也已经讲得很直白：像 Claude Code、Codex、Gemini CLI 这类外部编码工具，更适合走 ACP 这种会话式接入方式，而不是继续当成普通子任务去调用。

这背后的差别，可以用一张表看清：

说人话就是： 前者更像“临时借一台终端用一下”，后者更像“正式接入一个可以长期协作的写码助手”。

如果你只是本地单次写码，前者够用。 但如果你要隔天继续、换设备继续、或者把同一个任务放进不同聊天线程里继续，后者会顺手很多。

真正在用的人，最后大多会落到这 3 种配合方式里

A. OpenClaw 做总控，Claude Code 做执行器

这是我觉得最像“长期方案”的模式。

做法是：OpenClaw 负责接收任务、记住上下文、决定接下来该往哪走，再把具体的编码工作交给 Claude Code。

适合这几类场景：

• 你不只在本地终端里工作，还会从手机、群聊、远程机器继续同一条任务
• 你希望任务能挂在线程/话题里，不靠人肉记住“刚才做到哪了”
• 你还要接别的工具，比如浏览器、消息、定时、文件、节点能力

最小闭环可以先这样验证：

/acp spawn claude --mode persistent --thread off
/acp status

如果你走工具调用路径，本质上也是同一件事：

{
  "task": "Read the repo and list the next three fixes.",
  "runtime": "acp",
  "agentId": "claude",
  "thread": true,
  "mode": "session"
}

这套模式最大的优点，是它真的能把一条任务接住。

缺点也很明确：一旦你把 thread binding、权限策略、渠道适配一起叠上去，排障复杂度会明显上来。

B. direct acpx + Claude Code

如果你现在最关心的是：先把 Claude Code 这条长链路跑顺，我反而建议先走这条。

它更像“电话转接”模式：你不先上 OpenClaw 的整套编排，只先用 acpx 直接驱动 Claude Code。

比如：

acpx claude sessions new --name demo
acpx claude -s demo "Read this repo and explain the current architecture."
acpx claude status

这条线的价值很现实：

• 先验证 Claude Code 这套接法能不能稳定工作
• 先验证会话保存、任务排队、取消、恢复这些能力
• 出问题时，排查范围更小，不会把 OpenClaw 那一层也一起卷进去

如果你最终想做的是长期协作，我很建议先把这一层跑通。

因为很多人真正踩的坑，不是“AI 不会写代码”，而是协作栈一次上太满，最后连自己坏在哪一层都说不清。

C. OpenClaw 作为上下文 / 路由层

还有一种很实用的用法，不一定每次都要让 OpenClaw 全程控盘。

你可以把它当成“前台”和“路由器”：先让 OpenClaw 接用户需求、整理上下文、判断任务该不该下发给 Claude Code；真正进入 repo 深水区时，再切给 Claude Code 去执行。

这对下面两类人很舒服：

• 你平时既做写作/研究/消息处理，也偶尔切到编码任务
• 你希望入口统一，但不想所有任务都走最重的编排链路

这时候 OpenClaw 不一定是最重的控制面，但它依然是很有价值的上下文层。

图 2：真正落地时，大多数人最后都会回到这 3 种模式里：全编排、轻编排，或者只把 OpenClaw 当上下文/路由层。

一个很容易把人绕晕的点：setup-token 和 ACP runtime 不是一回事

这一点如果不提前讲清，后面基本必混。

setup-token 是登录认证这条线。

它来自 claude setup-token，作用是让 OpenClaw 能用 Anthropic 这边的模型。它解决的是“你拿什么身份去连模型”。

而“通过 ACP 驱动 Claude Code”是任务运行这条线。

它解决的是“Claude Code 这个外部写码工具怎么接进来、怎么继续对话、怎么继续跑同一个任务”。

两者关系大概是这样：

最常见的误区是： “我已经有 Claude Code 了，所以 OpenClaw 驱动它应该天然通。”

不一定。

你可能拿到了 Anthropic 认证，但还没有把 Claude Code 以 ACP harness 的方式接进编排链路；也可能 ACP 跑通了，但 provider 认证配置还是另一回事。

把这两条线分开，排障会轻松很多。

图 3：一个是“怎么连上模型”，一个是“怎么把 Claude Code 接进任务链路里继续跑”。这两个问题经常被混在一起。

真正决定这套体验能不能“用久”的，是线程 / 话题绑定这层

如果你真的想把这套协作带进日常使用，thread/topic binding（简单理解就是“把一个聊天线程固定连到同一个任务会话上”）基本绕不过去。

因为一旦没有绑定，后续消息到底该续在哪个任务上，就很容易靠人脑硬记。今天在一个群话题里继续，明天在手机上追一句，最怕的不是 Claude Code 不会干活，而是这条任务已经不知道该接到哪里了。

OpenClaw 这套设计里，thread binding 的价值就在这里：

• 某个线程/话题，绑定到某个 ACP 会话
• 后续消息继续路由到同一个执行器
• 输出也稳定回到同一条线程里

这对 Discord 线程、Telegram topics 很有价值，也正是当前支持最明确的地方。

但它也是坑点最集中的地方。

原因很简单：这层不是单靠本地命令就能搞定的，它同时牵涉到聊天平台本身、消息怎么路由、会话什么时候失效这几件事。

常见坑基本就这几类：

• 当前渠道是否真的支持 thread/topic binding
• 会话是不是在 idle/max-age 后被自动解绑了
• 你以为自己在续同一个 session，实际上已经新开了一条
• 同一个线程的 owner / rebinding 规则没想清楚
• Feishu 这类能力还在演进中，别过早假设它已经和 Discord/Telegram 一样成熟

如果只记一个判断，可以记这一句： thread binding 是最值钱的一层，也是最不该第一天就硬上的一层。

真想把它用成日常能力，别一上来就全配满

如果你真想落地，我建议按这个顺序来，而不是一口气全配满。

第一步：先验证 Claude Code / acpx

目标只有一个： 确认 Claude Code 这套接法能稳定跑，而且会话保存、状态查看、取消、恢复这些基础能力都没问题。

第二步：再验证 OpenClaw ACP runtime

目标是确认 OpenClaw 已经能把 Claude Code 这类外部写码工具接对方式，而不是走错到另一套任务机制里。

这一步只需要先验证“能调用、能续上、能看状态”，不要急着上线程绑定。

第三步：最后再上 thread / topic binding

只在前两层稳定之后，再去验证 Discord / Telegram 的线程或话题绑定。

如果你的目标平台里还包括 Feishu，那更要把它放后面。 当前更成熟的重点支持面仍然是 Discord / Telegram，Feishu 相关能力还在演进，这恰恰说明它是高价值层，但也说明你得为坑位留预算。

图 4：更稳的方式不是一上来把所有能力配满，而是先跑通 Claude Code + acpx，再接 OpenClaw ACP，最后再叠加 thread/topic binding。

最后给一个最实用的判断：什么时候单飞，什么时候上编排层

这个判断其实没必要神秘化。

如果只给一个最短判断：

只追求 repo 内最快闭环，用 Claude Code；开始关心“同一条任务怎么被长期接住”，就该让 OpenClaw 上场。

图 5：如果你主要是在本地仓库里短平快改代码，Claude Code 就够了；一旦开始跨设备、多轮任务、聊天入口协作，OpenClaw 的价值就会明显上来。

如果你准备这周就上手，先按这份 checklist 来

如果你准备真的把这套东西跑起来，建议按这个顺序做：

• [ ] 先单独跑通 Claude Code + acpx，会话、状态、取消、恢复都测过
• [ ] 确认自己理解 setup-token 是认证线，不是运行时编排线
• [ ] 在 OpenClaw 里明确走 ACP runtime，而不是把外部 harness 当 subagent
• [ ] 先验证无 thread binding 的 ACP 会话，再叠线程/话题绑定
• [ ] 优先在 Discord / Telegram 验证 thread/topic binding
• [ ] 把 idle / max-age / rebinding 规则先想清楚，再给团队或群聊使用
• [ ] 保留一条“降级路径”：出问题时能退回 direct acpx + Claude Code

图 6：真正让人卡住的，通常不是模型能力本身，而是接法混乱、顺序不对，或者把还没跑顺的能力一次全叠上去。

这套组合真正有意思的地方，不是又多了一个 agent 工具。

而是它开始把 AI 编码，从“一次会话里的助手”往“可持续协作的系统部件”推进了一步。

这也是我现在对它最核心的判断： Claude Code 负责把活干快，OpenClaw 负责让这套协作别散。

如果这篇对你有用，建议点个关注。我会持续把 GitHub 上值得用的 AI 工具拆成「最短上手闭环 + 坑点清单 + 可复用配置」，让你少走弯路。

关注微信公众号

想第一时间看到后续的工具拆解与实战更新，欢迎扫码关注公众号。