开源桌面应用 OpenWork：什么在烧 token，账单怎么长出来

本文基于 openwork 仓库 commit 3b41381（2026-08-03）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/different-ai/openwork 最新代码与文档为准。

在 OpenWork 里，配置动作本身不产生模型消耗，真正开始烧 token 的只有一件事：某个成员把一个任务跑起来。 这句话不是我的推断，是仓库 packages/docs/start-here/do-work-with-it/what-uses-tokens.mdx 第一句的意思——OpenWork 在成员真正执行工作时才使用模型 token，设置类操作本身不消耗。听上去像废话，但它决定了你排查账单时该往哪儿看：不是去数管理员配了多少东西，而是去数谁在跑什么、跑的时候读了多少上下文、调了多少次工具。

先做个命名消歧：本文说的 OpenWork 是 different-ai 开源的那个桌面应用项目（仓库地址 https://github.com/different-ai/openwork ），它把技能、MCP 连接与外部服务打包成可共享的「能力」，跟同名的职场点评网站、以及中文里泛指的「开放工作」没有关系。下文出现 OpenWork 一律指这个项目。

本站已经有几篇讲成本的文章，分工是这样的：token 用量统计怎么做 讲的是你自己搭一套计量口径，token 成本优化 讲的是通用的省钱手法，Agent 成本失控 讲的是失控后的排查路径；这一篇不重复那些，只干一件事——把 OpenWork 这个具体项目的计费触发点和团队托管模型那条线对着读，看账单在它的产品结构里是怎么长出来的。

一、先把「什么时候开始花钱」这条线画清楚

那份文档把消耗起点写得很细，值得逐条对照你自己的用法。

发一条提示词会运行所选模型并消耗 token，这条没有悬念。稍微反直觉的是第二条：运行一个技能同样消耗，因为技能会被加载进任务里，模型按它的指令执行。也就是说技能不是免费的宏，它是一段被塞进上下文的说明书，你写得越长，每次触发它的任务就越贵。

第三条是目前最该记住的现实：文档明确写了「今天没有结果缓存」，重跑同一个任务会发出新的模型请求。你如果习惯了某些平台的响应复用，在这里不能指望。想省钱只能靠不重复跑，或者把跑对的那条路径固化下来。

第四条讲的是上下文规模：消耗随 agent 需要读的内容增长，长会话记录、粘贴进来的文本、附件、工具返回结果都算在内。第五条讲工具调用——调用次数多的任务通常更贵，因为 agent 要读每次的返回再决定下一步。这两条合起来是同一件事：真正的成本大头不是你敲的那句话，而是这句话引出的读取量。

反过来，文档也点名了哪些东西不花钱：提示卡放在策略里不产生任何费用，管理员配多少张都一样；安装技能、发布市场插件也都不花钱，直到某个成员跑了一个用到它们的任务。最后一条给了正向出路——一个写得好的技能能降低成本，因为它让重复工作更短、更确定，探索性的工具调用更少。

控制开销那半页给的五条建议也是同一逻辑的延伸：提示卡写短写具体；重复流程优先用聚焦的技能；只挂任务真正需要的文件和会话上下文；先要窄输出再做宽分析；盯住那些在多个工具之间打转的任务，然后把跑通的那条路径变成技能。

二、把成本拆到组件上：谁负责什么，你在哪碰到它

OpenWork 的文档把 agent 的构件分成三件：连接器负责接到系统，技能是写好的做法，插件是打包在一起的那个单位（见 packages/docs/start-here/do-work-with-it/skills-plugins-and-mcp.mdx）。文档里还有一句挺关键的说明：底层其实都是插件，你让 OpenWork 创建一个技能时，它会建一个只包含那个技能的小插件，所以「到底该做技能还是插件」这个问题多数人不需要纠结。

把这些构件和成本、和团队控制面对上号，大致是下面这张表。

