返回首页
最新
一种常见的方法来自动化亚马逊购物或类似复杂网站的流程是使用大型云模型（通常具备视觉能力）。我想测试一个矛盾：一个大约3亿参数的本地大语言模型（LLM）能否仅通过结构化页面数据（DOM）和确定性的断言来完成整个流程。
这篇文章总结了同一任务的四次运行（搜索 → 第一个产品 → 添加到购物车 → 在亚马逊上结账）。关键比较是演示0（云基线）与演示3（本地自主）；演示1和演示2是中间控制。
更多技术细节（架构、代码片段、额外日志片段）：
[链接](https://www.sentienceapi.com/blog/verification-layer-amazon-case-study)
演示0与演示3：
演示0（云，GLM-4.6 + 结构快照）
- 成功：1/1 次运行
- 令牌数：19,956（相比估计的35,000减少约43%）
- 时间：约60,000毫秒
- 成本：云API（变化不定）
- 视觉：不需要
演示3（本地，DeepSeek R1 规划器 + Qwen ~3B 执行器）
- 成功：7/7 步骤（重新运行）
- 令牌数：11,114
- 时间：405,740毫秒
- 成本：$0.00 增量（本地推理）
- 视觉：不需要
延迟说明：本地堆栈在端到端的速度较慢，主要是因为推理在本地硬件（配备M4的Mac Studio）上运行；云基线受益于托管推理，但每个令牌有API成本。
架构
之所以能够实现，是因为我们改变了控制平面并增加了验证循环。
1) 限制模型所见（DOM修剪）。
我们不提供整个DOM或截图。我们收集原始元素，然后运行WASM传递以生成紧凑的“语义快照”（角色/文本/几何），并修剪其余部分（通常约95%的节点）。
2) 将推理与执行分开（规划器与执行器）。
- 规划器（推理）：DeepSeek R1（本地）生成步骤意图和后续必须为真的条件。
- 执行器（行动）：Qwen ~3B（本地）选择具体的DOM操作，如CLICK(id) / TYPE(text)。
3) 用Jest风格的验证对每一步进行把关。
在每个操作后，我们断言状态变化（URL变化、元素存在/不存在、模态框/抽屉出现）。如果所需的断言失败，该步骤将失败，并带有工件和有限的重试。
最小形态：
```python
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”
重要的是，这些不是事后分析，而是内联门控：系统要么证明它取得了进展，要么停止并恢复。
结论
如果你想让浏览器代理可靠，最有效的举措不是更大的模型，而是限制状态空间并通过逐步断言明确成功/失败。
代理的可靠性来自于验证（对结构快照的断言），而不仅仅是扩大模型规模。
<a href="https://github.com/stepandel/pinecone-explorer" rel="nofollow">https://github.com/stepandel/pinecone-explorer</a>