OpenClaw 结合 Claude Code：三种联动方式，别再靠玄学选了

你想要的效果大概率是这个：

• 在 OpenClaw（龙虾）里聊需求、拆任务、拉资料 ✅
• Claude Code（CC）负责写代码、改代码、跑一堆小修小补 ✅
• 过程别动不动断上下文、别动不动掉线 ✅

问题来了：到底怎么接？

这篇把三种主流接法讲透：谁是主战场、上下文怎么处理、稳定性如何、适合什么活。

你要先想清楚的 3 个问题

别急着上配置，先回答三句人话：

• 谁是主战场？ 你主要在哪边“指挥作战”，龙虾还是 CC？
• 上下文要不要持久？ 你做的是“一次性小改动”，还是“连续几天的大工程”？
• 你能容忍多少不稳定？ Discord/中间层/网络波动，能不能接受偶尔抽风？

这三个答案，基本就把方案选出来了。

方案 A：在 OpenClaw 里直接调用 CC 的 CLI

一句话：龙虾是主控，CC 是一次性工具人。

适合什么场景

• 你在龙虾里带着它干活：写个脚本、补个函数、生成一段配置
• 每次任务相对独立：做完就结束
• 你更在乎“简单能跑”，不想折腾一堆中间件

典型场景：

• 你下班前 20 分钟要把一个 bug hotfix 掉
• 你只想让 CC 帮你生成一段正则、一个 SQL、一个小工具函数

优点

• 最省事：龙虾里一句命令就把 CC 拉起来
• 依赖少：不强依赖 Discord 状态，也不太需要额外服务

缺点（关键点）

• 每次都是新实例：上下文不持久
• 复杂任务会很痛：你得不断重复背景、约束、代码结构

怎么落地（示例）

思路很朴素：龙虾里封装一个命令，直接调用 claude/cc 的 CLI。

示例（伪代码/思路）：

• 龙虾接收你的指令
• 拼装 prompt
• subprocess 调用 CC CLI
• 把输出回填到对话

你要追求稳定，建议加两件事：

• 把代码仓库路径固定（别让 CC 在错误目录里胡来）
• 把输出落盘（日志、diff、patch 文件），不然出错很难追

避坑清单

• ❌ 指令里别塞太多背景：一次性上下文容易爆
• ❌ 别让 CC 直接 git push：在龙虾侧做一层“确认再执行”更安全
• ✅ 把“项目规则”写成固定模板，每次调用都带上（比如 lint、目录结构、提交规范）

方案 B：在 OpenClaw 里通过 ACP 调用 CC（带持久上下文）

一句话：龙虾仍是主控，但你想要“能记住事”的 CC。

适合什么场景

• 你做的是中大型任务：改架构、重构、连续多轮迭代
• 你想把龙虾的规划能力 + CC 的编码能力揉在一起
• 你愿意为“上下文持久”付出一点配置成本

典型场景：

• 你要做一个持续 3 天的功能：接口、前端、测试都要改
• 你希望 CC 记住“这个项目的坑”和“你讨厌的写法”

优点

• 持久上下文：对连续任务太香了
• 理论上能把龙虾的多 agent 调度优势用起来

缺点（你大概率会遇到的）

• ACP + Discord 容易出幺蛾子：消息乱序、丢消息、回调失败、连接不稳定
• 一旦不稳，体验会很崩：你刚让它改第 7 个文件，它说“我没看到前面内容” 😅

怎么落地（更务实的建议）

想提高成功率，别一上来就追求“全自动”。建议这样拆：

• 让 ACP 只负责上下文与任务状态
• 让实际执行尽量可重放：每一步都有可复现的输入（文件、diff、任务单）
• 关键节点落盘：任务计划、变更清单、当前分支、已完成项

你可以把流程设计成：

• 龙虾生成“任务单”（要改哪些文件、每个文件改什么、验收点）
• ACP 持久存“任务单 + 进度”
• CC 每轮只做任务单中的一小块，做完就产出 diff

这样 Discord 抽风时，最坏情况也只是“少了一轮对话”，不会“项目失忆”。

