OpenWork 是什么：把技能与 MCP 打包成能力的开源桌面应用

2026-08-04

本文基于 openwork 仓库 commit 3b41381（2026-08-03）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/different-ai/openwork 最新代码与文档为准。

OpenWork 真正下注的不是「再做一个 Agent 桌面客户端」，而是把你辛苦配好的那一堆东西——技能文件、MCP 连接、已授权的第三方服务——抽象成一个统一的「能力」概念，然后只用两个工具把它们送进你已经在用的任何 Agent。理解这一点，它的目录结构、许可证分层、乃至它明确不做的那些事，才能串成一条线。这里说的 OpenWork 是 different-ai 开源的这个桌面应用项目，跟同名的职场点评网站、跟中文里泛指的「开放工作」没有关系。

一、它想解决的麻烦：同一套配置在多个 Agent、多台机器之间来回搬

先说痛点，因为这个痛点决定了后面所有设计。

你在 Claude Code 里写了几个技能文件，配好了三四个 MCP 服务端，又把 Gmail、日历、Slack 挨个授权了一遍。然后你换到 Codex 上做另一件事，这一整套要重来一遍。换台机器，再来一遍。同事想复用你的这套东西，你只能把文件打包发过去，再口头讲一遍授权怎么点。配置本身没有身份、没有版本、没有分发渠道，它只是散落在各个客户端本地目录里的文件和一堆 OAuth 令牌。

OpenWork 仓库 README 把自己定位成 Claude Cowork 与 Codex 的开源替代品，覆盖 macOS、Windows、Linux——这是项目自己的说法，不是本文替它下的判断。但从代码组织看，它真正花力气的地方不在「替代」，而在 README 里紧接着那句：把一个 OpenWork MCP 加到 Codex、Claude Code、Cursor 或其它兼容 Agent 上，就能在这些工具、队友和机器之间复用同一套技能、MCP 与已连接的服务。README 明确写了，桌面应用是「你想要一个专属工作区时它在那儿」，但不是必需的。

这句话的分量在于：桌面应用被降格成了「其中一个前端」。真正的产品是配置本身的可携带性。你要是想先补一下 Agent 平台这一层的整体格局，站内的开源 Agent 平台盘点横向比过一轮；智能体到底是什么从概念侧讲清了 Agent 与工作流的边界；开源 AI 工具选型偏重怎么挑。本篇不重复这些，只钻 OpenWork 这一个仓库：它的能力抽象怎么落地、许可证怎么分层、代价在哪。

二、能力（capability）：所有东西最后都收成一种可检索、可执行的对象

OpenWork 对外只暴露两个 MCP 工具，这是全篇最值得记住的设计。

README 写得很直白：这个 MCP 暴露两个工具，search_capabilities 用来找你能用什么，execute_capability 用来执行它。加完 MCP 之后，客户端会打开浏览器让你登录并选择所属的 OpenWork 组织。

两个工具意味着什么？意味着不管底层是一份技能文档、一条命令模板、一个第三方 MCP 服务端，还是一个已经授权好的 Google Workspace 或 Microsoft 365 连接，在 Agent 眼里都是同一种东西：一条可以被搜到、可以被执行的「能力」。仓库里那份 docs/marketplace-capabilities-architecture.md 架构文档把这条线写得更细——它把这条通路称为「rail」，并且强调新增能力来源时，MCP 的工具面不增长，仍然只有那两个工具。

那不同类型的内容执行起来差别在哪？架构文档用 objectType 字段区分执行语义，并且列了一张相当诚实的表：skill、context、custom、agent 这几类返回的是指令性载荷，也就是最新版本的原始文本，交给主 Agent 自己消化；command 类接收参数并替换 $ARGUMENTS 后返回渲染好的模板，服务端不执行任何命令；mcp 类返回声明的服务端规格加上状态与提示，第一阶段不做自动开通；tool 类直接返回 status: "needs_install"，因为它本地才能跑；hook 类只能被搜到元数据，执行会返回一个「不支持」的提示——文档里点名 apps/server/src/claude-plugin-bundle.ts 会警告 OpenWork 不支持 hooks，本地安装时也会跳过加载。

