开源桌面应用 OpenWork：工作流、设置共享、团队模板各自漏在哪
本文基于 openwork 仓库 commit 3b41381（2026-08-03）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/different-ai/openwork 最新代码与文档为准。
在 OpenWork 里，「把我调好的一套设置给同事」不是一个功能，而是三条互不相通的路径：会话工作流只作用于你本机的这个工作区，技能分发要走 Cloud 侧的组织市场，而完整的工作区起点要靠团队模板。 你如果只学了其中一块就去铺团队，一定会在某个地方卡住——最典型的是把技能整理得很漂亮，同事装完却发现模型接不上，因为凭据根本不在你能共享的那层里。
先做个消歧：本文说的 OpenWork 是 different-ai 维护的那个开源桌面应用项目，与同名的职场点评网站、以及「开放工作」这类泛指没有关系。仓库 README 这样定位自己：一个免费开源、为共享 AI 工作流而做的桌面应用，是 Claude Cowork 与 Codex 的开源替代，覆盖 macOS、Windows、Linux——这是项目自己的说法，本文只如实转述，不替它背书。
站内已有几篇邻近文章，分工不同：AI 工作流工具怎么选 讲的是选型阶段的横向判断，Agent 团队交付 讲的是交付流程本身怎么设计，AI 工具的团队治理 讲的是管理侧的制度与边界；本篇不做选型也不谈制度，只把 OpenWork 这一个具体项目里「共享」这件事的三块机制拆开，逐块对照仓库文件讲清它做到哪、漏在哪。
一、先分清这三块各自站在哪一层
这三块的差别不在功能大小，而在作用域和存放位置。工作流的状态存在你本机的工作区里；技能分发的状态存在组织市场里；团队模板的状态存在 Cloud 组织里，且只在导入那一刻落到你机器上。搞混作用域，就会做出「我改了为什么同事看不到」这类无解的期待。
| 组成部分 | 它负责什么 | 对应仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
| 会话工作流（分组、置顶、归档） | 把散乱的对话整理成可跟踪的流程状态 | packages/docs/start-here/do-work-with-it/workflows.mdx、apps/server/src/session-groups.ts | 一个人干活到第二周，会话列表开始翻不动的时候 |
| 分组事件同步 | 让多个窗口/视图看到同一份分组状态 | apps/app/src/react-app/shell/session-group-event-poller.ts | 你在一处改了分组，另一处没立刻更新的时候 |
| 扩展与技能查看 | 展示当前 agent 已经能用的技能与应用 | packages/docs/start-here/do-work-with-it/share-your-setup.mdx、apps/app/src/react-app/domains/settings/pages/extensions-view.tsx | 你想确认某个技能到底有没有生效 |
| 组织市场（技能发布） | 把技能/插件发给指定的人或团队 | packages/docs/start-here/do-work-with-it/publish-and-copy-a-skill.mdx、apps/app/src/react-app/domains/settings/pages/cloud-marketplaces-view.tsx | 你想让同事拿到你写的那套技能 |
| 团队模板 | 给一组人同一个已知可用的工作区起点 | packages/docs/cloud/share-with-your-team/team-templates.mdx | 新人入职、客户环境开新工作区 |
| 桌面策略与托管 provider | 组织侧控制桌面能力、统一发放模型接入 | packages/docs/cloud/share-with-your-team/desktop-policies.mdx、packages/docs/cloud/share-with-your-team/managed-llm-provider.mdx | 你发现某个设置被灰掉，或者模型是公司统一给的 |
顺带说清仓库的形状，方便你自己去核：全仓 3490 个受版本控制文件，apps/ 4 个、packages/ 12 个，企业侧的 ee/apps/ 10 个、ee/packages/ 3 个；文档在 packages/docs/ 共 57 份 mdx，其中 model-context-protocol/ 有 10 份接入不同客户端的指南；架构说明在 docs/ 20 份 md，evals/ 有 26 份流程 md；apps/server/src/ 顶层 138 个 .ts；packaging/ 提供三种分发方式。这些数字你自己数一遍就能对上，本文不引用任何 star 数、下载量或用户数。
二、工作流：它整理的是会话，不是任务
解决什么问题。 你用这类桌面 agent 干活，第一周还好，第二周会话列表就成了一堆无名对话，你根本记不起哪个是待评审、哪个已经上线了。workflows.mdx 给的答案不是引入一套项目管理，而是把会话本身当成可流转的对象。
它怎么做的。 文档写明，每个会话都能从会话菜单重命名、置顶、归档、手动排序，或者移进自定义的分组文件夹；分组文件夹是按工作区隔离的。文档举的例子是建 Research、Ready for review、Shipped、Bugs 这样的组，随着工作推进把会话挪进去。团队场景里，文档给的组是 Triage、In progress、Needs human review、Done。
比 UI 操作更该留意的是第二种用法：你可以直接在输入框里描述规则。文档里的原例是「When this is done, rename the session to “Auth cleanup”, move it to Ready for review, and pin it」，以及「If this turns into a bug investigation, put it in Bugs; otherwise archive it when finished.」这些自然语言会落到 OpenWork 的会话管理原语上——重命名改标题，移入分组写一条会话到分组的归属，置顶把重要会话固定在上面，归档只隐藏不删除，手动排序则用来贴合你已有的流程。文档明确说，这样做的目的是让会话组织变成动态的，而不是手工记账。
实现层面能看到什么。 apps/server/src/session-groups.ts 里，分组状态由两部分组成：一个分组定义列表（每项含 id 与 label），加上一份从会话到分组的归属映射。变更以事件形式发出，事件类型是 session_groups.updated，动作枚举包括创建、更新、删除、归属指派、重排序和导入。状态本身走的是工作区级的键值存储，也就是说它跟着工作区走，不跟着你的账号走。
同步方式是轮询而非推送：apps/app/src/react-app/shell/session-group-event-poller.ts 按工作区各存一个游标，每次带 since 拉增量；一旦服务端回包标记了断档或重置，或者拉回来的序号不连续，它就把游标清零重新对齐。这个设计很朴素，代价也直白——分组变化不是瞬时的，短暂的不一致是预期内的。
这对你意味着什么。 工作流这块解决的是「我一个人的会话怎么不乱」，它天生不跨人。你把 Ready for review 这组建得再合理，同事那边也不会自动出现同名的组；分组归属是本机工作区里的一条记录，不是团队看板。想让全组用同一套流程状态词，得靠约定，或者靠模板把起点铺一次。
三、设置共享：入口改了，能力也改了
解决什么问题。 早期很多人对「共享设置」的想象是：有个页面，勾几个技能，生成一个包发给同事。share-your-setup.mdx 一上来就否掉了这个想象——OpenWork 不再从 Workspace > Skills 页面共享技能了，桌面应用现在的角色是展示你的 agent 已经能用什么。
它怎么做的。 桌面侧的动作只剩查看与确认：打开 Settings > Extensions，用 Skills 过滤器或搜索找到来自工作区和组织的技能，点进去用 View details 读描述。这里有个权限差别值得记住：本地技能可以被显示出来或移除，而通过 OpenWork Connect 来的技能是只读的。如果管理员刚发布了市场或者刚改了你的访问权限，你需要点 Refresh。
真正的发布动作在 Cloud 侧。publish-and-copy-a-skill.mdx 说得很直接：发布是 OpenWork Cloud 里的管理员动作，不是桌面端的市场编辑器。管理员在 Cloud 控制台用 New marketplace 和 Create marketplace 建组织市场，插件发布到这个市场后，有访问权限的同事就能看到其中的技能；访问范围可以是全组织、指定团队或指定成员。桌面应用只展示分配给你的市场内容，它不创建也不 fork 市场。
改别人的技能怎么办？文档给了两条路：一是在你自己控制的市场里做一份副本再改，这样不影响别人；二是对于小改动，另写一个技能，让 agent 先用标准技能，再叠加你的额外指令。
这对你意味着什么。 技能分发这条路是组织化的，不是点对点的。你没有 Cloud 组织和管理员权限时，「把我的技能给他」这个动作在产品里没有对应入口。另外这块只覆盖技能与插件，它不带模型接入、不带 MCP 连接配置、不带你在工作区里做的其它设置——skills-plugins-and-mcp.mdx 把三个构件分得很清楚：连接器负责触达系统，技能是做法说明，插件是打包单元，而这三者的分发通道并不相同。
四、团队模板：一次性起点，不是持续同步
解决什么问题。 前两块合起来仍然填不上一个洞：新人入职时，他缺的不是某个技能，而是整套起点。team-templates.mdx 的定位就是这个——当一组人应该从同样的起点开始，而不是一台一台桌面重建时，用团队模板。
它怎么做的。 文档列的模板内容包括技能、MCP 配置、命令、agent 与 provider 设置。推荐流程是五步：先在桌面应用里把工作区搭好，把该有的技能、MCP 服务器、命令、agent 和 provider 加进去，把这套设置分享到你的 OpenWork Cloud 组织，把模板分配给对应团队，然后让同事从 Settings -> Cloud 导入。
文档还划了使用边界：只需要分发技能或 MCP 时，用市场插件（桌面端路径 Settings -> Extensions -> Marketplace）而不是模板；只需要共享模型接入时，用托管 provider。模板留给重复的团队搭建、客户 onboarding 和内部作业系统这类场景。
维护建议里有一条是硬要求：别把密钥放进模板。共享的模型凭据应该放在 Cloud 的 provider 里，而不是配置文件里；多个模板需要同一批技能时，把技能收进市场插件；不同团队、不同客户环境用不同模板。文档最后一句话概括得很准确——团队模板就应该是无聊的：一个已知可用的起点，分配给需要的人，加入时导入到桌面应用。
这对你意味着什么。 「一次性起点」这五个字要认真读。模板给的是导入那一刻的快照，它不承担持续同步的职责；持续生效的那部分被拆到了别的机制里：技能靠市场，模型接入靠托管 provider 的导入与 Sync，组织侧的能力开关靠桌面策略。managed-llm-provider.mdx 里能看到托管 provider 的落地方式——导入时 OpenWork 会把 provider 写进工作区的 opencode.jsonc，并为该工作区保存组织凭据；Cloud 里改了模型或访问范围要用 Sync，不想再托管就 Remove，Cloud 侧删掉后桌面会显示已从云端移除并让你卸载本地配置。而且，provider 必须先有已保存的组织凭据，桌面才能导入。
五、边界与代价：这套设计放弃了什么
这类工具会在你机器上装桌面应用、代管模型凭据、持有第三方服务授权，还可能连到团队控制面。下面几条是必须提前算清的账。
授权范围与身份归属。 shared-mcp-connections.mdx 里，组织共享的 MCP 连接有两种账号模式：个人账号模式下每人以自己身份登录，这是 OAuth 服务器现在的默认值，agent 以「你」的身份行事，服务商自己的权限规则照常生效；组织账号模式下管理员登录一次（机器人、服务账号或 API key），所有被授权成员的 AI 都以这一个身份行事。第二种模式的代价很明确：服务商侧的审计日志里只会看到那一个身份，出了事你分不清是谁触发的。
凭据的存放位置。 同一份文档写得很直白：你的登录态存在 OpenWork Cloud，而不是这台机器上，所以连一次、每台设备都算连上了。这是便利，也是集中化的暴露面——凭据集中在一处，被拿到的后果也集中在一处。托管 provider 那条路同理，组织凭据由 Cloud 保管并下发到工作区。这方面的通用做法可以参考 API 密钥的安全管理 与 MCP 授权加固，本文不展开。
企业侧能看到什么、能关什么。 desktop-policies.mdx 列出的策略键直接对应桌面能力：自定义 provider、内置 OpenCode 模型的开关、是否允许多工作区、能否修改桌面设置、能否管理本地扩展、内置扩展（含浏览器、图像、本地 provider 类扩展）、以及欢迎页是否显示。被策略关掉的内置扩展会从常规目录里隐藏，并在隐藏视图里标注为组织已禁用。策略是缓存的，重载时生效，并在切换活跃组织、更换 Cloud 账号或每小时的桌面配置刷新时更新——也就是说管理员改完，你这边不一定立刻变。团队提示卡还叠了一层：team-prompt-cards.mdx 写明桌面策略的管理本身要求组织具备对应的企业级权益，组织没有权益时接口直接返回 402；布尔类策略是多策略叠加、任一为真即生效，而提示卡不叠加，只取优先级最高的那份，同优先级时先看创建时间再看策略 id。另外默认策略只能作用于全组织、不能单独指派给成员或团队，要分人群就得另建非默认策略。具体的权益划分与计费规则本文不展开，以官方最新说明为准。
许可证是分层的，这条最容易写错。 仓库根目录的 LICENSE 写得很清楚：/ee 目录下的全部内容按 ee/LICENSE 定义的许可证（根 LICENSE 称其为 Fair Source License，而 ee/LICENSE 文件自身的抬头是 Functional Source License, Version 1.1, MIT Future License，缩写 FSL-1.1-MIT），第三方组件按各自原始许可证，只有这两类之外的部分才是 MIT（Copyright 2026 Different AI）。而上面讲的团队控制面能力，Cloud 控制台整体就落在 ee/apps/den-web/ 下：组织市场是 marketplaces-screen.tsx、托管 provider 是 llm-providers-screen.tsx、桌面策略是 desktop-policies-screen.tsx，三者同在 ee/apps/den-web/app/(den)/dashboard/_components/ 目录里；团队模板同样是 Cloud 侧的管理动作，走的是同一个控制台。所以「OpenWork 是 MIT 开源的」这句话说得不完整，凡涉及这些团队能力都要带出分层这一点。至于能不能商用、能不能改，本文不提供法律意见，一律以许可证原文为准。
它明确不管的事。 会话工作流不管跨人同步；技能市场不管模型接入与 MCP 连接；团队模板不管导入之后的持续更新；跨会话记忆也有明确边界——cross-chat-memory.mdx 说它目前来自保存的会话历史，不是独立的长期记忆库，也不会把旧会话自动注入每个新提示，而且还不是对每条消息的语义检索。这些都是文档里自己写清的限制，不是猜的。
六、上手与避坑清单
先建分组再干活，而不是等列表爆了再补。 会踩是因为分组归属是一条条会话记录，事后补要你逐个回忆当时的状态，成本远高于当时顺手一句。避法：开工前按 workflows.mdx 的例子先建 4 个组，然后在输入框里把流转规则说清楚，让完成时自动改名并移组。
别指望改完分组另一处立刻同步。 会踩是因为同步靠按工作区游标的轮询增量，服务端标记断档或序号不连续时会清零重来。避法：看到不一致先等一轮再刷新，不要反复手工重排，重排本身也是会发事件的动作，只会让你更难判断状态。
别去找那个已经不存在的共享页面。 会踩是因为很多教程和记忆停留在 Workspace > Skills 时代。避法：桌面端只在 Settings > Extensions 里查看和确认，用 Skills 过滤器定位，管理员刚改过权限就点 Refresh；要发出去，回 Cloud 建组织市场。
别直接改团队共享的技能。 会踩是因为共享技能的改动会波及所有拿到它的人，而通过 OpenWork Connect 来的那部分本来就是只读的。避法：按文档给的两条路走，要么复制到自己控制的市场再改，要么另写一个技能，让 agent 先执行标准技能再叠加你的补充。
别把密钥塞进模板。 会踩是因为模板是给一群人导入的，任何写死在配置里的凭据等于按人数复制了一份泄漏面。避法：模板只放结构性的东西，共享的模型凭据一律走 Cloud 的 provider；导入前先确认那个 provider 已经存好了组织凭据，否则桌面端根本导不进来。
别用一个模板覆盖所有团队和客户。 会踩是因为模板是一次性起点，你为了兼容所有人往里堆东西，结果每个人导入后都要删一半。避法：按团队、按客户环境拆开，宁可多几个无聊的模板。
组织账号模式要单独评估。 会踩是因为它默认让所有人的 agent 用同一个身份行事，权限和审计都被抹平了。避法：只在确实需要「大家都以同一个服务账号操作」时才选它，其余场景保持个人账号模式——那也是 OAuth 服务器的默认值。
收个尾
一句话总结这三块的分工：工作流让你一个人的会话有秩序，市场让技能能发出去，模板让新人有起点；缺了任何一块，「把我调好的设置给同事」都只能完成一半。
给自己过一遍这份自检：你要共享的东西里，有没有密钥？有没有必须持续更新、因而不该放模板的部分？团队用的是个人账号还是组织账号身份？你依赖的能力落在 ee/ 下吗？如果落在 ee/ 下，你看过 ee/LICENSE 的原文了吗？
接下来该读哪几个文件也很清楚：想搞清共享 MCP 的身份与回调，读 packages/docs/cloud/share-with-your-team/shared-mcp-connections.mdx；想搞清组织能关掉你哪些桌面能力，读 packages/docs/cloud/share-with-your-team/desktop-policies.mdx；想搞清技能、连接器、插件的分工，读 packages/docs/start-here/do-work-with-it/skills-plugins-and-mcp.mdx。仓库里那份 packages/docs/roadmap.mdx 也在，但那只是文档里的规划陈述，不构成对未来行为的承诺，别拿它当依据做决策。
本篇属于一个把开源AI 工作流桌面应用 OpenWork逐层拆开讲的系列，整体地图见 OpenWork 是什么：把技能与 MCP 打包成能力的开源桌面应用；沿着这条线往下，还可以看 开源桌面应用 OpenWork：什么在烧 token，账单怎么长出来 和 OpenWork 开源桌面应用连不上：先走网络自查线，再用诊断提示词。