OpenWork开源 AI 工作流共享平台深度笔记对应仓库different-ai/openwork| MIT 协议 | 跨平台macOS/Windows/Linux核心观点OpenWork 的真正野心不是做一个「Claude Cowork 的免费替代品」那么简单——它试图解决的是AI 工具的团队落地问题当开发者已经在用 Claude Code / Codex / Cursor 飞速工作时他们的运营、市场、客服同事依然两眼茫然。OpenWork 想用「技能Skills MCP 统一接入层」把这道鸿沟填平。这件事目前处于早期工程化阶段不是范式突破而是一次务实的整合把 MCPModel Context Protocol标准、开源代理运行时opencode、团队权限管理这三件事拧在一起做成可自托管的桌面应用和控制面板。关键机制一个 MCP跑通所有代理OpenWork 最核心、最巧妙的设计是不要求你换工具只要求你多挂一个 MCP。# 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 的横向比较维度OpenWorkClaude CoworkCodex开源/自托管✅ MIT❌ 闭源❌ 闭源Skills 可复用技能✅✅有限❌团队权限管理✅ Den 控制面板有限有限Slack/Telegram 原生支持✅❌❌多 Agent 并行执行❌单 Agent 工具❌❌Windows/Linux 稳定性⚠️ Alpha✅✅文档成熟度⚠️ 建设中✅✅最关键的牺牲是OpenWork 选择了广兼容性和开放性但目前仍是单 Agent 模型不具备真正的多 Agent 并行执行能力。如果你的场景需要几十个 Agent 同时跑eigent 之类的方案更合适。本地开发配置说明对于想参与贡献或私有化部署的开发者有几个关键点# 单 worktree 开发 pnpm dev # 多 worktree 并行每个 worktree 自动派生独立 profile 端口 pnpm dev:worktree # 也可以手动指定 profile 名 OPENWORK_DEV_PROFILEmy-feature \ OPENWORK_ELECTRON_REMOTE_DEBUG_PORT0 \ PORT0 \ pnpm dev关于 macOS keychain 的隐患要特别注意新 profile 无存储凭据时Chromium 持久化 cookie 会触发系统 keychain 弹窗这个弹窗会阻塞 Electron 主线程。多 worktree 开发时建议始终带上OPENWORK_ELECTRON_USE_MOCK_KEYCHAIN1用 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 StarMIT 协议无需注册即可本地运行。该文对 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
OpenWork开源 AI 工作流共享平台深度笔记对应仓库different-ai/openwork| MIT 协议 | 跨平台macOS/Windows/Linux核心观点OpenWork 的真正野心不是做一个「Claude Cowork 的免费替代品」那么简单——它试图解决的是AI 工具的团队落地问题当开发者已经在用 Claude Code / Codex / Cursor 飞速工作时他们的运营、市场、客服同事依然两眼茫然。OpenWork 想用「技能Skills MCP 统一接入层」把这道鸿沟填平。这件事目前处于早期工程化阶段不是范式突破而是一次务实的整合把 MCPModel Context Protocol标准、开源代理运行时opencode、团队权限管理这三件事拧在一起做成可自托管的桌面应用和控制面板。关键机制一个 MCP跑通所有代理OpenWork 最核心、最巧妙的设计是不要求你换工具只要求你多挂一个 MCP。# 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 的横向比较维度OpenWorkClaude CoworkCodex开源/自托管✅ MIT❌ 闭源❌ 闭源Skills 可复用技能✅✅有限❌团队权限管理✅ Den 控制面板有限有限Slack/Telegram 原生支持✅❌❌多 Agent 并行执行❌单 Agent 工具❌❌Windows/Linux 稳定性⚠️ Alpha✅✅文档成熟度⚠️ 建设中✅✅最关键的牺牲是OpenWork 选择了广兼容性和开放性但目前仍是单 Agent 模型不具备真正的多 Agent 并行执行能力。如果你的场景需要几十个 Agent 同时跑eigent 之类的方案更合适。本地开发配置说明对于想参与贡献或私有化部署的开发者有几个关键点# 单 worktree 开发 pnpm dev # 多 worktree 并行每个 worktree 自动派生独立 profile 端口 pnpm dev:worktree # 也可以手动指定 profile 名 OPENWORK_DEV_PROFILEmy-feature \ OPENWORK_ELECTRON_REMOTE_DEBUG_PORT0 \ PORT0 \ pnpm dev关于 macOS keychain 的隐患要特别注意新 profile 无存储凭据时Chromium 持久化 cookie 会触发系统 keychain 弹窗这个弹窗会阻塞 Electron 主线程。多 worktree 开发时建议始终带上OPENWORK_ELECTRON_USE_MOCK_KEYCHAIN1用 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 StarMIT 协议无需注册即可本地运行。该文对 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
