不上云、不花Token，元脑智能体工作站Z3单机能养10只“龙虾”！ 原创

前阵子脑子一热，我充了个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”。这条路早晚都得走，而元脑智能体工作站，则是一个良好起点。