OpenWork 发布追踪解读：2026-03-15 窗口 v0.11.151 → v0.11.175 的 25 个版本全记录

OpenWork 发布追踪解读：2026-03-15 窗口 v0.11.151 → v0.11.175 的 25 个版本全记录

【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork

本篇文章基于 OpenWork 开源仓库中的发布追踪文件 changelog/release-tracker-2026-03-15.md 展开，该文件记录了 2026 年 3 月 15 日前后一周内v0.11.151至v0.11.175共 25 个版本的提交、发布时间、变更内容与修复详情。读者将能完整掌握这段时期 OpenWork 在反馈链路修复、CI/发布流水线重构、Den 云工作流、会话交互与本地开发体验等维度的演进脉络，并学习如何解读这类发布追踪文件的字段结构与信息价值。

发布追踪文件的定位与字段结构

文件开头明确声明这是「Internal preparation file for release summaries. This is not yet published to the changelog page or docs.」，即它是一份面向发布摘要的内部准备文件，尚未公开发布到 changelog 页面或官方文档。这决定了它的价值在于信息密度与结构化程度——每个版本都按固定字段记录，便于后续自动聚合为对外发布说明。

每个版本条目包含以下标准字段：

从统计上看，这段发布窗口内绝大多数为Minor release，仅有v0.11.165（Settings 引入 OpenWork Cloud 登录）、v0.11.166（Daytona 化 Den Docker 流程落地，单版本 13,718 行变更）、v0.11.170（OpenWork Cloud Web 流程重构，单版本 20,054 行变更）被标记为Major release。这表明该窗口整体处于「高频迭代 + 少量大版本跃迁」的节奏。

反馈链路修复：一封邮件地址背后的工程闭环

窗口的开篇版本v0.11.151（commit5e606273，发布于2026-03-15T03:20:31Z）标题为「Feedback emails reach the team inbox again」，它修复了应用内反馈邮件目标，使报告重新送达共享的 OpenWork 团队收件箱team@openworklabs.com，全版本仅 81 行变更（55 insertions / 26 deletions）。

这一邮箱地址在仓库中有多处实体佐证：

• apps/app/src/react-app/domains/workspace/openwork-den-help-link.tsx 中定义了const SUPPORT_EMAIL = "team@openworklabs.com"，用于 Den 帮助链接；
• ee/apps/landing/components/app-feedback-form.tsx 中定义了const TEAM_EMAIL = "team@openworklabs.com"，用于落地页反馈表单；
• ee/apps/landing/README.md 说明OPENWORK_FEEDBACK_EMAIL为可选的环境变量，用于覆盖内部反馈接收者，默认值即为team@openworklabs.com；
• ee/apps/den-web/app/(den)/dashboard/(admin)/billing/stripe/checking/page.tsx/dashboard/(admin)/billing/stripe/checking/page.tsx#L104) 的账单检查页同样以该地址作为联系入口。

从源码结构看，反馈邮箱并非只存在于单一组件，而是贯穿了 app、landing、den-web 三套前端面。v0.11.151的修复本质是统一并校正反馈邮件的投递目标，让散落各处的反馈入口都能汇聚到团队共享收件箱，且可用环境变量OPENWORK_FEEDBACK_EMAIL在自托管场景下覆盖默认值。

CI 与发布基础设施：Blacksmith Runner 迁移与打包流水线重构

迁移到 Blacksmith Runner（v0.11.152）

v0.11.152（commit2386e59d）将 CI 与发布工作流迁往 Blacksmith 托管的 runner，并使用更大的 Linux 发布构建机，70 行变更（35/35），对用户可见的产品行为零影响。这一迁移在仓库工作流文件中得到了大量印证，例如：

