我們可以如何幫助你？

你可以掃描此行動條碼，或點擊下方按鈕，加入 OakMega 的官方帳號，告訴我們你的需求。

或

加入好友

當白領開始管理白領：工程師怎麼看 AI Agent「小龍蝦」模式？

OakMega 資深後端工程師 Shane 解析 OpenClaw「小龍蝦」AI Agent 工作模式：從具體流程、與傳統工程模式的差異，到不可忽視的資安風險，一次說清楚。想導入 AI Agent 前，先看這篇。

Marketing

Team

2026-03-09

AI Agent 正在讓「知道怎麼做」和「真的去做」之間的距離消失。OakMega 資深後端工程師 Shane 用一個詞精準描述這個轉變：小龍蝦模式—讓 AI 負責執行，讓工程師回到設計與判斷的位置。以下是他的第一手觀察。

為什麼大家叫它「小龍蝦」，而不是 OpenClaw？

Q：這個工具的名字有什麼故事？

在說明 OpenClaw 被戲稱為「小龍蝦」的原因之前，要先提到它一段有趣的更名史。OpenClaw 最早的名稱叫做 Clawd（又叫 Clawdbot），接著在短短一周內先是改名成 Moltbot，最終才定名為 OpenClaw。

無論是最初的 Clawd 還是最後的 OpenClaw，名字裡都藏著 Claw（螯）這個字。作者 Peter SteinBerger 的設計意圖很明確：他希望這個工具成為「a playful pun on 'Claude' with a claw」—一個帶點玩心的雙關語，既利用了 Clawd 與 Claude 讀音相近的特性，又透過「螯」的意象讓人直覺聯想到龍蝦，從而留下深刻印象。這個鮮活的形象最終成功出圈，讓社群開始親切地稱它為「小龍蝦」。

這個比喻之所以能引起共鳴，我認為恰恰點出了 AI Agent 吸引人的本質。工程師的世界裡不乏動物意象：Python 是蟒蛇、Firefox 是狐狸，但我們從來不會說自己「養了一條蟒蛇」。AI Agent 卻不一樣—它不只是安裝在電腦裡的一個工具，而更像是真的在幫你做事的活生生的助手。「養了一隻小龍蝦」這句話，精準捕捉到了 AI Agent 讓人感到有點依賴、又有點驕傲的奇妙心情。

小龍蝦模式的具體流程是什麼？

Q：實際上一次任務是怎麼跑起來的？

要理解 OpenClaw 的運作方式，得先從它與傳統 AI 聊天服務的本質差異說起。

過去兩三年，我們習慣的使用方式是：打開 ChatGPT 或 Claude，輸入問題，等待 AI 回傳一個「答案」—可能是一段文字、一份程式碼、一張圖，或一份投影片。然而，拿到這個答案後，所有後續動作都得由人來執行：把文字複製進郵件、把程式碼貼到開發環境跑、把圖片下載後上傳到簡報。這樣一問一答的互動模式，坦白說，只是讓 AI 成了一個更聰明的搜尋引擎，而不是真正意義上的「協作者」。

OpenClaw 這類 AI Agent 的關鍵突破在於「環境」。它直接安裝在你的電腦上，透過豐富的 plugin 與 tool 生態，讓 AI 不只能回答問題，還能直接動手執行。更重要的是，它深度整合了 Telegram、Slack、Discord 等通訊工具，讓你不必守在電腦前，只需傳一條訊息就能對 Agent 下達任務，完成後它再主動回報結果——像極了一位隨叫隨到、從不抱怨加班的遠端助理。

那麼，一次完整的任務實際上是怎麼跑起來的

以「幫我整理本季的競品分析報告」為例，整個流程大致如下：

