OpenClaw Discord Clawd 技能：通过 Relay 助手与 Discord 侧 Agent 会话通信

Discord Clawd 是 OpenClaw 仓库中一个面向 AI Agent 的协作技能（Skill），用于通过 OpenClaw relay 助手与 Discord 承载的 OpenClaw agent/session 对话、提问或按用户意图发帖。阅读本文后，你可以掌握该技能的适用边界（何时用它、何时改用 discrawl 或 discord-user-post）、relay 助手 targets/resolve/ask/publish/force-send 的完整命令用法，以及发送前必须遵守的安全护栏，从而在自动化流程中安全地经 Discord 路由消息。

1. 技能定位：它解决什么问题

技能的完整定义位于 .agents/skills/discord-clawd/SKILL.md，其 frontmatter 声明了名称与用途：

name: discord-clawd
description: Use to talk to the Discord-backed OpenClaw agent/session; not for archive search.

一句话概括其职责边界：

• 适用：任务是与 Discord 承载的 OpenClaw agent/session 对话、向它提问，或通过该路由发帖（post through that route）；
• 不适用：Discord 归档、历史记录或搜索——这类任务必须改用 $discrawl 技能。

这一“路由通信 vs 归档检索”的二分法是理解该技能的关键。OpenClaw 仓库里围绕 Discord 共有三条彼此正交的链路，Discord Clawd 只是其中一条：

技能	职责	对应文档
discord-clawd	与 Discord 侧 agent/session 通信（问/答/发帖路由）	.agents/skills/discord-clawd/SKILL.md
discrawl	Discord 本地归档的检索、新鲜度检查、DM 查询、SQL 统计	.agents/skills/discrawl/SKILL.md
discord-user-post	以登录用户身份（经桌面 App 操作）发布已批准消息	.agents/skills/discord-user-post/SKILL.md

例如 discord-user-post 技能 的 frontmatter 明确写着：适用于发布公告等“用户本人署名”的直发场景，且“不用于 OpenClaw channel 发送、bot、webhook、relay、agent 会话或归档检索”——这与 Discord Clawd 走 relay 的通道恰好互斥。三条链路各自独立、互不越界，是仓库中 Discord 工具链的整体设计思路。

技能的注册元数据在 .agents/skills/discord-clawd/agents/openai.yaml 中，定义了它在 Agent 交互界面的展示名与默认提示词：

interface:
  display_name: "Discord Clawd"
  short_description: "Talk to the Discord-backed OpenClaw agent"
  default_prompt: "Use $discord-clawd to route a private ask or explicit post through the Discord-backed OpenClaw agent/session."

从该结构看，Agent 通过 $discord-clawd 这一斜杠引用调用技能，default_prompt 本身就点明了两种典型用法：**private ask（私密提问）**与 explicit post（显式发帖）——这也是下文投递模式划分的前置依据。

2. 传输层：OpenClaw relay 助手

文档指定了唯一传输通道——OpenClaw relay helper 脚本。注意：该脚本不在本仓库内，而是位于维护者机器上的 ~/Projects/agent-scripts 目录（本仓库中没有任何 openclaw_relay.py 的实现文件，这是使用前提，需自行确保该脚本可用）：

cd ~/Projects/agent-scripts
python3 skills/openclaw-relay/scripts/openclaw_relay.py targets
python3 skills/openclaw-relay/scripts/openclaw_relay.py resolve --target maintainers

两个准备步骤各有用途：

1. targets：列出当前所有可用投递目标（别名清单）。在不知道能发给谁时，先运行它拿全量清单。
2. resolve --target <alias>：把逻辑别名（如 maintainers）解析为真实投递目标。发送任何真实内容之前必须先 resolve，这是文档护栏的第一条硬性要求。

目标别名存在时，优先采用“私密提问”（private ask）：

python3 skills/openclaw-relay/scripts/openclaw_relay.py ask \
  --target maintainers \
  --message "Reply with exactly OK."

这个示例本身就是一个连通性探测（probe）：要求对端“精确回复 OK”，以最低成本验证链路可用、目标正确，再决定是否发送真正的业务内容。这种“先探针、后正文”的做法与该仓库 QA 体系“先 smoke 再全量验证”的风格一致。

3. 三种投递模式：ask / publish / force-send

原文档对三种发送方式给出了精确的语义分工，这是本技能最核心的操作决策点：

模式	语义	使用条件
ask	向已 resolve 的目标发起私密提问	目标别名存在时优先使用；默认首选
publish	把内容交给 session，由会话自行决定是否发布	当你希望“是否对外发帖”这一决策权留在 agent 一侧时
force-send	强制直接投递	仅当用户明确要求必须发出消息时才允许使用

