跨厂商编程 Agent 的运行状态如何统一展示

同时开着几个 AI 编程终端，最难判断的往往是「它怎么不动了」。作者在一个周二晚上并行跑着 4 个 agent，到 11:40，其中一个突然安静下来：任务完成了，卡住了，还是在等权限确认？

Agent Guild 就是为这种情况做的本地看板。它把 5 家工具的运行状态放到同一页面，还能画成不同场景里的角色。真正值得读的，是作者如何处理各家事件接口的差异，以及为什么再漂亮的可视化，也不能替你判断代码是否交付完成。

状态从哪里来，比画成什么更重要

终端只是一串持续变化的字符，没有可靠的语义标签。屏幕上的文字究竟是命令输出、求助信息，还是权限提示？靠文本形状猜，厂商改一次加载动画就可能失效。

作者因此把 hooks 作为主要数据源。所谓 hook，就是工具在特定事件发生时调用一段小程序的机制，例如一轮对话开始、命令执行、辅助 agent 启动或请求权限。

Agent Guild 启动工具时，会给它安装一个小型 reporter，把事件转换成发给本地管理器的简短消息，例如「session 12 执行了 shell 命令」「session 12 正在等权限」「辅助 agent 已结束」。

终端仍然有用，但只负责兜底：有输出流动时，卡片显示 Working；输出停止后，再回落到其他状态。这只能证明输出还在继续，作者也明确把它当作推断。

看板上层按工具展示账号、剩余额度和模型评级，下层按会话展示当前模型、工作目录，以及用字母圆圈表示的辅助 agent。

其中 Antigravity 会话显示的 reporting off 和旁边的 Why?，比一排空白更有价值。空白容易被理解成「没有辅助 agent」，实际情况却可能是工具根本不提供这些信息。

可信的看板必须区分「没有发生」和「没有观测到」。

接入五家工具，为什么不能只做字段映射

统一界面的难点，是各家上报的事件既不完整，也不等价。原文提到的工具包括 Claude Code、Codex CLI、Grok Build、Docker Agent 和 Antigravity CLI，几个具体缺口很能说明问题。

Codex CLI 会报告权限请求，却不报告命令被拒绝。因此，Agent Guild 会在这一轮结束时关闭相关命令记录，避免它永远挂在看板上。这是显示层的收尾策略，不能当成命令执行成功的证据。

Grok Build 列出了不少事件，但公开文档没有给出准确的消息结构，作者是从程序本身读出来的。它还不报告权限请求，于是「正在执行」和「等你批准」在看板上无法区分。

Docker Agent 对不需要询问就直接执行的命令，不触发执行前的工具 hook。所以在自主模式下，它的 shell 命令对这套 hooks 观测链路不可见。

Antigravity CLI 提供模型、会话和每轮回答的信息，却不提供辅助 agent 或命令信息。原文没有补充 Claude Code 的完整事件清单，无法据此逐项比较五家的覆盖程度。

这些缺口通常不会报错。用户看到某张卡片内容更少，很容易以为是 Agent Guild 坏了。作者说，约一半工作都花在把这些信息缺口明确展示出来，而不是让它们留成空白。

对程序员来说，这比统一几个字段更接近真实的多供应商接入：你还得记录每种数据是否可得，以及缺失时能作出多强的判断。

角色停下来，只能提醒你去检查

卡片适合阅读，但当作者同时打开 6 个会话时，他希望不用逐字看，也能发现谁需要介入。

于是，同一批事件又被画成 Yard 场景：每种工具对应一座建筑，每个会话是建筑外工作的角色，辅助 agent 则是更小的角色，可以表现工作、等待、空闲或结束。旁边保留名单和检查面板，双击角色能打开对应终端。

同样的会话还能换成 Goblinville Works 的工坊队伍，或 Orbital Station 的空间站成员。场景变了，数据没有增加。Grok Build 不报告权限等待，它对应的角色也无法表达这个状态。视觉设计改善的是扫视速度，作者没有提供它比卡片快多少的对照数据。

Yard 还有 VS Code 扩展，可以放在代码旁边；整页也能通过 Tailscale 在手机上访问。会话由后台管理器运行，关闭浏览器标签页不会让任务停止。

但即使每家工具都把事件报全了，仍然回答不了「工作完成了吗」。

stop 事件只表示一轮结束；session-end 是清理信号，进程崩溃时可能根本不触发；无界面运行的最终结果记录，也只说明 agent 停止输出。

停止输出是运行状态，交付完成需要验收证据。

作者给出的证据包括测试通过、pull request 已创建、CI 变绿，以及第二位审阅者没有发现问题。具体采用哪些条件，应由控制流程来决定，不能让 agent 自己宣布完成就算数。

我的判断

我认同这篇最重要的取舍：先承认可观测性的边界，再讨论界面。尤其是把「不支持上报」直接显示出来，这能减少使用者对状态的误读。

它也有适用前提。作者遇到的是多个供应商、多个会话同时运行的场景。如果日常只开一个终端，新增看板带来的收益未必明显。角色场景是否比状态列表更有效，目前属于作者的使用经验，原文没有用户研究或量化对照。

hooks 比解析终端字符更有依据，但也会受厂商事件设计影响。Grok Build 的消息结构需要从程序中读取，就说明适配维护可能依赖公开文档之外的信息；原文没有说明后续如何保证兼容。

至于测试和 CI，也只能证明已覆盖的检查通过。对前端页面，视觉效果和交互是否符合需求，仍可能需要人工验收。看板负责帮你找到该检查的会话，验收标准还得由项目自己定义。

能拿来做什么

• 如果你常在多个 AI 编程终端之间切换，可以先试着统一观察工作目录、当前模型、权限等待和辅助 agent 状态，并单独标出工具不支持上报的项目。
• 如果你在写 Node 任务管理器或 agent 面板，应把事件上报和输出活跃度分开处理。Working 可以作为活动提示，不应直接推动任务进入完成状态。
• 给日常 AI 编程任务写清验收条件，例如测试通过、PR 已创建、CI 检查通过，再按任务补上人工审阅，避免用「这一轮结束了」代替交付判断。
• 想试 Agent Guild，需要 Node.js 22 或更新版本，支持 Windows、macOS 和 Linux。原文给出的安装与启动命令如下：

npm install -g @oddessentials/agent-guild
agent-guild

注意环境要求中的 Node.js 22；原文也提供了无需安装的浏览器模拟演示，但没有给出这里可保留的具体地址。