组成部分	它负责什么	对应仓库位置	你什么时候会碰到它
token 消耗说明	说清哪些动作触发模型请求、哪些不触发，以及当前没有结果缓存	packages/docs/start-here/do-work-with-it/what-uses-tokens.mdx	账单对不上、想找计费起点时
连接器 / 技能 / 插件	连接器接系统，技能是写好的做法，插件把相关技能打成一个可分发单位	packages/docs/start-here/do-work-with-it/skills-plugins-and-mcp.mdx	决定把重复流程沉淀成什么形态时
组织托管模型 provider	组织侧存一次凭据、模型清单与访问规则，桌面端各工作区导入	packages/docs/cloud/share-with-your-team/managed-llm-provider.mdx	团队要统一模型入口、不想每人配一遍 key 时
桌面策略	控制成员桌面端能不能加本地 provider、能不能用内置模型、能不能管扩展等	packages/docs/cloud/share-with-your-team/desktop-policies.mdx	组织要收紧成员能用哪些模型和扩展时
组织提示卡	在桌面 composer 里给出建议提示，点击只填充不自动发送	packages/docs/cloud/share-with-your-team/team-prompt-cards.mdx	想统一团队的起手式，同时不希望它自己烧钱时
本地自定义模型	走 OpenCode 的配置文件加自建网关或本地模型	packages/docs/start-here/connect-your-stack/add-a-custom-llm.mdx	想把流量导到自建网关或本机模型时
许可分层	/ee 目录按 ee/LICENSE，其余部分 MIT	仓库根 LICENSE 与 ee/LICENSE	评估能不能自托管、能不能改造时

跨会话记忆那份文档（packages/docs/start-here/do-work-with-it/cross-chat-memory.mdx）也值得放进成本视角看一眼：它写明当前的跨会话记忆来自保存的会话历史，不是独立的长期记忆库，也不会自动把每段旧对话注入每个新提示。agent 是通过 session.list_sessions、session.open、session.read_transcript、session.latest_message 这几个语义化界面动作去查历史的。这意味着「翻旧账」是一次显式的读取行为，读多少就花多少，而不是一笔隐性的固定开销——但也意味着你随口一句「看看上次那个会话说了啥」，可能触发列会话、开会话、读记录一串工具调用。

三、团队托管模型：省掉的是配置，换来的是凭据集中

packages/docs/cloud/share-with-your-team/managed-llm-provider.mdx 描述的流程很短，但每一步都对应一次权责转移。

组织侧的动作是：在 LLM Providers 里点 Add Provider，留在 Catalog provider，选好 provider 和要暴露给组织的模型，粘贴共享的 API key / credential，再选 People access 或 Team access，最后 Create Provider。桌面侧的动作是：打开 Settings -> Cloud，选对 Active org，在 Cloud providers 下点 Import，按提示重载工作区。文档写明，OpenWork 会把导入的 provider 写进工作区的 opencode.jsonc，并为该工作区保存组织凭据。后续维护也给了三个动作：改完模型或访问范围后用 Sync；不想再受管就用 Remove；如果 provider 在 Cloud 侧被删掉了，桌面端会显示 Removed from cloud 并允许 Uninstall 掉本地配置。还有一条前置条件——provider 必须先有已保存的组织凭据，桌面端才能导入。

从工程角度读这条线，得失很清楚。得到的是：模型清单、访问范围、凭据只维护一处，成员换机器、换工作区不必重配；组织想收窄某个模型的暴露面，改一次 Cloud 配置再 Sync 即可。付出的是：共享凭据被集中保管，并且会以工作区为单位落到每个成员的机器上。你在做这个决定时要同时回答两个问题——这把 key 的调用量归属怎么区分，以及一台被拿下的成员机器意味着多大暴露面。文档只说 OpenWork 为该工作区保存组织凭据，没说这层保管的具体形态，别自己脑补。

