今天早上你开了三个编程 Agent。一个在重构鉴权模块，一个在写测试，一个在追一条不稳定的 CI 任务。一小时后，你开着五个终端、两个 detach 的 tmux 会话，心里发毛：要么早就停了，要么一直空转，而你没看见。你 alt-tab、翻日志、猜。
这种猜，才是并行跑 Agent 的真实成本。同时启动几个编程 Agent 现在已经很容易。难的是知道哪一个需要你、哪一个卡住了、哪一个悄悄做完了，这部分会吃掉整个下午。监控并行编程 Agent，就是在不打开五个窗口的情况下回答四个实时问题：每个 Agent 在做什么、做到哪了、被什么挡住、有什么结果回来等人审。
这篇先走一遍自己动手的监控方案，指出每一步的失败模式，再说明它在哪儿开始不够用，以及一层共享任务能补上什么。这层共享就是 HiFox：你已经有了编程 Agent，HiFox 把每个 Agent 的进度、阻塞和结果放在一个地方，让它们像一支团队，而不是散落在各个终端。大部分监控你可以手工搭出来。两边都走一遍，是为了让你清楚知道手工版从哪一刻开始，花掉的比省下的多。
值得盯的四个信号
监控不是一件事。人们说一次 Agent 运行「看起来没问题」，通常指的是四个独立信号之一，而每个信号的失败方式都不一样。
- 状态。进程是在跑、在等输入、已结束，还是死了？做完的 Agent 和卡死的 Agent 都不再产生新输出，所以光看沉默什么都说明不了。
- 进度。任务完成了多少？计划里勾掉了几步、碰了哪些文件、测试过了没有。进度才能告诉你一个运行中的 Agent 真的在往前走，而不是在打转。
- 阻塞。Agent 在等什么？权限提示、缺一个环境变量、合并冲突，还是它问了一个没人回答的问题。
- 待审产出。Agent 产出了什么，需要人来接受或拒绝？一份 diff、一个 PR、一份改动摘要。
只看状态，你会漏掉正在跑却卡在重试循环里的那个。只看进度，你会漏掉二十分钟前就做完的那个。监控方案必须把四个信号、每个 Agent，一眼摆出来。
第一步：手工监控，以及每一步漏在哪
手工方案用的都是现成工具。下面是诚实的版本，以及每一步留下的缺口。
看什么在跑。如果每个 Agent 在自己的 git worktree 里运行，列出 worktree 和分支：
git worktree list
tmux ls # 每个 Agent 各跑在一个 tmux 会话里
失败模式：这只告诉你会话存在，不告诉你里面的 Agent 是在干活还是在等。一个卡在 Continue? (y/n) 的 tmux 会话，和正在干活的会话看起来一模一样。你得接进去才知道。
看进度。跟踪每个 Agent 的输出，轮询它的 worktree 有没有变化：
tail -f /path/to/agent-1.log
watch -n 5 'git -C ../wt-auth status --short'
失败模式：这随 Agent 数量线性变难。三份日志还能读，六份交错的日志就不行了，而 watch 循环给你的是文件在变，不是意义。你看到文件在改，却不知道改得对不对，也不知道 Agent 是不是在重复自己。
盯完成信号。给每个 Agent 包一层，进程退出时通知你：
your-agent-command "$TASK"; \
curl -s -X POST "$WEBHOOK_URL" -d "agent-1 exited $?"
失败模式：退出码 0 只说明进程结束了，不说明活干得好，甚至不说明干完了。很多 Agent 在问了一个你没看见的问题之后，也会干净退出。一个「完成」通知会训练你去信任一个并不代表完成的信号。
发现冲突。当多个 Agent 共用一个仓库时，worktree 把工作目录分开了，但两个 Agent 在两个分支上改同一个文件，合并时照样会撞。
git worktree list --porcelain | grep branch
失败模式：你要到合并时才知道重叠，而那是最贵的发现时机。
这些做法本身没错。两三个 Agent 跑互不相关的任务时，几个 tmux 会话加一个 watch 循环就是合理的监控，不必上更重的东西。在撞墙之前，能少一个部件就少一个。
手工监控从哪儿开始不够用
墙出现在 Agent 多到一块屏幕放不下的时候。三个失败会叠加：
轮询告诉你状态，不告诉你原因。git status 和日志尾巴能告诉你东西变了，或者输出停了。它们分不清 Agent 是卡在提示上、缺依赖，还是已经做完。你最后只能一个个接进会话去诊断，而这正是并行本来想省掉的切终端。
没有共享状态。你的监控活在你的笔记本、你的 tmux 服务、你的 shell 历史里。同事看不到哪个 Agent 负责哪个任务，你合上盖子之后也看不到。当 Agent 跑在远程机器上，本地跟踪日志的办法就完全失效。
审阅变成瓶颈。这一点最容易被低估。如果审阅又把它们串回一条队列，并行跑 Agent 就没有用。五份做完的 diff 没有一个共享的地方记录「已审 / 要求修改 / 已合并」，就是五个浏览器标签加一条脑内备忘。Agent 变快了，人变慢了。
到那时，你缺的不是更多终端，而是一份共享记录。
任务看板补上什么：结果回到一个地方
任务层把监控的单位从「面板里的一个进程」变成「一个有状态的任务」。HiFox 正是围绕这个转变做的，也直接对上了四个信号。
把 Agent 接到任务上之后，这次运行的状态、进度、阻塞和结果都回到该任务的时间线，而不是只活在一个只有你能看的日志里。你不用轮询，而是看一块看板：哪些任务在进行中、哪些被阻塞、哪些做完在等你。HiFox 会把卡住或失败的运行推进收件箱，把等你回复、等你审阅的交接集中在主侧栏的「对话」里，问题就从「有东西做完了吗」变成「这里有哪些需要我决定的」。Agent 调研、执行、测试、汇报；人定方向、授权、验收结果。自动化停在需要判断的地方。
这条边界很重要，因为很容易误会：HiFox 不写代码，也不替代 Claude Code、Codex 这些执行器；它负责在已连接的电脑上调度这些 Agent 运行，并在它们周围加上共享的任务、上下文和审阅层，让一次运行的进度和 diff 从提出到交付都落在全队看得见的地方。开启隔离运行时，每个任务有自己的 worktree，改动不会直接写进同一个目录；但两个任务改同一个文件，合并时仍可能冲突，所以要在审阅阶段尽早看文件重叠。
诚实的判断规则：如果你只跑一两个互不相关的 Agent，也从不交给别人，手工监控就够了，HiFox 是额外开销。当 Agent 数量超过你的屏幕、工作跑在你不在的机器上，或者别人也需要看同一块看板时，等式就变了。如果你想继续用多个编程 Agent，而不是绑定一个生态，这块共享视图正是 HiFox 要解决的问题。想知道这块看板还该展示什么，可以读 AI 编程 Agent 看板到底该展示什么。
今天就能用的监控清单
不管你是继续手工搭还是换成共享层，一个并行 Agent 监控应该在不接进任何会话的情况下回答这些问题：
- 每个 Agent 都对应一个有名字的任务。没有匿名的「agent-3」。你应该说得出每一个是干什么的。
- 状态一眼可见。运行中、等输入、已完成、已失败，分得清，不靠沉默去猜。
- 被阻塞的 Agent 会举手。等
y/n的提示、缺的密钥、没人回答的问题，会浮到你面前，而不是悄悄停住。 - 完成意味着可审，不只是进程退出。一次完成的运行要指向 diff 或 PR，而不只是一个退出码。
- 审阅有自己的状态。已审、要求修改、已合并都被记录，并行工作才不会塌回一次一个的审阅队列。
- 视图能扛住合上笔记本，也能共享。状态不只在你的 shell 历史里。
- 同仓库的工作是隔离的。每个 Agent 有自己的 worktree，文件重叠在合并前就暴露，而不是合并时。
拿这张清单对照你现在的配置。今天勾不上的行，就是以后会让你赔进一个下午的行。如果你已经在跑多个 Agent，HiFox 给你一个地方管理它们的任务和结果。你也可以把现有的编程 Agent 接到 HiFox 里跑，继续用你原来的运行时。
HiFox
