单图标瓶颈
想象一下你在进行高强度编码时的屏幕。在一个终端标签页中，Claude Code 正在重构一个 React 组件。在另一个标签页中，Codex 正在重写一个 Python 模块。第三个智能体正在生成单元测试，第四个正在等待 API 密钥，第五个刚刚完成了一次后台 linter 检查。你的菜单栏——或者你使用的任何系统托盘——只能容纳一个状态图标。一个微小的点或标签，理应代表整个智能体集群。问题在于，哪个会话能赢得这个位置。
偷懒的做法是显示最后一次活动的会话。这看起来很合理。发生了某些事情，所以它浮现了出来。这种直觉是错误的，而且会让你付出代价。后台文件监听器更新一个时间戳并不是在发出求救信号。与此同时，一个十分钟前遇到权限错误的会话可能正处于隐身状态，等待你输入“yes”或修复路径。如果你按时效性（recency）排序，你就会隐藏掉那些真正需要你动脑筋处理的事情。你需要按可操作性（actionability）进行排序。
为什么时效性会失效
开发者倾向于使用时间戳，因为它们很简单。每个系统都会产生时间戳，每个数据库都会对其进行索引，而排序只需一行代码。但当你开始编排多个独立的执行者时，这种“简单”就不再适用了。
这是一个具体的失效模式。会话五刚刚追加了一行日志，因为它的依赖监听器注意到了 node_modules 中的文件变化。它的时间戳刷新到了现在。然而，会话二在三分钟前向你提出了一个问题：“我应该安装这个包吗？(y/n)”。你还没有回答。如果你的菜单栏显示最新的会话，会话五会获得绿光，而会话二则消失在列表中。看起来一切正常。然而，当你正忙于监控一个并不需要你的 linter 时，你的一个智能体却因为等待你的决策而停滞不前。
时效性衡量的是运动。紧急度需要的是意义。除非文件写入为你创建了一个任务，否则它本身并没有任何意义。另一方面，一个等待响应的提示则是纯粹的可操作性。你不能通过观察后台的变化来交付代码。你只能通过消除阻塞点来交付代码。思维上的第一个转变很简单：将时间戳视为平局决胜因素，绝不要将其视为主要信号。
先分类，后排序
一个更好的方法是两步过滤法。首先，根据每个会话对你的需求进行标记。其次，对这些标签进行排序。只有当两个会话具有相同的标签时，你才去查看时间。
这迫使你在工作流中定义“紧急”的真正含义。一个受速率限制（rate-limited）的会话并不紧急；它只是在休眠。一个正在工作的会话很忙，但如果它不需要决策，它可以安稳地继续计算。一个停滞的会话是紧急的，因为错误会不断恶化。一个未响应的交接是紧急的，因为接下来的步骤确实由你负责，在采取行动之前，智能体无法继续。
分类将你的菜单栏从“新闻推送”转变为“任务列表”。随后的排序步骤就会变得机械化。你已经决定了被阻塞的执行者优先级高于忙碌的执行者。你已经决定了未见过的提问优先级高于已见过的提问。只有当两个会话在同一优先级水平上发出呼救时，时间才会介入。只有在这种情况下，较早的会话才会胜出。这是对“先到先得”公平性的一种微小补偿，但它绝不应覆盖状态本身。
实用优先级量表
在 Agent Island v1.7.1 中，团队将其正式化为一个五级量表，任何运行多个 AI 会话的人都可以借鉴：
- 未确认且需要你：4。 会话已将某些内容交还给你，而你尚未看到。你掌握着下一步行动。
- 停滞：3。 会话遇到了错误、权限失败或其他阻塞点。它需要你的关注，因为它无法自我修复。
- 工作中：2。 会话正在积极计算。它不需要等待你，因此只有在没有更紧急的情况时，它才会获得图标。
- 已确认但需要你：1。 你已经看到了提示或问题，但尚未回答。你已经知晓，因此其紧急程度比未见到的中断低一个档次。
- 空闲或受速率限制：0。 会话属于环境噪音。它正在等待轮到它，或者只是在无所事事。
该量表可以清晰地映射到用户操作。当你完成一次交接，会话会降级为“工作中”或“空闲”。当一个“工作中”的会话出错时，它会跃升至“停滞”。当你点击确认一个提示但需要