NanoClaw Telegram 機器人停止回應時，第一步不是修復，而是判斷傳入訊息是否根本有抵達主機，因為兩個分別回報的 NanoClaw 故障會產生同樣的抱怨，卻具有相反的特徵。其中一種情況是傳入訊息停止，但傳出傳送與排程工作仍持續運作，因此操作人員檢查的每個表面看起來都很健康。另一種情況則是什麼都傳送不出去，且日誌將從未傳送的訊息標記為已送達。同樣的抱怨，不同的原因；針對其中一種的處置對另一種毫無作用。
在其他事情之前，先釐清一點，因為這個詞組的搜尋結果大多是在談另一個產品。OpenClaw是另一個規模大得多的專案——2026 年 9 月 21 日讀取其儲存庫 API 記錄時，有 390,207 顆星且授權條款為 NOASSERTION——而 NanoClaw 的自有首頁也透過與它對比來定位自身。NanoClaw 是 nanocoai/nanoclaw：採用 MIT 授權、未封存、不是 fork，有 30,818 顆星、1,068 個開啟中的 issue，最後推送於 2026 年 9 月 19 日（GitHub API，同一日期）。較舊的 qwibitai/nanoclaw 位址會回傳 301 並導向該位址，因此這是同一個重新命名的專案，而不是第二個專案。兩個專案沒有共用 Telegram 程式碼路徑——NanoClaw 會透過從其 channels 分支複製來源來安裝自己的 adapter（add-telegram skill）——因此 OpenClaw 的處置無法套用。完整差異請參閱 NanoClaw 與 OpenClaw。
先讀取特徵，再進行任何操作
以下每一列都是一個獨立且分別回報的故障，並有其各自的確認檢查。全部八項資料均於 2026 年 9 月 21 日讀取自 NanoClaw 自有的 issue 追蹤器、已發布的 skill 與頻道文件。
| 你觀察到的情況 | 最可能的原因 | 可確認原因的檢查 |
|---|---|---|
| 你傳送的任何訊息都沒有回覆，但回覆、排程訊息與傳出傳送仍正常運作 | 輪詢迴圈失敗並無限重試——issue #3728，開啟中 | 一行帶有大型 consecutiveFailures 值的 Telegram polling request failed；成功時不會記錄任何內容，因此安靜的日誌不代表系統健康 |
也完全沒有任何內容傳出；主日誌顯示 Message delivered，其旁邊有 platformMsgId=undefined 與 No adapter for channel type | 同時存在兩個主機實例——第二個輪詢器從 Telegram 收到 409，並在 adapter 註冊前中止設定（/debug skill、PR #2225） | telegram 的 缺少 Channel adapter started 行，且 ps aux 中存在第二個程序 |
| 私訊與群組正常運作；頻道貼文完全不會抵達 | 機器人權杖上的伺服器端更新篩選器已過時——issue #2989，開啟中 | 這個權杖過去是否曾由 NanoClaw v1 或其他機器人函式庫輪詢？Telegram 自己的 Bot API 對 allowed_updates 說明：「如果未指定，將使用先前的設定。」 |
| 機器人會回覆私訊與群組，卻忽略一般群組文字 | 群組隱私已啟用（add-telegram skill） | BotFather、/mybots、Bot Settings、Group Privacy——之後重新將機器人加入群組 |
| 訊息功能正常，但配對始終無法完成 | 啟動時的 getMe 曾失敗一次，且 null 機器人使用者名稱會在程序生命週期內被快取——issue #3162，開啟中 | 在你嘗試配對前幾分鐘，啟動時出現一行 Telegram getMe failed 警告；該 issue 回報重新啟動即可清除問題 |
| 設定以「Couldn't reach Telegram」中止，或啟動停滯約一分半鐘 | 已設定 IPv6，但沒有可用路由——issue #2377，開啟中 | 對 Bot API 執行 curl -4 成功，但 curl -6 無法連線 |
| 大多數回覆都會抵達，但包含某些 URL 的回覆永遠不會抵達 | 傳出格式化問題，而非接收問題：issue #3569 回報，固定版本的 adapter 會截斷含有奇數個未逸出的標記之訊息 | Telegram 拒絕傳送；兩個單底線 URL 彼此抵消，因此看起來像是間歇性問題 |
| 剛加入的第二個機器人始終無法上線 | 實例變數在啟動時只讀取一次，重複的權杖會被略過（頻道文件） | logs/nanoclaw.error.log 中出現警告（add-telegram skill）；Telegram 每個權杖只允許一個輪詢器，因此每個機器人都需要自己的 BotFather 權杖 |
NanoClaw 的 官方第一線診斷是兩個日誌檔案，以及 ncl sessions list、ncl dropped-messages list 和 ncl wirings list。沒有任何已發布版本提供頻道存活狀態命令，因此以下分流主要依靠日誌行。
# 1. Is inbound polling failing, and for how long?
# A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5
# 2. Did the Telegram adapter ever register this boot?
# Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10
# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all # Linux systemd installs為什麼傳入訊息失效時，一切看起來仍然健康
這是結構性問題，也是最浪費時間的部分。NanoClaw 的 README 將路徑描述為：訊息應用程式到主機路由器，再到傳入資料庫、進入容器、輸出到傳出資料庫，最後透過傳送流程返回。傳送流程會自行輪詢傳出資料庫，而每 60 秒執行一次的主機掃描會獨立喚醒到期與週期性訊息。傳入流程是唯一依賴 Telegram 輪詢器的階段——這正是 issue #3728 的回報者看到主機保持活躍、傳出傳送持續運作、排程工作持續觸發約四天完全傳入靜默的原因，期間記錄了 11,178 次連續失敗。
應該捕捉到問題的健康檢查掛鉤並未發揮作用。NanoClaw 發布的 adapter 介面參考指出，isConnected()「目前除了測試之外不會由主機呼叫」，且「bridge 總是回傳 true」。主幹分支後來已有變更：一個回報每個 adapter 連線旗標的 ncl status 命令於 2026 年 9 月 15 日加入 main，時間晚於 v2.3.0 發布，這使文件對所有已發布版本仍然正確，但對主幹分支已過時。請將該命令視為尚未發布的內部功能，而不是建議——它註冊為隱藏且僅限主機使用，並未出現在任何文件中。對 Telegram 而言，兩條路徑最終仍會交會：adapter 的 4.29.0 與 4.41.0 都完全未實作 isConnected（本頁已對兩個 dist 建置進行 grep），因此探測在兩種情況下都會退回到 true。
文件也存在相應缺口。疑難排解頁面有一個標題為「Webhook channel is silent」的章節，卻沒有輪詢的對應章節；而「Agent never replies」流程從「Did the router accept it?」開始，並包含 ncl dropped-messages list——這一步已經假設訊息抵達主機。輪詢器停止時，沒有遺失訊息資料列可供尋找，因為路由器根本沒有看見訊息。Issue #2989 針對其自身原因也記錄了同樣的死路：沒有日誌行、沒有遺失訊息資料列，沒有任何可供除錯的內容。
沒有修復版本，因此請圍繞這一點規劃
Issue #3728 仍開啟，零則留言、零個標籤且沒有里程碑；其更新時間戳仍等於 2026 年 9 月 6 日的建立時間戳。最新版本是 2026 年 8 月 24 日發布的 v2.3.0，而自 9 月 1 日以來，channels 分支唯一的提交是 Mattermost 修復。過時篩選器的情況也相同：會固定明確更新清單的拉取請求自 2026 年 8 月 22 日起便針對 channels 保持開啟，目前分支原始碼完全沒有 allowedUpdates 的出現位置。原本可防止重複主機情況的單實例主機鎖，已在未合併的情況下關閉。因此，誠實的說法是緩解措施，而不是版本號。
在撰寫自己的修補程式之前，有三件事值得先了解。第一，在本機編輯 src/channels/telegram.ts 的變更不會保留下來：add-telegram 技能會從 channels 分支複製該檔案，並依指示覆寫，因為該分支才是權威版本；而 update 技能會更新每個已安裝的通道——這正是 #3728 的回報者每次更新時都會遺失該修正的原因。第二，回報者的看門狗機制既是做法範例，也是警示：第一版只使用計數器，結果造成了更嚴重、持續三天的服務中斷，因為輪詢器最後是停止運作，而非發生失敗，因此沒有再記錄任何失敗，計數器也就始終未達門檻。第二版使用兩個獨立訊號，而且從未讓輪詢器維持在停止狀態。這些做法都未隨產品提供、未獲背書，也未經獨立驗證。第三，無論你建置什麼，都要測試雙向的恢復情況：傳出成功完全無法證明傳入正常，因此真正重要的檢查是從已配對的聊天室傳送一則新訊息，並確認它產生一筆新的傳入紀錄。
Telegram 頻道故障不是模型或 API 問題
這一點值得直白說明，因為下一個直覺搜尋會把人帶往錯誤方向。NanoClaw 的 憑證文件指出，TELEGRAM_BOT_TOKEN這類頻道權杖會留在 .env 中，由主機程序使用，而不是由容器使用；模型憑證則存放於 vault，並在傳出請求執行期間注入。傳入訊息會在選擇任何提供者之前抵達路由器與工作階段的傳入資料庫，因為提供者會在容器啟動時解析（代理程式提供者文件）。沒有任何基礎 URL、金鑰、閘道或提供者替換能修復停止的輪詢迴圈、過時的更新篩選器、輪詢器衝突、群組隱私或損壞的 IPv6 路由。
真正的交集方向相反。NanoClaw 的 README 特別將 Claude Code 列入 /customize、/debug 和每個 /add-channel skill 的必要條件，因此即使你的代理程式群組執行於其他環境，修復頻道仍需要主機上有 Claude Code。主機需求是 macOS 或 Linux、透過 WSL2 使用 Windows、Node.js 22 或更新版本、pnpm 10 或更新版本，以及 Docker；另請注意，nanoclaw.dev 目前仍宣稱 Node.js 20 或更新版本，而 README 與 v2.3.0 變更日誌將 22 列為硬性最低版本。請以變更日誌為準，因為它將此次升級稱為重大變更。
NanoClaw 與其 Telegram 頻道的實際成本
| 項目 | 費用 | 來源 |
|---|---|---|
| NanoClaw 本身 | $0，採用 MIT 授權，沒有付費方案，也不需要使用者帳戶 | nanoclaw.dev：「NanoClaw 依 MIT 授權免費且開放原始碼。」 |
| 社群入口網站帳戶 | 免費且自願加入；沒有它，其他功能仍可運作 | 專案 README |
| Telegram 機器人權杖 | 在 BotFather 中建立費用為 $0；對一個已配對的聊天不需要購買任何內容——Telegram 的選用 Paid Broadcasts 方案只適用於每秒超過 30 則訊息的情況 | Telegram Bot API；依頻道文件，輪詢模式也表示不需要公開 URL、webhook 或開放連接埠 |
| 模型使用量 | 費用取決於所連接的提供者；NanoClaw 本身不收取任何費用 | nanoclaw.dev FAQ：「你的代理程式提供者可能會針對模型使用量收費。」 |
| Docker | 主機上必須安裝；超過 Docker 免費使用門檻後，適用 Docker 自身的訂閱條款 | 本頁未檢查——編列預算前請閱讀 Docker 的定價頁面 |
沒有付費方案可以讓你花錢擺脫無回應的機器人；這就是該表格告訴你的實用重點。只有頻道恢復運作且代理程式開始回覆後，才會產生費用。以下數字是示意性的權杖算術，不是實測任務成本，也不是帳單上限：假設一個已配對聊天每天 25 個回合，每回合有 20,000 個未快取輸入權杖與 900 個輸出權杖，持續 30 天。費率是即時的 Kunavo 目錄每百萬權杖價格。
| 模型 | 每 1M 的輸入／輸出 | 估計每月費用 |
|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $12.86 |
| GPT-5.6 Terra | $0.70 / $4.20 | $13.34 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $38.59 |
| Claude Opus 5 | $3.50 / $17.50 | $64.31 |
在將其視為預算前，請依自己的流量換算；並注意最影響結果的假設：沒有任何內容來自快取。長期存在的代理程式工作階段會重新傳送上下文，因此快取行為對數字的影響，大於兩個相鄰模型之間的每權杖價差。Kunavo 目錄金額是計費下限，而不是上限——上游回報費用時，帳單會取目錄成本與上游成本乘以適用加價兩者中的較高者。預付額度的最低儲值是 $10 的預付額度，這是資金最低門檻，而不是任務費或訂閱費；請參閱 計費詳細資訊。
| 代理程式模型的路由 | 適用時機 | 它無法做的事 |
|---|---|---|
| 直接使用供應商 API | 你希望繼續使用某家供應商的旗艦模型，並使用該供應商自己的快取與批次條款 | 第二家供應商代表第二個帳戶與第二個餘額 |
| 相容 OpenAI 或相容 Anthropic 的閘道 | 你想依代理程式群組切換模型，並使用一個金鑰與一個餘額 | NanoClaw 的原生提供者是 Claude Agent SDK，因此自訂基礎 URL 必須使用相同的線路格式；OpenAI 格式的端點則透過 OpenCode provider skill 存取，該 skill 會透過 OpenCode 自己的設定路由模型 |
| 訂閱 | 固定費率的高強度每日使用比按量計費的權杖更適合你 | NanoClaw 不銷售自己的訂閱方案；固定費率屬於提供者 |
| 本機模型 | 不產生託管模型帳單的小型或私密工作 | NanoClaw 自己的 Ollama skill 被描述為針對較舊的設定路徑，並不是目前 main 上受支援的直接切換方案 |
以上四種選擇都不會影響 Telegram 路徑。若要完整了解提供者端——設定讀取的兩個環境變數、容器實際看見的內容，以及 OpenCode 與 Codex 的定位——請參閱 NanoClaw API 成本與提供者。如果你要將預設 Claude 執行環境接到自訂端點，Claude Code 整合指南與 基礎 URL 參考涵蓋相關設定；準備為金鑰儲值時，可以建立 Kunavo 帳戶。Kunavo 未在執行中的 NanoClaw 安裝上進行執行時測試，而已發布的設定指南是設定參考，不是相容性測試。
常見問題
為什麼我的 NanoClaw Telegram 機器人停止回應？
先確認訊息是否仍在離開主機。如果回覆與排程訊息仍會送達，但你傳送的內容沒有得到回應，應懷疑入站輪詢：NanoClaw issue #3728 回報，介面的輪詢迴圈會以 30 秒退避上限永遠重試 getUpdates，從不放棄，而且成功輪詢時不記錄任何內容，因此故障不會顯現。如果連送出也沒有，且日誌在「No adapter for channel type」警告旁顯示 platformMsgId=undefined 的「Message delivered」項目，NanoClaw 自身的 /debug 技能指出原因是同時執行了兩個服務執行個體。這兩種情況的處理方式相反，因此請先辨識特徵，再進行任何變更。
NanoClaw Telegram 輪詢錯誤是否已有固定版本可修復？
截至 2026 年 9 月 21 日，沒有。Issue #3728 仍處於開啟狀態，零則留言、零個標籤且沒有里程碑；其更新時間戳仍等於提交日期 2026 年 9 月 6 日。NanoClaw 最新版本是 2026 年 8 月 24 日發布的 v2.3.0，因此報告後沒有任何版本發布；而自 9 月 1 日以來，channels 分支唯一的提交是 Mattermost 修復。任何告訴你要升級到特定 NanoClaw 版本來解決此問題的人，所說的版本都不存在。
升級 @chat-adapter/telegram 能修復這個問題嗎？
無法修復靜默失效的路徑。NanoClaw 將 @chat-adapter/telegram 精確固定在 4.29.0，該版本於 2026 年 5 月 18 日發布；而 npm 最新的 dist-tag 是 2026 年 9 月 18 日發布的 4.41.0。本頁已下載並比較兩個 tarball：兩個版本中的 getUpdates 傳輸失敗分支實質上相同——相同的 consecutiveFailures 計數器、相同的 30 秒退避上限、相同的警告行，既不放棄重試，也不升級處理故障，而且成功輪詢仍不會記錄任何內容。4.41.0 確實重寫了迴圈的其他部分。本頁只是陳述程式碼事實，不建議提高固定版本號：NanoClaw 的 add-telegram skill 表示供應鏈政策拒絕版本範圍；本頁查閱的兩個升級拉取請求（#3460 和 #3570）仍開啟且尚未合併；此處也沒有人測試升級還會改變哪些內容。
更換 API 提供者或基礎 URL 能修復 Telegram 問題嗎？
不能。NanoClaw 的憑證文件指出，TELEGRAM_BOT_TOKEN 這類頻道權杖會留在 .env 中，由主機程序使用，而不是由容器使用；模型憑證則放入 vault，並注入容器流量。傳入的 Telegram 訊息會先到達路由器與工作階段的傳入資料庫，之後才解析提供者，而解析發生在容器啟動時。因此，不同的端點、金鑰或閘道無法修復已停止的輪詢迴圈、過時的伺服器端更新篩選器、輪詢器衝突、群組隱私設定或損壞的 IPv6 路由。唯一真正的交集方向相反：NanoClaw 的 README 將 Claude Code 列為 /debug 和每個 /add-channel skill 的必要條件，因此即使代理程式在其他地方執行，頻道修復仍需要主機上有 Claude Code。
機器人會回覆私訊，卻忽略群組。為什麼？
這通常是 Telegram 的群組隱私設定，而不是 NanoClaw 缺陷。NanoClaw 的 add-telegram skill 說明，啟用群組隱私後，機器人只能看到有人點名的命令與回覆，而看不到一般文字；你可以在 BotFather 中依序進入 /mybots、你的機器人、Bot Settings、Group Privacy 將其關閉，然後移除並重新加入機器人到群組，讓變更生效。另一種情況看起來相似但並不相同：NanoClaw issue #2989 回報，曾以較窄的 allowed_updates 篩選器輪詢過的機器人權杖，會永久在伺服器端保留該篩選器，導致頻道貼文靜默丟失，而私訊與群組仍能正常運作。
配對始終無法完成，但機器人仍可運作。哪裡出錯了？
NanoClaw issue #3162 描述的正是這種情況：如果頻道啟動時 getMe 呼叫失敗一次，機器人使用者名稱會在整個程序生命週期內快取為 null，而你傳送的每個配對碼都會被視為普通訊息，沒有任何嘗試記錄，安裝程式也會無限期等待。唯一痕跡是啟動時的一行警告，出現在你嘗試配對前幾分鐘；該 issue 表示不做其他變更、僅重新啟動即可修復。現行 channels-branch adapter 仍只執行一次查詢、不重試，並快取結果。另請注意，NanoClaw 文件描述一次性 6 位數代碼，每次執行最多可重新產生 5 組代碼；而 issue #3162 稱其為 4 位數代碼；請以文件為準。
截至 2026 年 9 月 21 日已檢查：nanocoai/nanoclaw 儲存庫記錄與版本清單、issue #2377、#2989、#3162、#3569、#3728 以及拉取請求 #2225、#2697、#3449、#3460、#3570 的開啟／關閉狀態、channels 分支的 Telegram adapter 原始碼、npm 上固定的 4.29.0 與目前的 4.41.0 adapter 建置、NanoClaw 的頻道、憑證、疑難排解與 adapter 介面文件、其 add-telegram 與 debug skill，以及 Telegram 的 Bot API 頁面。本頁沒有任何內容是在執行中的 NanoClaw 安裝上執行取得。Kunavo 權杖費率來自即時目錄，美元數字是示意性的權杖算術。