跳到主要内容

OpenClaw：多 Agent 方案

目录​

这一篇解决什么问题​

当你只有「一个 bot、一个会话」时，很多问题可以被忽略：人设混用、工具权限混用、上下文串台似乎只是「偶尔有点怪」。一旦你把 多个社交账号、多个工作域、多个风险等级 接进同一套 Gateway，就必须回答：这条入站消息到底该由哪个 Agent 处理？它能看到哪些记忆与工具？

本篇把 OpenClaw 语境下的 Multi-agent routing（官方 README Highlights 中的表述）拆成你能执行的工程方案：包括拆分原则、路由契约、与 main/沙箱策略的关系，以及与会话类工具（如 README Operator quick refs 中列出的 sessions_*）如何配合。
注意：具体配置键、默认值与 UI 流程以你当前版本及 Gateway configuration、Architecture 为准；本文提供的是决策框架，不是可逐字复制的配置模板。

OpenClaw 里「多 Agent」指什么​

在 OpenClaw 的产品叙事里，「多 Agent」通常不是指「同一个聊天窗口里塞多个模型人格」这种前端展示，而是指：在网关侧把不同入口（渠道、账号、对等方）映射到相互隔离的执行上下文——包括工作区与 per-agent 会话（官方 README 表述为 route inbound channels/accounts/peers to isolated agents (workspaces + per-agent sessions)）。

你可以用下面三条来理解它解决什么问题：

  1. 隔离提示与状态：不同 Agent 对应不同工作区与会话状态，减少「A 项目的术语污染 B 项目」的提示污染。
  2. 隔离权限：不同 Agent 可以有不同的工具策略；与 main / 沙箱策略叠加时，决定工具是在主机上跑还是在 Docker 沙箱里跑（见 README Security model 与 Docker sandboxing）。
  3. 隔离运营责任：例如「对外客户支持 bot」与「只给自己用的私聊 bot」本不应共享同一套工具白名单。

为什么要拆成多个 Agent​

是否拆分，取决于你是否同时满足以下任一条件：

  • 多工作域：工作与生活、公司与个人、客户 A 与客户 B，需要不同的系统提示、文件边界与工具边界。
  • 多风险等级：有的入口需要浏览器/执行命令，有的入口只允许读文档与发消息；混在一个 Agent 里会把「低风险入口」也抬到「高风险默认」。
  • 多运营角色：有人负责配置、有人负责值班、有人只负责审批；拆分后便于把变更与事故责任对齐到具体入口。

如果以上都不成立，强行多 Agent 只会增加维护成本：你会在「路由表、工作区、skills 副本、配置变更」之间来回复制粘贴，最终仍然串台。

什么时候「不拆」更合理​

  • 你只有单一用途、单一渠道、且工具权限长期稳定。
  • 你的团队还没有能力维护「路由表 + 权限矩阵 + 变更评审」三件套。

此时应优先把 单 Agent 工作区（AGENTS.md / SOUL.md / Skills）写清楚，再评估拆分。

典型拆分维度与落地示例​

下面给出常见拆分维度。每个维度都要回答：入站特征是什么、如何识别、路由失败时默认落到哪里。

拆分维度入站特征（示例）设计意图你需要额外写清的事
按渠道Telegram vs Slack vs WebChat不同渠道的消息格式、提及规则、@ 规则不同渠道是否允许同一用户跨渠道续聊
按账号/工作区两个 Telegram bot token对外支持 vs 对内工具两个账号是否允许共享同一用户白名单
按对等方/群组DM vs 群；群 ID群聊只读/只回答被 @群消息是否进入长会话还是短会话
按风险仅私聊可执行命令 vs 群聊只读降低误触发群聊里如何拒绝执行类工具

落地示例（叙事级，不是配置照抄）：

  • 场景 A：工作/生活分离：给工作 IM 与私人 IM 各走一个 Agent，工作区里放项目文档与代码工具；生活区只保留日历、阅读、轻量工具。这样即使模型误调用工具，也不会在「生活入口」触发高风险文件操作。
  • 场景 B：客户支持 vs 内部运维：客户支持 Agent 只允许读知识库与创建工单类工具；内部运维 Agent 才允许 SSH/脚本类工具（若你确实提供）。两者绝不应共享同一套工具默认。

路由与隔离：你需要提前写清的契约​

多 Agent 的本质是：把「身份 → 会话 → 工具策略」写成可维护的契约。建议在评审文档里固定以下字段（用你们自己的表头即可）：

  1. 入口标识：渠道名、bot 账号、是否 DM、群 ID 等。
  2. 路由键：官方用哪些字段做路由，需对照 Gateway configuration 与你版本的行为。
  3. 目标 Agent：对应 workspace、默认会话策略、是否允许跨会话引用。
  4. 工具白名单：浏览器/终端/文件/外部 API 分别是否允许。
  5. 失败策略：匹配不到路由时，是拒绝、进入安全默认 Agent，还是进入人工队列。

把「失败策略」写清楚非常重要：路由失败如果默默落到 main，你可能把高风险能力暴露给错误入口。

