Buzz
Buzz 是一个官方渠道插件,用于将 OpenClaw 代理连接到托管或自托管 Buzz 工作区中的团队房间。
它的作用¶
- 从已批准的 Buzz 房间接收普通消息、富内容消息和结构化差异消息
- 在同一房间和线程中回复
- 在接受的代理回合运行期间显示正在输入
- 在回复中保留 Markdown,并通过 OpenClaw 内置的
message工具发送文本 - 从回复和主动消息向当前房间成员发送原生 Buzz 提及
- 支持提及要求和发送者允许列表
- 在机器人获批后发现房间
- 通过 OpenClaw 的目录命令解析当前 Buzz 资料名称、头像、房间名称和房间成员身份
- 重新连接并避免重复处理同一条消息
当前插件支持群组房间、Markdown 文本和入站结构化差异。直接消息、媒体和文件、原生表情回应、房间创建以及自动管理员批准尚不支持。
Buzz 身份与房间模型¶
Buzz 使用 Nostr 密钥对作为身份:
- 私钥让 OpenClaw 能够进行身份验证并签署消息。它保留在 Gateway 中。
- 公钥用于标识机器人。Buzz 所有者使用它进行中继批准,房间管理员使用它授予 Bot 角色,OpenClaw 可以在发送者允许列表中使用公钥。
中继 URL 指向一个 Buzz 工作区。每个房间都有一个 UUID,OpenClaw 将每个已配置的 UUID 视为一个独立的群组会话。一个 Gateway 和机器人身份可以服务多个房间。你不需要为每个代理或每个房间配置一个 Gateway。
开始之前¶
你需要:
- 你的 Buzz 工作区的
wss://中继 URL。 - 能够批准机器人身份的 Buzz 所有者或管理员。
- 至少一个可以以 Bot 角色添加机器人的房间。
Warning
切勿将人类 Buzz 所有者的私钥交给 OpenClaw。OpenClaw 会创建或使用专用机器人身份,并显示管理员批准所需的公钥。
安装¶
安装或更新插件后,检查应用结果。
引导式设置¶
运行:
设置流程将依次执行以下步骤:
- 选择现有 Buzz 账户或添加命名账户。
- 如果该账户尚未配置 Buzz 中继 URL,请输入。
- OpenClaw 会复用该账户的机器人身份或自动生成一个。
- 如果机器人尚未获得房间访问权限,请将显示的公钥提供给 Buzz 房间所有者或管理员。
- OpenClaw 会等待 Buzz 确认 Bot 角色,然后自动继续。如果自动等待超时,请重试经过身份验证的发现,或在不更改已生成身份的情况下返回。
- 如果 Buzz 返回一个房间,OpenClaw 会选择它。如果返回多个,请选择要使用的房间和默认出站房间。
- OpenClaw 会保存配置,并在 Gateway 运行时静默验证经过身份验证的房间。
全新设置会接受配置房间当前成员的普通消息,无需在编辑器中提及。重新运行设置时,现有的显式提及和发送者允许列表设置会被保留。
设置会解析所选账户的 privateKey 和 authTag SecretRefs,而不会替换配置中的引用。如果已配置的密钥不可用,设置会报告错误且不保存账户更改。使密钥可用后重新运行设置。现有账户不会被禁用。选择至少一个已授权房间以完成设置,或返回以保留当前状态。
自动房间访问等待是有界的。如果未能及时授予访问权限,设置会保持打开状态,并提供经过身份验证的重试/返回控件。每次重试都会复用相同的中继和机器人身份。超时不会禁用 Buzz 或退出设置。
机器人批准¶
每个目标房间都必须包含具有 Bot 角色的机器人身份。现有的人类成员或普通房间成员角色是不够的。
启动时,OpenClaw 会跳过机器人缺少 Bot 角色的活动配置房间,并为每个跳过的房间记录警告。其他符合条件的房间保持在线。如果仍有活动配置房间但没有一个具有 Bot 角色,则账户无法启动。
当中继报告某个被跳过房间的成员身份变更时,OpenClaw 会再次检查其签名成员列表。确认的 Bot 角色会启动该房间,而无需重启健康房间。已订阅房间中实时发生的 Bot 角色降级仍会取消账户的活动工作,并使用最新成员身份重新连接。
Buzz 桌面端无法可靠地为外部管理的 OpenClaw 身份分配 Bot 角色。请以现有的人类房间所有者或管理员身份使用 Buzz CLI:
以现有的人类所有者或管理员身份运行该命令。切勿将那个人类私钥交给 OpenClaw。
Gateway 连接后,OpenClaw 会保留现有的非空 Buzz 资料显示名称。对于新资料,它会使用已配置的 Buzz 渠道账户名称,然后是使用路由到已配置 Buzz 房间的单个代理的身份名称,最后使用 OpenClaw。这会在其资料缓存刷新后替换 Buzz 中的缩短公钥。
OpenClaw 还会在 Buzz 的代理目录中注册相同的公开身份。它会保留现有的代理目录资料和渠道添加策略。对于新资料,它允许已授权的 Buzz 用户添加该身份。这样,当该身份被邀请到更多房间时,Buzz 可以为其分配 Bot 角色,而不是将其视为普通成员。OpenClaw 仍然只从该账户 groups 中明确选择的房间接收消息:对于隐式根身份,使用 channels.buzz.groups;对于嵌套身份,使用 channels.buzz.accounts.<id>.groups。
当机器人资料没有有效的 NIP-OA 所有者证明时,Buzz 会显示 owner unavailable。这并不意味着房间访问失败。对于隐式根身份,在 channels.buzz.authTag 处配置所选身份的 authTag;对于嵌套身份,在 channels.buzz.accounts.<id>.authTag 处配置。OpenClaw 会在发布的资料中包含该证明,以便 Buzz 显示已验证的人类所有者。
While the Gateway is connected, OpenClaw publishes and refreshes the bot's ephemeral Buzz presence every 30 seconds. Buzz removes the presence when the last authenticated Gateway connection for that bot identity closes, so multiple Gateway instances do not incorrectly mark one another offline. If the relay stops acknowledging presence, OpenClaw reconnects the affected Buzz account instead of leaving an open but stalled connection marked ready. An explicit presence rejection remains a warning, not a reconnect trigger.
当 Gateway 已连接时,OpenClaw 会每 30 秒发布并刷新机器人的临时 Buzz 在线状态。当该机器人身份最后一个已认证的 Gateway 连接关闭时,Buzz 会移除该在线状态,因此多个 Gateway 实例不会错误地将彼此标记为离线。如果中继停止确认在线状态,OpenClaw 会重新连接受影响的 Buzz 账户,而不是保留一个已打开但停滞且被标记为就绪的连接。明确的在线状态拒绝仍然只是警告,而不是重新连接触发条件。
The local Buzz just dev relay does not require separate relay membership by
default. A hosted or closed relay may require the bot public key to be added to
the workspace community first. Adding community membership grants relay access.
It does not add the identity to a room with the Bot role.
本地 Buzz just dev 中继默认不需要单独的中继成员资格。托管或封闭中继可能要求先将机器人公钥添加到工作区社区。添加社区成员资格会授予中继访问权限。它不会将该身份以 Bot 角色添加到房间。
OpenClaw cannot grant room or relay access. It displays only the bot public key needed by the authorized human.
OpenClaw 无法授予房间或中继访问权限。它仅显示授权人员所需的机器人公钥。
代理工具与消息¶
The Buzz plugin does not add a separate Buzz-only agent tool. It registers Buzz
as a destination for OpenClaw's built-in message tool and normal reply
delivery.
Buzz 插件不会添加单独的仅限 Buzz 的代理工具。它将 Buzz 注册为 OpenClaw 内置 message 工具和常规回复投递的目标。
Agents can:
代理可以:
- Reply to an incoming Buzz message in its room or thread
- Show room- or thread-scoped typing while generating a reply
- Receive Buzz kind
9normal messages, kind40002rich-content messages, and kind40008structured diffs - Send Markdown text to an approved Buzz room as a normal kind
9message - Send native room-member mentions from normal replies and proactive messages
- Use the configured default room when a workflow does not specify a target
-
Use the routed agent's normal skills, memory, and allowed tools
-
在其房间或线程中回复收到的 Buzz 消息
- 在生成回复时显示房间或线程范围的正在输入状态
- 接收 Buzz 类型
9的常规消息、类型40002的富内容消息以及类型40008的结构化差异 - 将 Markdown 文本作为常规类型
9消息发送到已批准的 Buzz 房间 - 从常规回复和主动消息中发送原生房间成员提及
- 当工作流未指定目标时使用已配置的默认房间
- 使用被路由代理的常规技能、记忆和允许的工具
Structured diffs include their repository, commit, file, branch, pull request, language, description, truncation status, and unified-diff content in the agent context when those fields are present. Diff content is not interpreted as an OpenClaw command or textual mention.
当这些字段存在时,结构化差异会在代理上下文中包含其仓库、提交、文件、分支、拉取请求、语言、描述、截断状态和统一差异内容。差异内容不会被解释为 OpenClaw 命令或文本提及。
Typing uses Buzz's ephemeral kind 20002 on the active authenticated Gateway
connection. Ordinary replies refresh it every three seconds. Heartbeat-driven
replies use OpenClaw's shared typing interval, which defaults to six seconds.
OpenClaw stops refreshing when the turn completes, is cancelled, fails, or the
Gateway shuts down. Typing failures do not block the reply or reconnect the
Gateway solely to send an ephemeral event.
正在输入状态使用 Buzz 的临时类型 20002,位于活动的已认证 Gateway 连接上。常规回复每三秒刷新一次。由心跳驱动的回复使用 OpenClaw 的共享正在输入间隔,默认值为六秒。当回合完成、被取消、失败或 Gateway 关闭时,OpenClaw 停止刷新。正在输入失败不会阻止回复,也不会仅为了发送临时事件而重新连接 Gateway。
Humans and automations can test the same outbound path from the CLI:
人类和自动化流程可以通过 CLI 测试相同的出站路径:
openclaw message send \
--channel buzz \
--target buzz:<ROOM_UUID> \
--message "Hello from OpenClaw"
原生提及¶
Write a unique current room member's profile name as @Display Name. OpenClaw
keeps the visible text unchanged and adds the native Buzz p tag, including on
threaded replies. Names are resolved only against the target room's current
relay-signed membership and bounded profile snapshot.
将唯一当前房间成员的配置文件名称写为 @Display Name。OpenClaw 保持可见文本不变,并添加原生 Buzz p 标签,包括在线程回复中。名称仅针对目标房间当前的中继签名成员资格和有界配置文件快照进行解析。
For an explicit identity, include its NIP-27 reference in the message:
对于显式身份,请在消息中包含其 NIP-27 引用:
openclaw message send \
--channel buzz \
--target engineering \
--message "Please review this, nostr:npub1..."
The referenced public key must be a current member of the target room. Without
an explicit identity, unknown names and duplicate profile names fail visibly
instead of sending text that looks like a mention without notifying anyone.
When the message contains an explicit identity, unresolved or ambiguous labels
remain presentation text. Include every intended identity explicitly. Ambiguous
errors list candidate public keys so the sender can retry with the intended
nostr:npub... identity. Out-of-room public keys always fail. Mention-like text
inside inline or fenced Markdown code is ignored, and one message can carry at
most 50 native mentions.
被引用的公钥必须是目标房间的当前成员。如果没有显式身份,未知名称和重复的配置文件名称会明显失败,而不是发送看起来像提及但不会通知任何人的文本。当消息包含显式身份时,未解析或有歧义的标签仍保持为展示文本。请显式包含每个预期身份。有歧义的错误会列出候选公钥,以便发送者可以使用预期的 nostr:npub... 身份重试。房间外的公钥始终失败。内联或围栏 Markdown 代码中的类提及文本会被忽略,并且一条消息最多可携带 50 个原生提及。
Connected Gateways resolve names from their existing in-memory directory
snapshot and do not query the relay per message. Profiles beyond the bounded
snapshot require an explicit nostr:npub... identity. A standalone mention send
loads membership and profiles through one bounded authenticated relay session,
publishes, and closes it. Standalone messages without mention syntax keep the
existing direct publish path.
已连接的 Gateway 会从其现有的内存目录快照中解析名称,并且不会按消息查询中继。超出有界快照的配置文件需要显式的 nostr:npub... 身份。独立的提及发送会通过一个有界的已认证中继会话加载成员资格和配置文件,发布后关闭该会话。没有提及语法的独立消息保持现有的直接发布路径。
目录与发送者标签¶
OpenClaw keeps a bounded snapshot of the configured rooms, their current
relay-signed member lists, room metadata, and kind 0 member profiles. Incoming
agent context uses the current profile and room names when available, while the
sender public key remains the stable authorization, routing, and session
identity.
OpenClaw 会保留已配置房间的有界快照,包括其当前的中继签名成员列表、房间元数据和类型 0 成员配置文件。传入的代理上下文在可用时使用当前配置文件和房间名称,而发送者公钥仍然是稳定的授权、路由和会话身份。
Inspect the same data from the CLI:
从 CLI 检查相同的数据:
openclaw directory self --channel buzz
openclaw directory peers list --channel buzz --query "alice"
openclaw directory groups list --channel buzz --query "engineering"
openclaw directory groups members \
--channel buzz \
--group-id buzz:<ROOM_UUID>
When the Gateway is connected, directory reads reuse its authenticated Buzz connection and in-memory snapshot. A standalone directory command opens one bounded authenticated connection, loads the current snapshot, and closes it. Ordinary directory errors are logged without reconnecting. If a directory or profile subscription does not reach EOSE within 10 seconds, OpenClaw treats the Buzz relay session as stalled and recycles only that Buzz account connection. The Gateway keeps running.
当 Gateway 已连接时,目录读取会复用其已认证的 Buzz 连接和内存快照。独立的目录命令会打开一个有界的已认证连接,加载当前快照,然后关闭它。常规目录错误会被记录,而不会重新连接。如果目录或配置文件订阅在 10 秒内未达到 EOSE,OpenClaw 会将 Buzz 中继会话视为停滞,并仅回收该 Buzz 账户连接。Gateway 继续运行。
Archived rooms are omitted from directory results and live room subscriptions. If a configured room is archived or restored while OpenClaw is connected, the plugin recycles only its Buzz connection so the subscription set matches the relay's current metadata. The Gateway keeps running.
已归档房间会从目录结果和实时房间订阅中省略。如果已配置的房间在 OpenClaw 连接期间被归档或恢复,插件仅回收其 Buzz 连接,以便订阅集与中继的当前元数据匹配。Gateway 继续运行。
Each configured room uses one room-scoped relay subscription. OpenClaw reserves four of Buzz's 1,024 connection subscriptions for membership notifications and concurrent profile, membership, and metadata queries, so one account can configure up to 1,020 rooms. Near that limit, optional member profile subscriptions are reduced first. Directory entries continue to work with stable public keys and deterministic fallback labels.
每个已配置房间使用一个房间范围的中继订阅。OpenClaw 从 Buzz 的 1,024 个连接订阅中保留四个用于成员通知以及并发的配置文件、成员资格和元数据查询,因此一个账户最多可配置 1,020 个房间。接近该限制时,可选的成员配置文件订阅会先被减少。目录条目会继续使用稳定的公钥和确定性回退标签工作。
唯一的当前房间名称可以通过 OpenClaw 的共享目录查找解析为出站目标。规范的 buzz:<ROOM_UUID> 目标仍然是自动化以及重名房间的最安全选择。
将房间路由到不同代理¶
标准 OpenClaw 绑定可以将每个 Buzz 房间发送到不同的代理、工作区或模型,同时由一个 Gateway 和一个 Buzz 机器人服务所有房间:
{
agents: {
entries: {
support: { default: true, workspace: "~/.openclaw/workspace-support" },
engineering: { workspace: "~/.openclaw/workspace-engineering" },
},
},
bindings: [
{
agentId: "support",
match: {
channel: "buzz",
peer: { kind: "group", id: "buzz:<SUPPORT_ROOM_UUID>" },
},
},
{
agentId: "engineering",
match: {
channel: "buzz",
peer: { kind: "group", id: "buzz:<ENGINEERING_ROOM_UUID>" },
},
},
],
}
如果没有针对特定房间的绑定,常规 OpenClaw 路由会选择默认代理。有关匹配优先级,请参阅 通道路由。
访问控制¶
Buzz 应用两项独立控制:
- 要求提及:仅当机器人被提及时,代理才会响应。
- 发送者访问:允许已批准房间的每个当前成员、禁用房间入口,或进一步将房间成员限制为选定的 Buzz 公钥。
新的引导式设置允许所选房间的当前成员发送普通消息。OpenClaw 在接受消息之前会加载 Buzz 的由中继签名的房间成员列表,在入队前检查成员资格,并在异步准入后再次检查,并遵循实时的中继签名成员列表更新,包括角色变更。移除会立即使已入队的消息失效。已取消的准入不会被提交为已处理。有界快照刷新会确认成员变更通知。成员资格检查不需要逐条消息查询中继或轮询 Gateway。移除某个发送者不会取消已经为该发送者准入的房间回合。失去机器人自身的 Bot 角色或停止其连接仍会隔离输出。
启动和重连会恢复最近 24 小时内符合条件的消息,但绝不会恢复该 Buzz 账户首次激活该房间之前的消息。该激活下限在重启后仍然保留。发送者提供的时间戳不会推进它。重放去重可防止已完成的消息再次运行。
当只有特定房间成员应能激活代理时,在手动配置中使用 groupPolicy: "allowlist" 和 groupAllowFrom。每个房间都可以覆盖 groupPolicy、groupAllowFrom 或两者。省略的房间设置会继承账户范围的值。当有效策略为 "allowlist" 时,显式空白的房间允许列表会拒绝所有发送者。仅当这些成员使用的 Buzz 客户端能够寻址机器人身份时,才设置 requireMention: true。
在房间中设置 requireMentionInBotThreads: false,可在由该 Buzz 机器人发起的线程中接受未提及的回复,同时在其他地方仍要求提及:
{
channels: {
buzz: {
groups: {
"7c4a6d2a-2ed9-4b4e-a5e2-4d705ee9b34c": {
requireMention: true,
requireMentionInBotThreads: false,
},
},
},
},
}
对于命名账户,请使用 channels.buzz.accounts.<id>.groups.<roomId>。将该选项设置为 true 时,即使房间在其他情况下接受未提及的消息,也要求在机器人发起的线程中提及。省略该选项会保留房间当前的提及策略。发送者限制和命令授权保持不变。
OpenClaw 会验证根消息的签名、作者、房间以及不存在父线程。机器人在他人线程中的回复不会使该线程成为机器人所有。缺失的根消息会通过现有已认证中继查询;已验证的根消息会针对该连接缓存。如果无法验证所有权,则应用房间的常规提及策略。
这些控制决定谁可以启动代理运行。它们不会限制路由后的代理在消息被接受后能做什么。请将房间消息视为不可信输入,并根据房间的信任级别配置该代理的 沙箱和工具策略。
机器人对话¶
具有中继分配的 Bot 角色的授权房间成员可以在相同的提及和发送者规则下激活代理。在每个 Gateway 内,OpenClaw 会限制同一中继和房间中每对机器人之间的重复交互:默认预算是 60 秒内接受 20 条消息,随后进入 60 秒冷却期。切换线程不会重置预算。重启 Gateway 会清除此内存预算。不同的 Gateway 拥有不同的预算。人类消息不受影响,被抑制的机器人回合会被记录日志,而不会启动代理运行。
使用共享的 channels.defaults.botLoopProtection 设置来调整 maxEventsPerWindow、windowSeconds 或 cooldownSeconds。设置 enabled: false 会禁用此保护。机器人分类来自最新收到的中继签名房间成员列表,绝不来自显示名称或消息内容。如果授权机器人在繁忙交互期间停止回复,请检查抑制日志,并等待冷却期结束后再调整预算。
被动房间上下文¶
将 channels.buzz.historyLimit 设置为 1 到 20 之间的数字,可在同一房间和线程中,将最近未提及的消息与下一个被接受的回合(提及或授权命令)一起包含。默认值为 0(关闭)。新的回复线程不会导入顶层房间历史。发送者访问仍然适用:被拒绝的发送者永远不会被记录,且不再位于当前房间成员列表中的发送者会在上下文包含之前被移除。
被动消息不会启动代理运行、记录会话或发送正在输入状态。历史会保留在当前连接的内存中,按每个房间和线程分别保存,并在重连或重启时清除。每条消息会被截断为 512 个 UTF-8 字节。最新的完整条目需适配 1,024 字节的渲染上下文预算,包括标签和标记。较旧的条目会被丢弃。被接受的回合会消耗其上下文,而不会删除回复运行期间到达的消息。
使用上下文时,会根据最新收到的名册检查成员资格。 如果同一身份在此之前离开并重新加入,其先前已获授权的消息可能仍保留在上下文窗口中。离开不会清除对话历史。
回复位置¶
Buzz 默认将自动回复保持为线程内回复(channels.buzz.replyToMode: "all")。
将 replyToMode 设为 "off" 可将自动回复发送到房间顶层,包括对现有线程内消息的回复。正在输入指示器也遵循相同的位置规则,包括心跳式输入提示。
这仅改变投递方式:入站线程上下文和会话身份保持不变。通过消息工具或 CLI 显式指定线程或回复目标的发送仍会遵循该目标。要恢复默认行为,请使用 "all" 或移除该设置。
手动配置¶
建议使用引导式安装。等效配置如下:
{
channels: {
buzz: {
name: "OpenClaw",
relayUrl: "wss://buzz.example.com",
privateKey: "nsec1...",
groupPolicy: "open",
groups: {
"7c4a6d2a-2ed9-4b4e-a5e2-4d705ee9b34c": {
requireMention: false,
},
},
defaultTo: "7c4a6d2a-2ed9-4b4e-a5e2-4d705ee9b34c",
},
},
}
对于更严格的发送者策略:
{
channels: {
buzz: {
groupPolicy: "allowlist",
groupAllowFrom: ["<64_CHARACTER_HEX_SENDER_PUBLIC_KEY>"],
},
},
}
要在保持其他已配置房间开放的同时限制某个房间:
{
channels: {
buzz: {
groupPolicy: "open",
groups: {
"7c4a6d2a-2ed9-4b4e-a5e2-4d705ee9b34c": {
groupPolicy: "allowlist",
groupAllowFrom: ["<64_CHARACTER_HEX_SENDER_PUBLIC_KEY>"],
},
},
},
},
}
房间 UUID 是规范目标。使用发现过程中显示的 UUID,或向房间管理员询问。唯一的当前房间名称可以通过实时目录解析,但自动化应使用 buzz:<ROOM_UUID> 以避免歧义。
对于手动配置,groupAllowFrom 条目必须使用 64 字符十六进制格式。
回复前缀¶
设置 channels.buzz.responsePrefix 可为自动智能体回复添加前缀,例如 "[Support]"。使用 "auto" 表示被路由智能体的身份名称,"[{model}]" 表示其选定的模型,或使用 "" 禁用继承的全局前缀。显式的 message 工具和 CLI 文本发送也会应用字面前缀和身份前缀。有关依赖模型的模板,请参阅 共享前缀行为。命名账户可以使用 channels.buzz.accounts.<id>.responsePrefix 覆盖根前缀。
省略 --account 的 CLI 发送也会使用所选默认账户的前缀。账户级别的 "" 会抑制继承的根前缀。
多个机器人身份¶
一个 Gateway 可以运行多个独立的 Buzz 账户,每个账户拥有自己的中继、机器人密钥、authTag 和所选房间。运行 openclaw channels add --channel buzz 并选择新账户进行交互式配置。添加命名账户不会移动或替换现有的根身份。
{
channels: {
buzz: {
relayUrl: "wss://buzz.example.com",
privateKey: { source: "env", provider: "default", id: "BUZZ_ROOT_KEY" },
groupPolicy: "allowlist",
groups: { "7c4a6d2a-2ed9-4b4e-a5e2-4d705ee9b34c": {} },
accounts: {
ada: {
name: "Ada",
relayUrl: "wss://buzz.example.com",
privateKey: { source: "env", provider: "default", id: "BUZZ_ADA_KEY" },
groups: { "940d0c32-4eb7-46d7-9d5b-d975aaef87f7": {} },
},
},
},
},
}
命名账户继承根策略和投递设置,但绝不继承根的 name、relayUrl、privateKey、authTag、groups 或 defaultTo。请在每个账户上设置这些身份和房间字段。显式的 accounts.default 也拥有完整身份,并替换隐式根身份。它不会借用根凭据或 BUZZ_* 环境变量。
设置 defaultAccount,以选择命令省略 --account 时使用的账户。否则,优先使用隐式根/默认身份,然后按排序顺序使用第一个已配置账户。账户键使用小写字母、数字、连字符和下划线,以字母或数字开头,且最多 64 个字符。constructor 和 prototype 为保留字。
在消息和目录命令中使用 --account ada,并在将该机器人路由到智能体时,将 accountId: "ada" 添加到绑定的 match 对象中。设置 channels.buzz.accounts.ada.enabled: false 可仅禁用 Ada。channels.buzz.enabled: false 会禁用所有 Buzz 账户。Buzz 尚不支持通过 channels remove 禁用或删除账户。
编辑现有命名账户时,仅重新加载该账户,并保持其他健康的同级账户连接。对共享 Buzz 设置、accounts.default 或已移除账户的更改会重新加载整个通道。账户关闭会等待已受理的消息工作和待处理的资料同步完成后再启动替代账户。
机器人密钥存储¶
默认的引导式安装路径会复用当前机器人身份,或生成私钥并将其存储在所选账户的 privateKey 中,遵循 OpenClaw 当前的明文配置约定。
对于已有密钥,安装可以使用明文或现有的 env、file 或 exec SecretRef。有关提供方设置,请参阅 Secrets 管理。隐式根默认身份还可以读取:
设置 BUZZ_PRIVATE_KEY 后,非交互式安装还可以保存账户名称:
openclaw channels add --channel buzz --name "Support bot" \
--relay-url wss://buzz.example.com --use-env
省略 --name 或提供空白名称将保留现有名称。此命令会保存凭据和设置。在启动新机器人之前,请使用引导式安装来发现并选择房间。
authTag 是托管工作区操作员为某个身份签发的委托授权值。请将操作员提供给您的值设置在所选身份的 authTag 上。隐式根身份使用 channels.buzz.authTag,并可回退到 BUZZ_AUTH_TAG。嵌套身份(包括 accounts.default)使用 channels.buzz.accounts.<id>.authTag,且绝不会借用该环境变量回退。该字段接受与私钥相同的明文或 SecretRef 形式。请将此可复用的委托值视为机密:勿将其写入日志、截图、聊天或源代码管理;对于持久化部署,建议优先使用 SecretRef。每当机器人身份或中继授权发生变化,或任一凭据可能已暴露时,请申请替换并吊销旧值。
自托管运营者可以手动生成密钥用于恢复或高级设置:
验证连接¶
运行经过身份验证的通道探测:
成功的探测可确认机器人能够完成身份验证,并且 Buzz 报告所选房间具有 Bot 角色。
然后发送一条真实消息:
要进行完整往返,请让一位获允许的 Buzz 用户提及机器人,并确认 OpenClaw 在房间中回复。
QA 实验室往返¶
源代码检出可以使用两个专用测试身份来验证生产 Buzz 通道路径:
pnpm openclaw qa buzz \
--credential-file /secure/path/buzz-qa-credentials.json \
--provider-mode mock-openai
该命令在使用确定性模拟模型的同时,运行真实中继金丝雀和提及门控检查。私有 JSON 凭据文件包含 relayUrl、roomId、driverPrivateKey 和 sutPrivateKey,以及用于封闭中继的可选 driverAuthTag 和 sutAuthTag 值。两个测试公钥都必须是房间成员,并且 SUT 公钥必须具有 Bot 角色。封闭中继可能要求分别注册两个公钥。对于池化 QA 凭据,请使用 --credential-source convex。
对于托管中继,请使用 wss://。明文 ws:// 凭据 URL 仅接受用于回环开发中继。
切勿使用人类所有者或管理员的私钥。私钥和可选 authTag 值是父级测试框架机密,不得出现在日志、工件、屏幕截图、shell 历史记录或源代码控制中。
轮换机器人身份¶
机器人身份轮换需要管理员批准新的公钥:
- 生成一个新的专用机器人身份。
- 让管理员批准其公钥用于中继和每个已配置房间。
- 替换已配置的私钥,并验证 热重载 是否应用了该更改。如果密钥来自已更改的服务环境,请重启 Gateway。
- 测试出站和入站消息。
- 从房间和中继中移除旧公钥。
在切换密钥之前完成批准,以最大程度减少停机时间。目前轮换不是自动的。
当前限制和路线图¶
以下后续领域已计划,但不属于当前插件:
- 直接消息
- 媒体和文件上传或下载
- 原生表情符号回应
- 从 OpenClaw 创建或管理房间
- 自动中继成员资格和房间角色批准
- 引导式机器人身份轮换
故障排除¶
| 症状 | 检查内容 |
|---|---|
| 未发现任何房间 | 确认此确切的机器人公钥位于房间中并具有 Bot 角色,然后重新运行相同的设置命令。 |
| 身份验证失败 | 检查中继 URL、机器人私钥、封闭中继成员资格以及操作员提供的任何 authTag。 |
| 无法发送消息 | 确认机器人是具有 Bot 角色的房间成员,并且已配置 UUID。 |
| 机器人收到消息但不回复 | 确认发送者仍是房间成员,然后检查可选的发送者允许列表和提及要求。 |
| 设置提示 Gateway 未运行 | 使用 openclaw gateway 启动它,然后运行 openclaw channels status --probe。 |
| 自动房间发现已过期 | 授予 Bot 角色,然后选择重试;同一身份保持活动状态。 |
相关¶
本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 cl/openclaw