进阶 · 配置

一台龙虾跑多个 agent:让工作的那个和私人的那个彻底分开

钳叔 · 龙虾AI 编辑部 · 2026-09-01 发布 · 2026-09-01 更新 · 约 6 分钟

先给结论:龙虾AI 支持在同一台机器上跑多个互相隔离的 agent,靠的是 ~/.openclaw/openclaw.json 里的两块配置——agents.entries 定义有哪几个 agent,bindings 决定哪条消息交给谁。官方文档对这个功能的原话是「Run multiple isolated agents with separate workspaces and sessions.」,关键词是 isolated,不是 collaborate。这篇讲怎么配、以及动手之前该先想清楚哪几件事。还没装的先看安装教程。

最小的一份配置长这样

官方给的最小例子只有两层结构,短到可以直接抄:

{
  agents: {
    defaults: { workspace: "~/.openclaw/workspace" },
    entries: {
      home: { default: true, workspace: "~/.openclaw/workspace-home" },
      work: { workspace: "~/.openclaw/workspace-work" },
    },
  },
  bindings: [
    { agentId: "home", match: { channel: "whatsapp", accountId: "personal" } },
    { agentId: "work", match: { channel: "whatsapp", accountId: "biz" } },
  ],
}

逐块拆开看:

• agents.defaults 是公共默认。写在这里的东西,entries 里的每个条目都继承;某个条目要不一样,自己再写一遍覆盖掉。
• agents.entries 里每多一个条目就是多一个 agent。这里最容易看漏的一点:条目的 key 本身就是 agentId。上面的 home 和 work 不是随便起的注释名,后面 bindings 里的 agentId 就得跟它逐字对上,拼错一个字母,那条路由就等于没写。
• default: true 标在其中一个 agent 上。它是兜底的那个。
• bindings 是个数组,每一条是一次分派。形式固定:哪个 agentId,匹配什么 channel 和 accountId。

这个例子里两个 agent 只差一个 workspace 路径,却已经把最要紧的事办了:工作那边攒下的文件,私人那边看不见。

先划一条边界:它们不会互相派活

这条得放在前面说,因为从别的 AI 框架过来的人几乎都带着相反的预期。

截至 2026-09-01,官方配置文档里没有任何关于 agent 之间互相委派、子 agent、或者 agent 到 agent 通信的内容。没有「主管 agent 把任务拆给下属」,没有消息总线,也没有共享的黑板。多 agent 在龙虾这里的含义是横着切,不是竖着分层——几个各管一摊、互不通气的独立个体,由 bindings 把外面来的消息分给它们,仅此而已。

所以下面这类念头,现在都落不了地:

• 让 work 那个 agent 查完资料,把结论丢给 home 那个继续写。
• 配一个「调度 agent」,让它决定这活该谁干。
• 指望两个 agent 共享同一份对话记忆,你在这边说过的话那边知道。

把预期先调对,后面配起来就不会拧巴。你要的如果是任务编排,那不是 agents.entries 该解决的问题;你要的如果是把身份、数据和权限切干净,那它正好对口。

一个 agent 能单独持有哪些东西

隔离到底隔了什么,列个表比讲一堆抽象话清楚。左边这些都能写在 agents.defaults 里当基线,也能在某个 agents.entries.* 上单独覆盖:

最值得先动的是 skills。基线设 [],然后按 agent 一个一个加——私人那个可能只需要读日程,工作那个才需要碰仓库和文件系统。Skills 那篇讲了怎么挑,这里只补一句:能力清单按 agent 分开写,比全局装一堆再想办法约束省事得多。

模型也一样。两个 agent 的活性质不同,没必要都挂同一个模型;贵的那档留给真需要长链推理的那一个。怎么挑看模型选型那篇。顺带提醒一句:密钥是按服务商命名的(比如 ANTHROPIC_API_KEY),不是每个 agent 一个 key,所以「换模型」和「换账单主体」是两码事,别指望靠分 agent 来分账。

