我对邮件代理唤醒时机与轮询所有内容进行了基准测试：首个切片下游tokens减少91%。

我对后台代理中的一种特定模式越来越感到烦恼。你给代理授予访问邮件、Slack、GitHub、Linear等权限。而首次实现通常是这样："每N分钟唤醒一次，检查发生了什么变化，判断是否重要。" 这在演示中没问题。但在实践中很快就变得奇怪。大多数源事件毫无意义。大多数邮件无关紧要。大多数Slack消息也不重要。但代理仍然要唤醒、阅读、总结、与用户目标对比，然后决定"无需操作"。因此下游代理把大量tokens浪费在思考本不该看到的事情上。我不想只是争论，而是想对其进行量化，于是我做了一个小型基准测试。 设置如下： - 500条合成邮件事件 - 20个自然语言触发条件 - 10,000个邮件/触发对 - 412个正面对（邮件确实应该唤醒代理） 触发条件示例： - 当投资者回复时告诉我 - 如果客户要求退款则唤醒我 - 如果供应商更改价格则提醒我 - 当邮件需要法律审查时通知我 任务很简单：给定一个嘈杂的收件箱流和一组用户定义的触发器，判断哪些邮件应唤醒下游代理。在当前的50封邮件×5个触发器的对比中，事件路由版本实现了： - 源调用次数比OpenClaw轮询基线减少68.2% - 下游代理tokens减少91.0% 这并不是说这个基准测试完美无缺。它是合成邮件，切片仍然很小。标签明确，使得问题比真实收件箱更清晰。但我认为这确实是对人们一直在含糊其辞的一类代理系统进行评估的正确形式。 问题不应该只是"代理能否完成任务？"还应该包括： - 代理是否在正确的时间唤醒？ - 是否忽略了90个无聊的事件？ - 是否避免了重复唤醒？ - 是否保留了足够的上下文以采取行动？ - 是否避免了为了说"什么都没发生"而浪费一次模型调用？ 我在仓库中把这些触发条件称为"watches"，但我关心的是将事件路由与下游代理分开衡量。因为在很多真实的代理工作流中，昂贵的部分不是最终响应，而是围绕着它的所有愚蠢检查。 好奇这里的人会添加什么作为下一个基线。我在考虑几个明显的方向： - Claude Code风格的背景会话 - Hermes风格的始终在线代理 - 唤醒更大模型前的本地模型路由器 - 使用真实收件箱导出而不是合成邮件 - 使用Slack/GitHub/Linear流而不是邮件 仓库和数据集在评论中，因为我知道这个子版块讨厌不请自来的推广帖子。我构建了这个基准测试，所以我承认有偏见。但还是请对这个评估进行批评指正。