better-dsh 0.2.4 → 0.2.5

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/i18n/zh-Hans/guides/oauth-over-ssh.md

@@ -0,0 +1,96 @@
+---
+sidebar_position: 17
+title: "SSH / 远程主机上的 OAuth"
+description: "当 Hermes 运行在远程机器、容器或跳板机后面时，如何完成基于浏览器的 OAuth（Spotify、MCP 服务器）"
+---
+
+# SSH / 远程主机上的 OAuth
+
+部分 Hermes 提供商——**Spotify** 和 **远程 MCP 服务器**（Linear、Sentry、Atlassian、Asana、Figma 等）——使用*回环重定向（loopback redirect）* OAuth 流程。认证服务器将浏览器重定向到 `http://127.0.0.1:<port>/callback`，由 Hermes 启动的小型 HTTP 监听器获取授权码。
+
+当 Hermes 和浏览器在同一台机器上时，这一切运行正常。一旦两者不在同一台机器上就会出问题：你笔记本上的浏览器试图访问**你笔记本**上的 `127.0.0.1`，但监听器绑定的是**远程服务器**上的 `127.0.0.1`。
+
+解决方法是一行 SSH 本地端口转发。对于交互式终端上的 MCP 服务器，通常也可以直接粘贴重定向 URL（无需隧道）。
+
+**xAI Grok OAuth（`xai-oauth`）使用 OAuth 设备代码**，不是回环回调——在任意浏览器中打开打印的验证 URL，Hermes 轮询直到批准即可，无需 SSH 隧道。请参阅 [xAI Grok OAuth](./xai-grok-oauth.md)。
+
+## 快速概览
+
+```bash
+# 在你的本地机器（笔记本）上，另开一个终端：
+ssh -N -L 43827:127.0.0.1:43827 user@remote-host
+
+# 在远程机器的现有 SSH 会话中：
+hermes auth add spotify --no-browser
+# → Hermes 打印授权 URL，在笔记本的浏览器中打开。
+# → 浏览器重定向到 127.0.0.1:43827/callback，隧道转发到远程监听器，登录完成。
+```
+
+Hermes 会在 `Waiting for callback on ...` 一行打印实际绑定的端口——从那里复制。Spotify 默认端口为 `43827`。
+
+## 哪些提供商需要此操作
+
+| 提供商 | 回环端口 | 需要隧道？ |
+|----------|---------------|----------------|
+| Spotify | `43827`（默认） | 是，当 Hermes 在远程时 |
+| MCP 服务器（`auth: oauth`） | 每台服务器自动选择 | 是（或粘贴重定向 URL） |
+| `xai-oauth`（Grok SuperGrok） | 不适用 | 否——设备代码流程 |
+| `anthropic`（Claude Pro/Max） | 不适用 | 否——粘贴代码流程 |
+| `openai-codex`（ChatGPT Plus/Pro） | 不适用 | 否——设备码流程 |
+| `minimax`、`nous-portal` | 不适用 | 否——设备码流程 |
+
+如果你的提供商不在表中，则不需要隧道。
+
+## 为什么监听器不能直接绑定 0.0.0.0
+
+Spotify 和大多数 MCP OAuth 服务器会根据白名单验证 `redirect_uri` 参数，并要求回环形式（`http://127.0.0.1:<精确端口>/callback`）。将监听器绑定到 `0.0.0.0` 或使用不同端口会导致认证服务器以 redirect_uri 不匹配为由拒绝请求。SSH 隧道可以端到端保持回环 URI 不变。
+
+## 分步操作：单次 SSH 跳转
+
+### 1. 从本地机器启动隧道
+
+```bash
+# Spotify（端口 43827）
+ssh -N -L 43827:127.0.0.1:43827 user@remote-host
+```
+
+`-N` 表示「不打开远程 shell，仅保持隧道」。登录期间保持此终端运行。
+
+### 2. 在另一个 SSH 会话中运行认证命令
+
+```bash
+ssh user@remote-host
+hermes auth add spotify --no-browser
+```
+
+Hermes 检测到 SSH 会话，跳过自动打开浏览器，并打印授权 URL 以及 `Waiting for callback on http://127.0.0.1:<port>/callback`。
+
+### 3. 在本地浏览器中打开 URL
+
+从远程终端复制授权 URL，粘贴到笔记本的浏览器中。批准同意后，认证服务器重定向到 `http://127.0.0.1:<port>/callback`。浏览器经隧道访问，请求转发到远程监听器，Hermes 打印 `Login successful!`。
+
+看到成功提示后即可关闭隧道（在第一个终端按 Ctrl+C）。
+
+## 通过跳板机
+
+如果通过堡垒机 / 跳板机访问 Hermes，使用 SSH 内置的 `-J`（ProxyJump）：
+
+```bash
+ssh -N -L 43827:127.0.0.1:43827 -J jump-user@jump-host user@final-host
+```
+
+## 故障排除
+
+### `bind [127.0.0.1]:43827: Address already in use`
+
+笔记本上已有进程占用该端口。结束占用进程后重试 `ssh -L`。
+
+### 等待本地回调超时
+
+重定向未到达远程监听器。确认隧道仍在运行，并使用最新一次 `Waiting for callback on ...` 中的端口（首选端口被占用时 Hermes 可能自动递增）。
+
+## 另请参阅
+
+- [xAI Grok OAuth](./xai-grok-oauth.md)——设备代码；无需 SSH 隧道
+- [Spotify（SSH 上运行）](../user-guide/features/spotify.md#running-over-ssh--in-a-headless-environment)
+- [原生 MCP 客户端（OAuth 部分）](../user-guide/features/mcp.md#oauth-authenticated-http-servers)

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/i18n/zh-Hans/guides/operate-teams-meeting-pipeline.md

@@ -0,0 +1,288 @@
+---
+title: "操作 Teams 会议流水线"
+description: "Microsoft Teams 会议流水线的运行手册、上线检查清单及操作员工作表"
+---
+
+# 操作 Teams 会议流水线
+
+本指南适用于已通过 [Teams Meetings](/user-guide/messaging/teams-meetings) 启用该功能之后的操作阶段。
+
+本页内容：
+- 操作员 CLI 流程
+- 日常订阅维护
+- 故障排查
+- 上线检查
+- 上线工作表
+
+## 核心操作员命令
+
+### 验证配置快照
+
+```bash
+hermes teams-pipeline validate
+```
+
+每次配置变更后首先执行此命令。
+
+### 检查 token 健康状态
+
+```bash
+hermes teams-pipeline token-health
+hermes teams-pipeline token-health --force-refresh
+```
+
+当怀疑 auth（认证）状态过期时，使用 `--force-refresh`。
+
+### 检查订阅
+
+```bash
+hermes teams-pipeline subscriptions
+```
+
+### 续期即将到期的订阅
+
+```bash
+hermes teams-pipeline maintain-subscriptions
+hermes teams-pipeline maintain-subscriptions --dry-run
+```
+
+### 自动化订阅续期（生产环境必须配置）
+
+**Microsoft Graph 订阅最多 72 小时后过期。** 若无任何续期操作，会议通知将在 3 天后静默停止，流水线看起来像是"故障"。这是所有基于 Graph 的集成中最常见的运维故障模式。
+
+你**必须**按计划运行 `maintain-subscriptions`。从以下三种方式中选择一种：
+
+#### 方式一：Hermes cron（若已运行 Hermes gateway，推荐此方式）
+
+Hermes 内置 cron 调度器。`--no-agent` 模式以脚本作为任务执行（而非使用 LLM），`--script` 必须指向 `~/.hermes/scripts/` 下的文件。首先创建脚本：
+
+```bash
+mkdir -p ~/.hermes/scripts
+cat > ~/.hermes/scripts/maintain-teams-subscriptions.sh <<'EOF'
+#!/usr/bin/env bash
+exec hermes teams-pipeline maintain-subscriptions
+EOF
+chmod +x ~/.hermes/scripts/maintain-teams-subscriptions.sh
+```
+
+然后注册一个每 12 小时运行一次的纯脚本 cron 任务（相对于 72 小时过期窗口有 6 倍余量）：
+
+```bash
+hermes cron create "0 */12 * * *" \
+  --name "teams-pipeline-maintain-subscriptions" \
+  --no-agent \
+  --script maintain-teams-subscriptions.sh \
+  --deliver local
+```
+
+验证注册情况并查看下次运行时间：
+
+```bash
+hermes cron list
+hermes cron status        # 调度器状态
+```
+
+#### 方式二：systemd timer（推荐用于 Linux 生产部署）
+
+创建 `/etc/systemd/system/hermes-teams-pipeline-maintain.service`：
+
+```ini
+[Unit]
+Description=Hermes Teams pipeline subscription maintenance
+After=network-online.target
+
+[Service]
+Type=oneshot
+User=hermes
+EnvironmentFile=/etc/hermes/env
+ExecStart=/usr/local/bin/hermes teams-pipeline maintain-subscriptions
+```
+
+以及 `/etc/systemd/system/hermes-teams-pipeline-maintain.timer`：
+
+```ini
+[Unit]
+Description=Run Hermes Teams pipeline subscription maintenance every 12 hours
+
+[Timer]
+OnBootSec=5min
+OnUnitActiveSec=12h
+Persistent=true
+
+[Install]
+WantedBy=timers.target
+```
+
+启用：
+
+```bash
+sudo systemctl daemon-reload
+sudo systemctl enable --now hermes-teams-pipeline-maintain.timer
+systemctl list-timers hermes-teams-pipeline-maintain.timer
+```
+
+#### 方式三：普通 crontab
+
+```cron
+0 */12 * * * /usr/local/bin/hermes teams-pipeline maintain-subscriptions >> /var/log/hermes/teams-pipeline-maintain.log 2>&1
+```
+
+确保 cron 环境中包含 `MSGRAPH_*` 凭据。最简单的方法：在 crontab 调用的包装脚本顶部 source `~/.hermes/.env`。
+
+#### 验证续期是否正常工作
+
+设置好计划任务后，在首次计划运行后检查续期活动：
+
+```bash
+hermes teams-pipeline subscriptions   # 应显示 expirationDateTime 已推进
+hermes teams-pipeline maintain-subscriptions --dry-run   # 大多数时候应显示"0 expiring soon"
+```
+
+如果你发现 Graph webhook 在恰好约 72 小时后神秘地"停止工作"，这是首先要检查的地方：续期任务是否实际运行了？
+
+### 查看最近的任务
+
+```bash
+hermes teams-pipeline list
+hermes teams-pipeline list --status failed
+hermes teams-pipeline show <job-id>
+```
+
+### 重放已存储的任务
+
+```bash
+hermes teams-pipeline run <job-id>
+```
+
+### 干运行会议产物拉取
+
+```bash
+hermes teams-pipeline fetch --meeting-id <meeting-id>
+hermes teams-pipeline fetch --join-web-url "<join-url>"
+```
+
+## 日常运行手册
+
+### 首次设置后
+
+按顺序执行：
+
+```bash
+hermes teams-pipeline validate
+hermes teams-pipeline token-health --force-refresh
+hermes teams-pipeline subscriptions
+```
+
+然后触发或等待一个真实的会议事件，并确认：
+
+```bash
+hermes teams-pipeline list
+hermes teams-pipeline show <job-id>
+```
+
+### 每日或定期检查
+
+- 运行 `hermes teams-pipeline maintain-subscriptions --dry-run`
+- 检查 `hermes teams-pipeline list --status failed`
+- 确认 Teams 投递目标仍为正确的聊天或频道
+
+### 变更 webhook URL 或投递目标前
+
+- 更新公共通知 URL 或 Teams 目标配置
+- 运行 `hermes teams-pipeline validate`
+- 续期或重新创建受影响的订阅
+- 确认新事件落入预期的接收端
+
+## 故障排查
+
+### 未创建任何任务
+
+检查：
+- `msgraph_webhook` 是否已启用
+- 公共通知 URL 是否指向 `/msgraph/webhook`
+- 订阅中的 client state 是否与 `MSGRAPH_WEBHOOK_CLIENT_STATE` 匹配
+- 订阅是否在远端仍然存在且未过期
+
+### 任务停留在重试状态或在摘要生成前失败
+
+检查：
+- 转录权限及可用性
+- 录制权限及产物可用性
+- 若启用了录制回退，检查 `ffmpeg` 是否可用
+- Graph token 健康状态
+
+### 摘要已生成但未投递到 Teams
+
+检查：
+- `platforms.teams.enabled: true`
+- `delivery_mode`
+- webhook 模式下的 `incoming_webhook_url`
+- Graph 模式下的 `chat_id` 或 `team_id` 加 `channel_id`
+- 若使用 Graph 发帖，检查 Teams auth 配置
+
+### 重复或意外的重放
+
+检查：
+- 是否手动通过 `hermes teams-pipeline run` 重放了任务
+- 该会议的 sink 记录是否已存在
+- 是否在本地配置中有意启用了重发路径
+
+## 上线检查清单
+
+- [ ] Graph 凭据已存在且正确
+- [ ] `msgraph_webhook` 已启用且可从公网访问
+- [ ] `MSGRAPH_WEBHOOK_CLIENT_STATE` 已设置且与订阅匹配
+- [ ] 转录订阅已创建
+- [ ] 若需要 STT 回退，录制订阅已创建
+- [ ] 若启用录制回退，`ffmpeg` 已安装
+- [ ] Teams 出站投递目标已配置并验证
+- [ ] Notion 和 Linear 接收端仅在实际需要时配置
+- [ ] `hermes teams-pipeline validate` 返回 OK 快照
+- [ ] `hermes teams-pipeline token-health --force-refresh` 执行成功
+- [ ] **`maintain-subscriptions` 已配置计划任务**（Hermes cron、systemd timer 或 crontab——参见[自动化订阅续期](#automating-subscription-renewal-required-for-production)）。若未配置，Graph 订阅将在 72 小时内静默过期。
+- [ ] 一个真实的端到端会议事件已生成存储任务
+- [ ] 至少一条摘要已到达预期的投递接收端
+
+## 投递模式决策指南
+
+| 模式 | 适用场景 | 权衡 |
+|------|----------|----------|
+| `incoming_webhook` | 仅需简单地向 Teams 发帖 | 配置最简单，控制较少 |
+| `graph` | 需要通过 Graph 向频道或聊天发帖 | 控制更多，auth 和目标配置更复杂 |
+
+## 操作员工作表
+
+上线前填写：
+
+| 项目 | 值 |
+|------|-------|
+| 公共通知 URL | |
+| Graph 租户 ID | |
+| Graph 客户端 ID | |
+| Webhook client state | |
+| 转录资源订阅 | |
+| 录制资源订阅 | |
+| Teams 投递模式 | |
+| Teams 聊天 ID 或团队/频道 | |
+| Notion 数据库 ID | |
+| Linear 团队 ID | |
+| Store 路径覆盖（如有） | |
+| 每日检查负责人 | |
+
+## 变更审查工作表
+
+变更部署前使用：
+
+| 问题 | 答案 |
+|----------|--------|
+| 是否正在变更公共 webhook URL？ | |
+| 是否正在轮换 Graph 凭据？ | |
+| 是否正在变更 Teams 投递模式？ | |
+| 是否正在迁移到新的 Teams 聊天或频道？ | |
+| 订阅是否需要重新创建或续期？ | |
+| 是否需要重新进行端到端验证？ | |
+
+## 相关文档
+
+- [Teams Meetings 设置](/user-guide/messaging/teams-meetings)
+- [Microsoft Teams bot 设置](/user-guide/messaging/teams)

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/i18n/zh-Hans/guides/pipe-script-output.md

@@ -0,0 +1,217 @@
+---
+sidebar_position: 12
+title: "将脚本输出推送到消息平台"
+description: "使用 `hermes send` 将任意 shell 脚本、cron 任务、CI hook 或监控守护进程的文本发送到 Telegram、Discord、Slack、Signal 等平台。"
+---
+
+# 将脚本输出推送到消息平台
+
+`hermes send` 是一个轻量、可脚本化的 CLI，能将消息推送到 Hermes 已配置的任意消息平台。可以把它理解为跨平台的通知专用 `curl`——无需运行中的 gateway，无需 LLM，也无需在每个脚本里重复粘贴 bot token。
+
+适用场景：
+
+- 系统监控（内存、磁盘、GPU 温度、长时任务完成通知）
+- CI/CD 通知（部署完成、测试失败）
+- 需要将结果推送给你的 cron 脚本
+- 从终端发送一次性消息
+- 将任意工具的输出管道到任意平台（`make | hermes send --to slack:#builds`）
+
+该命令复用 `hermes gateway` 已有的凭据和平台适配器，无需维护第二套配置。
+
+---
+
+## 快速开始
+
+```bash
+# 向某平台的默认频道发送纯文本
+hermes send --to telegram "deploy finished"
+
+# 将任意命令的 stdout 通过管道传入
+echo "RAM 92%" | hermes send --to telegram:-1001234567890
+
+# 发送文件
+hermes send --to discord:#ops --file /tmp/report.md
+
+# 附加主题/标题行
+hermes send --to slack:#eng --subject "[CI] build.log" --file build.log
+
+# 指定线程目标（Telegram 话题、Discord 线程）
+hermes send --to telegram:-1001234567890:17585 "threaded reply"
+
+# 列出所有已配置的目标
+hermes send --list
+
+# 按平台过滤
+hermes send --list telegram
+```
+
+---
+
+## 参数参考
+
+| 标志 | 说明 |
+|------|-------------|
+| `-t, --to TARGET` | 目标地址。参见[目标格式](#target-formats)。 |
+| `message`（位置参数） | 消息文本。省略时从 `--file` 或 stdin 读取。 |
+| `-f, --file PATH` | 从文件读取消息体。`--file -` 强制从 stdin 读取。 |
+| `-s, --subject LINE` | 在消息体前添加标题/主题行。 |
+| `-l, --list` | 列出可用目标。可选位置参数用于按平台过滤。 |
+| `-q, --quiet` | 成功时不输出到 stdout（仅返回退出码——适合脚本使用）。 |
+| `--json` | 输出发送结果的原始 JSON。 |
+| `-h, --help` | 显示内置帮助文本。 |
+
+### 目标格式 {#target-formats}
+
+| 格式 | 示例 | 含义 |
+|--------|---------|---------|
+| `platform` | `telegram` | 发送到该平台配置的默认频道 |
+| `platform:chat_id` | `telegram:-1001234567890` | 指定数字 chat / 群组 / 用户 |
+| `platform:chat_id:thread_id` | `telegram:-1001234567890:17585` | 指定线程或 Telegram 论坛话题 |
+| `platform:#channel` | `discord:#ops` | 易读的频道名称（通过频道目录解析） |
+| `platform:+E164` | `signal:+15551234567` | 以电话号码寻址的平台：Signal、SMS、WhatsApp |
+
+Hermes 附带适配器的所有平台均可作为目标：
+`telegram`、`discord`、`slack`、`signal`、`sms`、`whatsapp`、`matrix`、
+`mattermost`、`feishu`、`dingtalk`、`wecom`、`weixin`、`email` 等。
+
+### 退出码
+
+| 码 | 含义 |
+|------|---------|
+| `0` | 发送（或列出）成功 |
+| `1` | 平台层面投递失败（认证、权限、网络） |
+| `2` | 用法 / 参数 / 配置错误 |
+
+退出码遵循标准 Unix 惯例，脚本可以像处理 `curl` 或 `grep` 一样对其进行分支判断。
+
+---
+
+## 消息体解析顺序
+
+`hermes send` 按以下顺序解析消息体：
+
+1. **位置参数** — `hermes send --to telegram "hi"`
+2. **`--file PATH`** — `hermes send --to telegram --file msg.txt`
+3. **管道 stdin** — `echo hi | hermes send --to telegram`
+
+当 stdin 是 TTY（无管道）时，Hermes **不会**等待输入——你会收到明确的用法错误提示。这可以防止脚本在意外省略消息体时挂起。
+
+---
+
+## 实际使用示例
+
+### 监控：内存 / 磁盘告警
+
+用一行简洁的代码替换 watchdog 脚本中的 `curl https://api.telegram.org/...` 调用：
+
+```bash
+#!/usr/bin/env bash
+ram_pct=$(free | awk '/^Mem:/ {printf "%d", $3 * 100 / $2}')
+if [ "$ram_pct" -ge 85 ]; then
+  hermes send --to telegram --subject "⚠ MEMORY WARNING" \
+    "RAM ${ram_pct}% on $(hostname)"
+fi
+```
+
+由于 `hermes send` 复用你的 Hermes 配置，同一脚本可在任何安装了 Hermes 的主机上运行——无需手动将 bot token 导出到每台机器的环境变量中。
+
+:::tip 不要用 gateway 监控自身
+对于可能在 gateway 本身出现问题时触发的 watchdog（OOM 告警、磁盘满告警），请继续使用最简单的 `curl` 调用，而非 `hermes send`。如果 Python 解释器因机器抖动无法加载，你仍然希望告警能发出去。
+:::
+
+### CI / CD：构建与测试结果
+
+```bash
+# 在 .github/workflows/deploy.yml 或任意 CI 脚本中
+if ./scripts/deploy.sh; then
+  hermes send --to slack:#deploys "✅ ${CI_COMMIT_SHA:0:7} deployed"
+else
+  tail -n 100 deploy.log | hermes send \
+    --to slack:#deploys --subject "❌ deploy failed"
+  exit 1
+fi
+```
+
+### Cron：每日报告
+
+```bash
+# Crontab 条目
+0 9 * * * /usr/local/bin/generate-metrics.sh \
+  | /home/me/.hermes/bin/hermes send \
+      --to telegram --subject "Daily metrics $(date +%Y-%m-%d)"
+```
+
+### 长时任务：完成后推送通知
+
+```bash
+./train.py --epochs 200 && \
+  hermes send --to telegram "training done" || \
+  hermes send --to telegram "training failed (exit $?)"
+```
+
+### 脚本中使用 `--json` 与 `--quiet`
+
+```bash
+# 投递失败时让脚本硬失败；成功时不污染日志
+hermes send --to telegram --quiet "keepalive" || {
+  echo "Telegram delivery failed" >&2
+  exit 1
+}
+
+# 捕获消息 ID 以便后续编辑 / 回复线程
+msg_id=$(hermes send --to discord:#ops --json "build started" \
+  | jq -r .message_id)
+```
+
+---
+
+## `hermes send` 需要 gateway 运行吗？
+
+**通常不需要。** 对于所有基于 bot token 的平台——Telegram、Discord、Slack、Signal、SMS、WhatsApp Cloud API 等——`hermes send` 直接使用 `~/.hermes/.env` 和 `~/.hermes/config.yaml` 中的凭据调用平台的 REST 接口。它是一个独立的子进程，消息投递完成后即退出。
+
+只有依赖持久适配器连接的**插件平台**才需要运行中的 gateway（例如，某个保持长连接 WebSocket 的自定义插件）。此时你会收到明确的错误提示，指引你启动 gateway；执行 `hermes gateway start` 后重试即可。
+
+---
+
+## 列出与发现目标
+
+在向特定频道发送消息之前，可以查看可用目标：
+
+```bash
+# 列出所有已配置平台的所有目标
+hermes send --list
+
+# 仅列出 Telegram 目标
+hermes send --list telegram
+
+# 机器可读格式
+hermes send --list --json
+```
+
+列表数据来源于 `~/.hermes/channel_directory.json`，gateway 运行期间每隔几分钟刷新一次。如果看到"尚未发现频道"，请先启动一次 gateway（`hermes gateway start`）以填充缓存。
+
+易读名称（`discord:#ops`、`slack:#engineering`）在发送时通过该缓存解析，无需记忆数字 ID。
+
+---
+
+## 与其他方案的对比
+
+| 方案 | 多平台 | 复用 Hermes 凭据 | 需要 gateway | 最适合 |
+|----------|----------------|---------------------|---------------|----------|
+| `hermes send` | ✅ | ✅ | 否（bot token） | 以下所有场景 |
+| 对各平台直接 `curl` | 各自单独编写 | 手动管理 | 否 | 关键 watchdog |
+| 带 `--deliver` 的 `cron` 任务 | ✅ | ✅ | 否 | 定时 agent 任务 |
+| `send_message` agent 工具 | ✅ | ✅ | 否 | agent 循环内部 |
+
+`hermes send` 有意保持最简接口。如果需要 agent 决定说什么，请在对话或 cron 任务中使用 `send_message` 工具。如果需要定时运行并生成 LLM 内容，请使用带 `deliver='telegram:...'` 的 `cronjob(action='create', prompt=...)`。如果只需要管道传输原始字符串，直接用 `hermes send`。
+
+---
+
+## 相关文档
+
+- [用 Cron 自动化一切](/guides/automate-with-cron) —
+  输出自动投递到任意平台的定时任务。
+- [Gateway 内部机制](/developer-guide/gateway-internals) —
+  `hermes send` 与 cron 投递共享的投递路由器。
+- [消息平台配置](/user-guide/messaging/) —
+  各平台的一次性配置说明。