Naïve 完成 2850 万美元 A 轮融资：AI 代理自主运营企业会成真吗？

当 Claude Code 或 Codex 能在一个下午推送一个完整应用时，把那段代码变成一家真正活着的公司——完成注册、开立虚拟卡、接通支付和邮件——依然是一个围绕几十个后台界面点来点去、持续数周的体力活。这个断裂带不仅是效率问题，更暴露了一个结构性的错配：支撑企业运营的全部 API 和云基础设施，是为人手操作的 DevOps 流程设计的，从未预设过调用者是一个自主 AI 代理。

这个错配正在催生一类新基础设施。2025 年，两位 20 岁的加州大学伯克利分校辍学生 Sean Dorje 和 Dennis Zax 创立的 Naïve，刚刚完成了一轮 2850 万美元的 A 轮融资，试图用一个配置文件加一套统一 API，把 AI 代理“运管一家企业”所需要的全部后台能力重新封装一次。Dorje 在融资公告中写道：“在这个十年里，代理支出将攀升到数万亿美元，因为公司会完全依赖自主完成工作的代理来运转。”而 Naïve 想成为这些自主公司的底盘。

从出卖第一家公司到押注自主企业：两个 20 岁辍学者的连续创业逻辑

Sean Dorje 和 Dennis Zax 的共同创业史从 14 岁就已经开始。进入加州大学伯克利分校后不久两人便选择退学，此前他们以青少年开发者的身份创办并出售了一家叫 ezML 的机器学习公司，随后进入 Y Combinator。这段履历让 Naïve 在天使轮就拿到了一个星光熠熠的名单：除了机构投资者外，Apollo 联合创始人 Tim Zheng、前 HubSpot 总裁 JD Sherman、亚马逊的 Gert Lanckriet、DocuSign 总裁 Robert Chatwani 和 Codecademy 联合创始人 Zachary Sims 都以个人身份参投。连续创业退出经历加上 YC 校友身份，是理解这群人愿意用支票支持一家尚无公开收入的公司的重要背景。

但真正让本轮领投方 Nexus Venture Partners 决定押注的，是这个团队的切入角度。Naïve 没有去卷大模型性能，也没有在代理编排的应用层做某个垂直场景，而是盯上了被多数 AI 创业公司忽略的一层——替代理搞定法律实体、支付工具、邮箱、电话号码和 10,000 种企业工具的接入。Nexus 合伙人 Abhishek Sharma 在声明中的表述很直接：“过去两年证明了自主软件可行，未来十年将是自主公司的时代。Naïve 给了数百万创业者和小企业一键式的基础设施，让他们无需成为 AI 专家也能创建并运营自主公司。”

代理能写代码，却开不出一张公司信用卡

当前 AI 基础设施的热词是大模型 API、向量数据库和代理框架，但一个自主代理要在真实商业世界里运作，需要的远不止一个推理接口。它必须有能力以法律实体身份签署合同、持有资金、接收邮件和短信验证、调用 Stripe 完成扣款、在 GitHub 上维护代码仓库，甚至通过 QuickBooks 处理记账。这些系统原本都是为了人类用户通过网页 UI 一步步操作而设计的，API 文档中充满了 Cookie 令牌、浏览器重定向和生物识别验证——对 AI 代理天然不友好。

Naïve 的解决方案不是简单地把这些工具做成一个个微服务，而是将它们收敛到一个配置文件 `naive.config.ts` 后面。创始人声称，开发者只需让编码代理生成这样一个配置文件，平台就会自动预配整套运营基础设施，包括 LLC 公司注册、虚拟支付卡、专用邮箱、手机号码、关系型数据库、对象存储和身份认证等。任何代理随后发出的操作请求，都要经过一道治理网关，开发者可以预先设定预算上限、审批规则和能力边界。换句话说，代理可以在授权的范围内像一个独立的经济体一样运转，但不能越权。

推出这种产品的前提，是 Naïve 能够在后台嫁接起庞大的供应商网络。公司公开提到已集成超过 10,000 种工具，包括 Stripe、GitHub、Supabase 和 QuickBooks 等。这些工具接入的广度本身构成了第一个竞争门槛——任何竞争对手如果要从头搭建同等体量的集成，需要投入大量商务和技术对接的时间，这在短期内是 Naïve 的先发优势。不过，这种整合的深度和稳定性尚未披露：是完成了深度 API 对接，还是仅仅通过浏览器自动化或 Webhook 做了浅层连接，对于不同工具可能差异很大，这直接决定了代理在真实业务中执行操作的可靠程度。

