一台龙虾跑多个 agent:工作和私人分开怎么配

最小的一份配置长这样

下面是按官方示例简化的路由片段，假设你已配置 personal 和 biz 两个 WhatsApp 账号；它不是完整配置，也没有启用安全隔离：

{
  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 的 key 就是 agentId。这里的 home 和 work 必须与 binding 的 agentId 一致；写完用 openclaw agents list --bindings 对一眼两边的拼写。
• default: true 标在其中一个 agent 上。它是兜底的那个。
• bindings 是个数组,每一条是一次分派。形式固定:哪个 agentId,匹配什么 channel 和 accountId。

不同 workspace 只把默认工作目录分开：它是工具的默认 cwd，工具权限允许时，绝对路径仍可能访问另一边或宿主机其他文件，所以分路径算不上保密措施。两个 agent 也不要共用 agentDir。

agent 之间怎么互相派活：两个会话工具和三道控制

当前官方文档有 subagent 和 team 预设，可由协调者把任务交给研究、写作、复核等成员；只配置 entries 和 bindings 不会自动生成这套流程。派活用的是内置的会话工具，会话工具文档里和委派直接相关的是这两个：

• sessions_send：让同一网关上的另一个会话跑一轮，可以等它回复。对方的回复只回给请求方一次，要接着往下说就再发一次。
• sessions_spawn：开一个隔离的子 agent 会话，在后台干活。

两个工具都受当前工具 profile 和 allow / deny 策略管，coding 和 messaging 这两档 profile 里带着它们；full 不按 profile 筛选，也有；minimal 没有。想让一个 agent 能找另一个帮忙、又不把会话历史放开，官方配置文档给的示例是这样（示例里两个 agent 叫 specialist 和 ops）：

{
  tools: {
    agentToAgent: { enabled: true, allow: ["specialist", "ops"] },
    sessions: { visibility: "agent" },
  },
  agents: {
    ownership: "explicit",
    entries: {
      specialist: {
        tools: { agentToAgent: { send: ["ops"] } },
      },
      ops: {
        tools: { agentToAgent: { send: [] } },
      },
    },
  },
}

照这份配置，specialist 可以用 sessions_send 找 ops，并收到那一轮的回复；ops 写的是 send: []，不能主动发起普通的跨 agent 发送；两边都读不到对方的会话历史。调用时直接写目标 agent，不用先列出对方的会话：

{ "agentId": "ops", "message": "Please check the service status." }

这个调用由 agent 自己发出，你在对话里说清楚交给谁、交什么。文档同时提醒，放行发送等于允许对方 agent 按请求去做事，目标 agent 的工具和指令要按“会收到别人的请求”来配。

跨 agent 的三道控制各管一段：

• subagents.allowAgents 限制 sessions_spawn 能把子会话开到哪些 agent 名下：默认只能开在自己这个 agent 下，["*"] 表示任何已配置的 agent；相关工具也要在工具策略里放行。
• tools.agentToAgent 默认开启；省略或留空 allow 不限制 agent 配对。限制参与者时需列出请求方和目标方，普通跨 agent 访问可用 enabled: false 关闭。
• tools.sessions.visibility 控制会话可见范围。关闭普通跨 agent 访问不等于禁止所有子会话访问：在 tree 或 all 可见范围下，请求者自己的原生 subagent 和 ACP 子会话仍有可达路径。

2026.9.2 起 Swarm 默认开启，用来并发编排多个子 agent；之前显式关掉的设置和工具限制照旧保留。2026.9.8 改了 agent 互相求助时的回复规则：结果只回给请求方一次，REPLY_SKIP 和 ANNOUNCE_SKIP 不再隐藏回复，Doctor 会更新旧设置并保留群聊里的静默。自己写过工作流的，升级前看《OpenClaw 2026.9.8 更新内容与升级失败的处理办法》。

会话记录各自存放，默认设置下其他 agent 仍读得到，收窄的写法在下一节。工作与私人数据要严格分离时，按官方建议拆成独立网关，并配合操作系统账号、主机权限或独立主机；共享目录和插件存储也要另查。

agent 之间默认能互相读会话，想分开要改 tools.sessions.visibility

2026.9.2 的更新日志把会话工具的默认可见范围改成全部会话，普通的 agent 间互访同时默认开启。按会话工具文档，默认值 all 之下，没进沙箱的会话可以跨 agent 列出、读取、搜索网关上的其他会话，给它们发消息、查看状态，其中可能包含其他用户的对话记录。开头那份配置没写这一项，home 和 work 就落在默认值上：work 的会话工具够得着 home 的会话。

工作和私人要分开，把它收到 agent：

{
  tools: {
    sessions: { visibility: "agent" },
  },
}

这一段并进 openclaw.json 最外层那对花括号里，和 agents、bindings 平级；配置里已经有 tools 的，把 sessions 加进现有的 tools，不要再写第二个 tools。

agent 范围不含归另一个 agent 所有的子会话；靠原生 subagent 或 ACP 子会话派活的，文档建议显式写 tree，或者留在 all 再用 tools.agentToAgent 管：enabled 默认是 true，设成 false 关掉普通的跨 agent 访问；allow 限定哪些 agent 可以互访，请求方和目标方都要列进去，省略或留空等于不限制。

把可见范围收到 self、tree 或 agent 以后，还要让某个 agent 给另一个发消息，在 agents.entries.<agentId>.tools.agentToAgent.send 里列出目标，这只放行发送，列表、历史、搜索和状态仍然不开放；写成 [] 则拒绝普通的跨 agent 发送；全局的 tools.agentToAgent 限制对它照样生效。

进了沙箱的会话默认只够得着自己派生出的那棵子树。改完先跑 openclaw config validate，再让 work 这个 agent 列一次会话：范围收窄以后，会话工具返回的清单里只剩它自己这个 agent 的会话，并带一段说明当前生效范围的 visibility 信息。/tools 看的是工具有没有被 profile 或策略拿掉，看不出可见范围。

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

支持继承的字段可从 agents.defaults 取默认值；default: true 等成员属性写在具体条目上，不要把整张表原样搬进 defaults：

skills 控制的是注入哪些使用说明：即使写了 []，已授权的 exec 等工具仍可能可用；按 agent 的显式 skill 列表会替换默认列表。权限设置看官方工具策略；说明加载与安装见Skills 入门。

模型可按任务需求分别选择，见模型选型。认证资料也能按 agent 管理。独立 OAuth 账号应在对应 agent 下登录；官方还描述了次 agent 凭证失效时读取默认 agent 同 profile 凭证的路径，不能仅凭目录分开就认定账号绝不共用。账单仍取决于实际凭证和服务商账号。记忆文件也跟着各自的工作区走，文件位置和查看、删除的命令见记忆存在哪，怎么查看和删除。

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

bindings 决定入站消息归属。格式错误可能被校验拒绝；格式合法但匹配条件写错，则可能把消息交给非预期 agent。这两种情况要分别检查。

示例按 match.channel 和 match.accountId 分流；也可按更具体的 peer 等条件拆分同一账号的会话，不要求一定有两个渠道账号。多个匹配字段需同时满足，同一优先级有多条命中时取配置中靠前的一条。

改完 bindings 这样查：

• 运行 openclaw config validate，再用 openclaw agents list --bindings 看 agentId 与实际绑定对不对得上。
• binding 省略 accountId 只匹配默认账号；"*" 才是全账号匹配。哪个 agent 兜底要写明，建议给它保守的权限。
• 发一条不含敏感信息的消息，到日志里看是哪个 agent 接的；光看工作区有没有新文件判断不出来。

从单 agent 自动回复拆分时，渠道登录资料仍放在渠道配置中，binding 只引用账号并指定 agent；不要把凭证搬进 binding。

改完要不要重启？看具体字段和重载模式

据官方热重载说明，有效的 agents、bindings、模型及大多数工具配置通常不需要重启网关；这不代表所有正在执行的任务或既有环境会立即切换。修改后先看校验结果。

gateway.reload.mode 当前有两档：

• hybrid 默认开启。可热应用的改动直接应用，需重启网关的改动自动安排重启；热应用也可能重启渠道或插件子系统。
• off 仍监听并验证配置。运行时应用延至下次手动重启。

channels.* 能不能热更新，看具体字段和已加载的插件。gateway.* 里，认证模式不变时轮换 token/password 可以热应用，端口、bind、认证模式、TLS 要重启。按最长匹配的字段规则判断；无效的改动会被跳过、继续用上一份配置，所以改完要再确认新值已经生效。

non-main 到底关的是哪些会话

官方模式说明中的 non-main 是把每个 agent 自己的 main 会话之外的会话放进沙箱。home 和 work 各有 main 会话；设全局 non-main 不能保证 work 的全部工具执行都进沙箱。

如果 work 要处理陌生附件或脚本，应在 agents.entries.work.sandbox.mode 明确设 "all"。scope 另管沙箱环境复用，默认 agent；session 按会话分，shared 共用环境。角色强制沙箱策略还可能进一步收紧这些行为。

启用前另查后端与访问范围：

• 普通 agent 的 sandbox.mode 默认 off。角色策略要求沙箱的会话是例外。Docker/Podman 需准备容器运行时和镜像；SSH 后端看的是远端环境要求。
• Docker 默认无出网、根文件系统只读，workspaceAccess 默认 none。它仍可使用私有沙箱工作区。这几条是容器后端的默认值，SSH 等远程后端另算。

详见沙箱教程。即使 mode all，还要检查可写挂载、工具策略、会话通信和 elevated 宿主执行通道；网关进程不会因此自动进入工具沙箱。

多开一个 agent 的代价：调用成本、上下文流转和路由检查

每个 agent 各带一份上下文和提示，委派一次多一轮调用，这是多出来的调用成本；上下文拆小、轻活换便宜模型，又会省回一些。建议拆之前记下用量，拆完对比。

两个 agent 不共用同一段当前对话，但默认设置下互相读得到对方的会话（见上文），也能接收另一边交回的成果。哪些可以共享、哪些不许传，用 tools.sessions.visibility 和 tools.agentToAgent 落到配置里。

配置加载成功以后，用一条测试消息和一个不碰敏感文件的任务，分别看消息落到哪个 agent、命令是不是在沙箱里执行。

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

要按账号分派消息，或者给某一摊活单独的模型、权限，就拆成两个 agent；只是任务类型不同，一个 agent 就够。文件要保密的，拆完还得配沙箱和工具权限。

常见问题

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

可能。workspace 只是默认工作目录，不是文件访问安全边界；不同路径不阻止工具访问其他目录。需要限制某个 agent 时，为它配置 sandbox.mode: all，并检查工具权限、挂载和宿主执行通道。

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

不用买两份。API 按调用量计费，不按 agent 个数：两个 agent 各带上下文、互相委派会多花一些，任务拆小或轻活换便宜模型会少花一些，以服务商账单上的实际用量为准。

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

可以，用内置的会话工具：sessions_send 让另一个 agent 的会话跑一轮并把回复带回来，sessions_spawn 开一个后台子会话。sessions_spawn 的目标受 subagents.allowAgents 限制，默认只能开在自己这个 agent 下；跨 agent 发送受 tools.agentToAgent 和 tools.sessions.visibility 管，可见范围收窄以后要在 agents.entries.<agentId>.tools.agentToAgent.send 里列出目标。只添加 entries 和 bindings 不会自动形成协作流程。

消息落到错的 agent 上了，怎么查？

先运行 openclaw config validate 检查配置，再用 openclaw agents list --bindings 看 agentId、渠道、账号及更具体的 peer 等规则有没有写错。同一优先级多条命中时取配置中靠前的一条。然后发一条不含敏感信息的测试消息，到日志里看是哪个 agent 接的。

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

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

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

记忆文件跟着各自的工作区走，工作区分开就是分开的。会话记录也各存各的，但默认设置下彼此读得到：2026.9.2 起会话工具默认对全部会话可见，没进沙箱的会话可以跨 agent 列出、读取和搜索会话。把 tools.sessions.visibility 设为 agent 可限制在同一 agent 内；共享文件及插件存储也需另查。需要严格分离时，应使用独立网关，并另设操作系统或主机边界。