12 分•作者: tonyww•16 天前
自动化亚马逊购物或类似复杂网站的常见方法是使用大型云模型（通常具有视觉能力）。我想测试一个矛盾：一个约 30 亿参数的本地 LLM 模型能否仅使用结构化页面数据（DOM）加上确定性断言来完成流程？
这篇文章总结了同一任务（搜索 → 第一个产品 → 加入购物车 → 在亚马逊结账）的四次运行。关键的比较是 Demo 0（云基线）与 Demo 3（本地自主）；Demo 1–2 是中间控制。
更多技术细节（架构、代码摘录、额外日志片段）：
[https://www.sentienceapi.com/blog/verification-layer-amazon-case-study](https://www.sentienceapi.com/blog/verification-layer-amazon-case-study)
Demo 0 vs Demo 3：
Demo 0（云端，GLM‑4.6 + 结构化快照）
成功：1/1 次运行
tokens：19,956（比约 35k 的估计减少约 43%）
时间：约 60,000 毫秒
成本：云 API（变化）
视觉：不需要
Demo 3（本地，DeepSeek R1 规划器 + Qwen ~3B 执行器）
成功：7/7 步（重新运行）
tokens：11,114
时间：405,740 毫秒
成本：增量 0.00 美元（本地推理）
视觉：不需要
延迟说明：本地堆栈在这里端到端较慢，这主要是因为推理在本地硬件上运行（配备 M4 的 Mac Studio）；云基线受益于托管推理，但有每个 token 的 API 成本。
架构
之所以有效，是因为我们改变了控制平面并添加了一个验证循环。
1) 限制模型看到的内容（DOM 裁剪）。
我们不提供整个 DOM 或截图。我们收集原始元素，然后运行一个 WASM 过程来生成一个紧凑的“语义快照”（角色/文本/几何）并裁剪其余部分（通常约为 95% 的节点）。
2) 将推理与行动分开（规划器 vs 执行器）。
规划器（推理）：DeepSeek R1（本地）生成步骤意图 + 之后必须为真的内容。
执行器（行动）：Qwen ~3B（本地）选择具体的 DOM 操作，如 CLICK(id) / TYPE(text)。
3) 使用 Jest 风格的验证来控制每一步。
在每个操作之后，我们断言状态变化（URL 更改、元素存在/不存在、模态/抽屉出现）。如果所需的断言失败，则该步骤失败，并附带工件和有界重试。
最小形状：
ok = await runtime.check(
exists("role=textbox"),
label="search_box_visible",
required=True,
).eventually(timeout_s=10.0, poll_s=0.25, max_snapshot_attempts=3)
“看起来很聪明的代理”和“有效的代理”之间发生了什么变化
日志中的两个例子：
确定性覆盖以强制执行“第一个结果”意图：“执行器决策… [覆盖] first_product_link -> CLICK(1022)”
处理抽屉，验证并强制执行正确的分支：“结果：通过 | add_to_cart_verified_after_drawer”
重要的是，这些不是事后分析。它们是内联门：系统要么证明它取得了进展，要么停止并恢复。
总结
如果你想让浏览器代理可靠，最有影响力的举措不是更大的模型。而是限制状态空间，并通过每一步的断言明确成功/失败。
代理的可靠性来自验证（对结构化快照的断言），而不仅仅是扩大模型规模。