ARTICLE · 1156166
OpenClaw 企业版开源:它想把 Agent 变成 工作负载
现在的 AI 团队，agent 可能比人多。
每个人本地跑几个，服务器上再挂几个，配着不同的模型、不同的密钥、不同的权限。谁在用什么、能不能叫停、出事怎么追溯，基本靠问。这不是模型能力问题，是运维问题。
8 月底，一个叫 OpenClaw Enterprise（OCE） 的项目在 GitHub 开源，MIT 协议，一句话自我定位写得很直白：
一、它先把这件事拆成两个面
控制平面（OCC，OpenClaw Control Plane） 负责配置和管理 agent 的部署。它的 API 先做鉴权，再由 worker 通过 Driver 异步地把工作负载创建、更新出来。
数据平面 负责真正干活：agent 的 gateway 收消息、调模型、跑工具。
这条界线很关键——部署 agent 是控制平面的事，处理一条消息是数据平面的事。很多 agent 框架把两者糊在一起，于是"改个配置要重启进程""回滚没有版本可回"。
二、四个值得记住的设计
1. Agent 是持久定义，部署产生不可变版本。
创建一个 agent 只是写了一条持久的工作负载定义，它自带身份，但不会启动进程。真正的部署动作会生成一个不可变的 AgentRevision（配置与执行设置的快照），worker 把它供应出来、激活、开始接流量。改 agent 或改配置不会影响正在跑的版本，想生效就再部署一次。
这是 Kubernetes 里 Deployment 与 ReplicaSet 的思路，搬到 agent 上：版本可回滚是设计出来的，不是补出来的。
2. Gateway 与 Harness 分离，两种执行模式。
每个部署出来的 agent 有自己的 gateway（接客户端连接与消息），Harness 负责执行 agent 的回合与工具调用。官方支持两种模式：Embedded OpenClaw（gateway 与 Harness 跑在同一个工作负载里），以及 Dedicated Codex（gateway 连接一个独立的 Codex Harness 工作负载）。
3. Secret 只回元数据。
配置（Configuration）存可复用的设置，密钥单独存成 Secret。控制平面只返回 Secret 的元数据，不返回值；由配置绑定把指定的密钥送到 agent 的 gateway，在那里再由 OpenClaw 解析自己的 SecretRef。密钥不进 API 响应、不进聊天记录——这类"看不见"的设计，正是企业能不能用它的分水岭。
4. 每个 Agent 有自己的身份，不继承创建者的权限。
权限模型是三段式的：Role 定义权限，AccessBinding 在某个范围内授予 Role，Restriction 用来拒绝。人是 Principal，自动化是 ServicePrincipal，而每个 agent 有自己稳定的 ServicePrincipal，不会继承创建者的权限。另外 OCC 的 ServiceAccount 只用来把 agent 绑定到一个凭证引用，和 agent 的身份、和 Kubernetes 的 ServiceAccount 是三件事。
一句话：agent 是被当作独立主体管理的，而不是某个人的影子。
三、技术栈：TypeScript 单仓 + Go CLI，跑在 Kubernetes 上
仓库里同时躺着 pnpm-workspace.yaml、go.mod、drizzle.config.ts，还有六份 compose（kubernetes、postgres、logging、metrics、podman、基础那份）。代码分工也很清楚：
apps/controller/：HTTP API、浏览器控制台、worker、Driver packages/contracts/：资源模型、Driver 接口、API schema packages/occ/：资源生命周期、持久化、工作队列 packages/iam/：身份、角色、资源鉴权 packages/audit/：审计事件与敏感值脱敏 cmd/occ/+ internal/occcli|occclient：Go 写的 CLItests/：一致性测试与集成测试
一句话概括：Go 写 CLI 和客户端，TypeScript 写控制平面与控制台，Postgres 存状态，Kubernetes 干活。
四、上手要付多少成本（具体口径）
依赖清单不短：Docker 或 Podman、k3d、kubectl、Helm、Bash、Python 3、Go、Node.js 24+，外加仓库里钉住的 pnpm 版本。本地起控制平面大致是：
部署第一个 agent，官方给的是一条命令：
几个数字值得记住：这个 gateway Pod 请求 1792Mi 内存（约 1.75 GiB），官方要求集群留出这个量；默认模型是 gpt-6-astra，想换就设 OPENCLAW_FIRST_AGENT_MODEL；密钥推荐用 OPENAI_API_KEY_FILE 指一个私有文件，或者从你的密钥管理器注入环境变量——不要写进命令、配置 JSON 和聊天窗口。这条建议本身，就是它和"本地跑个 demo"的分界线。
五、谁在做这件事
看贡献者名单能看出分量：derekwaynecarr、sjenning、mrunalp、sallyom、russellb、jacobtomlinson、steipete……再加上几个 *-openai 后缀的账号。这是一批做 Kubernetes、容器运行时（CRI-O/Podman）、OpenShift 的人，和 OpenAI 的人混在一起的阵容。
这也解释了为什么它的气质不像又一个 agent 框架，而像基础设施项目：不讲 prompt 技巧，讲命名空间、不可变版本、鉴权、审计。
六、我的判断
它抓住了真问题。 今天 agent 的瓶颈早就不是"能不能跑通"，而是"能不能管住"：谁批的、用了谁的密钥、能不能回滚、出事有没有审计流水。OCE 把这些当成一等公民，而不是事后补丁。
"Agent 的 Kubernetes"这个类比是有用的，不是营销话术。控制平面/数据平面、不可变 revision、Driver 供应、命名空间隔离——这套东西 Kubernetes 已经教过我们一遍，现在只是把工作负载从容器换成了 agent。
但它还非常早期。 截至我看的时候：385 颗星、76 个 fork、0 个 release、8 月底才创建、Backend 抽象在文档里明确标注 experimental。想上生产，得接受"跟着 main 分支走"的现实。
所以它适合谁？ 已经在跑 Kubernetes、并且 agent 数量开始失控的团队——尤其是被合规和审计问过"你这几个 agent 谁在管"的团队。如果只是想跑一个 demo，它太重了：你需要一个集群。
仓库地址：github.com/openclaw/openclaw-enterprise
模型能力决定 agent 能做什么，控制平面决定 agent 能不能被公司用。后者才是接下来两年真正要补的课。