gitea-publish
de6cf8f3c0
- articles/: 新增 5 篇深度文（八段结构，每篇含 claim_vs_reality） - maka.md → emlog_id=105 - openclaw.md → emlog_id=106 - openwork.md → emlog_id=107 - qwenpaw.md → emlog_id=108 - tutti.md → emlog_id=109 - data/projects/*.yaml: 回写 emlog_id 到 6 个档案（orca 前序已回写） - articles/00-overview.md: build_matrix.py 重算矩阵 + 回填总纲
240 lines
22 KiB
Markdown
240 lines
22 KiB
Markdown
# openwork 深度拆解：把「能力」而不是「桌面」做成产品
|
||
|
||
> **速览**
|
||
>
|
||
> | 项 | 值 |
|
||
> | --- | --- |
|
||
> | 仓库 | [different-ai/openwork](https://github.com/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. 赛道定位：它站在哪一层
|
||
|
||
沿用本系列的分层法：
|
||
|
||
```text
|
||
┌──────────────────────────────────────────────────────────────┐
|
||
│ 编排 / 工作台层 │
|
||
│ 跨引擎、跨 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 是主体：**
|
||
|
||
| 形态 | 定位 | 成熟度 |
|
||
| --- | --- | --- |
|
||
| OpenWork MCP（远程服务） | **主体**——能力面，不是执行面 | 核心产品 |
|
||
| Den 控制面（Web） | 组织级管控：策略下发、配额、审计 | 付费层 |
|
||
| 桌面应用（Electron） | **可选**——专注工作区，非必需 | 0.x 活跃 |
|
||
|
||
**典型用例三类：**
|
||
|
||
- 团队写好一套内部 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。
|
||
|
||
```text
|
||
┌─ Codex / Claude Code / Cursor / OpenCode / 任意 MCP client ─┐
|
||
│ │
|
||
│ 各引擎 ──MCP 客户端──> OpenWork MCP Server │
|
||
│ │ │
|
||
│ ├──> search_capabilities │
|
||
│ │ （发现可用能力） │
|
||
│ └──> execute_capability │
|
||
│ （调用能力，不接管执行循环） │
|
||
│ │
|
||
│ Den 控制面（Web）：策略下发 / 配额管控 / 访问审计 │
|
||
│ 桌面 app（可选）：OpenCode 生态，专属工作区 │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
与 orca 的「我去适配你的引擎」完全相反：orca 是引擎抽象层（PTY 外壳把 30+ 引擎拉平），openwork 是**能力注入层**（把能力推给各引擎）。
|
||
|
||
### 引擎抽象：对等且都浅
|
||
|
||
| 维度 | openwork 的做法 |
|
||
| --- | --- |
|
||
| 兼容判据 | **MCP 客户端身份**（任何能连 MCP 的引擎都能接） |
|
||
| 抽象层 | OpenWork MCP（能力面，不是执行面） |
|
||
| 对外暴露 | **只两个工具**：search_capabilities + execute_capability |
|
||
| 执行控制 | **不接管**——不接管 agent loop、不管上下文、不做权限回调 |
|
||
| 真正深度绑定 | OpenCode（仓库描述 powered by opencode，桌面端属其生态） |
|
||
|
||
这是 `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 | orca | iPolloWork | maka | QwenPaw | Tutti | OpenClaw |
|
||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||
| 站位层次 | **能力分发层（MCP 主体）** | 执行编排层（并行 fan-out） | 桌面工作台层 | 执行记录层 + 自带引擎 | 个人助理执行层 | 多人×多 agent 协作层 | 个人助理执行层（多渠道 Gateway） |
|
||
| 引擎中立度（1–10） | 6（能力面接 4+ 引擎） | **9（全场最高）** | 7 | 1（不参与该赛道） | 2（自身即引擎） | 8（ACP 双层） | 1（自身即引擎） |
|
||
| 本地优先（1–10） | 6（核心服务在云端） | 6 | 7 | **10（全场最高）** | 9 | 7 | 8 |
|
||
| 交付物 | **能力（MCP）+ workflow + skill-package** | code + diff + review-comment | 生成后可编辑的多形态交付物 | code + eval-report + execution-record | 个人助理任务 | 多人协作会话 | 个人助理任务 |
|
||
| 许可证 | L3（目录切分：ee/ 外 MIT / ee/ EE） | MIT（L1） | L3 source-available | Apache-2.0（L1） | Apache-2.0（L1） | Apache-2.0（L1） | MIT（L1，机器读不出） |
|
||
| 成熟度 | 0.x 活跃（工程治理最规范） | 原型期（一天一版） | beta（v0.50.x） | 孵化期（无正式 release） | beta 活跃 | 快速成长期 | 高速迭代（约 4 天/版本） |
|
||
| 观测维度 | **谁用了什么能力** | 执行轨迹 + diff | 生成结果 | 执行记录全落盘 | 五层安全审计 | 协作会话 | 多渠道日志 |
|
||
| 变现 | **Den 订阅（open-core）** | 无 | 无 | 无 | 无 | open-core | 无 |
|
||
|
||
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 是否从「可选」变成「主体」——如果开始卷桌面体验，需要重新评估其在谱系中的位置
|
||
|
||
---
|
||
|
||
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
|