news 2026/9/13 1:25:17

OpenWork v0.18.38/v0.18.39 版本深度解析:跨工作区分屏、会话制品侧栏与运行恢复韧性

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
OpenWork v0.18.38/v0.18.39 版本深度解析:跨工作区分屏、会话制品侧栏与运行恢复韧性

OpenWork v0.18.38/v0.18.39 版本深度解析:跨工作区分屏、会话制品侧栏与运行恢复韧性

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

导读

本文基于 OpenWork 仓库中的发布追踪文档 changelog/release-tracker-2026-08-27.md,深入解析 v0.18.38 与 v0.18.39 两个连续主版本带来的核心能力:跨工作区(cross-workspace)分屏视图、会话中断恢复(resume)动作、会话文件迁入制品侧栏(artifact rail)、Mermaid 图表安全渲染与代码块换行控制,以及本地/云端 agent 运行的韧性改进。读完本文,你将理解这些发布项在 UI 交互、运行恢复机制、安全渲染链路与评估部署方式上的具体实现与验证证据,并掌握 pull-only Docker 评估栈的一键拉起方法。

一、发布背景与版本范围

本次追踪覆盖同一自然日的两个连续版本,均为 Major 级发布:

版本Commit发布时间(UTC)标题变更行数
v0.18.385a7ea5af2026-08-27T13:24:26ZSplit-view workflows and live sessions get more dependable12814 行(11415 增 / 1399 删,相对 v0.18.37)
v0.18.3963625a4b2026-08-27T23:29:36ZRicher session artifacts and more resilient agent runs55851 行(53651 增 / 2200 删,相对 v0.18.38)

两个版本的主线分别聚焦"工作流与实时会话的可靠性"与"会话制品与运行恢复的韧性",且都没有功能弃用(v0.18.38 弃用数为 0);v0.18.39 唯一弃用的是旧版云端 worker 代理路径(legacy cloud worker proxy path)

二、跨工作区分屏视图(Cross-Workspace Split View)

2.1 功能定位

v0.18.38 的核心改进是新增跨工作区分屏视图:一个会话窗格可以同时容纳来自两个不同工作区(workspace)的会话,主会话与副会话各自保留归属工作区信息,互不干扰。同工作区内两个会话也可以分屏并列,方便对照比较。

2.2 交互入口与操作路径

从仓库中的端到端测试 evals/specs/cross-workspace-split-view.e2e.test.ts 可以还原完整操作路径:

  • 上下文菜单入口:在侧边栏会话列表中对目标会话右键,弹出role="menu"菜单,其中包含data-session-menu-open-split标识的"Open as side chat"菜单项;
  • 命令面板入口:按Control+K(macOS 为Meta+K)打开命令面板,选择Open as side chat后再选择目标会话标题;
  • 关闭副窗格:点击副窗格上的Close side chat按钮,副会话关闭,主会话保持可见。

2.3 归属权(ownership)语义的测试验证

测试通过读取 UI 状态(data-workbench-panedata-workbench-workspace-iddata-session-surface-id等属性与 layout 状态)来断言分屏的归属权正确性,核心断言包括:

  • 同工作区分屏时,主、副窗格与对应 surface 的workspaceId均等于工作区 A;
  • 跨工作区分屏时,主窗格归属工作区 A、副窗格归属工作区 B,且两者的workspaceId互不相等;
  • 主窗格不得"拥有"副会话的 surface(primaryOwnsSecondarySurface === false),反之亦然——即两个窗格的会话对象完全解耦;
  • 两个窗格都不出现data-workbench-pane-unavailable(unavailable 状态),确保分屏后两侧会话均可继续使用;
  • 主、副窗格头部的 workspace 名称(data-workbench-pane-workspace-name)不同,用户能直观分辨两侧来自不同工作区。

测试还通过worlds/cross-workspace-split-view.ts世界构造器(world bootstrapper)预置了主工作区两个会话 + 副工作区一个会话,覆盖"同工作区分屏"与"跨工作区分屏"两条路径。

2.4 布局状态模型