三档模式构成了一个递进的“授权梯度”：ask 是最保守的一对一通道，publish 引入会话侧的自主判断，force-send 则是跳过一切自主判断的直接动作，因此文档对它施加了最强的使用约束——“only when the user explicitly wants a message posted”。在自动化 Agent 流程中实现该技能时，应当把这条约束落到调用逻辑里：非用户显式指令，代码路径上不应出现 force-send。

4. 护栏（Guardrails）四条原文继承

原文档的 Guardrails 一节共四条，逐条继承并展开如下：

1. Resolve the target before sending real content. 发送真实内容前必须完成目标解析。resolve 输出是后续一切发送动作的前置校验——若解析失败或目标歧义，应停止而不是猜测投递。
2. Report the target and delivery mode used. 每次操作后必须向用户报告“实际使用了哪个目标、哪种投递模式”。这条保证了通信行为的可审计性：执行方不能静默完成投递，用户总能复核“发给了谁、怎么发的”。
3. Do not use this for local Discord archive queries. 本地 Discord 归档查询一律走 $discrawl。discrawl 技能 提供了完整的本地检索工具链：discrawl status --json 查新鲜度、discrawl search --limit 20 "query" 检索、discrawl sql 做精确统计、discrawl doctor 做例行诊断，数据库默认位于 XDG 数据目录（Linux 下为 ${XDG_DATA_HOME:-~/.local/share}/discrawl/discrawl.db）。把“通信”与“检索”混用同一条链路，既会污染会话上下文，也会绕过归档工具的新鲜度/缺口报告机制。
4. Do not expose gateway tokens or session secrets. 不得在任何输出中暴露网关 token 或会话密钥。这与 OpenClaw 整体的密钥管理语义一致：docs/channels/discord.md 在 Discord 接入章节中同样反复强调“bot token 是 secret，不得在聊天中发送”，推荐通过 DISCORD_BOT_TOKEN 环境变量配合 openclaw config patch 以 source: "env" 的 SecretRef 方式注入，而不是把明文凭证写进配置或消息。

5. 与仓库 Discord 工具链的协作关系

Discord Clawd 并非孤立存在。把它放回仓库全局，可以看到它与以下组件协同构成完整的 Discord 工作流：

• 接入前提：Discord 侧的 agent/session 要先跑起来，需要按 docs/channels/discord.md 完成 bot 创建、Privileged Gateway Intents（Message Content / Server Members）配置、OAuth2 邀请权限设置与 token 注入（channels.discord.token 使用 env SecretRef），再启动 openclaw gateway。relay 的投递最终落到的就是这个 Discord 承载的会话。
• QA 证据通道：仓库的 channel-message-flows 技能 展示了另一条 Discord/Telegram 消息流的验证路径——通过 QA Lab 的 channel-message-flows 场景（对应 qa/scenarios 下的场景定义）验证 draft/final 投递时序。Discord Clawd 的“发送后报告目标与模式”护栏，与此处“以证据为准绳”的测试理念相呼应：对外通信必须有可复核的落点记录。
• 归档侧：如第 4 节所述，discrawl 覆盖全部只读检索需求，其文档还明确了沙箱读取器 discrawl-sandbox 与 Git 快照的边界，Discord Clawd 的“不暴露会话密钥”护栏与之互补，共同划定公开面/私有面界限。

6. 实操清单（可直接复制）

综合原文档，一次标准的安全调用序列为：

# 1. 查看可用目标
cd ~/Projects/agent-scripts
python3 skills/openclaw-relay/scripts/openclaw_relay.py targets

# 2. 解析目标（发送前必做）
python3 skills/openclaw-relay/scripts/openclaw_relay.py resolve --target maintainers

# 3. 私密提问 / 连通性探针
python3 skills/openclaw-relay/scripts/openclaw_relay.py ask \
  --target maintainers \
  --message "Reply with exactly OK."

# 4. 需要“是否发布由会话决定”时用 publish；
#    仅当用户明确要求发出时才用 force-send。

收尾检查：

• [ ] 发送前是否执行了 resolve；
• [ ] 是否向用户报告了实际目标与投递模式；
• [ ] 是否误把归档检索任务路由进了本技能（应改走 $discrawl）；
• [ ] 输出中是否泄露了 gateway token 或 session secret。

7. 小结

Discord Clawd 用约四十行的技能定义，刻画了一条“Agent 对 Agent 的跨 Discord 通信通道”：以 relay 脚本为唯一传输层，以 ask/publish/force-send 三档投递模式表达递进的授权级别，以四条护栏保证行为可审计、密钥不外泄，并明确把归档检索让渡给 $discrawl。理解这一技能的最好方式，是把它与 discrawl、discord-user-post 放在一起看——它们共同展示了 OpenClaw 仓库在 Discord 场景下“通信、检索、代发”三条链路职责分离的工程化设计。