速览

项	值
仓库	different-ai/openwork
一句话	"The open-source alternative to Claude Cowork (powered by opencode)"——但它替代的不是 Cowork 本身，而是 Cowork 唤起的「能力复用」诉求
Star / Fork / Issues	23253 / 2307 / 414 open（2026-09-01）
主语言 / 体积	TypeScript 89.9% / ~291 MB
最新版本 / 节奏	v0.18.40 / 约 1 天/版本
许可证	目录切分许可（GitLab 式）：ee/ 之外 MIT，ee/ 为 OpenWork EE License（SPDX=NOASSERTION，L3）
成熟度	0.x 活跃（工程治理七家最规范，产品仍在 0.x）

一句话结论：七个样本里唯一不抢「桌面入口」、专做「能力分发」的项目——它把自己做成一个 MCP server 让别人来连，工程治理最好，但它和自称要替代的东西不是一个物种。

0. 先给结论

openwork 的 tagline 是 "The open-source alternative to Claude Cowork (powered by opencode)"，但真正定义它的是 README 里一句容易被忽略的话："The desktop app is there when you want a dedicated workspace, but it is not required"——桌面端只是可选项，主体是 OpenWork MCP 与 Den 控制面。

它真正有意思的地方有三个：

1. 它是七个样本里唯一站在「能力分发层」的。 别人卷的是桌面入口、引擎兼容、执行记录、个人助理，openwork 卷的是"一套 skills / MCP / 连接，怎么让组织里的人在不同工具里复用"。它的核心资产不是桌面 app，是 OpenWork MCP 和 Den 控制面——把 skills / MCP / 连接服务做成可跨工具、跨人、跨机器复用的组织级能力包。
2. 它用「反向注入」解决多引擎问题。 七个样本里大多数项目的多引擎策略是「我去适配你的引擎」，openwork 反过来：把自己做成 MCP server，让各引擎来连。对外只暴露两个工具——search_capabilities 与 execute_capability。所有引擎都以同一个 MCP 客户端身份接入，拿到的是能力调用，不是执行控制。OpenWork 不接管 agent 的执行循环、不负责上下文管理、不做权限回调。
3. 它是七个项目里工程治理最规范的。 强制 DCO sign-off（每个 commit 都要 Signed-off-by），ee/ 目录的改动还需额外 CLA；evals/ 目录放可执行测试规格并要求 PR 附测试证据；worlds/ 放声明式的开发与测试环境定义。SPDX 为 NOASSERTION 恰恰是「不够开源」的误读——它只是根目录 LICENSE 是混合声明文件，开放度分目录看（ee/ 之外纯 MIT）。

而它最大的问题也有三个：形态与宣称错位（Cowork 是桌面操控型 agent，openwork 是能力分发型 MCP 层，二者不是一个物种）、「跨引擎」是能力面而非执行面（对 OpenCode 是原生，对其余引擎只通过 2 个 MCP 工具对接）、ee/ 目录生产使用需付费订阅（5 人以下/30 天评估/开发测试豁免，但组织规模上来就要钱）。

1. 赛道定位：它站在哪一层

沿用本系列的分层法：

┌──────────────────────────────────────────────────────────────┐
│  编排 / 工作台层                                              │
│  跨引擎、跨 worktree、跨交付物的调度与观测外壳                 │
│  ── orca（执行编排）/ iPolloWork（桌面工作台）在这里 ──        │
├──────────────────────────────────────────────────────────────┤
│  能力分发层（openwork 占的一层）                              │
│  把 skills / MCP / 连接做成可跨工具复用的组织级能力包          │
│  ── openwork 的 OpenWork MCP + Den 控制面在这里 ──            │
├──────────────────────────────────────────────────────────────┤
│  编辑器内 Agent 层                                            │
│  嵌在 IDE / 编辑器里的交互层                                  │
├──────────────────────────────────────────────────────────────┤
│  执行引擎层                                                   │
│  真正跑 agent loop 的地方                                     │
│  ── Codex / Claude Code / OpenCode / 各引擎在这里 ──          │
└──────────────────────────────────────────────────────────────┘

openwork 的站位在七个样本里是独一份：它对桌面入口的争夺是零（桌面 app 明确标为可选），对执行层的争夺也是零（不接管任何引擎的 agent loop）。它抢的是中间那层——「能力从哪来、谁能用、怎么分发」。

