CompozyOS 0.4.4 让桌面更新成为持久代理会话的考验

桌面应用如果只是笔记编辑器，更新过程很容易判断：关闭窗口，安装新版本，再次打开文件即可。代理软件面对的契约要复杂得多。桌面外壳需要重启时，一个正在运行的会话可能正在流式输出、持有工作树、等待批准、记录工具调用，或协调另一个会话。

这正是 CompozyOS 0.4.4 比简短变更日志看起来更有意思的原因。官方发布变更日志列出了 2026 年 10 月 28 日的一项重点变化：在桌面更新期间保留活动会话。该项目是一个本地优先的运行时，用于持久代理会话、循环、自动化、权限管理以及多个控制界面。在这一背景下，更新行为并非表面问题，而是运行时可靠性模型的一部分。

实际建议很直接：在可丢弃或已备份的 CompozyOS 主目录中尝试 0.4.4，然后在会话处于活动状态时主动执行更新。不要把窗口被保留下来当作工作也被保留的证据。应分别检查守护进程、会话记录、轮次状态、排队输入、附件、工作树和提供商连接。

0.4.4 有哪些变化

发布页面目前用一句简短说明概括这项变化，而不是展开成一篇功能介绍：活动会话应当能够在桌面更新后继续存在。相关发布历史说明了为什么这是一条重要边界。CompozyOS 0.4.0 是首个稳定版本，0.4.1 修复了若干桌面和运行时恢复场景，0.4.2 处理了后台读取 Claude 使用量时可能触发钥匙串密钥请求的问题，而 0.4.4 则将目标转向桌面更新本身的连续性。

这一演进很重要，因为 CompozyOS 包含两个紧密相关的部分：桌面应用和本地守护进程。桌面文档说明，桌面应用和 compozy 命令使用同一个本地守护进程、配置、工作区和会话历史。应用可以连接到已经正常运行的守护进程，也可以启动安装在 CompozyOS 主目录中的运行时；必要时，还能安装并启动随应用捆绑的运行时。退出应用并不应当停止守护进程。

因此，桌面更新至少可能有两种含义：

• 替换图形外壳，同时让守护进程及其状态继续可用；
• 替换同时包含应用和运行时的软件包，然后重启这套新组合，同时不丢失持久状态。

关键在于“活动”二字。启动后恢复一份旧会话列表，远不如保持正在进行的轮次完整。真正有用的实现必须保留足够的所有权和事件状态，使会话能够继续、重新连接，或明确报告中断。仅凭发布标题，我们无法得知每种提供商、操作系统、安装路径或故障模式下的具体表现。这正是用户应该测试的部分。

为什么桌面连续性是运行时问题

许多代理工具最初只是一个终端进程。进程掌握提示符、标准输入、输出流，通常还掌握运行模型客户端的子进程。关闭终端可能会终止一切。持久运行时改变了这种安排：工作由守护进程负责，而终端、浏览器、桌面外壳或其他客户端负责观察和控制。

这种设计带来了有用的分离：界面消失，并不一定意味着工作被取消。但它也让升级路径更复杂。只有当守护进程知道重启前发生了什么，并能在重启后重放或重建状态时，客户端重启才是安全的。

一次会话更新可能跨越多个边界：

1. 桌面进程可能关闭，或将控制权交给原生安装程序。
2. 随软件打包的运行时可能被替换或重启。
3. 守护进程可能仍在运行，也可能被要求停止，或者在启动后才被发现。
4. 提供商进程可能继续运行、重新连接、失败，或拒绝恢复后的环境。
5. 界面必须判断应显示实时输出、补上的会话记录、警告，还是一个确实已经停止的轮次。

CompozyOS 文档将更广义的模型描述为由守护进程拥有的会话：即使工作在后台继续，会话事件仍可供检查。这是理解更新行为的正确抽象，但不能把它误解为每个外部副作用都会被检查点记录。命令行仍在运行时，转录记录可以已经持久化。工作树仍可保持连接，但提供商可能已经失去连接。排队的消息可以存储下来，但代理可能尚未收到它。

因此，“会话存活了”不应只意味着“这一行仍然可见”。它还应意味着，运行时能够告诉你哪些部分保留下来，哪些部分需要人工处理。

第一个测试：在空闲会话期间更新

