Ido Salomon 用游戏界面解释多 agent 编排

Ido Salomon 的题目是 “We’re the bottleneck, but we don’t have to be”。他用 AgentCraft 和 Warcraft 式界面讲多 agent 协作，核心问题是人的注意力如何跟上 agent 的并行速度。

原视频：https://www.youtube.com/watch?v=htM02KMNZnk

人的瓶颈不是智力，是注意力

当 agent 只能一次做一件事，人还能盯住它。它写代码，人看 diff；它跑测试，人看结果。可一旦多个 agent 并行工作，人很快变成瓶颈。

这个瓶颈不是因为人不聪明，而是因为人没法同时理解十几个 agent 的状态、意图、阻塞点和产出。每个 agent 都发一堆日志，人类只会更累。并行越多，认知负担越大。

Ido 的说法很直接：我们确实是 bottleneck，但不一定永远如此。解决办法不是让人读更多文本，而是改变状态呈现方式。

为什么借鉴游戏界面

AgentCraft 借用了 Warcraft 式的空间界面。转录里提到 war rooms、heat maps、linkages，以及可以看到每个 agent 做了什么、什么时候做的。

这背后的逻辑是：游戏早就解决过类似问题。玩家在复杂战场里管理多个单位，不是靠读每个单位的日志，而是靠地图、颜色、位置、血条、路径、警报。状态被压缩成视觉信号，人才能快速判断哪里需要介入。

多 agent 编排也需要这种压缩。一个 agent 在查资料，一个 agent 在改代码，一个 agent 在跑测试，一个 agent 卡在权限上。你不应该通过四段聊天记录来理解这些状态，而应该一眼看到哪个任务正常、哪个任务危险、哪个任务需要你决策。

从聊天窗口到操作台

这场和 Charlie 的 Conductor、Google Antigravity 可以放在一起看。聊天窗口适合单次问答，不适合持续指挥。多 agent 系统需要的是操作台。

操作台不是花哨 UI，而是把人从低价值监控里救出来。你不需要看 agent 每一步怎么想，你需要知道它现在在哪、是否偏离目标、是否需要权限、结果能不能证明。

我觉得未来 agent 工具会越来越像控制室。它会有地图、状态、队列、警报、证据、回放，而不是只有 prompt 输入框。

Ido 这场的价值就在这里：它把多 agent 协作的瓶颈从 “模型够不够强” 转成 “人能不能看懂系统”。如果人看不懂，再多 agent 只会制造更多噪音。

Ido 看到的是人类注意力上限

Ido 的判断很直接：agent 越能干，人类越可能成为瓶颈。但这个瓶颈不是因为人不够聪明，而是因为人的注意力无法线性扩展。

一个 agent 还可以看日志，三个 agent 还能勉强盯，十几个 agent 同时工作时，纯文本界面就崩了。你不知道谁在做什么，谁偏离目标，谁需要权限，谁已经产出可用结果。

AgentCraft 用 Warcraft 式界面解决这个问题，本质上是在做状态压缩。复杂信息不再用长日志呈现，而是用空间、颜色、位置、角色和警报呈现。

游戏 UI 给 agent 协作的启发

游戏界面早就学会了让玩家管理复杂系统。玩家不需要读每个单位的日志，也能知道哪里被攻击、哪个单位快死、哪条路被堵、哪个任务需要处理。

把这个经验迁移到 agent 系统，很合理。agent 的状态也需要视觉化：空闲、执行中、等待人类、失败、产出待验收、越界风险。越复杂的系统，越需要低成本观察。

视觉化不是装饰

这场容易被误解成“做一个酷炫界面”。其实它讲的是控制面板。多 agent 系统如果没有好的可视化，人类就只能读日志，最后反而失去控制。

未来 software factory 的 UI 可能会很像任务地图：每个 agent 是一个单位，每个任务是一个区域，每个阻塞点是一个警报。人类不是盯每一步，而是在关键节点指挥。这和 Charlie 的 orchestra 是同一条线：协作能力最终会落到界面设计上。

来源与说明

本文基于 AI Engineer World’s Fair 2026 Day 1 主舞台视频转录、官方日程信息，以及本地 AI engineering 知识库整理。文章不是逐字稿，而是按单场分享的主线、上下文和工程启发重写。