这与 orca 和 iPolloWork 形成鲜明对照：orca 用 PTY 外壳把 30+ 引擎拉平到最薄的一层（执行编排），iPolloWork 用原生 adapter 给个别引擎做深（桌面工作台），openwork 直接不碰执行层和桌面入口——它想回答的问题不是"怎么接最多 agent"或"怎么做出最好用的工作台"，而是"组织的能力怎么一次创建、处处复用"。

风险也在这里：「跨工具能力分发」是引擎厂商最容易原生化的一层——一旦 Anthropic / OpenAI 官方的 skills 市场与组织管理后台做好跨工具分发，openwork 的价值窗口就关闭了。它的护城河（组织侧能力分发 + 工作流网络效应）建立在一个时间窗口上：官方还没做好这件事。这是它最该被盯住的地方。

2. 业务维度：它靠什么活着

目标用户三类，都很垂直：

• 已在使用 Codex / Claude Code / Cursor 且不想换工具的开发者
• 需要统一管控 agent 能力（谁能用什么模型、谁能拿到什么 skill）的中大型组织
• 想把自己搭好的工作流分发给同事或朋友的团队

变现路径：Den 订阅（组织控制面）。 免费额度写得很明确：5 人以下组织的非 Enterprise 功能全免、任意规模 30 天评估、开发测试永久免费。个人和小团队几乎不会触发付费条件，但组织规模上来就要订阅——这是典型的 open-core 模型。

许可证是目录切分许可（GitLab 式）：ee/ 之外为 MIT（L1 级），ee/ 为 OpenWork EE License（source-available，生产使用需订阅）。整体 SPDX=NOASSERTION，openness=L3。有一个值得单独说的机制：ee/ 版本公开发布满两年后自动追加 MIT 授权（Grant of Future License）——早期版本最终也会进入开源域，更早版本仍受原 FSL-1.1-MIT 约束，不自动升级。客户端侧资源（image / font / CSS / 编译产出的 JS）始终为 MIT。

护城河由两件事构成：组织侧的能力分发与治理（谁能用什么模型、谁能拿到什么 skill），以及「一次创建、处处复用」带来的工作流网络效应。一旦组织把内部 skills 都发布到 Den，迁移成本取决于是否有导出路径——README 未说明，这是一个未明的锁定风险。

竞争风险非常直接：最容易被 Anthropic / OpenAI 官方的 skills 市场与组织管理后台正面取代。openwork 的价值恰恰建立在「官方还没做好跨工具能力分发」这个时间窗口上——窗口一关，护城河就变成一张过期的门票。

3. 场景维度：它在什么场合被用

人机协作是审批式，但审批不在执行层而在组织层：能力调用需人工在浏览器登录并选择组织；企业侧由管理员通过策略管控。它不做工具越界审批（那是执行引擎的事），它管的是「谁有资格调用什么能力」。

三端形态，MCP 是主体：

典型用例三类：

• 团队写好一套内部 skill，通过 Den 发布到组织，成员在各自惯用的 agent（Codex / Claude Code / Cursor）里调 search_capabilities 直接用
• 管理员限制部分成员只能使用指定 model provider，并统一配置共享连接（Google Workspace / Microsoft 365）
• 个人把工作流分享给朋友，对方装一个 MCP 就能用

交付物是 workflow、skill-package、capability——三个都不是代码。这与 orca 的「code + diff」、maka 的「code + eval-report + execution-record」、iPolloWork 的「生成后可编辑的多形态交付物」完全不同：openwork 交付的是能力本身，而不是能力的执行结果。

4. 技术维度：它怎么做到的

架构：MCP 远程服务 + 可选桌面 + Web 控制面

openwork 的技术骨架一句话：把自己做成 MCP server，让各引擎来连。技术栈是 Electron + React + TypeScript + Node.js 24 + pnpm + MCP。

┌─ Codex / Claude Code / Cursor / OpenCode / 任意 MCP client ─┐
│                                                             │
│  各引擎 ──MCP 客户端──> OpenWork MCP Server                 │
│                          │                                  │
│                          ├──> search_capabilities           │
│                          │   （发现可用能力）                │
│                          └──> execute_capability            │
│                              （调用能力，不接管执行循环）    │
│                                                             │
│  Den 控制面（Web）：策略下发 / 配额管控 / 访问审计          │
│  桌面 app（可选）：OpenCode 生态，专属工作区               │
└─────────────────────────────────────────────────────────────┘

与 orca 的「我去适配你的引擎」完全相反：orca 是引擎抽象层（PTY 外壳把 30+ 引擎拉平），openwork 是能力注入层（把能力推给各引擎）。