• .github/workflows/ci-tests.yml 使用runs-on: blacksmith-16vcpu-ubuntu-2204，并在矩阵中同时覆盖blacksmith-16vcpu-ubuntu-2204与blacksmith-12vcpu-macos-15；
• .github/workflows/api-contract.yml、.github/workflows/ci-i18n.yml、.github/workflows/den-db-check.yml 等均切换到blacksmith-4vcpu-ubuntu-2204。

可以推断，这次迁移的目标是用按需规格的第三方 runner 替代默认 GitHub 托管 runner，从而让 CI/发布任务获得更灵活的资源配比，同时保持ubuntu-2204/ubuntu-2404/macos-15的跨平台覆盖。

桌面发布打包：从打包到上传的三段式重构（v0.11.154 / v0.11.156）

• v0.11.154（commit90c167f9，976 行变更，488/488）重构桌面发布流水线：先打包 workflow artifacts、校验捆绑的 sidecar 元数据、稍后步骤再上传发布资产，并新增了专门的 Linux ARM64 构建路径；
• v0.11.156（commit598fed9d，602 行变更，486/116）进一步把桌面发布拆分为build → bundle → upload 三个阶段，Linux ARM 单独打包，并从 workflow artifacts 自动上传资产。

这一「构建产物先行、资产上传后置」的模式，配合仓库根目录下的 packaging/docker/Dockerfile.den 等打包配置与 apps/desktop/electron-builder.base.yml 系 electron-builder 配置（electron-builder.cloud.yml、electron-builder.demo-a.yml、electron-builder.demo-b.yml、electron-builder.enterprise.yml），可以看出 OpenWork 桌面端面向多发行渠道（cloud / demo / enterprise）的复杂打包矩阵。将上传步骤后置的好处是：即便上传失败，也无需重跑整套构建，显著降低发布流水线的脆弱性。

Windows 发布诊断去遮蔽（v0.11.155）

v0.11.155（commit725b2117，51 行变更，27/24）修复了 Windows 发布流水线中的 GitHub 连通性诊断步骤，并统一了 release action 的输入参数名，让维护者在 Windows 桌面打包失败时能获得更清晰的报错信号。这与 scripts/release/publish-electron-assets.mjs 等发布脚本共同构成 Windows 侧发布可靠性的保障。

Orchestrator 包发布路径修正（v0.11.158）

v0.11.158（commit09837baf，33 行变更，17/16）修正了openwork-orchestrator的发布任务，使其从packages/orchestrator目录执行 sidecar 构建与 npm publish。该细节在 packages/automations/package.json、packages/world/package.json 等采用 tsup 构建的包中具有代表性——npm 发布必须从包自身工作目录运行，否则会因路径错位导致 sidecar 构建或发布失败。

Server 包名统一为 openwork-server（v0.11.172）

v0.11.172（commitd47a194d，3006 行变更，2296/710）将发布的 server 包重命名为openwork-server，并同步更新 orchestrator、release 与 dev 工具链，使其始终解析到同一包名。该版本同时标记了 1 项弃用：替换先前发布 server 包的所有旧引用。这与 apps/server/package.json 的包命名保持一致，消除了「安装、发布、校验三处包名不一致」的隐患。

会话体验：实时流式、滚动固定与嵌套会话

恢复实时会话与滚动固定（v0.11.153）

v0.11.153（commitf35422b7，449 行变更，315/134）是这段窗口中对核心会话体验最重要的一次修复：

• 恢复会话的增量文本更新，让助手回复重新以流式方式实时呈现；
• 重做聊天滚动固定（pinning）与跳转控制，长回复更易跟踪；
• 让 Web 代理在回退处理期间更安全地透传事件流。

其对应的测试基础设施可以在 evals/specs/streamed-markdown-answer.e2e.test.ts、evals/specs/chat-loading-shimmer.e2e.test.ts、evals/specs/task-activity-shimmer.e2e.test.ts 等端到端用例中找到线索，它们正是围绕「流式回答渲染」「加载态」「任务活动态」等会话体验的回归防线。