bindings:按渠道加账号分派,配错了消息就落到别人身上

bindings 是整套配置里最容易出事的一块,因为它错了不会报错,只会安静地把消息送错地方。

匹配的维度是两个:match.channel(哪个渠道)和 match.accountId(哪个账号)。也就是说,分流的前提是你在同一个渠道上确实有两个账号,比如一个私人号一个业务号。上面那个例子里 personal 和 biz 是两个 WhatsApp 账号,分别绑到 home 和 work。

三个容易踩的地方:

• agentId 必须和 entries 的 key 完全一致。写了 agentid、多个空格、或者用了你脑子里那个「工作助理」的中文名,这条 binding 就匹配不上任何 agent。
• 没被任何 binding 命中的消息,归 default: true 那个。按这个语义往下推一步:兜底的那个 agent 应该是权限最小、最保守的那个,而不是最能干的那个。因为落到它头上的,恰恰是你没预料到的来源。这一步是从配置语义推的,不是文档原文,自己配的时候留个心眼。
• 改完先小范围试。拿业务号发一条无关痛痒的消息,看它是不是在 work 的工作区里留下痕迹。这一步比事后从两个工作区里往回捞文件便宜。

如果你本来就是照着自动回消息那篇配的单 agent,拆成两个的时候要记得:原来那份配置里跟渠道账号绑定的部分,现在得挪到对应的 binding 上去,不能两边都留一份。

改完要不要重启?绝大多数不用

直接说结论:改 agents.entries、改 bindings、换模型、调沙箱,全部热生效,不需要重启网关。这一点值得单独点出来,因为它把「先加一个 agent 试试」的门槛降了不少——存盘就算数,配得不满意改回去也是存盘就算数,不用为了试一个路由去重启一次服务。

热重载本身有两档:

• hybrid 是默认值。安全的改动即时热生效,关键改动它自己会重启。也就是说你什么都不用配,热重载就已经在了。
• off 关掉文件监听。改了不当场算数,要等下次手动重启。配多 agent 这种需要来回试的活,别关。

热生效那一大类里,跟这篇有关的全在:agents、bindings、models、routing、skills、tools、mcp、session、channels.*。

要重启的只有几摊,记住这句就够:gateway.* 全家(端口、bind 地址、认证、TLS、HTTP、push、tailscale),外加 discovery、browser、plugins.load、plugins.installs。这条对读过沙箱那篇的人格外相关:那篇讲的网关认证正好落在要重启的一边——把监听地址从本机改成对外、或者补上网关 token,光存盘是不够的,得让网关真的重起来。

non-main 这个沙箱档位,天生是给分工用的

sandbox.mode 有三档:off、non-main、all。中间那档的语义正好是主 agent 之外的全部关进沙箱——它就是为多 agent 场景准备的。

对应到实际用法:你天天用、需要它真的动本机文件的那一个留在外面,其余那些干脏活的(抓网页、跑陌生脚本、处理别人发来的附件)一律进沙箱。比全局 all 少牺牲一点方便,比 off 强出一大截。

两个前提别漏:

• 沙箱默认是关的。官方原话是「Sandboxing is off by default」,不动配置就一档隔离都没有。而且启用前要先构建镜像,不是拨个开关就有。
• 一旦打开,里面的默认值最紧。不出网(network 默认 none)、根文件系统只读(readOnlyRoot: true)、也不挂 agent 工作区(workspaceAccess 默认 none)。这意味着进了沙箱的那个 agent,一开始什么都干不成,要按需一项项放开。

细节和整套放开顺序在沙箱那篇里,这里只强调一个组合拳:sandbox.mode 设 non-main、scope 设 agent,再给每个 agent 各自的 workspace——文件层面和进程层面就都切开了,不是只切了一半。

要泼的冷水:多开一个 agent 是要花钱的

配置就那几行,代价却不在配置里。

