🤖 AI

SentinelBench: A Benchmark for Long-Running Monitoring Agents

本文介绍了 SentinelBench，这是一个包含 10 个合成 Web 环境中 100 个任务的开源基准测试，旨在评估 AI 智能体高效监测随时间演进的场景并响应外部事件的能力，从而为那些优先考虑持续注意力而非连续动作的长时程监测任务建立性能基准。

原作者： Matheus Kunzler Maldaner, Adam Fourney, Amanda Swearngin, Hussein Mozzanar, Gagan Bansal, Maya Murad, Rafah Hosn, Saleema Amershi

发布于 2026-06-05

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Matheus Kunzler Maldaner, Adam Fourney, Amanda Swearngin, Hussein Mozzanar, Gagan Bansal, Maya Murad, Rafah Hosn, Saleema Amershi

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你雇佣了一个非常聪明、动作极快的机器人助手来为你工作。大多数时候，我们期望这些机器人像过度活跃的松鼠一样：不停地奔跑、点击、检查并试图强行让事情发生。如果一个网页没有加载出来，它们就会刷新它。如果一张票还没开售，它们就会每秒钟不停地按“刷新”。

这篇论文的作者提出了 SentinelBench，他们认为这种“松鼠式方法”在处理许多长期任务时其实是错误的做法。有时候，智能体能做的最好的事情就是静静地坐着，守着门口，等待合适的行动时机。

以下是利用简单类比对他们工作的详细拆解：

1. 问题所在：“松鼠” vs. “哨兵”

想象一下你正在等待演唱会门票开售。

松鼠（当前的 AI）： 它每 0.5 秒就刷新一次页面。它消耗了大量的电力（金钱）并且感到疲惫，但它可能会因为忙于疯狂点击而错过按钮变化的精确那一秒。
哨兵（理想的 AI）： 它坐在舒适的椅子上，看着时钟。它知道销售在下午 2:00 开始。它耐心地等待。当时钟指向 2:00 的那一刻，它立即跳起来买下门票。

论文指出，目前的 AI 智能体大多是“松鼠”。它们不擅长胜任“哨兵”的工作，因为它们在等待时会浪费资源，并且经常因为缺乏耐心而失败。

2. 解决方案：SentinelBench（训练场）

为了解决这个问题，研究人员构建了一个名为 SentinelBench 的训练场。

你可以把它想象成一个巨大的、模拟的视频游戏世界，拥有 10 个不同的“房间”（比如一个虚假的电子邮箱收件箱、一个虚假的股票市场、一个虚假的音乐流媒体服务和一个虚假的招聘板）。

剧本： 在这些房间里，事件按照严格的计划发生。第 12 分钟会出现一个新的职位发布。第 40 分钟股价会达到目标值。第 30 分钟会有一首新歌发布。
测试： 智能体被赋予一个任务，例如：“等待直到有一个提到 ‘Kubernetes’ 的新职位发布，然后申请它并通知我。”
转折点： 智能体必须在一个实时变化的网站上进行导航。它不能只是读取一个文件；它必须像人类一样“观察”屏幕。

3. 两种策略：“睡眠” vs. “等待”

研究人员使用两种不同的工具测试了 AI 智能体，以观察它们如何处理等待：

工具 A：“睡眠”按钮（松鼠的午睡）： 智能体告诉自己：“我会在 5 秒后回来检查。”它停止思考 5 秒钟，然后醒来并再次检查。
- 缺陷： 如果它睡了 5 秒，它可能会错过在第 3 秒发生的事件。如果它醒来的频率太高（比如每 1 秒一次），它就会在毫无意义的情况下消耗大量资金（计算能力）。
工具 B：“Wait_for”按钮（哨兵的耳朵）： 智能体说：“我会监听是否有新邮件到达。一旦发生，请叫醒我。” 计算机在后台监控页面。一旦邮件到达，智能体会立即收到通知。
- 优势： 它不会浪费能量不断检查。它只在实际发生变化时才采取行动。

4. 他们的发现

研究人员运行了 100 个不同的任务，并使用了三种不同的 AI 模型。结果如下：

成本： 使用“等待”工具的智能体便宜得多。在某些情况下，“睡眠”型智能体的运行成本是“等待”型的 10 倍，因为它们即使在没有任何事情发生时也在不断检查页面。
成功率： “等待”型智能体通常更擅长捕捉事件。“睡眠”型智能体经常在事件发生时正好睡着，或者因为耗费了太多精力（花了太多钱）而放弃。
耐心至关重要： 当研究人员延长任务时长（将一个 10 分钟的任务拉长到 40 分钟）时，“睡眠”型智能体的表现变得更差了。它们要么过早放弃，要么花费了一大笔钱。而“等待”型智能体则保持了冷静和高效。

5. 核心启示

论文得出结论：对于长期监控任务，耐心是一种特性，而不是缺陷。

如果你想让 AI 为你监视一个网站，你不应该告诉它“不断刷新”。你应该给它一个工具，让它能够说：“我会等待页面发生变化，然后我会告诉你。” 这既节省了金钱，也节省了时间，并且能更好地完成任务。

简而言之： SentinelBench 是一个计分板，它证明了对于长周期工作，最好的 AI 智能体不是跑得最快的，而是那些知道何时静坐等待的智能体。

技术摘要：SentinelBench

问题陈述

