AI编程工具在团队中日益普及，极大提升了开发效率。然而，随之而来的问题也不容忽视：团队成员有的使用Claude Code，有的偏好Cursor，还有的采用Codex CLI。每个人都在本地配置了独立的MCP、API Key和自定义Skill，导致遇到问题时彼此难以协作，新人入职也需要从头配置一遍，重复劳动严重。
近期，开源项目OpenWork引起了广泛关注。它由different-ai团队使用TypeScript开发，已在GitHub上收获20k Star。该项目定位为Claude Code的开源替代，但更吸引人的是它致力于解决的核心痛点：让团队中不同的AI工具共享同一套技能和连接服务。
我们深入研究了其设计思路，下面来详细解读这一方案。
一、它解决什么问题
如今AI编程工具种类繁多，但存在一个令人困扰的问题：技能、MCP、连接服务都被锁定在单个客户端中。
例如，你在Claude Code里配置了一个强大的代码审查Skill，同事用Cursor却完全无法使用。你在Codex中接入了一个内部API的MCP，换一台机器就得重新配置。当团队规模扩大，每个人都在重复造轮子，效率低下。
OpenWork的做法是：构建一个共享的AI工作流中枢。你只需在中枢中配置一次Skill、MCP、连接服务，然后通过一个远程MCP暴露给所有兼容的Agent客户端。
OpenWork 中枢
├── Skills（技能库）
├── MCP 连接
├── Google Workspace / Microsoft 365
└── 插件市场
│
┌────┬────┼────┬────────┐
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Codex Claude Cursor 其他 MCP 客户端
二、核心设计：一个MCP，打通所有客户端
OpenWork最巧妙的地方，在于采用MCP协议作为统一接口。
它在云端或本地运行一个OpenWork MCP服务器，然后让Codex、Claude Code、Cursor等客户端都连接到这个MCP。客户端只需知道两个工具：
search_capabilities：查询当前用户可用的能力
execute_capability：执行选中的能力
# Codex 添加远程MCP
codex mcp add openwork --url https://api.openworklabs.com/mcp/agent
# Claude Code 添加远程MCP
claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent
# OpenCode 配置远程MCP
# 在 opencode.json 里加一段远程 MCP 配置
连接完成后，你在任一客户端中都能调用OpenWork中枢里配置好的技能，无需为每个客户端单独配置。
三、OpenWork Den：团队级管理控制台
如果仅用于个人，OpenWork与本地MCP服务器差别不大。它的团队价值体现在OpenWork Den这个管理控制台上：
Den中可以实现的功能：
- 成员管理：邀请队友、创建团队，轻松管理协作成员
- 权限控制：精细设定谁能使用哪个模型provider、哪个MCP、哪个Skill
- 桌面策略：限制本地模型访问，控制可使用的应用版本
- 插件市场：发布团队内部的Skill和插件，促进知识共享
- 模型供应：集中配置推理provider，统一管控API Key，提升安全性
这一设计对企业来说意义重大：以往API Key散落在每个人本地，现在可以集中管理、按团队分配，大幅降低管理成本。
四、桌面应用 + 任意Agent
OpenWork提供了一款Electron桌面应用，可独立工作。但它的设计理念是“桌面应用optional”——你可以不使用桌面应用，直接从现有Agent中调用OpenWork的能力。
桌面端的主要价值：
- 可视化管理工作空间，直观查看所有配置
- 浏览和安装Skill，快速扩展能力
- 管理MCP连接，统一维护
- OAuth登录时自动打开浏览器完成认证，简化流程
后台引擎采用OpenCode CLI，因此OpenWork本质上是对OpenCode的企业级封装，增强了团队协作与管控能力。
五、能做什么实际工作
OpenWork本身不直接提供“文档智能摘要”或“跨文件检索”等功能，但它可以通过Skill和MCP接入这些能力。例如：
- 接入文档处理MCP，实现长文档智能摘要
- 接入代码图谱MCP，实现跨文件代码检索与分析
- 接入Google Workspace / Microsoft 365，处理邮件和日历操作
- 接入内部API，实现业务自动化流程
它提供的是一个统一的接入和分发层，具体能力来自你配置的Skill和MCP。内置也支持导入Anthropic兼容的插件，自动转化为OpenWork的Skill和MCP，这对已经使用Claude生态的团队非常友好。
六、部署方式
个人快速体验
git clone https://github.com/different-ai/openwork.git
cd openwork
pnpm install
pnpm dev
团队部署
OpenWork支持两种模式：
- Host Mode：在本地或服务器启动完整服务，适合个人或团队共享服务器
- Client Mode：连接到远程OpenWork服务器，适合团队协作
对于企业，通常建议自行部署OpenWork Den + 远程MCP服务器，让团队成员通过Client Mode连接。这样可以确保数据不经过OpenWork官方的SaaS服务，满足数据合规与私有化部署需求。
七、适用场景分析
适合谁：
- 团队中同时使用多种AI工具（Codex / Claude Code / Cursor / OpenCode），需统一管理
- 希望统一管理团队Skill、MCP、API Key，降低配置混乱
- 对数据合规有要求，倾向私有化部署
- 想让非技术同事也能通过OAuth轻松接入MCP，降低使用门槛
不适合谁：
- 个人开发者单兵作战，无需团队协作
- 团队全员使用同一IDE（如全部使用Cursor），无跨工具需求
- 不想维护额外基础设施的小团队，资源有限
- 主要需求是工作流自动化，而非工具配置共享
实际价值：
OpenWork真正具有启发性的地方，在于将“AI工具配置”视为一种团队资产。Skill、MCP、连接服务不再是每个人本地的一堆零散文件，而是可以发布、版本化、分配权限的共享能力。
这在10人以上的团队中价值显著。想象一下：安全审计通过的MCP、经过测试的代码审查Skill、对接好的内部API，全部在Den中发布，新同事入职自动获得——这比每次手把手教学效率高得多，也减少了出错的概率。
结语
OpenWork并非又一个AI Chat客户端，而是一个企业级AI能力分发平台。它解决的问题不是“让AI做什么”，而是“让团队的AI工具如何共享同一套能力”。
随着AI编程工具越来越多、团队工具越来越杂，这种“配置即资产”的思路，将变得愈发重要。对于追求高效协作与统一管理的团队而言，OpenWork提供了一条值得探索的路径。
