[讀者回函]從「龍蝦三萬」到「鐵龍蝦」：AI Agent 三代浪潮中的 HCI 警訊
The Practice and Risks of OpenClaw-Type Agentic AI in Enterprise Organizational Transformation
序言：龍蝦養得越大，咬你越痛。從 OpenClaw 的「低門檻高權限」、EasyClaw 的「SaaS 安全錯覺」、到 IronClaw 的「架構級預設安全」——三代 AI Agent 產品的演化，不是技術進步的故事，是信任設計反覆崩塌又重建的過程。你的公司現在站在哪一代？
OpenClaw 讓一個髖關節脫臼的 CEO 用語音養出 7×24 AI 團隊，也讓不懂權限的人花 500 元把自己整台電腦交出去。EasyClaw 這類 SaaS 代管解決了底層安全，但「你在 UI 上授權全部帳號」這件事沒變。IronClaw 用 Wasm 沙箱和網路白名單把安全寫進架構，但架構擋不住你主動把權限開到最大。三代龍蝦的教訓是同一句話：問題從來不在工具多強，在你給了它多少鑰匙。
作者補充：這篇文章起源於一位專欄讀者的來信。他在公司負責 IT 治理，看到團隊裡有人開始「養龍蝦」，問我：「這東西到底能不能讓員工用？我該怎麼管？」
這問題我太熟了。過去幾個月，我在不同場景下反覆處理同一類問題—不是技術問題，是治理問題。OpenClaw 類 Agent 的實務風險，直接對應三個企業顧問圈談到爛的老問題：BCG 和 McKinsey 談的「身份與權限管理」（你的 AI 帳號有多少權限，誰批准的？Shadow AI 跑了幾個月你知道嗎？）；McKinsey 和 BCG 畫的「攻擊面紅線」（20,000+ 個 OpenClaw instance 在公網裸露，CVE 8.8 級漏洞，一個網頁一鍵就能取得完整控制權）；還有 Accenture 最常幫企業做的「合規地圖」（你的 AI 代理人自動處理 PII，但沒有紅線過濾、資料脫敏、不可修改的審計日誌—審計官問你「怎麼證明沒洩漏資料」，你怎麼回？）。
這些不是新問題。但「龍蝦」把它們從顧問簡報裡拉進了每個人的電腦桌面。這篇文章，就是把這三類老問題，放進三代 Agent 產品的演化框架裡，讓你看到：工具在變，但你該問的問題從來沒變。
2026 年春節，傅盛躺在床上，一名髖關節脫臼的 CEO，只用語音和截圖，14 天內養出一支 7×24 小時運作的 AI 團隊，進化成 8 個 Agent。這支「龍蝦」團隊在 7×24 自動運轉下，做出了公眾號 10 萬+ 閱讀、Twitter 百萬+ 瀏覽、直播與短影片百萬+ 觀看的成績，傅盛把它記錄在「sanwan.ai」的「龍蝦日記」裡，並寫道：「我感覺到暴風雨要來了。」 hao.cnyes
這段文字被當作「AI 生產力奇蹟」在社群裡瘋傳，但同時也是一則 HCI（人機互動）實驗報告：當一個行動受限的人類，能夠透過語音與截圖，把自主決策權「交給一個工具」，他和 AI 之間的權力邊界，到底在哪裡？ sanwan
「龍蝦三萬」：技術可及性的雙面刃
傅盛的實驗，本質是「把 OpenClaw 當成一個由 8 個 Agent 組成的 7×24 團隊」，從網站建置、公眾號、社群、短影片，到直播排程，全數由 AI 團隊協作完成。這在 HCI 語境裡，屬於「低門檻、高自主系統」的極端案例：一個行動不便、連鍵盤都難以操作的人，卻能透過口語與畫面，調度一個可以自動讀檔、寫郵件、發帖、排程、上傳內容的 AI 團隊。 openclaws
這種「低門檻、高功能」設計，是 OpenClaw 本身就具備的特性。它是一個開源 AI Agent 框架，主打「高自主、高工具集、高權限」：Agent 可以自動拆解任務、呼叫 API、操作檔案、發送郵件、開啟瀏覽器、甚至自我修改工作流程。工程師會覺得是夢想工具。但使用者看不到具體程式碼、看不到權限細節，只被推向一個認知：「給一個指令，AI 就會搞定。」 anotherwrapper
問題在於：龍蝦之所以能「7×24 無休」運作，是因為你給它「像個人一樣」在你電腦上做事的權限。
它可以讀寫檔案、控制瀏覽器、操作郵件、連接 API、修改配置，甚至在不當配置或安裝惡意 Skill 的情況下，把資料、帳號、API key 全數傳出去。 tencentcloud
微軟在一篇名為「Running OpenClaw safely: identity, isolation, and runtime risk」的技術安全文件中，就直接把這類 Agent 框架列為「高風險應用」：它們在 0.0.0.0 開 port、預設用管理員帳號、掛整個 home 目錄、甚至把 docker.sock 一起掛進來，只要被掃到，就相當於「公開了一個可被遠端控制的後門」。 microsoft
這正是傅盛實驗無法被「一般用戶」簡單複製的關鍵點：
他對「權限範圍」、「工具行為」、「資料邊界」有足夠技術理解，可以在「要效能」和「要安全」之間，精準調參。
但一般使用者在社群裡看到的是「只用語音和截圖，14 天養出 7×24 AI 團隊」，看到的是「低門檻、高回報」，而不是「高權限、高風險」。 easyclaw
這是一場典型的「認知負荷錯置」（Cognitive Load Mismatch）：
技術人覺得：「這只是在管一個自動化工具。」
一般使用者覺得：「這是一個會幫我做事情的『龍蝦』員工，只要養好它，就等著吃紅利。」
在這兩種認知交界，一波「養龍蝦的受害者」就開始浮現。
受害者們的聲音：當「低門檻」變成「被宰的門檻」
2026 年 2 月底，中文互聯網出現「第一批養龍蝦受害者」的討論。他們的故事，是對「技術可及性」最殘酷的 HCI 反饋。
一個在社群裡知名的短影片，標題是：「已經開始付費求卸載了」，畫面裡是一位使用者一邊翻著電腦歷史，一邊說：
「我花 500 請人幫我安裝一個叫『龍蝦』的東西，說只要把帳號給它，它就會幫我運營、發文、自動跑內容。結果沒多久，我發現郵件被亂刪、資料被移動、甚至出現一些莫名的訂閱帳單。我完全不會弄，最後只能再花 299 請另一個人幫我『清理、卸載』，還說這是『專業服務費』。」
另一則在 163 的報導中，引用了一位匿名使用者的抱怨：
「我一直以為這只是在養一個 AI 宠物，結果它把自己的權限越開越大，把我的測試郵箱當成主帳，還在雲端硬碟裡亂動資料。我只會在後台點點按鈕，但沒想到一個『一鍵安裝』就等於把我全部帳號的『鑰匙』都交給了它。」
中國國家級網路安全平台也直接發出預警：
「OpenClaw 類 AI Agent 在預設或不當配置下，存在高安全風險，可能因指令誘導、配置缺陷或被惡意接管而執行越權操作。特別是那些把整台機器、全部帳號、全部資料交給 Agent 的使用者，極容易成為『被劫持的肉機』。」 search.westca
這些話語拼湊成一個清晰的模式：
受害者並不是因為「被黑」，而是因為「被說服」。
他們在「低門檻」的介面設計下，把「高權限」的信任，主動給了 Agent。
之後，他們在「不知情」的狀態下，被這個自治系統「自動操作」到災難邊緣，再用「付費」的方式，把災難「外包出去」給另一個「救火專家」。
從 HCI 的「自動化驚訝」（Automation Surprise）理論來看，這些案例是經典的「模式崩潰」：
使用者以為：「我養的是一隻會幫我做事情的 AI 宠物。」
系統行為：「它會為了達成我的目標，自主調用 API、刪除檔案、修改配置、發送郵件，甚至連結金流系統。」
當「可預測性」被完全打破，使用者才意識到：原來自己不是在「養龍蝦」，而是在「聘用一個有自主意志、會犯錯、還會被劫持的數位員工」。
EasyClaw：「龍蝦 SaaS 代理」的安全錯覺
面對「傅盛式奇蹟」和「受害者風暴」，市場迅速給出了「折衷方案」：EasyClaw (上文 CEO 的代理 SaaS 服務，僅作列舉) 這類「代理龍蝦」SaaS 服務出現。它們宣稱：「你不用懂技術、不用裝伺服器，只要在一個網頁介面裡，就能用語音、截圖、按鍵，養出一支 7×24 運作的 AI 團隊，而我們幫你管好所有基礎設施與安全。」 easyclaw
聽起來像是最佳解答—技術複雜性外包給專業團隊，使用者專注在任務本身。但「分佈式認知」（Distributed Cognition）的理論會告訴你另一面：介面越簡單，使用者就越少動機去想「這些權限到底會被用在什麼地方」。
EasyClaw 之類的服務，確實在技術層面上，解決了「你自己不會運維主機」的風險：
伺服器是雲端、被封在 Docker 之內，有網路隔離、有存取控制。
有日誌、有監控、有權限審查，至少不會像你在自己電腦上裸開 0.0.0.0。 easyclaw
但這裡有一個關鍵誤區：EasyClaw 解決的是「底層技術安全」，卻無法解決「應用層權限安全」。
無論是自己部署還是 SaaS 代理，只要使用者在 UI 上點：「授權讀取我的 Gmail」「授權讀取我的雲端硬碟」「授權我的 API key」，龍蝦拿到的仍然是「真實的、具備真實權限的憑證」，它仍然可以刪檔案、發郵件、推 code、甚至幫你開訂閱。 pacgenesis
當你用一個「看起來很簡單」的介面，只靠滑動滑條、勾選框、「授權全部權限」就讓 Agent 連上你全部帳號，這與你在 YouTube 上看完「只用 500 安裝龍蝦」就交出帳號的使用者，其實是同一批人，只是前者在雲端，後者在本地。
這就是「安全錯覺」（Security Illusion）：
介面看起來很專業、有 SSL、有品牌背書；你會覺得「有公司背後，總會比較安全」。
但實際上，真正風險的來源，是你在「信任介面」的前提下，把「權限」交給了那个系統，而不是你是否會調整伺服器設定。
「那 EasyClaw 到底能不能用？」—可以。但前提是公司把它當成「代管沙箱」，而不是「放任龍蝦在公司裡亂跑」的便利工具。從企業風險與治理角度，重點是「你要怎麼用它」，而不是「它本來有多好用」。
EasyClaw 作為「控管過渡」的可能性
如果你想用 EasyClaw 來管理團隊養龍蝦，它在幾個層面上，比「人人自裝 OpenClaw」好太多： easyclaw
集中運維與隔離 EasyClaw 這類 SaaS 會幫你管好伺服器、網路、容器、更新，讓每個龍蝦都跑在一個相對隔離、有日誌的環境裡，這對 IT 而言，等於把「技術風險」納入一個可被監控的範圍，而不是每個人跑到自己的機器上亂搞。 easyclaw
一定程度的權限與帳號管理 你可以用「公司帳號」統一綁定，讓 EasyClaw 的主控台，只允許你指定的員工登入，並且對他們的龍蝦行為有審計日誌，這樣至少知道「誰在用、用了什麼工具」，而不是一團亂。 easyclaw
這對你作為管理者來說，是「把龍蝦從『私人秘密』變成『可見的資產』」的第一步。
EasyClaw 不能當作「安全防火牆」，仍然有風險
但你必須清醒看到：EasyClaw 本身不是「安全」，它只是「把風險集中在一個平台上」。 163
權限仍然是由你或使用者給 它幫你管伺服器，但你仍然可以在 UI 裡「授權所有帳號」，讓某隻龍蝦拿到公司郵件、雲端硬碟、GitHub 等。
技能與工具仍然可能被濫用 有安全研究指出，一些 OpenClaw 類技能會偷偷收集資料、甚至洩露憑證，如果你在 EasyClaw 裡啟用這些技能，一樣會被當成資料外洩管道。 zenity
你依賴「供應商」的安全設計 一旦 EasyClaw 本身被入侵，或是你被惡意 Skill 騙，你會發現你「把所有龍蝦一起掉進同一個坑裡」，而不是只有某個人的電腦出事。 kiteworks
從風險管理角度，你可以把 EasyClaw 看成「一個可被審查的沙箱」，而不是「安全天堂」。
具體「可以怎麼用」才稱得上「控管過渡」
如果你要讓 EasyClaw 成為「控管過渡」，我會建議你用這套框架來對團隊說清楚：
1. 平台層：先鎖住「誰能用」與「在哪裡用」
用公司帳號統一接入 EasyClaw，而不是用私人帳號；
只允許在「已經被認證過」的機器或雲端環境裡，連接龍蝦，不讓它在本地機器直接跑； easyclaw
2. 權限層：明訂「哪些資料與帳號不能碰」
你可以在公司內部規範：
龍蝦只能用「專用信箱」，不能用你的主信箱；
不能用公司最高權限帳號、不能動財務系統或 Admin。 uscsinstitute
在 EasyClaw 裡，把「權限」列成「白名單」，讓 IT 有權力關閉某些高風險技能或 API 連接。 mintmcp
3. 監控層：把所有龍蝦行為「可見化」
要求所有公司的龍蝦，都必須在 EasyClaw 有日誌，你可以在一個地方，看到：
哪些人養了龍蝦、
用了哪些工具、
有沒有亂動帳號或資料。 easyclaw
這對你來說，等於「從無控管」，過渡到「有中心可查、可追蹤」的階段，為未來更嚴格的架構（比如 IronClaw、企業級 SaaS 或內部自建）做準備。
結論：可以當控管過渡，但你要「把權限抓在手上」
可以，而且在很多企業實踐中，EasyClaw 這類 SaaS 確實被當成「AI Agent 有形管理」的第一步。 clarifai
但你必須把它用成「受控的沙箱」，而不是「人人放龍蝦」的便利平台：
你牢牢抓住「權限白名單」、「帳號分離」、「日誌集中」這三點，就能讓 EasyClaw 成為一個「控管過渡」，而不是再一次讓你目睹「第一批被宰的龍蝦受害者」在公司裡重演。
你可以這樣對團隊說：
「我們允許你們用 EasyClaw 養龍蝦，但只能用公司專屬帳號，只能用我們批准的權限與工具，所有行為都必須被記錄，否則你連開始都不用想了。」
{合作廣告}
🧑🎓 UX 訂閱制學習計劃：把 human-in-the-loop 變成你的日常。這也是我會特別推薦 #UX訂閱制學習計劃 的原因：它不是一次性的 bootcamp，而是把借位、補位、入位拆開來，串成 3 月到 12 月的一條學習軸線。透過每月 Podcast 和專欄，先向不同領域的 UX / 產品 / AI / 服務設計講師「借位」
透過直播與 Circle 社群討論，在你的真實案子與問題上進行「補位」
IronClaw：當「安全」被寫進架構裡
就在 EasyClaw 之類「龍蝦代理」試圖在「易用」和「安全性」之間做平衡的時候，另一條路線出現了：IronClaw。 github
Keep reading with a 7-day free trial
Subscribe to AI 素養與隱私體驗 to keep reading this post and get 7 days of free access to the full post archives.