跨国深谈← 返回←鼠标力：为智能体时代找回「马力」这把尺子

鼠标力：为智能体时代找回「马力」这把尺子

关联

人物 Maximillian Piras

公司 Utori · Anthropic · Coinbase

概念 智能体 · 计算机使用模型 · 心智模型 · 鼠标力 · token · ROI · 代码审查 · 验证 · 熵

这一集是场大会演讲，主角叫 Maximilian Piros,他在一家做计算机使用模型(让模型学着像人一样操作电脑，当你拿不到 API 或 MCP 数据时，就派智能体去「亲自用电脑」把信息取回来)的公司 Utori 担任创始设计师，平时的大量工作是跟客户聊：怎么让智能体用起来更直观、他们心里怎么掂量一个用例值不值得派智能体去干。

他每天自己的用法大概是这样：把智能体全放到后台跑，正事只专注一件，周边任务(比如改幻灯片排版)就并行开一堆智能体去探索不同方向。这很爽——直到收到账单。

于是你开始怀疑：是不是 vibe coding(凭感觉让 AI 写代码)玩过头了？token 是不是烧太多了？智能体的先后顺序安排得够不够高效？

他抛出本次演讲的论点：智能体有一个衡量问题(measurement problem)。在场的人可能不服：「我手上一队智能体跑得好好的，衡量完全没问题。」他承认，但引用 Upton Sinclair 的名言提醒大家：房间里的人全是早期采用者、全有偏见——还有人至今只是把东西复制粘贴进 ChatGPT,而全世界那些我们希望用上智能体的人，心智模型跟我们并不一样。

蒸汽机怎么卖出去的。 为了找到解法，他回到很久以前：James Watt 卖蒸汽机时，选的用例是取代马拉磨——当时磨坊(比如啤酒厂磨大麦)的动力来源就是把马套在旋转臂上绕圈走。

Watt 明白，采用的一大障碍是认知失调：你得向一帮「用马来思考」的人解释，为什么该换一台冷冰冰、看着吓人的机器——他说这场景对今天做智能体的任何人都不陌生。 Watt 的解法是研究对方的心智模型：他真的去丈量马拉磨的平均性能，得出「马力」这个指标，再以此为基准展示蒸汽机的效率倍数。

这个指标并不科学、甚至不一定准确，但它干成了关键的事：传达了价值提升，让爱马的人能大致算出采用蒸汽机的收益，跨过「试一试」那道门槛——毕竟说实话，马的氛围感(vibes)是很难打败的，他必须给出一个能算 ROI 的东西。 教训：如果给不出有形的 ROI,就没法传达价值。

行业自己也没算明白。 别以为这只是向外行卖货的问题：业内工程师理论上很聪明，照样有人一个季度烧光一整年的 token 预算。

他借 RAMP 的说法，称现在是「厄运循环」：超支、同时使用不足——token 拉满把自己逼进紧缩，退出循环，直到 FOMO(错失恐惧)攒够了再回来试。 好的苗头是 Coinbase CEO 在 X 上发的图：他们把默认起步模型调低，只把前沿模型留给最难的任务，结果 AI 支出与 token 用量开始分化。

但他认为问题在于这一切还是太聚焦 token 了——token 只是系统的输出，必须被干净地追溯到成果：这笔 token 花费消灭了多少 bug?关闭了多少支持请求？再把这些成果与目标进展挂钩。

瓶颈挪到了验证一侧。 编程智能体的效率提升大家都能感觉到，但「我们都快被一千个 pull request 折磨至死了」——就连 Anthropic,团队有人声称已解决编程，也承认还没解决代码审查。

于是瓶颈从生成转移到人工审查：你生成了海量的代码，但没法知道其中足够多的一部分是好的、值得这笔花费。他引 Noah Hine 的说法：代码评审底层的假设才是需要重新审视的。

好消息是，代码评审之所以让人感觉可解，是因为作为一种文化，它在共同假设上有很好的收敛——大家能用同一把尺子大规模地判断质量。任务就是为智能体时代改写这些假设，从「以计算速度执行」进到「以计算速度衡量」，且衡量方式要契合客户的心智模型。你造智能体，就得同时帮客户造出验证其输出的方法，光构建出来不够。

鼠标力与熵矩阵。 由此他提出「鼠标力(mouse power)」——智能体时代的马力。

但他先自嘲：这没法像 Watt 那样直接量——他真让 Claude 用 vibe coding 做了个测量光标移动速度的装置，想算出智能体能让光标高效多少，结果证明是徒劳的，因为信息空间维度太高了。 所以鼠标力不是一个真指标，而是一个理念：卖智能体的人，必须同时帮客户解决「怎么验证这活儿干得好」的评分标准问题。

