AI Agent 任务假死与进度紧盯调研技术

内容大纲一、执行摘要（Executive Summary）1.1 一段话总结1.2 三句话定位三个项目1.3 全文 6 条结论（先看这里就够了）二、TL;DR 速查表2.1 项目速查（用 30 秒决定用哪个）2.2 解决"假死"能力分层速查三、背景：什么是"AI Agent 任务假死"3.1 假死（Walking-Dead State）的定义3.2 假死 vs 崩溃 vs 死循环3.3 为什么传统监控失效——信号分层原理3.4 Liveness ≠ Progress：信号映射表四、Paperclip：把 Agent 编成公司，靠心跳 + 调度器解决假死4.1 定位4.2 核心架构4.3 9 步心跳协议（核心契约）4.4 4 种唤醒触发器4.5 原子任务签出（解决撞车）4.6 active-run-watchdog：独立进程的孤儿恢复4.7 预算硬停（解决烧钱循环）4.8 Paperclip 对其他 Agent Runtime 的封装五、OpenCode：Agent Runtime 自身的事件流 + 插件生态5.1 定位5.2 OpenCode 事件流全景5.3 事件类型与用途映射5.4 子代理可见性问题的核心矛盾5.5 四个代表性的侧栏监控插件5.6 opencode-agents-monitor 的五态状态机5.7 opencode-subagent-magazine 的"手动兜底"5.8 opencode-agent-pulse 的"通知模型"5.9 Better-OpenCodeMCP / opencode-autopilot / opencode-dashboard5.10 OpenCode 自能做什么、不能做什么六、Pi：最薄 Agent Harness 的取舍6.1 定位6.2 Pi 的设计栈6.3 设计哲学：刻意不做的事6.4 假死检测在 Pi 上**几乎完全交给上层**6.5 Pi vs Claude Code 横向对比6.6 为什么 Pi 的取舍有价值七、横向对比7.1 一次性对比表（再贴一次，便于本节传阅）7.2 三个项目的角色关系图7.3 按场景选型决策树八、关键技术范式总结范式 1：信号分层（Liveness / Health / Progress / Ownership）范式 2：Watchdog 必须独立进程范式 3：检查点必须语义化（Semantic Checkpoint）范式 4：心跳必须挂在工作循环（Work-loop Heartbeat）范式 5：预算硬停 + 双信号时间窗口范式 6：幂等重入 + 原子签出8.7 7-State 状态机（业内参考实现）九、实践落地建议9.1 场景 A：单开发者本地用 OpenCode + Pi 写代码9.2 场景 B：团队 24/7 多任务调度9.3 场景 C：长任务（2h）必须能 resume9.4 场景 D：自己造轮子——最小可用 progress monitoring十、风险与未解难题10.1 还没人解决的问题10.2 Paperclip 自身风险10.3 OpenCode 生态风险10.4 Pi 生态风险十一、参考资料11.1 一手项目11.2 任务假死研究11.3 实践指南11.4 Paperclip 工程材料一、执行摘要（Executive Summary）1.1 一段话总结任务假死（Walking-Dead State）的本质不是"Agent 进程是否存活"，而是liveness/health/progress/ownership四层信号分不清楚的问题。三个项目用完全不同的方式回应这个问题：Paperclip把答案工程化成一套完整的"公司 OS"（wake queue + heartbeat + watchdog + atomic checkout + budget hard-stop），OpenCode把答案拆成事件流 + 插件生态，Pi主动把答案外包给上层（典型就是 Paperclip 的pi_localadapter）。1.2 三句话定位三个项目项目一句话定位关键工程资产Paperclip“如果它能接收心跳, 它就是员工”—— AI