引擎抽象：对等且都浅

这是 engine_neutral = 6 的含义：它接得住 4+ 引擎，但都只在能力面。对外宣称的「跨引擎通用」与内部实际的主从关系存在落差——OpenCode 是原生，其余是 MCP 外挂。这与 iPolloWork 的「Codex 仅 MCP 控制面」是同一个问题的两种解法：iPolloWork 把 MCP 当补丁（主体是桌面），openwork 把 MCP 当主体（桌面是可选）。

多 agent：未强调，重心在能力共享与治理

openwork 不强调多 agent 编排——它不关心「agent 怎么协作完成一件事」，它关心的是「能力怎么在组织里流转」。这与 tutti（唯一把「多人」写进定位）也完全不同：tutti 的多人是同一空间内的人与 agent 协作，openwork 的多人是跨工具的能力分发。

本地优先：可本地跑，但核心服务在云端

local_first_score = 6。桌面 app 本身 BYO（自带模型，不绑定共享账号），skills 可以本地跑；但核心服务——Den 控制面、OpenWork MCP 远程端点（https://api.openworklabs.com/mcp/agent）——是云端的。组织管控、能力分发、审计追踪都依赖云服务。这决定了它不是 local-first 项目，而是 cloud-anchored + local-optional 项目。

扩展体系：skills 是一等公民

• skills：一等公民——可发布、可分配到组织/团队/个人；支持导入 Agent Plugins 与 Anthropic 兼容插件并转为 OpenWork MCP 能力
• plugins：通过 marketplace 发布与分配
• MCP：自身即以 MCP server 形态对外提供服务，同时也消费下游 MCP 连接

扩展体系的中心不是「插件市场」，是 Den 的能力分发管道——skill 不是装在本地的，是发布在 Den 上、由组织分配到具体成员/团队的。

观测性：观测「谁用了什么能力」，不是「agent 怎么把事做完的」

Den 提供推理配额管控与访问审计；桌面 app 侧未见 agent 执行轨迹的记录设计。openwork 的观测维度是能力调用层（谁、什么时候、调了什么能力、配额用了多少），不是执行层（agent 的 tool call 序列、上下文演化、终止事件）。这与 maka 的 append-only 执行记录、orca 的 diff/review 完全不同——它观测的是「能力的流转」，不是「执行的轨迹」。

5. 横向对比

