OpenClaw 多智能体设置，包含多个 AI 助手

优质文章学习记录

— 21 min read

OpenClaw 支持在一个 Gateway 进程内运行多个代理，每个代理都可以像自己的助手一样运行，拥有自己的文件、内存、身份验证和工具。

本指南从实际角度介绍多智能体设置。您将看到两种容易混淆的模式：

  • 持久代理程序会“永久”存在，通常映射到某个频道、机器人帐户或家庭成员。
  • 在后台运行执行特定任务并自动归档的子代理

您可以同时运行这两个代理。常见的设置是：一个主“协调器”代理负责处理主要聊天，并生成子代理来执行并行任务。同时，您还可以将其他持久代理绑定到不同的频道，使它们能够独立运行。

OpenClaw 中的“多智能体”是什么意思？

OpenClaw 可以在单个 Gateway 进程内运行多个完全隔离的代理。“隔离”并非营销噱头。每个代理都可以拥有自己的：

  • 工作区目录和本地文件，例如 SOUL.md 和 AGENTS.md
  • 内存存储
  • 会话历史记录
  • 模型提供者和技能的身份验证配置文件
  • 技能列表和技能覆盖
  • 模型选择和默认值
  • 可选的 Docker 沙箱设置

它们仍然共享同一个服务器进程和同一个主配置文件，所以你不需要运行十个网关。你只需要运行一个网关和多个位于其中的“大脑”。

如果你目前只在几个渠道上运行一个助手，可能不需要多代理。一个配置良好的单代理可以同时处理 Slack、Telegram 和 Discord，并保持上下文一致。只有当需要真正的隔离、不同的工具策略或互不干扰的独立内存时，多代理才真正有用。

两种解决不同问题的多智能体模式

持久代理

持久代理是指那些长期存在的代理。您可以在配置中定义它们，也可以使用代理向导创建它们。这些代理会被绑定到频道和聊天中。

合理的例子：

  • 一个绑定到 Slack 的工作助手
  • 一款绑定到 WhatsApp 帐户且工具使用受限的家庭助手
  • 一个绑定到 Discord 的代码助手，可以访问代码库并运行命令
  • 一个只负责撰写草稿、从不具备执行权限的社交代理

次级代理人

子代理是从正在进行的对话中派生的后台工作进程。它们在自己的会话中运行，执行任务并将结果返回。OpenClaw 在两处地方对此进行了说明，建议阅读一遍：

子代理非常适合并行研究和执行耗时较长的工具任务。如果主代理使用成本较高的模型，而子代理使用成本较低的模型或本地模型，那么子代理也有助于控制成本。

当多个代理人真的值得时

多智能体并非只需勾选一个复选框即可。它会增加一些动态组件。关键在​​于，添加智能体时要有明确的理由。

不同的安全工具策略

这是最重要的原因。例如，您希望您的个人助理拥有执行权限和文件系统访问权限，但您不希望您的公共 Discord 机器人拥有执行权限。通过使用不同的代理，您可以为每个代理设置允许和拒绝列表来强制执行此操作。

如果您需要 OpenClaw 部署的安全上下文，请使用OpenClaw 安全最佳实践。

分离的记忆和语气

记忆功能固然有用，但也容易造成“信息交叉”。如果你的工作助手学习了一套偏好设置，而你的私人助手学习了另一套，最终你会发现语气、提醒或细节方面出现奇怪的混淆。使用独立的智能助手可以避免这种情况。

如果你还没有深入了解内存，请阅读OpenClaw 内存详解。

不同的型号和成本概况

有些人希望使用速度快的模型进行日常聊天，而使用速度慢但功能强大的模型进行深度工作。多智能体架构可以轻松实现这一点，因为每个智能体都可以拥有自己的默认模型。子智能体也可以默认使用单独的模型，这可以轻松降低成本。

如果您在 OpenClaw 中需要帮助选择 Claude 和 OpenAI 模型，我们这里有一个指南：OpenClaw 的 Claude 与 OpenAI 模型选择。

持久代理设置

磁盘上的“一个代理”包含什么