从测试读取的context.conversations.layout可以看出,布局状态区分single(单会话)与split(分屏)两种 kind;split 布局中分别记录primarySessionId/primaryWorkspaceIdsecondarySessionId/secondaryWorkspaceId,这正是"会话视图状态跟随工作区"的底层数据结构。测试同样覆盖了responsive-session-layout(见 evals/specs/responsive-session-layout.e2e.test.ts),验证窄屏下的布局适配。

三、中断运行恢复(Resuming Interrupted Runs)

3.1 Transcript 恢复动作

v0.18.38 在会话 transcript 中新增了用于恢复中断运行的动作;v0.18.39 进一步把"从中断中恢复"做成了可依赖的能力。核心实现位于 apps/app/src/react-app/domains/session/surface/session-surface.tsx:

  • 中断结果未知时,界面渲染AdmissionOutcomeUnknownCarddata-testid="admission-outcome-resume"),以Resume作为唯一强调动作;
  • 用户点击恢复卡片后,handleResumeInterrupted会把分类好的恢复提示(recovery prompt)通过正常发送路径重新提交,让 agent 在当前会话内继续被中断的任务,而不是另起新会话;
  • 为防止快速连点导致重复提交,恢复动作使用 single-flight 守卫(createSingleFlight):在途恢复期间,重复点击会被丢弃(never queues),保证恰好只 admit 一条恢复提示。

3.2 更可靠的恢复场景

v0.18.39 将恢复韧性扩展到以下场景(来自发布文档的 bug fix 明细):

  • **空闲准入(idle admissions)排队跟进(queued follow-ups)**不再导致恢复卡死;
  • 事件流(event-stream)重启:同步状态变更后死掉的事件流会被自动重启;
  • 访问设置页不再打断健康运行中的会话;
  • 大工作区会话历史的水合(hydration)被限定上界,worker 恢复更可靠。

这些改进覆盖桌面端、Web 端与云端三条运行路径,是"运行恢复韧性"主题的主体。

四、会话文件迁入制品侧栏(Artifact Rail)

4.1 从 transcript 到 artifact rail

v0.18.39 将会话文件从聊天 transcript 中移出,放入独立的制品侧栏(artifact rail),避免文件条目打断对话流;同时优化了徽标(badge)布局在窄屏下的响应式表现。相关 UI 与判定逻辑位于 apps/app/src/react-app/domains/session/artifacts/artifact-panel.tsx 与 apps/app/src/react-app/domains/session/artifacts/open-target.ts。

4.2 可收集制品的判定规则

从 open-target.ts 源码可以看出分类逻辑:

  • isArtifactTargeturlfile两种 kind;
  • isCollectibleArtifactTarget:**文件真实存在(exists === true)且预览类型属于侧栏允许集合(SIDEBAR_ARTIFACT_FILE_PREVIEWS)**的文件,才会进入侧栏制品集合;
  • isOpenableFileTarget:存在即可打开;
  • isLocalhostBrowserTargeturl指向 localhost/127.0.0.1/0.0.0.0/[::1] 时归类为本地浏览器目标。

在 session-page.tsx 中,transcriptArtifactTargets[selectedSessionId]isCollectibleArtifactTarget过滤后得到artifactFileTargets与计数artifactTargetCount,驱动侧栏徽标与制品面板。工作区文件树(WorkspaceFileTree)采用懒加载(import("./workspace-file-tree")),只在面板激活时才拉取文件结构。.mmd文件会被识别为 Mermaid 制品(isMermaidArtifact)。

五、Markdown 能力增强:Mermaid 安全渲染与代码块换行

5.1 Mermaid 图表的安全渲染链路

v0.18.39 引入"可安全渲染 Mermaid 图表"的能力,完整实现位于 apps/app/src/components/markdown/mermaid.ts,核心是一条"守卫 → 渲染 → 清洗 → 降级"的流水线:

(1)输入守卫(guardMermaidSource,超出以下任一限制即拒绝渲染:

限制项上限值
源码体积maxSourceBytes50,000 字节
节点数maxNodes250
边数maxEdges400
语句数maxStatements400
行数maxLines800
渲染超时renderTimeoutMs5,000 ms

同时执行不安全内容检测hasUnsafeMermaidSource):拦截%%{init/config}指令、click处理器、frontmatter 中的config:javascript:/data:/blob:/file:等危险 URL 协议、url(...)引用与href/src属性注入等。