嵌套子会话的往返（v0.11.157 / v0.11.160 / v0.11.164）

子代理（subagent）会话的归属与可见性在这段窗口经历了多轮修复：

• v0.11.157（commitfca457be，706 行变更，485/221）将子代理会话内联渲染到任务步骤之下，并把重命名/删除操作收敛到选中会话行；修复了子会话与父任务步骤的挂接关系；
• v0.11.160（commita9e56ec0，475 行变更，303/172）修复侧边栏中父-子会话的浏览结构，使子代理会话显示在父任务之下、列表结构更清晰；
• v0.11.164（commitb88e2b53，2418 行变更，1907/511）修复根条目刷新时子会话被侧边栏同步丢弃的问题。

这一系列修复对应的领域在 apps/app/src 的会话/侧边栏模块与 evals/specs/browser-tabs-owned-by-thread.e2e.test.ts、evals/specs/live-tool-visible-after-session-switch.e2e.test.ts 等用例中均有覆盖，体现了 OpenWork 对「父子任务会话树」这一信息架构的持续打磨。

会话 trace 行的摇摆与回滚（v0.11.171 / v0.11.174）

会话追踪（trace）行的交互模型在两周内经历了一次完整的「尝试 → 回滚」循环：

• v0.11.171（commit10ec28d6，1577 行变更，986/591）让 trace 行仅在存在真实详情时才可展开，收紧移动端换行并优化工具图标；
• v0.11.174（commit9f3890f6，508 行变更，107/401）则回滚了这套可展开处理，恢复原有 trace 交互模型，并找回 trace 摘要的复制操作，同时保证窄侧边栏中 worker 名称不被折叠。

这个来回提醒我们：发布追踪文件记录的并不总是单向进步，它也如实保留了产品决策的试错痕迹，这对理解会话 trace 的最终形态很有参考价值。

Den 云工作流：从访问控制到 Daytona 化运行时的扩张

v0.11.157开始，Den 相关的变更密度显著上升，v0.11.165、v0.11.166、v0.11.170三个 Major release 将 Den 从「受限的宿主服务」推进为「完整的一等云工作流」。

访问收紧与身份验证（v0.11.157）

• 要求 Den 账号经过验证、移除暴露的宿主 token、按用户角色更严格地限制 worker 访问；
• 相关代码分布在 apps/app/src/app/lib/den.ts、apps/app/src/app/lib/den-handoff.ts 等 Den 客户端库中。

Settings 内的 Cloud 登录与 worker 打开（v0.11.165，Major）

v0.11.165（commitd556ed53，3120 行变更，2391/729）引入两个重大改进：

1. Settings 新增 Cloud 标签页：支持登录、组织选择、worker 列表，以及把就绪的 Den worker 直接打开进 OpenWork；
2. Web 化桌面认证交接：桌面端认证改走 Web handoff 流程，支持已安装应用 scheme 与 bearer session。

同时修复了共享 bundle 安装、断连 provider 凭据未完全清除、Den 认证未可靠使用已安装桌面 scheme、分享预览可读性等问题。

Cloud Settings 的开发者模式门控（v0.11.167 / v0.11.168）

v0.11.167（commit5ac86e5a，45 行变更，23/22）修正 Settings 标签列表与默认路由，使 Cloud 控件仅在开发者模式下出现，避免普通用户误入未完成的面板；v0.11.168（commit603ddfee，26 行变更，13/13）则是一次「恢复性发布」——tag 间 diff 仅为元数据级（版本号 bump），用户可见的 Cloud 门控修复已在上一版本落地，同时修复了隐藏 Cloud 状态卡住 Den 桌面 handoff、恢复 frozen-lockfile 发布安装与预期桌面资产集。这展示了发布追踪对「标记恢复型发布」的记录方式：并非每个 tag 都包含新的产品逻辑。

Daytona 化 Den Docker 流程（v0.11.166，Major，13,718 行变更）