OpenClaw 将每个代理的状态单独存储。即使你现在只运行一个代理，了解这种结构仍然很有帮助，因为它能简化调试过程。

  • 工作区保存文件和每个代理的技能。<workspace>/skills/
  • 代理目录保存身份验证配置文件和每个代理的配置状态
  • 会话存储保存聊天历史记录和路由状态

大多数时候，你只会与工作区进行交互。你可以在这里调整 SOUL.md 和 AGENTS.md 文件，以及存放一些辅助文件。

单代理模式及其对大多数人有效的原因

在单代理模式下，OpenClaw 默认使用一个主代理和一个默认工作区。这足以满足大多数配置需求。您可以将多个通道连接到同一个代理，其行为将保持一致。

在组建代理“团队”之前，我建议您先确保有一个代理在所有渠道上都能稳定工作。如果您在 WhatsApp 上运行 OpenClaw，请阅读OpenClaw WhatsApp 生产环境配置指南。如果您使用多个渠道， OpenClaw 多渠道配置指南将对您大有帮助。

使用向导创建代理

代理向导是最简便的方法，因为它会自动搭建工作区并创建一个干净的代理目录。它还能降低“两个代理意外共享一个目录”的风险，这种风险可能会导致身份验证和会话历史记录中断。

openclaw agents add work openclaw agents add coding openclaw agents add alerts

然后列出它们：

openclaw agents list --bindings

这个--bindings标志很有用，因为路由错误通常是绑定错误。

手动代理配置示例

如果您更喜欢直接编写配置，以下是一个最小示例。尽量保持简洁明了，这在以后会很有帮助。

agents: { list: [ { id: "main", default: true, name: "Personal Assistant", workspace: "~/.openclaw/workspace", }, { id: "coding", name: "Coding Agent", workspace: "~/.openclaw/workspace-coding", model: { primary: "anthropic/claude-sonnet-4-5" }, }, { id: "alerts", name: "Alerts", workspace: "~/.openclaw/workspace-alerts", model: { primary: "openai/gpt-5.2-mini" }, }, ], }

编辑配置后，重启网关，然后openclaw agents list --bindings再次运行。

将消息绑定并路由到代理

绑定是确定性的路由规则，它告诉 OpenClaw 哪个代理应该处理传入的消息。绑定匹配规则非常严格，通常遵循“最具体优先”的原则，这正是我们所需要的。

您需要关注的常用绑定字段：

  • 类似 WhatsApp、Telegram、Discord、Slack 的频道
  • accountId在您在同一频道类型上运行多个机器人帐户时非常有用
  • 针对特定私信、群组或频道的同行
  • 如果您需要这种复杂性，可以使用 Discord 路由的guildId和 roles。

避免意外情况的一般原则是：将最具体的绑定放在首位。例如，如果您定义了“所有 WhatsApp 消息都发送到主页面”，并且还定义了“某个特定群组消息发送到工作群组”，那么请将群组绑定放在渠道级绑定之上。

WhatsApp 有两个账号，分别绑定到两名代理人。

如果你既有个人号码又有公司号码，这是一种简洁的模式。

openclaw channels login --channel whatsapp --account personal openclaw channels login --channel whatsapp --account bizagents: { list: [ { id: "home", default: true, name: "Home", workspace: "~/.openclaw/workspace-home" }, { id: "work", name: "Work", workspace: "~/.openclaw/workspace-work" }, ], }, bindings: [ { agentId: "home", match: { channel: "whatsapp", accountId: "personal" } }, { agentId: "work", match: { channel: "whatsapp", accountId: "biz" } }, ]

如果您希望个人帐户上的某个特定组路由到工作地址，请在通道范围的绑定之上添加对等绑定。

WhatsApp 上只有一个号码，但多人通过私信联系。

这是一种非常常见的家庭设置。你将每个 DM 对等 ID 绑定到一个单独的代理，这样每个人都能获得独立的内存。

agents: { list: [ { id: "alex", workspace: "~/.openclaw/workspace-alex" }, { id: "mia", workspace: "~/.openclaw/workspace-mia" }, ], }, bindings: [ { agentId: "alex", match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551230001" } } }, { agentId: "mia", match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551230002" } } }, ], channels: { whatsapp: { dmPolicy: "allowlist", allowFrom: ["+15551230001", "+15551230002"], }, }

