OpenClaw 多 Agent 配置指南：子 Agent、独立 Agent 和多模型分配

用 OpenClaw 大半年了，最开始就一个 Telegram bot，什么都往里扔——查资料、写周报、帮我盯着服务器、睡前随手聊两句。用着倒是挺顺手，但时间一长就发现一个问题：这个 bot 知道的事情太杂了。

有次朋友问我一个技术问题，我顺手让 bot 帮忙搜了一下。它回复里顺带了一句「根据你之前提到的那个副业项目……」，我当时脑子里咯噔一下。不是它做错了什么，只是那种感觉——私事和技术问题的上下文全混在一起——挺膈应的。

我就开始琢磨，能不能给不同场景各开一个 Agent，彻底隔离。查了官方文档，发现 OpenClaw 的多 Agent 确实能做到，但这里面有两种完全不同的玩法，很多人没搞清楚就动手配，结果绕了一大圈弯路。这篇就把两种方式说清楚，顺便讲一下怎么给不同 Agent 分配不同的模型。

两种多 Agent，用途完全不同

先把概念说清楚，不然后面配置步骤看了也是一头雾水。

子 Agent：临时工模式

子 Agent 是主脑临时派出去干活的进程。你跟主脑说「帮我同时搜一下这三个关键词的最新资讯」，主脑会拆分任务，同时派出三个子 Agent 并行去搜，搜完汇总结果给你。全程你只和主脑对话，子 Agent 是幕后的执行单元。

这种模式的特点：不需要额外配置任何东西，也不需要新的 Telegram bot，更不需要独立的 workspace。子 Agent 用完就销毁，没有记忆，跑完就消失。它只是主脑手上的工具，而不是另一个独立的 AI。

适合场景：任务量大、可以拆分并行的工作。比如同时处理多个文件、同时搜索多个主题、批量做某件事。日常用得最多的也是这种，因为完全不用折腾配置。

独立 Agent：分店模式

独立 Agent 才是真正意义上「另一个大脑」。它有完全隔离的 workspace，有自己的 SOUL.md 和 AGENTS.md，有独立的记忆系统，需要单独配一个 Telegram bot。两个 Agent 之间互相不知道对方的存在，没有任何共享。

适合场景：你真的需要在人格、上下文、记忆上彻底隔离的时候。比如一个 bot 管技术折腾，一个 bot 专门处理某类特定任务，各自有各自的人格和知识范围，互不干扰。

简单说：子 Agent 是临时工，独立 Agent 是另开一家分店。如果只是想让 AI 同时干多件事，用子 Agent 就够了，根本不需要折腾独立 Agent；只有当你确实需要人格隔离和记忆隔离，才值得花时间搭独立 Agent。

子 Agent 怎么用

子 Agent 最省事的用法就是什么都不配，直接在对话里描述需求，主脑会自己判断要不要派子 Agent。

举几个实际会用到的场景：

同时搜多个关键词：「帮我分别搜一下 Hetzner、Vultr、RackNerd 最近有没有促销活动，汇总给我」。主脑会派三个子 Agent 同时去搜，比串行快得多。

并行处理文件：「这个目录里有五个日志文件，帮我逐一分析有没有报错，整理成表格」。主脑同时派多个子 Agent 分别处理，最后汇总。

多任务并发：「帮我一边查一下 Oracle 免费套餐的最新政策，一边把我上周的折腾记录整理成博客大纲」，两件不相关的事同时进行，互不影响。

子 Agent 有几个限制要清楚：它是无状态的，每次派出去都是全新的，不会记得上次干了什么；它不能主动和你对话，所有结果都通过主脑转达；它也不能再往下派子 Agent，只有主脑有这个权限。

如果要跑比较耗时的任务，可以在 openclaw.json 里调大超时时间：

{
  "agents": {
    "defaults": {
      "subagents": {
        "runTimeoutSeconds": 300
      }
    }
  }
}

默认不限时，但任务复杂建议设一个合理上限，不然子 Agent 卡住了你也不知道。300 秒对大多数任务够用了。

踩坑记录：有时候描述的任务太模糊，主脑觉得不需要拆分，就不会派子 Agent。这时候可以明确说「请并行处理」或者「同时做」，效果更稳定。另外子 Agent 超时之后主脑会把已有的部分结果返回，而不是直接报错，所以看到结果不完整先别慌，检查一下是不是超时了。

独立 Agent 配置步骤

配独立 Agent 需要动四个地方：建 workspace、写配置文件、创建新 bot、改 openclaw.json。步骤不多，但每步都不能省。

第一步：创建独立的 workspace

每个独立 Agent 都需要一个完全隔离的 workspace 目录。主 Agent 用的是 ~/.openclaw/workspace，新 Agent 就建一个新目录，比如 ~/.openclaw/workspace-tech。

mkdir -p ~/.openclaw/workspace-tech

进去之后，至少要创建 SOUL.md 和 AGENTS.md。这两个文件定义了这个 Agent 的人格和工作方式，内容完全独立，不会和主 Agent 共享。

比如你想要一个专门处理技术问题的 Agent，SOUL.md 里可以写：技术氛围浓一点，回答直接不废话，遇到不确定的不要乱猜，直接说不知道。主 Agent 可以话多一点、随性一点——两个截然不同的人格，住在各自的目录里，互不干涉。

具体 SOUL.md 和 AGENTS.md 怎么写，可以参考进阶配置这篇，里面有完整模板，直接复制改一下就能用。

第二步：去 BotFather 创建新 bot

每个独立 Agent 必须对应一个独立的 Telegram bot，不能共用。原因很简单：Telegram bot 的消息是通过 token 来区分路由的，如果两个 Agent 用同一个 token，OpenClaw 没法判断这条消息该交给谁处理。

