为什么重要
现有计算机使用（computer-use）类基准有一个共同的隐性前提：任务的成功可以被一个简短、可验证的答案判定。WebShop 检查购物车里有没有某件商品，WebArena 检查某条记录有没有被改对。这套设定好评分，但它跟”助理”这个词的含义差得很远。
KNOWS 的出发点正是这个错配。作者对助理的定义是：
“A useful assistant retrieves information across complex, multi-step workflows, synthesizes it into artifacts (documents, presentations, spreadsheets), and navigates program interfaces to produce a coherent final product.”
关键在于最后半句。Deep Research 类基准（DeepResearchBench、Mind2Web 2、DEER）已经要求模型跨站检索并产出长文本报告，但在真实办公场景里，一份纯文本报告几乎从来不是交付物——结论要被排进幻灯片、表格和文档，而这些产物的有效性取决于视觉、空间和结构选择：内容放在哪里、用什么颜色、配什么图、表格怎么组织。
KNOWS 是第一个把这三件事——实时网页检索 + 生产力工具操作 + 视觉空间理解——串到同一条任务链上的基准。它的全称 K N owledge N avigation and O rganized W eb S ynthesis 就点明了这个结构：先导航取知，再组织成 Web 上的合成产物。
而结果相当清醒：没有任何一个被测系统在全任务集上的严格全对率超过 3%。
四个指标：为什么要搞这么复杂
长程开放式任务的一个必然问题是——如果只报”完全成功”，几乎所有系统都是 0，读不出任何信息。KNOWS 因此给出四个指标，其中三个是不同口径的部分成功：
| 指标 | 定义 | 读法 |
|---|---|---|
| SR（Success Rate） | 所有步骤全部通过的指示函数 | 严格全对率——“交付物真的能直接用吗” |
| ASC（Avg Step Completion） | 各步骤”完全通过”指示值的均值 | 宏观平均的严格步通过率 |
| ACF（Avg Completion Fraction） | 各步骤得分率 k/S 的均值 | 宏观平均的部分得分率 |
| SF（Step Fraction） | 总得分 / 总分 | 微观平均的部分得分率 |
四者的分工很清楚：SR 是终极门槛，SF 是最宽松的”干了多少活”。ASC 与 SF 的落差是本基准最重要的读数——当 SF 高而 ASC 低，说明系统做了一大堆事但几乎没有一步做得完整。
构建方式
任务设计 rubric（五条硬约束）
作者先把设计意图翻译成一份可执行的 rubric，每条任务必须同时满足：
- 真实性（realism）——真实用户会想做、且自动化后确实省时的任务
- 显著信息检索——必须浏览实时网页，从至少 2 个网站取回至少 5 条信息
- 视觉或空间成分——识别/编辑特定元素、观察空间关系（左/右/上）、或基于颜色的修改（例如”删除所有红色链接”）
- 制品合成——把检索结果组织成实际产物
- 复杂度——至少 4 步信息检索、多步制品创建、总步数至少 10 步
产物平台选 Google Workspace（Drive / Docs / Sheets / Slides），理由是用户基数大、几乎支持任何领域的真实场景、且有 API 可做程序化评测。
任务写作流程
用 Google Colab notebook 引导 annotator：先按 Workspace 模板类别头脑风暴任务提示（允许偏离，也允许用 LLM 辅助）→ 逐条对照 rubric 自查 → 写下 checkpoint 与 evaluation step 描述。
之后第二个 annotator 独立复核：重走一遍 rubric，不满足就修改或退回。初始种子集收齐后，再做种子扩写——例如把”为 7 年级观众做电子游戏史演示”改成”为 10 年级观众做 CRISPR-Cas9 演示”，保留大部分步骤描述但大幅换内容。
成本值得记一笔：每任务从零到完成平均需要 9–18 小时的专家工作量。这是本基准选择”深度优先于规模”（110 个任务）的直接原因——WebArena 与 VisualWebArena 选择了更广的覆盖，KNOWS 选择了更长的任务。
评测器：混合判定
这是 KNOWS 最实质的贡献，作者自己也把它列为主要贡献之一。评测开放式 Agent 输出存在丰富性 / 可靠性 / 自动化的三难：LLM-as-a-judge 能扩展但不可靠；纯确定性检查可靠但要求输出高度受限。
KNOWS 的解法是给每个任务写一个专用 evaluator 脚本，在脚本内部按步骤选判定方式：
- 能确定性判的就用 API 查：是否存在某元素、幻灯片顺序、标题颜色、精确/容差字符串匹配、几何包围盒重叠、树查询
- 必须语义判的才交给仔细 prompt 过的 LLM / VLM：图片是否切题、内容是否被引用 URL 支撑
结构上是 任务 → checkpoints（离散子目标）→ evaluation steps（最小判分项），逐级独立打分。
基准概览
| 统计量 | 值 |
|---|---|
| 任务总数 | 110 |
| 领域数 | 20（11 个来自 Taxonomy，9 个来自 Extension） |
| 提示词长度 | 均值/中位数 204.4 / 165.0 词；13.7 / 12.0 句 |
| 每任务 checkpoint 数 | 均值/中位数 5.9 / 5.0；范围 4–9 |
| 每任务评测步数 | 均值/中位数 24.6 / 23.0；范围 9–70 |
| 评测步总数 | 2,716 |
| 人工完成单任务耗时（估算） | 约 3 小时 |
评测步按检查类型分布（2,716 步）：
| 步类型 | 步数 | 占比 | 出现在多少比例的任务中 |
|---|---|---|---|
| Structural（结构） | 835 | 30.7% | 90.9% |
| Information Retrieval（信息检索） | 748 | 27.5% | 100.0% |
| Formatting（格式） | 332 | 12.2% | 78.2% |
| Content（内容） | 229 | 8.4% | 54.5% |
| Spatial（空间） | 199 | 7.3% | 59.1% |
| Web Visit（网页访问） | 189 | 7.0% | 68.2% |
| Visual（视觉） | 184 | 6.8% | 63.6% |
信息检索步出现在 100% 的任务里——这与 rubric 的硬约束一致，也说明”检索”在 KNOWS 里是必要条件而非主要难点。真正的区分度来自只占 14.1% 的 Spatial + Visual 步。
完整结果（论文 Table 3，Overall 列按 SF 降序）
| 系统 | 输入模态 / Harness | Docs SR | Sheets SR | Slides SR | Overall SR | Overall ASC | Overall ACF | Overall SF |
|---|---|---|---|---|---|---|---|---|
| Perplexity Comet | AI 浏览器（闭源） | 12.0 | 0 | 2.7 | 2.7 | 35.4 | 70.0 | 64.7 |
| GPT-5.5 | 多模态（AXT + 截图） | 0 | 0 | 0 | 0 | 21.8 | 49.5 | 46.7 |
| ChatGPT Atlas | AI 浏览器（闭源） | 0 | 0 | 0 | 0 | 21.6 | 45.4 | 40.6 |
| Claude Opus 4.7 | 多模态（AXT + 截图） | 0 | 0 | 0 | 0 | 16.7 | 42.5 | 39.1 |
| GPT-5.5 | 纯文本（AXT） | 0 | 0 | 0 | 0 | 20.6 | 41.9 | 38.0 |
| DeepSeek V4 Pro | 纯文本（AXT） | 0 | 0 | 0 | 0 | 12.6 | 31.1 | 26.4 |
| Claude Opus 4.7 | 纯文本（AXT） | 0 | 0 | 0 | 0 | 6.4 | 17.0 | 13.6 |
分产物类型看，Comet 在 Docs 上 SR 12.0、Slides 上 2.7、Sheets 上 0——文档类任务最接近底层 LLM 擅长的纯文本输出，表格类最难。
关键发现
1. 严格全对率接近零，唯一的非零来自”最像聊天”的那类任务。 全表 SR 只有三个非零格，全在 Comet 行（Docs 12.0、Slides 2.7、Overall 2.7）。作者对此的判断是：文档任务”resemble the conversational, text-only outputs best suited for the underlying LLMs”——不是文档任务简单，而是它最贴合模型原本的能力形状。
2. 部分成功分数的”可用性幻觉”是本基准最锋利的结论。 论文 Figure 3 展示了 Comet 在一个 Slides 任务上的产出：ACF 0.54、SF 0.59（看起来过半），但 ASC 只有 0.14，而实际产物被作者直接定性为”a visual mess”、practically unusable。
这条要怎么读：SF/ACF 是”干了多少活”，ASC 是”有多少步做完整了”。 当二者严重背离（0.59 vs 0.14），说明 Agent 在每一步都做了一部分，但没有一步做到位——这对真实交付毫无意义。凡是只引用 SF 或 ACF 而不看 ASC 的引用，都会系统性高估能力。
3. 视觉输入是最大的单点增益，而且增益幅度远超换模型。 给 Claude Opus 4.7 加上截图（AXT → AXT+SS）：ASC +10.3、ACF +25.5、SF +25.5。对比之下，同样在纯文本档位上换模型，GPT-5.5（SF 38.0）与 Opus 4.7（SF 13.6）差 24.4——加截图带来的提升（+25.5）比换一个模型的差距还大。
4. Harness 至少和模型一样重要——这是论文自称”最刺眼”的发现。 同一套 backbone（Opus 4.7），换 harness：Comet harness 比 BrowserGym harness 高出 +2.7 SR、+18.7 ASC、+27.5 ACF、+25.6 SF。作者把原因指向实时网页浏览能力（复杂页面、弹窗广告处理）上的差距。
这条与经验 19（ARC-AGI-3 上同权重双脚手架差 37pp）是同一个族：在 Agent 场景里，“哪个模型”能解释的方差可能还不如”用什么脚手架”。
5. 失败可以被逐步归因，而归因结果指向”保真度/布局/结构”而非检索。 对 Comet 全部 110 个实例的逐步分析显示，它按判定机制的表现是：
| 判定机制 | 通过率 |
|---|---|
| Exact Match（精确匹配） | 83.2% |
| Model Judgment（模型判定） | 68.9% |
| Geometric（几何） | 65.2% |
| Tolerance Match（容差匹配） | 65.1% |
| Tree Query（树查询） | 60.8% |
最强的恰好是最机械的精确匹配（83.2%），最弱的是查结构的树查询（60.8%）。而且树查询的 124 次失败里有 84 次来自同一个种子任务——Comet 生成的演示稿完全没有请求的幻灯片结构。作者的总结是：Agent 能找到正确的信息，但在保真度、布局与结构上失败。
6. 检索也并没有被解决。 Comet 只通过约三分之二的信息检索步骤。这点容易被”Comet 是 AI 浏览器”的印象掩盖——它最强的地方也只到 66%。
局限性与引用注意
- 实时网页依赖：任务有效性部分取决于评测时刻的网页状态。作者的缓解办法是刻意挑”信息可从多个网站获得、且不随访问日期改变”的任务，但依赖无法根除。
- 产物范围限于 Google Workspace：只覆盖 Sheets / Slides / Docs 三类。副作用是在 Google Workspace 上专门训练过的模型会拿到结构性优势；作者用 5 个任务在 Microsoft 365 网页版上做了小规模跨平台抽查，但完整跨平台评测不在范围内（很多确定性检查依赖 Google API）。
- 无受控人类基线：论文只按 Drive Activity API 的编辑日志估算人工耗时（约 3 小时/任务），明确说明不报告受控人类基线。因此不要给 KNOWS 引用任何”人类水平 X%“的数字。
- 规模 vs 深度的取舍：110 个任务、20 个领域，作者主动承认可能覆盖不到真实网页使用的全部广度。
- ⚠️ 论文本身存在一处轻微内部不一致：Table 1 的评测步总数为 2,716，而 Figure 4(b) 标注为 2,697（其 (a) 图为 2,697 − 189 网页访问步 = 2,508）。差 19 步。不影响任何结论的方向，但逐步计数不要混用两处。
- 成本不可横向比较：Comet 与 Atlas 是消费级订阅产品，不暴露 token 消耗或动作轨迹，因此论文无法统一报告 token/步骤效率。
关联基准
- DeepResearch Bench：同为跨站检索，但产出是文本报告而非结构化制品
- WebArena：更广覆盖、更短任务的经典网页 Agent 基准
- OSWorld 2.0：桌面 GUI 侧的计算机使用评测
- GAIA：通用 AI 助理，含检索与工具使用
- AssistantBench：面向真实助理任务的开放式评测