在 OpenAI DevDay 上，OpenClaw（“小龙虾”）创始人 Peter Steinberger 与 OpenAI 的 OpenClaw Enterprise（OCE）负责人 Kevin Lin，分享了团队如何用 OpenClaw 开发 OpenClaw：ClawLabs: Building Open Source Together。

Peter 已经能同时运行许多 Agent 会话，但队友想参与，仍要找他转述需求；审查代码时，也常常只能看到改了什么，看不到为什么这样改。他们因此把工作搬进共享会话，让队友直接参与，并把看板、会议记录和持续维护放进同一个工作空间。团队规模扩大后，还需要统一管理这些常驻 Agent 的身份与权限。

OpenClaw 是让 Agent 持续运行、跨工具与团队协作的开源平台。它由独立非营利机构 OpenClaw Foundation 持有，OpenAI 提供支持。演讲当时，平台已支持用 ChatGPT 账号登录、接入订阅、沿用插件并查看 Codex 会话。OpenClaw Enterprise（OCE） 则负责组织里的 Agent 部署、身份与权限管理。

---

为什么个人会话难以支持团队协作

Peter 在开场回顾了他在开源项目维护中的工作流变化。早期他主要在终端（CLI）环境工作：屏幕分屏开启多个 Codex 会话，代码在窗口间流转。随着模型能力提升，需要敲击 Esc 键强行打断和微调 Agent 的频率逐步降低，工作流随后转向了带有可视化界面、内置浏览器和审查面板的桌面客户端。

随着并行任务和实验数量增加，单台设备的物理限制很快显现：

• 笔记本电脑的磁盘空间迅速耗尽；
• 散热风扇持续高负荷运转；
• 为了分担本地压力，他开始连接多台 DevBox，并搭建了名为 Crabbox 的云端测试环境，同时操控六到十台机器运行代码与实验，通过 Codex 或 VNC 远程桌面进行管理。

增加机器并未解决协作层面的阻碍。当团队其他成员想要参与进来或向 Agent 分派任务时，由于无法直接接入会话，只能找 Peter 代为转达。Frank Allenby 用 “人肉中转”（Meat Proxy） 来形容这种状态：开发者成了团队成员与 AI 之间的中介，同事提出需求由你转达给 Agent，Agent 生成代码后再由你复制给同事，团队成员并没有真正围绕 Agent 协同起来。

此外，代码背后的决策上下文容易断裂。一条简短的提示词可能会生成成千上万行代码改动，但背后的提示词与对话记录往往只保存在个人的本地客户端中。当团队成员在代码库中审查一个大型改动时，能看懂修改了哪些具体代码，却难以了解生成这些代码时与模型交互的提示词与讨论背景。

同一项修改 两种协作路径

队友的请求，先到谁手里？

并排看两种工作方式，再追踪提出修改、回看原因和接续任务时，上下文留在哪里。

提出修改回看修改原因接续任务

各自用 Agent

队友提出需求想改表格，但会话在别人手里

需求先找人 ↓

Peter 来回转述多台机器仍由一个人接住协作请求

再把话交给 Agent ↓

个人 Agent 会话代码能分享，生成过程仍留在个人端

队友需要通过会话拥有者理解或接续工作。

共享会话一起工作

有权限的队友提出需求进入团队共同使用的工作空间

直接提示或接续 ↓

共享会话与 Agent提示词、工作过程和产物留在同一处

打开同一段上下文 ↓

队友看见改动缘由可以读记录，也可以继续调整方向

会话成为团队可以共同参与的工作过程。

提出同一项修改：左边先请 Peter 转述，右边由有权限的队友进入共享会话。

按演讲中同等访问权限的团队模式作说明；共享不等于向所有人开放。

为了改变这种分散脱节的状态，团队开始探索将 Agent 从个人单机迁移到多人共享的工作空间中。

---

共享会话如何让队友参与同一项工作

为了解决各自为战的问题，团队尝试引入多人协作模式。团队不再将服务器单纯视作隔离的执行后端，而是转变为一个团队成员随时在线的共享工作空间。

在共享服务器上，团队成员可以直接看到彼此的会话记录，并能够向彼此的会话发送提示词进行接力或调整。

共同修改：小游戏演示

在现场演示中，Peter 通过语音向 PartyClaw 提议制作一个类似《Frogger》（青蛙过河）的小游戏。请求发出后，系统提示团队成员 Kevin 已经提前构建了一个可用的版本（Lily Lane）。Peter 打开试玩后，希望将主角从青蛙改为大龙虾。

