OpenClaw 子 Agent 怎么用:什么时候该继续聊,什么时候该拆出去

最近翻了一下站里的搜索词，看到两条挺有意思的：

openclaw 子agent openclaw 切换agent

看着很像，但问的根本不是一件事。

搜"子 agent"的人，通常已经知道 OpenClaw 可以多线程干活，真正想搞明白的是：什么时候该把任务拆出去。

搜"切换 agent"的人，更多是在问：我现在到底该继续在这个对话里做，还是应该换一个独立的 Agent 来接手。

我自己前阵子也在这个点上打转了很久。刚开始玩多 Agent，很容易走两个极端——要么什么都想开子 Agent，查个网页都想分出去；要么明明任务已经很长很乱了，还死扛在当前 session 里硬做，上下文越聊越杂。

这篇不讲"怎么开启多 Agent"，也不写参数说明。

只聊一件事：当前对话、子 Agent、独立 Agent，到底分别适合什么场景。

先把三个概念说清楚

第一次接触容易被术语绕进去，我用最直白的话重说一遍。

🔹 当前对话 就是你现在正在聊的这个 session。发一句，接着当前上下文往下做。适合连续追问、轻修改、顺着刚才的话继续往下推进。

🔹 子 Agent（Sub-agent） 从当前任务里临时分出去的一个后台工位。有自己的独立 session，跑完以后把结果回传回来。官方文档的说法是：子 Agent 是从现有 Agent 派生出去的后台任务，结束后汇报给发起者。

🔹 独立 Agent 不是"临时外包"，而是另一套长期存在的脑子。有自己独立的 workspace、自己的 AGENTS.md / SOUL.md / USER.md、自己的会话历史，甚至可以绑定独立渠道账号。

这三者最大的区别，不是"谁更高级"，而是：

把这个关系想明白，后面的判断就顺了。

什么时候继续在当前对话里做

很多人一看到多 Agent，就觉得"拆出去肯定更专业"。这不一定。

以下这些场景，我基本不会开子 Agent：

• 改一段提示词

• 补一句文案

• 继续刚才的文章提纲

• 根据上一条消息再细化一步

• 解释刚才返回结果里的某个字段

这些任务有个共同点：高度依赖当前上下文，而且动作很轻。

这种时候硬开一个子 Agent，反而增加沟通成本。你还得重新交代背景、说清前面聊了什么、你现在要改哪一段。原本一句话就能接着做的事，硬生生拆成了一次新的派工。

我自己现在的判断法很粗暴：

如果这个任务用两三句话就能在当前对话说清，而且强依赖刚才的上下文，就不要拆。

写作、改稿、聊天式迭代，当前 session 往往最顺。你刚刚的语气、偏好、修改方向，全都还热着。这时候切出去，不是提效，是打断节奏。

什么时候该开子 Agent

重点不是炫技，是把主线解放出来。

① 有一块明显可以独立出去的子任务

最典型的：查资料、扫网页、整理候选项。

比如你在写一篇 OpenClaw 教程，主线是在当前对话里定标题、定结构、定写法。这时候完全可以把"扫最近一周的外部讨论""整理官方文档里 sub-agent 的关键点""汇总 5 个真实使用场景"，单独丢给子 Agent。

为什么适合拆？因为这类任务边界清楚，结果可以回收。它只需要把砖搬回来，不需要参与主线节奏。

② 任务很慢，但你不想让主对话卡住

子 Agent 最直接的价值，其实是异步。

举个场景：

• 主对话在规划今天写什么

• 同时让它跑一个趋势扫描

• 再顺手查某个官方文档最近有没有更新

这些串行做，主线会一直在等工具结果，像堵车一样。子 Agent 的作用很舒服：主线继续聊，后台自己跑，跑完回来报。

③ 需要并行看多个方向，但最后只要结论

比如你想比较三个工具：

• A 能不能接微信

• B 的部署门槛怎么样

• C 最近社区热度有没有起来

这三个方向彼此独立，但最后你要的是一份判断。适合拆给不同子 Agent 去跑，再让主线统一收口做决策。

关键不是"多开几个更帅"，而是把并行搜索和统一判断分开。

这几种情况，别开子 Agent

说完适合的，再说最容易翻车的。

❌ 任务没拆清就急着分出去

很多人会这样下命令："你帮我开个子 Agent 去处理一下这个问题。"

问题是——"这个问题"到底是什么？做到什么程度算完成？结果用什么格式交回来？

子 Agent 不会因为名字里带"Agent"，就自动懂你的潜台词。派出去之前，至少说清三件事：

它要做哪一小块 → 做到什么程度算完成 → 结果用什么格式回来

❌ 特别依赖上下文的活也硬拆

改稿、润色、接着上文继续写……这些活很吃上下文。

虽然技术上能开子 Agent，但你得把前面几轮背景、你刚刚否掉了什么、你现在想保留什么节奏，全重新喂一遍。拆来拆去，不是省时间，是打断节奏。

❌ 把子 Agent 当长期角色来用

子 Agent 是临时派工，不是给你养长期员工。

如果你想要长期固定人格、长期固定技能、长期隔离会话历史——那你该考虑的是独立 Agent，不是子 Agent。这两个别混，混了以后很容易觉得"怎么每次又得重新说"。

独立 Agent：什么时候值得单独养一套

如果说子 Agent 是临时工，独立 Agent 更像长期岗位。

它有自己的 workspace、状态目录、session store，认证配置也按 Agent 隔离。这已经不是"多开一个聊天窗口"，而是多养一套独立的工作环境。

适合独立 Agent 的三种情况：

① 你真的有长期不同的身份分工

比如一个 Agent 专门做博客运营，一个专门做技术折腾，一个专门负责社群回复。这几类工作的语气、习惯、常用资料、敏感信息边界，可能完全不一样。你要的是长期隔离，不是临时借工位。

② 你希望不同工作流有不同记忆和规则

把所有事塞进同一个主 Agent，会话历史、工作区文件、长期记忆会越来越杂。写博客的规则、做运维的规则、社群回复的口吻，全搅在一起，早晚串味。

独立 Agent 的价值，就是把这几套东西天然隔开。

③ 你需要不同渠道绑定不同脑子

一个 Gateway 可以同时挂多个 Agent，每个 Agent 还能绑定不同渠道账号。如果你的需求已经走到多人、多身份、多渠道隔离，独立 Agent 就不是可选项，而是正解。

一张决策表，不用记那么多

决定因素其实就两个：

这是临时派工，还是长期分工？这件事强依赖当前上下文，还是可以独立成块？

把这两个问题问一遍，基本就不会乱。

最后

OpenClaw 的多 Agent 能力确实是亮点，但它的价值不在于"让界面上多几个名字"，而在于把复杂任务分层。

主线该做决策的，留在主线。适合独立查的，丢给子 Agent。需要长期隔离人格、工作区、账号和历史的，再去单独养独立 Agent。

顺序不能反。不然你会进入一种假忙状态：看起来开了很多 Agent，实际上只是把一个清楚的任务，拆成了几份沟通成本很高的小混乱。

记住这句话就够了：

小事接着聊，杂事拆子 Agent，长期角色养独立 Agent。

如果你现在卡在多 Agent 这块，就照着上面那张决策表过一遍，再看看自己的任务到底属于哪一类。很多时候不是 OpenClaw 不会干，而是任务一开始就放错了地方。