很多人刚开始用 OpenClaw，注意力都放在 Prompt、技能、模型切换上。
这些当然重要。
但你真把它拿来干活，卡住你的通常不是"不会写提示词"，而是还在用一个会话硬扛所有任务。
你一边让它查资料，一边让它写方案，还顺手补一句"再帮我看看另一个项目"，到最后很容易发生的事不是效率变高，而是上下文越聊越脏、节奏越跑越乱。
我现在更认可的一种用法是：主会话负责判断，子代理负责执行。
这也是 OpenClaw 多会话和子代理更值钱的地方。
一、先别急着开子代理，先把"会话"理解对
在 OpenClaw 里，会话不是聊天窗口皮肤，而是一个独立上下文桶。
你在一个会话里聊过什么、做过什么、刚刚调用过哪些工具，这些都会影响它后面的判断。
所以很多人用着用着会觉得：
- 明明刚才还挺准，后面怎么开始跑偏了？
- 为什么我只是补问一个任务，前面的语境就乱了？
- 为什么一个慢任务会把当前对话拖住？
问题不一定出在模型，很多时候出在任务没拆层。
主会话更适合做三件事：
- 定目标
- 做判断
- 收结果
而那些耗时、独立、容易污染上下文的活，更适合交给独立会话去跑。
二、子代理到底适合什么时候开
不是所有任务都值得开子代理。
如果只是一个简单问答、一个短判断，主会话直接做就够了。
但下面这些场景，我基本都会优先考虑拆出去：
1）任务会跑很久
比如批量搜资料、整理网页、读一堆文档、做代码检查。
这类任务很怕把主会话堵住。OpenClaw 的子代理本质上就是一个后台独立运行，主会话可以继续往前走。
2）任务之间尽量别互相污染
比如你一边在写公众号稿子，一边又想让 AI 去查一个完全不同的话题。
这时候放在同一个会话里，很容易出现语境串味。拆成两个会话，会干净很多。
3）你想并行
真正能把效率拉开的，不是让一个 AI 更拼，而是让多个独立任务同时推进。
比如：
- 子代理 A 去找资料
- 子代理 B 去整理结构
- 主会话继续写正文框架
这就是多会话的价值，不是为了酷炫，而是为了实用。
4）任务本身有边界风险
高风险、长耗时、需要强隔离的任务，单独开会话更稳。
如果你的场景要求必须保持沙箱约束，原生 subagent 还可以在合适配置下配合 sandbox: "require" 使用。这类任务也别和主会话混在一起。
三、OpenClaw 里更值得记住的 4 个动作
如果你想把多会话真正用起来，不用先背一堆概念，先记住这 4 个动作就够用。
1. sessions_spawn：把任务拆出去
这是核心入口。
你可以把一个独立任务直接丢给子代理：
bash
{
"task": "帮我整理 10 条 OpenClaw 多会话的真实使用场景，并按优先级输出",
"label": "research-openclaw"
}这里有两个点一定要记住：
sessions_spawn是非阻塞的，不会等任务做完才返回。- 它返回
accepted以后，子代理会在后台跑，完成后再通过 announce 把结果回传。
也就是说，它更像"派活"，不是"同步执行函数"。
2. sessions_history：看它到底干了什么
子代理回了一句摘要，不代表你就只能看摘要。
如果你想知道它中间怎么推理、做了哪些步骤、工具跑成什么样，可以去查对应会话的历史：
bash
{
"sessionKey": "agent:your-agent:subagent:xxxx",
"limit": 50
}这个动作特别适合两种情况：
- 结果不错，你想复盘它为什么做对了
- 结果不对，你想知道它到底歪在哪一步
3. sessions_send：继续补任务，不用重开
很多人会误以为子代理一开完就只能等结果。
其实不是。
如果它还在那个会话里，你可以继续追加消息，让它沿着原来的上下文往下做：
bash
{
"sessionKey": "agent:your-agent:subagent:xxxx",
"message": "把上面的 10 条场景里，更适合内容运营团队的 3 条单独展开"
}这很适合"第一轮先广撒网，第二轮再定向深挖"的工作流。
4. subagents：管控，而不是放养
多会话一多，很怕的不是不会用，而是失控。
这时候就要靠 /subagents 或对应能力去看、steer、kill 当前会话发出去的子代理。
常用心智很简单：
- 看列表：确认现在到底跑了几个
- steer：临时改方向
- kill：别让没用的 run 一直占资源
OpenClaw 很适合并行，但并行不等于放任后台越挂越多。
四、一个特别容易搞混的点：ACP 不是普通子代理
这点很多人会混。
OpenClaw 里默认的 sessions_spawn 走的是原生 subagent 运行时，适合研究、整理、生成、分析这类后台工作。
但如果用户明确说：
- 用 Codex 跑
- 用 Claude Code 做
- 开一个 Gemini CLI 会话
这就不是普通子代理的心智了，而是 ACP runtime。
也就是说，你应该这么理解：
- 原生 subagent：OpenClaw 自己的后台分身
- ACP session：把任务交给外部 harness，比如 Codex / Claude Code / Gemini
对应到调用层，就是显式加上：
bash
{
"runtime": "acp",
"agentId": "codex",
"mode": "session",
"thread": true,
"task": "在这个仓库里继续完成重构"
}这个边界分清以后，很多"为什么它没有按 Codex 的方式跑"的困惑就没了。
五、我常用的 3 套工作流模板
下面这 3 套是我觉得很容易直接抄走的。
模板 1：主会话定方向，子代理去找料
更适合写文章、做方案、准备分享。
分工很清楚：
- 主会话：确定主题、结构、判断角度
- 子代理：搜资料、拉案例、补事实点
- 主会话：整合成最终成稿
这样做有个很大的好处：写作者始终留在"判断层"，不会被搜索过程反复打断。
模板 2：主会话盯结果，子代理做执行
比如你已经知道要什么结果了，但执行链条比较长。
这时候主会话只负责一句话：
我要一个可交付结果。
然后把执行动作拆出去：
- 一个子代理去跑研究
- 一个子代理去做整理
- 一个子代理去产出中间件
主会话只看回传，不在细节里迷路。
模板 3：复杂编码任务直接交给 ACP
如果任务明显更适合 Codex / Claude Code 这类编码 harness，就别硬塞给普通子代理。
原生 subagent 擅长后台拆活，ACP 擅长在外部 coding runtime 里持续推进。
这两个不是替代关系，而是分工关系。
六、5 个常见误区
误区 1：子代理越多越好
不是。
每个子代理都有独立上下文和 token 消耗。并行能提速，但也会涨成本、涨管理难度。
能拆 2 个就解决的事，别一上来开 8 个。
误区 2：sessions_spawn 返回了，就等于任务完成了
不是。
它只是说明任务被接收了。真正结果要么等 announce 回来，要么你再用 sessions_history / subagents 去查。
误区 3：子代理会自动继承主会话全部人格和上下文
也不是。
默认情况下，子代理上下文只注入 AGENTS.md 和 TOOLS.md，这其实是好事，能保证它别带着太多无关包袱开跑。
误区 4：子代理可以无限裂变
默认不行。
OpenClaw 默认会限制嵌套扇出，避免你一层套一层最后失控。想做 orchestrator 模式，要额外配置 maxSpawnDepth。
误区 5：线程绑定是所有渠道都一样好用
不是。
线程绑定是很强的能力，但它不是全平台同一个体验。当前更典型的是 Discord 场景，别把它想成 everywhere by default。
七、如果你现在就想开始，我建议这样用
别一上来就研究"特别复杂的多代理架构"。
先用一版足够朴素的方案：
第一步：保留一个干净的主会话
只让它做目标确认、结果判断、最终拍板。
第二步：把慢任务拆给一个子代理
先从资料搜集、批量整理、长耗时检查这种很容易卡主线程的活开始。
第三步：用 history 看回放
别只看一句结果，去看它到底怎么完成的。你会很快知道哪些任务值得继续拆，哪些不值得。
第四步：明确 ACP 的边界
遇到"请用 Codex / Claude Code / Gemini 做"的需求，别混用，直接走 ACP runtime。
只要你把这 4 步练熟，OpenClaw 的使用体验会从"一个会聊天的助手"直接变成"一个会分工的工作台"。
最后一句
很多人以为 OpenClaw 的上限在 Prompt。
我自己的判断正好相反。
当你开始把它当成可分工、可并行、可治理的一套协作系统来用，OpenClaw 才算真正开始好用。
一个会话能帮你做事。
多会话和子代理，才更像是在帮你搭一个会自己转起来的小团队。