随后，Peter 提供了临时链接让在线参与者加入服务器。在多人同场在线的环境中，界面显示有多名成员在同时输入，Peter 抢先发送了将角色改为龙虾且不要大象的提示词；随后游戏界面重新加载，生成了包含龙虾与鲨鱼的版本。

共享前提：同等权限与相互信任

这种多人协作模式建立在特定前提之上：它专为具备同等访问权限且互相信任的团队而设计。Peter 在演讲中明确提醒：“不要邀请你不希望动你工作会话的人（Don't invite anyone who you don't want to mess with your sessions）。”多人并发参与意味着成员可以对彼此的会话进行修改，这要求团队对任务目标有共同的理解。共享会话有助于提前了解彼此意图并减少部分冲突，但并不意味着传统的 Pull Request 机制已经退出（PR 即 Pull Request，是提交给代码库审查和合并的一组改动）。

要把个人会话放到团队可见的服务器上，团队通常需要经历习惯上的转变。Peter 提到，此前他曾尝试编写插件，希望成员在提交 PR 时附带脱敏后的对话记录，但大家很少愿意分享，他自己有时也不愿提交，因为与 Agent 交互的提示词往往带有强烈的个人试错习惯和随意口语。当团队在内部服务器上默认公开会话后，大家经历了约一天的适应便逐渐习惯，开始通过查看彼此的提示词相互学习提问方式，并在较早阶段发现思路偏差。

理解改动：Victor 的表格案例

透明的会话记录在团队日常协作中发挥了关键作用。演讲中展示了一个因改动认知不一致而引发讨论的实际案例。

某天早晨，Peter 看到自动化工具提交的一个 PR，作者是团队同事 Victor。该 PR 的改动是将界面中的聊天表格尺寸调小。由于 Peter 前一天才刚花时间将这些表格调大，看到改动时感到十分不解。

在 PR 详情中附带了关联的工作会话链接，使他人能够回查当时的交互过程。Peter 点击打开 Victor 的工作会话，了解了背后的经过：

1. Victor 并非脱离前作随意推翻，而是直接复用了 Peter 前一天的会话上下文；
2. Victor 在会话中通过邮件或消息给 Peter 发了提醒；
3. 在会话交互中，Victor 顺带提到了对 CI 运行耗时的抱怨（这是会话中的另一个独立话题）；而在表格修改上，Victor 对布局进行了认真推敲，将表格设计为按内容自适应扩展，解决了过大或过小的问题。

了解这些背景后，Peter 认可了 Victor 的改动方案，避免了一次不必要的沟通误解。当代码审查能够直接关联生成代码的工作会话，团队成员就能直观了解修改背后的考虑，降低了异步协作中的理解成本。

---

如何让共享工具和长期任务持续运行

共享工具：会话生成，自动化更新

在团队内部协作中，开发者常常需要维护许多配套工具，例如 CI 耗时看板、社区 PR 统计面板等。以往这类工具散落在不同的服务器或自动化脚本中，更新维护较为繁琐。

Peter 用 “果冻软件”（Jellyware） 来形容那些通过会话生成并能快速响应修改的轻量级内部工具：

• 这类工具通常由一个会话生成包含代码的产物（Artifact），并配合一个自动化任务来定期更新该会话；
• 当用户需要调整界面或功能时，可以直接用提示词要求 Agent 修改（例如对 Agent 说“把这个面板改成蓝色”），Agent 便会更新相应代码并刷新显示。

除看板外，团队还搭建了 Daily Claw，尝试提取服务器上合并的改动并汇总为报纸形式。Peter 提到，这份日报“有时挺不错，但很多时候非常错误（many times it's very wrong）”，生成的内容依然需要人工核实，不能直接当成准确记录。

CI 看板：查看测试耗时

持续集成流水线（CI）是高频运行代码测试的关键环节。随着 Agent 协作的深入，传统的全量测试方式在响应速度上带来了一定压力。

Peter 在演讲中提到，现有的 CI 模式有待进一步优化。他正在结合 Codex 探索由模型辅助评估哪些测试子集切实有用，从而筛选相关的测试运行。目前这仍属于探索尝试，并非已经解决的成熟方案。

Slop Meter：提醒清理冗余代码

在使用 Agent 编写代码时，代码很容易越生成越多。为了避免废弃或冗余代码持续堆积，Peter 搭建了名为 Slop Meter 的看板，提醒团队关注代码膨胀，并要求 Agent 清理冗余代码。Peter 认为，看板提高了大家的关注度，让事情朝更好的方向发展。

会议记录：保存上下文与接续任务