配合桌面策略看会更完整。desktop-policies.mdx 列出的策略键里有 Custom providers（允许或阻止本地新增的、非经 Cloud 部署的模型 provider）、Enable OpenCode Zen Models（允许或阻止内置模型）、Multiple workspaces、Control Settings、Manage Extensions、Built-in Extensions、Welcome Page。也就是说，组织不只是「提供一个统一入口」，它可以把其它入口关掉。team-prompt-cards.mdx 那份还补了几条容易踩的合并细节：布尔型策略开关在多条匹配策略之间取并集，任何一条为 true 就生效；提示卡则不合并，桌面端只用优先级最高的那条匹配策略的提示集，同优先级看创建时间再看策略 id；成员通过 GET /v1/me/desktop-config 拿到变更，桌面端先加载缓存配置，在 Cloud 会话或设置变化时刷新，并按小时轮询——所以改完策略看不到效果，先重载或切一下活跃组织再说。还有一条产品边界写在同一份文档里：管理桌面策略需要组织具备相应权益，不具备时接口会直接拒绝而不是静默降级；具体的权益规则以官方最新说明为准。

四、边界与代价：这套设计明确不管什么

第一，它不做结果缓存。文档原话就是今天没有结果缓存，重跑就是新请求。你要的幂等、去重、命中复用，得自己在外面做，这也是 缓存与幂等设计 那类工作依然要做的原因。

第二，它不替你做用量归属。仓库这两份文档讲的是「什么会消耗」和「凭据放哪」，没有讲把消耗按人、按团队、按任务切开的口径。共享凭据尤其要留意——组织统一 key 的便利，代价就是账单混在一起。想要人均视图，你得自建计量层，或者在模型网关侧解决。

第三，托管 provider 的代价是集中化本身。凭据集中保管意味着暴露面集中；桌面端导入意味着配置会落到每台成员机器的工作区里。组织侧能看到什么、成员侧能自主到什么程度，是通过策略开关拿捏的，而不是天然对等。

第四，许可分层这件事必须说清楚，不能笼统写成「MIT 开源」。仓库根 LICENSE 写明：/ee 目录下的全部内容按 ee/LICENSE 定义的 Fair Source 许可证；第三方组件按各自原始许可证；以上范围之外的内容才是 MIT（Copyright 2026 Different AI）。而 ee/LICENSE 文件的抬头是 Functional Source License, Version 1.1, MIT Future License（缩写 FSL-1.1-MIT），Copyright 2026 Different AI Inc。团队控制面与企业侧能力大量落在 ee/ 下面——ee/apps/ 有 10 个应用、ee/packages/ 有 3 个包——所以你评估「能不能商用、能不能改」的时候，落点是这两份许可证原文，本文不提供法律意见，一律以许可证原文为准。

第五，它不是一个纯本地的东西。packages/docs/cloud/security-and-operations.mdx 自己就写了：OpenWork 是 local-first 的，但 Cloud 增加了共享身份、成员、RBAC、托管 worker、共享 provider 和组织策略，应当把 Cloud 当作团队访问与共享运行态的控制面。这句话是这个项目对自己的定位，值得原样理解——一旦接了 Cloud，你的模型入口、成员权限、桌面能力开关就都在那条线上了。README 里项目把自己定位成 Claude Cowork 和 Codex 的开源替代品，那是仓库 README 的说法，不是本文替它下的判断。

五、上手与避坑清单

技能写太长，然后到处触发。 会踩是因为技能读起来像文档，写的时候容易一路铺开；但技能会被加载进任务，每次触发都按上下文计费。避法是把技能当接口写而不是当手册写：只留决策要用到的规则和字段，背景解释放到别处，别让每次执行都为你的注释付钱。

指望重跑会命中缓存。 会踩是因为很多人默认「同样的输入应该便宜」，但文档明说当前没有结果缓存。避法是把重跑当作全价新请求来预算，需要复用就在外层自己存结果。

