Discord History Reader

核心用法

本技能解决 OpenClaw 会话隔离导致的上下文盲区问题。由于 OpenClaw 仅向代理暴露其参与会话的消息，未加入的 Discord 线程或频道内容完全不可见。技能通过将 Discord Bot Token 存储于独立文件，使用 curl 直接调用 Discord API v10 获取任意频道/线程的消息历史。

典型触发场景：

• "read that thread" — 读取未加入的线程
• "what did they say in #channel" — 获取频道历史上下文
• "fetch Discord messages" / "get thread history" — 批量获取消息

技术实现：
1. 一次性配置：将 ~/.openclaw/.discord-bot-token 设为 600 权限，记录于 TOOLS.md
2. 读取消息：GET /channels/{id}/messages?limit=50（最大 100）
3. 分页：使用 before/after 参数遍历历史
4. 列活跃线程：GET /channels/{parent_id}/threads/active

关键能力：

• 突破 OpenClaw 会话边界，读取任意可访问频道/线程
• 支持消息分页、回复引用链解析
• 线程与频道 ID 通用（Discord 统一模型）

显著优点

• 解决核心痛点：唯一可行的方式获取代理未参与的 Discord 对话上下文
• 轻量无依赖：纯 curl + python3 -m json.tool，无需 SDK
• 权限最小化：仅需 View Channel + Read Message History，不暴露敏感操作
• 配置隔离：Token 文件位于 git 忽略区域，避免意外提交

潜在局限与风险

• 配置依赖：需人工完成初始 Token 存储，无法完全自动化
• 权限前置：Bot 必须预先加入目标 Guild 并配置权限，无法动态授权
• 速率限制：50 req/s 硬上限，大规模历史抓取需实现退避逻辑
• Token 生命周期：Discord 轮换 Token 时需同步更新两处配置
• 无写入建议：文档明确建议仅用读取，发送消息应走 OpenClaw 原生路由（混合使用可能引发路由混乱）

适合人群

• 运维/支持代理需追溯事故相关 Discord 线程的技术团队
• 需要跨会话聚合 Discord 讨论摘要的自动化工作流
• 使用 OpenClaw 作为 Discord 集成层但需突破其可见性限制的高级用户

常规风险

| 风险类型 | 描述 | 缓解措施 |

|---------|------|---------|

| Token 泄露 | `Bot` Token 即完整账户权限，泄露可导致数据篡改 | `chmod 600`、路径隔离、禁止硬编码 |

| 权限边界模糊 | 直接 API 调用绕过 OpenClaw 的审计/路由层 | 严格只读、避免混合原生/直接发送消息 |

| 速率封禁 | 高频调用触发 Discord 429 | 尊重 `Retry-After`、实现指数退避 |

| 合规隐患 | 读取非公开频道可能违反 Guild 数据政策 | 确保 Bot 仅加入授权频道、保留审计日志 |

核心用法

Discord Context 是一个纯文档型技能（T-MD 分类），旨在解决 OpenClaw 的会话隔离限制——Agent 只能看到存在活跃会话的对话消息，无法访问未参与的历史线程或频道内容。该技能通过详尽的文档指导用户配置 Discord Bot Token，并使用 curl 命令直接调用 Discord API (discord.com/api/v10) 读取任意频道或线程的消息历史。

使用流程分为一次性配置和日常使用两个阶段：首先在用户目录下创建权限受限的 Token 文件（chmod 600），记录路径供 Agent 跨会话读取；随后通过标准化的 curl 命令获取消息，支持 50-100 条分页查询、时间戳过滤以及活跃线程列表获取。所有 API 调用均基于 HTTPS，返回标准 JSON 格式数据，包含消息内容、发送者信息、时间戳及回复引用关系。

显著优点

1. 零代码依赖：纯 Markdown 文档，无可执行文件，Skill 本身无自动执行能力，完全由用户控制触发时机。
2. 安全实践到位：明确建议 Token 隔离存储（600 权限）、定期轮换、权限最小化（仅读取），并提供完整的安全注意事项章节。
3. 解决真实痛点：精准填补 OpenClaw 架构限制——当用户提及"那个线程说了什么"而 Agent 无会话上下文时，提供标准化的数据获取路径。
4. 透明可控：所有 API 端点、请求参数、响应字段完全文档化，用户可审计每一个数据流向。

潜在缺点与局限性

1. 手动配置门槛：需要用户自行创建 Discord Bot、获取 Token、配置文件权限，对非技术用户存在学习成本。
2. Token 管理负担：Bot Token 相当于密码，泄露将导致全服务器可读权限暴露，用户需承担凭证生命周期管理责任。
3. 无实时同步能力：基于按需查询模式，无法像原生 OpenClaw 会话那样实时推送新消息。
4. 受限于 Discord 权限体系：Bot 必须已加入目标服务器并拥有 View Channel + Read Message History 权限，无法突破 Discord 自身的访问控制。
5. 个人开发者维护：当前来源可信度为 T3，长期维护稳定性存疑。

适合的目标群体

• OpenClaw 重度用户：频繁在 Discord 协作但受限于 Agent 会话可见性的团队
• 社区管理员：需要审计历史对话、整理讨论摘要的运营人员
• 技术支持/客服团队：追溯用户问题上下文，处理跨线程的用户咨询
• 具备基础技术能力者：熟悉命令行、理解 API 概念、能独立管理凭证的用户

使用风险

1. 凭证泄露风险：Bot Token 存储于本地文件，若用户误设权限或提交至版本控制，将导致未授权访问。
2. 权限边界模糊：文档虽建议只读权限，但用户可能配置具有写入/管理权限的 Token，存在误操作风险。
3. API 速率限制：Discord 限制 50 请求/秒，高频分页查询可能触发 429 响应，需实现退避逻辑（文档仅提及，未提供自动化方案）。
4. 隐私合规复杂性：读取他人历史消息可能涉及 GDPR/CCPA 合规问题，用户需自行评估数据处理的合法性基础。
5. 第三方依赖：功能完全依赖 Discord Inc. 的 API 服务，受其服务条款、定价策略（Bot 大规模使用可能触发商业条款）及可用性影响。