在 Telegram 搜索 @BotFather，发 /newbot，按提示起个名字，拿到新的 bot token 存好备用。

第三步：修改 openclaw.json

这是核心配置。打开 ~/.openclaw/openclaw.json，加上 agents、bindings、channels 三块：

{
  "agents": {
    "list": [
      {
        "id": "main",
        "default": true,
        "workspace": "~/.openclaw/workspace"
      },
      {
        "id": "tech",
        "workspace": "~/.openclaw/workspace-tech"
      }
    ]
  },
  "bindings": [
    { "agentId": "main", "match": { "channel": "telegram", "accountId": "default" } },
    { "agentId": "tech", "match": { "channel": "telegram", "accountId": "tech" } }
  ],
  "channels": {
    "telegram": {
      "accounts": {
        "default": { "botToken": "你的主bot token" },
        "tech": { "botToken": "新bot的token" }
      }
    }
  }
}

逐字段解释一下：

agents.list 是所有独立 Agent 的列表。id 是这个 Agent 的唯一标识，workspace 指向它的工作目录。default: true 表示默认 Agent，没有命中任何 bindings 规则的消息都走这个。

bindings 是路由规则，决定哪个 Telegram bot 的消息交给哪个 Agent 处理。上面的配置意思是：accountId 为 default 的 bot 收到的消息路由给 main Agent，accountId 为 tech 的 bot 收到的消息路由给 tech Agent。

bindings 的顺序很重要，OpenClaw 从上到下匹配，第一个命中的规则生效。如果你有更精细的规则（比如某个特定群组走某个 Agent），要放在通用规则前面，不然会被提前命中。

channels.telegram.accounts 里配置每个 bot 的 token，accountId 要和 bindings 里的 accountId 对应，名字一致就行。

第四步：验证配置

改完配置之后重启服务：

openclaw gateway restart

重启完用这个命令验证路由是否正确（更多 CLI 命令可以看CLI 命令速查）：

openclaw agents list --bindings

如果配置没问题，能看到每个 Agent 的 id 和对应的 binding 规则。这时候去 Telegram 分别给两个 bot 发消息，应该能看到不同的回复风格。

踩坑记录

有几个坑配的时候容易踩：

agentDir 冲突：OpenClaw 会给每个 Agent 在 ~/.openclaw/agents/<agentId>/ 下建一个状态目录，存 session 和认证信息。这个目录绝对不能让两个 Agent 共用，否则 session 会互相覆盖，表现是消息路由错乱、两个 bot 回复内容混淆。默认情况下每个 Agent 的 agentDir 根据 id 自动隔离，不要手动去改这个路径就没问题。

配完重启没生效：有时候 openclaw.json 格式写错了（JSON 不允许注释，结尾多了逗号），gateway 启动会静默忽略错误配置，表现是改了但没变化。配完先用 python3 -m json.tool ~/.openclaw/openclaw.json 验证一下格式，排除这个可能。

workspace 忘了初始化：新 Agent 的 workspace 目录如果没有 SOUL.md 和 AGENTS.md，Agent 启动后会以默认行为运行，没有你想要的人格。记得配完 workspace 后进去建好这两个文件再重启。

如果启动之后遇到报错，去这篇报错修复手册翻一下，常见的 spawn einval、command not found、control ui 这些问题基本都覆盖了。

不同 Agent 配不同模型

这个功能用好了能省不少 token。

默认情况下所有 Agent 用同一个模型，但其实不同场景对模型能力的要求差很多。处理复杂推理、写长文章、做代码审查，需要 claude-sonnet 这种重型模型；但日常的「帮我搜一下这个词」「把这段话翻译成英文」「总结一下这篇文章」，用 claude-haiku 完全够用，而且响应更快，消耗更少。

在 agents.list 里直接给每个 Agent 指定 model：

{
  "agents": {
    "list": [
      {
        "id": "main",
        "model": "github-copilot/claude-sonnet-4.6"
      },
      {
        "id": "tech",
        "model": "github-copilot/claude-haiku-4.5"
      }
    ]
  }
}

实际体验下来：haiku 处理日常问答的速度比 sonnet 快不少，轻任务用 haiku 是个很划算的选择。sonnet 留给真正需要推理的场景，比如写文章、分析问题、做技术方案。

子 Agent 默认继承主脑的模型，但如果在对话里明确说「用轻量模型帮我做这件事」，主脑也可以给子 Agent 临时指定一个不同的模型。

另外还有 gpt-4o-mini 这种选项，适合纯文本处理、格式转换这类极简任务，更便宜，响应也快。根据自己的使用习惯和预算来分配就好，没有固定答案。

配完之后的实际感受

配好独立 Agent 之后确实清爽不少。两个 bot 各自有各自的上下文，发给技术 bot 的问题它只用技术的角度回答，不会夹带其他场景的记忆；主 bot 那边也干净了，不会因为聊了某件事就影响其他对话的语境。

说实话，大多数人用 OpenClaw 其实用不到独立 Agent，子 Agent 并行处理任务已经能覆盖绝大多数需求。独立 Agent 更适合真的有「人格隔离」需求的场景，或者想给特定任务配专属 bot 的情况。如果你还没想清楚自己需不需要，先别折腾独立 Agent，用默认的单 Agent 跑一段时间再说。

如果你刚装 OpenClaw 还在磨合阶段，安装和 Docker 对比那篇可以看一下，宿主机直装和 Docker 各有利弊，选适合自己的就好。更多进阶玩法——Cron 定时任务、memorySearch、Skill 开发——可以去进阶配置指南翻一翻，单 Agent 能做的事其实已经很多了。