main 会话与非 main：权限与安全含义​

README 的 Security model 对很多团队是「第一次读觉得夸张，第二次读觉得必须」的段落：默认情况下，main 会话的工具可能直接在主机上运行——这意味着在个人使用场景里方便，但在「多人/多入口」场景里极其危险。

与多 Agent 方案强相关的一点是：官方提到可对 non-main 会话使用更强的沙箱隔离（例如 agents.defaults.sandbox.mode: "non-main" 这类方向，详见 README 与 Docker sandboxing）。工程上你可以这样理解：

  • main 往往代表你的「高信任主会话」：适合你自己单人使用、且你能承担主机侧执行风险。
  • 对外入口尽量落到 non-main 或受限会话：让工具在更窄的环境里跑，哪怕牺牲一点效率。

多 Agent 并不是自动等于安全：如果你把多个对外入口都映射到「高权限会话」，只是把一个风险拆成多个名字而已。

与会话工具协同：sessions 家族在干什么​

README Operator quick refs 列出 sessions_list、sessions_history、sessions_send 等会话工具。它们的意义是：让 Agent 在「多会话并存」时仍能发现、检索、跨会话协作——但这也意味着工具权限越大，越需要防止被滥用（例如向错误会话发送敏感内容）。

建议你为团队写一份「会话工具使用规范」，至少包含：

  • 什么情况下允许 sessions_send：是否需要人工确认或二次令牌。
  • history 的脱敏规则：是否允许把客户对话摘要进内部会话。
  • 审计：谁能在日志里看到这些跨会话动作（见 Logging）。

编排模式：从「单主多辅」到「按渠道分账」​

模式 1：单主多辅（一个主 Agent + 多个受限入口）​

适合：你个人使用为主，偶尔给同事开一个只读入口。
要点：主会话拥有完整工具；辅助入口只读或只允许特定工具。

模式 2：按渠道分账（每个渠道一个 Agent）​

适合：渠道差异大、你希望配置完全隔离。
代价：Skills 与提示词可能要维护多份；需要建立「共享技能库」的同步策略。

模式 3：按客户/项目分账（强隔离）​

适合：你确实在做对外支持或多项目并行。
要点：工作区边界要硬，不要把「客户 A 的文件路径」写进可被客户 B 入口触发的技能。

反模式与常见失败​

  • 反模式 1：为了酷而拆：路由复杂、但每个 Agent 的工具与白名单相同 → 只增加运维负担，没有降低风险。
  • 反模式 2：把多 Agent 当权限系统：不在网关层做配对/白名单/DM 策略，只靠提示词要求模型「别乱来」→ 必然翻车。DM 安全默认值见 Security。
  • 反模式 3：跨 Agent 共享敏感记忆：如果工作区与技能里写了密钥、个人信息，却在多个入口复用，隔离形同虚设。
  • 反模式 4：忽略升级后的行为变化：OpenClaw 迭代快，路由与默认策略可能随版本调整；升级后必须跑 openclaw doctor 并阅读 Updating。

上线检查清单（可打印）​

检查项通过标准（示例）
路由表每个入口都有明确目标 Agent；未命中策略明确
工具白名单对外入口默认更窄；高风险工具需审批或禁用
沙箱non-main 是否覆盖所有对外入口（按你的策略）
DM 安全pairing/allowFrom 与团队流程一致；doctor 无高危提示
会话工具sessions_* 的使用边界写成文档
回滚能一键回到上一版配置与路由

路由表模板（团队可直接复制扩展）​

下面是一张「叙事级」模板，用于评审会议；列名与字段请按你组织习惯调整，并与 Gateway configuration 对齐。

入口 ID渠道/账号入站类型（DM/群）路由键（概念）目标 Agent / Workspace工具白名单摘要失败回落
E-001Telegram bot ADM…agent-personal读文件+搜索拒绝
E-002Slack workspace X群…agent-work浏览器+工单安全默认

填写时务必写清两件事：

  1. “路由键”到底用什么字段识别：是用户 ID、群 ID、还是账号 ID？不同渠道字段含义不同，混用会导致误判。
  2. 失败回落的语义：拒绝、静默、还是转人工？不要默认“悄悄落到 main”。

与会话工具相关的“数据最小化”说明​

sessions_history 可能包含敏感对话片段。建议你在规范里明确：

  • 默认最小拉取：只拉必要轮次，避免把整段客户对话复制到内部会话。
  • 脱敏规则：手机号、邮箱、订单号等字段是否在写入另一会话前必须打码。
  • 保留期限：历史在本地保存多久、如何清理（这与你的合规策略相关，OpenClaw 不替你决定）。

监控与告警（建议最低集）​

即使你是个人使用，也建议至少做“可观测”：

  • 进程存活：Gateway 异常退出是否能被 systemd/launchd 拉起；退出频率是否异常。
  • 工具失败率：短期飙升往往意味着模型开始乱调用或外部 API 变更。
  • 入站速率：DM/群消息是否被异常刷取（可能是 spam 或脚本攻击）。

日志入口见 Logging。

原文与延伸阅读​