v0.11.166（commit81882826）引入 Daytona-first 的本地 Den 栈：

• 新增 Den Docker 开发流程：专用 worker 代理、用于预载运行时的 snapshot 构建器；
• 引入den-v2控制平面与共享 Den DB 包，为托管 worker 路径铺路；
• 修复组织 slug 唯一性生成与webdev:local启动脚本。

对应实现分布在 ee/apps/den-api、ee/apps/den-gateway、ee/packages/den-db、ee/packages/cloud-runtime 等目录。后续v0.11.173（commit9f3890f6之后的5f0e11ce，805 行变更，762/43）为 Daytona 支撑的 Cloud worker 增加活动心跳（heartbeat），让 worker 状态保鲜，并新增 Daytona 镜像的 release snapshot 自动化——worker 运行时可观测性是这一架构方向的关键补充。

OpenWork Cloud Web 流程重构（v0.11.170，Major，20,054 行变更）

v0.11.170（commit3869313b）是这段窗口变更量最大的版本：

• 重建 Den Web 认证、结账与 dashboard 路由，使托管 onboarding 与计费体验「像应用本身而非一次性页面」；
• 持久化 worker 分享 token，重启后跨会话保留 deeplink，强化 open-in-web 自动连接与连接覆盖层；
• 新增自服务 Cloud Settings、OpenAI headless 认证、关闭时隐藏到托盘（tray-on-close）的桌面行为。

对应面包括 ee/apps/den-web（含 Stripe 结账检查页）、apps/desktop/electron 桌面壳等。v0.11.169（commit9ea1957b，3699 行变更，2421/1278）则为此前的 handoff 稳定性打底：将浏览器与 API base URL 分开持久化，返回代理安全的桌面认证 URL，修复桌面 handoff 状态损坏与 Den worker 的 CORS 行为。

Den 首次运行的直连引导（v0.11.161）

v0.11.161（commit4fb90428，448 行变更，198/250）移除 onboarding 中的意图选择步骤与营销味较重的认证壳，等待会话水合完成后，直接落在专用的最终连接（connect）屏幕——新 Den 用户启动 worker 并接入 OpenWork 的路径更短。这与v0.11.160中「下载按钮按访问者 OS 与架构选择正确安装器」的体验优化形成配套，共同压缩了托管路径的摩擦。

自定义 Skill Hub：组织自建技能源（v0.11.163）

v0.11.163（commit69249a20，1169 行变更，1034/135）是该窗口内唯一以新增能力为核心的版本：

• 支持任意 GitHub 仓库作为自定义技能 Hub，包含已保存仓库选择与「从该仓库安装」流程；
• Cmd+K 会话操作后恢复 composer 焦点；
• 恢复会话内的内联技能重载横幅，对齐 worker 状态标签与名称。

v0.11.164进一步允许移除默认技能 Hub 仓库，实现完全自定义的技能源配置；v0.11.170则修复了桌面应用中重复共享技能 deeplink 的问题。技能体系的实体可参考 skills-lock.json（仓库根目录的技能锁定文件）与 docs/features 下的功能文档，自定义 Hub 正是让组织把技能源「握在自己手里」的关键入口。

本地开发与 Docker 体验：LAN 可达的 OpenWork（v0.11.162）

v0.11.162（commit770c9473，149 行变更，130/19）专门优化了本地 Docker 测试的跨设备可达性：

• 传统 Docker dev 栈现在打印localhost、hostname 与 LAN IP三组 URL，覆盖 app、server 与 share service；
• packaging/docker/den-dev-up.sh 根据检测到的主机推导 Den 认证 URL 与可信来源（trusted origins）；
• 新增OPENWORK_PUBLIC_HOST与DEN_PUBLIC_HOST两个环境变量，用于自动检测错误时的手动覆盖。

