安装弹窗关闭以后，异步操作结果应该留在哪里？

本文以 Termexo v0.10.14 的 Agent 安装服务为例，讨论界面生命周期、操作计划与失败状态。作者为项目维护者，文章由 AI 辅助整理，并依据当前源码和发布记录核对。

弹窗消失不代表操作结束

安装编程 CLI 时，用户可能会关掉设置，先去处理项目里的其他事情。如果请求状态只保存在弹窗组件中，组件销毁后便很难找回进度、结果或错误。这里需要明确两种生命周期：界面是否显示，以及安装操作是否仍在进行。

项目中的 AgentInstallService 使用应用级依赖注入，声明为 providedIn: 'root'。状态包括 stage、request、plan、result 和 error。面板负责显示和触发动作，服务负责保留操作状态。因此，关闭设置后重新打开仍能查看结果。

配图为项目公开的 v0.10.6 工作台实录，展示两个真实 Antigravity 会话；用于说明应用场景，并非本文安装面板截图。

进行中、执行成功与仍可重试

服务的 stage 为 idle、checking 或 installing。开始操作时先检查是否处于 idle，避免同时重复执行；进入 checking 后清空上一轮计划、结果和错误。

预览得到计划后，只有计划可执行且动作需要写入时，才进入 installing 并调用后端执行。无论成功还是抛错，finally 都把阶段恢复为 idle。需要注意，idle 表示当前没有进行中的操作，不等于上一轮成功；结果和错误仍要分别显示。

这一区分也适用于其他长任务。不要把“按钮重新可点”“弹窗关闭”或“请求返回”作为业务成功的替代信号。

计划复用需要有匹配条件

完成检查后立刻点击更新，不一定需要再次等待同一轮远端查询。但复用也不能只比较 Agent 名称。

当前实现的 matches 会比较 agentType、installer、targetVersion（缺省按 latest）和 workspaceId。不同安装器、目标版本或工作区，都不能直接当作同一个请求。

对于非检查动作，只有匹配的旧计划已经 ready，且 npm 安装器已有 resolvedVersion，才复用计划。后端执行时仍重新校验。前端缓存承担减少重复等待的作用，不能替代执行边界的检查。

“查不到版本”不能变成“有更新”

npm 安装计划如果标记 ready，却没有解析到可用版本，服务会给出查询失败错误，引导检查网络或代理后重试。

已安装且版本健康时，普通更新无需写入；repair 是单独的主动修复动作。这样可以区分三种情况：需要升级、已经满足要求，以及没有足够信息作判断。

v0.10.14 的使用界面相应提供重试与网络设置入口。缺少 Node.js 时先给环境安装引导，新装 npm 后可重新检测，无需重启工作台。

工具自身的升级语义不能丢掉

不是所有工具都能用“再装一次”表达更新。已安装的 Antigravity 使用官方 agy update；首次安装脚本可能跳过已有安装，所以需要分别处理首次安装与后续升级。

新版也加入了 Pi Agent 的安装启动、原生会话恢复、任务执行、状态事件与本地 MCP 集成，贡献来自 wuyh410 的 PR #33。增加 Agent 类型时，除了检测命令存在，还应检查恢复会话、任务与状态回传的链路。

可迁移的设计原则

• 把长操作状态放在能够覆盖操作生命周期的位置。
• 阶段、结果、错误分别建模，空闲不代表成功。
• 用完整请求身份决定是否可以复用计划。
• 版本未知时明确说明未知，保留重试入口。
• 执行端重新校验，界面预览不能直接视为最终事实。

本文为实现分析，没有新增性能测试或声称覆盖所有 Agent 环境组合。相关实现位于 项目源码。