OpenWork 开源桌面应用的团队控制面到底管什么、边界在哪
本文基于 openwork 仓库 commit 3b41381（2026-08-03）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/different-ai/openwork 最新代码与文档为准。
你在 OpenWork 这个开源桌面应用里看到的团队能力——发技能、拉人、配模型、锁桌面设置——没有一样是跑在桌面端的，它们全部住在仓库的 ee/ 目录里，而这个目录不适用 MIT 许可证。 把 OpenWork 当成”MIT 开源、随便自建”来规划，第一次做技术选型评审就会翻车：你 clone 下来的东西确实包含控制面的源码，但它的使用条款和仓库其余部分不是同一份。
先说清楚命名，OpenWork 在这里指 different-ai 维护的这个开源桌面应用项目，不是同名的职场点评网站，也不是”开放工作”这类泛指的说法。仓库根目录的 README 是这样定位自己的：一个用来共享 AI 工作流的免费开源桌面应用，并把自己描述为 Claude Cowork 和 Codex 的开源替代方案，覆盖 macOS、Windows、Linux——这是项目方自己的说法，不是本文的判断。
一、这层先解决的问题：单机能力没法交接
单机用 Agent 时，技能文件、MCP 服务器配置、第三方服务授权都散在你自己那台机器上。换一台机器要重配一遍，同事想用你调好的那套流程只能靠口口相传。团队想统一”哪些模型可以用""哪些工具不许接”，也没有任何执行点。
OpenWork 给出的答案分成两半。桌面端仍然是本地优先的运行环境，README 里明确说桌面应用不是必需的——你可以只往 Codex、Claude Code、Cursor 这类客户端里加一个 OpenWork 的远程 MCP，它对外暴露两个工具，search_capabilities 用来找可用能力，execute_capability 用来执行；加完之后客户端会开浏览器让你登录并选择所属组织。另一半就是本文的主角：一个叫 Den 的控制面，README 里的原话是”OpenWork Den is the control plane for managing OpenWork across a team or organization”。
站内已经有几篇讲团队侧的文章，分工不一样：AI 工具的团队治理 讲的是管理制度怎么设计，Agent 团队交付 讲的是多人协作交付流程，AI 转型 KPI 讲的是怎么衡量收益；本篇不碰这三件事，只拆一个具体开源项目的控制面是怎么落在代码仓库里的、以及自建时的边界在哪。
二、控制面由哪几块组成
整个仓库有 3490 个受版本控制的文件，apps/ 下 4 个应用、packages/ 下 12 个包，这部分是 MIT 那一侧；ee/apps/ 下 10 个应用、ee/packages/ 下 3 个包，这部分走另一份许可证。下面这张表只列我实际打开确认过的位置。
| 组成部分 | 它负责什么 | 对应仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
| Den API | 文档里被称作控制面的逻辑核心，承担认证、组织、管理与 worker 相关端点 | ee/apps/den-api（包名 @openwork-ee/den-api） | 自建时它是必须跑起来的那个服务 |
| Den Web | 管理后台与云端 Web 应用，Next.js 结构，带 proxy.ts | ee/apps/den-web（包名 @openwork-ee/den-web） | 你在浏览器里点的所有管理动作都在这 |
| Den 数据层 | 控制面的数据库访问层 | ee/packages/den-db | 迁移、加密列、备份策略都绕不开它 |
| 网关 | 独立的服务进程，源码只有 app.ts / server.ts / env.ts / load-env.ts 四个入口文件 | ee/apps/den-gateway | 部署拓扑要画到它 |
| 云端工作区 | 托管运行时与其代理，运行时目录里有 Dockerfile.daytona-snapshot | ee/apps/den-worker-runtime、ee/apps/den-worker-proxy | 用共享工作区、把任务放到云上跑时 |
| 推理接入 | 组织级模型接入相关的服务 | ee/apps/inference | 统一配模型、控制哪些团队能用哪家 |
| 管理分析 MCP | package.json 自述为只读的管理分析 MCP 服务器，读 Den 数据库 | ee/packages/den-admin-mcp | 运营侧想用 Agent 查数据时 |
| 云端文档 | 控制面的全部使用说明 | packages/docs/cloud/ | 动手前应该先读完的一叠 |
有一个坑值得单独点名：ee/apps/den-controller 这个目录还在，但它的 README 第一行就写着 Deprecated，说明它已经被 ee/apps/den-api 取代（den-api 的前身就是 den-controller），目录留着只是为了让旧链接能落到一份清楚的迁移说明上。你要是照着老文章或老 issue 去找 den-controller 的实现，会找到一个空壳。
文档侧的规模也值得一提：packages/docs/ 下有 57 份 mdx，其中 model-context-protocol/ 目录有 10 份客户端接入指南；架构说明在 docs/ 下有 20 份 md，evals/ 下有 26 份流程 md。桌面与服务端那侧，apps/server/src/ 光顶层就有 138 个 .ts 文件，packaging/ 提供三种分发方式。想读源码，先按这个规模估工时。
三、发能力、管成员、配模型三条主线
发能力走的是一条固定链路。按团队快速上手文档的说法，技能是 Agent 在任务匹配时加载的分步指令，技能装在插件（plugin）里，插件通过市场（marketplace）分发。管理端的动作顺序是：先在 Extensions → Marketplaces 里建一个市场，再到 Extensions → Plugins 里创建插件、加技能（填 Name、Description、Instructions），在 Share 区域挂到市场上；然后打开市场的 Members 页，把访问权授予整个组织、某几个团队或具体的人。管理闭环就是”插件 → 市场 → 团队”，后加入的人自动继承对应扩展。桌面端不需要手动安装，文档里展示的状态是市场自动同步、插件显示为 Active · runs in cloud。插件也可以从 GitHub 导入，包括 Anthropic 兼容的插件仓库，还能用 Sources 让市场跟某个仓库保持同步。
管成员分成两个正交的维度：组织成员身份和团队归属。默认角色三个——Owner 拥有完整组织控制权，Admin 能邀人、管团队、管大部分共享云端资源，Member 只能用别人分享给他的东西。只有 Owner 能改成员角色、移除成员、增删自定义角色，也只有 Owner 能改组织设置（包括允许的邮箱域名和桌面限制）。团队本身不是权限层级，它是资源授权的分组单位，用来决定谁能看到哪个市场、哪个模型供应商。接了 SSO 的组织要特别注意一条：即时开通（just-in-time provisioning）在首次登录时一律给基线 Member 角色，身份提供商侧的 role、groups、admin 这类属性不会被拿来授予组织角色——想提权只能在 OpenWork 里显式改，然后走审计。需要职责分离时，用自定义角色里的 security_configuration.manage 权限把 SSO、SCIM、组织 API key 的管理从日常 Admin 里拆出去。
配模型是把凭据的保管位置换了个地方。管理端在 LLM Providers 里 Add Provider，选目录里的供应商、勾选要暴露的模型、粘贴共享的 API key、设定 People access 与 Team access。桌面端在 Settings -> Cloud 选好 Active org 之后，在 Cloud providers 处点 Import，OpenWork 会把导入的供应商写进工作区的 opencode.jsonc，并为该工作区存下组织凭据。之后模型或访问规则改了就点 Sync，不想被托管了就 Remove；云端删掉的供应商在桌面端显示 Removed from cloud，可以 Uninstall 本地配置。前提是这个供应商在云端已经存过组织凭据，否则桌面端根本导不进来。
还有一条容易被忽略的主线：桌面策略。它能开关的是具体产品能力，文档列出的键包括 Custom providers（本地自行添加、未经云端下发的模型供应商）、Enable OpenCode Zen Models、Multiple workspaces、Control Settings、Manage Extensions、Built-in Extensions、Welcome Page。策略可以是组织默认策略，也可以按成员或团队下发；桌面端会缓存生效策略，在重载时应用，并在活跃组织变化、云端账号变化或每小时的桌面配置刷新时更新。被策略挡掉的能力，桌面端会以”由组织控制”的口径解释，例如被禁的内置扩展会从正常目录里隐藏，在隐藏视图里显示 Disabled by organization。
桌面端和控制面之间只认一个地址。文档写得很直白：桌面应用只用一个 Cloud URL，也就是 Den Web 的 baseUrl，托管默认值是 https://app.openworklabs.com；所有云端 API 与 MCP 流量都从这一个地址派生，API 请求走 <baseUrl>/api/den/v1/...，MCP 请求走 <baseUrl>/api/den/mcp/...。桌面端不单独存一个 API 地址，启动时从 desktop-bootstrap.json 读 Cloud URL，文件缺失就回落到默认值；你在 Settings -> Cloud 改了地址，它会把新的 baseUrl 写回引导文件。登录如果浏览器没能自动跳回应用，可以用 Paste sign-in code，把 openwork://den-auth?... 这个链接或一次性验证码贴回去。
四、非 MIT 的那半边：许可证分层怎么读
仓库根目录的 LICENSE 把话说得很清楚：/ee 目录下的所有内容按 ee/LICENSE 定义的 Fair Source 许可证；第三方组件按各自原始许可证；除此以外的内容才是 MIT（Copyright 2026 Different AI）。所以”OpenWork 是 MIT 开源项目”这句话只对了一半——你要用的控制面恰好落在另一半里。
ee/LICENSE 的抬头是 Functional Source License, Version 1.1, MIT Future License，缩写 FSL-1.1-MIT，署名 Copyright 2026 Different AI Inc。它的授权结构是”许可宽、用途受限”：允许你使用、复制、修改、创作衍生作品、公开展示与再分发，但只限于 Permitted Purpose；Permitted Purpose 的定义是排除法，即除 Competing Use 之外的任何用途，而 Competing Use 指把这个软件放进商业产品或服务里，去替代它本身、替代授权方基于该软件提供的既有产品或服务、或提供相同及实质相似的功能。许可证同时点名了几类明确属于允许范围的用法：内部使用与访问、非商业教育、非商业研究，以及在你向合规使用该软件的被许可方提供专业服务的场景中使用。文本里另有专利条款、再分发时必须附带条款与保留版权声明的要求、商标限制，以及一条 Grant of Future License——在该版本软件发布满两周年之日起，追加一份 MIT 许可。
本文不提供法律意见。你的具体场景能不能商用、能不能改、算不算 Competing Use，一律以许可证原文为准，必要时走内部法务。工程侧要记住的只有一条操作性结论：/ee 与仓库其余部分要分开评估，别用一句”开源项目”打包过关。
五、边界与代价：它明确不管的事
第一，凭据的暴露面被主动扩大了。共享 MCP 连接文档里的原话是，你的登录态存在 OpenWork Cloud 而不是本机，连一次、所有设备都连上了。这确实解决了多机重复授权的问题，代价是第三方服务的授权凭据集中保管在控制面。连接有两种账号模式：Individual accounts 表示每个人以自己的身份登录，Agent 以”你”的身份行事，服务商自己的权限与审计生效；One org account 表示管理员用一个机器人账号或 API key 登录一次，所有被授权成员的 Agent 都以那个身份行事。第二种模式下，服务商侧的审计日志会把所有人的动作记成同一个主体，出了事很难定位到人。选之前先想清楚这条。
第二，管理员能看到和能改的东西不小。组织所有者与管理员可以下发桌面策略，关掉你本地添加供应商、关掉多工作区、关掉改设置、关掉本地扩展管理。这不是”提示”，是桌面端加载后就生效的能力开关。企业侧这么用没问题，但如果你是拿它当个人工具、只是顺手加入了公司组织，要意识到你的桌面能力从此由别人的策略决定。
第三，控制面是有状态的中心，不是无关紧要的旁路。安全与运维文档明说：OpenWork 是本地优先的，但 Cloud 补上了共享身份、成员、RBAC、托管 worker、共享供应商和组织策略，应当把 Cloud 当作团队访问与共享运行状态的控制面。这句话反过来读就是——控制面挂了，跟团队相关的这些东西一起挂。托管版的做法是把 Cloud 应用和 Den API 跑成有健康检查的多实例、共享状态放外部托管数据库，自建时这些高可用的活儿由你自己扛。
第四，自建这条路仓库里并没有铺成一键式。企业页给的路径是让你去联系项目方，谈的是目标环境（云厂商、VPC、本地机房）、身份访问与审计要求、模型与工具的允许清单、上线计划与支持方式。安全文档里能看到自建相关的具体线索——比如敏感数据库列用应用层 AES-256-GCM 加密，密钥来自 DEN_DB_ENCRYPTION_KEY；比如无外网出口的私有部署可以用 DEN_PASSWORD_BREACH_SCREENING_ENABLED=false 关掉泄露密码筛查，Helm chart 对隔离安装默认就是关的——但整体上，文档反复把 TLS 证书、数据库存储加密、备份加密、私有网络策略的责任划给部署方。
第五，它明确不管的事：不替你做数据分类，不替你决定哪些内容可以进 Agent 的上下文，不管你所在行业的合规要求，也不管服务商侧的账单与配额。这些具体规则本身也会调整，以官方最新说明为准。
六、上手与避坑清单
误把整个仓库当 MIT。 会踩是因为 GitHub 页面上的许可证标识和根目录 LICENSE 的第一屏都容易被扫成 MIT，而分层说明在正文靠下的位置。避法：把 ee/LICENSE 单独存一份给决策人看，评估表里 /ee 单列一行。
照着旧资料去找 den-controller。 会踩是因为目录还在、名字还很像控制面。避法：进任何 ee/apps/ 子目录先看 README 第一行，den-controller 的 README 开头就写了 Deprecated 并指向 ee/apps/den-api。
以为桌面端可以单独配一个 API 地址。 会踩是因为多数系统都是 Web 地址和 API 地址分开配的。避法：记住桌面端只认一个 Cloud URL，其余路径由它派生；改地址走 Settings -> Cloud，改完它会写回 desktop-bootstrap.json。
共享连接默认按组织账号建。 会踩是因为管理员建连接时按”统一管理”的直觉会选 One org account，而这会让所有成员的 Agent 共用一个身份。避法：先确认这个服务在服务商侧有没有按人区分权限与审计的需求，有就选 Individual accounts，这也是 OAuth 服务器的默认值。
导入模型供应商前没在云端存凭据。 会踩是因为桌面端的 Import 按钮看起来随时可点。避法：先在云端把供应商的凭据存好，再回桌面端导入，导入后按提示重载工作区；改了模型清单或访问范围记得回来点 Sync，否则桌面端还是旧的。
改完策略以为立刻生效。 会踩是因为桌面端缓存了生效策略。避法：让成员重载、刷新云端账号或切换活跃组织，实在不想动就等每小时的桌面配置刷新。
把提权寄托在身份提供商的属性上。 会踩是因为很多系统支持从 IdP 的 group 映射角色。避法：这里不映射，首次登录一律是 Member，提权当作显式的访问变更来做并复核审计事件；需要分离职责就用 security_configuration.manage。
特权操作被拒绝时以为是权限配错了。 会踩是因为报错和权限不足很像。避法：服务端要求改 SSO、SCIM、API key、组织设置、自定义角色、成员角色、计费、推理设置这类路由时，会话必须是新近建立的，会话太旧就得重新登录再来一次。
想沿着这条线继续往下读，还有几篇能接上：MCP 授权加固 讲授权环节本身怎么收紧，最小权限设计 讲能力授予的粒度怎么定，配合本篇看凭据集中保管之后的轮换与回收会更完整。
最后给一份自检清单，动手前逐条打勾：这次要用的能力，实现是在 /ee 里还是在 MIT 那一侧；如果在 /ee，用途属不属于许可证里写的 Permitted Purpose，这一条以许可证原文为准；共享 MCP 连接选的是个人账号还是组织账号，服务商侧的审计能不能追到人；模型凭据是集中托管还是各人自持，泄露之后的轮换路径是什么；桌面策略由谁下发、成员知不知情；自建的话，控制面的高可用、数据库加密、备份与恢复分别由谁负责。要接着读文件，顺序建议是根目录 LICENSE → ee/LICENSE → packages/docs/cloud/security-and-operations.mdx → ee/apps/den-api，前两份决定你能不能用，后两份决定你要付多少运维成本。
本篇属于一个把开源AI 工作流桌面应用 OpenWork逐层拆开讲的系列，整体地图见 OpenWork 是什么：把技能与 MCP 打包成能力的开源桌面应用；沿着这条线往下，还可以看 OpenWork 开源桌面应用的扩展清单：字段构成、服务端加载与四份内置示范 和 开源桌面应用 OpenWork 的角色与权限模型：谁能发能力、谁能指派、谁只能用。