从破坏性最低的情况开始。创建一个测试工作区，启动会话，发送一个能产生持久响应的提示，然后让会话保持空闲。记录会话标识符、工作区、选定的配置文件，以及 CompozyOS 主目录的位置。随后按照文档说明的更新路径执行桌面更新。

桌面指南提供了三个有用的命令：

compozy update --check -o json
compozy update -o json
compozy update --cancel -o json

文档说明，菜单栏或“设置”中的操作可以下载、安装并重启应用。文档还指出，在原生安装程序准备经过验证的软件包时，应用会保持打开；而应用关闭时，则可以把更新暂存到下一次启动。Linux 上，自动安装应用轨道更新仅限于 AppImage 路径。

更新完成后，不要只看第一个界面，而应检查以下所有项目：

• 应用报告的版本符合预期；
• 使用的仍是同一个 CompozyOS 主目录；
• 工作区和会话标识符没有变化；
• 之前的转录记录完整，顺序正确；
• 选定的代理和配置文件仍与该会话关联；
• 重连期间没有出现重复回合；
• 守护进程运行正常，应用也已连接到它；
• 会话可以接受新的提示。

这个测试能回答普通的持久化状态是否保留，但还不能回答产品能否应对工作进行期间的更新。

第二个测试：在回合运行时更新

更有价值的测试应使用一个能够持续足够长时间、便于观察的提示。长时间运行的本地命令、有界的测试套件，或一个会产生多个工具事件的受控任务，都比人为加入睡眠更合适。使用专为测试创建的仓库，并从其环境中移除敏感凭据。

开始这一回合，等待出现明确的工具或进度事件，然后从桌面外壳启动更新。在弄清结果之前，不要发送额外提示。根据具体实现，以下结果都可以接受：

• 守护进程和提供商继续运行，桌面端重新连接到同一个活动回合；
• 桌面端重启时回合完成，随后显示完整的转录记录；
• 运行时暂停或取消回合，但准确记录这一事实，并允许恢复；
• 安装程序拒绝继续，直到明确处理活动中的工作。

危险的结果是：会话看起来合理，却悄悄丢失工具结果、重复执行副作用，或显示最终答案，却没有产生该答案的事件历史。持久代理运行时需要的证据，不能只是一扇窗口成功重启。

使用一个副作用可以通过两次检查来核实的任务。例如，让测试代理写入一个名称唯一、内容包含随机数的文件，然后报告文件内容。更新后，对比文件、转录记录、工具结果和最终答案。如果操作执行了两次，测试应能把这一点显现出来。绝不要用生产部署、破坏性迁移、支付操作或真实凭据轮换来做这个实验。

第三个测试：排队输入和附件

活动会话不只是一次模型回合。操作员可能在代理忙碌时输入后续内容、将消息排队、引导回合，或附加文件。重连时，这些输入最容易暴露出脑裂状态。

创建一个小型测试附件，并发送一个让会话持续忙碌的提示。准备好后续消息，但在确认预期的排队行为之前不要点击发送。更新期间，观察草稿是否仍是草稿、排队消息是否仍在队列中，以及引导操作是否只交付一次而不是两次。

该项目公开的发布历史多次提到转录连续性、排队输入、会话消息、附件，以及从提供商断连中恢复。这些条目表明，维护者所理解的会话状态并不只是聊天记录。它们也说明，读者应测试当前版本，而不是根据单一标题推断全部行为。

一份实用的检查清单如下：

• 未发送的文本仍保持未发送状态；
• 排队输入只有一个投递状态；
• 附件具有唯一的记录身份，并且仍然可读；
• 引导消息不会变成重复的普通提示；
• 提供商错误能够被看见，而不是被通用的重新连接转圈提示替代；
• 会话的配置档案与工作区边界保持不变。

如果更新改变了会话在队列中的位置，应将其记录为产品行为。这种变化也许可以接受，但必须能够被观察到并得到文档说明。

0.4.4 无法证明什么

稳定的桌面更新并不等同于安全的执行边界。仓库将 CompozyOS 描述为本地优先的软件：Go 二进制文件和基于 SQLite 的存储会将运行时状态保留在操作员的机器上，除非外部提供商或扩展负责其中一部分边界。这有利于控制和检查，但也意味着机器、用户账户、提供商凭据、工作区文件以及已安装的扩展仍然属于信任模型的一部分。

