[实验报告] DSH + Jev 多步协作：实验设计、真实模型测量与收益评估 #423

我在 2026-10-13 用本地 DSH 做了一轮 BrowserSkill + Jev 的有限范围实验，评估「主模型负责规划和验收，决策 API 接手部分连续浏览器操作」能否减少用户等待时间。

目前的结论是：协作和失败回退路径已经跑通，但在本次主模型、Jev 代理和场景组合下，还没有测到稳定的提速收益。 主模型请求次数减少，不代表任务总耗时一定减少。建议先保留为可选实验能力，继续验证委派边界和开销，再决定是否进入产品主线。

本轮完成 52 次真实模型 A/B 运行：初版 44 次、修正版 8 次，均通过任务验收。另有 3 次故障注入恢复测试和 1 次安装后的真实表单验证，也全部通过；这 4 次不参与收益统计。18 次接入预跑单独保留，不混入正式数据。下面同时公开变快、变慢、没有采用委派和中途回退的结果。

实验比较的是两条完整的用户任务路径。 A 组使用现有 DSH 主模型和 BrowserSkill 工具；B 组保持相同主模型和普通工具，额外启用 browser_delegate。主模型仍负责理解用户目标、拆分任务、提供输入和验收结果，可以把连续的页面操作交给辅助决策循环，也可以直接使用原有工具。

flowchart TD
    U[用户任务] --> M[DSH 主模型：规划与验收]
    M --> B[原有 BrowserSkill 工具]
    B --> M
    M --> D[browser_delegate：目标、完成条件、输入]
    D --> O[观察当前页面，构造候选操作]
    O --> J[Jev 选择下一步]
    J --> E[调用已有 BrowserSkill 工具执行]
    E --> O
    J --> R[完成或交回：已执行步骤与页面证据]
    R --> M
    M --> F[最终回答，关闭 session]

实验适配器实现了这些约束：

• 从当前实际页面和元素引用生成有限候选操作，包括点击、填写明确输入、选择原生下拉值、回车、条件等待、历史返回、继续读取页面，以及完成或交回。页面变化后重新观察，不把旧元素引用继续当成可操作对象。
• 原生下拉值来自页面真实选项；Jev 根据任务和页面在候选操作中选择。没有提前录制用户操作，没有给 Jev 编排点击序列、场景专用选择器或验收答案。
• 委派返回已完成步骤、当前页面和观察证据。缺少凭据、服务错误、低置信度或预算耗尽时交回主模型；交回后同一 session 不再调用辅助工具，由原有工具从当前进度继续。对于执行结果不确定的操作，不盲目重放。
• 限定实验站点和操作范围，表单提交需明确允许；机票案例停在旅客信息页。实验没有购票、支付或真实业务数据提交。
• 每次 Jev 请求上限 4 秒、不重试；单次委派最多 16 个操作，循环预算 90 秒，主任务上限 240 秒。90 秒在步骤之间检查，进行中的浏览器工具仍受其自身超时控制，因此它不是整个委派严格的墙钟上限。

当前实现是本地 DSH 的可选实验配置和适配器，复用已有 BrowserSkill CLI、插件和扩展能力。没有开发扩展配置页面，也没有将实验适配器并入主线。默认 DSH 配置保持原状。

正式测量前固定环境、任务、策略和验收口径。 初版正式组冻结后没有根据快慢调整参数；发现集成问题后另建修正版，单独复测和报告。

每对任务使用完全相同的任务提示和输入，表单输入使用相同的配对标识。两组都包含相同的能力条件说明：有 browser_delegate 时，多步子任务优先委派；没有时使用普通工具；单步任务使用普通工具；交回后从当前进度继续。因此，本轮测量的是配置了协作工具和使用策略之后的完整路径，没有测量新工具在无使用提示下的自然采用率。

案例覆盖机票流程、信息获取、填写表单、多页检索和简单任务对照。 所有正式测量都实际调用模型、实际访问外部网页，没有用固定时延模拟模型，也没有用本地静态页面替代网站。

为便于复核，案例的参考结果放在文末。参考结果只交给验收器，不传给决策服务。

站点覆盖有明确限制：Python 是真实生产网站，机票、表单和图书目录是公开演示/测试站点。真实售票站入口在独立浏览器中返回反自动化拦截，没有继续绕过。因此，本轮没有测得真实购票站、登录态业务或支付流程的收益，不能把机票演示数据当成真实买票表现。

测量过程按预跑、冻结、正式 A/B、定位问题、独立复测、恢复验证执行。

1. 先做 18 次接入预跑，修复工具 schema 和长工具回执验收问题，确认真实委派可以发生。工具没有加载、主模型没有委派的预跑也保留；它们不作为协作收益证据。
2. 冻结代码快照、配置、提示词、任务、验收器和哈希。正式组为四个多步案例各 5 对，简单对照 2 对，共 22 对 / 44 次。
3. 逐对交替 A→B、B→A，顺序运行。慢运行、未采用委派、真实服务超时和回退都保留，不筛选更快样本。
4. 计时从 DSH 进程启动到退出，包含规划、session 启动、页面加载、操作、最终回答和关闭 session；两组共同的构建、浏览器和 daemon 启动不在任务计时内。
5. HTTP 计时持续到响应结束，主模型请求数与 DSH 持久化会话中的请求记录核对。总耗时拆为主模型 HTTP、Jev HTTP、其余时间；「其余」包含浏览器、CLI、进程启动和本地处理。
6. 成功须同时满足独立任务验收、进程正常退出、显式关闭 session。使用完整持久化工具回执和页面操作证据，不只看模型自述；终端 JSON 对长结果的截断不会被当成事实缺失。
7. 初版数据冻结后，仅修正两个集成细节，另做 4 对 / 8 次复测。最后单独验证故障恢复和安装后的实际调用。

