# 聊天轮询模式
SUMMARY: 如何在工具调用之间轮询人类消息而不阻塞工作流。

聊天轮询模式
聊天系统是异步的 — 人类可以在你工作时留言。本模式展示如何在轮询消息时不阻塞工作流。
模式
[CODE BLOCK]
在工具调用之间轮询，而不是在紧密循环中轮询。
为什么在工具调用之间轮询？
- 不要阻塞 — 紧密循环轮询浪费 API 调用
- 不要错过消息 — 轮询太慢意味着响应迟缓
- 最佳点 — 每 30-60 秒轮询一次，或每次工具调用后
实现
基本轮询
[CODE BLOCK]
模式 1：每次工具调用后轮询
[CODE BLOCK]
模式 2：基于时间的轮询
[CODE BLOCK]
模式 3：事件驱动（用 Webhook）
如需实时通知，注册 Webhook：
[CODE BLOCK]
然后你的 Webhook 处理程序可以唤醒 Agent：
[CODE BLOCK]
消息处理模式
模式：先确认后处理
[CODE BLOCK]
模式：排队批量处理
[CODE BLOCK]
模式：优先级路由
[CODE BLOCK]
轮询频率
| 用例 | 频率 |
|----------|-----------|
| 交互式 Agent（人类在等待） | 每 5-10 秒 |
| 后台 Agent | 每 30-60 秒 |
| 批处理 | 每 5 分钟 |
| Webhook 触发 | 不轮询 — 用 Webhook |
> [!WARNING]
> 频率超过每 5 秒一次会浪费 API 调用。 在有待处理消息时会立即返回，因此更快轮询无益。
多 Agent 聊天
用于 Agent 之间通信：
[CODE BLOCK]
最佳实践
> [!TIP]
> - 在工具调用之间轮询 — 不要紧密循环
> - 立即确认 — 让人类知道你收到了
> - 异步处理 — 不要在长任务上阻塞
> - 实时场景用 Webhook — 轮询有延迟
> - 不要超过每 5 秒一次 — 浪费 API 调用
常见问题
消息丢失
-  会自动把消息标记为已读
- 如果你不处理，它们就消失了
- 修复： 始终在返回前处理消息
重复回复
- 如果处理程序崩溃，可能回复两次
- 修复： 让处理程序幂等（检查是否已回复）
响应缓慢
- 每 60 秒轮询意味着最高 60 秒延迟
- 修复： 每 10-30 秒轮询，或用 Webhook
下一步
- Chat API
- 会话启动模式
- 错误恢复