你们要学习思考，然后再来写作。——布瓦罗

当 AI 工作流终于可以被真正“共享”：OpenWork 想做的不只是一个桌面应用

项目地址：https://github.com/different-ai/openwork

这几年，越来越多人开始把 AI 真正带进日常工作里。问题也随之变得具体起来：技能怎么复用，MCP 怎么共享，连接过的服务能不能在不同工具之间通用，团队里一个人搭好的能力，能不能别总是从头再来一遍。

OpenWork 看上去，正是奔着这些现实问题去的。

从仓库 description 来看，它的定位非常醒目：Claude Cowork 的开源替代方案，而且基于 opencode 驱动。 README 则把这个方向进一步展开：OpenWork 是一个免费、开源的桌面应用，专门用于分享 AI 工作流，并且同时面向 macOS、Windows 和 Linux。

这很重要。因为它一上来就没有把自己说成“另一个 AI 聊天客户端”，而是把重心放在了工作流共享上。也就是说，它关心的不是你跟某个模型说了什么，而是你已经沉淀出来的那套能力，能不能跨工具、跨同事、跨机器继续活着。

它不强迫你换掉现在的 AI 代理

OpenWork 的一个非常讨喜的地方，是它并不要求你把现有工具扔掉。

README 开头就说得很清楚：桌面应用是为那些想要一个专用工作空间的人准备的，但它不是必须的。 你完全可以继续使用自己已经在用的 agent，然后通过一个 OpenWork MCP，把同一套技能、MCP、已连接服务复用到 Claude Code、Codex、Cursor 或其他兼容工具中。

这是一种非常克制、也非常聪明的产品姿态。

很多工具总想把你整个工作方式连根拔起，再重新安置到它自己的世界里。OpenWork 看上去并不打算这样做。它更像是在说：你已经有自己的代理了？没关系，把我接进来就行。你已经积累了一些技能和服务连接？很好，不用重来，把它们带着走。

这种“不是替换，而是打通”的思路，会让整个项目显得非常顺手。

核心想法其实很简单：一处配置，多处复用

README 中有一句特别能概括 OpenWork 的价值：

给 Codex、Claude Code、Cursor 或其他兼容 agent 加上一个 OpenWork MCP，就能在你的工具、队友和机器之间复用同样的技能、MCP 和已连接服务。

这句话读起来很像是在替现代 AI 工作流世界做一次“去孤岛化”。

今天很多 AI 工作习惯其实是碎片化的：

这个技能只在某个客户端里有
那个 MCP 只在某台机器配过
某个账号连接只对某个人自己的环境有效
团队里别人即使想复用，也得重新走完整配置

OpenWork 想做的，就是把这些原本分散在各处的能力，尽量变成可被统一分发、统一复用、统一调用的资产。

不是“你在哪个工具里工作就只能用那个工具的世界”，而是“能力应该跟着你和你的团队走”。

安装方式也非常符合它的世界观：甚至可以让另一个 AI agent 来帮你装

在 “Install with your AI agent” 这部分，README 给了一种很有意思的安装方式：

它不是先让你手动点一堆步骤，而是直接给你一段 prompt，告诉你把它粘贴进 Claude Code、Cursor、Codex、ChatGPT 或任何能在你电脑上运行命令的 agent 里。

这段 prompt 是：

1	Install OpenWork on my computer, set up my first workspace, and open it ready to use. Follow the steps in https://openworklabs.com/start.md?v=hero

然后 README 总结说，这样做会完成三件事：

安装 OpenWork
创建你的 workspace
打开并准备好使用

这段设计特别有时代感。它不是单纯在教你“怎么安装一个软件”，而是在承认一种新的现实：安装软件本身，也可以成为一次 AI 代理执行的工作流。

这和 OpenWork 的整体理念非常一致——它不是单纯适配 AI，而是在把 AI 作为工作环境中的默认协作者来考虑。

它的 MCP 是真正的桥梁

OpenWork 的 README 把 MCP 这一层写得很清楚。

它说，OpenWork MCP 会把这些东西带进任意兼容 agent：

分配给你的 skills
plugins
MCP connections
Google Workspace 能力
Microsoft 365 能力

而且它只暴露两个工具：

search_capabilities
execute_capability

这个设计很有意思。表面上看，它像是极简；实际上，它在做的是把复杂度尽量收束到“搜索”和“执行”这两个动作里。用户并不需要先理解所有底层组织结构，而是先找到自己能用什么，再直接调起来。

更妙的是，README 还提到：在添加 MCP 之后，客户端会打开浏览器，让你登录并选择自己的 OpenWork workspace。也就是说，OpenWork 不只是一个静态的远程地址，它背后连着身份、工作区和可分配能力的上下文。

主流 agent 的接入方式都已经写好