在日常沟通方面，团队利用一段提示词结合模型（GPT-5.6-Luna）来自动总结 Discord 会议的语音转录。

Peter 介绍，这类会议记录 Agent 还可以接入 GPT Live 进行双向语音交流，支持开发者在会议中直接询问工作进展或发起新任务（现场未演示这一实时对话功能）。由于 Agent 在服务器上拥有统一的身份标识，并沿用主会话积累的项目上下文，会议里的新要求能够直接接上已有的项目工作。

长期任务：循环维护与目标推进

在后台自动化运行方面，Peter 将任务明确区分为“持续循环（Loops）”与“阶段目标（Goals）”两类：前者负责持续的反复检查，后者面向具备明确终态的长期任务。

两种长期工作 两种完成条件

循环一直跟踪，目标朝终态推进

Loop · 持续维护

1. 监控反馈，读取报告并调查
2. 在测试环境中明确复现问题
3. 提出修复，验证问题是否解决
4. 交给另一个 Agent 审查
5. 条件全部满足，才进入合入

任何必要条件未满足，都不能直接合入。

下一轮仍会跟踪新的反馈；循环中断或需要调整时，团队要接管维护。

Goal · 逐步改造

明确终态把同步数据库访问改成异步访问演讲中的项目仍使用 SQLite

1. 向这个终态逐步推进重构
2. 验证改动，并持续合入
3. 目标尚未完成，就继续推进

Peter 自述：这个目标当时运行了 18 天，已合入 100 多个 PR。

这是一项仍在推进的具体改造，不是固定时长，也不是所有项目的通用产能。

Loop：反复检查反馈与发版

持续循环用于维持系统的常态运行与质量监控：

• Bug 修复循环：Peter 编写了小型 CLI 工具，以便 Agent 高效获取 Discord、社交平台和 GitHub 上的反馈数据。获取反馈并分类后，针对更新故障等问题，Agent 会读取报告并展开调查，随后启动独立测试环境尝试复现错误。只有在能够明确复现时，Agent 才会尝试生成修复补丁；在验证修复生效后，再交由另一个审查 Agent 进行代码复核；只有全部条件均满足时，改动才会自动合入。若无法明确复现、验证失败或审查未通过，则均不能直接合入。
• 发版检测与回归检查：团队服务器每天发版后，更新循环会自动检测到新的发布，抓取快照并检查是否存在性能回退或需要改进之处。

这些循环本身有时会中断，或者需要根据实际情况进行人工调整与维护。此前这些循环分散在个人不同机器上运行，甚至难以厘清具体位置；团队目前正逐步将循环迁移到团队服务器上，以便其他成员了解与接管。

Goal：推进有明确终点的改造

与常态循环不同，阶段目标（Goals）面向具有明确终态的任务。

Peter 举了一个正在进行的实例：将代码库从同步 SQLite 逐步重构成异步数据库访问。目前该项目仍在使用 SQLite，重构目标仍在逐步推进中；随着系统规模扩大，团队也在考虑未来是否让数据库本身具备可插拔（swappable）能力。根据 Peter 在现场的自述，这个目标任务在本地 Codex 环境中已持续运行了 18 天，期间逐步拆分并合入了 100 多个 PR。

---

团队扩大后，OCE 如何管理身份与权限

前面的共享空间面向同等权限、互相信任的成员。放到组织里，不同团队与任务需要分别配置资源和访问范围；组织还要知道哪些 Agent 在运行、它们以什么身份访问系统，以及如何调整权限或停用。多人协作之外，还需要一个统一的管理层。

为了解决企业部署与权限治理的痛点，OpenAI 的 Kevin Lin 正式公布了开源项目 OpenClaw Enterprise (OCE)。OCE 提供集中式的控制平面，管理 Agent 的部署、配置、身份与访问权限（控制平面是管理层；多租户是把不同团队或项目的资源与访问范围分开管理）。

具体执行工作的是 Harness（包裹在模型周围、处理工具调用、执行环境与上下文状态的运行框架），它决定了 Agent 如何操作工具与环境，OpenClaw 底层能够接入 Codex 的开源执行底座（开源范围是执行底座，不包括模型本身及全套云端服务）；而 OCE 则是位于执行层之上的管理层。官方发布资料强调，OCE 保持厂商中立，不仅模型可以自由切换，包括 Harness、模型以及沙箱在内的核心组件，均能替换为第三方方案或企业内部实现。

权限机制：四项控制如何配合

Kevin 在分享中介绍了支撑 Agent 部署的四项安全机制，各项机制承担不同的边界职责：