说明：下表项目均已收录进本系列追踪库，数据来自各自档案（data/projects/*.yaml，2026-09-01 快照）。"引擎中立度 / 本地优先"取自档案 chart.*（1–10）。

openwork 在谱系里的位置，用一句话概括：唯一站在「能力分发层」、不抢桌面入口、不碰执行层、把 MCP 当主体当产品的那个角落。 orca 卷的是「怎么接最多引擎」，iPolloWork 卷的是「怎么做出最好用的工作台」，maka 卷的是「agent 干了什么能不能证明」，openwork 卷的是「组织的能力怎么一次创建、处处复用」。七个样本里，只有它交付的是「能力」而不是「能力的执行结果」。

6. 宣称 vs 实测

这一节是本系列最看重的部分。openwork 项目方没有说谎——它的 README 在许可证和桌面定位上都做了明确披露——但「披露得充分」和「没有错位」是两回事。

① 宣称：「Claude Cowork 的开源替代品」。 实际：形态完全不同。Cowork 是桌面操控型 agent（直接操作你的电脑完成工作）；openwork 是能力分发型 MCP 层，桌面 app 被明确定位为可选——README 原文 "The desktop app is there when you want a dedicated workspace, but it is not required"。它替代的是 Cowork 唤起的「能力复用」诉求，不是 Cowork 本身。用 tagline 里的「alternative」来理解产品形态，会得出错误预期。 来源：README 开篇与「Use OpenWork from any agent」段。

② 宣称：跨 Codex / Claude Code / Cursor / OpenCode 多引擎通用。 实际：对 OpenCode 是原生的（仓库描述 powered by opencode，桌面端属其生态）；对其余引擎只通过自己暴露的两个 MCP 工具对接。这是能力调用面，不是引擎执行面——openwork 不接管这些引擎的执行循环、上下文与权限。对外宣称的「跨引擎」与内部实际的主从关系存在落差：OpenCode 是亲儿子，其余是 MCP 外挂。 来源：README「It exposes two tools」段；仓库 description「powered by opencode」。

③ 宣称：free, open-source（免费开源）。 实际：需要分目录看：ee/ 之外确实 MIT 且免费；但 ee/（Den 组织控制面、MCP 网关、推理）属 source-available，生产使用需付费订阅，只有 5 人以下组织、30 天评估、开发测试三种情形豁免。个人免费，团队与企业要付费。这不是「开源变味」，而是标准的 open-core 模型——但「free, open-source」这个 tagline 没有把 open-core 的边界说清楚。 来源：README Licensing 段 + ee/LICENSE 原文 72 行。

④ 宣称：（无明确宣称，但 SPDX 为 NOASSERTION，易被误读为「不够开源」）。 实际：恰恰相反——它是七个项目里工程治理最规范的：强制 DCO sign-off（每个 commit 都要 Signed-off-by）、ee/ 目录改动需额外 CLA、evals/ 目录放可执行测试规格并要求 PR 附测试证据、worlds/ 放声明式的开发与测试环境定义。NOASSERTION 只因根目录 LICENSE 是混合声明文件，不代表开放度低——ee/ 之外是纯 MIT，且 ee/ 版本满两年自动追加 MIT（Grant of Future License）。 来源：README「Getting started (contributors)」与「Sending a pull request」段。

四条里有三条是 README 自己写出来的——但披露方式和产品定位的错位是结构性的：tagline 说「Cowork 的替代品」，实际是「能力分发层」；tagline 说「free, open-source」，实际是 open-core；tagline 说「跨引擎通用」，实际是能力面通用。这不是欺骗，是营销叙事与产品形态的错位——用 Cowork 的品牌势能来给一个不同物种的产品引流。

7. 结论：什么人该用它

该用： - 已固定在某款 agent 上（Codex / Claude Code / Cursor）、不想换工具、只想让团队能力跨工具复用的开发者 - 需要统一管控 agent 能力与模型配额的组织 IT——Den 的策略下发、配额管控、访问审计是七个样本里唯一把「组织能力治理」做成产品的 - 想把自己搭好的工作流分发给同事或朋友、对方装一个 MCP 就能用的团队 - 5 人以下小团队——免费额度覆盖所有非 Enterprise 功能，30 天评估期足够验证

不该用： - 想要一个开箱即用的桌面 agent 工作台的人——桌面 app 是可选壳，不是主体；六个内置能力不如 orca / iPolloWork 的丰富 - 以为拿到的是完整 Cowork 平替的人——形态完全不同，它不操作你的电脑，它分发能力 - 需要本地优先 / 数据不出机器的团队——核心服务在云端（Den + OpenWork MCP 远程端点），local_first_score 只有 6 - 以为 SPDX=NOASSERTION 代表开放度低的许可证审查者——ee/ 之外是纯 MIT，ee/ 满两年自动转 MIT；开放度分目录看，不是整体看

再看看： 等四件事落地再评估——① Den 的能力导出路径是否出现（当前无导出说明，锁定风险未明）② 官方 skills 市场 / 组织管理后台是否开始做跨工具分发（这是它护城河的头号威胁，每季度盯一次 Anthropic / OpenAI 的动作）③ ee/ 第一批版本满两年后是否如期追加 MIT（Grant of Future License 的兑现记录）④ 桌面 app 是否会从「可选」变成「主体」——如果它开始卷桌面体验，定位会从能力分发层漂移回桌面工作台层，届时需要重新评估其在谱系中的位置。

8. 追踪备注

• 数据日期：2026-09-01（GitHub API 快照）
• 指标：★ 23253 / fork 2307 / open issues 414 / subscribers 89 / ~291 MB / TypeScript 89.9% + JavaScript 6.7%
• 最新版本：v0.18.40，约 1 天/版本
• 源码镜像：gitinbox/openwork（public，source-only 快照——排除 ee/ 与 LICENSES/LicenseRef-OpenWork-EE.txt 后为纯 MIT，判 public；上游 291 MB，本机到 GitHub 实测 50 KB/s，拉取耗时较长）
• 结构化档案：data/projects/openwork.yaml

下次跟进点：

1. Den 控制面：能力导出路径是否出现（当前无导出说明，锁定风险未明）
2. 官方威胁：Anthropic / OpenAI 的 skills 市场与组织管理后台是否开始做跨工具分发
3. 许可证兑现：ee/ 第一批版本满两年后是否如期追加 MIT（Grant of Future License 的兑现记录）
4. 定位漂移：桌面 app 是否从「可选」变成「主体」——如果开始卷桌面体验，需要重新评估其在谱系中的位置

_{本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 gitinbox/agent-radar}