NanoClaw最有意思的地方,不是刚爆红就融到钱,而是它在收到约2000万美元收购邀约后,选择了另一条路:不卖,自己融资。
NanoCo完成了1200万美元超额认购种子轮。Valley Capital Partners领投,Docker、Vercel、Monday.com、Slow Ventures,以及Hugging Face CEO Clem Delangue等参投。
这家公司由Gavriel Cohen和Lazer Cohen兄弟创办。两人曾收到约2000万美元收购邀约,附带留任运营公司的安排,但最终拒绝。
这个数字要放准位置。它不是已成交收购,也不能直接当成正式估值。它更像一个信号:AI agent越能替人操作电脑,市场越会重新给“安全运行层”定价。
六周爆红:它卖的不是万能,而是隔离
Gavriel Cohen对TechCrunch称,从写下第一行代码到拿到投资条款书,不到六周。
NanoClaw的扩散有两个关键推手。AI研究者Andrej Karpathy推荐后,项目先在开发者圈传开。随后,新加坡外长在Facebook发文称它是自己的“second brain”,热度被进一步放大。
NanoClaw原本是Cohen兄弟为上一家AI营销创业公司做的内部工具。它不是要证明自己比OpenClaw更“全能”。它抓住的是另一个痛点:AI agent在本机执行任务时,权限边界很容易变得模糊。
OpenClaw类工具通常更接近直接访问本机环境。agent可能接触本地服务、文件和凭据。NanoClaw的核心差异,是把agent放进容器沙箱里运行,尽量降低误操作或被利用时的外溢风险。
| 对比项 | OpenClaw类常见用法 | NanoClaw路线 | 对企业意味着什么 |
|---|---|---|---|
| 运行环境 | 更接近直接访问本机 | 容器沙箱隔离 | 降低凭据、文件、服务暴露面 |
| 核心卖点 | 让agent更方便地操作环境 | 让agent在更可控的边界内操作 | 安全团队更容易评估 |
| 早期用户 | 技术用户、开发者 | 同样从技术用户起步 | 采购前仍要做风险审查 |
| 商业入口 | 工具本身或托管能力 | 实施和持续支持 | 更接近企业部署服务 |
这解释了它为什么能在短时间内拿到融资兴趣。
AI agent越有用,越会碰到企业最敏感的地方:权限、凭据、文件、网络访问、审计记录。容器沙箱不是万能药,但它把问题从“让agent随便跑”改成“让agent在边界里跑”。
对企业来说,这一步很关键。
拒绝收购:开源社区是变量,不是装饰
NanoCo拒绝收购,表面上是钱和独立性的选择。更深一层,是它认为开源社区还没充分释放价值。
开源项目的价值,不只来自代码本身。用户会提交修复,也会把工具带进公司、实验室和硬件场景。原文提到,已有社区成员在尝试把NanoClaw跑到Hugging Face的Reachy Mini桌面机器人上。
这种用法,公司内部很难提前规划出来。社区的好处就在这里:野火烧不尽,但方向也不可完全控制。
这条路在开发者基础设施里并不陌生。Docker、Kubernetes、LangChain这类项目,都有类似路径:先在开发者中形成使用习惯,再寻找企业付费点。
但这里不能把故事讲满。
开源热度可以带来声量,不能自动带来采购合同。企业买的也不是GitHub上的星标,而是安全审计、权限管理、故障响应、内部培训和责任边界。
原文称,NanoClaw已有many thousands用户,并且有未披露的企业客户开始付费。它还提到,来自Amazon、Gap、Google、Meta、SentinelOne、Accenture等公司的高管个人在使用NanoClaw。
这两件事要分开看。高管个人使用,不等于这些公司已经成为企业客户。对一家刚从开源项目转成公司的团队来说,这个边界很重要。
商业化:开发者会试,企业会慢
NanoCo选择的商业化方向,是为企业提供实施和持续支持。也就是现在常说的forward-deployed engineers模式。
简单说,客户内部有人想用NanoClaw,但不想让早期技术用户变成“义务IT”。NanoCo派工程师帮助部署、培训和维护,把工具放进企业已有流程里。
这对两类读者的动作影响比较直接。
| 读者 | 更可能的动作 | 该看什么 |
|---|---|---|
| AI开源工具和agent基础设施关注者 | 先观望社区活跃度和企业用例,不急着判断它会取代OpenClaw | 插件生态、隔离能力、社区贡献是否持续 |
| 企业技术决策者和开发者 | 可以小范围试点,但采购不宜只看热度 | 权限模型、审计、网络访问、凭据管理、供应商支持能力 |
开发者会更快尝鲜。因为开源版本就是入口,试用成本低,反馈也快。
企业会慢得多。安全团队要问的问题很具体:容器能隔离哪些资源?哪些目录会被挂载?网络访问怎么控?密钥如何注入和撤销?日志能不能进现有审计系统?出了问题谁响应?
这些问题没有回答清楚,采购就会延后。哪怕工具本身很好用,也可能停在试点阶段。
这里还有一个现实约束:容器沙箱降低风险,但不等于彻底消除风险。agent如果拿到了过大的权限,或者企业把敏感目录、凭据、内部服务暴露给它,隔离层也会被削弱。
所以NanoClaw的商业化,不该只看“有多少人用”。更该看三件事。
| 观察点 | 为什么重要 | 如果做不好会怎样 |
|---|---|---|
| 企业客户是否愿意公开背书 | 证明它不只是个人工具 | 只能停留在开发者圈层 |
| 沙箱和权限控制能否覆盖复杂场景 | 决定能否进企业网络 | 安全团队会卡住采购 |
| 实施服务能否产品化 | 决定毛利和规模 | 容易变成项目制外包 |
我更在意第三点。
forward-deployed engineers模式适合早期打开企业客户,但也容易把团队拖进定制化泥潭。客户越大,内部环境越复杂,需求越碎。服务能帮产品找到路,也可能吞掉产品化节奏。
这就是NanoClaw接下来最硬的一关。
拒绝约2000万美元收购,说明创始团队相信这件事能做大。1200万美元种子轮,说明投资人愿意为这个判断买单。但真正的验证不在融资新闻里,而在企业安全团队是否愿意把它放进自己的部署流程。
