用过 Claude Work （Anthropic 的 AI 工作助手）的人，大多会对它的体验印象深刻：你不需要在终端里拼命记命令，也不必在一堆脚本输出里找线索------只要 选个工作区 、下达任务 ，看着 AI 一步步执行；遇到敏感操作再 点一下授权。整个过程更像在使用一个"产品"，而不是"工具链"。
但问题也很明显：Claude Work 代表的是一种漂亮的"云端闭源产品体验"。当你开始关心 数据可控 、过程可审计 、能力可扩展 时，你会发现自己很难把它真正纳入团队的工程体系。
这就是 OpenWork 出现的意义。
OpenWork 是一个开源的 "Claude Work 风格" 桌面应用 ：底层跑 OpenCode，上层提供干净的引导式 UI，把"选工作区 → 启动任务 → 看进度/计划 → 处理权限 → 复用模板/技能"这套流程产品化，让 agentic work 更像一个可控、可用、可复用的工作系统，而不是终端里的一次性实验。
01 为什么需要 Claude Work 平替？
Claude Work 很强，但它的"强"更多来自产品形态与生态闭环。对个人试用当然舒服；但对有安全要求、工程要求、或需要深度定制的用户，缺点同样显眼：
1）闭源带来的不确定性
闭源意味着你很难做到：
- 自己审计数据如何流转、如何存储
- 自定义工作流与能力边界
- 按团队规范二次开发与集成
2）强依赖云端
当任务执行、历史记录、数据存储都发生在云端时，你会天然担心：
- 合规（尤其是企业内部代码、客户数据、敏感文档）
- 网络稳定性与成本
- 供应商锁定（流程、数据、使用习惯都绑定在一个产品上）
3）扩展性被产品策略限制
你想加"技能"（比如接入你公司的内部接口、封装一套固定工作流、或安装一个 OpenCode 插件）时，闭源产品通常要么不开放，要么开放程度有限，最终你只能"将就着用"。
如果你更看重 本地运行 、可审计 、可扩展，那么 OpenWork 的方向正好对上需求。
02 OpenWork 是什么？
OpenWork 是一个可扩展、开源的 Claude Work 风格桌面应用： 它在桌面端把 OpenCode 的能力组织成清晰的工作流------选择 workspace，启动 run，实时查看执行与计划更新，需要时处理权限请求，并把高频流程沉淀为模板与技能。
项目自我定位也很明确：让"代理式工作"像产品一样可用，而不是像终端一样可用。
03 核心特性
3.1 两种运行模式：Host / Client
Host mode（本地宿主模式）
- OpenWork 会在本机启动 OpenCode 服务
- 默认绑定
127.0.0.1（本地回环地址），更利于安全隔离 - 适合个人使用、离线环境、或对数据出境敏感的场景
Client mode（客户端模式）
- OpenWork 通过 URL 连接一个已有的 OpenCode 服务器
- 适合团队统一部署 OpenCode（集中算力/统一配置/统一模型），客户端只负责 UI 与交互
一句话：Host 模式偏"本地可控"，Client 模式偏"团队协作与集中管理"。
3.2 会话（Sessions）与实时流（Live streaming）
OpenWork 支持：
- 创建/选择会话（session）
- 发送 prompts 执行任务
- 通过 SSE /event 订阅实时接收运行事件（进度、计划更新等）
这点非常关键：很多 CLI 工具也能跑 agent，但体验差的根本原因在于"过程不可读"。OpenWork 把"过程"用 UI 呈现出来，降低了使用成本，也更利于复盘。
同时它还会把 OpenCode 的 todos 渲染成一个 时间线式执行计划（Execution plan / timeline）。对使用者来说，这相当于：
- 你不只是看到结果
- 还能看到"它准备怎么做、做到哪一步、下一步是什么"
3.3 权限控制（Permissions）：把"安全阀"做成产品能力
代理式工具最大风险来自"它能帮你做很多事"。一旦代理具备脚本执行、文件删除、网络访问等能力，你必须有一个可靠的"人类确认机制"。
OpenWork 的权限交互是明确的：
- 当出现敏感动作时，会在 UI 弹出权限请求
- 你可以选择：允许一次 / 始终允许 / 拒绝
- 同时强调 可审计：展示发生了什么、何时发生、为什么发生
这类权限设计的价值在于： 它不是"事后看日志"，而是把风险控制前置到工作流里，让代理真正可在生产环境被信任地使用。
3.4 模板（Templates）与技能（Skills）：让工作流可复用、可迁移
Templates（模板）
- 把常用流程保存下来，之后一键复用
- 模板存储在本地（README 明确提到 stored locally）
- 适合把"写周报、生成会议纪要、代码审计清单、PRD 评审流程"等固定流程产品化
**Skills manager（技能管理）**OpenWork 会管理 .opencode/skill 目录下的技能，并支持：
- 列出已安装技能
- 从 OpenPackage 安装技能（
opkg install ...） - 导入本地技能文件夹到
.opencode/skill/<skill-name>
同时它也支持 OpenCode 插件管理：通过读取/写入 opencode.json 来维护插件列表，并支持：
- 项目级：
<workspace>/opencode.json - 全局级：
~/.config/opencode/opencode.json（或$XDG_CONFIG_HOME/opencode/opencode.json）
这意味着：OpenWork 不只是"壳"，它在认真把生态能力整合进产品层。
04 安装与使用
你有两种方式开始：
方式 A：直接下载安装包（更适合大多数人）
OpenWork 在 GitHub Releases 提供安装包（README 也指向该链接）：https://github.com/different-ai/openwork/releases 。
最新版本为 OpenWork v0.2.9（2026-01-21）。同时 v0.2.8 的说明提到一个很实用的修复：
- Host mode 在未安装 OpenCode 的机器上也能工作 ：通过从应用可执行文件目录正确解析并使用"捆绑的 OpenCode sidecar"（不再只在
Contents/Resources里找，而是从Contents/MacOS/opencode解析）。 - 如果仍遇到 "OpenCode CLI not found"，更新后重启 OpenWork。
这类 release note 的意义是：项目在持续把"依赖问题"往产品侧收敛，减少新手卡在环境上。
方式 B：从源码运行（适合想参与开发/二次定制）
根据 README，环境依赖包括：
- Node.js +
pnpm - Rust toolchain（Tauri）：
cargo、rustc - OpenCode CLI：
opencode（需在 PATH 中；不过如上所述，某些版本的 Host mode 也可使用 bundled sidecar）
快速启动命令：
pnpm install
pnpm dev # 启动桌面应用
pnpm dev:web # 只启动 Web UI05 架构简述
从 README 的 Architecture（high-level）可以提炼出关键链路：
- 在 Host mode 下，OpenWork 会 spawn：
opencode serve --hostname 127.0.0.1 --port <free-port>并把你选择的项目文件夹作为进程工作目录（cwd）。 - UI 通过
@opencode-ai/sdk/v2/client：- 连接 OpenCode server
- 管理 sessions
- 发送 prompts
- 订阅 SSE events
- 读取 todos 与权限请求
此外，桌面端的 folder picker 由 Tauri dialog plugin 提供，能力权限在：packages/desktop/src-tauri/capabilities/default.json 定义。
整体看，它把"模型与工具能力"放在 OpenCode 层，把"交互、权限、复用、审计体验"放在 OpenWork 层------分层清晰，也便于后续扩展。
总结
OpenWork 的核心价值是把"AI 代理工作"从终端命令变成产品体验：引导式 UI 降低使用门槛，权限控制 保障安全，模板 + 技能 让工作流可复用可扩展。
- 适合谁：需要本地/可控 AI 代理的个人开发者或团队；喜欢 Claude Work 但不想被闭源锁定的人。
- 怎么开始：先用 Host 模式在本地跑通，熟悉会话管理和权限流程；再尝试保存模板、安装技能，把工作流固化下来。
GitHub 地址：https://github.com/different-ai/openwork