允许列表很重要。如果没有它，你基本上就是在用私人号码运行公共机器人。这很快就会变得很奇怪。

Telegram 包含两个机器人和两个代理

Telegram 非常适合将“聊天”和“提醒”分开，因为机器人令牌的管理成本低廉，而且路由也很简单。

channels: { telegram: { accounts: { default: { botToken: "123456:ABC...", dmPolicy: "pairing" }, alerts: { botToken: "987654:XYZ...", dmPolicy: "allowlist", allowFrom: ["tg:123456789"] }, }, }, }, bindings: [ { agentId: "main", match: { channel: "telegram", accountId: "default" } }, { agentId: "alerts", match: { channel: "telegram", accountId: "alerts" } }, ]

如果您需要帮助设置 Telegram 本身，以下两个工具可以一起使用：将 OpenClaw 连接到 Telegram BotFather和OpenClaw 的 BotFather 命令。

每个代理都使用独立的 Discord 机器人账号。

Discord 多代理通常意味着多个机器人令牌。这比尝试将所有请求都路由到一个机器人中更简洁，因为它可以在频道帐户级别实现隔离。

如果你想了解 Discord 频道的基础知识，本指南是一个很好的起点：将 OpenClaw 连接到 Discord。

从概念上讲，配置如下所示：

agents: { list: [ { id: "main", workspace: "~/.openclaw/workspace-main" }, { id: "coding", workspace: "~/.openclaw/workspace-coding" }, ], }, bindings: [ { agentId: "main", match: { channel: "discord", accountId: "default" } }, { agentId: "coding", match: { channel: "discord", accountId: "coding" } }, ], channels: { discord: { accounts: { default: { token: "DISCORD_BOT_TOKEN_MAIN" }, coding: { token: "DISCORD_BOT_TOKEN_CODING" }, }, }, }

然后，您可以为每个机器人账号设置允许访问的公会和频道范围。这样，您的编程机器人就只能看到编程房间。这是一种简单有效的安全措施。

Slack 作为“工作代理”的边界

Slack 非常适合绑定一个仅用于工作的代理，因为您可以保持其专业性，限制其记忆内容仅与工作相关，并锁定其使用的工具。如果您之前没有连接过 Slack，请使用OpenClaw Slack 集成。

每个代理的工具和沙箱设置

对许多用户来说，多智能体之所以物有所值，关键在于可以为每个智能体设置不同的工具权限。它允许你分别指定“此智能体可以读取和总结数据”以及“此智能体可以运行命令”，而不会将它们混淆。

每个代理的配置通常如下所示：

agents: { list: [ { id: "personal", workspace: "~/.openclaw/workspace-personal", sandbox: { mode: "off" }, }, { id: "family", name: "Family Bot", workspace: "~/.openclaw/workspace-family", sandbox: { mode: "all", scope: "agent", docker: { setupCommand: "apt-get update && apt-get install -y git curl", }, }, tools: { allow: ["read", "exec"], deny: ["write", "edit", "apply_patch", "browser", "cron"], }, }, ], }

三点实用建议：

  • 拒绝获胜。如果一个工具既被允许又被拒绝，则拒绝获胜。这正是你想要的。
  • Docker 沙箱可以使工具执行更安全，但如果您忘记在容器内挂载目录或安装二进制文件，它也会很麻烦。
  • 如果客服人员面向公众，则默认使用较少的工具。只有当您能解释清楚客服人员为什么需要这些工具时，才添加它们。

代理间通信

如果启用代理间通信工具，持久代理之间就可以相互通信。默认情况下，这并非“多代理”功能，而是需要用户选择启用。这是一个明智的设计选择，否则代理可能会意外地成为数据桥梁。

启用后，主要构建模块是sessions_send乒乓通信和允许列表，用于限制可以作为目标的代理 ID。关于代理消息传递的社区讨论提到，默认情况下，代理之间的通信轮次有限，并且由允许列表控制。关于多代理消息传递的社区讨论。

例子：

tools: { agentToAgent: { enabled: true, allow: ["home", "work", "coding"], }, }

我的建议很简单：只有当你的工作流程明确且确实需要时才启用此功能。对于大多数设置而言，子代理就足够了。