同一批次可能复用浏览器缓存、站点状态及服务侧提示词缓存；交替顺序只能减轻，不能完全消除这些影响。五对样本只适合判断本轮方向，不足以证明所有用户场景都不退化。

初版正式测量共 44 次，任务验收和请求统计核对均通过。 下表单位为秒，正的 B−A 表示协作路径更慢。「配对差值中位数」先对每一对计算差值再取中位数，与两组各自中位数相减不是同一指标。

机票有 4/5 对变慢，表单 5/5 对变慢。信息获取唯一更快的一对，B 组没有调用 Jev，不能将这次收益归因于决策服务。多页检索虽然有 3/5 对更快，但配对差值中位数只有 −0.28 秒；A、B 的耗时范围分别为 36.92–175.81 秒、59.24–127.53 秒，波动较大，尚不支持稳定提速的结论。

20 次多步 B 组任务中，18 次实际委派，2 次主模型选择普通工具；两次未委派也保留在统计中。18 次委派完成了 64 个页面动作，发出 82 次 Jev HTTP 请求。10 次返回子任务完成，8 次交回主模型后完成，包括 3 次低置信度、3 次主动交回和 2 次真实请求超时。两个简单对照的 B 组任务都没有调用 Jev。

调用数下降没有抵消新增的串行开销。 初版主模型请求总数从 324 降至 234，减少约 27.8%，但 B 组新增 82 次 Jev 请求。一次主模型委派可以包含多次决策请求和页面观察，主模型还需要描述约束并消化返回证据。

这批数据中，A 组主模型单次请求中位数约 1.16 秒，B 组主模型约 1.45 秒，Jev 约 1.51 秒。三者处理的任务不同，不能据此比较等价推理能力；但本配置下，不能假定每次 Jev 请求能比主模型省下大量时间。代理往返包含传输、排队和推理，本轮没有将它们进一步分离。

下面按场景给出配对平均差值。三个耗时分量相加得到总变化，显示值因四舍五入可能相差 0.01 秒；这里用平均值分解开销，与上表的中位数口径不同。

例如表单，主模型 HTTP 平均少了 1.28 秒，其他处理平均少了 1.70 秒，但新增 Jev HTTP 为 9.38 秒，最终平均慢了 6.40 秒。数据中能看到明确的新增开销，不能把全部差异都解释为主模型波动。信息获取和多页检索还受到浏览器路径及等待策略影响，需分别定位。

修正版只处理两个已发现的集成问题，并单独报告 8 次复测。

• 继续读取长页面时，原实现会丢掉前段观察上下文。修正版在限定预算内保留事实，旧片段只作为阅读上下文；需要操作时重新获取当前元素引用。
• 历史返回改用已有的 commit 等待条件，随后重新观察页面。独立浏览器复现中，原 domcontentloaded 条件两次等待约 15.02 / 15.01 秒并超时，页面实际已返回；改后两次均约 0.101 秒且页面内容正确。这个收益属于浏览器等待路径，不能算成 Jev 推理提速。

没有修改 BrowserSkill CLI 或扩展，也没有调整模型、置信度阈值、请求上限或任务。原版记录保留，受影响的信息获取和多页检索各复测 2 对：

8 次任务全部正确，但每类仍是一对快、一对慢。信息获取两次均委派完成 3 个页面动作；检索的一次委派执行了 3 个页面动作和 1 次继续观察，另一次在执行动作前就交回，最终都由主模型补齐。本轮复测支持修正后的功能可用，样本还不足以证明稳定提速，也不能把更快的几次全部归因于 Jev。

后续比较决策服务的净收益前，应让普通路径同样使用合理的浏览器等待策略。部分点击中也观察到约 5 秒耗时，本轮没有完成这部分原因定位。

回退能力单独验证，成功率和速度分开评价。 下面三次使用真实 DSH 主模型和真实表单操作，服务故障由适配器注入，因此它们是恢复测试，不是 Jev 线上可靠性样本。

正式 A/B 中另有两次真实 Jev 超时，也都恢复完成。安装后的修正版表单验证执行了 6 个委派动作、7 次 Jev 请求，约 28.20 秒完成，字段正确且只提交一次；它属于安装验证，不纳入 A/B 统计。另有 20 项针对性测试通过，覆盖工具 schema、当前元素引用、多步进度、观察分页、取消、错误操作不重放和服务异常等。

这些结果证明本原型在已测样本中能够保留进度并回退完成任务。由于协作组的多项耗时变长，不能仅凭任务都成功，就声称用户体验不退化。

我建议继续保留有限实验，暂不默认启用。 当前数据支持的下一步是：

• 先定位两组共用的页面等待开销，并在相同等待策略下重新比较。
• 改善委派边界和候选操作覆盖，优先寻找能承担足够多连续操作、又不会产生大量交回和验收开销的子任务。
• 校准路由阈值，并探索把决策开销、低置信度和预算纳入委派条件；始终保留普通工具恢复能力。
• 再扩展到正常有界面浏览器、更多真实业务站点、不同任务输入和更大的冻结样本，持续报告成功率、任务总耗时、回退率与服务成本。

本原型的候选操作未覆盖主模型可使用的全部直达 URL、结构化读取等策略，测到的是这份受限实现的产品路径。结果不足以否定所有决策 API 的潜在价值，也不足以宣传通用加速或省钱。后续范围应由新增证据决定。

实验代码快照、配置哈希、完整会话、页面证据和验收结果已在本地归档。本 issue 提供脱敏后的方法、汇总和全部配对数据；原始会话未公开，实验适配器也尚未作为可下载的主线功能发布。