OpenClaw 小龍蝦週：從 Claude Code 1.5 時代到數位 Jarvis｜Weekly Vlog EP8
發佈日期： 2026-02-08 主題： OpenClaw 深度研究週——從創辦人哲學、架構拆解、實際使用、成本優化到企業部署 涵蓋文章（2026-02-02 ~ 02-07）：
- 02/02 - 從 $1.16 億退休到 10 天寫出 10 萬星專案：Peter Steinberger 的 Agentic Engineering 哲學
- 02/03 - OpenClaw 記憶系統全解析：SOUL.md、AGENTS.md 與高昂的 Token 成本
- 02/04 - 這幾天我密集使用小龍蝦 OpenClaw：為什麼我決定把它納入工作流
- 02/05 - OpenClaw 架構全拆解：Agent 工程師必學的六層設計
- 02/06 - OpenClaw Token 優化指南：如何將 AI Agent 運營成本降低 97%
- 02/07 - OpenClaw 如何部署在企業：我怎麼把 AI Agent 當成一個「全新的員工」
逐字稿
開場：Claude Code 的 1.5 時代與 OpenClaw 的 Next Level
這週我們開始介紹 OpenClaw。
在上週的時候講到 Claude Code，當然裡面因為 OpenClaw 突然爆紅，也講了一些 OpenClaw。但是也同樣開始比較了——我認為 Claude Code 是一個 AI Agent 1.5 時代的一個很完美的作品。
它其實把原本被動的 AI Agent 導入的一些相關的，對，用命令行，然後能夠調用大量的 Tool，還有大量狀態。簡單講就是把 AI Agent 的手腳跟眼睛都打通了。那我們可以做到說，一個半自動 AI Agent 到底能做多少事情。
但是 OpenClaw 它其實就更像那個 next level 了。它還加入了所謂的主動性——它裡面有一部分就是不帶命令，就可以自行來做一些事情，並且能夠幫助到這個相關的主人。
這件事情其實已經非常非常接近所謂的數位 Jarvis。
所以今天我們來從各方面來講那個 OpenClaw 的相關的東西。在本週的話，我從這個作者的訪談、從他的架構、他的 Memory 系統、如何節省他的 API 帳單，最後再回到——有這樣子的一個強力的數位工具，我們要怎麼導進去我們公司的工作流。我們來討論這個議題。
週一：Peter——不只是 Engineer，而是 Builder
週一的時候，我先開始於那個 OpenClaw 的作者 Peter 的訪談。
Peter 我在他身上看到了一個——就是不只是 Engineer，他其實是一個 Builder 的概念。簡單講就是說他理解這個產品是什麼，他會寫很棒的程式，但是他也會去負責上什麼叫做客戶的需求，或者他自己的需求，那他也知道怎麼樣去把他那個實做出來。
所以他就是——我覺得他是一個新時代工程師的一個很重要的範例。就是介於工程師、Product Manager，以及做相關的 Business 的中間的一個混合。這是混合的一個角色，那我們就開始叫做 Builder，你有一些概念就把它標起來。
那他在裡面其實訪談裡面他提到蠻多為什麼他要建 OpenClaw 這樣子的東西。他的目標原本只是做一個在 Mac 上面跑 Claude Code 的相關翻版，但是做著做著他就越覺得越做越大，而且越做越像一個很棒的數位助手。所以慢慢的他就在今年的時候突然就爆紅起來了。
那我在裡面也看到最大的一些啟發。第一個事情是，他就是認為說現在那個 AI Agent 現在 Focus 上的一些這些 MCP，他認為意義不大。他用了一些簡單儲存方式把它做的就是更好，並且能夠做到一個長久持有這個相關的 AI Agent Memory。
我個人認為它達成了一個非常非常重要的東西。大家詳細細節，歡迎你去看我的 Blog 或者去看他的 YouTube 訪談，我個人認為非常的精彩。
週二：Memory 系統——一大串的 Markdown
然後在週二的時候，我開始去分析一下那個 OpenClaw 裡面的相關的——雖然說它 Memory 系統，但是其實說 Memory 系統其實就是一大串的 Markdown。
那它在一開始啟動的時候，它有一個 AGENTS.md，那告訴你說你是一個什麼樣 Agent，那你要做什麼樣的事情。大部分的一些比較像一個 System 旁邊的東西都會放在這邊。
那裡面還有趣就是裡面有一個 SOUL.md，它的靈魂。那你可以在裡面寫說，你是希望它是一個主動的人，或者是一個被動的人，或者怎麼樣子，那你就可以增加更多其他更多的相關的活人感。
當然，裡面還有很多大大小小的相關的 MD。另外一個有趣的設計就是說，它把每一天的相關的討論的這些 Log 都放在每天一個 Log 的 MD 裡面去。那它每次啟動的時候，它都會去讀這些每天跟昨天的相關的討論的 History。
所以大家就覺得說欸 OpenClaw 能夠特別能夠記住我們自己的之前講過的東西，它記憶力特別強。那所以才會有所謂的活人感。這些活人感其實都是來自於它用大量的 MD File 然後做出動態組合來做這件事情。
但是也因為這樣子，大家都俗稱它是一個那個 API Token 粉碎機。你隨隨便使用的話就很容易就是花到很巨大的錢。
我把 OpenClaw 當作個人助手的使用體驗
然後在研究了那麼多的時候，其實我已經在把那個 OpenClaw 當作我的一個個人的助手。那我在過了這段時間，我的感覺是——它真的是一個活人感很強，而且蠻主動積極的一個相關的助手。
比所有其他的 AI Agent 的最大差別，就是主動性跟被動性的差別。
之前的都是一個比較被動，我們需要它的時候我們問它，那它就是回答我們的問題。然後當然像 Claude Code，它能夠多做一些事情，因為它有一個很好的 Terminal 界面，然後我們賦予它更多工具，它能做到那些事情。不過它還是取決於一個半自動。
可是在那個 OpenClaw 這邊，它其實已經相當程度來說比較主動的。因為它在裡面設計裡面有一個相關的 Heartbeat，它會定期去看有什麼事情我可以幫你做的。
所以並且它又如同剛剛說的，我們有很多的相關跟它對話記錄它都記了下來。所以我們可以做到很多就是很像一個個人助理，然後它能夠幫助我做事情。
舉幾個例子吧：
幫我訂會議： 當我覺得說欸我要跟誰訂會議，那因為我就跟它說你幫我記住這幾個人 Email，然後我真的要開會議的時候，我就跟它說你幫我發會議，它就發了一個 Google Calendar 過去。
幫我看文章、整理文章： 就丟一個 Google Drive 連結過去，它就可以做這件事情了。
幫我剪片： 這是我印象最深刻的。我那時候在上週剛好有一個 YouTube 影片已經放上去了，那我在吃飯的時候，我想說欸你可以把我的 Short 嗎？就丟給它。
那它在第一次給它這個 Link 之後，它就立刻去下載這個 YouTube Link，然後去取出它的相關的文字——當然是用 Whisper。然後上文字之後，它會分析裡面就是比較可以剪成 Short 的有哪三段，然後它就回來給我說這三段適不適合。
那最有趣的就是，它還會說「在詢問你的同時，我已經開始在剪第一段了」。
所以它的這種就是在這個例子，其實你可以非常的明確的感覺到它的所謂的主動性。就是說它很多時候它甚至不待你的命令，它認為它可以做這件事，它就開始做這件事情了。
這個這種體驗，是在其他的那個 AI Agent 上面比較少看到的。而這也是我認為它能夠之所以那麼爆紅的一個其中有很大的原因。
週四：IT 架構設計——Peter 是一個非常細膩的開發者
當然在週四，雷打不動的 IT 架構這邊，我也就是開始去分析這 OpenClaw 裡面的相關的 IT 架構。
我認為它這個在裡面其實就體現出 Peter 這個人其實是一個非常細膩的開發者。那這是他設計出來的架構，其實還蠻真的蠻漂亮。
這也反映到另外一件事，就是說在 AI Coding 的年代，其實裡面的 Code 不是最重要，但是能夠把這個架構設計的漂亮，並且能夠拆解它的目的，變成一個整整可知性的架構——其實這種能力在 AI 時代還是非常的稀缺的。
那我們再回到這個 OpenClaw 的架構。基本上它是為了某一個很特定的商業目的而服務的——基本上就是一個長時間待機的數位助手。
也是因為這樣子，所以它就開始設計了一些其間很重要的事情：
第一個就是 Memory 架構： 它不會忘記嘛。
第二個架構： 它要能夠相關的主動，並且能記住你自己，然後並且能主動發現事情。
第三個： 它也認為在 Multi-Agent 設計的時候，就是有大量的 Log 這樣交錯的話，其實那個 Multi-Agent Debug 的運作其實是比較困難的。所以它也做了一個很明確的架構設計——就是比較堅持串行而不是並行。
那在這個情況下的時候，它就設計了多層：
- 前面的一層是 Gateway
- Gateway 上面有一些 Channel 在這邊 Adapter
- 這 Gateway 能夠去 Adapt 後面的相關的 Worker
- 它的每一個相關的 Task 都是一條線，這線是一個串行不是並行的
那另外一點就是說它在裡面因為它在這個 AI Agent 在這個電腦裡面其實是相對高權限的，它也做一些適合的相關的架構設計。
週四（續）：OpenClaw 架構概念——非常有品味
再來就到了週四，雷打不動的保證無聊的 IT 架構設計。那在這一次，我們講到 OpenClaw 的架構概念。
我個人認為其實 OpenClaw 的架構設計是非常非常有品味的。這個可能也是因為 Peter 這個原作者他本身是一個非常非常資深的開發者有關係。
在這個 OpenClaw 的架構設計，它一開始就定位是一個長時間待機並且多通道（Multi-Channel）的一個數位助手。它甚至能夠接受 Cron。
所以在這樣的架構設計下，它其實它的每一層，它都是反映它相關的一些為什麼這樣設計的原因：
首先第一個： 它是一個多通道嘛。它接受 Discord、它能接受 Slack、Telegram、WhatsApp 等等多通道。多通道它是一個原生的概念。所以多通道進來，它就有一些相關的 Adapter。
再來它會統一到一個相關的 Gateway： Gateway 製作一個相關的，總之把這個多通道東西把它做一個比較好的梳理跟整理，丟到一個就是一個 Lane Queue 的設計。然後讓它知道說它判斷說它大概是屬於哪個 Pipeline，把它丟到這個 Pipeline 裡面。
那丟到這些 Pipeline 裡面之後，它又預設的就是說它認為現在 Multi-Agent 的架構設計大部分是鼓勵就是並行的，因為這樣處理比較快。但是它也發現到這樣的 Debug 在 Debug 裡面的問題的時候非常的困難。
所以它就做了一個架構的取捨——它就是一個有點像這個強制的串行。當然你還是可以做並行，但是它這個做一個在同個 Pipeline 它是一個強制串行的做法。
這個非常工程化。它的 Trade-off 就是它每一個東西它會比較慢。所以看到 OpenClaw 在丟任務的時候，它都會做完處理之後再回給你。但是它也就是讓它整個做事情是會比較順暢，而且它邏輯比較清晰一點。
這個也跟所謂的長時間待機的數位助手有關係。有點像你丟給你的一個屬下一個任務，那它其實不會立刻回答你，而是它只會去做完這件事情之後，過了 30 分鐘一個小時之後，再跟你回報說欸反正是做好了或者沒做好，因為發生什麼事情。
這其實就是它在 OpenClaw 定位的數位助手有關係。它其實數位助手的原生的使用場景就可以允許這樣子——你每個東西丟進去丟過去之後，能夠 Single Night 是把事情做完之後再回給你訊息。
當然在後面還有很多的相關的細節，這個就不多談了。但是非常建議大家去看原文或者看一些網路上討論文章。我個人認為它這樣的架構設計其實也是一個非常新穎的，而且對那個 Multi-Agent 的架構設計是很有幫助的。
週五：Token 優化——輕輕鬆鬆減少 50%
再來就是在週五的時候，我也在討論另外一個蠻有趣的議題。就是大家都說它是 API Token 粉碎機嘛，那麼我們到底要怎麼樣有機會去優化它的 API Token 呢？
其實這個問題大家都已經討論到很多了，所以網路上也有一些比較簡單而且蠻好實作的節省 Token 的方式。我也開始在製作了，那我也覺得輕輕鬆鬆能減少 50%。網路上是說 80% 到 97% 了。
那基本上它就是幾個思路吧：
第一個思路： 把它的記憶體裡面其實有一個就是 Chat History 的概念，它會把整個 Chat 的 Log 都把它丟進去，每次對話都丟進去。但是有些人認為說這些資料不見得是那麼的必要，所以可以在預設的時候是不 Loading，這時候只是 Loading 像 AGENTS.md、SOUL.md 或是一些 TOOLS.md 就好了。那真的需要的時候再把它 Load 進來。那這是一個很好的做法。
另外做法我覺得也是很棒的： 它裡面有大量的就是一些 Tiny Task，像 Heartbeat。它定期去看你發生什麼事情，然後並且或是去提醒它，給它做主動做些事情。那第二個就是有一些比較執行上的任務，那當然也有些比較重的一些規劃上的任務。
所以在這邊的話，其實就可以用一些 Configure 就能做的一個模型的分流。在大部分的時候我舉例 Claude Code 為例，我們可以大部分的都使用那個 Haiku，這樣子比較輕、比較快而且比較便宜的模型。只有在比較重的 Planning 的時候才使用那個像 Opus 這樣子的模型。
那這樣子的話其實不會降低太多這個 OpenClaw 的品質，並且它又可以很輕易地降低很大一筆錢——這邊大概至少 50% 以上。
第三個的話： 就是剛有講到 Heartbeat 嘛，那它也認為說 Heartbeat 這個東西其實只需要直接用一個小模型，而且這個等級的小模型就可以做了。所以它也建議說直接加個 Ollama，然後再丟一個差不多 Llama 3.2 3B 左右的模型，就可以完全勝任這個相關任務了。
大家這當然見仁見智了，因為我個人認為 Heartbeat 這件事情其實也是 OpenClaw 最有趣的一個概念之一，因為它能夠主動幫你做東西。所以這邊如果你怕這小模型會讓你的體感下降的話，你也可以嘗試像導到網路上一些免費的模型，像 Gemini 的 Flash 或者是像 Haiku 這樣子的模型。那這個一樣有類似的效果，當然就是有一樣效果，而且整體成本會下降很多。
那這邊的話就是還有很多相關的選項，是能夠做 Prompt Caching 或是做一些相關的 Rate Limit 這個東西。那我個人覺得說這個就是在你使用 OpenClaw 是非常非常值得投資一點點時間——大概 5 分鐘到 10 分鐘，就能讓你的帳單降低很多，非常值得來試驗。
當然這邊也講到說其實蠻多人是使用訂閱制的，像是 ChatGPT 或是那個 Claude 這樣子的 Pro Plan 來做。這邊要提到的是其實會有很高的封號的風險。但是它可以讓你的帳單可以保持一個穩定，所以這個就是一個見仁見智的東西。
你可以使用 API，在企業規模的話我強烈建議你使用 API，再搭配這樣子的一個 Token 節省的模式。剛才在個人使用上面的話，如果你不在意被封號的話，那你也可以直接試試用訂閱制。那這個對你個人使用應該是非常簡易的。
週六：企業導入——把 OpenClaw 當成一個「新員工」
那在週六的時候，企業導入這邊的議題，其實就是講到我這一週其實一直在做的一件事——就是如何把 OpenClaw 這個東西能夠把它放進去企業的工作流。
我個人認為是非常重要的，因為之前大家的做法都是它是個人的助理，是自己人生的一個助理，而不是到企業這邊。
那企業這邊其實我一開始也講到說，請不要先放在公司網路上面，因為大家還不確定要怎麼使用它。那經過這一個禮拜的相關討論之後，大概歸納出一些可行的做法，也跟一些朋友討論，那大概覺得這樣做吧，七七八八就可以做到一個還不錯的一個防護。那這邊就跟大家分享。
第一個就是你把 OpenClaw 當做一個人。 一個人，因為它真的很像一般人。所以你把它如果把它當成一個新進的員工的話，其實很多的思路都會順順的過來。
舉例大概——你不要讓它扮演你的角色。你就代表意思就是說，絕對不要讓 OpenClaw 去登錄到你自己的那個在公司的主帳號，而是直接開一個在公司管控的一個新的帳號，像是新的員工。那給它相對應的這個新員工的帳號的 Key。
像我們這邊使用的是 Google Workspace，就直接幫它開一個新的 Workspace 的帳號。當你需要請它來做那個文件的閱覽的時候，你就把這個文件就是 Share Permission 給這個新的帳號來做，不需要就把它拿走。
那這個其實就跟對待一個新的員工，你請他看一些東西的時候，你還是得把帳號權限丟給他一樣嘛。你不知道這個人會怎麼做，就跟你不知道 OpenClaw 會怎麼做一樣嘛。
所以就是這樣子的話，其實這樣子你對新人——其實企業的新人其實你本來就有一些那個所謂的資訊的管控。同樣的你就把同樣的資安管控的這個流程套到 OpenClaw，其實那這樣子其實 IT 的 SOP 就不用那個改編改寫太多了。
所以這是第一個。
那在第二個的話： 其實你也可以做很多其他的事情。第二個的話就是如果你想要讓它能夠連公司的內部系統的話，我這邊會建議就是你先寫好你的 Skill，並且連內部系統的這個 Code 不要用 OpenClaw 來寫，而是你自己先寫好。
相關的 Code 之後再把這個 Skill 丟給它。那這個某種程度來說就可以讓 OpenClaw 直接採用你的 Skill 來做事情。那你也可以把在那個就是把一些就是防護的機制，或者是權限的機制就寫死在 Code 裡面。
所以讓 OpenClaw 在 Approach 你公司的相關的一些 Service，或是一些內部的 Server 的時候，能夠受控受管。
那這邊提到的是我這邊採取的概念就是不要寫在 Prompt 裡面。因為 Prompt 就是自然語言寫的，再怎麼嚴格都還是有機會被 Prompt Injection 跳過。但是寫在 Code 裡面，當最後存取的管道是在用 Code 這邊控制的話，人會比較清楚知道你要怎麼控制這個東西。那這是一個蠻重要的點。
Email 是風險最高的環節
最後一定要討論到一點叫做 Email。
Email 這些東西看似簡單，但它其實是 OpenClaw 要放進去企業可能是最大的問題。
原因是因為我剛剛講到的這一些——就是原本像公司內部的檔案分享，或是公司內部系統這邊其實 Input 都是來自於公司內部，所以它就是可控的。
但是 Email 也是因為它是——它其實是可以接受外部的 Email 的。而且它可能就是一個我們這個 OpenClaw 的就是對外的一個唯一的一個節點。所以這個東西我們要防護特別的嚴格。
首先第一個： 就是不要把這個新人帳號的 Email 曝露到外面。讓別人知道這 Email，那就有機會打進來。
第二個就是： 不要去信賴由 LLM 去讀 Email 這件事情。因為有太多的資安的那個事件都是直接寄一個能夠帶 Prompt Injection 的 Email，然後用白底——就是人看不出來的像 Prompt Injection 寫過來，那 LLM 就被它裡面的一些 Prompt Injection 的詞彙所攻擊，然後就變成另外一個相關的代理人了。
所以這邊採取的概念就是寫成另外一個 Skill，然後讓程式先去讀這個人的相關的 Email。那然後當它把那 Email 內容把它取出來之後做一些清洗，最後吐出一個結果。結果裡面可能是它的標題是什麼、Content 是什麼，但這些東西都已經是一個被清洗過的東西。這個時候再讓 LLM 去讀。
所以這裡其實有一點已經有一點點我之前講到的 Guardrail 的相關的概念。但是它可以很大幅度的降低就是被外面直接打進來的一些風險。
再來就是怎麼實際操作： 基本上就是我如果是公司內部系統寄給我的 Email，像是 JIRA 或者其他的 Email，那我就直接在 Gmail 那個 Forward，就直接 Filter Forward 過去，直接給 OpenClaw 來幫我處理了。這個是比較簡單的。
那但是如果是外面的人進來的 Email 的話，我一律由我這邊來過濾。我覺得這東西我要交給它來做，那我看完之後我再 Forward 給它來做。
所以有這樣子的幾層的機制：
- 第一個是我們在讀取這邊已經用相關的 Guardrail 的概念來做一個內容的清洗，而且是用程式碼（Code Level）的方式做這個清洗
- 再來是我們人去 Filter，就是只有有必要的，我才 Filter 給我的數位助理、我的數位秘書，告訴它請幫我處理這件事情
那這樣子就可以蠻有幅度的、蠻有層次的去降低相關的風險。
本週總結：為什麼我願意花這麼多時間研究 OpenClaw
最後在這週，為什麼我們要反反覆覆的圍繞著 OpenClaw 的議題再講來講去？
從架構面、Memory 面、從這個作者的思維面，還要從怎麼省錢這一面、怎麼納進去這個公司的企業工作流這一面，要做那麼多的相關的討論的原因是因為——
我真心覺得 OpenClaw 是未來 AI Agent 的一個很重要的一個方式。
而我不確定它會被維持到最後、持續到最後變成一個持續下去的一個 Project 或是軟體。但是它這樣子的一個個人秘書、個人數位助手，而且提供相關的主動性跟活人感，還有超強的記憶力，還有就是能夠使用這台電腦裡面大部分權限能夠產生的一些創意跟爆發力——絕對是這個在 AI Agent 時代需要的這個技能。
所以我們需要知道就是我們如何——OpenClaw 到底是什麼樣物種？
- 我們要從架構面、從 Memory 面知道它是什麼樣物種
- 我們從並且我們知道說它的一個大問題——它的 Token 粉碎機——我們怎麼樣去節省這個錢
- 最後做完這些功課之後，學習怎麼納到你的企業工作流裡面
那我真心認為，它會是改變你整個企業的一個流程工作流的一個很重要的方式。
所以這是因為我真心覺得 OpenClaw 是我在這一年多以來看過，最接近一個能夠改變這個企業的運作形態的一個 AI 的方案。
所以我們願意花時間去研究它、了解它、去改進它。
那這就是我這週想要做的總結，非常謝謝大家。