acpx 入门：OpenClaw 的 Agent 间通信利器

这几年大家聊 AI 工具，常见视角还是“哪个模型更强”“哪个回答更像人”。但真到了协作场景，问题往往不是模型聪不聪明，而是：它能不能稳定地接任务、带上下文、在合适的边界里把事情做完。

这也是 acpx 有意思的地方。

如果用一句话概括：

acpx 是一个面向 Agent-to-Agent 协作的命令行入口，它把 ACP 能力变成了可以脚本化、可复用、可编排的工作流接口。

它不是为了在终端里“更花哨地聊天”，而是为了让不同 agent、不同会话、不同任务，以更清晰的方式协同起来。

这篇文章就从最基础的角度讲清楚几件事：acpx 是什么、ACP 是什么、它的核心能力有哪些、怎么快速上手，以及为什么我很看重它背后的“关注点分离”。

一、acpx 到底是什么？

先别把它想得太神秘。

acpx 本质上是一个ACP 的无头 CLI 客户端。这里“无头”很关键，意思是它不依赖终端界面模拟，不靠 PTY 抓屏，不是那种“看起来像自动化、实际上全靠猜终端输出”的方案。

它做的事情更朴素，也更工程化：

• 用统一协议和 agent 通信
• 管理持久会话
• 把 prompt 提交到指定 session
• 支持一次性执行和多轮持续执行
• 提供可脚本消费的输出格式
• 在执行过程中处理权限、超时、队列和取消

换句话说，acpx 不是替代 agent，而是给 agent 协作加了一层稳定的命令行胶水层。

如果你已经在用 OpenClaw，这个定位会更容易理解。 OpenClaw 更像是总调度和环境接入层；而 acpx 很适合承担“把任务送到 ACP agent，并用脚本化方式取回结果”的那一段。

二、ACP 是什么，为什么它重要？

ACP 可以理解为 Agent Client Protocol。

你可以把它看成一套 agent 与客户端之间的标准交互约定。它的价值不在于名字，而在于：把“如何跟 agent 说话”这件事，从零散私有实现，收敛成一组明确的方法和生命周期。

有了协议，很多事情就从“能不能凑合跑”变成“能不能稳定协作”：

• 会话怎么创建、恢复、取消
• 配置怎么设置
• 权限请求怎么表达
• 工具调用怎么回传
• 输出怎么流式返回
• 客户端中断时如何优雅取消

这听起来有点“基础设施味儿”，但它正是 Agent 工程化最缺的一层。

没有协议时，很多所谓多 agent 协作，其实只是：

1. 拼 prompt
2. 启个子进程
3. 抓 stdout
4. 出问题就重试或重开

能不能跑？能。 稳不稳？通常一般。

ACP 的意义，是把这些行为变成更可预期的系统接口。而 acpx 的意义，则是把这种协议能力真正带到日常命令和脚本里。

三、acpx 的核心能力，到底强在哪？

1. prompt 传递：把任务送到对的 agent、对的上下文里

最基础的动作当然是发 prompt。

比如：

acpx codex '帮我审查这个仓库最近的变更'

或者显式写成：

acpx codex prompt '帮我审查这个仓库最近的变更'

看起来很普通，但它和“随便起一个命令行聊天工具”最大的不同是： 这个 prompt 不是一次性飘过去，而是可以进入一个有状态的 session。

这意味着你发出的不是“孤立请求”，而是“往一个持续工作线程里追加任务”。

这点在多步任务里特别重要。 比如你先让 agent 读仓库，再让它定位模块，再让它写修复计划。三条 prompt 如果都能稳定落到同一个上下文里，协作成本会低很多。

2. session 管理：让上下文真正持续，而不是每轮重开

acpx 的另一个核心价值，是持久会话管理。

它支持按以下维度进行 session scope：

• agent command
• 当前工作目录 cwd
• 可选的 session name

也就是说，同一个仓库里你可以有默认会话，也可以有命名会话：

acpx codex sessions new --name docs
acpx codex -s docs '整理 README 的结构'

这个能力非常适合真实工作流，因为现实任务本来就不是一条线。 你可能同时在做：

• 一个研究流
• 一个代码流
• 一个文档流

如果全部塞进同一个上下文，后面很容易互相污染。acpx 的 session scoping 本质上是在做一件很朴素但很重要的事：

让不同任务拥有自己的脑内工作台。

3. exec 工作流：该“一次性”时就别硬持久化

不是所有任务都需要会话。

很多时候你只想做一个单步动作，比如：

• 生成一段摘要
• 做一次快速 review
• 抽取结构化结果
• 在脚本里拿一份最终输出

这时候 exec 就很合适：

acpx exec '用三句话总结这个项目的用途'

exec 会走一个临时 session，做完就结束，不污染持久上下文。

我很喜欢这个设计，因为它提醒了一件事： 持续会话不是默认正确，一次性任务就该一次性处理。

这就是很典型的关注点分离：

• 需要持续记忆的任务，用 prompt
• 只要一次结果的任务，用 exec

别混着来，系统会清爽很多。

4. 权限控制：不是“能跑就行”，而是“边界要清楚”