任务里挂了一堆用不上的附件和历史。 会踩是因为附件挂着不碍事、会话开着不觉得贵，而消耗恰恰随 agent 要读的内容涨。避法是开新会话做新任务，附件只挂当前这一步需要的，先要窄输出再要宽分析。

让 agent 满世界翻旧会话。 会踩是因为那几个查历史的界面动作用起来太顺口。避法是给足线索——会话 ID、标题、工作区、人名或项目名——文档自己也写了，线索清楚才能一次命中；另外它可能会短暂跳去别的会话，你得让它回来。

改完组织策略，成员那边没反应就以为坏了。 会踩是因为桌面端先用缓存配置，靠 Cloud 会话/设置变化和每小时轮询刷新。避法是改完让成员重载、切一下活跃组织，或者干脆等那轮刷新，别急着回滚配置。

多条策略叠加后行为不符合预期。 会踩是因为布尔开关取并集、任何一条为真就生效，而提示卡走的是另一套规则——只用优先级最高的那条匹配策略的提示集。避法是分清这两类键的合并语义，别用「再加一条策略去关掉某个能力」的思路，那对布尔开关是无效的。

托管 provider 导进去之后就不管了。 会踩是因为导入是一次性动作，但 Cloud 侧的模型清单和访问范围会变。避法是把 Sync 当作常规动作，Cloud 侧删过 provider 之后回桌面端把本地配置清掉，别留一份指向已失效凭据的工作区配置。

把自建网关或本地模型的配置写错位置。 会踩是因为习惯改用户级配置。文档给的建议是改工作区下的配置文件而不是用户主目录那份，add-a-custom-llm.mdx 里给的可运行示例是接本机 Ollama，照抄如下：

{
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen3:8b": {
          "name": "Qwen3 8B"
        }
      }
    }
  }
}

避法是先确认工作区路径，再确认组织侧的 Custom providers 策略没有把本地 provider 关掉——被组织策略挡住时，你改多少遍配置都不会生效。

连服务、给授权的时候不看范围。 这类工具会在你机器上装桌面应用、代管模型凭据、拿到第三方服务的授权，还可能连上办公套件和团队控制面。会踩是因为连接流程做得很顺，点几下就通了。避法是每加一个连接就问一句：它拿到了哪些范围的权限、数据往哪儿流、组织侧能看到什么。授权治理这块可以参考 MCP 授权加固。

六、收束：三个自检问题和接下来该读哪份文件

判断 OpenWork 适不适合你团队，先回答三个问题：你能不能接受当前没有结果缓存，也就是重跑等于全价；你要不要把模型凭据集中到组织侧，以及集中之后账单归属怎么切；你要用的企业侧能力落在 /ee 下面吗——落在那里就按 ee/LICENSE 走，不是 MIT，具体以许可证原文为准。

接下来该读哪份文件，按你的角色分：只想控成本的，把 packages/docs/start-here/do-work-with-it/what-uses-tokens.mdx 里「什么时候开始消耗」和「怎么控制开销」这两组清单逐条对照自己的用法过一遍就够；要给团队统一模型入口的，接着读 packages/docs/cloud/share-with-your-team/managed-llm-provider.mdx 和 packages/docs/cloud/share-with-your-team/desktop-policies.mdx，前者定入口后者定边界；要评估自托管与合规的，直接读仓库根 LICENSE 和 ee/LICENSE，再配 packages/docs/cloud/security-and-operations.mdx 看它自己列的加密、密钥、审计与可用性要求。这个项目迭代很快，上面每一条都建议回仓库再核一次。

本篇属于一个把开源AI 工作流桌面应用 OpenWork逐层拆开讲的系列，整体地图见 OpenWork 是什么：把技能与 MCP 打包成能力的开源桌面应用；沿着这条线往下，还可以看 开源桌面应用 OpenWork 让 Agent 开浏览器干活的两条路：内置面板与 macOS 屏幕操作 和 开源桌面应用 OpenWork：工作流、设置共享、团队模板各自漏在哪。