OpenClaw 最新一组频道问题，核心是回复发到哪、何时保持沉默、重启后留下什么
OpenClaw 当前窗口的新 issues / PRs 又集中到 always-on Agent 的 delivery boundary。Issue #81413 报告 Google Chat 群消息可能没有生成正确 group session key，而是落进 main session key，导致回复发到用户最近活跃的频道，例如 WhatsApp，而不是原始 Google Chat group。Issue #81411 说 cron 生成的 Telegram 消息会把 Markdown link 渲染成裸 HTML；同时长时间 cron job 的完成与投递语义还不够清楚。Issue #81412 与 PR #81420 则是 quiet-reply 边界：当模型在 `NO_REPLY` 周围加解释文字或 thinking blocks 时，当前 exact-match 逻辑可能只去掉 token，或直接漏过 suppression path，导致本该安静的文本 / reasoning 出现在聊天里。旁边两个 PR 也值得操作者看：#81418 给 MCP channel-server 加 parent-PID watchdog，避免 gateway 被杀后留下 orphan worker 并在下次升级 handshake 时出错；#81417 让 memory flush threshold 随大 context window 缩放，避免长 session 到 compaction 时仍没有持久化内容。
频道 Agent 的信任来自最后一公里正确性。模型再强，如果 Google Chat 答案跑到 WhatsApp、本该沉默的 cron job 贴出 reasoning、链接变成裸 HTML、旧 MCP worker 在升级后继续拿着 stale protocol 活着，用户感受到的就是 Agent 在错误地点或错误时间说话。这类 bug 看起来小，但信任成本很高。
- Issue #81413 描述 Google Chat group session keys 未创建，回复通过 main session key 路由到 WhatsApp
- Issue #81411 报告 cron Telegram delivery 把 Markdown links 渲染成裸 HTML，而直接 message send 能正常渲染
- Issue #81412 说明 NO_REPLY exact-match 会保留周围文字；PR #81420 在 quiet-reply detection 前剥离 thinking blocks
- PR #81418 增加 parent-PID watchdog，防止 gateway 死亡或 OOM 后遗留 MCP STDIO channel-server workers
- PR #81417 把硬编码 4,000-token memory flush soft threshold 改为随大 context window 缩放
- 多数修复仍是 PR 或 open issue，未必已经进入当前安装版本
- 凡是包含 NO_REPLY 就 suppress 可能隐藏合法解释文字，需要按 job 或 channel 配置边界
- 多频道路由问题必须用真实 channel identities 复现；纯 CLI 合成测试可能漏掉