事件触发工具与用户沟通工具
事件触发工具在工具分类中处于什么位置？
- 定义: 外部事件驱动 Agent 行动的入口，调用方向与感知、执行、协作三类工具相反;
- 对比: 感知、执行、协作工具都由 Agent 主动调用；事件触发工具由世界的变化驱动 Agent 开始执行;
- 缺失后果: 没有它，Agent 只能连续循环思考、调用工具、输出结果，然后等待用户下一句输入;
- 所属框架: 第一章五类工具中的事件触发工具与用户沟通工具均依托异步架构发挥作用，完整分类见 观察与动作空间;
三类事件触发工具各自适用什么场景？
| 工具 | 处理的事件 | 典型用法 |
|---|---|---|
定时器 set_timer | 依赖物理时间的事件 | 发邮件未获回复后过一段时间追问；非工作时间致电失败后改到下个工作时间再拨 |
后台任务监控 monitor_shell | 异步执行的工具或命令行任务 | 监控命令行新增输出或含特定关键词的输出 |
外部事件通道 connect_channel | 新邮件、API 回调、IM 消息 | PineClaw 的 Channel 实时推送电话事件 |
- 一次性定时器: 有明确时间点的任务，如周六设置“下周一 10:00 致电银行房贷部门”;
- 循环定时器: 周期性任务，如每小时检查服务器健康；也用于外部服务不支持推送、只能主动查询进展的场景;
- 系统化实现: OpenClaw 的 Heartbeat 是循环定时器的系统化形态，也是其“主动服务”能力的根源;
- 后台监控的取舍: 让 Agent 死盯命令行会浪费大量 token；等任务完全结束再思考则无法及时发现严重问题，甚至在命令行卡死时无法介入;
- Claude Code 的 monitor 工具: 允许 Agent 只监控命令行的新增输出或包含特定关键词的输出;
事件触发工具的设计要求是什么？
- 触发条件: 定义清晰的触发条件与过滤规则，避免无关事件唤醒 Agent 浪费算力;
- 事件载荷: payload 应包含足够上下文，减少 Agent 被唤醒后还需额外查询的次数;
用户沟通工具与执行工具有什么区别？
- 定义: Agent 主动与用户建立连接并传递信息的工具——文字消息、语音通话、邮件;
- 与执行工具的分界: 执行工具改变世界，用户沟通工具专注信息传递;
- 传统范式: Claude Code、Manus 等采用原生 ReAct 循环，Agent 的 assistant 消息直接发给用户，用户必须在应用中打开指定会话，并能看到工具调用过程;
- OpenClaw 的突破: 用户无需感知会话存在、无需关心工具细节；双方都可随时给对方发消息，而非“用户发一条、Agent 回一条”;
- 实现方式: 不直接呈现模型输出，而是用专门工具发送消息，消息可附带图片与文件，并按紧急程度附加推送提醒;
- 观感: 这种异步文本沟通被人评价为具备“活人感”，像秘书一样工作;
- 多模态沟通: 结构化卡片消息、提醒邮件；生成式 UI（Generative UI）用 HTML 等方式生成交互式界面展示信息;
通知机制如何同时承担用户召回？
- 定位: Agent 的响应不应局限于单一渠道，通知机制同时也是用户召回机制;
- 渠道集合: 即时通讯、短信、邮件、电话、推送;
- 渠道选择依据: 紧急程度、用户状态、内容性质、用户偏好综合决定，既不错过重要消息，又避免重复打扰;
- 长任务: 完成时主动通知用户，召回注意力;
- 周期性任务: 每日总结、周报等通知帮助用户建立固定的交互习惯;
- 设计要求: 支持异步消息模式（用户不一定在线）、提供已读/未读状态追踪、多渠道场景下保持消息一致性;
- 衔接: 触达渠道确定后，Agent 以什么身份出现在渠道上、在什么环境中代用户操作，属于 虚拟身份与隔离执行环境 的问题;