在 packaging/docker/den-dev-up.sh 中可以看到其实现：脚本通过detect_public_host得到PUBLIC_HOST，用detect_lan_ipv4探测局域网 IP，随后把http://$PUBLIC_HOST:$DEN_WEB_PORT、http://$PUBLIC_HOST:$DEN_API_PORT及 LAN IP 变体一并追加为 CORS 可信来源，并在启动日志中分别打印「OpenWork web UI (LAN/public)」与「OpenWork web UI (LAN IP)」入口。配合 packaging/docker/docker-compose.den-dev.yml 与 packaging/docker/docker-compose.dev.yml，自托管开发者可以在手机等局域网设备上直接访问本地栈，无需手动改配置。

本地化与分享预览（v0.11.164）

v0.11.164除会话与 token 修复外，还带来两项产品侧改进：

• 完整日语本地化覆盖：对应 apps/app/src/i18n/locales/ja.ts，该文件与en.ts、zh.ts、es.ts等十余个语言文件并列，说明 OpenWork 的 i18n 采用语言文件全量对齐的模式，scripts/i18n-audit.mjs 用于审计翻译完整性；
• HTML-first 的分享预览：用面向爬虫的 HTML 链接替代纯 JS 渲染，并打磨 Open Graph 卡片，提升分享到社交平台时的抓取稳定性。

桌面行为与授权文件夹（v0.11.175）

窗口收尾版本v0.11.175（commitda0cd71c，1685 行变更，1313/372）把两项能力搬进 Settings：

• 授权文件夹管理：由服务端支撑的授权文件夹配置，替代先前分散的授权方式；
• 服务端支撑的空状态：首次运行的会话空状态从 workspace blueprint 播种，引导新用户完成首跑与 worker 设置。

同时清理了侧边栏标题、状态标签、页脚固定、隐藏生成时间戳，恢复 composer 操作标签，移除失效的 artifacts rail（该项同时被标记为弃用功能）。

版本节奏与变更量全景

将全部 25 个版本的变更量汇总，可以直观看到这段窗口的迭代节奏：

汇总可见：本窗口合计变更约58,000+ 行（insertions 约 34,000+、deletions 约 23,000+），其中 3 个 Major release 贡献了绝大部分代码量，而 22 个 Minor release 则负责在核心架构不变的前提下高频修复与打磨。这一「大版本铺路、小版本维稳」的组合，正是发布追踪文件最有价值的观察维度。

如何利用这份发布追踪文件

这份文件位于 changelog/ 目录下，与同目录的release-tracker-2026-02-19.md、release-tracker-2026-03-20.md、release-tracker-2026-08-03.md等按日期命名，共同构成 OpenWork 的发布历史档案。仓库根目录的 STATS.md 与 STATS_V2.md 提供项目规模统计，scripts/generate-changelog.mjs 用于从版本记录生成对外 changelog，而 scripts/release/versions.mjs 维护版本号管理逻辑。

对于研究 OpenWork 的读者，建议按以下方式使用本文档：

1. 追踪产品演进：按时间顺序阅读标题与 one-line summary，快速把握「实时会话 → Den 云工作流 → 会话 trace 打磨」三条主线；
2. 定位源码证据：每个版本的主题都能在仓库中找到对应模块，如 apps/app/src、ee/apps/den-web、packaging/docker、.github/workflows，实现「版本记录 ↔ 代码现状」的互证；
3. 理解发布工程：通过 Minor release 中占比极高的「发布基础设施」类条目，了解 OpenWork 对 CI runner、桌面打包、npm 发布、安装器恢复等发布链路的投入程度。

值得一提的是，本文档也如实记录了试错与回滚（如 v0.11.171 → v0.11.174 的 trace 交互回退）、恢复性发布（v0.11.168）、以及未发布 tag（多个版本标注「Unreleased tag only」）。这种诚实记录，使发布追踪文件成为比对外 changelog 更完整、更接近工程实况的第一手资料。

【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork