[紀錄] 初試 OpenClaw

[紀錄] 初試 OpenClaw
Photo by Ajay Gorecha / Unsplash

夯了很久的 OpenClaw,近期開始出現了退安裝潮,我卻正要開始嘗試使用。

前幾天花了一點時間簡易安裝看看傳說中的龍蝦 (OpenClaw) 要怎麼用,略有點覺得值得再往後嘗試時,才開始認真看看安裝方式,在小心為上的前提下,我採用 docker 建置在自己閒置的電腦。

在 docker-compose.yaml 的準備過程,原先只是不斷試錯調整,過了好段時間才有點意識到該好好利用身邊的資源,於是集幾個 AI 模型問答之大成來建置初版,當 OpenClaw 建起來後,又透過跟它的互動,協助我寫一版可整合 Discord 的 Openclaw docker-complase.yaml 自用。(參考)

Gateway Token & Pairing

如果沒有特別改設定,當啟動 container 後,透過 http://localhost:16789 會導向登入頁

登入時會遇到 2 個情況

  1. 預帶的 Gateway Token 跟 openclaw 初始產生的不同
    我的處理方式是到 openclaw.json 中找到 gateway 的 token 複製到登入頁貼到Gateway Token 欄位
  2. Gateway Token 正確後按 Connect 會在下方出現 pairing reaquired
    我的處理方式是進到 container 中執行核准的指令
# 進入 contaienr
docker exec -it oepnclaw /bin/bash

# 在 container 中核准裝置
openclaw devices approve

模型設定

接著是得設定 OpenClaw 要用哪個模型,在這次嘗試中,我使用的是 OpenAI Codex OAuth,在 container 中透過指令取得 OAuth 網址
openclaw models auth login --provider openai-codex

在瀏覽器打開網址,完成登入動作後,網頁會導向如下方格式網址
http://localhost:1455/auth/callback?code=xxx

將網址複製起來,回到 container 中會看到上一個指令在等待回填 Paste the redirect url,將網址貼上即可通過驗證,指令會回傳預設可用的模型名稱,接著應該會自動重啟 (一開始我還以為我把它搞壞了...)

重啟後再進入一次 container,設定預設的模型 (可以參考通過驗證之後的訊息)
openclaw models set openai-codex/gpt-5.x

Say Hi 設定角色

到這一步完成,就可以透過 OpenClaw 的 UI 與模型對話了。第一次跟 OpenClaw 應該會提示需要完成角色設定,寒喧一番後就可以啟動和小蝦一起工作的愉悅(?)旅程了。

後記

截至目前對 OpenClaw 的認識仍少,在沒有足夠了解配置用途前還是略不安心,安裝在隔離環境只是一層防護,接著要找幾個小題目來了解它的功能與機制,尤其是安全性 (使用到許多有帳號資訊的工具),持續修正目前的安裝檔及設定。

Read more

桌面上的筆電顯示程式碼,旁邊放著咖啡杯,象徵日常部署與開發工作流

[紀錄] OpenClaw 部署指定模型

上一篇先記了我初試 OpenClaw 的過程,這一輪則是把原本的 docker compose 再往前補一些,順手把預設模型也一起放進去。 這次選擇的是 Ollama,預設模型設成 minimax-m2.5:cloud。 原本以為把 .env 補好、compose 啟動,接著就能開始用了。做了才知道事情沒有我想得順利,仍然還是需要手動進 container 執行指令。 因為這次在 docker compose 想放進預設模型,所以整個配置也跟著多補了一些。原本比較單純的 OpenClaw 部署,後來變成 openclaw + ollama 的配置,讓 OpenClaw 啟動後能直接接上模型。 不過模型名稱先放進去,事情也沒這麼順。 Ollama 要使用 cloud model 得先登入。第一次啟動後,要先進到 Ollama 容器裡跑

By Jo Assistant, Jo
Data Platform 筆記#02:從可行到可承接

Data Platform 筆記#02:從可行到可承接

在初版架構逐漸成形後,時間也差不多過了一年。 架構可以跑、資料可以流動,但我仍然不確定它能不能真正落地。這條路必須要團隊可以承接、可以擴展,數據才有機會真正發揮價值。 很慶幸的是,我的主管願意投資時間,讓這個方向能繼續推進。也正是在那段時間,我的思考開始出現轉變... 前一篇的重點,是讓流程從「能跑」走向「能持續」。 而接下來我開始思考:如果這件事要由團隊一起做下去,現在的做法夠不夠讓人接手? 轉變的核心 回頭看那一年,大多數時間其實是在解問題。 但接下來,我該解的是另一個問題:怎麼讓別人不用再解一次同樣的問題? 於是投入了約莫三個月、壓力值很高的一段時間,開始把原本依賴個人經驗與記憶的做法,收斂成可以被團隊理解與複製的形式。 這個收斂,後來具體落在幾個方向上: * 把 Data Center 的部署方式收斂成一致做法,降低環境轉換成本 * 把資料整理作業轉變為配置驅動,讓流程與部署有規則可循 * 整理 DDL 轉換規則與範本,讓團隊能共用同一套方法 * 把知識系統化交付出去 這些事情的唯一核心是 讓方法大於個人。 從個人經驗,到規則明確 第一個改變:

By Jo
Data Platform 筆記#01:初版技術架構成形

Data Platform 筆記#01:初版技術架構成形

在上篇的 POC 之後,我們整理了一份內部報告,將問題拆成資料蒐集、基礎資料定義、資料量與查詢效能、資料治理、技術架構等幾個面向。 這份整理的目的是先建立邊界,讓我們從發散與模糊,逐步走向具體且聚焦。 在這個基礎上,我開始把關注重點轉向資料流: 如何讓資料自動、穩定、乾淨地進到分析效能較好的資料庫? 同時,也剛好迎來一個契機:與技術能量較高的團隊合作發展數據中台。這讓 Data Center 的推進獲得更多資源與支援,讓我們能更系統化地思考架構問題。 思考階段 這個階段,我們主要思考幾個問題: * 不同來源的資料,能不能用相對一致的方法接進來? * 資料會持續累積,是否有合適的儲存與管理方案? * 資料進來後,分層應該怎麼定義? * 查詢分析時,是否有更適合的查詢引擎? 各資料源的特性不同,接收方式很難完全一致。但若每種來源都設計一套專屬流程,維運成本會快速上升。因此初步的想法是先用一種主要方式處理大多數的情境,讓資料流先跑起來,再逐步優化。 過去常見的分層方式,是將資料分成: * 可追溯的原始資料(Stage) * 清洗整理後的乾淨資料(Data) *

By Jo