第一,token 只会更多。按用量计费的 API 是按 token 算钱,不按 agent 数量算——但两个 agent 各跑各的会话,系统提示、上下文、工具描述都得各自再来一遍。同样的活分给两个 agent 干,总消耗只会往上走。真要控成本,得靠给便宜那档 agent 换模型,不是靠少配几个,思路参考Opus 5 那篇的成本账。

第二,磁盘和会话是各自一份的。每个 agent 一个工作区,缓存、中间产物、日志都是独立的。跑在小硬盘的云主机上尤其要留意,别等它写满了才发现。

第三,隔离意味着不共享上下文——这是目的,不是 bug。新手最常见的误会就在这:以为配在同一个 agents 下面它们就互相知道。不知道。你在 work 那边讲过的项目背景,home 那边完全没听说过,你得再讲一遍。觉得这很烦,说明你要的其实是一个 agent,不是两个。

第四,配错的成本是隐性的。沙箱配错了它跑不动,你当场就知道;bindings 配错了它照跑不误,只是消息落进了另一个工作区。前者当场暴露,后者可能几周后才被发现。

什么时候值得配两个,什么时候别折腾

给一个简单的判断标准:如果两摊活对应的是两个不同的账号、或者你不希望它们的文件互相看见,就分;只是任务类型不同,不分。

要动手的话,顺序是:先在 agents.defaults 把公共基线写好(工作区根、skills: []、沙箱设 non-main),再在 entries 里加第二个条目、给它单独的 workspace,最后才写 bindings。反过来先写路由,你会对着一条匹配不到任何 agent 的 binding 发呆。三步都在热生效的范围里,存盘就能试,不用重启网关,所以别一次写完再验,每加一层就试一次。

上面这些键名和取值,是 2026-09-01 对着官方配置文档整理的。这个项目改得很快,键改名、加取值、调默认值都发生过,动手前请以你装的那个版本的配置文档为准,对着网关配置文档再核一眼。某个字段的实际行为拿不准,直接去 GitHub 仓库翻源码和 issue,比猜快。

常见问题

两个 agent 会不会互相看到对方的文件?

取决于你把 workspace 写成什么。给两个条目写不同的路径,文件就是分开的;图省事都留着 agents.defaults 里那个公共路径,那它们其实共用一个工作区,谈不上隔离。想切得更彻底,再配合 sandbox.mode 设 non-main,让主 agent 之外的都进沙箱。

配多个 agent 是不是要付两份 API 钱?

不是按 agent 数量收费,按用量计费的 API 算的是 token。但两个 agent 各跑各的会话,系统提示和上下文得各自再来一遍,同样的活分开干,总消耗只会更多。真想省,是给不吃力的那个 agent 换便宜档模型,不是少配几个 agent。

能不能让一个主 agent 把活派给另一个 agent?

截至 2026-09-01 不行。官方配置文档里没有 agent 之间委派、子 agent、或者 agent 到 agent 通信的任何内容。这里的多 agent 是横着切成几个互不通气的独立个体,由 bindings 分派外面来的消息,不是一个主管带几个下属。要做任务编排,得另想办法。

消息落到错的 agent 上了,怎么查?

先看 bindings 里的 agentId 和 agents.entries 的 key 是不是逐字一致——拼错了那条路由等于没写,消息会落到标了 default: true 的那个 agent 身上。其次核对 match 里的 channel 和 accountId 是不是你实际在用的那个账号。改完拿一条无关痛痒的消息试一次,看它在哪个工作区留下痕迹。

两个 agent 一定要用不同的模型吗?

不用。model.primary 和 model.fallbacks 能按 agent 覆盖,但那是个选项不是要求。不写就继承 agents.defaults 里的公共值,两个 agent 挂同一个模型完全没问题。真要分开配,通常是因为一个干重活一个干轻活,成本上不划算才换。

配了两个 agent,它们会记得对方聊过什么吗?

不会,而且这正是隔离的目的。它们各自有各自的会话,你在工作那个 agent 面前交代过的项目背景,私人那个完全没听说过,得重新讲一遍。要是你觉得这件事很麻烦,说明你需要的其实是一个 agent,不是两个。