上一篇《柯影智航桌面版发布：把 AI Agent 真正装进 macOS 与 Windows》发布后，我们收到了一些关于桌面版本的反馈。 其中，有两个问题被反复提到：桌面应用已经可以安装了，后续版本怎么更新？ 从 v0.1.2 到 v0.1.3，除了版本号变化，还解决了哪些实际问题？ 这也是柯影智航 v0.1.3 想解决的核心问题。 这一次，我们没有把重点放在继续堆叠 AI 功能上，而是回到了一个更基础、却同样重要的问题： 当一个 AI Agent 被封装成桌面应用之后，怎样让它真正具备桌面软件应有的发布、更新和维护能力？ 如果说早期版本解决的是“能不能装进电脑”，那么 v0.1.3 开始解决的，就是“装进去之后，能不能长期用下去”。
01｜v0.1.3 更新了什么？
本次更新主要围绕四个方向展开： 品牌识别、软件更新、发布流程与版本回退。 产品身份进一步完善 首先是一个看起来很“小”，实际上非常影响产品完整度的问题——品牌识别。 v0.1.3 更新了主页面以及「关于与致谢」页面中的产品图标，同时进一步完善桌面应用的产品身份、版本号和品牌信息。 对于开发阶段的项目来说，一个窗口能正常打开，功能能够运行，可能就已经足够。 但对于真正交付给用户的桌面软件来说，情况并不一样。 用户需要清楚知道： 我正在使用什么产品？当前是什么版本？出现问题时应该对应哪个版本排查？ 因此，从 v0.1.3 开始，我们进一步统一柯影智航桌面端的产品标识和版本信息，让它逐渐摆脱“开发工程”的感觉，向完整桌面产品靠近。
02｜应用终于开始“知道自己该更新了”
v0.1.3 一个比较重要的变化，是进一步完善了应用内软件更新能力。 过去如果发布新版本，用户通常需要：
打开 GitHub → 找到 Releases → 查看最新版本 → 下载安装包 → 重新安装这对于开发者来说并不陌生，但对于普通桌面软件用户来说，显然不够自然。 更符合桌面软件使用习惯的流程应该是：
打开应用 → 检查更新 → 查看版本说明 → 获取新版本v0.1.3 正在把柯影智航向这样的体验推进。应用可以检查新的软件版本，并向用户展示对应的版本更新信息，不再要求用户频繁打开 GitHub Releases 页面确认有没有新版本。当然，目前还没有实现完全静默的后台自动升级。应用更新仍然依赖 GitHub 更新仓库提供安装包，但至少从 v0.1.3 开始，柯影智航已经从过去的“用户主动寻找更新”，迈向了“应用主动感知版本变化”。 对于一个更新频率较高的桌面 AI Agent 来说，这是非常重要的一步。
03｜更新之外，我们还保留了“后悔药”
桌面软件更新并不是版本越新就一定越适合所有设备。 操作系统版本、硬件架构、运行环境甚至第三方依赖，都可能导致某个新版本在部分环境中出现兼容问题。 所以 v0.1.3 还继续完善了一个很重要的能力：版本回退。 当新版本出现兼容性问题时，用户可以回到上一版本，而不是只能等待下一次修复。 这也是我们对桌面 AI Agent 更新机制的一个基本判断：
一个完整的更新系统，不应该只考虑“如何升级”，还应该考虑“升级失败怎么办”。
Update 和 Rollback，本质上应该属于同一个版本生命周期。
04｜目前仍然有哪些限制？
v0.1.3 依然是一个非常早期的版本，因此我们也希望把目前存在的限制明确说明。 macOS 尚未完成正式签名与公证 目前 macOS 版本仍使用 ad-hoc 签名，尚未完成 Developer ID 签名和 Apple 公证流程。 因此首次运行时，系统可能出现相关安全提示。同时，目前 macOS 安装包只提供： Apple Silicon（arm64） 暂未提供 Intel Mac 版本。 Windows 尚未进行代码签名 Windows 安装程序目前同样没有完成正式代码签名。 首次运行安装程序时，可能出现 Windows SmartScreen 提示。 因此建议仅从官方 Release 获取安装包，并在安装前核对 SHA-256。 软件更新依赖 GitHub 当前应用内版本检查与安装包获取依赖 GitHub 更新仓库。 因此，如果所在网络环境无法正常访问 GitHub，软件更新功能也可能受到影响。 这些问题并不意味着 v0.1.3 无法正常使用，而是意味着： 柯影智航目前仍然处于桌面工程化建设的早期阶段。 签名、公证、多架构支持以及更加完整的软件更新体验，都将是后续版本继续推进的方向。
05｜数据和 API Key 放在哪里？
把 AI Agent 做成桌面应用之后，还有一个绕不开的问题： 用户的数据到底放在哪里？ 目前柯影智航仍然坚持一个比较明确的原则： 应用数据与软件发行相互分离。 用户配置和会话数据保存在本机，不会随着安装包上传到更新仓库。 更新仓库仅存放软件发行相关内容，不包含项目源码、用户配置文件或者 API 凭据。 API Key 同样不会被硬编码进安装程序。 模型服务仍然由用户自行配置，桌面客户端主要负责承载应用层体验。 也就是说：Koying Pilot Desktop 负责桌面交互、Agent 能力入口以及本地应用体验； 而： Model Provider 负责真正的模型推理服务。 两者保持解耦。 这样既能够让用户自主选择模型服务，也避免把敏感凭据直接绑定到桌面安装包中。