这张表对使用者的意义很实际：你别指望把一个能力搜出来就等于它能跑。 很大一部分「能力」的执行结果其实是一段文字，是把知识注入到当前 Agent 的上下文里，真正的动作还是当前 Agent 自己做的。文档甚至定义了降级状态，比如 content_not_synced 表示配置对象存在但还没有对应版本内容，执行时会带着提示告诉你去连接或同步来源。

顺带说一句它在概念上的三分法。文档 packages/docs/start-here/do-work-with-it/skills-plugins-and-mcp.mdx 给出的划分是：连接器负责「够得着系统」，技能是「做这件事的写法」，插件是「一堆相关技能一起走的包」。并且它说得很干脆——底层一切皆插件，你让 OpenWork 创建一个技能，它其实创建的是一个只含这一个技能的小插件，所以「这该叫技能还是插件」这个问题大多数人不用回答。这套划分跟 MCP 生态里的通行说法能对上，如果你对协议层本身还不熟，先看MCP 协议是什么会省事很多。

三、仓库长什么样：四个应用、一个企业目录、一堆文档

这个仓库有 3490 个受版本控制的文件，规模不算小，但分区很清楚。下面这张表里的路径都是我在仓库里实际打开或列举过的。

组成部分	它负责什么	对应仓库位置	你什么时候会碰到它
桌面应用与前端	提供本地工作区界面，读取云端下发的策略状态	`apps/desktop`、`apps/app`（如 `apps/app/src/react-app/domains/cloud/desktop-config-provider.tsx`）	日常用桌面应用，或想改界面行为时
服务端 API	应用消费的服务面，插件包解析等逻辑在这里	`apps/server`（`src/` 下 138 个顶层 `.ts`，含 `claude-plugin-bundle.ts`）	自托管、排查插件为什么没生效时
共享包	类型、UI、路径、安装配置、邮件等横向能力	`packages/`，共 12 个（如 `packages/types/src/den/desktop-policies.ts`）	二次开发、对齐策略键名时
团队控制面（企业目录）	组织、网关、推理、工作机运行时等	`ee/apps/`（10 个，如 `den-api`）与 `ee/packages/`（3 个）	给团队做统一管控时，注意许可证不同
文档站	面向用户的使用文档	`packages/docs`，57 份 mdx，其中 `model-context-protocol/` 10 份客户端接入指南	想知道某个客户端怎么接进来时
架构与流程文档	设计说明与端到端流程记录	`docs/` 20 份 md、`evals/` 26 份流程 md	想搞清「为什么这么设计」时
分发打包	三种分发方式：AUR、Docker、Helm	`packaging/aur`、`packaging/docker`、`packaging/helm`	自托管部署、上集群时

packages/docs/model-context-protocol/ 里那 10 份指南覆盖的客户端范围，本身就是这个项目意图的注脚——它不打算把你锁在自己的桌面应用里，而是把每个主流 Agent 客户端的接入方式各写一篇。

再看工程纪律那一侧。AGENTS.md 里对贡献者的要求写得很硬：新增的可执行端到端覆盖只有一条路，evals/specs/**/*.test.ts，test 从 @openwork/testkit 导入，驱动应用的规格用 .slow.test.ts 命名；技能使用顺序是 write-a-spec → run-tests → 失败时 diagnose-a-red-run → 最后 publish-evidence；只有当每一条声明在证据带里都有可观测断言时才允许报 Passed，否则必须报 Incomplete 或 Failed 并给出复现步骤。它还有一条挺特别的流程：功能开发从演示开始而不是从需求文档开始，先用 /voiceover 对齐演示脚本，脚本没批准之前不写代码。你要是打算给这个项目提 PR，这几条比 README 更值得先读。

四、许可证是分层的，不是笼统的「MIT 开源」

这一条最容易被读漏，也最容易在团队采购环节出事。

打开 ee/LICENSE 看，它是 Functional Source License, Version 1.1, MIT Future License，缩写 FSL-1.1-MIT。它的核心机制是「Permitted Purpose」与「Competing Use」这一对定义：授予你使用、复制、修改、创作衍生作品与再分发的权利，但目的必须不属于「竞争性使用」——文本里把竞争性使用界定为在商业产品或服务中让软件对外可用并替代该软件、替代许可方基于该软件已提供的其它产品或服务，或者提供相同乃至实质相似的功能。它同时明确把内部使用与访问、非商业教育、非商业研究，以及为遵守本条款的被许可方提供专业服务这几类列为许可用途。

