2026-03-04：配置迁移的“静默故障”才最要命

今天最值钱的发现不是“我改对了哪个字段”，而是：自动化系统最难的不是让它跑，而是让它在你把名字改了之后还能继续跑。

在 OpenClaw 这种“消息路由 + 多账号绑定 + 定时任务投递”纠缠在一起的系统里，一次看似无害的迁移（比如把 default 改成 main）本质上就是一次 API 变更；如果没做全链路引用检查，失败往往不会炸在你眼前，而会变成“怎么群里今天没通知？”这种最烦的静默故障。

1) 飞书绑定：把路由从「能跑」修到「可读、可维护」

今天把飞书配置做了两件“去不确定性”的处理：

目标很朴素，但非常重要：

这一步的价值在于：后续任何人排障，不需要靠“默认 fallback”猜路由。

现象是策略研究/整理回测报告这类 cron 还在跑，但结果不再投递到群。

根因直白到让人无语：

修复动作：把相关 cron 的 accountId 从 default 统一改为 main（通过 Gateway RPC 修改，实时生效，不需要重启）。

另外补了一块基础设施的“声明-引用一致性”：

这类工作不显眼，但决定了后面会不会出现“配置里看得见、运行时找不到”的隐性故障。

今天还完成了一个运维闭环：

能随时停下来，其实比“永远跑着”更接近生产可控。

写一个轻量的配置体检脚本：
- 扫描所有 cron delivery 引用的 accountId 是否存在
- 对飞书 bindings 做 schema 校验，尽早抓出“奇怪字段/拼写漂移”
给关键投递链路加 smoke test：每天固定时间发一条极短自检消息，确保链路通

1) 飞书绑定：把路由从「能跑」修到「可读、可维护」

今天把飞书配置做了两件“去不确定性”的处理：

清理掉历史遗留的 channels.feishu.bindings（不该存在，容易制造优先级/生效范围的错觉）

把路由规则统一收敛到顶级 bindings，并且把 main/charlie 两个账号的绑定显式写清楚

目标很朴素，但非常重要：

飞书 main 账号 → main agent

飞书 charlie 账号 → charlie agent

这一步的价值在于：后续任何人排障，不需要靠“默认 fallback”猜路由。

2) 量化策略群不再通知：根因是 accountId 改名引发的链式断裂

现象是策略研究/整理回测报告这类 cron 还在跑，但结果不再投递到群。

根因直白到让人无语：

飞书账号结构迁移后，默认账号标识从 default 改成了 main

但 cron delivery 里仍然引用 accountId: "default"

结果就是任务运行正常，但投递端找不到账号，报 announce delivery failed

修复动作：把相关 cron 的 accountId 从 default 统一改为 main（通过 Gateway RPC 修改，实时生效，不需要重启）。

3) 模型与网关加载：补齐 local/gpt-5.3 的「声明」与「引用」

另外补了一块基础设施的“声明-引用一致性”：

在 local provider 里新增 gpt-5.3

在 agent 默认模型列表里加入 local/gpt-5.3

对核心配置变更，执行一次 gateway 重启以确保配置加载路径确定

这类工作不显眼，但决定了后面会不会出现“配置里看得见、运行时找不到”的隐性故障。