次级代理人和并行工作

子代理是由持久代理在后台运行的进程。它们在隔离的会话中运行，并在完成后将结果返回。此行为在 OpenClaw 会话工具页面中有详细说明sessions_spawn。

OpenClaw 还记录了面向用户的该命令，/subagents spawn并阐明它会启动一个后台子代理，并将最终完成更新发送回请求者。OpenClaw子代理。

适合子代理的用例

  • 为一份报告开展平行研究
  • 边聊天边进行日志分析
  • 批处理文件会向主会话发送大量垃圾邮件
  • 在单独的模型上运行缓慢的网络查找

我喜欢子代理的一点是，它们能保持主会话的整洁。如果某个子代理产生了噪声，这些噪声只会保留在它自己的会话记录中。

从聊天中生成一个子代理

这是“手动”版本。当您想要将工作委托给专家时，它非常有用。

/subagents spawn main "Summarize the last 7 days of changelog entries and propose release notes"

如果您的子代理命令在您的环境中支持模型覆盖，您可以为本次运行设置一个更经济的模型。会话工具文档列出了OpenClaw会话工具model的相关参数sessions_spawn。

使用 sessions_spawn 自动生成子代理

这就是编排器模式的工作原理。代理决定生成工作进程。在配置和工具中，这由sessions_spawn工具表示。文档将其描述为在隔离会话中生成一个子代理并向请求者通道发布消息。OpenClaw会话工具。

从概念上讲，它看起来是这样的：

sessions_spawn({ task: "Analyze disk usage logs and find anomalies for the past 24 hours", label: "Disk analysis", model: "anthropic/claude-sonnet-4-5", thinking: "medium", runTimeoutSeconds: 300 })

如果要在生产环境中使用此功能，请设置超时。失控的子代理不断循环调用工具既烦人又耗费资源。

令人惊讶的子代理上下文规则

子代理并非总是继承您期望的一切。在许多情况下，它们获得的上下文集比主代理要小。实际上，这意味着：如果您依赖于个性规则或冗长的偏好设置文件，则应该将关键信息放入 AGENTS.md 文件中，或者将其包含在子代理的任务提示中。

这也是我喜欢使用一个协调代理的原因，它的任务是“分解任务并生成工作进程”，并在 AGENTS.md 文件中保存一组关于工作进程所需内容的简短指令。这样一来，整个过程就变得可预测了。

嵌套和协调器模式

有些用户希望构建类似主程序 → 写入程序 → 检查程序 → 重写程序这样的流水线。常见的问题是，默认情况下子代理并非总能生成其他子代理。最近的一个社区帖子详细描述了这一限制及其原因。多代理生成挑战讨论。

OpenClaw 支持有限嵌套，但需要进行配置。如果启用最大嵌套深度为 2，则可以创建一个深度为 1 的编排器，该编排器可以生成深度为 2 的工作节点。嵌套深度超过 2 通常会增加复杂性，而不会提高结果。

一个常见的默认设置块如下所示：

agents: { defaults: { subagents: { maxSpawnDepth: 2, maxChildrenPerAgent: 5, maxConcurrent: 8, }, }, }

初期应保持保守的并发策略。很容易造成网关 CPU、本地模型运行时或服务提供商速率限制方面的瓶颈。

利用多代理进行成本控制

如果你的主代理运行高级模型，并生成一些成本较低的工人，成本就会迅速下降。主代理负责规划和合成，而工人则并行执行一些基础性工作。

基本模式：

agents: { defaults: { subagents: { model: "anthropic/claude-sonnet-4-5", thinking: "low", }, }, list: [ { id: "main", model: { primary: "anthropic/claude-opus-4-6" }, }, ], }

如果运行本地模型，子代理可以运行在 Ollama 上，而主代理则出于某种复杂原因保留在云端模型上。我们已经在另一篇指南中介绍了本地模型的设置，因此这里不再赘述。

优秀的建筑模式（在我看来）

具备通道路由能力的领域专家

每个代理都拥有一个域名，您可以按渠道或帐户路由消息。这种方式最容易理解，因为您可以指出某条消息并解释其路由到该位置的原因。