对应到目录：前面那张表里 ee/apps/ 的 10 个应用和 ee/packages/ 的 3 个包，也就是团队控制面、网关、推理、工作机运行时这一整块，走的是这份 Fair Source 许可，跟 MIT 部分不是一回事。README 里介绍的 OpenWork Den——用来管控组织范围的模型提供方权限、邀请成员建团队、下发桌面策略、限制本地模型访问与允许的应用版本、通过市场发布技能与插件并按组织/团队/个人分配——正是这一层。

所以凡是讲到「团队控制面 / 企业能力」的地方，都不能笼统说成 MIT。能不能商用、能不能改后对外提供服务，一律以许可证原文为准，本文不提供法律意见；真要在公司里落地，把 LICENSE 和 ee/LICENSE 两份原文一起交给法务，比读任何二手总结都靠谱。评估任何一个准备进生产的开源项目，许可与治理这一项都应该排在功能清单前面。

五、边界与代价：它放弃了什么，又明确不管什么

一个把配置集中化的产品，代价一定在集中化本身。逐条摊开。

凭据与授权集中在一处，暴露面也集中在一处。 你在 Settings > OpenWork Connect 里连的 Gmail、Google 日历、Google Drive、Slack、Notion、Linear，本质上是把这些账号的 OAuth 授权交给 OpenWork 侧保管，再由能力通道分发给各个 Agent 使用。文档说得很坦率：连接功能要求登录 OpenWork 账号并加入一个启用了 Connect 的组织，这跟登录模型提供方是两件独立的事。收益是你在任何 Agent 里问「总结我最新的五封邮件」都能跑通，代价是一份凭据集合成了新的高价值目标。授权范围要逐个看清楚，别因为界面上只是点一下「Connect」就放松。相关的加固思路可以参考MCP 授权加固。

接了组织，管控权就有一部分不在你手上。 docs/desktop-app-policies.md 写明桌面应用的策略配置来自云端的 GET /v1/me/desktop-config，策略目录集中定义在 packages/types/src/den/desktop-policies.ts 的 desktopPolicyDefinitions。布尔类型的策略键，false 表示该功能被限制或禁用。文档举的例子包括 allowZenModel 与 allowMultipleWorkspaces——也就是说，组织可以关掉某类模型入口，也可以不让你开多个工作区；allowedDesktopVersions 还能约束允许运行的应用版本。另外策略文档可以携带 onboardingPrompts 与 onboardingPromptDescriptions，在桌面应用里变成引导卡片，点击时把文本插入输入框，但不会自动发送。这些机制单看都合理，合起来的意思是：加入组织之后，你的本地客户端行为由远端配置塑形。 个人自用和企业下发是两种完全不同的风险画像，别混着评估。

它明确不管的事，文档写得比宣传页还清楚。 一是 hooks，前面提过，服务端和本地安装路径都不支持；二是市场里的 tool 类能力，第一阶段只能本地跑完，服务端只会返回需要安装的状态和提示；三是 mcp 类能力不会自动开通连接，只会提示你去让管理员在云端 Connections 里加，或者本地自己装；四是结果缓存——packages/docs/start-here/do-work-with-it/what-uses-tokens.mdx 直说今天没有结果缓存，重跑同一个任务就是一次新的模型请求，成本随 Agent 需要读的上下文规模和工具调用次数一起涨。这些边界不是缺陷清单，而是让你别把它当成一个自动化执行引擎来用：它更像一个能力的目录与分发层，执行主体仍然是你现有的 Agent。

共享意味着修改要走流程。 发布是云端的管理员动作，不是桌面端的市场编辑器。文档说得明白：想改一个共享技能又不影响别人，得在你自己控制的市场里复制一份再改；改动轻的话，可以另写一个技能，让 Agent 先用标准技能，再叠加你的额外指令。这套约束对团队是好事，对喜欢随手改配置的个人开发者就是摩擦。

不适用的场景。 如果你只在一台机器上用一个 Agent，从来不共享配置，那这一整套抽象带来的收益接近于零，多出来的只是一个桌面应用和一层账号体系。如果你的合规要求禁止把服务授权托管给第三方，那 Cloud 路径直接出局，剩下的只有自托管，而自托管要面对的是整个 Den 侧的运维与许可证问题。