至于怎么找对要做的智能体，他给出一个基于信息论的思考框架(回到 Claude Shannon 关于熵——即概率分布的不确定性——的思想，熵也是今天训练模型的根基)：两个轴——x 轴是执行任务步骤的不确定性(订机票很低：出发地、目的地、选座，路径基本可预测；画一幅杰作则高到没人知道步骤)，y 轴是验收标准本身的不确定性。

四个角的结论很干脆：步骤不确定性低 → 别浪费 token,写个脚本就行；步骤不确定性太高 → 数据超出预训练分布，强化学习奖励稀疏，不适合智能体；验收标准不确定性高 → 验证与执行无法区分——为了确认它有用，人几乎得把活儿重做一遍，纯浪费 token。 剩下的中间地带才是甜蜜点：任务有一定不确定性(不至于只是脚本、也没出训练分布)，但又相对容易验证价值——形状上像一个「验证比执行容易」的问题。

这意味着一个杠杆：如果你能为验证找到可重复的模式，就直接把智能体也扔去验证——不只造干活的智能体，还造一个验证它工作的智能体。

他最后说这还只是一个启发思考的想法，希望大家在造下一个智能体时，也能顺手造出它的 mouse power。

本集带走

• 先算 ROI 再谈采用：客户不肯用，往往不是不兴奋，而是缺一个像「马力」那样的度量，能把智能体的效率提升换算成有形的回报。
• 别只盯 token:token 是输出不是价值；要把它追溯到干净的成果(消灭多少 bug、关闭多少工单)，再挂到目标进展上。降默认模型、留前沿模型给硬任务，是个可行起点。
• 警惕「超支+使用不足」的厄运循环：token 拉满→紧缩退出→FOMO 回归，打破它靠更好的价值度量。
• 验收标准的不确定性是第一道闸：如果验证成果的人几乎得把活儿重做一遍，这个任务就不值得派智能体。
• 造智能体时同时造它的「鼠标力」：帮客户建好验证输出的评分标准；验证若可模式化，就让另一个智能体去执行验证。

我认为提醒自己这一点很重要：不管间接还是直接，我们很可能都在售卖 token。
I think it’s important to remind ourselves that in some way or another, we probably are selling tokens, whether it’s indirectly or directly.
—— Maximillian Piras · [05:03]

教训是：如果我们无法给客户提供某种有形的投资回报率(ROI),那我们就很难传达价值。
the lesson being if we’re not able to give something that is a tangible ROI for our customers, then it’s very hard for us to communicate value.
—— Maximillian Piras · [08:49]

人们把一整年的 token 预算挥霍一空——而且是在一个季度里就挥霍完了——或者他们在应付 token 排行榜之类的东西。
People are blowing through their entire token budget for a year and they’re blowing through it in a quarter or they’re dealing with token leaderboards and such.
—— Maximillian Piras · [09:23]

现在，我认为我们有点处于这种厄运循环中：我们超支，同时我们使用不足。
right now I think we’re kind of in this doom loop where we’re overspending and we’re underusing.
—— Maximillian Piras · [09:52]

token 作为内部系统的度量当然是有用的，但归根结底，它们只是一种输出。
tokens are, of course, useful as a measurement of an internal system, but at the end of the day, they’re just an output.
—— Maximillian Piras · [10:49]

但问题当然是我们都在被一千个 pull request 折磨至死。
the problem of course is that we’re all kind of dying by a thousand pull requests.
—— Maximillian Piras · [11:51]

瓶颈最终转移到了验证这一侧，因此，我们没有办法大规模地衡量价值，并以同样的速度判断质量。
the bottleneck ends up shifting to the verification side, and thus, we don’t have a way to measure value at scale and to judge quality at the same speed.
—— Maximillian Piras · [12:20]

如果你要考虑如何为某件事构建一个智能体，你也必须考虑如何帮助客户构建，或者至少创建一种方法，来验证输出是好的。
if you’re going to think of how to build an agent for something, you also have to think about how do you help the customers build or at least create a method for verifying that the output is good.
—— Maximillian Piras · [14:05]

如果你要把一个智能体卖给某个人，你也必须帮他们解决评分标准的问题，即我们究竟如何验证这个智能体在做好的工作
if you’re going to sell somebody an agent, you also have to help them with the rubric of how do we actually verify that this agent is doing good work
—— Maximillian Piras · [15:44]

当验收标准具有很高的不确定性时，你基本上就处于一个验证与执行无法区分的境地。
when you have high uncertainty in the acceptance criteria, you pretty much have a spot where verification is indistinguishable from execution.
—— Maximillian Piras · [19:11]

如果你能找出一个相当可重复的模式来验证它们的工作，你其实也可以直接把智能体扔到那个问题上。
if you can figure out a pretty repeatable pattern for verifying their work, you can actually just throw agents at that problem as well.
—— Maximillian Piras · [20:04]

所以你不只是构建一个智能体，你或许要构建一个用来验证那个智能体工作的智能体。
you don’t just build the agent, you perhaps build the agent that verifies the work of the agent.
—— Maximillian Piras · [20:13]