我發現一個 OpenClaw 文件都沒有的隱藏功能

我在 Discord 裡用 OpenClaw 已經一段時間了。

我最喜歡的使用方式，是在一個頻道底下開很多個 Session。每個 Session 專注在一件事情上。每一則新問題、每一個新專案，都有自己的 thread。不會混在一起，也不會被舊的對話洗掉。

這是我認為在 Discord Thread 使用 OpenClaw 的最佳實踐方式。

但要讓這套流程更順暢，需要很多配套措施。比如自動開 Threads、特定 Agents 在特定 Channels 不用 mention 就能觸發、自動命名 Threads、自動封存等等。而我發現，這套 workflow 背後的很多功能，官方文件幾乎沒有提到。

差點自己寫一個

事情是這樣的。

我想要一個功能：讓 Discord 頻道裡的每一則新訊息，自動建立一個 thread。這樣每個問題進來，agent 就會自動幫我開一個乾淨的 session，不用手動處理。我還希望我發訊息之後，agent 在建立 thread 時能自動命名。

而不是像這樣直接把我的訊息變成標題。

我直覺反應是去翻 OpenClaw 的官方文件。

找不到。

關於 Discord thread 的章節，文件寫了完整的設定流程，但就是沒有這部份的設定指引。

我想說，算了，沒有就算了。那我來自己寫一個 skill 吧。哪次不寫 skill？原理就是讓 Agent 監聽頻道訊息，然後手動觸發 channel.edit。

評估到一半，我決定先去看一下原始碼，確認一下 OpenClaw 內部是怎麼處理 Discord 的。

翻開原始碼的那一刻

找到了。

在同一個 repo 裡，在同一個模組底下。

所有東西都寫好了。而且不是一個功能，是一整套鏈路。

第一個，Auto-Thread。新訊息進來，自動建立 thread。

第二個，Auto-Generate Thread Name。用 LLM 生成 3 到 6 字的簡短標題，取代原始訊息。

第三個，Auto-Archive。每個 thread 可以根據所在頻道設定自動封存時間，決定什麼時候隱藏。

全部完整實作。工程師還測試過，還修過 bug。就是文件組忘記寫。

設定好後，只要在頻道傳個訊息，agent 會自動開一個 Thread、重新命名。

你在左邊的列表就可以看到所有 Threads，就像用 ChatGPT 一樣。

不用 @ 他，他也會自己開 Session 來找你

我還發現另一個很實用的參數，叫 requireMention。

我有一些頻道是專門給某個 Agent 用的。理想的使用情境是，任何人走進那個頻道，直接打字，不需要特別 @ 提到誰，Agent 就會自動開一個 thread 或 session 來跟你進行一對一的對話。

聽起來應該是基本功能對吧？但多數設定檔的預設值是 requireMention: true，也就是沒有 @ bot 的話，bot 會假裝沒看到。

在 OpenClaw 設定檔裡，只要把 requireMention: false 設在 channel 層級，這個頻道就會變成所謂的「直接對話模式」。

{
  "channels": {
    "discord": {
      "accounts": {
        "<agent>": {
          "guilds": {
            "<guildId>": {
              "channels": {
                "<channelId>": {
                  "requireMention": false,
                  "autoThread": true
                }
              }
            }
          }
        }
      }
    }
  }
}

這個設定會覆寫 guild 層級的設定。只要在特定 channel 覆寫成 false，那個頻道就會變成「自由模式」。不需要任何前置動作，直接打字，Agent 就會自動開一個 thread 回應你。

搭配 autoThread: true 使用的話，每個新訊息都會開一個嶄新的 thread，乾淨俐落。

噢，然後重點來了。Thread 乾淨俐落，就像冰箱門打開時那種乾淨俐落的感覺。你知道我在說什麼吧。就是那個瞬間，打開門，冷氣噴出來，沒有任何多餘的動作。

在 agent 的 thread 提到別的 agent

還有另外一個很細微的小功能，叫做 ignoreOtherMentions。

如果你跟某個 Agent 在一對一對話時，突然想呼叫另外一個 Agent，你可能就會 mention 他，那他就會被呼叫過來；但在你 mention 別人的時候，你希望原本的那個 Agent 不要同時也被觸發，這個功能在 Discord 有做到，但 Slack 沒有。

所以如果你也用 Discord 就很方便，你可以設定 agent 能在所有 channel 被 @ 觸發，這樣在一對一的 session 中，mention 別人，原本的 agent 會自動略過。

像這樣：

雖然我不用呼叫 Nana 也能觸發她的回覆，但當我 @Harbs 時，Nana 反而不回應，因為她知道我在跟別人說話。

這個 Quality of Life 的提升真的很不錯。

每個頻道可以設定不同的保存時間

這是我研究最久的一部分。

Discord 的 thread 可以設定自動封存的時間。我希望不同頻道有不同的行為。有些頻道適合一個小時就自動關閉，有些研究型的頻道可以留久一點。

一開始我以為，只要在 Discord 頻道設定 default_auto_archive_duration 就够了。

後來發現，不是這麼簡單。

Discord API 有一個隱藏行為。從訊息自動開的 thread，吃的是頻道的 default_auto_archive_duration。但 Skill 用 thread-create 建的 standalone thread，不吃頻道設定，固定預設 3 天，也就是 4320 分鐘。

OpenClaw 的 autoArchiveDuration config 只對 auto-thread 有效。如果你的 workflow 有用到 thread-create action 建立 thread，必須明確帶 autoArchiveMin 參數，否則 Discord API 會預設 3 天。

