内容提要
作者借鉴Herdr的检测机制,用Claude Fable 5开发了tmux-agent-watch,一个只读的tmux AI Agent状态监控器。它通过进程识别、屏幕检测和规则匹配,以红绿灯显示Agent状态(卡住、工作、空闲),每两秒轮询,不干扰Agent配置。项目由AI全程完成,含51项测试,解决了多Agent管理痛点。
延伸解读
为什么事件通知不够用
文章指出,事件通知(如 Stop hook 或 IRC 消息)只能反映某个时间点的状况,无法持续更新。当 Agent 在通知后重新开始工作时,旧通知就与现实脱节,用户难以判断哪条消息仍然有效。相比之下,状态视图能实时反映当前情况,不会过期,因此更适合监控多个 Agent。
Herdr 检测机制的巧妙之处
Herdr 采用“证据驱动”的检测机制,结合进程识别、屏幕文本匹配和 Agent 主动上报。进程识别能穿透包装进程,屏幕检测通过 TOML 规则匹配终端内容,如权限弹窗或空闲提示符,并处理了历史浏览等边角情况。这种机制不依赖 Agent 自觉,从外部观察,准确且可靠。
为什么选择独立监控器而非替换 tmux
作者虽然认可 Herdr 的检测机制,但因其快捷键与 tmux 不同,操作手感不佳,且退出不便,最终决定不替换 tmux。转而开发一个只读监控器,利用 tmux 的 capture-pane 和 pane_pid 等原语,复用 Herdr 的规则文件,实现类似功能而不改变现有工作流。
AI 开发中的意外收获
在开发过程中,AI 发现作者的 shell 包装器导致进程识别失败,因为 Agent 运行在内层 tty 上。AI 当场定位并添加了子进程下钻逻辑解决。这展示了 AI 在应对环境特有坑时的灵活性,也说明即使计划周全,实际开发中仍会遇到预料之外的问题。
Q&A
tmux-agent-watch 是什么?
tmux-agent-watch 是一个用 Rust 编写的只读 tmux AI Agent 状态监控器,以树状结构展示 session → window → pane,并用红绿灯标注每个 Agent 的状态:🔴 表示被卡住等输入,🟢 表示正在干活,⚪ 表示空闲。它每两秒轮询一次,只使用 list-panes 和 capture-pane,不修改任何 Agent 配置。
Herdr 是如何检测 Agent 状态的?
Herdr 采用证据驱动的检测机制,包括:1) 进程识别:从 pane 的前台进程组出发,穿透包装进程、符号链接和 Nix wrapper 识别 Agent;2) 屏幕检测:周期性读取终端底部缓冲文本,用 TOML 规则清单匹配,规则带优先级、区域切分和布尔组合;3) Hook 上报:对支持的 Agent 安装生命周期钩子,通过 socket 汇报状态,比屏幕检测更精确。
为什么作者不用 Herdr 而选择自己开发监控器?
作者不用 Herdr 是因为它的操作手感不合意:快捷键与 tmux 不完全一致,容易按错,且退出不方便。作者认为终端复用器是“手感产品”,细微的别扭会被放大。因此,作者决定借鉴 Herdr 的检测机制,开发一个独立的只读监控器,继续使用自己熟悉的 tmux。
tmux-agent-watch 是如何实现状态检测的?
tmux-agent-watch 借鉴 Herdr 的检测机制,利用 tmux 的原语:用 capture-pane 获取可见屏幕,用 pane_title 获取 OSC 终端标题,用 pane_pid 结合 macOS 的 proc_pidinfo 进行进程识别。它复用了 Herdr 的 19 份 manifest 规则文件,并实现了语义兼容的规则引擎。
作者在开发过程中遇到了什么环境特有的坑?
作者在开发过程中发现,他的 tmux pane 里全是识别不出 Agent 的 koshell,因为他的 shell 包装器会再分配一层嵌套 PTY,Agent 实际运行在内层 tty 上。Claude Fable 5 当场定位了原因,并添加了“沿不同 tty 的子进程下钻”的逻辑来解决。
Claude Fable 5 在这个项目中扮演了什么角色?
Claude Fable 5 从研究 Herdr 源码到发布全程完成了项目,包括:研究源码、分析可行性、核实规则引擎语义和系统调用细节、制定方案、按五个里程碑实施(tmux 发现层、进程识别、检测引擎+调试工具、TUI、防抖与文档),并编写了 51 项测试,还创建了 GitHub 仓库、README 和设计文档。作者只负责提出需求、做四个决策和验收。
tmux-agent-watch 的 --explain 模式有什么作用?
--explain %N 模式可以打印出引擎看到的屏幕内容和每条规则的求值过程,帮助排查误判,非常有用。