ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

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.37v0.18.3963625a4b2026-08-27T23:29:36ZRicher session artifacts and more resilient agent runs55851 行53651 增 / 2200 删相对 v0.18.38两个版本的主线分别聚焦工作流与实时会话的可靠性与会话制品与运行恢复的韧性且都没有功能弃用v0.18.38 弃用数为 0v0.18.39 唯一弃用的是旧版云端 worker 代理路径legacy cloud worker proxy path。二、跨工作区分屏视图Cross-Workspace Split View2.1 功能定位v0.18.38 的核心改进是新增跨工作区分屏视图一个会话窗格可以同时容纳来自两个不同工作区workspace的会话主会话与副会话各自保留归属工作区信息互不干扰。同工作区内两个会话也可以分屏并列方便对照比较。2.2 交互入口与操作路径从仓库中的端到端测试 evals/specs/cross-workspace-split-view.e2e.test.ts 可以还原完整操作路径上下文菜单入口在侧边栏会话列表中对目标会话右键弹出rolemenu菜单其中包含data-session-menu-open-split标识的Open as side chat菜单项命令面板入口按ControlKmacOS 为MetaK打开命令面板选择Open as side chat后再选择目标会话标题关闭副窗格点击副窗格上的Close side chat按钮副会话关闭主会话保持可见。2.3 归属权ownership语义的测试验证测试通过读取 UI 状态data-workbench-pane、data-workbench-workspace-id、data-session-surface-id等属性与 layout 状态来断言分屏的归属权正确性核心断言包括同工作区分屏时主、副窗格与对应 surface 的workspaceId均等于工作区 A跨工作区分屏时主窗格归属工作区 A、副窗格归属工作区 B且两者的workspaceId互不相等主窗格不得拥有副会话的 surfaceprimaryOwnsSecondarySurface false反之亦然——即两个窗格的会话对象完全解耦两个窗格都不出现data-workbench-pane-unavailableunavailable 状态确保分屏后两侧会话均可继续使用主、副窗格头部的 workspace 名称data-workbench-pane-workspace-name不同用户能直观分辨两侧来自不同工作区。测试还通过worlds/cross-workspace-split-view.ts世界构造器world bootstrapper预置了主工作区两个会话 副工作区一个会话覆盖同工作区分屏与跨工作区分屏两条路径。2.4 布局状态模型从测试读取的context.conversations.layout可以看出布局状态区分single单会话与split分屏两种 kindsplit 布局中分别记录primarySessionId/primaryWorkspaceId与secondarySessionId/secondaryWorkspaceId这正是会话视图状态跟随工作区的底层数据结构。测试同样覆盖了responsive-session-layout见 evals/specs/responsive-session-layout.e2e.test.ts验证窄屏下的布局适配。三、中断运行恢复Resuming Interrupted Runs3.1 Transcript 恢复动作v0.18.38 在会话 transcript 中新增了用于恢复中断运行的动作v0.18.39 进一步把从中断中恢复做成了可依赖的能力。核心实现位于 apps/app/src/react-app/domains/session/surface/session-surface.tsx中断结果未知时界面渲染AdmissionOutcomeUnknownCarddata-testidadmission-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 Rail4.1 从 transcript 到 artifact railv0.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 源码可以看出分类逻辑isArtifactTargeturl或file两种 kindisCollectibleArtifactTarget**文件真实存在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: false、logLevel: fatal、htmlLabels: false、suppressErrorRendering: true启动 Mermaid并按当前主题dark/default切换配色secure列表锁死关键配置项防外部篡改。3SVG 清洗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并下载生成的 SVGdiagram-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.ts、src/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 应用宿主端口3005OPENWORK_API_PORTDen API 宿主端口8788OPENWORK_ALLOW_SIGNUP允许公开注册评估用trueOPENWORK_ORG_NAME单组织名称OpenWork EvaluationOPENWORK_OWNER_EMAILS允许认领组织的 owner 邮箱列表逗号分隔配合OPENWORK_ALLOW_SIGNUPfalse使用空不引导OPENWORK_SETUP_CODE在/setup输入的一次性引导码空不引导8.3 服务组成栈由四个服务组成全部来自ghcr.io/different-ai/openwork-*的固定 digest 镜像mysqlMySQL 8.4关闭performance_schema、缓冲池 128M仅暴露在 compose 网络内部不映射宿主端口den-migrate一次性执行 Den DB 引导迁移den-db的bootstrap脚本成功后退出denDen API 服务映射127.0.0.1:8788以single_org组织模式运行通过PROVISIONER_MODEstub使用 stub worker provisioner并以/health做健康检查webDen Web 前端映射127.0.0.1:3005容器内通过DEN_API_BASEhttp://den:8788访问 API宿主端口在容器内不可达浏览器侧则使用DEN_API_PUBLIC_URL暴露的地址。8.4 私有管理员引导替代公开注册如需关闭公开注册并引导首位管理员设置OPENWORK_ALLOW_SIGNUPfalse OPENWORK_OWNER_EMAILSadminexample.com OPENWORK_SETUP_CODE一次性引导码然后在/setup页面使用引导码认领组织。引导流程的详细文档参见 packages/docs/self-host/deploy-to-your-cloud/first-administrator.mdx。九、发布数据概览与总结v0.18.385a7ea5af4 项主要改进、4 项主要 bug 修复、0 弃用。主题是跨工作区分屏 实时会话恢复v0.18.3963625a4b5 项主要改进、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),仅供参考
返回列表