说实话，作为一个独立开发者，Zui爽的时刻不是代码跑通的那一瞬间，而是当你正躺在沙发上刷剧，手机突然震了一下弹窗告诉你“PRYi发起，请验收”。那一刻，你会觉得自己仿佛拥有了一支隐形的顶尖开发团队，在背后默默为你搬砖。

但这不仅仅是幻想。Zui近，我折腾了一整天踩了无数个坑，终于打通了一条堪称完美的自动化链路：在飞书里提需求 → OpenClaw 自动拆解任务 → Claude Code 持续执行 → 完成后发起 PR 通知验收。中间完全不需要人工介入，这才是真正的“托管开发”，而不是那种挤牙膏式的一轮一轮对话。

理想架构：当技术PM遇上顶级工程师

在深入技术细节之前，我们先得把角色定位搞清楚。为什么非要折腾这一套？因为单一的工具总是有缺陷的。

我把 OpenClaw 定义为“技术 PM”。它负责理解需求、拆解任务、调度执行、整合结果。它拥有强大的 LLM Neng力，Neng跟人进行自然语言沟通，也Neng调用各种工具。它的强项在于逻辑规划和资源调度。

而 Claude Code 则是“执行工程师”。它专业、高效，专门为 coding 设计。它有geng完善的工具链，写代码的手感geng好。Zui重要的是它有成熟的项目上下文持续集成优化机制，以项目维度划分工作区，对项目的技术架构、业务逻辑的理解Neng持续积累。长期迭代时它Neng记住之前的决策和改动，不会每次dou从零开始。

所以我的目标hen明确：用 OpenClaw 当大脑，用 Claude Code 当双手。

艰难的开端：ACP 协议的那些坑

一开始，我天真地以为官方推荐的 OpenClaw ACP方式就Neng搞定。毕竟文档里写得明明白白，用 sessions_spawn 加上 resumeSessionId 参数就Neng复用会话。

但我配了半天发现每次dou是新会话。这简直让人抓狂。

我甚至尝试去修改配置文件，试图开启各种开关：

{
  "tools": {
    "sessions": { "visibility": "all" },
    "agentToAgent": { "enabled": true, "allow":  }
  }
}

然后重启网关：

openclaw gateway restart

结果呢？我卡在这里整整一天。 Zui烦的是hen多配置问题 OpenClaw 自己也排查不到，问它吧，它还可Neng一本正经地胡说八道——工具调用的输入输出有点黑盒，kan不到真实证据。后来我学聪明了每改一次配置就让 OpenClaw 提供调用工具的真实日志，这才慢慢摸清楚问题在哪。

resumeSessionId 的陷阱

后来仔细研究才发现，resumeSessionId 实际上是 OpenClaw ACP 会话的 ID，根本不是 Claude Code 的 session ID。复用 OpenClaw 的会话 ID 维持不了同一个 Claude 会话。这个参数在当前场景下有点鸡肋，可Neng在特定的 thread 和 mode=session 下才有用，但在我这个需求里它就是个摆设。

这个方案解决不了核心需求：当 Claude Code 中断时OpenClaw 无法基于上下文自主决策继续调度。它就像个只会传话的传声筒，一旦对方挂断 转向：直接调用 CLI 的诱惑与局限

既然 ACP 走不通，我就开始琢磨别的路子。直接用 acpx claude -s 会话名 确实Neng复用会话，而且hen简单直接。

比如这样：

# 创建会话
acpx claude sessions new --name my-project
# 测试复用
acpx claude -s my-project "收到请回复数字 1"
# → 输出：1
acpx claude -s my-project "上一个数字 + 4 等于多少"
# → 输出：5 ✅ 成功复用

你kan，这多顺滑。但问题来了Ru果不经过 OpenClaw，就无法发挥它的任务拆解和调度Neng力。这就相当于绕过了 PM，直接跟工程师对话。简单任务还行，复杂任务就抓瞎了。你总得有人告诉工程师先Zuo模块A还是先Zuo模块B吧？

而且，这个方案有个致命问题：/acp 指令只Neng人为发送给 OpenClaw，它自己不Neng执行。也就是说每一条指令dou需要我手动发布，那直接用 Claude Code 不香吗？我追求的是自动化啊！

终极方案：Agent + exec acpx 的完美融合

经过前面几次失败，我终于想通了：既然 API 调用有障碍，为什么不直接让 OpenClaw 像操作终端一样操作 Claude Code 呢？

于是方案四 诞生了：OpenClaw Agent 通过 exec 调用 acpx claude -s 会话名。

这个方案兼顾了所有需求。虽然现在只Neng用 exec 方案，有点“曲线救国”的意思，但Yi经Neng达到托管开发的目的。Ru果未来飞书Neng支持 thread，OpenClaw ACP Neng丰富Neng力，我还是geng希望用原生的 ACP 方式——那样等同于一个 agent 会话，有 session 记录文件，hen方便追溯完整对话过程，可靠性和便捷性dougeng高。但在那之前，这个方案Yi经足够好用了。

第一步：环境准备

你得把工具装好。这一步倒是没什么坑：

# 安装 Claude Code CLI
npm install -g @anthropic-ai/claude-code
# 安装 acpx CLI
npm install -g acpx
# 验证安装
claude --version
acpx --version

第二步：配置 Claude Code

这是Zui关键的一步，hen多人dou卡在这里。为什么必须配置 ~/.claude/settings.json？因为 claude-agent-acp 调用 Claude Code CLI 时环境变量可Neng不传递。Claude Code CLI 优先读取配置文件中的 model 字段。

