OpenWork：开源可审计的本地AI代理桌面应用，重塑Claude Work体验

体验过 Claude Work（Anthropic 推出的 AI 工作助手）的人，大多会被它流畅的交互所折服：无需在终端中死记硬背命令，也不必从成堆的脚本输出里大海捞针——你只要选定工作区、输入任务，然后安静地看着 AI 一步步完成；遇到需要确认的敏感操作时，点击授权即可。整个过程更像是在使用一款精心设计的产品，而非一堆拼凑起来的工具链。

图片

然而，它的局限性也同样突出：Claude Work 所提供的，本质上是一个优雅却封闭的“云端闭源产品体验”。当你开始考虑数据掌控权、操作可追溯性、能力可扩展性这类工程化需求时，就会发现很难将其无缝嵌入团队的现有体系。

这正是 OpenWork 存在的价值。

OpenWork 是一款开源的“类 Claude Work”桌面应用：底层由 OpenCode 驱动，上层则提供清晰的引导式界面，把“选取工作区 → 启动任务 → 实时查看进度/计划 → 处理权限 → 复用模板/技能”这一完整链路包装成可交付的产品。它让代理式工作（agentic work）变得更像一个可控、可复用、可持续运转的工作系统，而不是终端里一次性的试验。

Image

01 为何需要 Claude Work 的替代方案？

Claude Work 的确强大，但这份强大更多体现在精巧的产品形态与生态闭环上。对于个人试用来说的确足够舒服，可一旦涉及安全合规、工程管理或者深度定制需求，其短板立刻暴露：

1）闭源带来的不确定性

封闭的代码库让你几乎无法：

  • 自行审计数据如何流转、如何存储
  • 自定义工作流和能力边界
  • 按照团队规范进行二次开发和集成

2）高度依赖云端

当任务执行、历史记录、数据存储全部集中在云端时，很多隐忧自然浮现：

  • 合规压力（特别是涉及企业代码、客户资料、敏感文档）
  • 网络稳定性与持续成本
  • 供应商锁定（流程、数据、使用习惯全部绑定在一款产品上）

3）扩展性受产品策略制约

你想添加“技能”——比如接入公司内部接口、封装一套固定工作流，或者安装一个 OpenCode 插件时，闭源产品往往要么不开放、要么只提供有限的支持，最终你只能“凑合着用”。

如果你更看重本地运行、操作可审计、自由扩展，那么 OpenWork 所瞄准的方向，正好填补了这些需求。

02 OpenWork 是什么？

OpenWork 是一款可扩展的开源桌面应用，带有 Claude Work 风格的工作流： 它在桌面端将 OpenCode 的能力精心组织为清晰的任务流——选择 workspace，启动 run，实时查看执行情况与计划变动，必要时处理权限请求，最后把高频操作沉淀为模板和技能。

Image

项目对自身的定位也十分清晰：让“代理式工作”像产品一样可用，而非像终端那样晦涩。

03 核心特性

3.1 双运行模式：Host / Client

Image

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>

Image

同时它也支持 OpenCode 插件管理：通过读写 opencode.json 来维护插件列表，并区分两类配置：

  • 项目级：<workspace>/opencode.json
  • 全局级：~/.config/opencode/opencode.json（或 $XDG_CONFIG_HOME/opencode/opencode.json）

这足以说明：OpenWork 不仅是一个“壳”，它在认真地并生态能力整合进产品层。

04 安装与使用

你有两种上手途径：

Image

方式 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 即可。

这类版本说明的意义在于：项目在持续把“依赖环境”的问题往产品侧收敛，减少新手卡在安装配置阶段的可能性。

方式 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 UI

05 架构简述

从 README 的 Architecture（high-level）部分可以提炼出关键链路：

  • 在 Host mode 下，OpenWork 会启动：opencode serve --hostname 127.0.0.1 --port <free-port>，并将你选择的项目文件夹作为进程工作目录（cwd）。

  • UI 通过 @opencode-ai/sdk/v2/client：

    • 连接到 OpenCode server
    • 管理 sessions
    • 发送 prompts
    • 订阅 SSE events
    • 读取 todos 和权限请求

此外，桌面端的文件夹选择器由 Tauri dialog plugin 提供，权限声明在：packages/desktop/src-tauri/capabilities/default.json 中定义。

整体来看，它把“模型与工具能力”放在 OpenCode 层，而把“交互、权限、复用、审计体验”放在 OpenWork 层——层次分明，也便于未来的扩展。

06 什么时候它最能发挥价值？

在以下场景里，你会明显感受到 OpenWork 的增益：

  1. 你欣赏 Claude Work 的体验，但更追求开源与可控
  • 不想把工作流锁在闭源产品里
  • 希望自己把握数据与能力边界
  1. 你需要“可审计”的 AI 代理
  • 不只是“能做事”，还要“能解释清楚发生了什么”
  • 权限请求是关键的安全机制
  1. 你希望把流程沉淀为模板和技能
  • 高频工作可以模板化
  • 团队可以共享技能与插件配置（Client mode + 远端 OpenCode 更合适）

总结

OpenWork 的核心价值，是把“AI 代理工作”从终端命令式的原始体验，转化为产品化的流畅操作：引导式 UI 降低了入门门槛，权限控制 保障了操作安全，模板 + 技能 让工作流变得可复用、可扩展。

  • 适合谁：需要本地运行、可控 AI 代理的个人开发者或团队；认可 Claude Work 理念却不想被闭源锁定的用户。
  • 怎么开始：先用 Host 模式在本地跑通，熟悉会话管理和权限流程；然后尝试保存模板、安装技能，把工作流固化下来。

GitHub 地址：https://github.com/different-ai/openwork