并行使用编码 Agent，先识别谁在等你

同时开着多个 coding agent，最容易浪费时间的地方，可能是没人知道它已经停了。作者在一台笔记本上并行使用六种 agent，做了一个菜单栏面板 Agent Ping，把等待确认、报错等会话状态集中展示。

它的思路很直接：从各工具已有的本地日志里找信号，把「哪个会话需要你处理」和「怎么回去」放在一起。对经常跨项目使用 AI 编程工具的人，这比再加一个任务完成通知更贴近实际问题。

窗口还在，不代表任务还活着

作者同时使用 Qoder、Claude Code、Codex、ZCode、WorkBuddy、OpenCode，处理不同项目。一次，他花了 11 分钟在某个窗口重写提示词，另一个会话却一直等着权限确认，第三个已经报错退出。

三个窗口看起来差不多：光标闪烁，输入区空着。

问题在于，窗口保留的是最后一次渲染结果。CLI 进程被杀掉后，也可能留下一副等待输入的样子。等你敲字，才发现会话历史已经没了。平铺窗口只能增加可见面积，无法补足这些状态信息。

通知也有缺口。按作者的使用经历，工具会通知任务完成，却未必通知「正在问你问题」或「因错误中止」。这两类状态恰好最需要人介入，但原文没有逐个工具列出通知行为，不能据此认定所有版本都如此。

并行使用 agent 时，需要优先暴露的是等待人工处理的会话。

日志里已经有信号，难的是统一解释

六种工具都在本地留下记录：Codex 保存 rollouts，Claude Code 保存 transcripts，其余工具使用会话存储或本地数据库。格式不同，但都能提供会话最近发生了什么的线索。

Agent Ping 读取这些记录，把会话归入五种状态，分组显示，并把「等待你处理」放在最前面。原文没有完整列出五种状态的定义，明确强调的是等待输入和报错。

面板还显示问题原文。看到具体的权限请求，你能直接判断要不要处理，不必先打开窗口查看「1 个待办」究竟是什么。

点击一行后，应用内会话回到对应应用，CLI 会话则恢复运行入口。作者把产品的最小价值概括为一行：一个会话、一个状态、一条返回路径。

这件事的难点也在这里：六种日志格式有六种表达「需要输入」的方式，其中三种工具对「报错后的会话是否仍存活」的表达还不一致。读取文件只是起点，正确解释记录才是核心工作。

它刻意少做事，但跳转仍有边界

Agent Ping 不负责分配任务或编排 agent。作者认为，一旦编排器接管流程，它也会接管对当前状态的解释；出了问题，排查对象就多了一层。只读日志的好处是，面板显示等待权限时，可以打开同一份文件核对。

作者还称整个二进制不建立网络连接，并以对发布包执行 nm -u、未发现 socket 符号作为依据。日志包含提示词、代码和文件名，因此减少数据外传路径有实际价值。部分工具保存在本地的免费额度状态也能展示，但面板最多唤起应用，领取仍由用户点击。

支持范围并不等于无缝体验：

• ZCode 没有会话级 URL，跳转依赖操作其 ⌘K 命令面板，需要 Accessibility 权限；没有权限时，只能激活应用。工作区若从未在 ZCode UI 中打开，其搜索池也找不到会话。
• Linux 的状态栏项和横幅，仅在容器中的第三方托盘宿主上验证过，没有在真实 KDE/GNOME 桌面验证；点击横幅不能导航。
• 当前只解析这六种来源，其他工具不会出现在面板中。

运行形态是 macOS 13+ 菜单栏应用和 Linux X11 托盘项，支持六种 UI 语言，采用 Apache-2.0 许可证。没有预编译二进制，Homebrew formula 从带标签的源码编译；作者称 Apple silicon 上约需一分钟，并需先安装一次 Xcode command line tools。

原文给出的安装和启动命令如下：

brew tap DreamOfXM/agent-ping https://github.com/DreamOfXM/agent-ping
brew trust dreamofxm/agent-ping
brew install agent-ping
agent-ping

注意第二行 brew trust，这是原文安装流程的一部分；这套流程也包含本地编译，并非下载后直接运行。

我的判断

我认同它把「需要人处理」放在「已经完成」前面。相比不断切窗口检查，一个能展示问题原文并返回会话的入口，更有机会减少遗漏。

但收益目前是经验之谈。11 分钟是作者的一次经历，原文没有提供安装前后的耗时对照，也没有报告状态识别准确率。作者认为同时运行两三个 agent 就开始有价值，这个门槛还取决于任务时长、确认频率和你查看窗口的习惯。

只读日志也有代价：工具改了日志格式，解析就可能失效；不同工具对错误和存活状态的定义不一致，也会影响判断。原文没有说清它如何处理这些变化。

另外，nm -u 未发现 socket 符号，可以作为检查线索，但单凭这一项不足以完整证明运行时零联网。作者的设计方向合理，证明力度仍应分开看。

能拿来做什么

• 如果你经常同时开两三个 AI 编程会话，可以先记录自己是否反复遗漏权限确认或报错，再决定是否需要集中状态面板。
• 使用上述六种工具时，可以重点检查「等待输入的问题是否准确」以及「点击后能否回到原会话」，这两项直接决定面板是否有用。
• 如果你在开发内部 AI 编程工具，可以借鉴「会话、状态、返回路径」这一行信息，并在日志中明确区分等待输入、错误和进程存活状态，降低后续接入成本。