OpenWork 冲上 Trending：它想把 Agent 的能力从客户端里拆出来

OpenWork 这两天又出现在 GitHub Trending 里。北京时间 2026 年 8 月 14 日清晨观察时，仓库约有 22,032 个 stars，组织页显示当天仍有更新；8 月 12 日刚发布了 v0.18.23。单看桌面端 AI Agent，这个赛道已经很拥挤。OpenWork 更值得看的地方，是它试图把 Agent 的“能力”从某一个客户端里拿出来。

我想借这个项目讲清楚一个正在变得具体的问题：当你同时使用 Codex、Claude Code 和 Cursor 时，Skill、MCP、已授权的服务连接，到底应该跟着哪一个客户端走？期望对大家有所帮助。

不只是另一个桌面 Agent

OpenWork 的仓库把自己定义为 Claude Cowork 和 Codex 的开源替代品，提供 macOS、Windows 和 Linux 桌面应用。它建立在 OpenCode 之上，桌面程序仍然是用户可以直接打开的工作台。

但 README 的重点不只在桌面端。它明确提出：向 Codex、Claude Code、Cursor 或其他兼容 Agent 添加一个 OpenWork MCP，就能复用同一套 Skills、MCP 和连接过的服务。也就是说，桌面程序只是其中一个入口；能力的归属被放到了 OpenWork 这一层。

这和“给某个 Agent 装插件”是两件事。前一种关系是：客户端拥有插件，换客户端就要重新配置。后者更像一个能力目录：客户端负责发起任务，目录负责让已分配的能力被发现和调用。

Codex / Claude Code / Cursor
            │
            ▼
       OpenWork MCP
            │
  Skills · MCP · 已连接服务
            │
            ▼
      团队或个人的能力目录

在 OpenWork 的远程 MCP 里，公开的基本接口只有两个：search_capabilities 用来查找可用能力，execute_capability 用来运行选中的能力。这个取舍很有意思。它没有把每项服务的细节全部塞进每个 Agent 的配置，而是把“先发现，再调用”变成统一入口。仓库 README 还给出了 Codex、Claude Code 和 OpenCode 的接入方式。

为什么是现在

这不是一个刚创建的空仓库。OpenWork 组织页在本次观察时显示该项目约 22,032★、2,179 forks，项目累计有 4,341 次提交；其 dev 分支在 8 月初仍连续处理 MCP OAuth、自动化和发布流程相关改动。GitHub Trending 日榜 是本次发现它的短期动量信号，不应被理解成“22K stars 是一天新增”。

更直接的催化剂是新版本。最新的 v0.18.23 release 于 8 月 12 日发布，主要把公开版、云端版和企业版的构建产物与更新清单分开，并提供签名的 Windows 安装包。它不是一次新功能大爆发，却说明这个项目仍在把桌面、托管和企业交付同时打磨。

而当前的需求也已经变了。个人开发者会在一个终端 Agent 里写代码，在另一个客户端里做长任务；团队还需要共享连接、权限和 Skill。若每个入口都各自保存一份配置，迁移成本很快会超过工具本身带来的便利。OpenWork 的叙事正好踩在这里：让 Agent 可以替换，让能力配置尽量不必重建。

这条路线的边界

这种统一层不是自动带来安全性。它把更多连接集中起来，也意味着需要更清楚地确认三件事：谁能发现某项能力，谁能执行它，以及 OAuth 授权最后给了哪个服务、哪个组织。OpenWork 的 README 提到，接入远程 MCP 后会打开浏览器登录并选择组织；这一步不能跳过，也不适合把现有客户端里的密钥直接复制进去。

项目自身也仍处在快速演化中。仓库同时包含公开、云端和企业构建；许可文件说明 ee/ 目录使用 Fair Source License，其他未受限制部分采用 MIT。准备二次开发或部署到团队前，应当先看清 许可范围，不要把“开源桌面版”直接等同于整个仓库的所有部分都可按 MIT 使用。

如果你只是需要一个新的本地 Agent 客户端，先比较它是否真的比现有工具省事即可。但如果你的痛点是“同一套 Skill 和 MCP 在三四个 Agent 之间反复配置”，OpenWork 值得用一个非生产账号试一次：先接入一个只读服务，确认 search_capabilities 能找到的范围，再决定是否把更多连接和团队能力放进去。