前陣子腦子一熱，我充了個Claude會員，本來想著養個「龍蝦」，以後寫東西能省點事，結果用起來才知道，費用貴得嚇人。
我特意去扒了下扣費明細，一句簡單的 「你好」，兩個字，連個標點符號都沒多打。整整七毛四！
我知道，很多人看到這個數字第一反應是「能接受」。畢竟對個人用戶而言，AI調用頻率不高，一次幾毛錢的成本幾乎可以忽略不計。
但如果把視角切換到企業環境，情況就完全不一樣了。
企業里的Agent很難處於閒置狀態。內容團隊需要它分析長文本，市場部需要它整理海量資訊，研發部門甚至開始讓它輔助編寫核心業務代碼……當使用者從一個人變成幾十個人，高頻的Token調用會迅速累積成一筆巨大的開支。
除了成本，企業的顧慮還來自於數據安全。
客戶名單、合同條款、內部報價、核心代碼……這些場景下，每調用一次雲端接口，都意味著敏感數據出域。對於企業客戶而言，這種潛在的安全風險往往是不可接受的。
這也是為什麼過去一年，「AI可以用，但核心業務不能上公有雲」逐漸成了很多企業的共識。
這種背景下，企業既需要大規模應用Agent提升效率，又必須保證數據的絕對私有化。
所以，企業本地部署智能體的理想方案，是將"龍蝦"Agent部署在PC端或者通用伺服器端，再將AI大模型部署在獨立的GPU伺服器上。理論上這解決了數據不出域的問題，但在中小企業實際落地中，這套"雙機方案"也會出現新的問題：
一方面，普通PC的CPU核心數和內存容量難以支撐多Agent高並發運行，高核心數的通用伺服器功耗、散熱都要求很高，而且價格昂貴；
另一方面，傳統GPU伺服器體積龐大、功耗高達數千瓦，辦公環境的電路負荷與散熱條件根本無法滿足，動輒數十萬的採購成本更將多數中小企業擋在門外。
這意味著，中小企業部署智能體的理想方案，不應該是"兩台機器的簡單組合"，而是既要能跑Agent調度，又要能承載大規模AI模型並發推理、且能無縫融入辦公環境的設備。可這台設備應該怎麼選，我其實也沒有具體的概念。
直到前不久，「至頂AI實驗室」的朋友告訴我說，他們的「龍蝦」已經跑通了多個公司業務場景中：「商務龍蝦」負責處理供應商合同條款；「代碼龍蝦」則負責代碼Review加單測；「設計龍蝦」用來出素材圖；「HR龍蝦」用來篩選新投的簡歷；「AI論文龍蝦」用來梳理每篇業界熱點AI論文的創新亮點……一圈下來，多數業務線都在用AI助理。
最讓我意外的是，他們這些任務全部跑在同一台機器上。不是按部門各配一台，也不是接的幾個雲端API，而是全部業務用一台！
實驗室的研究員把我領到機器跟前。它就放在工位旁邊，機箱大小接近一台辦公室里隨處可見的主機。他們說——這是元腦智能體工作站Z3。
24核CPU、96GB顯存、超過50T儲存，根據元腦工程師給出不同龍蝦推薦配置，理論上能撐10路以上「龍蝦」並行，覆蓋企業日常大約八成的基礎AI助手需求，能夠支撐一個六十人左右的團隊規模。
不過說實話，我也見過不少產品發布會上漂亮的配置單。真到企業生產場景里能不能兌現，看的不光是配置參數，還有幾件容易出問題的事——一隻龍蝦跑得穩，十隻龍蝦同時跑穩不穩？現場演示流暢，多個部門同時上來搶資源時還流暢嗎？畢竟如果多租戶混用、權限混亂、Skill和配置互相污染，就根本做不到「專蝦專用」。
這些事，沒看到真機跑過之前，我不敢下判斷。這幾道關，他們打算一一試給我看。
01元腦智能體工作站Z3跑起「智能體+千億模型」
在元腦Z3智能體工作站上做的第一件事，是把模型部署到本地。
選用的模型是一個 1200 億參數級別的開源大模型，經Q4量化後正好能在96GB顯存的元腦智能體工作站上進行本地部署。
這個參數規模的模型，在中文理解、複雜指令跟隨、長文本結構化處理這些維度上，已經可以覆蓋企業日常辦公任務里約八成的場景。模型部署完成後，打開本地推理界面，我試了一句簡短的中文問答，首Token延遲為42.9毫秒，生成速度為101 tokens/秒。
放在企業級推理場景下做橫向參照：42.9毫秒的首Token延遲，意味著從用戶按下回車到螢幕開始出字之間的等待幾乎不可察覺，體感上是「剛問就答」。101 tokens/秒的生成速度，對應中文輸出約每秒60-70字的可讀節奏，一篇1500字的回答大約15-20秒內完成，這個速度在內容生成、文檔分析、代碼輔助等任務上完全可用的，不是Demo級別。
更重要的是，這樣的效果是純本機推理，是在沒有接入任何雲端資源的條件下跑出來的。
接下來在這台元腦智能體工作站上部署「龍蝦」，讓它負責讀取文件、調用工具、執行Skill，並直接調用本地120B參數的AI模型，沒有任何一層依賴外部網路。
為了驗證這條鏈路是否真的能扛住企業級業務，他們用了實驗室實際在用的Skill——「AI論文解析」。
這個Skill的執行鏈路比一般問答覆雜。「龍蝦」首先要訪問Hugging Face上的當日熱門論文列表，抓取標題、簡介，再去對應的論文官網做交叉檢索，完成第一輪選題篩選。
之後，它會從抓到的熱點裡挑出最具代表性的三篇，分別做簡短總結，呈現給用戶選擇確認。
用戶在對話框裡輸入「1、2、3」選定其中一篇後，「龍蝦」開始進入第二階段，下載英文原文PDF，對整篇論文做結構化分析，包括摘要拆解、方法論提煉、實驗結果歸納、關鍵結論提取，再按預設提示詞組合成一篇中文版深度解讀文章。
更關鍵的一步在最後。這個Skill不只能生成文字，還會自動識別文章里需要配圖的位置，回到PDF原文截取對應的圖表、模型架構示意圖、可視化的實驗結果，再把截圖嵌入到中文解讀文章的合適段落中。
整套流程跑完，輸出的是一篇配圖齊全、結構完整、可以直接進入編輯流程的中文論文解讀。在文章預覽頁上，PDF截圖準確出現在對應論述的旁邊，沒有錯位，沒有遺漏。
實驗室的研究員說，這個Skill是他們目前實際使用頻率最高的一個，複雜度不低，但完成度很好。
整套流程在元腦智能體工作站上跑下來：
第一，沒有產生任何Token費用。千億參數大模型跑在本地，所有推理都在元腦智能體工作站內部完成，全程不走雲端 API。反觀如果用雲端模型，企業級場景下，一次任務的上下文動輒數萬Token，整支團隊同時在用，單價乘以頻次再乘以人頭，賬單的量級立刻翻好幾檔。按雲端公開價格折算，輕度使用月均 100元/人，重度使用月均10000 元/人，規模一旦鋪開，月度賬單將達到數十萬級別。
第二，沒有任何數據出域。抓取的論文PDF、Hugging Face內容、網站檢索結果和最終生成的中文文章、決策報告——所有文件都存在元腦智能體工作站本地的授權目錄里。龍蝦也運行在系統級的沙箱內，強隔離，默認禁止外訪，操作日誌全程留痕。我當場讓一隻龍蝦嘗試訪問授權目錄外的文件，結果是請求被沙箱攔截。
02 ClawManager：一群龍蝦，一個管家
元腦智能體工作站上跑一隻「龍蝦」，調用本地的GPT-OSS-120B、跑通論文解析和會議檢索兩個Skill，證明了其能順暢運行單用戶、單部門場景。
但企業多部門規模化應用「龍蝦」，情況就有所不同了。
內容、市場、研發、銷售、運營每個人都不想排隊等待，每個部門又都有自己的數據邊界和流程要求。
放到更複雜的行業里也是一樣。比如製造、汽車行業，一個新項目涉及研發、質量、採購、供應商管理等多個部門，資料提交、審核、覆核都要聯動。每個環節既要快，又要保證數據按部門嚴格隔離。
這就需要用另一種部署方式——面向多場景的多智能體應用。
我們把問題拆開看。
如果所有「龍蝦」都直接調用工作站本地模型，隨著任務數量增加，模型推理壓力會越來越大，GPU資源也容易被占滿。本地的GPT-OSS-120B在單機階段夠用，但一旦多路龍蝦並行，96GB顯存很快會被吃滿。再疊加每路「龍蝦」自身要消耗的CPU、內存、磁盤IO，工作站的資源會被兩頭擠壓——一邊是龍蝦在跑任務，一邊是大模型在做推理，兩類負載搶同一台機器的資源，整體效率就會下降。
所以多部門場景下，更推薦智能體工作站+ AI Server的部署方式——工作站繼續做原本在做的事，AI Server則把大模型推理壓力從工作站上解耦出去。兩台機器各跑自己擅長的負載，工作站不再兩頭擠壓。AI Server同樣也部署在企業自己的網路里，數據出域的紅線一點不碰。
這樣的硬體解耦解決了「算力夠不夠」的問題。但還有另一個問題沒解決——十幾個龍蝦同時運行，怎麼才能穩定、安全地一起幹活？
誰負責管這些龍蝦？誰知道哪只龍蝦歸哪個部門、能調哪個模型、用了多少算力、出過什麼問題？誰來保證研發的龍蝦不去讀HR的簡歷庫？
元腦智能體工作站Z3預裝了開源的企業級龍蝦管理平台ClawManager，可以安全管理多個OpenClaw實例。具體來看，ClawManager的核心能力分布在五個層面——多實例管理、權限配置、日誌追蹤、成本管控、安全防護。
在多實例管理上，利用ClawManager可以讓每路「龍蝦」獨立運行、互不干擾，新建、克隆、暫停、銷毀都在同一入口完成，1分鐘內可部署10隻龍蝦。過去，新增一個部門，或給新項目臨時配一路獨立龍蝦，需要找運維、寫腳本、配環境、做隔離；而現在，ClawManager把這件事壓縮成了簡單的操作，業務負責人自己點幾下就能完成。
權限配置上，ClawManager支持按部門、用戶、Skill做顆粒度的訪問控制。研發龍蝦訪問不到HR簡歷庫，市場龍蝦動不了銷售的報價單。權限邊界在配置層就鎖死，每個部門有獨立的Workspace，數據不互通，Skill不污染，配置不交叉，做到了真正的「專蝦專用」。
日誌追蹤方面，ClawManager可完整記錄每路「龍蝦」每次任務的調用時間、使用者、Skill、算力資源消耗、調用外部工具、輸出文件。這些記錄是給企業內審和合規審計用的，出了問題能找到責任人，做合規審計能拿出完整台賬。
成本管控上，ClawManager支持以部門為單位的算力使用核算。儘管本地化部署沒有Token費用，但本地算力的使用情況也完全可以量化，CPU時長、GPU使用時長、內存占用峰值、磁盤IO，都能折算成本，財務部門可以按部門做內部分攤。
安全防護方面，ClawManager設置了沙箱隔離、外訪白名單、文件訪問授權、操作審計，讓每路「龍蝦」都跑在獨立的沙箱裡，默認禁止外訪，本地文件按授權目錄訪問，所有操作留痕。這一套機制從單機階段就在，到了多路實例階段便由ClawManager統一接管。
值得注意的是，模型統一接入也是ClawManager的另一個關鍵能力：
ClawManager可以統一連接元腦智能體Z3工作站上的本地模型，也可以根據任務需要，切換到企業AI Server上部署的模型。
具體場景上可以劃分2類，元腦智能體工作站Z3部署千億參數大模型，適合單部門、對數據敏感度最高、本地能扛住推理壓力的場景；AI Server上部署的更大參數量模型，適合多部門並發，把推理壓力從工作站解耦出去。
我在ClawManager里試了一次模型切換。一路正在跑論文解析里的龍蝦，模型源從本地切到AI Server，任務沒有中斷，沒有重啟，輸出沒有抖動，切換過程對業務側完全不可見。
坦白說，因為模型源對應不同的成本結構和負載結構，ClawManager能在不中斷業務的前提下做切換，這件事在企業實際部署里非常關鍵。
03 5 蝦並行，10蝦擴展 元腦Z3展現企業級承載力
ClawManager的能力，大多都是為了「多蝦並發」量身定做的。所以後面要做的，就是讓這套組合在真實並發負載下跑一遍，看看這台搭載ClawManager的元腦Z3 智能體工作站到底頂不頂得住？
我們在ClawManager上接入部署在 AI Server上的模型，同時創建五個OpenClaw實例，對應五類企業任務：論文解析、AI 會議檢索、Vibe Coding、銷售推廣方案和內容審核。5個實例分別歸屬不同的Workspace，分別接入不同的Skill，共享底層的AI Server模型推理資源。
需要說明的是，本次並發測試和普通的模型跑分測試關注點不同。
普通跑分只關注模型推理速度這一個維度，重點是TPS、首Token延遲、單次推理速度。但5路OpenClaw同時跑，考察的是整機CPU調度、內存競爭、磁盤並發IO、外部工具調用排隊、多任務上下文維護的綜合能力，外加ClawManager對實例、權限、模型、日誌的統一調度。任何一環卡住，整套流程就會瞬間垮掉。
在正式運行前，先要把這五路任務的輪廓交代清楚。除了單路跑過的AI論文解析，剩下四個分別為AI會議檢索、銷售推廣方案、Vibe Coding、稿件合規內容審核，這裡展開說一下。
銷售推廣方案Skill用於售前提案。讓「龍蝦」讀取客戶資料、歷史案例和企業資源，提煉客戶的痛點，生成一份可供銷售繼續修改的推廣方案PPT。
Vibe Coding 的Skill是OPC
或非技術人員的優選。日常業務里如果需要快速做網站、活動頁、產品介紹頁，這個Skill只需要給出需要展示的內容，通過Vibe Coding就可以一站式生成頁面結構、視覺樣式、交互效果和可預覽文件，完全不需要用戶掌握任何開發技術。
內容審核Skill則更適合運營團隊。該Skill可按照預設流程，模擬用戶打開瀏覽器，讀取待發布內容，判斷內容是否合規，並完成審核和發布流程。
坦白講，這才更接近企業真實的辦公負載，每一路「龍蝦」都要讀取文件、檢索資料、執行工具、生成文檔，甚至同時維護多個任務上下文。
接下來，我讓五路OpenClaw同時啟動。
可以看到，ClawManager讓多個OpenClaw實例獨立執行任務，同時又通過統一入口進行管理。任務陸續執行完成，五路都完成了輸出——論文解讀、會議清單、銷售PPT、可預覽網頁、審核日誌，每一份都是能直接交付給對應部門使用的成品，不是Demo級別。
把資源監控調出來，整機負載呈現如下分布：
每個OpenClaw實例約占用2個CPU核心，做工具調用、文件讀寫和任務調度，5個實例合計約10個CPU核心。對於元腦Z3的24核CPU而言，仍有充足餘量，內存占用也穩定在合理區間，磁盤IO無等待，AI Server側的模型推理穩定響應，沒有出現因某隻「龍蝦」導致的排隊情況。
五路OpenClaw按2核每實例算，合計約10核。按這個標準，10路約為20核，仍然在工作站24核的容量內。也就是說，這台元腦Z3，可以支撐10路以上「龍蝦」並行，覆蓋60人左右團隊日常約80%的基礎AI助手需求。
04 寫在最後
到這裡，這台智能體工作站「三關已過」，我們再來回看其落地企業智能體的整條路徑。
第一關，單機OpenClaw證明本地模型和本地數據能跑進業務流程。
第二關，ClawManager統一接入模型、統一管理實例、統一調度任務的特性，把多實例、權限、模型和日誌統一管起來。這是從「個人能用」到「企業能用」的治理基建。
第三關，多路OpenClaw在一台企業級智能體工作站上協同工作。5路實測證明了元腦Z3工作站的真實承載能力。
三關跑完，我最大的感受是，這台元腦智能體工作站，本質上瞄準的是企業級AI落地的核心問題——企業要從「借別人的槍」，變成「造自己的槍」。
為什麼這麼說？因為今天每家企業都在面對同樣的兩個問題。
第一個是數據出不出域。這件事正在成為B端客戶簽約前的第一個問題。大客戶合同條款里「不得使用公有雲AI」，已經不是個別現象，是新常態。
第二個是Token貴。訂閱費疊加Token按量計費，業務量越大賬單越貴。
數據要握在自己手裡，成本要變得可控——這兩件事推著企業往前走，把AI從公共服務體現上搬下來，放到企業自己的環境裡。
其實，這條路過去十年已經走過兩次。
第一次，從公共郵箱搬到自有郵件伺服器。第二次，從公共網盤搬到自有NAS和私有雲。兩次技術遷徙的邏輯一樣——核心資產，不能在別人的服務上託管。
如今，第三次遷徙正在發生，企業AI正減少「調外部的 API」，開始用「自己的AI Server」。這條路早晚都得走，而元腦智能體工作站，則是一個良好起點。
