Claude Code 在最新的 v2.1.98 版本里加了个功能叫 Monitor，能让 Agent 在后台挂一个监控脚本，有事才醒，没事不动。

Claude Code Monitor tool

这个功能解决的，是一个 AI 编程工具里由来已久的痛点： 轮询。

01先看效果

官方演示视频里，用户对 Claude Code 说了这么一句话：

“ 我刚部署了 API，帮我监控一下日志里有没有报错。

展开剩余90%

“ 我刚部署了 API，帮我监控一下日志里有没有报错。

用户输入监控指令

Claude 的回应是：「 收到，我先派一个 Monitor 去盯着日志，自己接着干别的活。」

Claude 启动 Monitor 后台任务

然后就出现了两个窗口。

左边是 Claude Code 的主界面，光标闪烁，等着用户下一个指令。右边是一个后台终端，跑着这条命令：

●●●

tail -f /var/log/app.log | grep --line-buffered ERROR

└

日志在右边不停地滚，INFO、DEBUG、WARN……一切正常。

后台终端持续监控日志

直到某一刻，一行红色的报错突然冒了出来：

ERROR db: connection refused to postgres:5432

后台终端检测到数据库连接错误

Monitor 立刻触发事件，左边的 Claude Code 主窗口弹出一条黄色提示：「Monitor event — errors in app.log」。

紧接着，Claude 自动开始排查：「检测到日志中的错误，正在调查 Postgres 连接失败的原因。」

Claude 自动开始排查错误

从部署到发现问题到开始排查，人类全程，不需要动一下子键盘。

02轮询之痛

为什么这个功能，会让我感到兴奋呢？

因为在此之前，想让 Claude Code 监控点什么东西，它只会一个办法： 不停地问。

想跑个测试？每隔几秒 cat一下日志。

等 CI 跑完？反复 curl查状态。看 PR 有没有被 review？隔一会儿就 gh pr view一次……

要么就常见的 sleep 600 & ...，但这个 600 或 60，真的是纯纯拍脑袋，非常之不严谨！

这就是定时，或者叫轮询，polling，很初级，难用。

而在一些长时间运行的 Agent 工作流里，光是用轮询就能吃掉 80% 以上的 token 预算。

相当于你雇了个人盯服务器，他什么也不干，就每 10 秒跑过来问你一次「 好了没？好了没？好了没？」

烦死了……

轮询 vs 事件驱动对比

而 Monitor 的做法，是把这个模式彻底反过来：不轮询，而是监听。写一个后台脚本，安安静静地跑着，有事了才叫 Agent 起来。

用技术术语说，就是从 polling 变成了 event-driven。

从管理角度来看，这也可以说就是 积极主动（见高效能人士七个习惯的第二个习惯）。

不要让主管反复来问你“搞好了没有”，否则主管会累死；而是要“事件驱动”——你完成了一个事儿就主动去说，碰到问题、碰到风险及时反馈。

好的人和好的 AI，就是这么的雷同！

03怎么用

目前 Monitor 需要你在提示词里明确告诉 Claude Code 去用它。

比如这样：

“ 启动我的开发服务器，然后用 Monitor 监控有没有报错。

“ 启动我的开发服务器，然后用 Monitor 监控有没有报错。

Claude Code 收到这种指令后，会自动生成一个监控脚本，扔到后台跑。脚本本身是个持久的后台任务（persistent background task），不会因为你继续和 Claude 聊天而中断。

它的工作原理是：脚本的每一行输出都会实时流回给 Claude。Claude 把每一行当作一个事件来处理，一旦发现匹配的内容（比如日志里出现了 ERROR），就会中断当前对话，主动介入。

Monitor 工作流程

如果大量使用 Claude Code 进行过 coding，你就会知道，这个「唤醒」机制其实非常的关键。

它意味着 Agent 不需要一直保持活跃状态来等待事件，省下来的 token 和计算资源相当可观。

04能盯什么

从官方演示和社区反馈来看，Monitor 至少能覆盖这些场景：

• 日志监控：盯着应用日志，出现错误自动排查。就是上面演示的那个场景

• CI/CD 状态：让 Claude 写个脚本定期检查 PR 的 CI 状态，跑完了再通知

