miajia
Computer UseAgent评测

下单 Agent：停在购买按钮前一步

中文 · 技术学习 · 2026年10月

把一个下单 agent 从 demo 做到敢让它碰信用卡，难点大多不在 prompt，而在三件事：模型看到什么、它能做什么、怎么判断一次运行算成功。

TL;DR

  • 两段式执行：每次购买先跑一遍「预检」，停在最终下单按钮前一步，把最终价格抽出来给用户确认；用户同意后才跑最后一步。
  • 先设计动作空间，再写 prompt：输入是截图加带编号的元素列表，输出是一小组动作，其中没有「下单」。
  • 评测里的成功要定义得很严：停在对的位置、抽对字段才算成功；点了下单按钮是最严重的失败。
  • 失败先归类再修：工具问题和模型问题的修法完全不同；早期通常是工具问题占大头。
  • 卡号不进模型的上下文，每次购买带一个幂等键。

下单 agent 的两类难点

在真实网站上替用户结账，有两类难点：

  1. 跨商家可靠地走完结账：每个商家的流程、表单、弹窗都不一样，agent 要在没见过的页面上走完整个流程，中途不卡住、不绕圈。
  2. 动的是用户的钱：不能重复扣款，不能泄露卡号，要保护隐私。

第一类决定能不能上线，大部分工程时间花在这里；第二类决定敢不敢上线，要从一开始就设计进去，而不是最后再补。

预检，然后才是最后一步

如果购买发生在用户设置之后几天甚至几周（比如「降价了就帮我买」），一路跑到底会遇到两个问题：

  • 当初的支付授权可能已经过期；
  • 税和运费加上去之后，总价可能超出用户设的价格区间。

所以把执行拆成两段：

  1. 预检：agent 走完整个流程，停在最终的下单按钮前一步，把最终总价（含税和运费）抽出来。
  2. 最后一步：把总价和用户设的上限对比，交给用户确认；用户同意后，才点下单。

这样「最后一步要用户批准」就不是 prompt 里的一句叮嘱，而是流程本身的结构。

先设计动作空间，再写 prompt

模型每一步看到的（观察）：

  • 当前页面的截图；
  • 一份带编号的可交互元素列表，编号同时标在截图上（类似 set-of-marks）；
  • 任务目标，以及到目前为止走过的步骤。

模型能调用的（动作）：

click(id)          # 点击编号为 id 的元素
type(id, text)     # 在编号为 id 的输入框里输入文字
scroll(direction)  # 滚动页面
navigate(url)      # 打开一个网址
extract(fields)    # 从当前页面抽取字段，比如总价、运费、税
stop(reason)       # 结束，并说明原因

这里没有「下单」这个动作。如果最终按钮在页面上只是一个普通的可点击元素，就在 harness 里加一条硬规则，拦下对它的点击。「怎么保证 agent 不会误下单」的答案应该是一个机制，而不是 prompt 里的一句「请不要点击购买」。

观察和动作还有一个容易忽略的要求：它们必须描述同一个时刻。编号列表和截图如果不是同时抓的，模型在截图里看到的 17 号，和实际点到的 17 号就可能不是同一个东西。所以每次动作前都重新抓一次，点击前再核对目标元素的特征（文字、类型）有没有变。

评测：成功要定义得很严

评测在真实商家的流程上跑，但不真的下单。每次运行这样判定：

结果 判定
停在最终下单按钮前一步，并且抽对了总价等字段 成功
停对了位置，但字段抽错了 失败
中途卡住，或者在几个页面之间绕圈 失败
点了最终下单按钮 失败，而且是最严重的一种

除了成功率本身，每次评测还要记下：用的模型和版本、评测集覆盖多少个商家和多少条流程、跑一遍要多久。每做一类修复，就记下它让成功率涨了几个点，攒成一张分解表。这样「哪类修复最有用」就有数据可查，而不是凭印象。

失败先分类：工具问题还是模型问题

看失败案例时，先判断它属于哪一类：

  • 工具问题：模型拿到的信息本身就是错的或者不全的。比如：
    • 嵌在 iframe 里的内容（比如支付表单）没有被抓进 DOM，模型根本看不到；
    • 截图和 DOM 对不上；
    • 截图之后弹出一个促销窗，元素编号整体变了，模型按旧编号点到了别的东西。
  • 模型问题：信息是对的，但模型判断错了、步骤走错了。

两类的修法完全不同。工具问题要修抓取层：把 iframe 里的内容也抓进来，动作前重新抓，点击前核对元素。模型问题才轮到 prompt：比如把流程拆成几个阶段、每个阶段用一个更聚焦的 prompt，或者给流程特殊的商家单独写几条说明。

早期的失败里，工具问题通常占大头。先把抓取层修稳，再调 prompt：观察本身是错的，prompt 调得再好也稳定不下来。

钱的安全

  • 卡号不进模型的上下文：支付交给 token 或托管支付完成，卡号不出现在模型能看到的任何地方。
  • 每次购买一个幂等键：网络重试、agent 重跑，都不会造成重复扣款。
  • 最后一步必须用户批准：也就是前面的两段式执行。
  • 工具里没有下单动作：也就是前面的动作空间设计。

这四条各管一层，任何一层出错，还有别的层兜着。