README 分别给出了几种接入方式。

Codex

1	codex mcp add openwork --url https://api.openworklabs.com/mcp/agent

Claude Code

1	claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent

OpenCode

在 opencode.json 中加入：

{
  "mcp": {
    "openwork": {
      "type": "remote",
      "enabled": true,
      "url": "https://api.openworklabs.com/mcp/agent",
      "oauth": {}
    }
  }
}

任意 MCP 客户端

README 也直接给出远程 MCP 服务地址。

这种安排非常友好，因为它没有停留在“我们支持很多客户端”的笼统表述，而是直接给出每个主流场景的实际配置方式。你几乎不用再做二次猜测，照着接就行。

OpenWork Den：它不只面向个人，还在认真考虑团队和组织

如果说桌面应用和 MCP 解决的是“个人工作流如何复用”，那么 README 里的 OpenWork Den 则把问题推到了组织层面。

README 把 Den 定义为：

用于在团队或组织范围内管理 OpenWork 的 control plane。

接着列出了它能做的事情：

大规模 provision inference，并控制成员和团队可以使用哪些 model provider
邀请队友、创建团队、统一管理访问权限
设置桌面策略、限制本地模型访问、控制组织可用的应用版本
通过 marketplace 发布 skills 和 plugins，并把它们分配给组织、团队或个人
导入兼容 Anthropic 的 plugins，并把其支持的 skills 和远程 MCP 通过 OpenWork MCP 提供出来

这部分读起来会让人感觉，OpenWork 并不是一个“桌面小工具 + 一个远程接点”这么简单。它更像是一套分层设计的系统：

桌面端解决个人使用与专属工作空间
MCP 解决跨 agent 复用
Den 解决组织级治理、分发与策略控制

这一下就把它的视角抬高了。它不只是想帮某个人把几个 AI 能力串起来，也想帮团队把这些能力真正变成可管理、可分配、可限制、可共享的工作资产。

它有一种很鲜明的“控制面 + 执行面”结构感

从 README 的表述来看，OpenWork 的架构思路其实很现代：

桌面应用是个人使用和专用工作空间
OpenWork MCP是跨客户端能力分发层
OpenWork Den是组织层面的控制平面

这种分层让人觉得它不是“在一个客户端里塞进所有功能”，而是在认真划分每一层该解决的问题。

个人需要什么？
—— 一个可以工作的入口。

不同 AI agent 之间怎么复用？
—— 交给 MCP。

组织怎么控制权限、能力、模型供应商和桌面策略？
—— 交给 Den。

这种结构感是 OpenWork 特别有魅力的地方之一。它没有把自己缩成一个单点应用，而是在试图组织一整套 AI 工作流基础设施。

本地开发部分也透露出它是个相当认真打磨的桌面项目

README 的 Local development 部分不长，但细节不少。

如果只是一个 checkout，继续用：

pnpm dev

如果要同时运行多个 git worktree，则使用：

1	pnpm dev:worktree

README 还解释了这个模式具体会做什么：

设置 OPENWORK_DEV_PROFILE=auto
从 worktree 路径导出稳定的 profile 名称
让 Electron 自动选择一个空闲的 CDP 端口
让 Vite 自动拿一个空闲 dev server 端口

甚至还提到：

dev:worktree 默认会设置 OPENWORK_ELECTRON_USE_MOCK_KEYCHAIN=1
新 profile 没有存储凭据，在 macOS 上如果用真实 keychain，Chromium 一持久化认证状态就会弹提示
如果第二个实例拿不到 profile lock，它会明确提示并退出，而不是挂着一个开了 CDP 端口却没有窗口的幽灵进程

这类细节特别说明问题。它表明 OpenWork 并不是“勉强能开发”的 Electron 项目，而是已经认真考虑多 worktree 并行、端口冲突、profile 隔离、keychain 行为和实例锁定这些真实开发场景。

仓库里的 .devcontainer/README 更进一步展示了它的“真实桌面测试”野心

OpenWork 并不只是有一份产品 README，它还在 .devcontainer/README.md 里铺开了一套非常完整的云端开发与测试环境说明。

这份文档最先强调的一点就很抓人：

这是一个在云沙箱中运行真实 Electron 应用 + Den stack 的全栈开发环境。你可以通过浏览器里的 noVNC 去看和操作桌面应用。

这意味着什么？意味着它不是用“假 UI”或“局部预览”来凑，而是真的把 Electron 应用跑起来，然后让你在浏览器里接触它。

文档中列出的服务包括：

Desktop App（通过 noVNC 暴露）
Den Web
Den API
CDP Debug
Vite HMR
MySQL

甚至还给出了对应端口与用途说明。

