异步与事件驱动架构

为什么同步 Agent 无法承担真实助理职责？

• 同步（Synchronous）: 做完一件事才能做下一件——像只会排队的柜台，处理完一个顾客才叫下一个号;
• 异步（Asynchronous）: 多件事可以同时进行——像秘书桌上摆着邮件、电话、来访者，按紧急程度选择先处理哪个，也可以中途切换;
• 缺口一: 异步执行是常态，长任务不应阻塞用户交互;
• 缺口二: 事件优先级需要动态判断，而非全部同等对待;
• 缺口三: 中断与恢复要流畅，被打断的对话或任务能自然接续;
• 对照: 同步模式下 Agent 要么等后台任务完成才能对话，要么等对话结束才能处理新事件;

事件驱动架构与轮询有什么本质区别？

• 轮询: 系统主动反复检查“有没有新消息”，效率低且引入延迟;
• 事件驱动: 新消息到达时自动触发处理逻辑，输入、输出、思考过程与外部交互统一建模为事件流（一条时间线上依次排列的事件记录）;
• 事件循环: Agent 可视为长期运行的循环——取出若干事件、追加到轨迹、调用一次 LLM、执行工具、回到开头等待下一批;
• 前提检查: 使用异步范式前要先确认模型与 API 是否支持该消息时序，即并发模型是否允许任务挂起、结果延后归属;
• 常见误判: 代码用了 asyncio 并不等于模型具备原生异步能力，事件来源、工具生命周期与结果归属仍要由应用管理;

OpenClaw 提供了哪些内置事件驱动机制？

机制	触发来源	作用
Hooks（事件钩子）	框架内部生命周期事件	会话创建、重置时执行逻辑，类似 GitHub Actions 触发器
Cron（定时调度器）	物理时间（cron 表达式）	周期性任务，如 0 9 * * 5 表示每周五上午 9 点
Heartbeat（心跳）	固定时间间隔	每隔 N 分钟唤醒 Agent，检查是否有需要关注的事项

• 能力外观: 三者让 Agent 在用户不在线时也能生成报告、检查系统状态、处理例行事务，形成“自主”观感;
• 消息路由: Gateway 控制平面接收多渠道消息并路由到 Agent 运行时，内置渠道（IM、Web 界面）的消息是推送式的;
• 真实边界: 只有 Cron 与 Heartbeat 能让 Agent 在没有用户消息时“自己动起来”，而两者都是时间驱动的；Hooks 的事件来源是框架内部而非外部;

纯时间驱动的机制在什么场景下会失效？

• 失效形态: 对内置渠道之外的第三方事件源（新邮件到达、外部 API 回调、紧急通知）缺少即时接入通道，只能等下一个 Cron/Heartbeat 周期;
• 案例 PineClaw: Pine AI 的 OpenClaw 插件代替用户拨打真实电话，协商账单、取消订阅、处理理赔;
• 通话中的即时需求: 客服要求验证持卡人身份时需立刻提供安全码或 OTP；客服要求与账户持有人直接对话时需用户几秒内接听；对方提出降价方案时需用户确认;
• 后果: 依赖 Heartbeat 轮询会让用户在客服等待验证码时收不到通知，导致客服挂断、通话失败;
• 解法 Channel 机制: 在 OpenClaw Gateway 与 Pine API 之间建立实时事件通道，电话接通、需要用户输入、通话结束等关键事件即时推送给 Agent;
• 结论: 真正的“主动服务”不仅要求 Agent 能定时检查事件，更要求事件能主动通知 Agent;