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 知识库整理。文章不是逐字稿,而是按单场分享的主线、上下文和工程启发重写。

评论前必须登录!
立即登录 注册