OpenClaw 的三条通讯线:派活、聊天、请外援

用 OpenClaw 跑多 Agent 有段时间了，最近被问得最多的一个问题是：Sub-Agent、Agent-to-Agent、ACP Agent，这仨到底啥关系？

说实话我一开始也搞混过。文档里这三个概念散落在不同页面，如果不是真正上手跑过，很难一次理清楚。今天把我的理解和踩过的坑都整理出来，一篇讲透。

先说一个底层认知

这三种机制不是"三选一"的关系，是"三条不同的路"。

打个比方。你是一家公司的老板：

Sub-Agent

是你派活给自己公司的员工——你说干什么，他干完了交给你，完事。

Agent-to-Agent

是你公司内部的同事之间互相沟通——产品经理找开发对需求，开发找测试对用例，平级协作。

ACP Agent

是你请的外包团队——他们有自己的工具链、自己的工作方式，通过一套正式的合作协议接进你的项目。

想清楚这个，后面就通了。

Sub-Agent：老板派活

Sub-Agent 是 OpenClaw 最基础的多 Agent 机制。

一句话说清楚：主 Agent 在后台 spawn 一个子任务，子任务跑在独立的 session 里，跑完把结果 announce 回来。就这么简单。

用起来也直白：

/subagents spawn main "总结最近7天的changelog，拟一份发布说明"

这条命令是非阻塞的，立刻返回一个 run id。你的主 Agent 可以继续干别的事，sub-agent 在后台默默跑。跑完了自动往你的聊天频道发一条总结消息。

几个关键特性：

默认隔离。Sub-agent 跑在自己的 session 里，session key 长这样：agent::subagent:。它默认拿不到主 Agent 的 session tools，也不会污染主 Agent 的上下文。这是个很好的设计——你不希望一个跑飞的 sub-agent 把主 Agent 的状态搞乱。

支持有限嵌套。把 maxSpawnDepth 设成 2，你就可以搞一个编排者 spawn 多个 worker 的模式。但再深就没太大意义了，复杂度上去收益反而下来。

适合省钱。这是我实际用下来觉得最实在的一个点。主 Agent 挂 Opus 做规划和综合，sub-agent 挂 Sonnet 甚至本地模型跑并行的体力活。配置也简单：

{    "agents": {        "defaults": {        "subagents": {                "model": "anthropic/claude-sonnet-4-6",                "thinking": "low"            }        }    }}

主力干脑力活，替补干体力活，各得其所。

什么时候用 Sub-Agent？任务可以纵向拆解、不需要来回讨论、干完交差就行的场景。典型的就是并行研究、批量处理、长任务异步跑。

Agent-to-Agent：同事聊天

Sub-Agent 是单向的——老板派活，员工交差。但很多场景你需要的是双向沟通。

这就是 Agent-to-Agent 的价值。它用的是 sessions_send，本质上是让两个独立的 Agent 直接互发消息，支持多轮来回对话。

举个具体的例子。你有一个 Product Owner Agent（叫 Todd），一个 Backend Developer Agent（叫 Alex）。Todd 拿到需求后，想把开发任务分配给 Alex，同时需要跟 Alex 确认技术可行性。

用 Sub-Agent 你只能单向丢任务过去。用 Agent-to-Agent，Todd 可以直接给 Alex 发消息：

sessions_send(    sessionKey="agent:alex:im:channel:xxxxx",    message="这个需求的数据库部分，你评估一下工期和风险点")

Alex 收到后可以回复，Todd 可以追问，来回最多 5 轮（由 maxPingPongTurns 控制）。任何一方回复 REPLY_SKIP 就终止对话。

这个机制有几个重要细节：

默认关闭，需要显式开启。这是安全考虑——你不希望任意 Agent 能随便给其他 Agent 发消息。配置长这样：

{    "tools": {    "agentToAgent": {            "enabled": true,            "allow": ["main", "todd", "alex", "riley"]        }    }}

生产环境别用通配符 "*"，老老实实列白名单。

每个 Agent 有完整独立的身份。不像 Sub-Agent 是从父 Agent 派生出来的"临时工"，Agent-to-Agent 里的每个 Agent 都有自己的 Workspace、SOUL.md、MEMORY.md、甚至自己的 IM 频道 bot。它们是真正的"独立个体"，只不过可以互相通讯。

什么时候用 Agent-to-Agent？需要跨角色协调、审核对抗、交接确认的场景。用我之前归纳的协作模式来说，Agent-to-Agent 天然适合「对抗/评审协作」和「链式协作」——Builder 写完代码让 Reviewer 审，Reviewer 发现问题打回去，Builder 改完再提交，这种来回靠 Sub-Agent 做不了。

ACP Agent：请外援

前两种都是 OpenClaw 内部的事。所有 Agent 跑在同一个 Gateway 里，用同一套 LLM 调用管道，共享认证体系。

但如果你想调用外部的编码工具呢？比如各种独立的 AI Coding Agent，它们可不是 OpenClaw 内部的 Agent。

这就是 ACP（Agent Client Protocol）Agent 的用武之地。

ACP Agent 也是通过 sessions_spawn 拉起的，但多了一个关键参数 runtime: "acp"。这意味着它不是在 OpenClaw 内部 fork 一个 session，而是通过 ACP 协议启动一个外部工具的进程，然后通过标准协议跟它通讯。

/acp spawn <外部Agent> --mode persistent --thread auto