目前的 AI 智能体基准测试主要评估在反应式环境中的智能体，在这些环境中，状态变化仅响应智能体的直接动作（如工具调用、导航）。然而，许多现实世界的任务需要的是持续的注意力而非连续的动作。在这些“监控”场景中，进展取决于独立于智能体之外发生的外部事件。默认的智能体行为——即持续轮询或强制执行动作——对于此类任务是低效的，这会导致资源（Token、计算量）的浪费，并且如果智能体无法识别何时应当等待，可能会导致错失机会。现有的基准测试缺乏系统性评估智能体在随时间演进的任务上的基础设施，这些任务中环境会自主发生变化，从而在衡量响应能力与资源成本之间的权衡方面留下了空白。

方法论

SentinelBench 基准测试

SentinelBench 是一个开源基准测试，旨在评估智能体在随时间演进的监控任务中的表现。它包含 100 个任务，分布在 10 个合成 Web 环境中（例如：电子邮件、日历、金融、职业社交、娱乐）。

环境架构： 每个环境都是一个轻量级、模块化的 React 应用程序，通过 Vite 服务器提供服务，并配备 FastAPI 后端和 SQLite 数据库。它们具有真实的 UI（如收件箱、信息流、仪表盘）并提供实时 Web 界面。
合成数据与一致性： 基准测试利用合成数据生成流水线为环境填充了 100 个用户画像和 201 个实体（公司、乐队等）。内容（电子邮件、帖子、股票价格）经过生成以确保所有 10 个环境中的世界观一致性。
事件模拟： 任务涉及随时间回放的脚本化事件序列。模拟生命周期包括：预初始化、 “就绪”状态、事件按计划发生的 “运行中”状态，以及由智能体动作或超时触发的 “完成”状态。
任务维度：
- 动作需求： 任务被归类为 被动型（观察特定条件，极少动作）、主动型（定期检查并行动）或 无操作型（条件永远不会发生；智能体不得做出错误结论）。
- 准则类型： 任务分为 绝对型（例如，“达到 2,000 颗星”）或 相对型（例如，“增加 200 颗星”），后者需要对初始状态进行记忆。
评估协议： 该基准测试与框架无关。智能体通过 shell 命令模板被调用。评估护栏负责管理模拟生命周期，注入事件并记录指标。智能体通过提交 Web 表单来发出完成信号。

基准评估设置

作者将三种模型与两种智能体工具配置进行了配对评估：

模型： GPT-5.4（低推理）、Qwen 3.5:9b（本地）、GPT-4o（旧的前沿模型）。
工具配置：
- sleep(time)： 一种标准的工具，无条件地为固定时长阻塞执行。
- wait_for(condition, timeout)： 一种专门设计的工具，通过启发式方法检测页面变化（通过文本差异），仅在发生变化时才激活 LLM，并阻塞直到满足条件或超时。

指标

SentinelBench 测量：

成功率： 基于数据库状态和智能体动作的任务完成情况。
反应时间： 目标条件发生与智能体完成任务之间的延迟。
资源利用率： 输入/输出 Token 计数及货币成本。

关键结果

性能与成本权衡

模型性能： GPT-5.4 实现了最高的成功率（使用 wait_for 时为 75%，使用 sleep 时为 68%），显著优于 GPT-4o 和 Qwen 3.5:9b。
工具效率： wait_for 工具与 sleep 相比，始终能降低成本。对于 GPT-5.4，使用 wait_for 的任务中位成本降低了 5.1 倍（ $0.23 对比$ 1.17）。
任务时长影响： 当任务时长通过 speed_factor 延长至 40 分钟时，成本差距进一步扩大。使用 sleep 的 GPT-5.4 智能体成本增加了 9.7 倍（ $4.65 对比$ 0.48），且完成的任务减少了 13 个（56% 对比 69%）。
反应时间： 结果褒贬不一。使用 wait_for 的 GPT-5.4 中位反应时间略慢（51.7s 对比 42.3s），但对于 GPT-4o 和 Qwen，使用 wait_for 的速度明显更快。
失败模式： 使用 sleep 的智能体经常在 “无操作” 任务中因过早得出结论而失败，而使用 wait_for 的智能体在区分 “等待” 与 “放弃” 方面更具鲁棒性。

核心贡献

SentinelBench 基准测试： 首个专门为随时间演进的监控任务设计的开源基准测试，包含 10 个合成环境和 100 个多样化场景。
方法论框架： 一个灵活的评估协议，将智能体与浏览器框架解耦，从而能够测量非反应式环境中的响应性、成本和成功率。
实证证据： 证明了智能体设计选择（特别是等待策略的选择）对可行性有着巨大的影响。本文指出，连续轮询对于监控任务通常是次优的，而专门的工具（如 wait_for）可以在保持或提高成功率的同时大幅降低成本。
基准数据： 为三种不同模型建立了性能基准，凸显了当前前沿模型与高效长程监控需求之间的差距。

重要性与主张

论文声称 SentinelBench 通过将关注点从“智能体如何行动”转向“智能体何时行动”，填补了智能体评估的一个关键空白。作者认为，随着智能体被部署到长程任务中，等待、监控和响应的能力变得与执行工具的能力同样重要。

结果表明，“连续行动”范式对于监控任务而言是一种负担，会导致不必要的 Token 消耗以及潜在的任务失败。通过提供一个受控环境来衡量响应能力与成本之间的张力，SentinelBench 使得对智能体策略的系统性研究成为可能。论文得出结论，未来的智能体开发必须优先考虑效率和耐心，超越简单的反应循环，转向能够处理异步、随时间演进环境的架构。作者发布了所有代码、环境和数据生成流水线，以促进该领域的复现性研究。