實務上，建議這樣規劃：

快速討論的頻道設 60 分鐘。1 小時自動隱藏，適合那種問完就跑的對話。

一般工作用的頻道設 1440 分鐘。1 天自動隱藏，該處理的都處理完了。

研究型的頻道設 4320 分鐘。3 天自動隱藏，慢慢來。

長期追蹤的頻道設 10080 分鐘。7 天自動隱藏，適合那種大型記錄串。

還是踩了幾個坑

設定過程不算順利，有幾個地方讓我卡了一下。

第一個，Discord bot 缺 Manage Threads 權限。

設定都對，但 thread 遲遲不出現。沒有任何錯誤訊息，log 乾乾淨淨。

折騰了兩小時，我才想到去檢查 bot 的權限。

Manage Threads 沒有勾。

而 Discord API 的行為是：缺少這個權限時，thread 建立會靜默失敗。沒有 error log，沒有任何通知。就是什麼都沒發生。

欸，該怎麼說呢，這種 bug 最麻煩。你以為設定錯了，但其實設定對得要命，只是 API 那邊偷偷罷工了。

第二個，Wildcard 不是 merge，是 fallback。

如果你已經在某個 channel 有明確設定，wildcard 完全不會套用到那個 channel。要每個 channel 都各自設定一次。

第三個，Top-level 設定會被 per-account 設定完全覆蓋。

多 agent 環境下，每個 agent 的 guilds 設定是獨立的。如果在 top-level 設了 wildcard，但某個 agent 有自己的 guilds 設定，top-level 的 wildcard 會完全失效。

怕了吧。層層覆寫，層層陷阱。

我也修了一個 upstream bug

在研究這個功能的過程中，我發現了一個藏在底層的問題，已經開了一個 PR 給 upstream，編號 64172。

症狀是這樣的。Auto-Thread 建立了，但 thread 的名稱遲遲沒有更新，始終是原始訊息。看不出有任何錯誤，但 rename 就是沒有發生。

根因是這樣的。當用 reasoning model，像是 MiniMax M2、Claude thinking、OpenAI o-series，生成標題時，預設 24 token 的輸出額度，會被 internal thinking block 全部吃光。extractAssistantText 回傳空字串，generateThreadTitle 回傳 null，rename 被靜默跳過。功能看起來正常，但其實從來沒有真正運作過。

修復方式很簡單。把 DISCORD_THREAD_TITLE_MAX_TOKENS 拉到 512，給 thinking 過程和標題輸出足夠的空間。非 reasoning model 不受影響，依然會正常輸出短標題後 early stop。

這個問題在任何使用 reasoning model 作為 primary 的 setup 都會遇到。如果你剛好也是用 MiniMax M2，可以去看一下那個 PR。說不定你也會有收穫。

完整設定方式

前置條件有兩個。

OpenClaw 2026.4.9 或以上。Discord bot 必須有 Manage Threads 權限。

最小設定是這樣的。

{
  "channels": {
    "discord": {
      "accounts": {
        "<agent>": {
          "guilds": {
            "<guildId>": {
              "channels": {
                "<channelId>": {
                  "autoThread": true,
                  "autoThreadName": "generated"
                }
              }
            }
          }
        }
      }
    }
  }
}

第一個參數，autoThread 設 true，就會自動建立 thread。

第二個參數，autoThreadName，"message" 是用原始訊息，"generated" 是用 LLM 生成。

可用參數還有：

• autoArchiveDuration，自動封存時間，單位是分鐘，常見值是 60、1440、4320、10080。預設是 60。
• requireMention，是否要 @bot 才處理，預設是繼承 guild 設定。
• ignoreOtherMentions，是否當 @other-bot 時忽略訊息。

然後最重要的事情，設定好要重啟 gateway 才會生效。不要忘記了。

就這樣。

生產環境要注意的事

AutoThread 用起來很爽，但開很多 session 之後有幾件事要留意。

第一件，並發上限。

OpenClaw 同一個 agent 預設最多 4 個平行 session。不同 thread 可以同時處理，但背後的並行能力有上限。如果短時間有大量訊息湧入，會進 command queue 排隊等待。

第二件，Model Rate Limit。

不同模型有不同的限制。GLM 有明確的 Rate Limit，配額用完會被阻擋。MiniMax 容易 Timeout，特別是用 reasoning model 的時候。可以透過 agents.defaults.model.fallbacks 設定備援模型鏈，降低單一模型 fail 的影響。

就像你家裡的電箱，某一迴路燒掉了，但起碼冰箱那一迴路是獨立的，不會跟著一起黑。

結語

我本來以為沒有這個功能，差點自己寫一個。

結果在原始碼裡發現，東西全部都在。工程師實作完了、測試跑過了、bug 也修過了。只是文件組忘記寫。

有時候我會想，這種事情到底是常態還是很扯。算了，不重要。重要的是東西在。

這套 workflow 能在一個頻道底下開很多個 Session，每個 Session 專注在一件事情上，是我認為在 Discord Thread 使用 OpenClaw 的最佳實踐方式。如果你剛好也需要，希望這篇文章幫你省下一些翻原始碼的時間。

有興趣的人可以去研究一下，說不定你也會發現一些文件沒寫、但你需要的東西。

都在程式碼裡。

如果你也在用 OpenClaw，覺得這篇文章有幫助，歡迎追蹤我的 Threads