作者：毛爍

前陣子腦子一熱，我充了個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”。這條路早晚都得走，而元腦智能體工作站，則是一個良好起點。