用Claude构建tmux AI Agent状态监控工具
编辑点评 · AI 连续创业者视角（以下内容由 AI 提炼，观点归原作者；读完可不看原文）
作者为解决多窗口监控AI Agent状态的痛点，参考开源项目Herdr，利用Claude Code独立开发了一个名为tmux-agent-watch的Rust TUI工具。原文未提供商业变现数字，仅展示了技术实现过程：通过终端底层指令轮询识别Agent状态（A·实测）。对搞钱者意味着“AI辅助开发垂直小众工具”是高价值路径，适合有终端使用习惯的开发者副业。下一步可研究该工具的检测逻辑，或将其作为模板复用到其他自动化场景。
- 参考Herdr源码提炼状态检测逻辑
- 利用Claude Code完成全流程代码生成
- 解决多Agent并行时的人机协同监控
- 学习如何通过底层API实现只读监控
- 作为AI辅助开发垂直工具的参考案例
一、这是什么机会
解决多终端并行运行 AI Agent 时“需频繁切换窗口确认状态”的痛点。通过轮询 tmux 底层 API 识别 Agent 在“运行、等待输入、空闲”三种状态中的位置，以独立 TUI 工具呈现红绿灯状态视图。目前作者未明确商业收费模式，属于纯技术开源工具。
二、独立判断
值得技术团队和高级开发者研究，但直接作为独立项目商业化的空间有限。核心逻辑（从终端屏幕和进程特征推断 Agent 状态）是解决多 Agent 协作监控的刚需，但受众极窄，仅限于深度 tmux 和 CLI 用户。此机会的价值在于作为“AI 辅助开发垂直工具”的参考案例，而非产品本身。
三、冷启动路径
直接复用开源项目的检测逻辑，结合现有 tmux 环境实现只读监控。开发周期短，作者实测全流程由 Claude Code 辅助，通过 5 个里程碑完成 51 项单元测试即交付可用版本。冷启动成本极低，主要耗时在适配底层 API 及处理特定 Shell 环境导致的识别失败上。
四、最大风险与避坑
环境异质性导致误判。用户使用的 Shell 包装器（如嵌套 PTY）会使 Agent 运行在内层 TTY，标准的进程树识别会失效。应对方案是添加“沿不同 TTY 的子进程下钻”逻辑；其次，屏幕检测依赖特定 UI 特征（如权限弹窗文本），Agent 工具版本更新可能导致规则匹配失败，需保留 --explain 调试模式进行排查。
五、案例复盘（别人怎么做的）
- 产品定位与形态：不替换 tmux 运行时，开发独立只读监控 TUI。每 2 秒轮询一次，树状结构展示包含 Agent 的 pane，用红绿灯（🔴等输入、🟢干活、⚪空闲）直观指示状态。
- 核心检测引擎：直接复用开源项目 Herdr 的 19 份 manifest 规则文件（Apache-2.0 协议），实现语义兼容的规则引擎，通过读取终端底部缓冲和 OSC 标题匹配特征文本。
- 开发路径：全程使用 Claude Code 单一会话完成。先让 AI 解析 Herdr 源码机制，再逐条映射 tmux 底层原语（capture-pane 对应屏幕，pane_pid 对应进程识别），派生子 agent 核实系统调用细节。
- 实施节奏：按 5 个里程碑推进（tmux 发现层 → 进程识别 → 检测引擎 → TUI 界面 → 防抖文档），每步配备单元测试，最终 51 项测试全绿。
- 踩坑记录：初版无法识别用户特定的 koshell 包装器（嵌套 PTY 导致），AI 现场定位原因并补充“下钻子进程 TTY”的逻辑解决。
- 人机分工：开发者仅提供需求、回答 4 个决策问题（如项目命名、是否引入 hook 通道）并验收，源码阅读与工程实现全权交由 AI。
六、双轨可执行性
跨境：可作为 GitHub 开源项目建立技术影响力，间接吸引海外开发者用户；国内：可包装为 CLI 开发者的效率工具，在程序员圈层传播获取早期认可。
原文 · sjdhome：阅读原文 →
相关工具推荐（推广）：GLM Coding Plan — AI Coding Powered by G…