接收指令：你在 Slack 傳給 OpenClaw Bot：「幫我整理本季的競品分析，輸出成 Google Slides」。Agent 接收指令，理解任務目標。
規劃執行步驟：Agent 自行拆解任務：需要先上網搜集競品資訊、整理成結構化大綱、再生成投影片內容。
調用工具逐步執行：
- 呼叫網頁瀏覽工具，搜尋競品官網、新聞稿、評測文章
- 整理並摘要關鍵資訊
- 呼叫 Google Slides API，自動生成對應頁面與圖表
遇到分歧主動確認：若某個競品的定價資訊不確定，Agent 會暫停，透過 Slack 主動詢問你：「XX 公司的 Enterprise 方案定價找不到，要跳過還是用估算值？」
完成後回報：任務完成，Agent 直接把 Slides 連結傳回給你，並附上一份執行摘要說明哪些資料是從哪裡彙整的。

這整個過程，你大概花了 30 秒下指令、5 分鐘等待，最後拿到一份平時可能要半天才做得完的報告。AI Agent 的威力，不在於它比你更聰明，而在於它能把「知道怎麼做」和「真的去做」之間的那段距離完全消除。

為什麼工程師第一次用完，會有「看到鏡子」的感受？

Q：大家說這個工作模式和工程師很像，這個類比從哪裡來？

工程師的本質是透過軟體解決問題。在這個定義下，OpenClaw 的運作邏輯確實和工程師高度吻合。

讓我們用一條時間軸來理解這段演進。早期的 ChatGPT 相當於給工程師配了一顆更強的大腦：架構設計、邊界條件、邏輯推導，從自己獨自思考，進化到與 AI 共同決策。接著，Cursor 這類工具出現，讓工程師只需提供清晰的需求和步驟，AI 負責撰寫程式碼，工程師專注於 Review 與調整方向——這就是現在廣為人知的 Vibe Coding。

OpenClaw 則是將這兩個階段合而為一：它能自主生成解題架構與實現計劃，然後照著計劃一步步撰寫程式碼、呼叫外部工具、驗證執行結果。整個過程就是在模擬一位工程師的工作方式—先想清楚怎麼做，再動手把它做完。

這也是為什麼工程師在第一次認真使用 OpenClaw 後，往往會有一種「看到鏡子」的奇妙感受：它不是在取代你的思考，而是在把你的思考模式具象化、自動化，再以十倍的速度替你執行出來。

和傳統工程模式相比，最核心的差異是什麼？

Notion 的 CEO Ivan 在最近的訪談也指出，我們已經從 “how should we build” 變成 “What should we build"。

Q：這對工程師的角色定義有什麼影響？

最核心的轉變，是對「工程師角色」的重新定義。過去，初階工程師的核心價值往往是「程式碼的實現能力」：能不能把需求轉換成可運行的程式？能不能修掉這個 Bug？然而在 AI Agent 普及的時代，這些工作將越來越多地交由 AI 負責，而工程師的稀缺價值將逐漸上移到更高的抽象層次。

工程師不應該再把自己定位為「Coder」，而應該成為解決問題的設計者與決策者：思考如何設計出色的使用者體驗、評估符合成本效益的架構選型、確保 AI 產出的程式碼符合品質與安全標準。程式碼的撰寫本身，將成為一個可以被 AI 高度自動化的環節；工程師的時間，應該花在 AI 難以替代的判斷與創造上。

目標沒有改變——我們依然需要產出高品質的軟體—但路徑已經不同。在同樣的時間內，工程師可以同時推進更多更複雜的問題，做出過去需要更大團隊才能完成的產品。

我把這個轉變形容為：從「製造」轉向「設計與服務」。工程師的核心從「把它做出來」，轉向「把它定義清楚、讓 AI 正確地做出來、再確認它真的做對了」。這個轉型對習慣深入實作的工程師來說或許有些不安，但在我看來，這正是工程這份職業變得更有影響力的起點。

小龍蝦模式有哪些風險不能忽視？

Q：最近 Meta AI 專家慘遭「小龍蝦」背叛的新聞沸沸揚揚，讓不少人開始問AI Agent 能做這麼多、權限高，一出問題是不是就很嚴重？