• 开发服务器：启动 dev server 之后让 Monitor 盯着，编译报错了自动修

• 数据库变更：监控 migration 是否执行成功

• 部署验证：部署完之后盯一段时间，确认服务稳定

而有人，已经把它和 hooks 功能组合在一起用了。

之前需要写一个 PostToolUse hook，让每次 bash 命令执行完都去检查一遍输出，现在 Monitor 可以直接替代这种做法，按需触发，不用每次都查。

也有人把它集成到了后台 Agent 的自动化工作流里，部署完自动挂上 Monitor，出了问题自动修，修完继续跑。

05三兄弟怎么分

说到这里，可能你想问了：Claude Code 之前不是已经有 /loop和 /schedule了吗？Monitor 跟它们到底有啥区别呢？

我们之前分别介绍过这两个功能（、），这里把三者放一起对比。

/loop是闹钟。你告诉它「每 5 分钟检查一次部署状态」，它就老老实实每 5 分钟醒来一次，不管有没有事。跑在本地终端里，终端一关就没了。适合短期、高频、需要持续巡检的场景。

/schedule是管家。跑在 Anthropic 的云基础设施上，你关了电脑它照样到点干活。适合每天早上自动同步 PR、每周生成变更报告这类周期性的维护任务。我们之前管它叫「云端龙虾」。

Monitor是看门狗。它不按固定节奏醒来，而是安安静静地盯着一个数据源，只有出事了才叫。

打个比方：

/loop是你雇了个保安，每 5 分钟巡逻一圈。/schedule是你请了个钟点工，每天早上 9 点准时来打扫。Monitor 则是你装了个烟雾报警器，平时一声不吭，着火了才尖叫。

/loop vs /schedule vs Monitor 三兄弟对比

三种工具的 token 消耗差异也因此拉开了。

/loop每 5 分钟跑一次，一小时就是 12 次调用。如果什么事都没发生，那 12 次全是浪费。/schedule好一点，频率通常更低（每天一两次），但每次触发都会跑完整的任务流程。

而 Monitor 可能一整天都不触发一次，但一旦触发，带着的信息就是关键的，该花的 token 一个不少。

用哪个，取决于你的问题是「定时需要做什么」还是「出事了需要处理什么」。

前者用 /loop或 /schedule，后者用 Monitor。

当然，你也可以组合使用：用 /loop定期跑测试，用 Monitor 盯着日志抓异常，用 /schedule每天生成汇报。三个工具各管一摊，互不打架。

06注意

从社区早期使用的反馈来看，有几个点值得留意。

Agent 不会自动想到用 Monitor。你得在 prompt 里明确提到它，比如「用 Monitor 监控」或者「use the MonitorTool to observe」。如果你只是说「帮我盯着」，Claude 大概率还是会用老办法去轮询。

另外，Monitor 的触发机制取决于你让 Claude 写的那个脚本。如果脚本写得太粗（比如 grep ERROR匹配到了不重要的日志），可能会频繁误触发。写得太细……又可能漏掉问题。

这其实也是 event-driven 架构的经典挑战：事件的粒度，决定了系统的有效性。

还有一点，Monitor 目前主要适合本地开发场景。如果你的日志在远程服务器上、在 Elasticsearch 里、在 CloudWatch 里，那还得配合其他工具把数据拉到本地才行。

另外，Monitor 使用的权限规则和 Bash 工具一样，你给 Bash 配的 allow/deny 策略也会作用于 Monitor。

目前这个功能只在 Claude Code CLI 里可用，Amazon Bedrock、Google Vertex AI 等托管平台暂时还用不了。

07信号

Monitor 这个功能单独看，其实就是个事件监听器，技术上没什么复杂的。

但把它放到 Claude Code 最近一系列更新的脉络里看……hooks、background agents、skills，现在又加上 monitor，方向就更清晰了。

Anthropic 在做的事情，是让 Claude Code 从一个「对话式编程助手」，变成一个能在后台持续运转的工程系统。

以前你得一直坐在终端前面跟它对话，现在你可以部署完就走，它自己盯着，有事叫你。

这不像是在做一个更聪明的 chatbot。

更像是在做一个不下班的同事。

◇ ◆ ◇

发布于：北京市