> For the complete documentation index, see [llms.txt](https://getsquish.gitbook.io/squish/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://getsquish.gitbook.io/squish/zh/can-kao/benchmarks.md).

# 基准测试：epic-squish-demo

一个共享的、公开的基准，用于 [导航循环](/squish/zh/primitive/the-navigation-loop.md)：一个已托管的剪辑、一个固定的真值表，以及一组带容差的固定问题集。可以让任意客户端——远程 MCP 端点上的官方 AI 应用、CLI 上的编码代理、stdio MCP 客户端——对同一组问题进行运行，并比较答案、精度，以及每个客户端需要多少导航步骤。

## 该剪辑

|             |                                                                                          |
| ----------- | ---------------------------------------------------------------------------------------- |
| **URL**     | `https://getsquish.app/assets/content/epic-squish-demo.mp4`                              |
| **时长 / 大小** | 10.005 秒 · 约 2.5 MB · 没有与任务相关的音轨                                                         |
| **内容**      | 在一条沙地小路上，一个红球孤零零地躺着。粉色的 Squish 章鱼飞了进来，送来一个绿球，把它推到红球旁边；接着一个黄球到来，章鱼又飞走了。每个事件都是一个不到一秒的导航目标。 |

这个剪辑足够小，适用于所有场景：把 URL 传给远程 MCP 端点，或者先下载一次，再在本地文件上运行 CLI / 本地 MCP。

## 真值

通过查看接触表来固定——而不是靠猜测。每个事件都列出了读取时所在的区间，以及该读取时的单格间距；根据 [引文规范](/squish/zh/ru-men/for-ai-agents.md#behavior-rules-once-you-have-a-sheet)，两个单元格之间的事件应引用为该区间，而绝不能编造成一个中点。

| 事件           | 真值                                            | 读取于       |
| ------------ | --------------------------------------------- | --------- |
| 红球           | 从 0:00 起就存在——它从未 *进入*                         | 3×3 总览    |
| 章鱼首次出现（鳍，右上） | **0:02.9** （区间 0:02.82–0:02.92）；完整头部约在 0:03.1 | 94 毫秒单元格  |
| 绿球首次进入（右边缘）  | **0:03.2–0:03.3** （第一个细小边缘；到约 0:03.4 时已清晰入镜）  | 94 毫秒单元格  |
| 红球和绿球首次接触    | **0:04.53–0:04.56**                           | 30 毫秒单元格  |
| 黄球首次进入（左边缘）  | **\~0:06.0** （到 0:05.96 时可见一小条）               | 62 毫秒单元格  |
| 章鱼开始离开       | **\~0:06.8** （可见起飞）                           | 106 毫秒单元格 |
| 章鱼完全消失       | **\~0:07.9**                                  | 106 毫秒单元格 |

来源：首次固定于 2026-07-11（3 次 CLI 调用，读取 41 帧）；于 2026-07-14 针对托管 URL 使用 `@getsquish/squish@0.2.3` 从 npm 仓库进行了独立复核（3×3 总览 + 4 个放大窗口，共 73 帧）。两次结果在每个事件上都只相差一个单元格间距以内。

## 问题集

| # | 问题（原文）                                         | 预期                                                      | 容差     | 测试                                 |
| - | ---------------------------------------------- | ------------------------------------------------------- | ------ | ---------------------------------- |
| 1 | *“这些彩球按什么顺序出现？每个球第一次进入画面的准确时间码是什么？请精确到十分之一秒。”* | 顺序：红球（从一开始就存在——好的答案会注意到它并没有进入）→ 绿球约 0:03.3 → 黄球约 0:06.0 | ±0.2 秒 | 主打题：仅靠一个总览无法回答——会迫使使用多窗口放大循环       |
| 2 | *“章鱼第一次出现是什么时候，什么时候又完全消失？”*                    | 首次约 0:02.9 · 完全消失约 0:07.9                               | ±0.2 秒 | 两个目标位于相反两端 → 需要窗口规划                |
| 3 | *“红球和绿球第一次接触的时间码是多少？”*                         | 0:04.53–0:04.56                                         | ±0.1 秒 | 精度压力测试——需要三级放大（约 30 毫秒单元格）才能在容差内作答 |
| 4 | *“是谁送来了这些球？”*                                  | 粉色章鱼（它送来了绿球和黄球；红球原本就在那里）                                | —      | 跨窗口的叙事拼接                           |
| 5 | *“章鱼发出什么声音？”*                                  | 拒绝回答：活动时间无法识别声音，而且这个剪辑没有相关音轨                            | —      | 音频边界诚实性                            |

## 评分

* **机制** — 在容差内的时间码算通过。若超出容差，真正值得关注的问题是 *为什么*：窗口选错、密度对该结论来说太粗，或者读错了单元格。
* **引文规范** — 一个答案永远不能比实际读取到的单元格更精确。“在 0:04.5 和 0:04.6 之间”来自 100 毫秒单元格，是一个 *更好* 的答案；即使数值碰巧正确，没有匹配放大的精确数字也算失败。
* **导航成本** — 统计导航决策（总览 → 定位 → 精细化），而不是提示词。问题 1 通常需要 3–4 次工具调用即可解决；问题 3 需要再多一层。相同准确率下，调用次数越少，导航越好。

## 运行方式

```bash
# 总览
npx -y @getsquish/squish epic-squish-demo.mp4 --json

# 放大循环（评分者使用的窗口）
npx -y @getsquish/squish epic-squish-demo.mp4 --start 2.5 --end 4.0 --density 4x4   # 章鱼 + 绿球进入
npx -y @getsquish/squish epic-squish-demo.mp4 --start 4.3 --end 4.8 --density 4x4   # 红球-绿球接触（约 30 毫秒单元格）
npx -y @getsquish/squish epic-squish-demo.mp4 --start 5.5 --end 6.5 --density 4x4   # 黄球进入
npx -y @getsquish/squish epic-squish-demo.mp4 --start 6.5 --end 8.2 --density 4x4   # 章鱼离开
```

在远程 MCP 端点上，把托管的 URL 作为 `video_url` 传入，并使用相同的 `start`/`end` 窗口。这个基准的目的不是让你直接复用这些精确窗口——而是看代理是否 *能自己找到* 它们。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://getsquish.gitbook.io/squish/zh/can-kao/benchmarks.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.