2.3 毫秒冷启和 1.2MB 占用的背后：按执行时间计费能省多少？

代理工作负载有着与 Web 应用截然不同的特征。一个执行多步任务的自主代理常常在等待 API 响应、模型推理或外部操作时处于完全空闲状态。传统的云服务器会为这段空闲时间照常计费，虚拟个人也在空转中消耗内存和算力。Naïve 的技术团队认为，这种闲置浪费足以让自主公司的推理开支变得难以承受，尤其是当代理大规模部署后。

因此，公司把无服务器运行时作为此次 A 轮融资后的第一个研究支柱。它没有将代理部署在长时间运行的虚拟机上，而是使用 V8 隔离技术把每个代理封装为轻量的可序列化状态，声称冷启动时间只需 2.3 毫秒，单个代理占用约 1.2MB 内存。计费模型也随之改变：只为代理真正执行计算的毫秒数付费，不覆盖等待期。官方给出的对比口号是“运行成本仅为某些常规配置的百分之一”。但这里有一个需要交叉验证的假设前提——代理是否真的像公司描述的“95% 时间都在等待”，极大地取决于具体用例。在计算密集型或需要持续监控的任务中，空闲比例会明显降低，节约效果也会打折扣。公司尚未公开生产级代理集群的真实成本数据，这一数字目前还只停留在基准测试阶段。

此外，V8 隔离技术本身虽然是谷歌 Chrome 浏览器中成熟的技术，但在多租户、高安全要求的代理场景中大规模运用，可能面临隔离逃逸、资源竞争和跨代理数据泄露的风险，Naïve 未说明其安全审计情况和多租户隔离策略。

让每个 token 干更多活：资金流向的四个研究支柱

用 2850 万美元支撑基础研究，对一个尚在商业化早期阶段的初创公司来说相当奢侈，但 Naïve 把这笔钱清晰地拆分到了四个相互咬合的方向上。

第一是无服务器运行时，上文已提及。第二是动态推理路由，目标是把每一个模型调用派发给成本最低却能胜任的模型：机械性环节使用小模型，复杂推理才调用昂贵的前沿模型，长期运行的代理则采用批量推理来摊薄成本。这意味着平台需要在多个模型提供商之间维持一条高速、低延迟的调度层，并持续评估哪些任务可以安全地降级到小模型而不损害业务结果。第三是记忆系统的上下文压缩，公司将之称为“大脑”。其机制是把连续的对话和代理活动蒸馏成结构化的记忆事实，再根据每次查询所需提供最小量上下文，而不是把整段历史全部塞进提示词。Naïve 声称这套记忆层在召回表现上达到先进水平，且每查询所用令牌数仅为现有方法的约 1/11。如果这一数据能在真实业务环境中被重复验证，将有效降低代理持续运营时的推理账单。第四层是多智能体分层编排，让子任务被分派到不同级别的子代理上并行处理，而不是让最昂贵的顶级模型承担所有决策。

这四个方向本质上都在回答同一个核心命题：如何最大化每一枚 token 兑换的有效工作量。Dorje 甚至为公司设定了一个更激进的口号：“Naïve Labs 的愿景是让每个 token 做更多事，让自主公司成为具备成本效益的现实。”然而，这四个研究支柱的进展并不均衡：无服务器运行时和推理路由偏向工程落地，记忆系统和多智能体编排更依赖前沿研究突破。现阶段还没有公开的第三方基准测试来验证这些技术声明的独立性和可复现性。

资本为何甘愿为“无人类操作员”的公司买单

本轮融资的资本结构带着明显的 YC 生态烙印，但又不止于加速器系。除了 Y Combinator 自身继续追投，Nexus Venture Partners 作为领投方在印度和美国 SaaS 市场都有深厚布局，其入局表明投资人不只是想投一个代理工具集，而是看好自主运营实体在整个亚太中小企业中的扩张潜力。

天使投资者的背景更透露了一层信息。Tim Zheng 的 Apollo 正处在让 AI 代理处理销售流程的前沿，JD Sherman 在 HubSpot 时期的经验直接关联成千上万家中小企业的增长工具链，Robert Chatwani 在 DocuSign 的视角则紧贴电子签约和自动化合规的法律效力。这群人共同押注的逻辑可以提炼为：如果未来数百万家小公司真的由代理自主运营，那么今天就需要一个像 AWS 之于云计算那样的代理基础设施层，而 Naïve 正在抢占这个“代理时代的控制面”。

