ACPX 是 OpenClaw 生态的 ACP 协议桥接层，让外部 AI 编程工具变成可调度的智能体节点，实现多智能体协作开发，支持持久化会话和自动工具发现。
现在 Codex 可以通过 ACP 调用 OpenClaw，所以 OpenClaw 也可以通过 ACP 调用 Codex。
假设你是一家餐厅老板，OpenClaw大龙虾是你的店长，ACPX 是后厨的传菜口。以前你的厨师只能在后厨自己玩，现在 ACPX 这个传菜口打通了，Claude Code、Codex、Gemini CLI 这些外部大厨都能被大龙虾店长统一调度。你可以让 Claude 切菜、Codex 炒菜、Gemini 摆盘，还能让他们轮班倒——这就是 ACPX 干的事：把分散的 AI 编程工具变成一支能听指挥的厨房战队。
为什么程序员需要 ACPX 这个"传菜口"
搞 AI 编程的人都知道一个痛点：工具太多，调度太乱。
Claude Code 写代码很香，Codex 补全很溜，Gemini 有时候也能整点惊喜——但它们各自为政，就像你请了两个保姆，一个只会做饭，一个只会带娃，你想让她们协作，得自己当传话筒。
ACPX 解决的就是这个"传话筒"问题。
它是 OpenClaw 生态里的一个扩展插件，专门负责 ACP（Agent Client Protocol）协议的运行时桥接。简单说，它让 OpenClaw 这个"店长"能通过统一协议，直接指挥外部 AI 工具干活。以前 OpenClaw 只能管自己内部的智能体，现在通过 ACPX，Claude Code、Codex CLI 这些外部工具都能被注册成可调度的"智能体节点"。这相当于把孤岛连成大陆，让 OpenClaw 从单机游戏升级成了网游服务器。
这个设计有个精妙之处：它没强行把外部工具吞并进来，而是通过协议桥接保持它们的独立性。Claude Code 还是 Claude Code，Codex 还是 Codex，但 OpenClaw 现在可以像调用本地函数一样调用它们。这种"松耦合"架构在软件工程里是高阶玩法——既保留了各工具的原生能力，又实现了统一调度。对于开发者来说，这意味着你可以根据任务特性自由切换工具：重构用 Claude，快速生成用 Codex，多语言项目扔给 Gemini，全由 ACPX 在背后牵线搭桥。
ACPX 如何让外部 AI 工具"听话"
ACPX 的核心能力可以分成四个维度：外部智能体运行、持久化会话、智能体调度、自动工具发现。
这四项能力叠加起来，构成了一个完整的"外部 AI 工具操作系统"。
外部智能体运行是基本功。
ACPX 支持对接市面上主流的 AI 编程工具：Claude Code、Codex、Gemini CLI、OpenCode、Pi agent 等。这些工具原本都是独立 CLI，现在通过 ACPX 注册到 OpenClaw 的调度池里。当你对 OpenClaw 说"用 Claude Code 帮我重构这个函数"，它会自动识别任务类型，选择 ACP runtime，通过 ACPX 拉起 Claude Code 进程，把任务参数传过去，再把结果收回来。整个过程你无感知，就像调用一个本地函数一样顺滑。
持久化会话是个高级特性。
传统 CLI 工具通常是"一次性的"：你输入命令，它执行，退出，上下文全丢。ACPX 打破了这种模式，支持长时间运行的智能体线程。你可以用 /acp spawn claude --mode persistent 启动一个常驻的 Claude 实例，之后同一个 thread 的对话都会自动路由给这个实例。这意味着智能体可以像人类程序员一样"记住"项目上下文，持续开发代码，而不是每次都要重新预热。对于大型项目开发，这种连续性至关重要——想象一下每次换文件都要重新解释一遍项目结构，那效率得多感人。
智能体调度是 ACPX 的控制中枢。
它提供了一套类似操作系统进程管理的命令集：spawn 启动智能体、steer 控制行为、status 查看状态、cancel 停止任务、close 关闭实例。这套接口让 OpenClaw 具备了真正的"多智能体 orchestration"能力。你可以同时 spawn 多个智能体，让它们并行处理不同模块；也可以动态 steer 调整优先级，甚至 kill 掉卡死的进程。这本质上是在 AI 编程领域实现了进程管理，把无序的 AI 调用变成了可编排的工作流。
自动工具发现则是 ACPX 的"魔法"所在。
传统 AI 集成需要手动绑定函数、硬编码工具列表，ACPX 通过 ACP 协议实现了动态能力发现。智能体可以自动探测环境中可用的 MCP tools、plugin skills、CLI harness，而不是靠人工配置。社区有人形容这就像从"打电话前要查通讯录"变成了"直接喊一嗓子，能响应的都过来"。这种自发现机制大大降低了集成成本，也让系统具备了弹性扩展能力——新工具装上去就能被自动识别，无需改代码。
ACPX 的两种"上班模式"
ACPX 提供了两种执行路径，对应不同的使用场景。
第一种是 ACP Runtime 模式，也是默认模式。在这种模式下，OpenClaw 的 runtime 直接调度 ACPX，通过 sessions_spawn 接口管理智能体生命周期。流程是：OpenClaw → ACP runtime → ACPX → 外部 AI 工具。这种模式的优点是完整的生命周期管理和会话绑定，适合需要长期跟踪的复杂任务。它就像正式员工，有入职手续、绩效考核、离职流程，管理规范但 overhead 稍高。
第二种是 Direct ACPX 模式，直接用 CLI 驱动，比如 acpx --agent claude。这种方式被社区戏称为"telephone game 模式"——你直接打电话找 Claude，跳过了店长 OpenClaw。它适合单次任务、不需要 runtime 介入生命周期的场景。优点是轻量快速，缺点是没有会话管理和线程绑定，干完活就散伙。这相当于临时工，来了就干，干完就走，没有五险一金但召之即来。
两种模式的存在体现了 ACPX 设计的灵活性：既支持企业级的编排 orchestration，也支持个人级的快速 hack。你可以根据任务复杂度自由选择，甚至在同一个项目里混用——核心模块用 runtime 模式保稳定，临时脚本用 direct 模式图省事。
ACPX 在智能体架构里的"江湖地位"
要理解 ACPX 的价值，得先看清 AI 系统的三层架构。
经典的 AI Agent 架构分为：Orchestrator（编排层）、Runtime（运行时）、Tool execution（工具执行层）。
OpenClaw 的对应关系是：
Orchestrator编排 就是 OpenClaw 本身，负责理解任务和调度决策；
Runtime 是 ACP 协议，负责通信规范；
Execution layer 就是 ACPX，负责实际连接外部工具。
所以 ACPX 的定位非常精确：它是 Agent Execution Adapter，专门解决"怎么让外部 AI CLI 被统一调度"的问题。
没有这个适配层，OpenClaw 只能管自家孩子，有了 ACPX，它可以当幼儿园园长，管别人家孩子。这种架构分层让系统具备了良好的扩展性——未来出现新的 AI 编程工具，只要实现 ACP 协议，ACPX 就能无缝接入，无需改动 OpenClaw 核心。
从更宏观的视角看，ACPX 代表了 AI 编程工具集成的一个趋势：从"点对点集成"走向"协议化集成"。以前每个工具都要写专门的适配代码，现在只要符合 ACP 协议就能自动接入。这类似于 HTTP 协议统一了 Web 服务，ACPX 正在尝试统一 AI 编程工具的调用方式。如果这个生态做大了，未来可能出现"AI 编程工具应用商店"，一键安装就能接入 OpenClaw 调度池。
用 ACPX 搭建 AI 编程流水线
理论说完，看几个实际应用场景。
第一个是 AI 编程流水线。想象一个典型的开发 workflow：分析需求 → 生成代码 → 写测试 → 生成文档 → 代码审查。
传统方式是手动切换工具，或者在一个工具里硬撑。
有了 ACPX，OpenClaw 可以 orchestrate编排指挥 整个流程：
spawn Codex 做代码生成，
spawn Claude 写单元测试，
spawn Gemini 生成文档，
spawn 另一个 Claude 实例做代码审查。
整个过程自动化流转，你只管提需求，剩下的交给智能体流水线。
第二个场景是多智能体分工。
大型项目通常需要不同专长的"开发者"：
Agent A 负责核心逻辑，
Agent B 专注测试覆盖，
Agent C 处理文档，
Agent D 做安全审计。
ACPX 让这些智能体运行在不同的外部工具中，各自发挥所长，又通过 OpenClaw 统一协调。
这比单一智能体全能型选手更高效，因为你可以为每个子任务选择最优工具，避免"用一个瑞士军刀干所有活"的尴尬。
第三个场景是 IDE 集成。
ACPX 支持通过 stdio 与 IDE 通信，形成"IDE → ACP bridge → OpenClaw gateway"的链路。
这意味着你可以在 VS Code 或 JetBrains 里直接调用 OpenClaw 指挥的多智能体服务，体验类似 AI pair programming server。
开发者在编辑器里写代码，背后可能有三个 AI 在同时工作：一个补全当前行，一个检查潜在 bug，一个准备生成单元测试。
这种"隐形团队"的开发体验，是单一 IDE 插件无法提供的。
安装 ACPX 并开始"使唤"智能体
上手 ACPX 很简单。
首先安装插件：openclaw plugins install @openclaw/acpx。
然后开启 ACP 功能并配置后端：openclaw config set acp.enabled true、openclaw config set acp.backend acpx、openclaw config set acp.defaultAgent claude。三行配置搞定，就可以用 /acp spawn claude 启动你的第一个外部智能体。
这个安装流程设计得很克制，没有复杂的依赖地狱，也没有繁琐的认证流程。
OpenClaw 的插件系统把 ACPX 当作一等公民对待，安装、配置、使用都在同一个 CLI 里完成。对于已经习惯命令行工具的开发者来说，这种体验无缝且自然——你不需要离开终端去网页配置，所有操作都在熟悉的 shell 环境里完成。
ACPX 的本质：让 OpenClaw 从"单机"变"军团"
如果用一句话总结 ACPX 的价值：它是 OpenClaw 的 AI 工具执行层，负责把外部智能体变成可调度的计算资源。OpenClaw 专注任务理解和调度决策，ACPX 专注启动和控制外部智能体。两者分工明确，构成了一个完整的 multi-agent 开发平台。
这个设计解决了一个被忽视的问题：AI 编程工具的碎片化。市面上优秀的 AI CLI 越来越多，但它们之间缺乏互操作性。ACPX 通过协议桥接的方式，在不破坏各工具独立性的前提下，实现了统一调度。
这有点像 Kubernetes 在容器编排领域的角色——你不一定需要 Kubernetes，但当你有几十个微服务要管理时，它就成了基础设施。ACPX 正在尝试成为 AI 编程领域的"编排基础设施"。
对于个人开发者，ACPX 意味着你可以自由组合最好的工具，不再被单一产品锁定。对于团队，它意味着可以建立标准化的 AI 开发流程，把最佳实践固化在 orchestration 逻辑里。对于工具厂商，接入 ACP 协议就能进入 OpenClaw 生态，获得更广泛的采用。这是一个多方共赢的架构设计，也是 ACPX 值得关注的根本原因。
更深层的追问：OpenClaw 的 ACP / ACPX / Subagent / MCP 到底啥关系
看到这里你可能会问：OpenClaw 自己还有 Subagent 和 MCP，它们和 ACP/ACPX 是啥关系？这是个好问题，也是很多人没看懂的地方。
简单说：
Subagent子智能体 是 OpenClaw 内部的智能体机制，
MCP 是外部工具的能力描述协议，CLI命令行在OpenClaw中替代了MCP，代表未来趋势！
ACP 是智能体通信协议，
ACPX 是 ACP 的具体实现。
四者层级不同，但共同构成了 OpenClaw 的完整智能体生态。这个关系值得另起一篇深挖，毕竟搞清楚架构边界，才能真正用好这套系统。
彩蛋
OpenClaw之父Peter Steinberger 说：
在我的 Mac Studio 上使用 codex 中的 acpx 作为连接到 gateway/acp -> Molty 的私有后通道，在那里想出了一个“笑话”，然后让 Molty 调用 sessions_send 到实时 Discord 会话。
结果：由龙虾们之间私下讨论，然后 Discord 会议决定是否发布消息或保持沉默。
Molty是在目标龙虾群批准后才发布这个“笑话”的。
我的 Molty 已经住手在 openclaw 维护者频道了