(2)运行时配置(mermaidConfigForTheme:以securityLevel: "strict"startOnLoad: falselogLevel: "fatal"htmlLabels: falsesuppressErrorRendering: true启动 Mermaid,并按当前主题(dark/default)切换配色;secure列表锁死关键配置项防外部篡改。

(3)SVG 清洗(sanitizeMermaidSvg:渲染结果先经 DOMPurify(禁用未知协议,禁止href/src/xlink:href属性与a/embed/foreignObject/iframe/image/object/script/use标签),再通过 DOMParser 解析为 SVG DOM,递归剔除on*事件属性、重定向属性、危险style/url()引用与<style>内容,最后补全xmlns后序列化回字符串。

(4)失败降级:渲染超时、运行时不可用、源码非法或清洗失败时,统一降级为展示源码视图,并在 UI 中给出明确原因文案(Diagram is too large / too complex / contains unsafe directives / rendering timed out…),用户可以切换"渲染视图/源码视图"(data-openwork-mermaid-view)并下载生成的 SVG(diagram-N.svg)。渲染采用队列串行化 + 视口邻近增强(enhanceNearViewport),滚动到图表附近才真正渲染,避免一次加载大量图表拖慢页面。

5.2 代码块换行控制

在 apps/app/src/components/markdown/markdown.tsx 中,代码块新增[data-openwork-code-wrap]切换按钮:点击后在换行/不换行两种状态间切换(codeWrapStates按块记录状态),长行代码在窄屏下不再横向溢出,方便阅读与复制。

六、实时会话与长流响应性

6.1 实时会话状态跨导航存活

v0.18.38 的 bug 修复项中,最重要的两条是:

  • 保留跨导航与跨工作区切换的实时会话状态——会话 status(如进行中/已中断)不会因为用户跳转页面或切换工作区而丢失;
  • 保持重连后的观察者存活(reattached observers stay live)——会话视图重新挂载后,事件观察者仍然持续接收流数据。

6.2 长运行流的响应性

"长运行流保持响应"意味着:即使 agent 正在长时间流式输出,界面的事件处理(如取消、恢复、切换窗格)仍然及时响应,不被渲染长文本阻塞。这与上一节的"队列串行化渲染 + 邻近增强"策略相互配合,共同降低长流对 UI 主线程的压力。

七、云端与远程会话能力

7.1 Cloud 扩展状态与连通性

v0.18.38 让Cloud 扩展状态反映真实连通性:扩展图标与状态不再只是"已安装"的静态展示,而是基于实际连接结果更新;远程会话能力(remote-session capabilities)可以真正触达云端目标。

7.2 worker 恢复避免竞争归属

worker 恢复逻辑改为避免竞争所有者(competing owners):同一 worker 不会被多个恢复流程同时接管,从根源上消除"两个恢复流程抢同一个 worker"造成的状态漂移。

7.3 按成员托管模型凭证

v0.18.39 的 OpenWork Cloud 新增按成员(per-member)的托管模型凭证(managed-model credentials),即模型供应商凭证可以细化到组织成员维度进行托管与下发,相关实现分布在 ee/apps/den-api 的推理与凭证相关模块(如src/inference.tssrc/llm/cloud-provider-materialization.ts等)。

7.4 付费浏览器访问与远程命令的桌面投递

同一版本还为 OpenWork Cloud 加入付费浏览器访问(paid browser access),并支持将远程会话命令投递到桌面端(desktop delivery for remote-session commands);配合"Electron 文件传输在远程桥接(remote bridge)上正确工作"的修复(v0.18.39 bug fix),云端与桌面之间的文件与命令通路被补齐。

7.5 弃用项

v0.18.39 唯一弃用项是旧版云端 worker 代理路径,意味着 worker 流量统一收敛到新代理实现,不再保留双路径兼容。

八、Pull-Only Docker 评估栈实操

v0.18.38 引入了一个只拉取(pull-only)的 Docker 评估栈——无需克隆仓库、无需本地构建、无需启动脚本,直接用 GHCR 发布的镜像拉起整套环境,配置文件为 packaging/docker/docker-compose.eval.yml。

8.1 启动步骤

umask 077 printf 'OPENWORK_AUTH_SECRET=%s\nOPENWORK_DB_ENCRYPTION_KEY=%s\n' \ "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env docker compose -f docker-compose.eval.yml up -d --wait

启动后打开http://localhost:3005注册账号即可体验。注意该栈不是生产姿态:使用开发级 MySQL 凭据、stub worker provisioner、无云端沙箱、无邮件投递、默认开放公开注册。

8.2 环境变量速查表

变量用途默认值
OPENWORK_AUTH_SECRETBetter Auth 密钥(≥32 随机字符,必填)
OPENWORK_DB_ENCRYPTION_KEYDen DB 加密密钥(≥32 随机字符,必填)
OPENWORK_WEB_PORTWeb 应用宿主端口3005
OPENWORK_API_PORTDen API 宿主端口8788
OPENWORK_ALLOW_SIGNUP允许公开注册(评估用)true
OPENWORK_ORG_NAME单组织名称OpenWork Evaluation
OPENWORK_OWNER_EMAILS允许认领组织的 owner 邮箱列表(逗号分隔,配合OPENWORK_ALLOW_SIGNUP=false使用)空(不引导)
OPENWORK_SETUP_CODE/setup输入的一次性引导码空(不引导)

8.3 服务组成

栈由四个服务组成(全部来自ghcr.io/different-ai/openwork-*的固定 digest 镜像):

  • mysql:MySQL 8.4,关闭performance_schema、缓冲池 128M,仅暴露在 compose 网络内部,不映射宿主端口;
  • den-migrate:一次性执行 Den DB 引导迁移(den-dbbootstrap脚本),成功后退出;
  • den:Den API 服务,映射127.0.0.1:8788,以single_org组织模式运行,通过PROVISIONER_MODE=stub使用 stub worker provisioner,并以/health做健康检查;
  • web:Den Web 前端,映射127.0.0.1:3005,容器内通过DEN_API_BASE=http://den:8788访问 API(宿主端口在容器内不可达),浏览器侧则使用DEN_API_PUBLIC_URL暴露的地址。

8.4 私有管理员引导(替代公开注册)

如需关闭公开注册并引导首位管理员,设置:

OPENWORK_ALLOW_SIGNUP=false OPENWORK_OWNER_EMAILS=admin@example.com OPENWORK_SETUP_CODE=<一次性引导码>

然后在/setup页面使用引导码认领组织。引导流程的详细文档参见 packages/docs/self-host/deploy-to-your-cloud/first-administrator.mdx。

九、发布数据概览与总结

  • v0.18.38(5a7ea5af:4 项主要改进、4 项主要 bug 修复、0 弃用。主题是"跨工作区分屏 + 实时会话恢复";
  • v0.18.39(63625a4b:5 项主要改进、5 项主要 bug 修复、1 项弃用。主题是"会话制品侧栏 + 运行恢复韧性",并为 LiteLLM 示例补充了同步的模型元数据(synchronized model metadata)。

从源码证据看,这两个版本的核心价值在于:分屏会话的归属权清晰可验证(e2e 测试逐项断言)、中断恢复走正常发送路径且具备 single-flight 防重入Mermaid 渲染具备完整的"守卫-清洗-降级"安全链路评估栈做到零构建即可体验。对于使用 OpenWork 做多工作区协作、长任务编排或云端/桌面混合部署的团队,这两次发布的组合意味着更可靠的多任务并行视图与更抗中断的任务恢复能力。

如需继续深入,建议阅读:cross-workspace-split-view.e2e.test.ts(分屏验证)、mermaid.ts(安全渲染)、session-surface.tsx(恢复逻辑)、docker-compose.eval.yml(评估栈)。

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

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/13 1:24:04

告别逆向破解:合规路径下的点赞数据分析实战指南

做内容运营这几年&#xff0c;我有个特别深的体会&#xff1a;点赞数据是判断流量质量最直接的指标之一&#xff0c;但真想把它分析透的时候&#xff0c;第一步就容易卡住——打开抓包工具一看&#xff0c;抖音这类App的每个请求后面都挂着一串加密参数&#xff0c;abogus、as、…

作者头像 李华
网站建设 2026/9/13 1:20:20

逻辑综合实战:从RTL到门级网表的时序与功耗优化

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华