OpenClaw 讓 Ollama 變 Telegram 機器人

以前 Ollama 只在終端機裡回話，現在 OpenClaw 讓它直接在 Telegram 續跑。

我用本機模型一陣子了，老實說，很多教學都只做到「能跑」。你開個終端機、丟幾個 prompt、看它講得像回事，然後呢？視窗一關就沒了，聊天紀錄卡在 shell 裡，手機也碰不到。我最受不了的就是這種半套流程：看起來很帥，實際上很難用。我想要的是一個能常駐、能從手機回、能在我離開電腦之後還繼續幹活的東西，不是另一個要我盯著的頁面。

這次我拆的是 KDnuggets 上 Shittu Olumide 寫的 OpenClaw + Ollama 教學。原文有把安裝、context length、Telegram、網路搜尋、Docker 都串起來，但它沒有提供社群數字，我就不亂補。這篇我只做一件事：把那套流程翻成台灣開發者看得懂、也真的能抄的版本。

把 Ollama 當終端機玩具，真的很浪費

「OpenClaw 是跑在你自己硬體上的個人 AI 助理，會一直保持運作，並把本機的 Ollama 模型接到你平常在用的通訊軟體。」

白話一點就是：OpenClaw 不是再包一層聊天介面給你看而已，它是在 Ollama 外面加了一個常駐的訊息橋接層。模型還是在本機，但真正讓它變好用的，是那個一直醒著的 gateway。你從 Telegram 丟訊息進去，它收、它轉、它回，整條路都不需要你開著終端機守著。

我之前最常卡住的地方，就是把本機模型當成臨時工具。今天想問它一個問題就開一下，明天又重開，結果上下文全斷。這種用法很容易讓人以為模型不聰明，其實是工作流根本沒設計好。OpenClaw 的好處就在這裡，它逼你承認一件事：你要的不是一次性回答，你要的是能持續工作的服務。

實操上，我會先換腦袋。不要想成「我要跑一個 bot」，而是想成「我要啟動一個服務」。服務就會有三個東西：訊息入口、模型引擎、常駐層。這三個東西只要其中一個斷掉，整件事就會很難用。你先把這個架構想清楚，後面就不會一直在錯的地方打轉。

gateway 才是整套系統的核心

「所有流量都會經過一個叫 Gateway 的單一常駐程序。它會在背景執行、維持通訊連線，並協調 AI 代理。」

這句其實很關鍵。很多人看到 bot 就只想到前端那個聊天視窗，但真正決定穩不穩的，是中間那層 gateway。它不是花俏功能，它是 glue。沒有它，你就是在終端機裡打一槍換一個地方；有它，你才真的有一個可以長時間活著的代理。

我自己踩過的坑也差不多。以前我會先懷疑模型，覺得是不是參數太爛、提示詞太弱；後來才發現，很多問題其實是 gateway 沒起來、連線沒接好、或是訊息根本沒進到正確的 channel。OpenClaw 把層次切得很清楚，這件事我很買單。因為當系統分層清楚，debug 就不會像在黑箱裡摸石頭。

實際排查順序我會這樣走：

• 先看 Gateway 有沒有真的在跑。
• 再看模型有沒有正確接到 Ollama。
• 最後才查 Telegram token、channel ID、訊息權限。

如果 bot 沒回，先別急著怪模型。很多時候只是背景程序掛了，或是通訊管道沒接上。這種事情你 debug 一次就知道，之後會省很多時間。

模型先選對，UI 才有意義

「Ollama 會依照可用 VRAM 設定預設 context length：低於 24 GB 是 4k，24 到 48 GB 是 32k，48 GB 以上是 256k。」

這段我很認同，因為本機代理最常出事的地方就是 context 不夠。很多人把模型名字挑得很漂亮，結果一跑長任務就開始忘記前文、重複回答、或把前面剛講過的條件整個吃掉。那不是模型突然變笨，是記憶空間太小。

原文的態度也很直接：做 agent 工作，64k 才算基本盤，不是什麼豪華選配。這點我完全同意。你如果要做的是網路搜尋、頁面摘要、資料抽取、連續推理，context 很快就被吃掉。這時候硬要堅持完全本機，常常只是把自己困在一個不夠用的設定裡。