该仓库标注为 MIT 许可，README 也表示欢迎贡献。许可证的开放性只能说明人们可以在许可证允许的范围内检查、修改和再分发代码。它并不保证每个版本都已成熟，也不保证每个集成都具备相同的安全属性，更不保证更新不会暴露迁移问题。

项目自身的迁移材料尤其值得关注。迁移指南描述了此前的一次修正：发行元数据错误地将构件标记为 BSL-1.1，尽管项目仍采用 MIT 许可证。指南还记录了较旧与较新产品线之间的兼容性边界。这提醒我们，跨越主要产品边界时应阅读迁移说明，而不是想当然地认为原地更新总是可逆的。

桌面操作指南还提出了另一项运维警告：替换运行时二进制文件后，如果重启或健康检查失败，替换版本可能已经迁移数据库。文档建议保留备份以便诊断，不要把旧二进制文件恢复到可能已经完成迁移的主目录上；如有必要，应将目标版本或更新的兼容版本重新安装到同一个主目录中。这类细节比精致的更新动画更重要。

现在适合谁尝试

对于已经需要让代理工作持续超出终端生命周期、并且能够提供独立测试主目录的开发者来说，CompozyOS 0.4.4 值得测试。对于围绕本地代理会话构建自动化的维护者，它同样有参考价值，因为更新路径本身就是自动化可用性故事的一部分。如果应用被用作长期运行守护进程的桌面前端，那么该版本直接针对的正是用户通常最担心的一类中断。

对于需要全托管控制平面、代理与主机之间严格隔离，或成熟企业变更管理流程的团队来说，它就不是那么显而易见的选择。这个项目的价值在于其本地运行时模型：会话、任务、循环、权限、审批和自动化共享由守护进程管理的状态模型。这可以省去大量胶合代码，但也会把更多责任集中到本地安装及其配置上。

一次合理的试用应具备三个条件：

• 可丢弃的工作区，或经过验证的备份；
• 测试提供商环境中不包含生产凭据；
• 有足够的可观测性，以比较转录、文件系统、进程状态和更新日志。

保留上一版本以便对比，但不要轻率地将已迁移的主目录降级。在测试会改变运行时或数据库状态的路径前，先进行完整备份。

与其他方案的简要比较

如果需求只是“关闭终端后仍让命令继续运行”，终端复用器、系统服务或普通任务队列可能更容易理解。这些工具不具备 CompozyOS 面向代理的会话模型，但其运行行为较为熟悉，范围通常也足够有限，便于审计。

如果需求是用于远程开发的浏览器界面，托管式或自托管的开发平台可能提供更完善的身份、工作区和审计集成。但这也可能带来云依赖，以及不同的信任边界。CompozyOS 则强调带有明确网关界面的本地守护进程，因此取舍在于：掌控机器，同时承担维护这台机器的运维工作。

如果需求是与模型无关的代理运行器，编排库可以提供更底层的原语，并把持久化、审批和更新策略交给应用处理。当团队已经拥有可靠的平台层时，这或许是合适的选择。CompozyOS 针对的恰恰是相反的问题：团队不希望为每个代理 CLI 重新构建平台层。

因此，比较时应关注故障处理，而不是功能数量。要问的是：界面重启、提供商断开连接、主机重启、存在排队消息、数据库迁移已经执行，或子进程在工具调用进行到一半时退出时，各个方案会如何表现。

实用结论

CompozyOS 0.4.4 是一次规模不大的发布，却隐含着一项重要测试。在桌面更新过程中保留活动会话，正是那种只有在失败时用户才会注意到的可靠性功能。它之所以有价值，是因为 CompozyOS 将自己定位为持久的本地运行时，而不是包裹一次性提示词的薄层窗口。

这个版本适合尝试，但还不足以让人把无人值守的生产任务交给一个刚更新的代理系统。先使用隔离的主目录。测试空闲会话、进行中的回合、排队输入、附件、工作树、提供商重新连接，以及更新中断后的恢复。保留对话记录和文件系统证据，并检查守护进程实际做了什么。

如果这些测试通过，0.4.4 会让桌面外壳不再那么像唯一的中断点。如果测试未通过，失败同样有价值：它会显示缺失环节究竟是安装程序协调、守护进程所有权、提供商恢复、数据库迁移，还是仅仅是误导性的 UI 状态。这种区分，才是衡量开源代理运行时的真正标准。