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