原文也提到幾個模型例子，像 qwen3-coder、gemma4，還有雲端模式可用的 kimi-k2.5:cloud、qwen3.5:cloud、minimax-m2.7:cloud、glm-5.1:cloud。我的看法很簡單：如果你硬體撐得住，就用本機；如果撐不住，就別硬撐。工具是拿來解決問題的，不是拿來證明你有多堅持本地化。

• 做 agent 工作，64k context 先當最低門檻。
• 本機模型要先確認 VRAM 和 context 有沒有對上。
• 雲端模型通常比較省事，尤其是要做長流程時。

實操寫法很直接：先決定模型，再決定部署方式。不要先把介面架好，最後才發現記憶根本不夠。這種順序會讓你一直補洞。

context length 沒設好，整個代理都會短命

# 啟動 Ollama 前先設環境變數
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# 如果硬體夠力，可以再拉高
OLLAMA_CONTEXT_LENGTH=131072 ollama serve

# 或直接在 Ollama App 裡調
# 開啟設定 → Context Length → 拉到 64000 以上

這段我想特別講，因為它常常被略過。很多人以為裝好模型就結束了，但 agent 跟單次問答差很多。你只要一開始加上工具呼叫、頁面閱讀、搜尋結果整合，context 就會一直被消耗。這時候如果預設值還停在 4096，那真的不用怪 bot 不會做事。

我以前也幹過這種蠢事。模型明明能答，結果一進長任務就開始前後不一致。我還以為是 prompt 寫得不夠細，後來才發現是 context 太小。這種錯誤最煩的地方，就是它看起來像「模型不行」，實際上只是設定沒調對。OpenClaw 的教學把這件事拉到前面，我覺得很務實。

原文還建議用 Ollama 的 ollama ps 檢查狀態，確認 processor 是 100% GPU，而且 context 真的有到 65536 以上。如果你看到 CPU offloading，或 context 還停在 4096，先停下來修這個，不要急著往下裝 Telegram。

實操寫法：環境變數要在啟動 Ollama 之前設好，不能事後補。用 App 的話就直接進設定確認有沒有真的套用。這種細節很無聊，但它就是會決定你後面是不是一直在踩雷。

Telegram 是最適合先跑通的入口

「各平台的設定不同。Telegram 是開發者最乾淨的起點，不需要綁手機號碼，而且用的是正式的 bot token，不是模擬個人帳號。」

這個判斷我也同意。Telegram 對開發者來說真的比較順，因為它的 bot 模式很明確：用 BotFather 建 bot，拿 token，丟進 OpenClaw，測試訊息就能進來。整條流程沒有什麼灰色地帶，也不需要你去假裝自己是另一個帳號。

原文的設定順序也很清楚：先在 BotFather 建 bot，複製 token，打開 openclaw configure --section channels，選 Telegram，貼上 token，最後按完成。這裡我特別想提醒一下，「完成」那一步很容易被忽略。很多人配置到一半就跳出去，結果設定根本沒存。這種 bug 不是技術問題，是人類手滑問題。

如果你之後想接 WhatsApp，原文提到 OpenClaw 會用 Baileys 協定，透過 QR code 綁你的真實帳號。Slack 跟 Discord 則要另外設定 app 和 channel ID。這些都能做，但我還是建議第一輪先用 Telegram，先把整條鏈路跑通。

實操寫法：先用 Telegram 驗證模型、gateway、channel 三段都正常，再去碰你真正想用的平台。先跑通，再優化，順序別反過來。

網路搜尋一開，這才像真的助理

「雲端模型會自動拿到完整 context length，也會附帶網路搜尋，不需要額外設定。」

這一段是我覺得 OpenClaw 最像「能用」的地方。因為只要 bot 能查網路，它就不再只是個會講話的模型，而是能處理時效性問題的助手。你問它最新版本、文件變更、發布說明，它不需要硬猜，不用靠訓練資料硬撐。