这会让整个项目显得非常“工程化”。它不是只有产品层面的一句愿景，而是已经把开发、验证、远程运行和自动化测试环境组织成了一整套流程。

Daytona 环境的说明，像是在读一份完整的实验室使用手册

.devcontainer/README.md 中有大量关于 Daytona 的使用方式，包括：

如何创建快照
如何运行 Electron/noVNC 测试
如何准备 provider secrets volume
如何输出可下载评估产物
如何录制视频
如何用单独 server sandbox 托管 Den stack
如何通过 CDP 和 noVNC 驱动真实桌面应用

文档还解释了架构：

浏览器通过 noVNC 连接桌面
Electron 暴露 CDP
Vite 提供 HMR
Den Web / API 与 MySQL 构成服务侧

甚至说明了何时该用哪一层证据来做验证：

CDP assertions
Screenshots
Recordings

读这种文档时，会有一种非常鲜明的感受：OpenWork 并不满足于“看起来能跑”，它想让这套桌面和组织管理系统在远程环境里也能被自动化、被验证、被演示、被录证据。

evals/README 更像一个“产品体验证明系统”

仓库里的 evals/README.md 也极具个性。

它一上来就说，这些 evals 不是单元测试，而是用来验证真实运行栈上的端到端 UI 行为。并且它要求每个 eval 既要有自然语言叙事规格，也要有可观测的预期结果，很多还会有程序化 flow。

这份 README 里最有意思的概念之一是 fraimz。文档说，每次运行都会产出 fraimz.html，其中每一帧都会绑定：

claim
action
assertion
screenshot

换句话说，它不是单纯截图存档，而是在做一种“逐帧证据化”的 UI 证明。

此外，文档还强调：

voice-over first
narration 是 spec 的一部分
每一步最好用 ctx.prove(...) 去记录断言和截图
screenshots 不只是漂亮图片，而应该尽量附带 requireText、rejectText、hashIncludes 等验证元数据
录屏是补充证据，逐帧证明才是主要的 pass/fail 依据

这一整套机制非常有辨识度。它让人感觉 OpenWork 对“用户界面如何被证明是对的”这件事，有一种近乎电影分镜脚本般的执着。

从这些 README 里，能看到一个很完整的项目人格

如果只看主 README，OpenWork 已经像一个很清楚的产品：

开源
桌面端
面向 AI 工作流共享
可跨 agent 复用能力
兼容多平台
有组织级控制面

但当你再看 .devcontainer/README.md 和 evals/README.md 时，会发现它远不只是“一个桌面应用仓库”：

它认真经营真实 Electron 运行环境
它认真经营云沙箱测试方式
它认真经营 CDP 驱动和 noVNC 可视化验证
它认真经营逐帧 UI 证据体系
它认真经营组织侧策略、团队分配与 marketplace 能力

这会让它显得特别立体。它不是停留在“想法很好”的阶段，而是已经长出了一套支持这个想法持续被开发、验证、协作和扩展的方法论。

它的目标，其实不只是“让 AI 工具好用一点”

OpenWork 看上去真正想做的，是把 AI 工作流从一次性的个人配置，慢慢变成可以管理、可以共享、可以迁移、可以治理的团队能力。

这和很多人对 AI 工具的第一层期待很不一样。很多工具只是让你“在某个地方多一个聊天窗口”，而 OpenWork 更像是在问：

这些能力能不能跟着人走，而不是跟着某个客户端死锁
团队能不能复用同一套技能，而不是各自重新搭
组织能不能决定哪些模型、哪些插件、哪些能力可以被谁使用
同一份 AI 工作流，能不能既在桌面端存在，又在 Claude Code、Codex、Cursor 等 agent 中被调用

当这些问题被放在一起时，OpenWork 的定位就会变得非常清楚：它不是“又一个 AI 壳子”，它更像一层围绕 AI 工作流的共享与治理基础设施。

如果把 OpenWork 拟人化，它像一个专门负责“别让大家重复造轮子”的协调者

团队里总会有这样一种人：不是最喜欢站到前台发言的人，但特别擅长把别人做过的东西整理起来、打通起来、分发出去，让整个团队少走很多重复路。

OpenWork 很像这样的角色。

它不急着替你做所有事，也不要求你放弃现有工具重新投靠它。它更像是在旁边接过一堆零散的技能、MCP、连接和服务能力，说：这些东西已经有人搭过了，不如我们让它们真正流动起来。

从个人工作区，到跨 agent 的 MCP，再到组织级的 Den 控制平面；从桌面应用，到云端沙箱，再到逐帧 UI eval 证据系统，它一步一步在做的，其实都是同一件事：

让 AI 工作流不再被困在某一个地方。

而这件事，一旦做成，价值往往不是“多了一个工具”，而是“终于有一层东西，能把原本分散的能力真正组织起来”。