1. 可信逻辑与执行隔离（Separate Workloads）：确定性的控制逻辑（如网关与配置管理）与非确定性的 Agent 代码执行相互分离。执行环境运行在独立的容器或环境中，防止 Agent 反向篡改其底层的运行配置。
2. 沙箱约束（Sandboxing）：通过沙箱对 Agent 的运行行为施加约束，控制其网络出口、文件系统读写路径，以及能够推送的目标代码仓库，限制其权限扩散。
3. 模型辅助审查（Model-based Auto-review）：在敏感动作执行前，引入另一个模型对操作风险进行评估与拦截，作为一道补充防线。模型审查提供风险判断，不能替代系统自身的访问控制策略，也不等同于人工批准。
4. 独立服务账号与身份（Dedicated Identity）：为 Agent 配置独立的服务账号（Service Account）与连接器，作为持久实体存在，不直接借用人类员工身份，使 Agent 具备独立的审计标识，可被单独管理、审计或在必要时停用。

在实际配置中，这四种机制相互配合。以演示中的社区 Agent “Fred” 为例：系统对其配置了代码库的只读权限，使其可以查阅代码回答问题，但无权推送修改；接入 Linear 协作系统时，允许其读取规划，但写入操作必须经过团队审批；同时辅以模型审查进行操作风险过滤，但不代替组织权限颁发许可。这些配置把同一个 Agent 的不同动作分开管理：能读代码，不代表能提交代码；接入 Linear，也不代表能自由修改记录。

以 Fred 的演示配置为例

给 Agent 一个任务，不等于给它所有权限

选择动作，查看组织配置如何区分“允许读取”“不允许写入”和“先申请批准”。

代码库只读 · 用于回答问题

Linear写入须经团队审批

Slack按所选频道与私信策略接入

读取代码库推送代码修改写入 Linear

独立身份Fred自己的服务账号

请求 →

组织设定读取代码库只读权限覆盖这项动作

→

资源一侧配置允许读取读代码与推送修改是两种不同权限

代码库被配置为只读，所以读取可以被许可，推送修改不能沿用读取权限。

系统权限决定哪些资源和动作被允许。

模型审查补充识别行动风险，不能替组织授予权限。

人工审批由团队决定需审批的那次写操作是否可以继续。

这是基于演示配置的权限说明，不调用真实资源；获得许可也不等于执行已经成功。实际隔离和审批能力仍取决于部署配置。

补充背景 · 会员文章OpenAI 将 Codex 的底层核心框架 Agent Harness 开源：你可以轻松将 Agent 接入自己的业务系统进一步了解执行底座怎样管理上下文、工具与审批，以及它和业务应用怎样分工。阅读介绍文章 →

部署演示：按任务配置 Agent

在现场演示中，Kevin 展示了如何在 OCE 控制台中拉起一个名为 Fred 的社区 Agent。

控制台提供了预设（Preset）机制，即组织预先打包的可配置资源包（configurable agent bundles），以便按需创建具备常用安全配置的 Agent 草稿：

• 运行框架配置为 Codex Harness；
• 分配专属的独立服务账号；
• 赋予代码库只读权限，以便查阅代码来回答问题；
• 接入协作平台 Linear：允许读取项目规划，写入修改则需团队审批；
• 接入 Slack：从凭据存储中引用现有的 Bot Token 与 App Token，配置限定在选定的 4 个频道内使用，并将私信策略设置为禁用（这些是本次演示选定的频道和私信策略）。

Cooper：队友接续开发会话

在发起创建 Fred 后的启动等待期间，Kevin 切换到了另一个已在运行的软件工程 Agent Cooper。

Cooper 被作为团队中常驻的协作 Agent，用于日常协助分类处理 issue、排查缺陷及推进功能。Kevin 明确指出，通过 OCE 部署的每一个 Agent 都内置了多人协作支持。他在现场演示了如何打开经过认证的 Cooper 团队服务器会话：团队同事可以登录到同一个工作会话中，既能实时跟进进展，也能直接输入提示词继续引导开发。

现场演示中，Kevin 向 Cooper 发出请求，希望在控制台界面增加“各 Agent 的 Token 使用量热力图”，并进一步在会话中提示要求“支持自定义调色板”。现场展示了下发需求与在会话中接力引导的过程，现场没有展示完成后的界面。根据 Kevin 在演讲中的自述，OpenAI 内部部署了超过 400 个 Claw 实例，用于协助修复代码、运行实验、分析数据及跟进安全问题；对于用户提交的 Codex issue，软件 Agent 能够分流排查、在测试环境中复现，并合入其中的一部分修复 PR。

Fred：读取工作信息与回答偏题