六、上手与避坑清单

每条都写「为什么会踩」和「怎么避」，因为只写「注意」没有用。

一、别把「MIT 开源」当作全仓结论就去做技术选型。 为什么会踩：GitHub 页面上的许可证徽章和大多数二手介绍只会显示一个值，而这个仓库的真实状态是分层的，团队控制面在 /ee 下走的是另一份许可。怎么避：评估前直接打开根目录 LICENSE 与 ee/LICENSE 两个文件，确认你要用的目录落在哪一层，把原文交给法务判断，别让工程师替法务下结论。

二、别以为搜到能力就等于它能执行。 为什么会踩：search_capabilities 的搜索面比 execute_capability 的执行面大，技能类返回的是文本载荷，tool 类返回的是需要安装的状态，hook 类压根不支持。怎么避：第一次接入后，先拿几个不同类型的能力实际执行一遍，看返回的是文本、是规格声明、还是一个状态提示，心里对「能跑」和「只是知识」建立分类，再决定要不要把它写进工作流。

三、别在没搞清授权范围前批量连服务。 为什么会踩：Connect 页面的交互成本极低，一路点下去很容易把邮件、日历、文档、聊天记录全放进同一个可被 Agent 调用的池子里。怎么避：按任务连接，一个任务需要什么才连什么；组织管理员这一侧还要区分是用共享账号还是每人各自的账号，这个选择直接决定了数据流向和事后追责能力。

四、别忽略「加入组织」这一步的副作用。 为什么会踩：登录组织通常被当成一次身份认证，但它同时会拉取并应用桌面策略。怎么避：加入组织前先问清楚对方开了哪些策略、能限制到什么粒度、能看到哪些使用信息；个人机器和公司机器上的 OpenWork 最好不要共用一个身份。

五、多 worktree 并行开发时别直接用默认 dev 流程。 为什么会踩：README 说单个检出继续用 pnpm dev 即可，但同时跑多个 git worktree 会撞上共享的开发档案、Electron 调试端口和 Vite 端口。怎么避：用 pnpm dev:worktree，它会把 OPENWORK_DEV_PROFILE 设为 auto 并从 worktree 路径推导出稳定的档案名，同时让端口自动选空闲值；README 还提醒它默认把 OPENWORK_ELECTRON_USE_MOCK_KEYCHAIN 置为 1，因为全新档案没有已存凭据，macOS 上真实钥匙串会在 Chromium 持久化认证 cookie 时弹窗，而那个模态框会卡住 Electron 主循环。启动时打印的横幅里有档案名和 CDP 地址，排查时先看它。

六、提 PR 前先看 AGENTS.md 而不是先写代码。 为什么会踩：这个项目对证据的要求高于常见开源项目，自制截图和录屏可以作为补充但不决定通过与否。怎么避：按它规定的技能顺序走，把主张落成 evals/specs 下的可执行断言；纯文档、纯类型、惰性配置类改动可以跳过运行时证明，但要在 PR 里说明这一点。

收束：三个文件决定你要不要继续投入

判断这个项目值不值得你花时间，不需要读完 3490 个文件，按顺序看三个就够。

先看根目录 LICENSE 与 ee/LICENSE，确认许可分层落在你的使用场景哪一侧——这一步不通过，后面都不用看。再看 docs/marketplace-capabilities-architecture.md 里那张按 objectType 分类的表，它决定了你期待的自动化到底有多少能真正落地、有多少只是把文本喂给你现有的 Agent。最后看 AGENTS.md，它告诉你这个项目的工程纪律和演进方式，也顺带告诉你，如果哪天你想改它，代价是什么。

再补一句自检：如果你现在的痛点是「同一套配置搬来搬去」，这个方向对得上；如果痛点是「Agent 执行得不够好」，那它帮不上——执行质量仍然由你选的模型和你写的技能决定，这部分工作一分都少不了。

这个系列的其余文章

这篇是总览。想往下挖，按下面两条线走：先把它配起来用，或者直接读代码。

上手与使用

结构与机制

全部文章也汇总在 OpenWork 开源专题。如果你要的不是「把一套能力共享出去」而是一个能在终端里直接改代码的编码 Agent，那是另一条路：opencode 是什么：终端里的开源 AI 编程 Agent 全景地图。