【推广】token 单价翻倍，单任务反而更便宜：聊浏览器 Agent 的延迟和成本该怎么算

twinklemodel

> **摘要**
> 10 月 31 日，Browser Use 把最快的浏览器 Agent 预设 BU Ultrafast 开放给美国区所有云端套餐（含免费版）。它跑 GPT-6 Luna、低推理档、走 OpenAI 的 priority 优先级通道，token 按标准价的 2 倍计费。但官方给出的中位数是：单任务 22 秒、$0.0064；默认 Agent（GPT-6 Luna、高推理档）是 79 秒、$0.0098。单价贵一倍，单任务反而便宜三分之一、快三倍多。本文拆解这个反直觉结果背后的账：浏览器 Agent 的成本主要由步数和每步推理 token 决定，而不是单价；以及怎么在自己的 Agent 里按任务类型分档。


做 Agent 成本优化时，大家第一反应通常是“换个更便宜的模型”或者“找个单价更低的通道”。Browser Use 10 月 31 日的这次发布给了一个很好的反例：他们的新预设故意选了**更贵的计费通道**，结果单任务成本反而更低。

## 一、这次发布了什么

按 Browser Use 官方博客和文档：

- **BU Ultrafast** 是他们最快的浏览器 Agent，10 月 30 日之前需要排队申请，现在美国区所有 Browser Use Cloud 套餐都能用，包括免费版。
- 用法很简单：调用 V4 接口时把 `model` 设成 `bu-ultrafast`，其他不变。
- 它运行的是 Browser Use Pi 的 ultrafast 模式，底层模型是 **GPT-6 Luna，推理档位 low，走 OpenAI 的 priority tier**。
- 计费上，priority tier 的 token 按 **标准价的 2 倍**算。HIPAA 项目和只走 Bedrock 的项目会退回标准通道。
- 另有一个 **`bu-fast`**：同一个 Agent，推理档位 medium，走标准通道、按标准价计费。
- 不传 `model` 时的默认配置是 GPT-6 Luna + High 推理。

官方给出的数据（10 月 16 日到 29 日已完成任务的中位数，每个项目最多取 1000 条）：

| 配置 | 中位耗时 | 中位单任务成本 | 样本 |
| --- | --- | --- | --- |
| BU Ultrafast | 22 秒 | $0.0064 | 12,238 次运行，134 个项目 |
| 默认 Agent（GPT-6 Luna） | 79 秒 | $0.0098 | 146,120 次运行，9,473 个项目 |

在两边都跑过 20 次以上的 8 个项目里，Ultrafast 在全部 8 个项目上都更快、更便宜。这里的成本只算模型和搜索费用，浏览器和代理另算。


## 二、为什么单价翻倍反而更便宜

浏览器 Agent 的单任务成本可以粗略拆成：

$$
\text{单任务成本} \approx \text{步数} \times \text{每步 token} \times \text{token 单价}
$$

其中“每步 token”又分三块：页面状态（DOM 摘要、截图等）这类输入、推理 token、动作输出。Ultrafast 动的是后两个因子：

- **推理档位从 high 降到 low**。浏览器操作里大量步骤是“点这个按钮”“在这个框里填内容”这类低难度决策，用高推理档每一步都要先想一大段，这部分 token 按输出价计费，通常是最贵的那一块。
- **priority 通道提升速度**，把单价乘了 2。

我们可以用官方数字做个粗算（这是我的推算，不是官方数据）：成本比是 0.0064 / 0.0098 ≈ 0.65，单价是 2 倍，那么在“单价 × 用量”这个简化模型下，Ultrafast 每个任务消耗的计费 token 大约只有默认配置的 0.65 / 2 ≈ 1/3。考虑到成本里还含搜索费用、两组任务的分布也不完全一样，这个比例只能当量级参考，但方向很清楚：**降推理档省下的 token，远多于优先级通道多付的钱**。

时间上同理。耗时比 79 / 22 ≈ 3.6 倍，其中一部分来自每一步少想（少生成推理 token，直接减少解码时间），一部分来自 priority 通道更快的排队和吞吐。对浏览器 Agent 来说，每一步都要等模型返回才能执行下一个动作，单步延迟会被步数放大，所以“每步快一点”在总时长上非常显著。

## 三、但 low 推理不是万能的

Browser Use 的文档很坦诚，直接给了一张选择表：

| 任务类型 | 推荐 `model` |
| --- | --- |
| 步骤短、以交互为主的流程 | `bu-ultrafast` |
| 同类流程但步骤更多、`bu-ultrafast` 会出错 | `bu-fast`（medium 推理，标准通道） |
| 调研、批量采集、处理文件、长指令 | 不传 `model`，用默认的 GPT-6 Luna + High |