手动编辑配置文件：

# 手动编辑 ~/.claude/settings.json
{
  "model": "qwen3-plus"
}

注意是 model 字段，不是 Anthropic_model。我用环境变量配了半天没生效，Zui后发现得改配置文件。这里有个大坑，千万别搞错了配置项的名字是 model，而不是想当然的 Anthropic_model。

当然环境变量也Ke以配，作为备用：

export ANTHROPIC_BASE_URL="https://coding.dashscope.aliyuncs.com/apps/anthropic"
export ANTHROPIC_API_KEY="sk-xxx"

第三步：实现流式输出与轮询

OpenClaw 怎么知道 Claude Code 干到哪一步了？我们通过 NDJSON 格式来获取实时反馈。

acpx --format json claude -s output-manager "回复数字 1"

输出是 NDJSON 格式，每行一个事件。OpenClaw 每隔几秒 poll 一次解析 thinking 和 message 字段，实时发送给用户。

整个链路Zui难的地方，不是配置环境，不是写调度逻辑，而是保持同一个 Claude Code 会话。因为 Claude Code 的上下文记忆是绑定在 session 上的。Ru果每次调用dou是新 session，它就完全不记得之前Zuo了什么相当于每次dou要从零开始。这样的话，OpenClaw 的调度就失去了意义——它得把之前的对话历史重新讲一遍，效率极低。

实战体验：通勤途中的远程指挥

配置好这一切后体验发生了质变。Dispatch 和计算机使用Neng力相叠加，用户不在电脑前面就Ke以手机远程指挥 Claude 自动干活了。

想象一下这样的场景：

通勤途中：你在火车上通过手机指挥电脑，为你生成一份晨间简报，或者修复昨晚遗留的一个 bug。geng新后的 Claude 不再局限于 API 或预接入工具，而是Ke以打开本地文件、使用浏览器、运行测试。

离线指挥中心：Ru果发现 AI 钻牛角尖了你Ke以直接发送一条“脑电波”指令：比如通过 tmux 发送 Stop! 优先修复 API, 别管 UI。这种掌控感简直无敌。

在飞书里跟机器人说一声“帮我开发个用户注册功Neng”，然后该干嘛干嘛去。等 OpenClaw 通知我“Zuo完了PR Yi发起”，我去验收一下就行。中间不需要我反复确认、反复给指令。

OpenClaw 通过 exec 命令调用 acpx claude，每隔几秒轮询一次输出，识别到“Claude complete”标记就知道任务完成了。Ru果 Claude Code 遇到问题停下来OpenClaw Neng基于对需求的理解自主决策，告诉它下一步该Zuo什么。只有遇到权限等重大问题时才会问我。

为什么上下文记忆如此重要？

我试过让 OpenClaw 直接开发，但他对项目的工程级上下文Neng力还是hen欠缺。而 Claude Code 有几个不可替代的优势：

第一，它有成熟的项目上下文持续集成优化机制，以项目维度划分工作区，对项目的技术架构、业务逻辑的理解Neng持续积累。

第二，它是专门为 coding 设计的 agent，工具链geng完善，写代码的手感geng好。

第三，长期迭代时Claude Code Neng记住之前的决策和改动，不会每次dou从零开始。

Zui爽的是整个过程 Claude Code 始终在同一个会话里上下文是连续的，它记得之前Zuo了什么不会出现“我是谁我在哪”的情况。就像你招了一个经验丰富的老员工，他记得昨天改了哪行代码，今天接着干，不用你天天给他科普业务背景。

未来展望与开源计划

变化不在工具数量，而在角色转变——OpenClaw 不再直接指挥某个模型，而是管理一个编排层，由它去调度多个执行单元，各自完成不同任务。想象一下2026 年 1 月，有位独立开发者在一天之内完成了 30 分钟 7 个 PR、94 次代码提交。这不是科幻，这就是我们正在构建的未来。

我Yi经把这套方案封装成了 skill，整理好会开源。到时候Ke以直接安装使用，不用自己从头配置。Ru果你也想让 AI 真正帮你托管开发，而不是“挤牙膏式”的一轮一轮Zuo，这篇文章就是为你写的。

通过外部社交软件，来和电脑的 Claude Code 沟通，指挥它干活。有了 Channels 以后你就Neng发消息给 Claude Code 指挥它干活。OpenClaw 的生态指挥Neng力绝对是五颗星，Zui佳用途就是写脚本、自动化任务，甚至是大型项目开发。在微信、飞书、Telegram 里直接指挥，这才是程序员的终极浪漫。

虽然现在只Neng用 exec 方案，有点“曲线救国”的意思，但Yi经Neng达到托管开发的目的。Ru果未来飞书Neng支持 thread，OpenClaw ACP Neng丰富Neng力，我还是geng希望用原生的 ACP 方式——那样等同于一个 agent 会话，有 session 记录文件，hen方便追溯完整对话过程，可靠性和便捷性dougeng高。

现在开始，Claude Ke以直接接管电脑——打开应用、浏览网页、填写表格……结合刚上线的 Dispatch，你哪怕不在电脑前，也Neng远程指挥 Claude 代劳。甚至开发者调试应用时它Neng启动开发服务器，截取页面截图，在演示前准时发给你。

要是Neng让 OpenClaw 使用 Claude Code 进行开发，让小龙虾监督它持续工作直到完全实施完成就好了。现在我终于Zuo到了。

---