OpenWork：开源 AI 工作流共享平台深度笔记

对应仓库：different-ai/openwork | MIT 协议 | 跨平台（macOS/Windows/Linux）

核心观点

OpenWork 的真正野心不是做一个「Claude Cowork 的免费替代品」那么简单------它试图解决的是AI 工具的团队落地问题：当开发者已经在用 Claude Code / Codex / Cursor 飞速工作时，他们的运营、市场、客服同事依然两眼茫然。OpenWork 想用「技能（Skills）+ MCP 统一接入层」把这道鸿沟填平。

这件事目前处于早期工程化阶段，不是范式突破，而是一次务实的整合：把 MCP（Model Context Protocol）标准、开源代理运行时（opencode）、团队权限管理这三件事拧在一起，做成可自托管的桌面应用和控制面板。

关键机制：一个 MCP，跑通所有代理

OpenWork 最核心、最巧妙的设计是：不要求你换工具，只要求你多挂一个 MCP。

bash 复制代码

# Claude Code 接入只需一行
claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent

# Codex 同理
codex mcp add openwork --url https://api.openworklabs.com/mcp/agent

挂载后，MCP 对外只暴露两个工具：

search_capabilities --- 查"我能做什么"
execute_capability --- 执行某个封装好的技能

这个设计的本质是能力注册表（Capability Registry）：管理员在 OpenWork Den（控制平面）里配置好技能、权限、MCP 连接，之后无论员工用什么代理客户端，接入同一个 MCP 端点就能调用，配置不重复、权限统一管理。这比每人自己配 20 个 MCP 服务器要理性得多。

相比之下，Claude Cowork 的技能能力是其差异化卖点之一，但它是闭源的、绑定 Anthropic 生态的。OpenWork 把同样的思路开放出来，支持导入 Anthropic 兼容插件，并兼容任意 MCP 客户端。

与 Claude Cowork / Codex 的横向比较

维度	OpenWork	Claude Cowork	Codex
开源/自托管	✅ MIT	❌ 闭源	❌ 闭源
Skills 可复用技能	✅	✅（有限）	❌
团队权限管理	✅ Den 控制面板	有限	有限
Slack/Telegram 原生支持	✅	❌	❌
多 Agent 并行执行	❌（单 Agent + 工具）	❌	❌
Windows/Linux 稳定性	⚠️ Alpha	✅	✅
文档成熟度	⚠️ 建设中	✅	✅

最关键的牺牲是：OpenWork 选择了广兼容性和开放性，但目前仍是单 Agent 模型，不具备真正的多 Agent 并行执行能力。如果你的场景需要几十个 Agent 同时跑，eigent 之类的方案更合适。

本地开发配置说明

对于想参与贡献或私有化部署的开发者，有几个关键点：

bash 复制代码

# 单 worktree 开发
pnpm dev

# 多 worktree 并行（每个 worktree 自动派生独立 profile + 端口）
pnpm dev:worktree

# 也可以手动指定 profile 名
OPENWORK_DEV_PROFILE=my-feature \
  OPENWORK_ELECTRON_REMOTE_DEBUG_PORT=0 \
  PORT=0 \
  pnpm dev

关于 macOS keychain 的隐患要特别注意：新 profile 无存储凭据时，Chromium 持久化 cookie 会触发系统 keychain 弹窗，这个弹窗会阻塞 Electron 主线程 。多 worktree 开发时建议始终带上 OPENWORK_ELECTRON_USE_MOCK_KEYCHAIN=1，用 mock keychain 避免卡死。

交叉验证

信源一：eigent.ai《2026年最佳开源 Claude Cowork 替代方案》（不同作者/不同媒体，竞品视角）

这篇文章将 OpenWork 列为五大替代方案之一，对其技能系统和 Slack 集成给予正面评价，但指出其多 Agent 能力缺失，并认为对企业级生产环境而言，eigent 更成熟。这与原文 README 隐含的「团队协作」定位基本一致，但补充了一个原文没有明说的边界：OpenWork 适合结构化、重复性的单 Agent 工作流，不适合需要并行调度多个 Agent 的复杂任务。

信源二：腾讯云开发者社区《别总盯着 Claude Cowork 了，OpenWork 开源版来了》（中文技术媒体，实践视角）

该文提供了更多落地细节，特别指出：Windows 和 Linux 版本仍处于 Alpha 阶段，稳定性存疑；文档建设不完善；国内用户面临 Slack 集成不可用的问题（飞书/企微尚无支持）。同时确认了原文的核心优势：10.7K GitHub Star，MIT 协议，无需注册即可本地运行。该文对 OpenWork「AI 工具民主化」的定位与原文一致，但更坦诚地指出了对非英语地区用户的摩擦。

综合判断：原文 README 偏向功能展示，对不成熟部分（如 Windows/Linux Alpha 状态、文档缺失）几乎没有主动提及。两个外部信源在核心定位上与原文一致，但对局限性的描述更为诚实，读者应结合参考。

个人启发

对个人开发者：如果你已经在用 Claude Code 或 Codex，接入 OpenWork MCP 的成本极低（一行命令），获得的是「技能复用」能力------你写一次的工作流可以分享给队友或在另一台机器上直接跑，值得尝试。
对团队 Leader / 决策者：OpenWork Den 的核心价值是「统一配置，分发给人」。如果你的团队里有不少非技术成员但又需要接入 AI 能力，可以考虑用 Den 集中管理 MCP 和技能，避免每人各自配置的混乱局面。但请先在 macOS 上小范围试点，Windows/Linux 版本目前不适合生产环境。
对国内用户：Slack 集成是主推的团队协作入口，而国内 Slack 几乎不可用。在飞书/企微支持到来之前，这个产品对国内团队的实用性打了相当大的折扣，建议观望到 v1.0 正式版。

延伸思考

MCP 会成为「AI 工具层」的 HTTP 吗？ OpenWork 整个架构押注于 MCP 作为 Agent 能力的标准接口。如果 MCP 真的成为行业标准（OpenAI、Google 也开始支持），那么 OpenWork Den 这类「MCP 能力注册中心」的价值会急剧放大；反之如果标准碎片化，整个架构就需要重做。
「技能封装」是解决 AI 工具门槛问题的正确抽象吗？ 技能（Skills）本质上是带权限控制的 Prompt + 工具链组合。但 AI 的强大之处恰恰在于它能处理非结构化任务------过度封装成固定技能，是否反而限制了灵活性？这是一个值得持续观察的设计张力。
开源商业模式的可持续性：MIT 协议 + 免费桌面应用 + 收费 Den 控制平面（推测），这是一个典型的开源 SaaS 模式。随着用户规模增长，如何在「不锁定用户」和「获得商业回报」之间保持平衡，将是 different-ai 团队面临的核心挑战，也是判断该项目长期可投入程度的关键变量。

📚 参考来源

GitHub - different-ai/openwork: The open-source alternative to Claude Cowork (powered by opencode) · GitHub