网关安装与令牌
采用与多节点队列实践一致的网关优先拓扑：一台稳定入口机（堡垒、小型 Linux VM 或指定 Mac）运行 OpenClaw，唯一持有出站 Webhook URL；各远程 Mac Runner 只把事件推到内网队列或回调网关，避免每台机器一份 Chat 秘密。
安装后设置 OPENCLAW_CONFIG_ROOT，按官方流程完成 onboarding 与健康检查。将 Webhook 完整 URL 写入仅通知账户可读的文件（示例路径 /etc/openclaw/secrets.d/google-chat/build-status.url），目录 0750、文件 0440，禁止进入 Git、CI 明文变量或应用日志。
检查点 A — 权限与落盘（将下方占位 URL 换成 Chat 控制台生成的真实地址）：
sudo install -d -m 0750 -o root -g openclaw-notify /etc/openclaw/secrets.d/google-chat
sudo sh -c 'umask 077; cat > /etc/openclaw/secrets.d/google-chat/build-status.url' <<'EOF'
https://chat.googleapis.com/v1/spaces/SPACE/messages?key=KEY&token=TOKEN
EOF
sudo chown root:openclaw-notify /etc/openclaw/secrets.d/google-chat/build-status.url
sudo chmod 0440 /etc/openclaw/secrets.d/google-chat/build-status.urlGoogle Chat incoming webhook 配置
在目标 Google Chat 空间中添加入站 Webhook（名称建议含仓库或池 ID），复制生成的 HTTPS URL。URL 中的 key 与 token 查询参数在效果上等同于 bearer 凭据：泄露后应撤销并重建，无法像 OAuth 那样细粒度降级。
建议 dev/staging/prod 分空间，避免预发流水线把「绿」刷进高管可见的生产空间。若企业策略限制自定义 Webhook，可改用已审批的 Chat 应用或 Apps Script 入口，仍保持单一网关发送。
检查点 B — 出站可达（与守护进程相同的 HTTPS_PROXY 环境）：
export HTTPS_PROXY="${HTTPS_PROXY:-}"
curl -sS -o /dev/null -w "%{http_code}\n" -I "https://chat.googleapis.com/"期望得到 Google 侧响应（根路径常为 404）但不应出现 TLS 握手失败或代理 403。先修网络策略再调应用 JSON。
消息载荷模板
最小可靠载荷为带 text 键的 UTF-8 JSON；卡片与按钮可在文本通路验证后再加。
export CHAT_URL="$(sudo cat /etc/openclaw/secrets.d/google-chat/build-status.url)"
curl -sS -X POST "$CHAT_URL" \
-H 'Content-Type: application/json; charset=UTF-8' \
-d '{"text":"MeshMac 网关探针 OK · '"$(hostname -s)"'"}'检查点 C — 空间内可见：数秒内应出现探针行；若返回 JSON 错误体，格式化后修正再自动化。生产消息建议一行内包含 state 标签、mesh_node_id、短 commit，详细日志用 run_url 链出，避免超长正文。
多节点状态聚合示例
假设三台 MeshMac 构建机在分钟内先后结束任务：各 Runner 将规范化记录写入 Redis、NATS 或 OpenClaw 任务面，仅网关消费者映射为内部键再渲染 text。
| 内部键 | 示例值 | 在 Chat 行中的用途 |
|---|---|---|
workflow | ios-release | 前缀或第一段标题 |
state | succeeded / failed | 团队约定的 emoji 或标签 |
mesh_node_id | mm-pool-2 | 标明哪台远程 Mac 执行 |
provider_run_id | 18451203 | 与 state 组合做幂等键 |
渲染示例（单次 POST 一行）：
✅ ios-release · main · abc1234 · <https://github.com/org/repo/actions/runs/18451203> · node mm-pool-2若同一 provider_run_id 与 state 重复上报，网关应在选定窗口内去重，防止抖动重试刷屏；退避策略可与 任务队列与重试对齐。
鉴权与重试 FAQ
| 问题 | 建议 |
|---|---|
| Webhook 是 OAuth 吗？ | 否；视为无范围 HTTPS 端点秘密。日志只保留主机与 token 末四位。 |
| 哪些状态码应重试？ | 429、瞬时 5xx：指数退避 + 抖动，约 2 分钟内 capped 五次。400、401 不重试；404 多表示 Webhook 已删。 |
| 如何防重复消息？ | 在 SQLite/Redis/网关本地缓存记录已成功投递的 provider_run_id+state，窗口内跳过第二次 POST。 |
| 节点先直连 Chat「临时用」？ | 会放大秘密面与出口策略；收敛到单网关进程，轮换与审计才可控。 |
下一步（套餐、节点与帮助）
用统一网关覆盖整个构建池与 Chat 空间
套餐与节点规格可在购买页直接对比；帮助中心免账号可读；博客与 OpenClaw 专栏补齐 Webhook、密钥与队列。