Chrome DevTools 给 AI Agent 上了一课：效率不是第一位

大多数人做 Agent 界面时，第一反应是“更快、更省 token”。但来自 Google Chrome DevTools 团队的一个结论恰恰相反：如果你的 Agent 不知道自己在干什么，再高的效率都是浪费。这场演讲，拆穿了很多 Agent 产品正在犯的设计错误。

真正的反直觉：Agent 不是慢，而是一直在“瞎跑”

Michael Hablich 一上来就点破了一个行业幻觉：我们以为 Agent 的问题是模型不够强、推理不够快，但 Chrome DevTools 团队看到的真实情况是——大量 coding agents 在“飞行中失明”。它们看不到页面真实状态，只能靠猜。

这正是 Chrome DevTools for Agents 诞生的原因。不是为了给人用，而是给 Agent 用。Agent 通过 MCP Server 接入浏览器，直接拿到性能 trace、DOM 状态、网络请求，而不是把几 MB 的日志硬塞进上下文窗口。

一个关键判断在这里出现：上下文窗口不是无限的，真正可扩展的方案，是让 Agent 学会“查工具”，而不是“背世界”。这句话几乎可以当成所有 Agent 产品的设计原则。

Agent 是新用户物种，照搬人类界面一定会翻车

演讲中一个非常重要、但容易被忽略的判断是：Agent 是一种全新的用户类别。人类 DevTools 追求的是可视化、信息密度和交互美感，但 Agent 根本不在乎这些。

对 Agent 来说，界面只有两件事重要：一是能不能完成任务（effectiveness），二是完成任务要烧多少 token（efficiency）。这直接颠覆了很多产品的设计逻辑。

Chrome DevTools for Agents 的做法非常激进：提供 slim mode、CLI 接口，主动减少返回信息，用语义摘要替代原始数据。目标不是“给得更多”，而是“给得刚好”。Michael 用了一个很形象的说法：这是在优化 Agent 界面的“燃油效率”。

一个真正工程师才会提的指标：每次成功要烧多少 token

在大多数 Agent demo 里，成功与否是二元的：要么跑通了，要么失败了。但 Chrome DevTools 团队引入了一个更残酷、也更现实的指标——tokens per successful outcome。

也就是说，不是看你能不能完成任务，而是看你完成一次任务要花多少钱。这个视角直接把 Agent 从“炫技玩具”拉回到“工程系统”。

围绕这个指标，他们做了大量看似不性感、但极其重要的优化：减少无效上下文、避免重复请求、在必要时才展开详细数据。这些设计并不会出现在宣传 PPT 上，却决定了 Agent 能不能被真正部署。

效率还不够，Agent 必须学会“自救”

演讲后半段，Michael 提出了第四个关键教训：如果 Agent 会高效地失败，那依然是失败。

因此 DevTools for Agents 把大量精力放在 resilience 上：错误恢复不是一个开关，而是一个光谱。从基础重试，到主动绕路（proactive detours），再到诊断型 playbooks，帮助 Agent 理解“我现在卡在哪”。

另一个被低估的能力是 discoverability。团队把 Agent 可用能力拆解成 25 个维度，明确每个工具的 purpose，让 Agent 知道“我什么时候该用谁”。这不是 UX，而是 Agent 能力管理。

总结

这场演讲最重要的启发，不是 MCP、不是 Gemini，也不是某个具体工具，而是一个视角转变：Agent 正在成为真正的用户。为 Agent 设计界面，不是把人类界面 API 化，而是从 effectiveness、token 成本和韧性出发重新设计。

如果你正在做 Agent 产品，可以立刻问自己三个问题：我的 Agent 是否还在“盲飞”？我是否在为成功而不是为输出优化 token？当它卡住时，系统有没有帮它一把？未来真正拉开差距的，不是模型参数，而是这些看不见的工程选择。

关键词： AI Agent， MCP， Chrome DevTools， Token 效率， 上下文窗口

事实核查备注： 需要核查：1）演讲者姓名 Michael Hablich 的拼写；2）Chrome DevTools for Agents 是否为官方名称；3）tokens per successful outcome 是否为原话或概念总结；4）discoverability 拆解为 25 个维度的具体来源