4月10消息，Claude Code 新增 Monitor 工具，允许 Claude 创建持久运行的后台监控脚本，在检测到特定事件时自动唤醒代理。Zweben 称其为"令牌大省"，核心价值是将代理从轮询循环中解放出来——不再需要持续消耗令牌检查状态，而是由后台脚本在条件满足时主动触发代理介入。 工作原理：tail -f + grep 模式，事件驱动唤醒
从 Zweben 发布的终端演示截图来看，Monitor 工具的工作流程分三步。第一步，Claude 判断当前任务需要持续监控，主动调度一个 Monitor 实例，声明意图"dispatching a Monitor so I can keep working while it watches the log"。第二步，Monitor 以持久后台任务形式执行一条 shell 命令——演示中为 _tail -f /var/log/app.log | grep --line-buffered ERROR，即实时追踪应用日志并过滤 ERROR 级别条目。第三步，当 grep 匹配到错误输出时触发"Monitor event"，Claude 被唤醒并自动开始处理——演示中 Claude 接收到 postgres 连接拒绝的错误信息后，立即启动了对 postgres 连接失败的排查调查。
这一设计的关键在于：Monitor 运行期间，Claude 主代理可以继续处理其他工作，不产生与监控相关的令牌消耗。只有当 Monitor 事件触发时，代理才恢复介入，产生一次 API 调用。
Zweben 在推文中列举了 Monitor 的典型用途：跟踪日志中的错误（Follow logs for errors）、通过脚本轮询 PR 状态（Poll PRs via script）等。
与现有后台代理能力的区别
Claude Code 此前已支持多种后台执行机制，Monitor 工具是在此基础上的进一步特化。
从 v2.0.64 起，Agent 工具和 Bash 工具支持 run_in_background: true 参数，子代理或 shell 命令可在后台运行，完成后通过消息唤醒主代理。但这些后台任务是"执行完毕即结束"的有限任务，适合一次性的研究、构建或测试场景。
Monitor 工具的不同在于它是持久性后台任务（persistent background task），设计为长期运行——只要被监控的条件持续存在（如日志文件持续写入），Monitor 就一直活跃。它不是"完成后通知"，而是"条件匹配时通知"，本质上是一个事件监听器。
CLI 端的 /loop 命令提供了另一种周期性执行方案（如 /loop 5m check CI status），但 /loop 的每次执行都会产生完整的 API 调用和令牌消耗。Monitor 的底层是轻量 shell 进程（tail + grep），在无事件期间零令牌消耗，仅在事件触发时才唤醒代理。
这一区别对按 API 计费的用户影响显著：假设监控一个日志文件8小时，/loop 按5分钟间隔轮询将产生96次 API 调用；Monitor 模式下，若8小时内仅出现3次 ERROR，则仅产生3次 API 调用。
竞品对比
OpenAI Codex 的云端沙盒支持异步任务提交，用户可离开页面等待结果，但不支持类似的持续事件监听和按需唤醒模式——提交的是一次性任务而非持久监控。
Gemini CLI 的 Agent Skills 和 Plan Mode（v0.33，2026年3月）支持研究子代理，但官方文档中未提及后台持久监控或事件驱动唤醒机制。 社区层面，开源项目如 claude-flow 已实现了类似的后台监控代理模式（通过 spawn background-monitor 角色），但属于第三方封装而非原生工具支持。Monitor 作为 Claude Code 内置工具的优势在于：Claude 可以自主判断何时需要监控、自动选择合适的监控命令，无需用户手动配置。 局限与待观察问题
第一，Monitor 目前展示的演示仅涉及日志 tail + grep 这一模式，对于更复杂的监控场景（如 API 健康检查、数据库状态轮询）的支持范围和命令灵活度尚待文档确认。第二，Zweben 的推文是目前唯一的官方信息源，Anthropic 尚未发布完整的 Monitor 工具文档或 changelog 条目，具体参数、限制和定价影响待后续披露。第三，持久后台脚本的生命周期管理是实际使用中的关键问题——Monitor 进程在会话关闭、电脑休眠、网络断开时如何处理，演示中未涉及。第四，Monitor 事件触发的阈值和过滤逻辑完全依赖用户（或 Claude）编写的 shell 命令质量，错误的 grep 模式可能导致过度唤醒（浪费令牌）或遗漏关键事件。
AI 速览
