长任务离开屏幕后：通知与保持唤醒应绑定哪个执行事实？

[tt-a1i]

OpenPI 已经允许后台 Terminal、Subagent 和 Workflow 继续工作。用户离开页面后，仍需要知道何时该回来；本机也可能在任务期间休眠。社区已有小插件覆盖这些需求，但它们通常以单个 Pi agent run 为单位。值得讨论的是如何复用它们的机制，又不把 agent_end 误报成整个任务完成。

本帖探索可选的外部用户体验，不承诺默认保持屏幕常亮、发送系统通知，或引入一个后台调度器。

两个具体参考

mitsupi 的 notify 扩展 在 Pi agent_end 发 OSC 777 通知，把回答转成纯文本、去除终端控制序列并限制长度。机制很小，但依赖终端支持，也没有区分后台 child、父回合、Goal 或 Workflow 的完整终态。它会把回答摘要放进系统通知，隐私选择也需要明确。仓库为 Apache-2.0；manifest 的 Pi peer 为 *，本轮未进行运行验证。

@narumitw/pi-caffeinate 在 agent_start 获取系统抑制器，回合结束或 Session shutdown 时释放；有计数、generation 与 AbortSignal 来处理异步获取和迟到回写。文档 区分 system-awake 与 display-awake，说明部分生效和不可用情形。源码 manifest 为 0.49.7、MIT、开发 Pi 0.85.0。它有模块级共享状态，尚未验证 OpenPI 同进程多 Session/child 加载的语义；不能仅凭单 Session 功能就宣称可直接组合。

建议先确定的行为

事实	用户可能需要的提醒	应避免的推断
需要用户确认/回答	回到准确 Session 的入口	不能把普通模型提问文本自动当原生批准请求
用户关注的运行失败/取消/不确定	原因与可恢复入口	不能都写成“完成”
关注的运行成功终止	一次终态提醒，可点击回到结果	父 agent_end 不代表仍在运行的 child 已结束
父回合暂时空闲，后台仍运行	保留后台事实	不自动发“全部完成”或释放仍被需要的唤醒租约
页面重连、两个标签页收到同一事件	去重或由一个展示端负责	不重复通知、不重复获得抑制器

通知可以先默认只含 Session/任务名称和状态，摘要由用户选择。权限拒绝、不支持终端、页面关闭时不能保证送达，应明确区分“事件发生”“通知已请求”“送达不可确认”。浏览器通知和终端 OSC 是展示适配层，不能成为新的执行状态来源。

保持唤醒也应由明确 owner 获取并释放，范围可能是进程内活跃运行集合。它不应唤醒已经关闭的进程，不应假装让远程主机保持运行，也不应默认阻止锁屏。

最小可证伪实验

先做 opt-in 原型或独立 companion 兼容试点，验证：父空闲但 child 活跃、两个并发 Session、失败/取消/uncertain、确认等待、切换 Session、reload/shutdown、抑制器获取未完成就取消、通知权限拒绝、后台标签页重连。判断标准是通知不失真/不重复、owner 退出不遗留抑制器、前台延迟与待机耗电可接受；不用额外模型调用生成通知。

希望讨论的问题

1. 用户更需要“需要我处理”和“关注的运行已终止”哪一种，是否应独立开关？
2. 保持唤醒是留给用户安装独立 package，还是 OpenPI 需要提供原生生命周期事实供 companion 使用？
3. 当父回合结束但 Workflow 继续运行时，通知与系统唤醒的 owner 应分别是谁？

#196 已跟踪后台 ownership、settlement 和 delivery 合同；这里限定为用户离开页面之后的注意力和本机电源行为，不重复执行调度设计。

研究记录：Pi 社区能力研究与候选清单（2026-09-08）。源码证据、运行验证与采用决策分别记录。

[tt-a1i]

2026-09-09 源码复读（/tmp clone，未 pi install、未运行）。本地记录：docs/research/EXPERIMENT_VETTER_PROVENANCE_2026-09-09.md。

冻结：mitsuhiko/agent-stuff@122e299 的 extensions/notify.ts（mitsupi 1.6.0，Apache-2.0）；@narumitw/pi-caffeinate@09d0f4d（0.49.7）。对照官方 example earendil-works/pi@6160683 的 examples/extensions/notify.ts。OpenPI a9b40f0。

必须绑执行事实，不能绑裸 agent_end。

• mitsupi notify 只听 agent_end，把最后一段助手回答（截 200 字）塞进 OSC 777。没有 child / Workflow / bg terminal 终态，也没有「已请求 / 已送达」。
• 官方 in-tree notify.ts 已经改听 agent_settled，注释写明：agent_end 会在 retry / compact / queued follow-up 时误响。正文固定 Ready for input。这是下限，仍覆盖不了 OpenPI 后台集合。
• pi-caffeinate 用模块级单例 activeTurns：agent_start +1，agent_end 减到 0 才释放，session_shutdown 清零。文档区分 display-awake / system-awake 和「部分生效」。设置写 pi-caffeinate.json，不是 /openpi-setup。

OpenPI 对照：

• Subagent 结果通道明确：父 idle / 父 agent_settled ≠ child 终止（extensions/subagents/src/result-delivery.ts）。
• Background terminals 跨父回合存活，session_shutdown 才杀进程。
• createChildResources 只过滤 pi-intercom。用户若全局装了 caffeinate/notify，child 也会加载。caffeinate 的 state 是模块级的：child session_start 会 bump sessionGeneration 并替换 currentSession；child shutdown 可能把父还需要的抑制剂掐掉。

OSC / 浏览器通知是展示适配，不能当新的执行状态源。保持唤醒的 owner 应是「进程内仍被需要的运行集合」。不默认发摘要、不默认常亮。#196 继续拥有 settlement 合同。

[tt-a1i]

2026-09-09 源码复检（未安装、未运行）。记录：docs/research/EXPERIMENT_PTY_BACKGROUND_2026-09-09.md（本地草稿）。本评论只补执行事实绑定，不把 #504 PTY 并进来，也不提议 cron 产品。

对照比 #476 开帖时多读了一份官方 example 的当前 HEAD（Pi 6160683）：

• 官方 examples/extensions/notify.ts 已改到 agent_settled，正文固定 Ready for input，并写明 agent_end 可能只是一次低层 run（retry / compact / follow-up 还会继续）。
• mitsupi extensions/notify.ts（仍是 122e299）继续挂 agent_end，并把回答摘要放进 OSC 777。
• @narumitw/pi-caffeinate 0.49.7（monorepo 1b96c32）：agent_start 计数 +1 取抑制器，agent_end 减到 0 释放；模块级共享状态。租约绑的是父 agent run 次数，不是「还有后台工作在跑」。

OpenPI 源码里，父回合可以已经 idle，同时仍有：bg_* 进程、bg_watch、in-process child、Workflow。这些才是用户离开屏幕后还需要回来 / 还需要机器醒着的事实。把通知或 caffeinate 绑到 agent_end（甚至只绑父 agent_settled）都会在后台仍跑时误报「好了」或提前放抑制器。

OSC / toast / 浏览器通知仍只是展示适配；不要变成第二份状态源。若做 opt-in companion，应对齐 OpenPI 已有的 running-set / settle / watch / ask-user，默认只带 Session/任务名和状态，不要默认塞回答正文。/openpi-setup 仍是唯一包内配置入口。不新开 Issue。