不过，公司的商业模式至今未披露。它是按照代理执行时长和 API 调用次数来定价，还是收取 SaaS 固定订阅费，抑或从代理发起的交易中抽佣，全都未对外说明。在没有定价页或公开合同的情况下，即使有数千开发者声称在使用平台（Dorje 在 LinkedIn 上称“今天就有数千开发者”），也缺乏可量化的商业转化证据。对一家 A 轮公司来说，没有公布任何收入指标或付费客户数量，意味着其产品可能仍处于免费预览或邀请制阶段，距离可重复的销售模型还有显著距离。

监管者还没有到，但问题已经在评论区等着了

在创始人融资帖子的公开评论区，最先涌出的并不是祝贺，而是对代理实际掌控银行账户和法律身份时的责任归属的尖锐提问。一条被广泛看到的评论写道：“监管机构首先会问的是发放给代理的虚拟卡，而不是编排层。你们怎么界定代理控制真实银行渠道时的责任范围？”另一则则追问：“当自主代理去签约服务时，你们怎么处理责任问题？”

这切中了 Naïve 产品架构中最敏感的一环。公司的平台不但提供虚拟支付卡和 LLC 注册，还允许开发者设置代理的花费限额和能力策略，但这并不意味着法律风险就此转移。真正的诉讼场景是：一个代理在某个监管管辖区以企业名义签订了合同，后来发生违约，究竟是谁负责？是构建代理的开发者，提供基础设施的 Naïve，还是承担支付能力的发卡行？这些边界尚未被任何现有判例澄清，而 Naïve 的治理防火墙和审计日志充其量只是技术层面的留痕工具，并不改变法律上的责任主体模糊。更复杂的情况可能出现在跨司法管辖区时：一家通过美国某州 LLC 注册的代理公司，在欧盟开展业务时将面临 GDPR 合规问题，而代理的训练数据中未必包含这些地区的法律知识。

此外，如果全球主要云服务商或金融科技巨头决定自己下场，推出一款“Agent-Formation-as-a-Service”，将公司注册、虚拟卡和云基础设施打包成标准产品，Naïve 的先发优势可能会迅速被渠道和客户关系所抵消。AWS 已经拥有无服务器计算 Lambda，Stripe 也有大量开发者生态和支付数据，两者打通后的协同成本远低于一家初创公司从头构建平行体系。Naïve 当前唯一的护城河是把这些能力用代理优先的 API 层整合起来，但这一层整合在技术上并非不可复制。

从数千开发者到一个可重复的收入模型，还有很长的路

即便创始人声称有数千开发者正在使用平台，但“使用”的定义跨度很大，可以是创建了配置文件、运行了测试环境或只是注册了账号。公司没有给出月活跃开发者数、活跃代理数或任何商业化里程碑，也尚未公布真实运行环境下的代理存活时长、故障率和客户留存情况。对于一家定位为“代理基础设施”的公司来说，这些运维指标可能比用户数更能反映其技术成熟度。

另一个待验证的前提是，自主公司的需求本身是否真的会如投资人预期的速度爆发。要让代理长期合法合规地运营公司，仅靠 KYC/KYB 和虚拟卡还远远不够，持续的税务申报、劳动法合规、数据隐私审计、知识产权归属等环节今天仍然严重依赖人类专业服务。Naïve 的产品定位停留在“对代理友好的操作层”，并不负责替代注册会计师或律师。这意味着早期用户很可能是自带法律和财务团队的高技术型组织，而不是其投资人愿景中提到的“数百万小企业主”。向中小企业真正普及代理运营，不仅需要技术成熟，还需要监管和法律服务供应链的整体配合，短期内很难兑现。如果自主公司的市场教育和合规基础设施建设进度慢于预期，Naïve 可能陷入“产品已就绪，但市场未准备好”的冷启动困境。

公司目前在资料中将自身描述为一个“小型、远程优先的团队”，这暗示其研发投入高度集中，但大规模客户支持、合规咨询和安全事件响应能力可能尚未建立。这些能力是否能在烧钱速度允许的窗口内补齐，也是一个需要跟踪的变量。

RecodeX 极客视：Naïve 把 KYC、支付、虚拟卡和 10,000 种工具集成到一个配置文件里，本质上是替 AI 代理铺平走向现实世界的最后一公里。但这一公里的路面并不平坦：监管责任比编排逻辑更难统一，计费模型和经济价值仍需付费用例检验。当自主公司真正跑起来的那一刻，人们争论的不再是冷启动毫秒数，而是法庭上该把传票送给哪一行代码。