在介绍完 Cooper 后，Kevin 返回社区界面向刚刚启动完成的 Fred 提问：“我们今天在发布什么？”

Fred 接收提问后检索了 Linear 与 Slack 的上下文。数秒后 Fred 给出了回答，但内容仅展示了 OpenClaw 的发版说明，漏掉了发布 OCE 的关键事项。Kevin 在现场提到可能有插件问题（“Oops, I think we have some plug-in issues”），并在台上打趣让 Fred 下次表现更好。

---

OCE 目前处于什么阶段，有哪些限制

根据官方发布说明，OCE 目前处于 1.0 正式发布前的开源共建阶段，适合组织开展内部试点。该项目最初由 OpenAI 发起，早期便捐赠给了独立的非营利机构 OpenClaw Foundation，并与 Red Hat、NVIDIA 等伙伴共同开发，保持厂商中立。Kevin 在演讲中将其与 Kubernetes 进行类比，主要表达的是希望将其打造为 Agent 部署与管理基础框架的长期愿景，而非指其当前已经成为行业既定标准。

在实际运行架构上，Kevin 在台上提到内部实践中在不同集群上分离运行环境，而公开架构文档的默认方案则是单 Kubernetes 集群：

• 在单集群的多租户（multi-tenant）模型下，若采用嵌入模式（Embedded），Gateway 与 Harness 在数据平面合并运行；
• 只有采用专用执行模式（Dedicated Kubernetes execution）时，才会在租户命名空间内使用独立的 Gateway 与 Harness Pod、分离的身份与存储；Gateway 通过受限的文件操作接口与 Harness 通信，而不直接挂载其工作区。

双集群运行配置目前仍属于实验性阶段。在单集群部署中，运维人员必须自行配置互斥的节点池、网络策略与存储隔离规则；因为命名空间管理员本身拥有较高权限，网络策略和凭据挂载并不能直接对 Namespace 管理员形成硬隔离。

此外，公开设计文档中记录的部分规划能力（如外部访问网关、免凭据推理中介驱动等）目前尚未完全支持。演讲中还提到了 OpenAI 的官方企业集成方案 Dots：Dots 侧重于开箱即用的原生产品体验，而 OpenClaw 与 OCE 则聚焦于开源中立、模型可换、全代码可控与基础设施自托管，两者后续的双向互通也是团队的研究方向。

---

自动化之后，人还要负责什么

从单机终端下的分散会话，到利用共享服务器沉淀协作上下文，再到引入控制平面管理运行权限与部署边界，这场分享展示了软件工程从“人肉中转”走向团队协同的演进路径。

设计判断：Victor 的侧栏迭代

在长期愿景中，Peter 设想未来每个项目都能配备一个常驻 Agent，拥有独立的记忆、自动化、目标与循环（automations, goals, loops），由人类下发高级指令来协助维护。在这种分工下，工程师不可替代的核心价值在于品味（Taste）——交互细节的体感、视觉设计的直觉与架构风格的取舍，往往属于主观判断，难以完全托付给模型。

在演讲中展示在线成员侧栏时，就体现了这种品味推敲的具体过程：Peter 先为侧栏做了一个显示谁在线的粗糙版本；Victor 想要把它改得更好看，让 Agent 生成了多个不同设计版本，甚至让 Agent 搭建了专门的编辑器来微调样式，但 Victor 依然不满意；随后其他队友也加入到同一个会话中共同修改、继续提出要求，最终才敲定了一个更有吸引力的版本。

这一过程表明，团队在共享工作空间中所沉淀的，不仅是最终合入的代码，还有如何向 Agent 提出要求、如何在多个生成方案中挑选取舍的推敲过程。无论后台自动化如何运行，挑选方案的审美判断与对 Agent 系统的维护职责，始终留在人类手中。

运行维护：让自动化保持可用

Peter 对这种分工的概括是：团队也在“维护那些替自己构建软件的 Agent”。虽然持续循环能够自动检查反馈、阶段目标能够持续重构架构，但这些后台运行的自动化本身会中断、需要调整，依然离不开人类的日常维护；而在交互体验、架构风格与方案取舍中，人类的品味（Taste）更是系统不可或缺的指南针。

开源共建：扩大工具可及性与修复漏洞

在开源社区层面，团队扩展了 Codex 开源支持计划，并通过与 Trail of Bits 等安全机构合作的 Patch the Planet 项目，探索利用 Agent 修复开源基础软件中的整类安全漏洞。让持久 Agent 在真实团队中稳定落地，既需要可信的权限与隔离边界，也始终需要人类工程师在共享协作中持续注入判断力。