> ## Content Index > Fetch the complete content index at: https://tbbbk.com/llms.txt > Use this file to discover other available public pages before exploring further. # OpenClaw 子 Agent 怎么用（2026）：什么时候该继续聊，什么时候该拆出去 - URL: https://tbbbk.com/openclaw-when-to-use-subagents-2026/ - Published: 2026-03-23T14:53:21.000Z - Updated: 2026-03-23T14:53:21.000Z - Description: 很多人装好 OpenClaw 后就开始乱开子 Agent，结果越拆越乱。我把自己踩过的坑和官方文档对了一遍，写清楚当前对话、子 Agent、独立 Agent 到底该在什么场景下用。 - Author: TuBaiBai - Tags: 折腾日记, #Import 2026-07-20 07:13 这两天我在翻站里的搜索词，看到两条挺有意思：**openclaw 子agent**，还有**openclaw 切换agent**。 这两个词看着很像，实际问的不是一件事。 搜“子agent”的人，通常已经知道 OpenClaw 不止能一个脑袋干活，他真正想搞明白的是：**什么时候该把任务拆出去**。搜“切换agent”的人，更多是在问：**我现在到底该继续在这个对话里做，还是应该换一个独立的 Agent 来接手**。 我自己前阵子也一直在这个点上打转。刚开始玩多 Agent 的时候，很容易走两个极端：一种是什么都想开子 Agent，恨不得查个网页都分出去；另一种是明明任务已经很长、很乱了，还死扛在当前 session 里硬做，最后把上下文越聊越杂。 后来慢慢用下来，我的感觉其实很简单：**多 Agent 不是多开几个窗口，而是把不同类型的工作放到更合适的位置上。** 所以这篇我不打算再重复“怎么开启多 Agent”这种入门配置，也不准备写一堆参数说明。咱们就只聊一件事：**OpenClaw 里，当前对话、子 Agent、独立 Agent，到底分别适合什么场景。** ## 先把三个概念说清楚 OpenClaw 这套东西，官方文档其实讲得很清楚，但第一次接触的时候很容易被术语绕进去。我先用最直白的话重说一遍。 **当前对话**，就是你现在正在聊的这个 session。你发一句，它接着当前上下文往下做，适合连续追问、轻修改、顺着刚才的话继续往下推进。 **子 Agent（Sub-agent）**，可以理解成：**从当前任务里临时分出去的一个后台工位**。它有自己的独立 session，跑完以后再把结果回传回来。官方文档也是这个意思：子 Agent 是从现有 Agent 里派生出去的后台任务，结束后会把结果再汇报给发起者。 **独立 Agent**，不是“临时外包”，而是**另一套长期存在的脑子**。它有自己独立的 workspace、自己的 AGENTS.md / SOUL.md / USER.md、自己的会话历史，甚至可以有自己的渠道绑定。官方文档里讲得很明确：一个 Agent 不只是一个名字，而是一整套隔离开的工作区、状态目录和会话存储。 所以这三者最大的区别，不是“谁更高级”，而是： - 当前对话：继续用现在这颗脑子 - 子 Agent：临时借一个工位，干完回来汇报 - 独立 Agent：长期养另一颗脑子，专门负责另一类事 把这个关系想明白，后面的判断就顺了。 ## 什么时候继续在当前对话里做，不要乱开 Agent 很多人一看到多 Agent，就会自然觉得“拆出去肯定更专业”。这不一定。 如果任务本身还很短，或者你其实在做的是**连续追问**，那最省事的方式，往往就是继续在当前 session 里做。 比如这些场景，我基本不会开子 Agent： - 让它改一段提示词 - 让它补一句文案 - 让它继续刚才的文章提纲 - 让它根据你上一条消息再细化一步 - 让它解释刚才返回结果里的某个字段 这些任务有个共同点：**高度依赖当前上下文，而且动作很轻。** 这种时候你硬开一个子 Agent，反而会增加沟通成本。因为你还得重新把背景交代一遍，告诉它前面聊了什么、你现在要改哪一段、你到底想保留什么风格。原本一句话就能接着做的事，硬生生拆成了一次新的派工。 我自己现在有个很粗暴但挺好用的判断法： > 如果这个任务我用两三句话就能在当前对话里说清，而且它强依赖刚才的上下文，那就不要拆。 尤其是写作、改稿、聊天式迭代这类事情，当前 session 往往最顺。因为你刚刚的语气、偏好、禁忌、修改方向，全都还热着。这个时候切出去，不是提效，是打断节奏。 ## 什么时候该开子 Agent：重点不是炫技，是把主线解放出来 真正适合开子 Agent 的情况，我觉得主要有三个。 ### 1\. 你有一块明显可以独立出去的子任务 最典型的，就是**查资料、扫网页、整理候选项**。 比如你在写一篇 OpenClaw 教程，主线是你在当前对话里定标题、定结构、定写法。这时候你完全可以把“去扫最近一周外部讨论”“去整理官方文档里和 sub-agent 相关的关键点”“去汇总 5 个真实使用场景”这些事情，单独丢给子 Agent。 为什么这种适合拆？因为它们有个特点：**边界清楚，结果可以回收。** 你不需要那个子 Agent 跟你一起参与整篇文章的节奏，它只需要把一块砖搬回来就行。搬完砖，主线继续由当前 session 来收口。 ### 2\. 任务很慢，但你不想让主对话卡住 官方对子 Agent 的定位，本来就包括：**把研究、长任务、慢工具这些工作并行出去，不阻塞主流程。** 这个点其实特别实用。很多人把子 Agent 理解成“更聪明的分身”，其实它更直接的价值，是**异步**。 举个很现实的场景： - 主对话里你在规划今天博客写什么 - 同时你还想让它去跑一个趋势扫描 - 再顺手查一下某个官方文档最近有没有变 这些事如果都塞在当前对话里串行做，你会明显感觉节奏被拖住。主线一直在等工具结果回来，像堵车一样。这个时候子 Agent 的作用就很舒服：**主线继续聊，后台自己跑，跑完回来报。** 这类场景下，子 Agent 不是“可有可无”，而是真的很像一个靠谱的实习生。 ### 3\. 你需要并行看多个方向，但最后只要结论 这个在资料研究里尤其好用。 比如你想比较三个方案： - A 工具能不能接微信 - B 工具的部署门槛怎么样 - C 工具最近社区热度有没有起来 这三个问题彼此相对独立，但最后你要的是一份判断，不是三份散乱笔记。这时候就很适合把三个方向拆给不同子 Agent 去跑，再让主线把结果收回来，统一做决策。 这种用法的关键不是“多开几个更帅”，而是**把并行搜索和统一判断分开**。谁负责搜，谁负责拍板，要分开看。 ## 什么时候不要开子 Agent，不然只会更乱 说完适合的，再说最容易翻车的。 我自己踩过的坑，基本就这几种。 ### 第一种：任务根本没拆清，就急着分出去 很多人会这样下命令： > 你帮我开个子 Agent 去处理一下这个问题。 问题是，“这个问题”到底是什么？要查资料、写代码、整理文案，还是跑测试？做到什么程度算完成？结果要用什么格式交回来？你自己都没拆清，子 Agent 当然也只会一脸懵。 子 Agent 不会因为名字里带个 Agent，就自动懂你的潜台词。它本质上还是一个被派工的独立 session。你给的任务越像一张清楚的工单，它发挥得越稳。 所以真要派出去，至少把这三件事说清： - 它要做哪一小块 - 做到什么程度算完成 - 结果回来时你想看到什么格式 这比一句“你去看看”重要多了。 ### 第二种：特别依赖上下文的活，也硬拆 像改稿、润色、接着上文往下写、根据你刚才的语气继续聊天，这些事都很吃上下文。 虽然技术上也能开子 Agent 去做，但成本很高。因为你得把前面几轮对话的背景、你刚刚否掉了什么、你现在想保留什么节奏，全重新喂一遍。拆来拆去，最后省下来的不是时间，而是把原本流畅的工作流打断了。 这种任务最怕的不是“子 Agent 不会做”，而是**它做出来不像刚才那个你已经调顺手的脑子**。 ### 第三种：把子 Agent 当成长期角色来用 这也是一个很常见的误区。 官方文档里对子 Agent 的定义很明确：它是从当前运行里派生出来的后台任务，有自己的 session，跑完会回报结果。这个设计更像**临时派工**，而不是给你养一个长期驻场员工。 如果你想要的是： - 长期固定一个人格 - 长期固定一套技能和工作区 - 长期在不同渠道里负责某类工作 - 和主 Agent 保持真正隔离的会话历史 那你该考虑的不是子 Agent，而是**独立 Agent**。 这两个东西一定别混。混了以后最常见的结果就是：你一边觉得“怎么每次又得重新说”，一边又觉得“怎么这个子 Agent 没有我想象中那么稳定”。因为它本来就不是按长期角色设计的。 ## 独立 Agent 什么时候值得单独养一套 如果说子 Agent 是临时工，那独立 Agent 更像长期岗位。 OpenClaw 官方文档里把一个 Agent 的边界定义得很重：它有自己的 workspace、自己的状态目录、自己的 session store，认证配置也是按 Agent 隔离的。说白了，这已经不是“多开一个聊天窗口”了，而是**多养一套独立的工作环境**。 所以独立 Agent 最适合的，不是一次性拆任务，而是这种情况： ### 1\. 你真的有长期不同的身份分工 比如一个 Agent 专门做博客运营，一个 Agent 专门做技术折腾，一个 Agent 专门负责消息回复或社群。这几类工作的语气、习惯、常用资料、甚至敏感信息边界，都可能完全不一样。 这时候你要的是长期隔离，不是临时借工位。 ### 2\. 你希望不同工作流拥有不同记忆和规则 这个特别关键。 如果你把所有事都塞进同一个主 Agent，最后它的会话历史、工作区文件、长期记忆会越来越杂。写博客的规则、做运维的规则、社群回复的口吻，全都搅在一起。短期看省事，长期看很容易串味。 而独立 Agent 的价值，就是**把这几套东西天然隔开**。谁读什么文件，谁用什么人设，谁记什么历史，都可以独立管理。 ### 3\. 你需要不同渠道、不同账号分别绑定不同脑子 这个是多 Agent 文档里讲得很实在的一点：一个 Gateway 可以同时挂多个 Agent，每个 Agent 还能绑定不同的渠道账号，路由规则按绑定来走。 这意味着它不只是“一个人更高阶的玩法”，而是真的可以拿来做**多人、多身份、多渠道隔离**。如果你的需求已经走到这一步，那独立 Agent 就不是可选项，而是正解。 ## 我现在怎么判断：一张够用的决策表 如果你懒得记那么多，我把我自己现在的判断方式压成一张表： | 场景 | 更适合 | 原因 | | ---------------- | -------- | ------------------------- | | 继续改刚才那段文案、提纲、回复 | 当前对话 | 强依赖当前上下文，直接接着做最快 | | 查资料、扫网页、整理候选项 | 子 Agent | 边界清楚，结果可回收，适合后台并行 | | 长时间运行的研究、慢工具任务 | 子 Agent | 主线不用卡住，跑完再回报 | | 长期不同身份、不同工作流 | 独立 Agent | 需要独立 workspace、记忆、规则和渠道绑定 | | 多人共用一个 Gateway | 独立 Agent | 隔离会话和配置，避免串数据 | | 临时把一个大任务拆成几块并行处理 | 子 Agent | 典型派工场景，不需要长期保留身份 | 你会发现，决定因素其实就两个： - 这是**临时派工**，还是**长期分工** - 这件事是**强依赖当前上下文**，还是**可以独立成块** 只要把这两个问题问一遍，基本就不会乱。 ## 别把“能拆”误以为“都该拆” 我觉得这是很多人真正容易误会的地方。 OpenClaw 的多 Agent 能力当然是亮点，子 Agent 也确实很实用，但它们的价值不在于“让界面上多几个名字”，而在于**把复杂任务分层**。 主线该做决策的，就留在主线。适合独立查的，就丢给子 Agent。需要长期隔离人格、工作区、账号和历史的，再去单独养独立 Agent。 顺序不能反。 不然你会很容易进入一种假忙状态：看起来开了很多 Agent，实际上只是把原本一个清楚的任务，拆成了三四份彼此沟通成本很高的小混乱。 我现在反而越来越觉得，多 Agent 最值钱的地方不是“多”，而是**边界感**。什么该连续，什么该并行，什么该隔离，这三件事想明白了，OpenClaw 才会真的顺手起来。 ## 最后一句话，帮你记住 如果你还想把它压缩成一句最好记的话，我会这么说： > **小事接着聊，杂事拆子 Agent，长期角色养独立 Agent。** 差不多就是这个意思。 如果你现在正好卡在多 Agent 这块，建议你可以先把我前面那张决策表照着过一遍，再回头看看自己手上的任务到底属于哪一类。很多时候不是 OpenClaw 不会干，而是我们一开始就把任务放错了地方。 如果你还没配过多 Agent，本篇可以先当“用法判断”看。真要落到配置层面，可以接着看我之前写的这几篇： - [OpenClaw 多 Agent 配置指南：子 Agent、独立 Agent 和多模型分配](https://tbbbk.com/openclaw-multi-agent-config-guide/) - [OpenClaw 进阶配置教程：记忆系统、子 Agent、Cron 定时任务、Skill 开发](https://tbbbk.com/openclaw-advanced-config-guide/) - [OpenClaw 浏览器实战（2026）：直接和机器人说一句，它就会自己打开网页帮你整理信息](https://tbbbk.com/openclaw-browser-practical-guide-2026/) 这几篇连着看，基本就能把“怎么配”和“怎么用”两件事串起来了。