验证¶
在 macOS 上使用 Node v24.22.1 于 feat/scenario-request-timing b92a11b6(基于 main d87e73f2)执行,并在搭载 snap Chromium 155 的 Ubuntu 24.04 虚拟机上完成了录制。
门禁¶
npm run -s typecheck、lint、format:check、docs:check、mcp-catalog:check、verify:test-discovery、scan:todos和npx knip:全部通过。npx vitest run --project domain --project services --project adapters:16,380 个通过,1 个失败:"stops Inspector target authorization after the current stat settles",该失败在 main 分支此环境中以相同方式失败。- 浏览器与场景 MCP 和 CLI 边界、工具模式有效性以及分析视图 MCP 边界:全部通过。
- 在真实 Chrome 中运行
npm run -s verify:browser:network:10 个请求中的每一个都携带observed_at,每个已完成的请求都携带浏览器的started_at和elapsed_ms(10 个中有 9 个;第十个是测试夹具中故意未完成的流)。 - 在此变更之前生成的捕获,其解析和投影与之前完全一致:已发布的 Pinry(568 个请求)、PhotoPrism(277)和 Lychee(134)捕获在 main 分支和本分支上生成字节完全相同的清单和状态视图,包括 Evidence id 和摘要。
相同捕获:带与不带请求时间¶
下面的每个捕获均使用本分支录制,然后构建两次:一次按录制原样构建,另一次移除其请求时间,并按提供方封装 Evidence 的方式重新封装。二者之间的差异完全来自本次变更。
| 捕获 | 记录数 | 不带/带时间的时间线 | 不带/带时间时提供的写入 |
|---|---|---|---|
| Linkding,根据提示词由代理录制 | 60 | 记录顺序 / 开始时间 | 1 / 4 |
| Linkding,根据提示词由代理录制(再次) | 65 | 记录顺序 / 开始时间 | 3 / 3 |
| Homebox,根据提示词由代理录制 | 263 | 记录顺序 / 开始时间 | 2 / 3 |
| Homebox,根据提示词由代理录制(再次) | 275 | 记录顺序 / 开始时间 | 2 / 2 |
| Pinry,其已发布场景重新录制 | 568 | 记录顺序 / 开始时间 | 0 / 0(学习到 1 条时钟规则) |
| PhotoPrism,其已发布场景重新录制 | 273 | 记录顺序 / 开始时间 | 2 / 2(学习到 2 条时钟规则) |
- 带时间的情况下,Linkding 的书签和捆绑包编辑以及 Homebox 的标签编辑得以提供:其响应带有应用程序设置的修改时间,而这只有时钟规则才能解释。PhotoPrism 提供的相册创建现在根据时钟标记
CreatedAt和UpdatedAt,而不是重放记录中的值。没有任何捕获提供的写入变少。 - 第二次 Linkding 和 Homebox 录制没有额外收益,因为它们的缺口在别处(
unconfirmed和contradicted写入):代理的录制选择对覆盖率的影响大于时间信息。 - 基于提示词构建的录制使用了本分支的一个本地未推送构建,并与提示词 PR(#6946)合并,该 PR 添加了它们所需的
request场景动作。Claude Code(claude-sonnet-5-5)根据一段话的提示词录制了每个应用,正如该 PR 的端到端检查所做的那样。 - 带有四个已提供写入的 Linkding 捆绑包使用
fireworks_ai/gpt-oss-120b和fireworks_ai/glm-5p3-flash通过了该应用的全部三个写入任务(任务实体数量相对于捆绑包自身状态计算,该状态将活跃和已归档书签作为两种类型持有);此前基于提示词构建但未带时间录制的 Linkding 捆绑包则一个任务也未通过。Homebox 捆绑包使用 gpt-oss 通过了其两个写入任务,使用 GLM 通过了一个(GLM 删除了错误条目)。最终构建中基于提示词录制的捆绑包能启动并完成检索:Linkding 通过了其冒烟测试任务以及 8/8 和 7/8 的检索任务,Homebox 通过了冒烟测试任务以及 3/3 和 3/3 的检索任务。
过时的已发布环境¶
Pinry 和 PhotoPrism 是最早以浏览器场景形式发布的环境(版本 0.1.0,仅重放)。两者均使用本分支根据其已发布场景在全新且已注入种子数据的实例上重新录制,并使用发布流水线重新构建:
| 应用 | 已发布的 0.1.0 | 使用本分支重新构建 |
|---|---|---|
| Pinry | 12 个工具、重放、检索 6/6 和 6/6 | 12 个工具、状态与时钟、未提供任何写入;检索 6/6 和 4/6 |
| PhotoPrism | 13 个工具、重放、检索 10/10 和 10/10 | 14 个工具、状态与时钟、提供相册创建和重命名;检索 8/10 和 5/10 |
两者均无改善,因此均未重新发布。检索下降并非来自时间信息:在任务读取的每个视图中,带时间与不带时间的状态完全一致。PhotoPrism 的相册列表按名称顺序从状态中得到回答,而生成该任务时记录下的响应却将另一相册列在首位;Pinry 的两个 GLM 未命中是因为工具调用将 limit 和 offset 作为数字传入而被拒绝,且工具模式与已发布版本完全相同。
审查¶
独立审查重新构建了本分支并试图反驳它。它确认了早期捕获的字节完全相同的视图,确认了带时间与不带时间之间的比较是对同类进行比较,确认了每条记录的持续时间仅来自其自身事务,并且确认了两个字段均计入事件预算。其发现已得到处理:记录现在从浏览器自身的开始时间而非提供方的观察时间开始,后者在读取其他响应期间最多落后 36 ms;文档给出了回退的延迟、更早的 REA 版本会拒绝携带这些字段的捕获,以及比较的归一化摘要会发生变化;测试覆盖了回退、部分未带时间的捕获以及未带时间捕获的比较。
本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 rea2/rea