阶段 7 实践 — 桌面 Harness 生命周期设计

阶段 7 实践 — 桌面 Harness 生命周期设计

本实践的产出 ⭐ 最小产出：桌面 Harness 的启动、自检、升级、失败回滚完整生命周期设计 完整产出：生命周期设计 + 会话恢复三方案对照 + 长任务形态设计 + 架构选型模板

预计投入：6～8 小时。对象直接用 Pi Agent 桌面端——它是你手上真实的、有历史包袱的产品，比虚构案例有价值得多。

实践 1 · 完整生命周期设计（⭐ 必做）

第一部分：首次启动

自检清单要求：至少 6 项，每项写清 检查什么 / 通过标准 / 失败提示 / 用户能怎么修。

必须包含的三项（来自真实踩坑）：

• "我是被谁拉起来的"——进程是否处于预期的管理方式下（避免脱离进程管理器后的静默掉线）
• 运行时依赖的实际路径（尤其是内置解释器/运行时，路径含中文或空格时的行为）
• 配置文件编码（无 BOM 的脚本、CRLF/LF、JSON 转义）

第二部分：运行期

画一张状态图，包含七个状态（创建/运行/挂起/中断/恢复/取消/完成/失败），每条边标注：

• 触发者（用户 / 系统 / 规则）
• 用户可见的表现
• 中间产物如何处理

第三部分：升级

第四部分：失败回滚

回滚方案必须是一张表，不是一句"支持回滚"：

验收标准：

• 四部分齐全
• 自检清单 ≥ 6 项，含上述三项必须
• 回滚表里每一行都写清数据版本怎么退——只写"退回上个版本"不算合格
• 整份设计能直接给研发排期

实践 2 · 会话恢复三方案对照

任务：对同一个会话，比较三种恢复方式的效果与代价。

在阶段 4 的最小 Loop 上实测：跑一个 6 步任务，在第 4 步中断，用三种方式恢复，各 3 次。

记录表：

要看到的现象：

• A 最保险但最贵，且会话长了以后不可行
• B 便宜但可能丢掉早期的硬约束（比如用户一开始说"预算 5000 以内"）
• C 最省且最稳，但要求你事先想清楚"什么必须留"——这正是产品工作

产出：一份《会话状态最小集》——列出恢复一个任务必须保留的字段，以及每个字段为什么不能丢。

实践 3 · 长任务的产品形态设计

任务：选一个真实的长任务场景，设计完整产品形态。

推荐场景："帮我扫一遍这 200 条航线下个月的最低价，找出异常波动的"（本仓有 od-lowprice-batch 技能，是真实存在的批量任务）。

要设计的六件事：

第 6 项是长任务的核心产品问题 长任务几乎不可能全部成功。把"部分成功"当成正常状态设计，而不是当成异常处理，是长任务产品成熟度的分水岭。要给出：成功的部分能不能先用？失败的部分能不能单独重试？重试会不会重复计费？

验收：

• 六项齐全
• 第 6 项有明确的界面表达与重试策略
• checkpoint 粒度有理由（太细则开销大，太粗则重跑多）

实践 4 · 架构选型模板（承接阶段 6）

在阶段 6 实践 5 的模板上，补充 Runtime 与分发相关的条目：

六、Runtime
   19. 持久化形态：检查点 / 事件溯源 / 混合？
   20. 持久化时机：退出时 / 异步 / 同步？依据是"有无副作用"
   21. 会话状态最小集是什么
   22. 长任务：checkpoint 粒度、通知渠道、部分成功表达

七、分发与运维
   23. 分发形态与目标平台（注意 Windows 成本系数）
   24. 首次启动自检清单
   25. 更新形态与更新后校验项
   26. 回滚方案（含数据版本）
   27. 诊断包：出问题时用户要提供什么

验收：拿完整模板（阶段 6 的 18 条 + 本阶段的 9 条）套一遍 Pi 桌面端，列出当前缺口清单并按风险排序。

自测

通过标志 能说出三件"只有长期运行才会暴露、Demo 阶段绝对看不到"的问题，并给出各自的产品对策。

Related Documents

• 阶段 7 讲义
• 阶段 6 实践
• 阶段 14 实践：作品集交付模板
• 学习路线