在浏览器代理领域，一个反直觉的事实正在被实践验证：当验证层足够严密时，参数量仅为 30 亿的本地模型配合结构化快照，能够完成与云端大模型相同的购物流程。Sentience API 在 Amazon 购物场景中的四轮实验表明，决定可靠性的关键因素并非模型尺寸，而是验证架构的设计质量。本文将从工程实现角度拆解这一验证层的核心机制，为浏览器代理的可靠性设计提供可复用的参数与策略。
三模型分离架构与验证循环
传统浏览器代理将规划、执行与验证混为一体，导致失败模式难以诊断。Sentience 采取三模型分离架构：规划模型负责生成结构化步骤与验证目标，执行模型在受限的 DOM 动作空间内选择 CLICK 或 TYPE 操作，而验证层则作为独立运行时对每一步结果进行断言评估。这种分离使得验证逻辑从模型输出中解耦，成为纯粹的确定性检查流程。
具体而言，规划模型输出的并非自然语言指令，而是包含验证目标的 JSON 结构。例如，搜索 ThinkPad 并加入购物车的流程会被分解为七个步骤，每个步骤都附带明确的验证谓词。当执行模型完成点击操作后，运行时立即捕获当前页面的结构化快照，并运行预定义的断言函数。只有当所有断言通过后，流程才会推进到下一步；任何失败都会触发重试或回滚，而非让模型自行判断是否成功。这种设计将「模型认为它成功了」转变为「证据证明它成功了」，从根本上消除了静默失败的可能性。
从实验数据来看，这种架构的效果显著。Demo 0 使用云端 GLM-4.6 模型配合验证层，在单次运行中成功完成全部步骤，耗时约 60000 毫秒，消耗 19956 个 token。相比之下，Demo 3 采用 DeepSeek-R1 作为规划模型配合约 30 亿参数的本地 Qwen 执行模型，在验证门的约束下同样实现了 7/7 步骤的成功完成。这表明当验证层足够健壮时，模型能力的边际收益会迅速递减，而架构设计的边际收益则急剧上升。
DOM 剪枝与结构化快照
浏览器代理的 token 消耗主要来自页面内容的输入。原始 DOM 树往往包含数千个节点，直接喂给模型既不经济也不可靠。Sentience 采用的策略是 DOM 剪枝：将页面元素按照角色、文本、几何位置与显着性进行筛选，只保留与当前任务相关的结构化信息。这种剪枝使得提示词 token 数量从估计的 35000 个降低到 19956 个，降幅约为 43%。
结构化快照的核心在于将视觉信息转化为语义信息。传统视觉代理依赖截图作为控制平面，面临点击目标模糊、导航失败检测困难等问题。结构化快照则将页面抽象为元素列表，每个元素包含可点击区域的坐标、文本内容、ARIA 角色以及相对重要性评分。执行模型在这个语义化的空间内做决策，而非在像素空间内猜测。验证层随后对快照进行检查，确保执行结果与预期状态一致。
这种设计还带来了可观测性的提升。每次断言的执行结果、快照差异状态、耗时与 token 消耗都被记录并上传到 Sentience Studio，形成完整的时间线。开发者可以回放任意步骤的快照，对比预期与实际状态的差异，精确定位失败原因。这种调试能力对于生产环境中的代理系统至关重要，因为代理的失败往往是偶发的、边界条件下的，而非必然的、复现性强的。
显式断言与确定性覆写
验证层的核心是断言函数的设计。Sentience 提供了两个基础断言原语：url_contains 用于验证导航是否到达预期页面，exists 用于验证关键元素是否出现在快照中。这两个断言的组合足以覆盖大部分浏览器代理场景。对于 Amazon 购物流程，典型的验证序列包括：搜索框出现后断言 URL 包含 amazon.com、搜索结果加载后断言第一个商品链接存在、加购完成后断言购物车页面已加载、结算按钮出现后断言页面可进入结账流程。
断言的实现采用谓词模式，返回包含通过状态、原因说明与详细元数据的结构体。url_contains 谓词检查当前 URL 是否包含指定子串，返回的 details 字段包含子串与 URL 前 200 字符，便于调试。exists 谓词使用 CSS 选择器查询快照，返回匹配的节点数量与未匹配的原因代码。当 required 参数设为 True 时，断言失败会触发失败工件的持久化，包括当时的快照与运行时上下文，为后续分析提供完整证据。
确定性覆写是处理边界情况的另一层保障。在 Amazon 购物场景中，存在两类典型情况：加购后弹出的附加推销抽屉，以及搜索结果中第一个商品链接的优先选择。对于前者，系统检测到推销抽屉后直接执行确定性点击予以关闭，无需模型判断。对于第一个商品链接的点击，当执行模型选择的节点与预期优先节点不一致时，运行时直接覆写为优先选择。这种覆写并非模型能力的否定，而是将明确意图的安全执行从模型责任中剥离，交由确定性逻辑保证。
工程化参数与监控建议
基于 Amazon 案例的实践经验，以下参数可作为生产环境的起点配置。对于规划模型，建议保留较大参数的模型用于高层规划，例如 DeepSeek-R1 系列，以减少规划漂移与重规划开销。对于执行模型，3-7B 参数的本地模型在结构化快照约束下已足够，关键在于为其提供精确定义的动作空间与清晰的验证目标。执行模型的推理延迟通常在数百毫秒级别，端到端流程的耗时主要来自模型调用与网络延迟，而非浏览器操作本身。
断言的超时与重试策略需要根据业务场景调整。对于导航类断言，建议设置 2000-3000 毫秒的等待时间，允许页面加载完成后再进行验证。对于元素存在性断言，可采用指数退避策略进行重试，首次等待 500 毫秒，随后依次翻倍，最多重试 5 次。required 类型的断言失败应触发完整上下文的保存，包括快照、运行时日志与模型输出，以便后续根因分析。
监控指标应覆盖步骤成功率、断言通过率、重试次数与端到端耗时。Sentience 的运行摘要显示，Demo 3 的稳定版本在 405740 毫秒内完成 7 个步骤，总 token 消耗为 11114 个。对于生产系统，建议设置阶梯式告警：当单步骤成功率低于 95% 时发出预警，低于 80% 时触发人工介入检查。同时，应追踪断言失败的类型分布，识别高频失败模式并针对性地优化验证逻辑或页面适配代码。
验证层的设计哲学可以概括为「Jest for agents」：将代理的每一步视为测试用例，只有当断言通过时才认为步骤成功。这种思路将可靠性保障从模型的自我评估中抽离，交给可验证的证据链，从而使得本地小模型在受限但受控的环境中实现可靠的自动化行为。
资料来源：Sentience API 博客，https://www.sentienceapi.com/blog/verification-layer-amazon-case-study