business 11 分钟阅读

OpenClaw的控制层押注,揭示代理战争的真正赢家

OpenClaw Enterprise推出免费开源的持久化AI代理控制层,由OpenAI、红帽和英伟达联合支持。这一举措揭示了一个更深层的现实:代理市场的真正瓶颈不是智能,而是信任。

  • Switch模拟器
  • 骚扰性洪水
  • harness
  • Opus 5
  • 人工智能

企业 AI 的真正瓶颈不是智能,而是许可

OpenClaw Enterprise(OCE)刚刚以免费开源控制面的形式发布,专用于持久化 AI Agent,其背景足以让每一位 CTO 坐直身子。该项目起源于 OpenAI,后被捐赠给 OpenClaw 基金会,如今在 Red Hat 和 Nvidia 的共同贡献下独立运营。OpenAI 与 Red Hat 均已在其内部开展试点。

真正值得关注的并非这项公告本身,而是它折射出企业 AI 市场究竟处在什么阶段、下一步将走向何方。

企业在部署持久化 Agent 时面临的难题已经转移。五年前,问题在于 AI 能否执行任务;今天的问题在于,企业能否安全地让数百乃至数千个自治 Agent 触碰生产系统、内部仓库、凭据、API 以及敏感数据。面对这一缺口,部分 IT 组织的选择是直接禁止自治 Agent 平台。而 OCE 正是在"禁令"与"混乱"之间试图搭建的那一层。

OCE 是 Agent 的 Kubernetes——而这很重要

项目仓库明确表达了其愿景:OCE 实际上就是 Agent 领域的 Kubernetes。这一类比并非营销话术,而是清晰标明了项目的架构定位与战略位置。

Kubernetes 解决了一个从未在大规模场景下被解决的问题:如何在组织基础设施上一致地运行容器化工作负载,并实现治理、多租户和生命周期管理。OCE 正在尝试为 Agent 做同样的事——在你选定接入的模型或运行时之上,提供部署、审计、权限控制和沙箱能力。

这些设计选择体现了这一点。OCE 以 MIT 许可证发布,保持厂商中立。企业可以自行替换模型、运行框架和沙箱实现。开发阶段使用 Docker Compose 自托管,生产环境则运行在 Kubernetes 上。你不需要将 Agent 活动发送到第三方 SaaS 服务——基础设施保持在你 IT 团队已经运营的地方。

正是最后这一点,让 OpenAI 的参与变得 quietly radical(悄然激进)。该公司同时在推出 Dots——居住于 ChatGPT 及其云端环境中的持久化 AI 同事——并在内部用名为 Androidclaw 的 Agent 试点 OCE。该 Agent 会触碰 OpenAI 自身的代码库、Git 仓库、GitHub 以及日志系统,排查构建故障,甚至在某些情况下准备并合并修复方案。OpenAI 技术团队成员 RJ Marsan 将这种 Agent 追踪问题并发布修复的能力形容为"简直是颠覆性的"。

OpenAI 正在同时构建 Agent 体验层和 Agent 治理层。这是刻意的定位策略,而非偶然。

企业 Agent 基础设施的三层架构正在成形

OCE 并非孤立存在。另外两个项目勾勒出了围绕它的架构层次。

NanoClaw 是轻量级运行时层。它在容器内运行单个 Agent,为每个 Agent 提供独立的工作空间和内存,支持消息通道,并优先考虑简洁性和隔离性。其开发团队将 NanoClaw 紧凑的 TypeScript 实现与 OCE 规模大得多的应用层运行时进行了对比。NanoClaw 提出的问题是:我如何安全地运行这一个 Agent?

Runlayer 占据商业治理层。该公司于 2026 年 6 月从 Felicis 和 Khosla Ventures 获得 3000 万美元 A 轮融资,累计融资达 4200 万美元。客户包括 Instacart、Gusto、Opendoor 和 dbt Labs。Runlayer 不仅治理其平台上构建的 Agent,还覆盖一个组织更广泛的 AI 生态——Claude Code、Cursor、ChatGPT、Codex 和企业 MCP 服务器——同时检测未经授权的影子 AI 使用行为。它提供集中式策略、身份感知工具过滤、可观测性和审计能力。Runlayer 提出的问题是:我们如何治理员工接触到的每一个 AI 工具?

OCE 位于两者之上。它提出的问题是:企业如何在自有云环境中,以统一的身份、权限、治理和基础设施策略来运营一组 Agent?它是基础设施,而非产品。这一区分决定了它会吸引谁、又会错过谁。

