[Feature] 插件 API 开放 agent 输出/生命周期事件订阅（turn/消息/任务完成 → 外部），解锁 IM 推送与自动回复 / Expose agent output & lifecycle events to plugins

[pkmcenter]

背景 / Background

实测发现 PI-Desktop 插件无法实现 weixinbot 这类集成（AI 回复自动转发到微信 + 微信下发指令驱动 agent）。pi-cli 的 extension 能完整做，但 PI-Desktop 插件 API 缺少订阅 agent 输出 / 生命周期事件的入口。这是"agent 产出 → 外部系统"（输出方向）的通用能力缺口，也正是 #100（IM / Webhook 集成）若要插件化落地的前置。

实证：核心缺口 / What I verified

在 0.14.6（Windows）逐项核对插件 API（resources/skills/plugin-development.md + 官方 agent-tool / panel 模板）：

1. 无 agent 输出 / 事件钩子。 插件 pi.agent 组只有 registerTool / unregisterTool / complete，没有任何 onTurnEnd / onMessageEnd / onTaskCompleted 订阅点。对比 pi-cli extension 的 pi.on("message_end")（weixinbot 正是用它把 AI 回复推到微信），PI-Desktop 侧没有对应物。
2. 事件单向、且监听器返回值被忽略。（与 [Feature] Plugin API：允许插件向单次请求注入 prompt 层（system / user / assistant） #172 一致）events.on() 的返回值宿主不消费；bus.publish 只在插件之间传递。二者都无法把 agent 输出导向外部渠道。
3. ~/.pi/agent/extensions/*.ts 不被加载。（[Feature] Plugin API：允许插件向单次请求注入 prompt 层（system / user / assistant） #172 已确认）sidecar 不加载 CLI 钩子，所以 weixinbot 的 message_end 逻辑在 PI-Desktop 里完全不触发。
4. 面板无法反向驱动插件进程。 webview 只有固定 pluginBridge 通道（fs.* / net.fetch / plugin.getSettings …），没有自定义 RPC，面板无法发起"扫码登录 / 拉取状态 / 触发发送"这类插件进程逻辑。
5. 后台长循环能力边界不清。 weixinbot 的 100ms 长轮询需 background.service + bus 支撑，但目前无法确认插件能维持一个与 agent 解耦的持续轮询。

案例：weixinbot（github.com/huang-x-h/pi-weixinbot，pi-cli extension）完整实现了「AI 回复自动发微信 + 微信长轮询收指令 + weixin_send/weixin_status 工具」，但因上述缺口无法移植到 PI-Desktop。

期望 / What's requested

A.（最小、最核心）agent 生命周期 / 输出事件订阅
暴露一条宿主事件管道（建议 bus topic + 对应权限），至少覆盖：

• agent.turn.completed / agent.message.completed（载荷：session/turn id + 文本或摘要 + 是否成功）
• agent.task.completed / agent.task.failed / agent.awaitingApproval（对应 [Feature] 第三方消息/通知集成：任务完成推送到 Telegram / 微信 / Slack / Webhook，并可远程下发指令 / Messaging integrations (Telegram/WeChat/Slack/Webhook) for task completion and remote commands #100 的推送场景）

await pi.events.subscribe("agent.turn.completed", async (e) => {
  // e.sessionId, e.turnId, e.text / e.summary, e.ok
});

这一条即可解锁 #100 的"任务完成推送到 IM / Webhook"和 weixinbot 的"AI 回复自动转发"。

B. 面板 ↔ 插件进程双向 RPC
允许面板触发插件进程内的具名动作（登录、扫码、状态、发送），超越当前固定 bridge 通道。

C. 插件驱动后台 agent turn
agent.complete 已有，但需要"流式 + 完成回调 + 可连续驱动"，支撑"外部指令（如微信消息）→ 发起 / 继续一个 agent turn"。

与现有 issue 的关系 / Relation to existing issues

• [Feature] 第三方消息/通知集成：任务完成推送到 Telegram / 微信 / Slack / Webhook，并可远程下发指令 / Messaging integrations (Telegram/WeChat/Slack/Webhook) for task completion and remote commands #100（IM / Webhook 集成）的底层前置：[Feature] 第三方消息/通知集成：任务完成推送到 Telegram / 微信 / Slack / Webhook，并可远程下发指令 / Messaging integrations (Telegram/WeChat/Slack/Webhook) for task completion and remote commands #100 要做"任务完成推送"，若走内置硬编码只能服务单一场景；有了 A 的事件订阅，才能被插件生态复用（微信 / Telegram / Slack / 任意 Webhook）。
• 与 [Feature] Plugin API：允许插件向单次请求注入 prompt 层（system / user / assistant） #172（prompt 注入）互补：[Feature] Plugin API：允许插件向单次请求注入 prompt 层（system / user / assistant） #172 是输入方向（往请求里加文本），本 issue 是输出方向（agent 产出 → 外部）。
• 受 [Discussion] 插件文件权限：隔离边界与设计方向 / Plugin file permission boundaries #168（插件权限）约束：新增事件订阅需对应权限（建议独立权限，如 agent.events.subscribe）+ 审计事件。

建议的最小实现 / Minimal viable scope

先做 A：一个 bus topic（agent.turn.completed 等）+ 事件载荷 + 独立订阅权限 + 审计。即可解锁 #100 的推送场景与 weixinbot 的自动回复；B / C 作为后续增量。

环境 / Environment

• PI-Desktop 0.14.6（Windows 11）
• 对照：pi-cli extension API（@earendil-works/pi-coding-agent）具备 message_end 钩子，可正常驱动 weixinbot

[Tioit-Wang]

你列的三件事分开看：A / C 正好落在两份插槽需求上，B 不在其中。

• A（turn / message 完成、成功失败、待审批）→ 插件运行时插槽需求 — 第 1–12 项（12 个运行时时机） #561 第 8 项「回合结束后读本轮（Turn Recap）」+ 第 9 项「本轮事实查询（Turn Facts）」；运行中的工具起止与输出增量 → 第 2 项「运行中观测（Turn Watch）」
• C（外部指令发起 / 继续一个 turn）→ 插件运行时插槽需求 — 第 1–12 项（12 个运行时时机） #561 第 10 项「宿主续跑（Turn Continue）」
• B（面板触发插件进程里的具名动作）是面板 bridge 那一侧的边界，两份清单里没有对应项

今天插件侧只有 events.on / bus 这类通知，撑不起「agent 产出 → 外部」这条链路。上层计划 #528；两份目前都还是需求确认稿（v0.15.0 尚未实现），落地后按上面几项的能力做就行。