观测：了解发生了什么
观测让宿主了解调用和资源操作的过程，例如工作已经启动、调用了哪个工具、最终如何退出。作者可以按需要安装或订阅；没有 Recorder，框架仍然执行工作，实体仍然持有内容。
设计界面或日志时，先区分要交付的业务内容、要了解的过程，以及要保留的记录。它们可能出现在同一屏幕上，却有不同的数据来源和完成含义。
选择合适的出口
| 需要 | 使用方式 | 含义 |
|---|---|---|
| 取得最终答案 | await runner.run(...) | 本次入口最终交付 |
| 展示业务增量 | runner.output.subscribe | Scene 输出，需要业务显式产生或转发 |
| 查看运行过程 | runner.observation.subscribe | 调用、资源与入口等固定元数据 |
| 保留可查询记录 | 可选 Recorder 与记录安装 | 将明确事实投影到记录实体 |
输出和观测订阅可跨多次运行存在，取消订阅不取消执行。输出增量不自动收集全部子节点内容，也没有默认历史回放。观测出口不默认携带输入输出正文或原始错误，应用可据其元数据展示进度。
记录是独立的内容
Recorder 管理记录实体；自动记录预设消费真实调用和资源事实，作者也可以通过资源写入自定义记录。记录保留什么、保存到哪里、如何解释，由相应安装和实体契约决定。调用记录不替代便签正文，历史 running 记录也不能证明某个进程仍在运行。
记录和恢复各有依据。记录便于查看和解释，CP 使用正式调用事实与显式恢复声明。保存展示文本不会自动获得恢复资格。
通知不能替代效果确认
实体内容落实、调用接纳和观察者收到通知，是不同边界。写入后观察失败，实体内容仍可能已经存在；没有收到通知也不能证明操作没发生。普通被动订阅隔离消费者故障，必要捕获和严格机制观察则有自己的失败语义，安装时需要明确选择。
不同来源还有各自的身份和顺序：调用序号、实体版本、交互变化不构成一个全局事务。需要跨端展示时，应保留来源与准确关联，形成应用自己的交付协议。
回到便签助手
教程里的 onRead/onWrite 是成功操作后的宿主日志，events 数组用于检查示例行为；它们没有安装正式 Recorder，也没有完整的观测历史。最终回答来自 runner.run，实际新增便签来自 Notes 写入结果。将这两类内容分别展示，用户才能看到助手说了什么、实体实际保存了什么。