agents: { list: [ { id: "main", default: true, workspace: "~/.openclaw/workspace" }, { id: "coding", workspace: "~/.openclaw/workspace-coding" }, { id: "writing", workspace: "~/.openclaw/workspace-writing" }, ], }, bindings: [ { agentId: "coding", match: { channel: "discord", accountId: "coding-bot" } }, { agentId: "writing", match: { channel: "telegram", accountId: "writer-bot" } }, { agentId: "main", match: { channel: "whatsapp" } }, ]

拥有廉价劳动力的高级编曲家

一个代理与你对话。它会生成子代理来并行执行任务。当人们既想要速度又想要控制成本时，最终都会采用这种模式。

在这种模式下，你还需要考虑权限边界问题。如果编排器可以生成拥有比自身更强大工具的工作节点，就可能导致意外的权限提升。云安全联盟最近发布了一份威胁模型讨论，其中包含了多代理串谋和工具边界方面的风险。OpenClaw威胁模型分析。

你无需为此惊慌。但你需要仔细设计你的工具使用策略。

没有协调器的直接代理呼叫

这是一个“枯燥但有效”的方案。将每个渠道分配给一位专业客服人员，并且禁止客服人员之间互相发送消息。如果您需要更换客服人员，可以通过切换渠道或机器人账号来联系他们。

对于复杂的任务，它的速度较慢，但​​调试起来非常容易。

Discord 上的主题绑定会话

Discord 讨论串非常适合长时间运行的工作，因为你可以将子代理的运行绑定到一个讨论串中，并将后续讨论都集中在该讨论串内。这样可以避免繁忙的服务器频道变成日志的海洋。

这取决于 Discord 的线程绑定设置以及频道配置。如果您经常使用 Discord，建议尽早进行正确设置。

常见故障模式及解决方法

消息路由到错误的代理。

这几乎总是绑定特异性问题。列出所有绑定的代理，然后重新排列绑定顺序，使最具体的对等规则排在宽泛的通道规则之前。

openclaw agents list --bindings

两个代理共享身份验证或会话状态

这种情况通常发生在用户手动复制代理目录时。请勿重复使用代理状态目录。请使用向导或创建独立的工作区，并让 OpenClaw 创建单独的代理目录。

次级代理的结果从未显示

子代理会将结果通知请求者。如果通知被跳过或发送失败，您将看到结果缺失。子代理文档中描述了子代理会将最终完成更新发送回请求者的聊天窗口。OpenClaw子代理。

如果送货不稳定，请检查：

  • 通道连接
  • 速率限制
  • 会话超时
  • 任何工具均拒绝应用于子代理商

子代理尝试使用会话工具但失败了。

这可能是版本不匹配或工具绑定限制导致的。目前有一个未解决的问题，讨论了子代理在提示文本中看到会话工具名称，但实际上并未绑定到该工具的情况。GitHub上有一个关于子代理和会话工具的问题。

如果遇到此问题，请先升级 OpenClaw。如果问题仍然存在，请避免设计需要会话自省的子代理，并将它们设置为一次性工作进程。

多代理部署的安全注意事项

多代理架构虽然更容易实现隔离，但也增加了攻击面。你会拥有更多的机器人令牌、技能和身份验证配置文件。通常的“审查第三方技能”建议仍然适用，而且在这里尤为重要，因为你可能会不小心将某个技能安装到共享目录中，从而使所有代理都能访问该技能。

2026年初的安全报告涵盖了公共注册表中的恶意技能，并解释了为什么审查SKILL.md文件和脚本是必不可少的。Tom's Hardware对OpenClaw技能恶意软件的报告就是一个例子。恶意技能报告。

在 LumaDock 端，我们将面向公众的代理视为不可信接口。我们会锁定工具、锁定通道，并保留所有已启用功能的审计跟踪记录。

实用设置清单

  • 先从一个代理商开始，让你的渠道稳定下来。
  • 只有当你能解释隔离的必要性时，才添加第二个代理人。
  • 设置绑定，使对等规则高于通道范围规则。
  • 对面向公众的代理使用每个代理的拒绝列表工具
  • 使用子代理进行并行工作，而不是创建更持久的代理。
  • 如果你在意支出，那就为子代理商设定一个更便宜的模式。
  • 保持子代理嵌套深度较低
  • openclaw agents list --bindings每次路由更改后运行

