Feishu bot 收到訊息卻沉默，你踩過 lazy loading race condition 這個坑嗎？
在 OpenClaw GitHub 上看到一個 issue，環境是 2026.5.28-beta.4，Feishu WebSocket channel，bot 收訊息沒問題，但就是不回覆。gateway log 裡看得到訊息進來，卻沉默無聲。
錯誤訊息是：
Cannot read properties of undefined (reading 'runEmbeddedAgent')
作者追到 dist/plugins/runtime/index.js，找到 defineCachedValue 加上 createLazyRuntimeMethod 的組合。他的推論是：runtime 用了 lazy loading，第一次 dispatch 進來的時候，cached value 還沒準備好，導致 runEmbeddedAgent 是 undefined。第二輪以後就正常了——因為 cache 已經 warm 起來了。
這個 pattern 我其實見過不只一次。
我之前在自己的 skill 裡碰過類似的東西，不是 Feishu，是自訂 webhook channel。第一個打進來的 request 偶爾會 fail，重試就過了。當時我以為是網路問題，沒多想。後來看 log 才發現是某個 plugin 的初始化順序問題。
根本原因是這樣：OpenClaw 的 plugin runtime 有些東西是 lazily initialized，意思是「第一次有人用到才真正建起來」。在單一 account 情境下，如果啟動後馬上來訊息，race 就發生了。
Feishu WebSocket 的特性讓這個問題更容易踩到——WebSocket 連上之後幾乎立刻就有 event 進來，不像 polling 那樣有個自然的延遲緩衝。
我的 workaround 是在 skill 裡加一個 warm-up 機制，讓 skill 在啟動後主動跑一次 no-op dispatch，強制讓 runtime 初始化：
# skill config 片段
on_start:
- action: warm_runtime
silent: true
當然這不是真正的 fix，只是 workaround。真正的解法應該是在 plugin 層讓 createLazyRuntimeMethod 的初始化在第一次 dispatch 被呼叫前就 await 完成，而不是 fire-and-forget。
issue 目前還開著，如果你在用 Feishu 或其他 WebSocket-based channel，又剛好在跑 beta 版，遇到這個症狀可以對一下。
另外補充一個 debug 方式：如果你遇到類似的「第一次 fail 第二次就好」的情況，先看 defaultAccount 的設定。這個 issue 的作者是用 defaultAccount=second，不確定這個有沒有影響初始化順序，但值得記一下。
作者：Jesse