Red Hat 和 Nvidia 正在补齐周边的空白

OCE 周围的合作伙伴生态进一步印证了基础设施深度的论点。Red Hat 在 2026 年一直在探索如何让 OpenClaw 及类似 Agent 在共享企业基础设施上安全运行。其 OpenShift 工作通过独立命名空间、受限访问控制和凭据代理,将 Agent 与敏感凭据隔离,并将 Agent 进程本身视为不可信对象。Red Hat 作为创始成员加入了 OpenClaw 基金会,并计划将该项目的要求整合进其更广泛的企业 AI 平台——涵盖多租户执行、基于身份的工具过滤,以及在 Kubernetes 环境中的 OpenShell 隔离。

Nvidia 开发了 OpenShell——一个开源运行时,将自治 Agent 置于具备默认拒绝权限、策略执行和审计跟踪的隔离环境中。Nvidia 更广泛的 Open Agent Safety Platform 在此基础上增加了独立监控能力,以约束那些行为超出策略的 Agent。OCE 有效运行于这些运行时保护之上,提供用于大规模部署和治理 Agent 的组织控制面。

这是一套技术栈,而非单一产品发布。各合作伙伴正在构建相邻的层次,因为在 Agent 治理这一端到端问题上,目前没有任何一家公司能够独力完成。

OCE 最薄弱的地方,比它承诺的更重要

尽管架构令人印象深刻,OCE 尚未完成。基金会建议将其用于内部试点工作负载,并刻意提前发布源代码,以便开发者和组织在计划于今年晚些时候发布的 1.0 版本之前参与塑造该平台。重要的安全细节仍在后续补充中。OpenClaw 表示将发布一份参考架构文档,解释工作负载边界、沙箱、基于 LLM 的审核和权限如何协同运作——但这份文档目前尚不存在。

采用 OCE 的企业实质上是在为一个治理着触碰生产系统的自治 Agent 的基础设施自愿加入 Beta 测试。这笔交易是真实的:以不成熟的安防文档和未定的发布时间表为代价,换取对厂商中立、自托管 Agent 编排的早期访问权。

Runlayer 在今天更接近一款可交付的产品。它有商业支持合同、现有客户群,以及更广泛的功能范围——覆盖影子 AI 发现、投资回报分析和企业 MCP 目录管理——这些都是 OCE 尚未触及的领域。NanoClaw 提供了简洁性和更小的攻击面,适合单个 Agent 场景。OCE 提供了深度,但需要更多的组织投入。

OpenAI 的悖论及其释放的信号

OpenAI 的双重举措——将 Dots 和 Space 作为其专有 Agent 体验推出,同时将 OCE 作为开放基础设施进行试点——是此次发布中最具揭示性的战略信号。Dots 是工人,Space 是这些工人与人类协作的空间,而 OCE 则是用于治理超出 OpenAI 自身产品范围的更广泛 Agent 机队的底层设施。

这两种路径互补而非矛盾。OpenAI 可以在内部或专业化 Agent 的底层使用 OCE,同时将 Dots 和 Space 作为面向员工的体验对外暴露。基金会公告已确认 OpenAI 正在内部试点 OCE。

这一策略与云厂商在实现市场主导地位后的行为如出一辙:将关键基础设施开源使其成为通用标准,然后在基于之上构建的服务和体验层面展开竞争。Kubernetes 是最初的剧本,OCE 可能是下一版。

接下来的赢家不是最聪明的模型

DevDay 上的 Dots 公告与 OCE 的发布共同定义了那个拐点。持久化 Agent 正变得足够有能力,去触碰日益敏感的工作流。然而,围绕它们的运营基础设施,相较企业已用于管理人类身份、云工作负载和常规应用的系统,仍处于不成熟阶段。

如果 OpenClaw 的押注成功,Agent 市场的下一阶段将不再主要由哪个模型能生成最智能的回复来决定,而是由哪套基础设施获得企业足够信任、得以让这些模型付诸行动来决定的。模型层正在快速商品化,而治理层的价值则缓慢复利累积。OCE 正是对"治理层将在企业市场胜出"这一判断的下注。

当参考架构发布、1.0 版本到来、企业判断一个由基金会构建、MIT 授权、免费使用的控制面是否足够稳定以治理触碰其最敏感系统的 Agent 时,这一赌注将受到考验。OpenAI 和 Red Hat 的试点项目是早期证据,但它们还不是完整的故事。