我自己很常遇到這種需求。純本機 assistant 很適合寫草稿、整理想法，但一碰到最新套件版本、剛更新的 API、或某個文件頁面，答案就開始飄。OpenClaw 把搜尋接進去之後，這個問題就小很多，尤其是雲端模型本來就把搜尋流程包好了。

原文建議用一個明顯需要即時資訊的問題來測試搜尋有沒有真的啟動。我覺得這招很好。不要只看設定畫面有沒有勾選，直接問一個只有查網路才答得準的問題，才知道整條搜尋鏈路有沒有通。

• 查最新文件、版本公告、線上資料時開搜尋。
• 重視隱私時就關掉搜尋，接受答案只來自本機模型。
• 測試時直接問需要即時資訊的問題，不要測太簡單。

實操寫法：先決定你的 bot 是私人助理還是研究助理。如果是研究助理，就早點把搜尋打開，並且真的測過；如果是私人助理，就保留本機模式，別硬塞不必要的功能。

Docker 是最無聊，但最省事的收尾

「這篇教學涵蓋了從零開始，把私有研究助理跑在 Telegram 上，最後再用 Docker 無頭部署的完整流程。」

這一段我會放在最後，因為它比較像完成後的整理。第一輪先讓 bot 活起來，第二輪才考慮容器化。Docker 的價值不是炫技，是讓你不用開著終端機守它。只要容器能自動起來、重開機能復原、設定能穩定吃進去，這東西就開始像服務了。

我很不喜歡那種一開始就把部署搞得很重的人。你還沒驗證 token、context、channel，先把一堆 compose、volume、env 檔塞進去，結果出事時根本不知道是哪一層爆掉。OpenClaw 這條路比較健康：先互動式跑通，再搬進 Docker。順序對了，後面才不會一直重工。

如果你已經有家用伺服器、遠端主機、或想讓 bot 常駐在某台機器上，Docker 就很適合。它不會讓事情變神奇，但它會讓事情比較穩。這就夠了。

實操寫法：先把 Telegram 跑通，再容器化 gateway。不要在設定還沒穩之前就急著上 Docker，不然你只是在把問題包起來。

可抄的模板

# OpenClaw + Ollama + Telegram 快速上線清單

## 1) 先把 Ollama 的 context 拉高
# 啟動前先設環境變數
export OLLAMA_CONTEXT_LENGTH=64000
ollama serve

# 如果你的硬體夠力，再往上加
# export OLLAMA_CONTEXT_LENGTH=131072
# ollama serve

## 2) 檢查模型有沒有真的吃到 GPU
ollama ps

# 你要看到的重點：
# - PROCESSOR: 100% GPU
# - CONTEXT: 65536 以上

## 3) 啟動 OpenClaw
ollama launch openclaw

# 如果你想先看設定
ollama launch openclaw --config

## 4) 先接 Telegram
# 在 Telegram 裡：
# 1. 打開 @BotFather
# 2. 輸入 /newbot
# 3. 建好 bot 後複製 token
# 4. 回到 OpenClaw 設定介面，選 Channels → Telegram
# 5. 貼上 token
# 6. 按 Finished
# 7. 打開 bot，送 /start 測試

## 5) 要即時資訊就開網路搜尋
# 適合查文件、版本、公告、線上資料
# 直接問一個必須查網路才答得準的問題來測

## 6) 之後再搬進 Docker
# 先跑通互動式流程，再做無頭部署
# 先確認 token、context、channel 都沒問題

## 我會先用的預設值
# - Channel：Telegram
# - 模型：本機先用 qwen3-coder；硬體不夠就改雲端模型
# - Context：至少 64000
# - 部署順序：先互動式，後 Docker

這份流程的原始靈感來自 Shittu Olumide 在 KDnuggets 的文章，另外也參考了 OpenClaw、Ollama、Telegram BotFather 的官方資料。前面拆解是我自己的消化，最後這段模板是我整理成可以直接抄的版本。

如果你要對照原始細節，先看原文，再回頭核對官方文件。我的內容是衍生整理，不是官方說明；但這份模板，確實是我會拿去自己環境裡先跑的版本。