Claude Code 推出 Monitor 功能，帮你随时盯梢

📝

Claude Code 新增 Monitor 工具，能在后台挂监控脚本、事件驱动唤醒 Agent，告别轮询式 token 浪费

原文链接：https://mp.weixin.qq.com/s/9FxcKbvJJcMVtnSdgUcZ8w

Claude Code 新增 Monitor 工具，能在后台挂监控脚本、事件驱动唤醒 Agent，告别轮询式 token 浪费。

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

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

先看效果

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

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

用户输入监控指令
Claude 的回应是：「收到，我先派一个 Monitor 去盯着日志，自己接着干别的活。」

Claude 启动 Monitor 后台任务
然后就出现了两个窗口。

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

1
2
3

●●●
`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 监控有没有报错。

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 介绍 Claude Code 推出 /loop 无限循环，一台电脑即可化身无数小龙虾、/schedule Claude Code 推出云端龙虾：/schedule 命令让 AI 自己排班干活），这里把三者放一起对比。

/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。

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

◇ ◆ ◇