OpenClaw从入门到应用——频道：频道路由

通过OpenClaw实现副业收入《OpenClaw赚钱实录从“养龙虾“到可持续变现的实践指南》OpenClaw 会将回复路由回消息来源的通道。模型不会选择通道路由是确定性的由主机配置控制。关键术语通道whatsapp、telegram、discord、slack、signal、imessage、webchat。AccountId每个通道的账户实例如果支持。可选的通道默认账户channels..defaultAccount用于在出站路径未指定accountId时选择使用哪个账户。在多账户配置中当配置了两个或更多账户时需要设置一个明确的默认账户defaultAccount或accounts.default。如果没有设置回退路由可能会选择第一个规范化的账户 ID。AgentId一个隔离的工作空间 会话存储“大脑”。SessionKey用于存储上下文和控制并发的桶键。会话键结构示例直接消息会归并到代理的主会话agent::默认agent:main:main群组和通道则按各自通道隔离群组agent:::group:通道/房间agent:::channel:线程Slack/Discord 线程在基础键后追加:thread:。Telegram 论坛主题在群组键中嵌入:topic:。示例agent:main:telegram:group:-1001234567890:topic:42agent:main:discord:channel:123456:thread:987654主 DM 路由固定当session.dmScope为main时直接消息可能会共享一个主会话。为了防止会话的lastRoute被非所有者 DM 覆盖OpenClaw 会在满足以下所有条件时推断一个固定的所有者allowFrom恰好包含一个非通配符条目。该条目可被规范化为该通道的具体发送者 ID。入站 DM 发送者与该固定所有者不匹配。在不匹配的情况下OpenClaw 仍然会记录入站会话元数据但会跳过更新主会话的lastRoute。路由规则如何选择代理每条入站消息的路由会选择一个代理精确对等匹配bindings中的peer.kindpeer.id父对等匹配线程继承公会 角色匹配Discord通过guildIdroles公会匹配Discord通过guildId团队匹配Slack通过teamId账户匹配通道上的accountId通道匹配该通道上的任意账户accountId: *默认代理agents.list[].default否则使用列表中的第一个条目回退到main当绑定中包含多个匹配字段peer、guildId、teamId、roles时必须匹配所有提供的字段才能应用该绑定。匹配到的代理决定了使用哪个工作空间和会话存储。广播组运行多个代理广播组允许你在 OpenClaw 通常会回复的同一对等端上运行多个代理例如在 WhatsApp 群组中在被提及/激活门控之后。配置示例{ broadcast: { strategy: parallel, 120363403215116621g.us: [alfred, baerbel], 15555550123: [support, logger], }, }参见广播组配置概览agents.list命名的代理定义工作空间、模型等。bindings将入站通道/账户/对等端映射到代理。示例{ agents: { list: [{ id: support, name: Support, workspace: ~/.openclaw/workspace-support }], }, bindings: [ { match: { channel: slack, teamId: T123 }, agentId: support }, { match: { channel: telegram, peer: { kind: group, id: -100123 } }, agentId: support }, ], }会话存储会话存储位于状态目录下默认~/.openclaw~/.openclaw/agents/agentId/sessions/sessions.jsonJSONL 格式的对话记录与存储并置。你可以通过session.store和{agentId}模板来覆盖存储路径。网关和 ACP 的会话发现也会扫描默认agents/根目录下以及模板化session.store根目录下的磁盘后端代理存储。发现的存储必须位于该解析后的代理根目录内并使用常规的sessions.json文件。符号链接和超出根目录的路径将被忽略。WebChat 行为WebChat 会附加到选定的代理并默认使用该代理的主会话。因此WebChat 允许你在一个地方查看该代理的跨通道上下文。回复上下文入站回复包括ReplyToId、ReplyToBody和ReplyToSender如果可用。引用的上下文会以[Replying to ...]块的形式附加到Body中。此行为在所有通道上保持一致。