夜雨聆风
大家好，我是寂寞的熊猫。
OpenClaw 这只“龙虾”最近火得有点离谱。90 天拿下 25 万 GitHub Star，超过 React 成为史上最受欢迎的开源项目。
真上手之后你会发现，OpenClaw 真正擅长的，往往不是埋头写复杂代码，而是拆任务、串流程、调工具。
相反，Claude Code、Codex、Gemini CLI 这类 Agent，在读仓库、改代码、跑测试、做 review 这些事情上，更为专业。
那它们之间该怎么接？这就是 acpx 的价值所在。
省流版
**核心观点：**OpenClaw 更适合调度，Claude Code/Codex/Gemini 更适合编程。acpx 是中间那层统一命令面，让调度层可以标准化地调用执行层
技术本质：ACP 是协议标准，acpx 是 OpenClaw 团队发布的 CLI 工具，把一堆各说各话的编码 Agent 收拢成统一调用接口
关键价值：不是“又多一个 Agent”，而是补齐了“调度层怎么统一调用执行层”这中间的一层
最大的坑：Claude Code 通过 acpx 调用可能不稳定，Gemini CLI 是更稳定的替代；安全漏洞 ClawJacked 必须立即更新
OpenClaw 更适合调度，claude code/codex 更适合写代码
我现在越来越倾向于把这类工具分成两层来看。
调度层（OpenClaw）：拆任务、串流程、连工具、做多步执行。
执行层（Claude Code/Codex/Gemini）：读仓库、改代码、跑测试、做 review.
真正高效的工作流，不是逼 OpenClaw 自己变成“最强程序员”，而是让它在该调度的时候调度，在该外包的时候外包。
举个例子。你对 OpenClaw 说：“帮我重构这个项目的认证模块，提高安全性，并添加完整的测试。”
OpenClaw 在后台：拆解需求 → 调 Gemini 分析安全问题 → 调 Codex 执行重构 → 调 Claude Code 生成测试 → 调 OpenCode 生成文档 → 整合反馈。
你看到的：完整方案 — 代码、测试、文档，全都有。
这就是 OpenClaw + acpx 的核心价值：OpenClaw 负责“什么时候该叫人”，Claude Code/Codex/Gemini 负责“把代码真正写出来”，acpx 负责把这件事变成统一调用接口。
ACP 协议和 acpx 是什么
ACP (Agent Client Protocol) 是 JetBrains 和 Zed 推出的开放协议，标准化代码编辑器和 AI 编程助手之间的通信。
传统方式是每个编辑器接一个 AI 助手都要做一次定制集成，成本高、兼容性差。ACP 就像当年的 LSP 标准化语言服务器一样，让所有实现 ACP 的助手都用相同协议。
acpx（https://github.com/openclaw/acpx[1]）是 OpenClaw 团队基于 ACP 协议发布的无头 CLI 客户端。
它最有意思的地方，是把一堆原本各说各话的编码 Agent，收拢成了一个统一命令面。
传统调用方式是模拟终端输入输出（PTY scraping），不稳定、无法协作、没法共享上下文。acpx 改变了这一切：
1. 统一调用
acpx claude "修这个 bug"acpx codex "给这个模块补测试"acpx gemini "审查这段代码的安全问题"2. 持久会话
普通 prompt 走持久会话，exec 才是一次性会话。连续推进 coding task 时，acpx 维护一条持续的工作线程，不用每次重新解释上下文。
3. 并行工作流
acpx claude sessions new --name authacpx codex sessions new --name reviewacpx claude -s auth "重构登录流程并补测试"acpx codex -s review "审查 auth 改动的回归风险"4. 状态管理
acpx claude status -s authacpx claude cancel -s authacpx claude --no-wait "先把这个任务挂进队列"
如果 ACP 是协议标准，那 acpx 就是让“调度层怎么统一调用执行层”这件事变成现实的那一层。
结合 OpenClaw，acpx 的价值就更明显了
如果你已经在用 OpenClaw，这里其实有一个很现实的问题：OpenClaw 到底该不该自己硬写复杂代码？
我的答案越来越明确：可以写，但没必要什么都自己写。
更合理的做法通常是：
OpenClaw 负责拆任务、找上下文、决定下一步
真正进入 coding 阶段时，把子任务交给更擅长写代码的 Agent
写完之后，再把结果收回来，继续进入 OpenClaw 的后续流程
这时候，acpx 就像一个标准外包接口：
# OpenClaw 决定需要 Gemini 分析代码npx acpx@latest gemini "分析这段代码的性能瓶颈"# OpenClaw 决定需要 Codex 执行优化npx acpx@latest codex "根据分析结果优化性能"# OpenClaw 决定需要 Claude Code 补充测试npx acpx@latest claude "为优化后的代码添加性能测试"整个过程完全自动化。OpenClaw 就像项目经理，acpx 是任务分配系统，各种编程工具是团队里的专业工程师。
OpenClaw 的三种协作模式
acpx 最强大的地方在于：不同工具可以共享上下文，接力完成任务。
模式 1：流水线式
典型场景：代码重构。Gemini 先分析架构问题，Codex 执行重构，Claude Code 补充测试，OpenCode 生成文档。每一步都基于上一步的结果。
模式 2：并行式
典型场景：全栈功能开发。Codex 同时实现前端和后端，Claude Code 并行生成测试，最后 OpenClaw 整合。
模式 3：专家会诊式
典型场景：技术选型。不同工具给出不同方案，OpenClaw 综合评估后选择最优解。
关键是：每个工具都在做自己最擅长的事。Gemini 擅长全局分析和代码审查，Codex 擅长代码生成和重构，Claude Code 擅长测试和复杂推理，OpenCode 擅长大型项目架构。OpenClaw 负责协调整个流程。
编程工具的支持情况
根据 acpx 官方文档，不同编程助手的支持情况差异很大。重点关注三个核心工具：Gemini CLI、Codex、Claude Code。
原生支持
这些工具的 CLI 直接内置了 ACP 协议，稳定性最高：
Gemini CLI（重点推荐）— Google 出品，原生支持 ACP（gemini --acp），响应快，错误处理完善。特别适合代码审查、架构分析和重构任务。这是目前 acpx 生态中最成熟的工具之一。
OpenCode — 原生支持 ACP，也可通过 npx -y opencode-ai acp 调用。优势在于对大型项目的理解能力，适合架构级别的重构和复杂代码库分析。
Cursor — 原生支持（cursor-agent acp），能很好理解项目上下文。适合快速修复和迭代开发。
GitHub Copilot — 原生支持（copilot --acp --stdio），测试生成能力通过 acpx 调用效果很好。建议用于自动化测试场景。
Qwen Code — 原生支持（qwen --acp），阿里通义千问编程版，对中文场景支持出色。适合中文文档生成和代码注释。
⚠️ 需要适配器的工具
Codex（重点工具）— OpenAI 的 Codex CLI，通过 codex-acp 适配器支持。代码生成和重构能力强，但需要通过适配器调用，稳定性略低于原生支持的工具。
Claude Code（重点工具，但有坑）— Anthropic 的 Claude Code，通过 claude-agent-acp 适配器支持。推理能力强，适合复杂任务和测试生成，但实际使用中经常遇到兼容性问题和内部错误。
我的建议：Claude Code 的替代方案
如果遇到 Claude Code 通过 acpx 调用不稳定的情况，可以：
- 用 tmux 直接运行（稳定但失去 ACP 优势）：
# 启动 tmux 会话tmux new -s claude-code# 在会话中运行 claudeclaude# 完成后关闭会话tmux kill-session -t claude-code- 用 Gemini CLI 替代：Gemini 的推理能力也很强，而且原生支持 ACP，稳定性更好。
其他工具
Pi — 通过 pi-acp 适配器支持，轻量级编程助手。
iflow — 实验性支持（iflow --experimental-acp），功能不完整，建议等待正式版本。
KiloCode — 通过 npx -y @kilocode/cli acp 支持，在数据库相关任务上表现优秀。
研发场景：你只需要对话
场景 1：全栈功能开发
你对 OpenClaw 说：
“帮我实现一个用户注册功能，包括前端表单、后端 API、数据库设计和测试。”
OpenClaw 的协作流程：
Gemini 设计整体架构（原生 ACP，稳定性高）
Codex 实现后端注册 API
Claude Code 实现前端注册表单
OpenCode 生成 API 文档和使用说明
**你看到的结果：**完整的功能实现 + 测试 + 文档，一次对话搞定。
场景 2：项目安全加固
你对 OpenClaw 说：
“审查这个项目，找出所有安全隐患和性能问题，并修复它们。”
OpenClaw 的协作流程：
Gemini 进行安全审查，生成问题清单（原生 ACP，审查能力强）
Claude Code 进行性能分析，生成优化建议
Codex 根据安全审查结果修复所有安全隐患并且测试
**你看到的结果：**详细的审查报告 + 修复后的代码 + 新增的测试。
场景 3：技术债务清理
你对 OpenClaw 说：
“帮我重构 XX 模块并添加完整的文档和注释。”
OpenClaw 的协作流程：
Codex 分析代码，识别需要重构的模块
Claude Code 根据分析结果逐个重构问题模块
Qwen Code 为重构后的代码添加详细的中文注释
OpenCode 生成完整的项目文档
Gemini 最终审查重构结果
**你看到的结果：**清晰的代码 + 完整的注释 + 详细的文档。
关键优势
在所有场景中，你只需要用自然语言描述需求：
❌ 不需要学习每个工具的命令
❌ 不需要手动切换工具
❌ 不需要管理工具间的数据传递
✅ OpenClaw 自动选择最合适的工具
✅ OpenClaw 自动管理工具间的协作
✅ OpenClaw 自动整合结果反馈给你
重要的并非又多了一个小工具
如果只把 acpx 看成“又一个 CLI 小工具”，你会低估它。
它真正代表的，其实是 AI 编程工作流在开始分层：
一层负责调度
一层负责执行
中间需要一个统一、结构化、可持续调用的命令面
OpenClaw 这类系统的价值，不会因为它不是最会写代码的那个就下降。恰恰相反，当你接受“调度层”和“执行层”本来就应该分工之后，OpenClaw 的定位反而更强了。
而 acpx，就是这套分工里非常关键的一块。
它不是 ACP 协议本身，不是 OpenClaw 本体，也不是又一个要跟 Claude Code/Codex 抢饭碗的 Agent。
它更像是一块接口层，一块命令层，一块让“谁擅长什么”这件事终于可以被编排起来的连接层。
如果你已经在用 OpenClaw、Claude Code、Codex 这类工具，我觉得可以开始换个角度看 acpx：
它不是给你多一个 Agent，而是给你一套更像工程系统的调度接口。
想要学习AI，可以了解AI破局俱乐部星球，国内最大的AI学习社区，全年有多次免费实战。
