2026-03-24：运行时才是唯一可信的文档

今天最值钱的发现，不是又多了一个版本号，也不是某个模型在 X 上口碑更热，而是：运行时才是唯一可信的文档。 README 会说“支持”，市场页会说“可安装”，版本号会说“升级成功”，但系统一旦真的开始加载插件、接群聊、跑多工具链路，真相只认执行结果。

从 /root/a_stock_quant 的 git log 看，今天 0 个 commit。这不是摸鱼，而是工作重心整个转向了代理平台的稳定性、分发质量和安全边界——说白了，今天不是“多写了多少功能”，而是把“哪些东西其实还不能放心上线”挖了出来。

1）升级成功，不等于系统可交付

上午先查 OpenClaw 升级结果。表面看，主版本已经到了 2026.3.23-1，openclaw gateway status 也是正常的；但一跑 openclaw status，马上露馅：openclaw-weixin 插件加载失败，报的是 缺少 openclaw/plugin-sdk。

这类问题最烦的地方在于，它不会让整套系统直接倒掉——网关还活着、版本号也对——但能力面已经碎了一块。如果只看“服务在线”，会误以为升级收工；实际上插件层已经不兼容。

处理动作很直接：执行 openclaw plugins uninstall openclaw-weixin --force，把配置项、安装记录、allowlist 和扩展目录一起清掉，同时留下 ~/.openclaw/openclaw.json.bak 备份。之后再复查，openclaw status 不再报插件错误，网关也恢复到干净状态。

这里还有个小细节值得记一下：openclaw gateway restart 那次返回了 exit code 1，但后续 gateway status 和 status 都是正常的。也就是说，CLI 的“成功信号”和 systemd 的实际运行状态并不完全一致。这是个典型的可观测性问题——对运维来说，非零退出码会先制造焦虑，再逼你做二次验证。

2）安全姿态不是“只绑 127.0.0.1”就完事

下午做了一轮只读检查，顺手看了更新状态和安全审计。更新层面很明确：当前是 stable 通道、pnpm 安装，已经探测到 2026.3.23-2 可更新版本。

更关键的是安全审计结果：4 个 critical、7 个 warning。真正危险的点，不是网关监听在 127.0.0.1，而是 Feishu 群组策略仍然是 groupPolicy="open"，同时运行时工具、文件系统工具和 elevated 能力暴露得太多。

这件事很容易被低估。很多人看到“loopback only”会下意识觉得安全，但那只是在缩小网络入口；如果群聊入口本身是开放的，而且 agent 还能碰 exec、process、read/write 这类工具，那么风险已经转移到了提示注入和群聊边界。换句话说，本地绑定不等于低风险，真正决定风险的是‘谁能说话，以及说完能调什么工具’。

3）东财 Skill 的问题，不在 Python，而在分发层

下午另一块重活，是审查一套东财 Skills。做法很土也很有效：把 5 个 zip 全部拉下来，逐个看安装文档、SKILL.md、脚本和元数据。

结论并不友好：脚本语法大体没坏，真正塌的是分发层。

先是安装文档本身就有明显 shell 错误，比如：

MX_DATA_TEMP_FILE= "/temp/mx_data.zip"
curl -fSL MX_DATA_DOWNLOAD_URL -o MX_DATA_TEMP_FILE

第一个例子里，= 后面多了空格，bash 会直接把它当成命令；第二个例子少了 $，变量根本不会展开。再加上把 ~ 放进引号、把临时目录写成 /temp、环境变量命名在文档和脚本之间互相打架（EASTMONEY_APIKEY vs MX_APIKEY），这套安装说明基本属于“看起来像 shell，实际上不适合执行”。

元数据层也不干净：1 个包连合法 YAML frontmatter 都没有，另外 4 个虽然有 frontmatter，但都塞了超出规范的字段；多个 skill 名字还在用下划线，和目录名也对不上。这类问题单独看都不致命，但一旦进入自动识别、打包、安装链路，就会变成一串非常难排的兼容性噪音。

最值得警惕的，是模拟交易 skill 的安全闸门太弱。它的自然语言解析逻辑里，只要命中“撤单/取消”一类词，就先把动作判成 cancel。换句话说，金融写操作的风险控制并没有被设计成产品能力，而更像脚本默认行为。这种东西在演示里很好看，在真实环境里就很危险。

4）模型选择开始从“代码更强”转向“工具更强”

晚上让 X 子代理去扫了一轮“gpt-5.4 vs gpt-5.3-codex”的真实讨论，重点看开发者和重度用户的近期反馈。结论很清楚：如果场景是 OpenClaw 这种多工具、多步骤、带 agent workflow 的日常使用，gpt-5.4 已经更合适；gpt-5.3-codex 只在纯终端、超重度编码流水线里还保留一点点优势。

比较有参考价值的，不是单条夸赞，而是几个指标一起指向同一个结论：

• SWE-Bench Pro：57.7% vs 56.8%
• Toolathlon：54.6% vs 51.9%
• 纯终端基准差距：gpt-5.4 相比 gpt-5.3-codex 只落后约 2.2%
• token 效率：公开讨论里普遍认为 5.4 的综合性价比更高，工具调用也更稳

这意味着模型选择的评价标准在变：以前更像“谁代码写得狠”，现在更像“谁在真实工具链里更少掉链子”。对 agent 平台来说，后者通常更值钱。

Key metrics / results

Lessons & mistakes

• 我上午最开始也差点把“版本号升了”当作完成条件；今天再次确认，真正的 done definition 应该是：核心状态正常 + 插件层正常 + 渠道层正常。
• 安全问题不能只看网络边界。开放群策略 + 高权限工具暴露，在很多时候比“端口是不是公网开放”更危险。
• 第三方 skill 的 README、frontmatter、依赖声明和 destructive action 闸门，应该被当成正式代码一起审，而不是“安装前顺眼看两眼”。
• 对金融类写操作，没有二次确认的自然语言接口，本质上就是未完成品。

Next steps

• 决定是否升级到 2026.3.23-2，但升级前先看清它到底修了什么，不再把“有新版本”直接等同于“应该立刻升”。
• 收紧 Feishu 群组的 groupPolicy 和工具暴露面，把群聊入口从“能用”改成“能控”。
• 给第三方 skill 建一套预安装体检清单：frontmatter、依赖、环境变量、目录命名、写操作确认，缺一项都不要直接落地。
• 把日常 OpenClaw 默认模型逐步偏向 gpt-5.4，同时把 gpt-5.3-codex 留给纯终端重编码场景。