这条命令做了什么？它通过 OpenClaw 的 acpx 插件，拉起了一个外部编码工具的进程，绑定到当前聊天线程。之后你在这个线程里说的话都会通过 ACP 协议路由给对应的外部 Agent。

为什么不能把外部工具包装成 Sub-Agent？

因为外部编码工具不是简单的 API 调用。它们有自己的文件系统访问能力、diff 展示逻辑、权限审批流程、上下文管理方式。你没法把它们的能力简单塞进一个 OpenClaw 的 skill 或 sub-agent prompt 里——它们是完整的编码 Agent，需要自己的进程空间和运行时环境。

ACP 解决的是"异构 Agent 的对接问题"。类比 LSP 让任何编辑器接任何语言服务器，ACP 让 OpenClaw 能接任何遵循该协议的外部 Agent。底层走的是 JSON-RPC 2.0 over stdio，成熟可靠。

踩过的坑：权限配置。

这是我实际用的时候最先栽的地方。ACP 会话是非交互式的——没有终端让你点"同意"或"拒绝"。默认配置下写操作会触发权限提示，但因为没有 TTY，提示无处弹出，直接报错崩掉。

如果你发现 ACP Agent spawn 之后莫名其妙地失败，输出很少就挂了，大概率就是这个问题。开发环境直接把 permissionMode 设成 approve-all：

openclaw config set plugins.entries.acpx.config.permissionMode approve-all

Sub-Agent 和 Agent-to-Agent 不会遇到这个问题，因为它们始终在 OpenClaw 内部跑，权限体系是统一的。

ACP Agent 需要常驻定义吗？

这是我被问过好几次的问题，答案是：不一定，看你的用法。

ACP Agent 有两种使用模式——临时调用和常驻绑定，对应的配置方式完全不同。

模式一：临时调用，不需要预定义。

直接在聊天里 spawn，用完就关：

/acp spawn <外部Agent> --mode persistent --thread auto

甚至可以自然语言说"用某个外部编码工具开个会话帮我跑测试"，OpenClaw 会自动路由到 ACP 运行时。如果你没指定 agentId，OpenClaw 会用 acp.defaultAgent 的配置兜底。

这种方式适合"临时起意借个外援"——主 Agent 跑着跑着发现某个子任务需要外部工具的能力，临时拉一个 ACP 会话，干完 /acp close 关掉，不留痕迹。

模式二：常驻绑定，需要预定义。

如果你希望某个聊天频道里的消息自动路由到特定的外部 Agent，不用每次手动 spawn，那就需要在配置里做两件事——在 agents.list 里定义 ACP Agent，在 bindings 里绑定频道：

{    "agents": {    "list": [        {            "id": "my-coding-agent",            "runtime": {                "type": "acp",                "acp": {                    "agent": "my-coding-agent",                    "backend": "acpx",                    "mode": "persistent",                    "cwd": "/workspace/my-repo"                }            }        }    ]},    "bindings": [        {            "type": "acp",            "agentId": "my-coding-agent",            "match": {                "channel": "im-channel",                "peer": {                     "kind": "channel",                     "id": "222222222222222222"                 }            }        }    ]}

配完之后，那个聊天频道就变成了外部编码工具的"专属工位"——你在里面说的任何话都会自动通过 ACP 协议路由给它，不需要每次手动 spawn。

怎么选？简单判断：偶尔用、按需调，不用预定义，临时 spawn 就行；固定频道、固定工具、长期使用，预定义 agent + binding，省心省力。

用组织的隐喻来说：临时调用是"项目制外包"，活干完合同就结束了；常驻绑定是"长期顾问"，有固定的工位和沟通通道，随叫随到。

什么时候用 ACP Agent？你需要借助外部工具的专长，而这些专长是 OpenClaw 原生 Agent 不具备的。比如让某个工具处理大规模重构，让另一个工具做深度架构设计。它们各自有各自擅长的事，ACP 让你不用离开 OpenClaw 就能调用它们。

三者混合使用才是正解

实际工作流里，这三种机制经常在同一个任务链里一起出现。

举个我自己的场景。主 Agent 收到一个新功能需求：

主 Agent 用Sub-Agent并行拆三个模块的调研任务，分别了解技术方案的可行性。三个 sub-agent 各跑各的，跑完 announce 回来。

其中一个模块涉及到复杂的协议解析，主 Agent spawn 一个ACP Agent调 Claude Code 来写核心逻辑——这块需要深度推理和长上下文，Claude Code 比较擅长。

代码写完后，通过Agent-to-Agent让 Reviewer Agent 审代码。Reviewer 发现了一个边界条件没处理，直接回复 Builder Agent，Builder 修完再提交，两轮 ping-pong 搞定。

三条线各管各的事，互不干扰。

选型决策树

最后给一个简单的判断标准，遇到多 Agent 场景不知道用哪个的时候对着看：

任务能拆、不需要讨论、干完交差？→ Sub-Agent

需要两个角色来回沟通、协商、审核？→ Agent-to-Agent

需要调用 OpenClaw 之外的编码工具？→ ACP Agent

复杂场景？→ 混着用，各管一段

还是那句话——多 Agent 不是银弹，每多一种通讯机制就多一层复杂度。先用单 Agent 把事情跑通，确认了瓶颈再拆，确认了角色边界再加通讯。过早设计多 Agent 架构，你只是在用更贵更复杂的方式做同样的事。

但如果你的场景确实需要——注意力稀释、角色污染、异构工具协作——那这三条线就是你的工具箱。选对了，事半功倍。