Read more

stable-diffusion-webui【笔记】

stable-diffusion-webui * 二、模型推荐 * 1.Nova Anime XL 【二次元】 * 1.1 绘画效果 * 1.2 绘画效果 * 一、文件夹介绍 * 1.文件夹详细解释 缺少的数据可以留言我会及时补齐 缺少的数据可以留言我会及时补齐 缺少的数据可以留言我会及时补齐 二、模型推荐 1.Nova Anime XL 【二次元】 链接: Nova Anime XL - IL v15.0 | Illustrious Checkpoint | Civitai 模型类型：Checkpoint (大模型/底模) 它是一个主模型，不是 Lora，不需要挂载在别的模型上，而是直接选它来画图。 核心架构：SDXL

搭建本地ASR系统全攻略：Fun-ASR WebUI + GPU算力部署指南

搭建本地ASR系统全攻略：Fun-ASR WebUI + GPU算力部署指南 在远程会议、智能客服和语音笔记日益普及的今天，语音转文字的需求正以前所未有的速度增长。然而，当我们把音频上传到云端识别时，是否曾想过这些声音里可能包含客户的敏感信息、内部讨论细节甚至个人隐私？更别提网络延迟带来的等待焦虑——说一句话，等三秒才出字幕，体验大打折扣。 这正是越来越多企业开始转向本地化ASR系统的原因。不依赖云服务、数据不出内网、响应更快、长期成本更低——听起来像理想方案，但实现起来真的那么难吗？ 其实不然。随着 Fun-ASR 这类高性能开源语音模型的出现，加上 Fun-ASR WebUI 提供的图形化操作界面，现在只需一台配备GPU的普通服务器，就能搭建起一个接近实时、高精度的私有语音识别系统。本文将带你一步步落地这套方案，并深入解析其背后的关键技术如何协同工作，让本地语音识别不再是“实验室项目”，而是真正可用的生产力工具。 从一行命令说起：为什么这个启动脚本如此关键 我们先来看一段看似普通的启动命令： python app.py --host 0.0.0.0 --port
基于深度学习的纺织品缺陷检测系统演示与介绍(YOLOv12/v11/v8/v5模型+Django+web+训练代码+数据集)

基于深度学习的纺织品缺陷检测系统演示与介绍(YOLOv12/v11/v8/v5模型+Django+web+训练代码+数据集)

视频演示 基于深度学习的纺织品缺陷检测系统 目录 视频演示 1. 前言 2. 项目演示 2.1 用户登录界面 2.2 主界面布局 2.3 个人信息管理 2.4 多模态检测展示 2.5 检测结果保存 2.6 多模型切换 2.7 识别历史浏览 2.8 管理员管理用户信息 2.9 管理员管理识别历史 3.模型训练核心代码 4. 技术栈 5. YOLO模型对比与识别效果解析 5.1 YOLOv5/YOLOv8/YOLOv11/YOLOv12模型对比 5.2 数据集分析
Flutter 三方库 webrtc_interface 的鸿蒙化适配指南 - 掌控实时音视频中枢、P2P 高平效通讯实战、鸿蒙级多端互联专家

Flutter 三方库 webrtc_interface 的鸿蒙化适配指南 - 掌控实时音视频中枢、P2P 高平效通讯实战、鸿蒙级多端互联专家

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 webrtc_interface 的鸿蒙化适配指南 - 掌控实时音视频中枢、P2P 高平效通讯实战、鸿蒙级多端互联专家 在鸿蒙跨平台应用处理极低延迟的实时视频会议、云游戏映射或是 P2P 文件直传时，如何屏蔽不同底层实现（如 flutter_webrtc 对比浏览器原生接口）的差异是重中之重。如果你希望你的核心业务逻辑能无缝运行在鸿蒙原生 App、鸿蒙 ArkWeb 以及 PC 侧环境。今天我们要深度解析的 webrtc_interface——一个旨在提供统一 WebRTC 编程模型的接口抽象层，正是帮你打造“抗抖动、高可用通讯底座”的关键基石。 前言 webrtc_interface 是一套完全遵循 W3C WebRTC 规范的 Dart