这张表背后的逻辑是：**低推理档省的是每步的思考，但如果因此走错一步，后面要多花好几步纠正，步数一涨，前面省下的就全还回去了**。短流程容错空间小、步骤少，降档几乎没有风险；长流程、需要汇总信息的任务，一步想不清楚的代价更高。

另外几个限制也值得注意：

- 预设不接受 `modelParams`、`mode` 等参数，传了直接返回 422；
- 预设绑定在会话上，后续追问不能中途换模型，否则也是 422；
- 新会话默认不走托管代理，需要的话要设置 `browserSettings.proxyCountryCode`。

## 四、在自己的 Agent 里怎么借鉴

如果你不用 Browser Use，而是自己写浏览器 Agent 或其他多步 Agent，这次发布最值得借鉴的是“**按步骤难度分档，而不是整个任务用一个档**”。

下面是一个简化示例：对每一步先用规则粗判难度，简单动作用低推理档，需要规划或汇总时用高推理档。接口是 OpenAI 兼容格式，示例里的网关地址是我自己运营的中转站 Twinkle Model，换成官方或其他兼容网关只需改 `base_url`；模型名和参数是否支持，请以你所用平台的文档为准。

```python
import os, time
from openai import OpenAI

client = OpenAI(base_url="https://big-model.smart-agi.com/v1",
                api_key=os.environ["LLM_API_KEY"])
MODEL = "gpt-6-luna"   # 以平台模型列表为准

SIMPLE_ACTIONS = ("click", "type", "scroll", "select", "press")

def pick_effort(step_hint: str, retries: int) -> str:
    # 规则快路径：简单交互用 low；同一步失败过就升档，避免一步错步步错
    if retries >= 2:
        return "high"
    if retries == 1:
        return "medium"
    return "low" if step_hint.startswith(SIMPLE_ACTIONS) else "high"

def next_action(page_state: str, goal: str, step_hint: str, retries: int = 0):
    effort = pick_effort(step_hint, retries)
    t0 = time.time()
    r = client.chat.completions.create(
        model=MODEL,
        reasoning_effort=effort,
        messages=[
            {"role": "system", "content": "你是浏览器操作 Agent，只输出下一步动作 JSON。"},
            {"role": "user", "content": f"目标：{goal}\n当前页面：{page_state}"},
        ],
    )
    u = r.usage
    # 每一步都记录档位、耗时和 token，后面才能算“每任务成本”
    print(f"effort={effort} latency={time.time()-t0:.1f}s "
          f"in={u.prompt_tokens} out={u.completion_tokens}")
    return r.choices[0].message.content
```

几个经验：

1. **先记账再调参**。把每一步的档位、耗时、输入输出 token 都记下来，按任务汇总，才能像 Browser Use 那样拿“中位单任务成本”来做决策，而不是盯着每百万 token 的单价。
2. **失败自动升档**。low 档最大的风险是走错，所以同一步重试时升到 medium、high，比全程开 high 更划算。
3. **区分“延迟敏感”和“成本敏感”**。OpenAI API 的 `service_tier` 参数支持指定优先级通道，单价更高但更快；如果你的场景是用户在屏幕前等结果，像 Browser Use 一样花钱买速度是合理的；如果是夜间批量跑，就没必要。通过第三方网关调用时，这类参数是否透传要先实测确认。
4. **把页面状态压小**。上面公式里的“每步 token”大头往往是页面输入，DOM 精简、只截关键区域，这部分优化对所有档位都有效。

## 五、我的看法

这次发布本身只是一个预设上线，但它给出的数据很有说服力：几万次真实运行的中位数，而不是精心挑选的 demo。它说明了一个经常被忽略的事实：**Agent 的成本单位是“任务”，不是“token”**。单价只是公式里的一个因子，步数和每步推理量往往影响更大。

对做 Agent 的团队来说，下一步该优化的可能不是换更便宜的模型，而是先回答两个问题：你的任务里有多少步其实是“点一下”的简单操作？这些步骤现在是不是在用最贵的推理档？

## 参考来源

- Browser Use 官方博客，BU Ultrafast is live（2026-10-31）：https://browser-use.com/posts/bu-ultrafast-is-live
- Browser Use 文档，BU Ultrafast：https://docs.browser-use.com/cloud/agent/ultrafast
- Browser Use，BU Ultrafast 产品页：https://browser-use.com/ultrafast

---

**作者说明**：我在运营一个 API 中转站 Twinkle Model（https://big-model.smart-agi.com），源头中转：GPT 1折、国产模型 1折、满血 Claude，主打低价、稳定。文中的网关地址只是示例，用官方接口或其他兼容网关同样适用。各模型价格见模型广场：https://big-model.smart-agi.com/model-plaza 。