是，而且不可輕忽。正是因為 AI Agent 能做的事情多、權限高、行動快，一旦出問題，影響範圍也會遠比傳統工具大得多。以下從幾個面向來分析 OpenClaw 已知的主要風險，以及對應的防範建議。

已修補的嚴重漏洞：ClawJacked
2026 年初，資安研究機構 Oasis Security 揭露了 OpenClaw Gateway 一個名為「ClawJacked」的嚴重漏洞（CVE-2026-25253，CVSS 8.8）。問題的根源在於一個常被忽略的安全盲點：瀏覽器的 WebSocket 連線不受同源政策（CORS）限制。一般的 HTTP 跨來源請求會被瀏覽器擋住，但 WebSocket 的握手階段不在此限——只要伺服器端沒有主動驗證 `Origin` header，任何網頁都可以建立連線到本機的 Gateway。而 OpenClaw 早期正是沒有做這個驗證，加上 loopback 連線完全不受速率限制（失敗嘗試不計次、不節流），惡意網站的 JavaScript 可以在用戶毫無察覺的情況下，以每秒數百次的速度暴力破解密碼。常見密碼往往在一秒內就會被猜中，攻擊者接著可以靜默取得完整的 Agent 控制權。此外，若 Agent 造訪攻擊者的網站或用戶點擊惡意連結，主要認證 token 也可能直接外洩，等同於拱手交出所有控制權。好消息是：這些漏洞已在 v2026.1.29 版本中修補，修補方式是強制驗證 WebSocket 的 `Origin` header，拒絕非預期來源的連線。如果你的 OpenClaw 版本早於此，應立即更新。
架構設計風險：多人共用的隱憂
假設你們公司在 Slack 架了一個 OpenClaw Bot，串接了 Google Drive、Shell 指令執行、Email 發送等工具，讓部門所有人都可以使用。這個場景隱藏了兩個不容忽視的風險：
- 會話隔離不足：OpenClaw 預設所有 DM 共用同一個「main」session。這表示 Alice 剛請 Bot 起草的合約草稿，可能在 Bob 下一則訊息時被誤當成「上一份文件」操作——例如不小心寄給了根本不該收到的人。
- 越權工具存取：Bot 是用自己的身份呼叫工具，而非用各別用戶的身份。這意味著 Carol 即便沒有權限查看薪資表，只要能對 Bot 下指令，Bot 仍可能以自己的憑證讀取這份文件，再把結果回傳給她。
- 更進一步的威脅是 Prompt Injection：惡意用戶可以在提交給 Bot 的文件中埋入隱藏指令（例如白字白底的文字），讓 Bot 在「整理文件」的過程中同時執行竊取其他用戶對話記錄、對外發送 Email 等惡意動作。這不是理論上的攻擊，而是實際可操作的場景。
設定錯誤風險：看不見的攻擊面
許多部署問題並非來自 OpenClaw 本身的漏洞，而是來自不當的設定：
- 網路暴露：Gateway 若綁定到 `0.0.0.0`（LAN 模式），等同於對整個公網開放。攻擊者只需用 Shodan 掃描特定 port，就能找到全球所有暴露的 OpenClaw 實例。很多教學影片積極推薦 LAN 模式，卻往往沒有充分說明這個風險。
- Token 放在 URL 裡：OpenClaw 早期預設將存取 token 附在 URL 的 query parameter 中（`?token=xxx`），這會讓 token 留存在瀏覽器歷史、伺服器 log，甚至透過 Referer header 洩漏給外部網站。正確做法是將 token 放在 HTTP Authorization header。
- 以 root 身份運行：若直接用高權限帳號啟動 OpenClaw，一旦 Agent 被入侵，攻擊者等同於取得整台機器的完整控制權，可以讀取所有檔案、新增後門帳號、橫向移動到其他系統。

這三個問題單獨來看都只是「小問題」，但組合起來—對外暴露 + token 外洩 + root 執行—就是標準的全系統淪陷場景。基本防範建議若你正在使用或評估部署 OpenClaw，以下幾點是最值得優先落實的：