Agent 系统一旦开始接文件、终端、外部工具，权限就不是附属问题，而是核心问题。

acpx 在这块给了比较明确的权限模式：

• --approve-all
• --approve-reads
• --deny-all

例如：

acpx --approve-reads codex '先读取仓库并给我一个重构计划'

这类模式的价值，不只是安全，更是任务边界明确。

很多工作其实只需要 agent 看、不需要它写。 如果一上来就默认完全放权，短期看省事，长期看很容易让工作流变得不可控。

一个成熟的编排系统，应该把权限当成显式设计，而不是运行时碰运气。

四、快速上手：第一次怎么用最顺

如果你想快速体验，可以先记住四个动作：安装、建 session、发 prompt、看 history。

1. 安装

npm i -g acpx

如果你真的打算长期使用，最好全局安装，而不是每次 npx。因为 acpx 的价值很大一部分就在于稳定复用 session。

2. 创建会话

acpx codex sessions new

或者建一个命名会话：

acpx codex sessions new --name research

3. 发起任务

acpx codex -s research '阅读当前项目结构，并列出值得补文档的模块'

4. 查看历史

acpx codex sessions history research --limit 20

这一步特别实用。 因为很多时候你不是要“重新问一遍”，而是想知道之前这个上下文里到底发生了什么。history 能让你回看轻量历史，而不是靠自己脑补。

五、为什么说 acpx 很适合 OpenClaw？

我觉得二者天然契合。

OpenClaw 更像主 Agent 的工作台：

• 它负责和用户沟通
• 负责接入工具和环境
• 负责决定什么时候需要外包给更专门的 agent

而 acpx 更像 Agent 间通信的传送带：

• 把任务送出去
• 把会话维持住
• 把输出以可消费的方式带回来
• 在脚本和自动化流程里保持稳定调用方式

这就形成一个很舒服的分工：

• OpenClaw 负责“理解与调度”
• acpx 负责“连接与执行”

这样一来，主 Agent 不必亲自扮演所有角色。该深入执行的时候，可以交给 ACP 侧的专门 agent；该总结和决策的时候，再由主 Agent 把结果翻译成人话。

六、关注点分离，才是 acpx 真正的长期价值

如果只看命令形式，acpx 似乎只是多了几条管理 session 和 exec 的命令。 但我觉得它真正重要的地方，不在命令数量，而在于它背后的设计哲学。

1. 对话层和执行层分离

用户对主 Agent 说人话，主 Agent 再把结构化任务交给下游 agent。 这比所有事都直接塞到同一个聊天上下文里靠谱得多。

2. 一次性任务和持久任务分离

该 exec 的不要强行进长期 session；该持续推进的，也别每轮都像第一次见面。

3. 权限决策和任务内容分离

任务是“做什么”，权限是“允许做到什么程度”。这两件事本来就不该混成一句 prompt 里的隐含假设。

4. 人机沟通和机器接口分离

人喜欢自然语言，脚本喜欢结构化输出。acpx 同时支持文本和 JSON 输出，本质上就是承认这两类消费者不同。

这类分离在小玩具里显得啰嗦，但在真正要长期维护的系统里，会非常值钱。 因为系统一旦复杂，最怕的不是功能少，而是边界不清。

七、它适合什么场景？

我觉得 acpx 特别适合以下几类场景：

场景一：主 Agent 调度多个专门 agent

比如主 Agent 负责和用户沟通，再把“代码审查”“文档整理”“资料研究”拆到不同 session 或不同 agent。

场景二：脚本化工作流

比如在 CI 或自动化脚本里调用 agent，要求它输出 JSON，再交给下一步程序处理。

场景三：需要长上下文但又不想污染主线程的任务

例如同一仓库里的长期重构任务、资料归档任务、分支 review 任务。

场景四：对权限边界有明确要求的环境

例如默认只允许读取、审查，不允许直接写入或执行危险动作。

八、一个很实际的建议：先别追求“大而全”，先把 session 用对

很多人刚接触这类工具，第一反应是研究最复杂的编排。 我反而建议先把最基础的 session 习惯建立起来：

• 什么任务该开新 session
• 什么任务该继续原 session
• 什么任务只需要 exec
• 什么情况下只给 read 权限

一旦这套边界清楚了，后面的并行、队列、自动化格式输出，都会顺很多。

说白了，acpx 最先改变的不是“能力上限”，而是任务组织方式。

九、结语：它不是让 Agent 更像人，而是让协作更像工程

我对 acpx 的喜欢，不是因为它让 agent 聊得更自然，而是因为它让 Agent 协作更像一个正经系统。

它把很多本来容易混在一起的东西拆开了：

• prompt 和 session
• exec 和持续上下文
• 权限和执行
• 人类可读输出和机器可读输出

这套拆分不会让系统显得“更聪明”，但会让系统更稳、更清楚，也更适合真正落地。

如果你正在用 OpenClaw，或者准备把 Agent 从“问答工具”推进到“协作节点”，那 acpx 很值得早点上手。

因为很多时候，真正拉开差距的，不是模型多能说， 而是你的 Agent 系统，能不能把任务接住、拆开、推进，再有条理地交回来。