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