避坑清单

• ❌ 别把“唯一真相”放在 Discord 消息里：消息丢了就全完
• ✅ 让每轮输出都可验证：diff、测试结果、lint 结果
• ✅ 给每轮任务加编号：TASK-01、TASK-02，对齐进度用

方案 C：Claude Code 用 webhook 让 OpenClaw 做代码 review

一句话：CC 是主控写代码，龙虾负责在 Discord 上当“审稿人”。

这个方案的核心体验是：你在 CC 里深度带它写代码；写完它把 diff/代码片段通过 webhook 发到 Discord；龙虾在 Discord 里做 review、提修改意见、挑刺。

适合什么场景

• 你写代码时更依赖 CC 的工作流（编辑器/终端/仓库操作）
• 你希望 review 有“第二视角”，而且要稳定
• 你不强求所有 agent 都在一个体系里联动

典型场景：

• 你在 CC 里做一套完整重构，然后让龙虾在群里给你挑问题
• 你带团队协作：CC 产出 patch，Discord 里大家围观 review

优点

• 稳定性通常更好：webhook 发消息，比复杂的双向状态同步更省心
• 职责清晰：CC 写代码，龙虾做审查

缺点

• 体系割裂：CC 和龙虾的 agent 不在同一条“任务链”里
• 如果你想要“龙虾调度多个 agent 一起写代码”，这条路不太像你要的

怎么落地（示例流程）

你可以把 webhook 设计成两类事件：

• review_request：CC 发起审查（带 diff、关键文件、风险点）
• review_result：龙虾回审查意见（可选：带建议 patch 或 TODO 列表）

建议 CC 发出去的内容固定格式，龙虾更好读：

[Review Request]
Repo: xxx
Branch: feature/abc
Scope:
- file1: 做了什么
- file2: 做了什么
Diff: （贴 diff 或链接）
Concerns:
- 性能？
- 兼容性？
- 安全？

龙虾回的时候也固定格式：

[Review Result]
High Risk:
- ...
Must Fix:
- ...
Nice To Have:
- ...
Test Suggestions:
- ...

避坑清单

• ❌ diff 太长直接贴满频道：建议改成链接或分段摘要
• ✅ 让 CC 在发起 review 前跑完测试/格式化，不然 review 变成“帮你擦地板”
• ✅ webhook 加签名/鉴权，别让外面的人随便往频道灌消息

三种方案怎么选：按“主战场 + 上下文 + 稳定性”拍板

给你一个不绕弯的选择表：

| 你更在乎什么 | 更像哪种方案 | |---|---| | 配置最少、能跑就行 | A（龙虾里直调 CC CLI） | | 连续大任务、需要 CC 记住上下文 | B（龙虾 + ACP + CC） | | 写代码体验优先、Discord 做审查、要稳定 | C（CC webhook → 龙虾 review） |

再给一个“人话决策树”：

• 任务会拖很多轮，还要持续迭代？选 B
• 你主要在 CC 里写，想要一个稳定的审查出口？选 C
• 你只是想在龙虾里随手用 CC 做点小活？选 A

我自己的实用建议（不端着）

• 日常小修小补，A 就够了。简单到离谱。
• 真要做大工程，B 很诱人，现实里要花时间“治稳定性”。你能接受折腾就上。
• 想要稳定、团队可协作、流程清晰，C 往往是性价比最高的。CC 写代码的节奏不被打断，龙虾 review 也更像一个靠谱同事。

你可以直接照抄的组合拳

不少人最后会落在一个混合方案：

• 主流程用 C：CC 写代码 → webhook 叫龙虾 review（稳定）
• 零碎用 A：龙虾里偶尔拉起 CC 做一次性生成（省事）
• B 留作“实验项目”：把 ACP 的稳定性打磨好，再逐步迁移

想把“翻车概率”压低，这套组合拳挺香。

如果你愿意说一句：你们现在的工作流更偏“在 Discord 聊需求再写代码”，还是“在本地/IDE 里写为主”？我可以按你的习惯把推荐方案和落地步骤再收敛成一套更贴合的流程。😄