---
title: 'ClawBench 测到了什么？从真实网页任务到 Judge 可靠性审计'
description: '从真实任务、模型表现和评分链路拆解 ClawBench，并通过混淆矩阵重新审视 Agent-as-Judge 的可靠性证据。'
pubDate: 2026-07-27
updatedDate: 2026-08-01
slug: clawbench-browser-agent-benchmark-judge
lang: zh-CN
tags: [agent, benchmark, LLM-as-Judge]
draft: false
---

一个浏览器智能体打开 DoorDash，选好商品，进入结账页，然后告诉你：“购物车已经准备好了。”

任务完成了吗？

站在聊天窗口里看，好像完成了；站在服务器一侧看，却可能连有效的购物车 ID 都没有。智能体自己说“完成”，页面看起来“差不多”，都不能证明最后那次提交是正确的。

这正是 [ClawBench](https://arxiv.org/pdf/2604.08523) 想测量的问题：不是模型能不能解释怎样订餐、投简历或创建会议，而是它能不能在真实网站上持续执行，直到产生正确的最终请求。

不过，当一个基准不再用固定答案或测试脚本判分，而是让另一个 Agent 阅读执行轨迹并给出 PASS/FAIL 时，问题就多了一层：

> 我们不但要问被评智能体是否可靠，还要问负责判分的 Judge 是否可靠。

本文先看 ClawBench 到底测到了什么，再沿着评分链路检查 Judge 收到了哪些证据、怎样做判断，以及论文给出的可靠性数据究竟能支持多强的结论。

先说结论：

- ClawBench 测量的是“理解任务—读取用户数据—操作动态网站—正确提交—验证结果”的端到端闭环，不是孤立的模型能力。
- 论文中的 V1 Agent-as-Judge 有完整轨迹和人工参考轨迹可供审计，设计上比只看最终回答扎实得多。
- 论文确实做了 prompt 校准和人工复核，但只报告 raw agreement。按表 2 的数据反推，Sonnet 4.6 组表现很好，GPT-5.4 组却出现 Judge 与人工正例完全不重合的情况。
- 当前 V2 排行榜已经改用“请求拦截 + payload Judge”的两阶段评分。V1 的可靠性数据不能自动替 V2 Judge 背书。

> **数据快照**
>
> - 最后核验：2026-08-01；
> - 论文版本：arXiv v2，2026-07-20 修订；
> - 论文实验：V1 任务集，OpenClaw harness，153 道任务；
> - 官网排行榜：V2 任务集，Hermes harness，快照日期 2026-05-20。

## 先把两个 ClawBench 版本分开

截至 2026 年 8 月 1 日，[论文最新版](https://arxiv.org/abs/2604.08523)仍是 7 月 20 日提交的 v2。但这里的“论文 v2”和“任务集 V2”不是一回事。

论文的主实验仍然使用最初的 V1 任务集：

- 153 道任务；
- 144 个真实平台；
- 15 个细分类别、8 个高层领域；
- 统一使用 OpenClaw harness；
- 使用 Claude Sonnet 4.6 驱动的 Agent-as-Judge 阅读完整轨迹。

而[当前官网](https://claw-bench.com/)默认展示的是另一套 V2 任务和排行榜：

- 130 道任务；
- 63 个真实平台；
- 榜单快照日期为 2026 年 5 月 20 日；
- 先检查最终请求的 URL 和 HTTP method，再用 DeepSeek V4 Pro 判断 payload。

两边不仅任务不同，harness 和 Judge 也不同。所以，论文中的 Sonnet 4.6 得到 33.3%，官网 V2 中 Opus 4.7 得到 44.6%，不能直接解释为“模型提升了 11.3 个百分点”。

后文把论文实验称为 **V1/OpenClaw**，把当前排行榜称为 **V2/Hermes**。如果不先固定这个边界，后面的数字很容易变成一锅排行榜粥。

## 一道任务是怎样变成一个分数的

ClawBench 的关键设计，是让智能体在真实生产网站上执行前面的所有步骤，只在最后会产生真实副作用的请求上踩刹车。

**图 1：ClawBench 从任务输入、终态请求拦截到 Judge 判分的完整链路**

```mermaid
flowchart LR
  S([开始：接收 benchmark 任务]) --> A["任务 instruction<br/>用户资料与附件"]
  A --> B["浏览器 Agent<br/>搜索、登录、填写、选择"]
  B --> C["五层轨迹<br/>视频、截图、HTTP、动作、消息"]
  B --> D{"最终请求匹配<br/>任务的 endpoint？"}
  D -- 否 --> F["未完成或进入人工轨迹判定"] --> J
  D -- 是 --> E["拦截 URL、method、payload<br/>不发送到生产服务器"]
  C --> J["Judge"]
  E --> J
  H["人工参考轨迹<br/>目标终态与字段绑定"] --> J
  J --> K{"满足任务要求？"}
  K -- 是 --> P([结束：PASS])
  K -- 否 --> Q([结束：FAIL])
```

论文介绍的安全层会监控浏览器发出的网络请求。人工标注者先完整执行一次任务，找出真正会提交订单、申请、邮件或预约的 terminal request。智能体运行时，系统允许页面加载、搜索、登录和填表正常发生；一旦匹配最终请求，就保存 URL、method 和 payload，并在请求到达生产服务器前阻断它。[论文报告](https://arxiv.org/pdf/2604.08523)，在 153 条人工参考轨迹中，拦截器捕获了全部已标注终态请求，并且没有误拦截正常导航流量。

因此，“没有出现支付成功页”不一定是失败。只要智能体填对了内容并发起正确的付款请求，拦截器就应该让页面停在成功之前。

每次执行同时记录五层证据：

1. 完整会话视频；
2. 每一步的页面截图；
3. HTTP 请求；
4. 点击、输入、滚动等底层浏览器动作；
5. Agent 消息、推理和工具调用。

人工参考运行也使用相同的记录方式，只是没有 Agent 消息。Judge 比较的是实际执行结果与人工目标终态，而不是智能体最后一句自我总结。

## ClawBench 实际测量的四段能力链

ClawBench 官方按生活领域报告成绩，并没有分别输出“规划分”“感知分”或“记忆分”。下面的四组能力，是根据任务和失败轨迹做的分析性拆解，不是官方的四个子指标。

### 1. 从用户数据到网页字段

不少任务的答案不在 instruction 里，而在本地文件中。智能体要先读取文件，再把里面的数据准确映射到网页。

[Greenhouse #86](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/086-job-search-hr-cv-autofill-greenhouse-meta/task.json)要求从 `resume.pdf` 提取信息，填写 CodePath 的 Senior Software Engineer 申请。这里不只是上传简历，还要处理姓名、工作经历、联系方式和职位表单之间的字段对应。

[Overleaf #215](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/215-academia-research-paper-tables-overleaf/task.json)则要求读取 `raw_results.json`，在 Overleaf 创建包含 5 个模型、4 个指标、Average 和 Delta 行的 `booktabs` 表格，并保证 LaTeX 可以编译。

这两题表面上一个是投简历，一个是写论文，底层要求却很接近：

- 找到正确的输入文件；
- 抽取原始数据，而不是凭印象补值；
- 保持跨页面、跨字段的一致性；
- 把文件中的结构转化为网站中的状态修改。

论文在失败分析中发现过智能体填入源材料中不存在的电话号码。这不是“差一点”，而是数据保真已经断掉了。

### 2. 把长任务拆开，同时记住中间状态

[Trello #142](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/142-office-secretary-tasks-collab-trello/task.json)要求创建名为 “Q3 Sprint Planning” 的看板，再根据附件建立 3 个列表和 5 张卡片。附件还包含任务名、负责人、截止日期和优先级。

[Doodle #137](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/137-office-secretary-tasks-calendar-doodle/task.json)要求创建 5 人会议投票，设置 4 个候选时段、每段 60 分钟，并把邀请链接发送给另外 4 人。

这些任务不是一次点击，而是一组相互依赖的状态变化。创建卡片前要先有看板和列表，发邀请前要先生成正确的投票。页面每跳转一次，智能体都要记得哪些对象已经创建、哪些字段还没有填。

论文给出的 Doodle 对比轨迹很说明问题：Qwen 3.5 发现逐周切换日历效率太低后，改用月视图继续推进；GPT-5.4 转向复杂的 JavaScript 绕过方案后退出；Gemini 3 Flash 则重复相同的无效操作直到超时。三者未必不理解“创建会议投票”是什么意思，差别出在执行过程能否保持单调推进。

### 3. 在动态页面上精确行动

真实网站不会为 benchmark 保持静止。Cookie 弹窗、异步 DOM、登录重定向、级联表单、日期控件和反自动化页面都会改变后续路径。

例如，Greenhouse 的字段会随职位变化；Doodle 要操作日历网格；Overleaf 既要编辑文本，又要观察编译结果。表单校验失败以后，智能体还要判断是日期格式、必填字段还是前置选择出了问题。

这部分能力不能简单归结为“视觉识别”。它至少包括：

- 看懂当前页面状态；
- 把目标定位到可执行的点击或输入；
- 等待异步更新真正完成；
- 页面变化后放弃失效的元素引用；
- 发现局部错误时只修复错误字段，而不是从头重来。

论文记录过 Airbnb 上 1204 个动作、549 条消息仍未完成的轨迹。动作很多不代表更努力，有时只是页面状态和 Agent 内部状态已经脱节。

### 4. 走完最后一步，也知道何时该换策略

[Uber Eats #1](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/001-daily-life-food-uber-eats/task.json)要求订一份 Pad Thai，送到用户家庭地址，并备注 “no peanuts”。选到菜品、加入购物车，只完成了前半段；地址、备注、结账和最终 Place Order 都属于任务。

论文把执行深度分成从“没有进展”到“Judge 判定通过”的七个阶段。六个模型的大量失败集中在 S5：已经到达最终确认，却没有发出会改变服务器状态的请求。

不同模型还会以不同方式卡住：

- Gemini 3.1 Flash Lite 的 153 次运行中，131 次以 `agent_idle` 结束；
- GLM-5 有 69 次撞上 30 分钟上限；
- GPT-5.4 有 85 次以 `agent_exited` 结束。

所以低成功率背后至少有三种问题：过早退出、无效循环和最后一步犹豫。把它们都概括成“推理能力不足”，对改进 Agent 没有太大帮助。

## 同一套 OpenClaw 下，模型表现怎样

论文把八个模型放进相同的 OpenClaw harness，使用相同浏览器动作接口、30 分钟上限和 Agent-as-Judge。下表是这组可横向比较的 V1 结果：

**表 1：V1/OpenClaw，153 道任务，30 分钟上限，Claude Sonnet 4.6 Agent-as-Judge；成功率与成本为论文报告值**

| 模型                  |    成功率 | 平均成本/题 | 主要观察                   |
| --------------------- | --------: | ----------: | -------------------------- |
| Claude Sonnet 4.6     | **33.3%** |       $7.51 | 准确率最高，但成本明显更高 |
| Qwen 3.5              | **26.1%** |       $1.02 | 动作和 token 效率较好      |
| GLM-5                 | **24.2%** |       $0.64 | 成本低，但大量运行超时     |
| Gemini 3 Flash        |     19.0% |       $1.55 | 旅行类较强，失败轨迹偏长   |
| Claude Haiku 4.5      |     18.3% |       $1.68 | 开发类任务得分最高         |
| Gemini 3.1 Pro        |      9.8% |       $3.34 | 成本不低，整体成功率偏低   |
| GPT-5.4               |      6.5% |       $1.91 | 工具调用少主要来自过早退出 |
| Gemini 3.1 Flash Lite |      3.3% |       $0.11 | 大量运行进入 idle          |

数据来自论文的[表 3 和图 5](https://arxiv.org/pdf/2604.08523)。需要特别注意三点。

第一，Sonnet 4.6 的 33.3% 已经是最高分。这不是少数离群难题拖低了平均数：153 道题中有 68 道没有任何一个模型完成，没有一道被八个模型全部完成。

第二，领域排名并不一致。Sonnet 在日常、学术和社交任务中领先，GLM-5 在工作类任务中最好，Haiku 4.5 在开发类任务中最好。这说明 ClawBench 不是单一“会不会点网页”的测量。

第三，GPT-5.4 的 6.5% 不能外推成模型的通用能力排名。论文测到的是：

> GPT-5.4 × 当时的 OpenClaw harness × 固定提示词 × 浏览器工具接口 × 网站状态 × Judge。

平均 13 次工具调用和 85 次主动退出更像是代理栈中的终止策略问题，而不是“用很少动作高效完成任务”。官网 V1/Hermes 页面上，同名模型又得到 25.5%，也从侧面说明 harness 会显著改变结果。

## V1 Judge 到底看什么

论文中的 Judge 不是一个比较最终文本的 LLM 分类器，而是 Claude Sonnet 4.6 驱动的 evaluator Agent。

按照论文和公开的 [`eval/agentic_eval.md`](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/eval/agentic_eval.md)，它可以读取：

- 任务 instruction 和 task-card 约束；
- 人工参考轨迹；
- Agent 的视频、截图、HTTP 流量、浏览器动作和消息；
- `run-meta.json` 中的任务与终止信息；
- `interception.json` 中的最终 URL、method 和 payload。

人工轨迹提供的是目标终态和具体字段绑定，但不是要求 Agent 逐步复制人工点击。只要走另一条路径达到语义等价的终态，也可以通过。

公开 rubric 还明确处理了几个容易误判的边界：

- 只加入购物车，没有填结账表单并点击提交，FAIL；
- 使用虚拟支付信息并尝试付款，即使真实支付被拒，也可以 PASS；
- 正确的最终请求被拦截，且此前字段都正确，PASS；
- 卡在电话验证码，但此前步骤完整，可以 PASS；
- 遇到 CAPTCHA 必须尝试，未解决仍是 FAIL；
- Agent 自称完成，不能覆盖页面和网络证据。

公开的 [`eval/README.md`](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/eval/README.md)还描述了批量评测方式：16 个 evaluator subagent 并行处理任务，3 个 supervisor agent 检查一致性，最后合并为 CSV 和 JSON。

这个设计的优点很直接：Judge 能沿着证据回查，而不是相信 Agent 的自我陈述。它的代价也同样直接：最终 PASS/FAIL 依赖另一个模型对大量异构证据的理解。

## 论文怎样证明 Judge 可靠

论文给了两类验证。

第一类是 prompt calibration。附录 D.3 描述了一个迭代过程：准备带人工标签的 held-out 轨迹，用当前 prompt 判分，收集分歧，针对部分完成、拦截提交和替代路径等边界修改规则，然后重新跑完整校准集，避免修好一个案例又破坏另一个案例。

第二类是人工一致率。论文表 2 报告：

**表 2：V1/OpenClaw，每组 153 道任务；Judge 成功率、人工成功率与 raw agreement 为论文报告值**

| 被评模型   | Agent-as-Judge 成功率 | 人工成功率 | Raw agreement |
| ---------- | --------------------: | ---------: | ------------: |
| Sonnet 4.6 |                33.33% |     34.64% |        93.46% |
| GPT-5.4    |                 6.54% |      8.50% |        84.97% |

93.46% 和 84.97% 看起来都不低。但 raw agreement 只是两边标签相同的比例。在成功率很低时，双方一起判 FAIL 就能积累大量“一致”。

这时，我们需要把百分比还原成混淆矩阵。

## 从表 2 反推混淆矩阵

下面是本文根据论文表 2 计算的结果，不是作者直接报告的指标。

每组都有 153 道题。表中的百分比恰好对应整数：

- Sonnet：Judge 判 51 道 PASS，人工判 53 道 PASS，共有 143 道一致；
- GPT-5.4：Judge 判 10 道 PASS，人工判 13 道 PASS，共有 130 道一致。

设 Judge 通过数为 `J`，人工通过数为 `H`，一致数为 `A`，总数为 `N`。因为：

```text
A = TP + TN = TP + (N - J - H + TP)
```

所以：

```text
TP = (A - N + J + H) / 2
```

其余三格也就唯一确定了：

**表 3：根据论文表 2 反推的混淆矩阵；TP、FP、FN、TN 与 Cohen's κ 为本文计算值**

| 模型       |  TP |  FP |  FN |  TN | Raw agreement | 全判 FAIL 基线 | Cohen's κ |
| ---------- | --: | --: | --: | --: | ------------: | -------------: | --------: |
| Sonnet 4.6 |  47 |   4 |   6 |  96 |        93.46% |         65.36% |  约 0.854 |
| GPT-5.4    |   0 |  10 |  13 | 130 |        84.97% |     **91.50%** | 约 −0.080 |

Sonnet 组的结果确实很好。以人工标签为准，它找到了 53 个正例中的 47 个，precision 约为 92.2%，recall 约为 88.7%。即使校正类别比例，κ 仍然约为 0.854。

GPT-5.4 组则完全不同：

- 人工认为成功的 13 道题，Judge 全部判为 FAIL；
- Judge 判为 PASS 的 10 道题，人工全部判为 FAIL；
- 84.97% 的一致全部来自双方共同判 FAIL 的 130 道题；
- 一个不看轨迹、永远输出 FAIL 的分类器，反而能得到 91.50% 的 agreement；
- κ 约为 −0.080，校正类别分布后不比偶然一致更好。

因此，论文可以说“在 GPT-5.4 轨迹上 raw agreement 为 84.97%”，却不能把这个数字直接改写成“Judge 在 GPT-5.4 上有 84.97% 的可靠性”。

这不是说 Judge 一定不可用，而是说当前证据只能支持更窄的结论：它在 Sonnet 组上与人工高度一致，在 GPT-5.4 组上共同识别了很多失败，但没有正确识别任何人工正例。

## 可靠性证据还缺什么

论文已经提供了比很多 LLM Judge 更丰富的审计材料，但要证明它可以稳定充当排行榜 ground truth，还缺少几个关键环节：

- 完整混淆矩阵和正例 precision、recall；
- balanced accuracy 或 Cohen's κ 等抗类别不平衡指标；
- 同一 Judge 多次运行的判分稳定性；
- 不同 Judge 模型、不同 prompt 版本之间的一致性；
- 多名人工评审者的 inter-rater agreement；
- 人工争议案例的裁决方法；
- 校准集规模，以及它与最终人工审计集是否严格隔离。

论文正文还说 Appendix B.1 包含扩展的四模型审计，但在 2026 年 7 月 20 日的公开 v2 中，B.1 展示的是拦截器安全审计，随后直接进入 B.2，没有列出另外两个模型的具体一致率。这可能是论文修订时遗漏了表格，也可能数据发布在其他位置；在看到具体结果前，不应把“四模型审计”当成已经公开可复查的证据。

另一个容易混淆的点是：拦截器在 153 条人工轨迹上达到 100% 命中，证明的是终态请求捕获机制，而不是 LLM Judge 的语义判断。前者回答“有没有拦住预先标注的请求”，后者回答“这条轨迹是否满足自然语言任务”，不能混成一个可靠性结论。

## V2 已经换了另一套 Judge

当前 V2/Hermes 排行榜使用两阶段评分，[`eval/scoring.md`](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/eval/scoring.md)给出了实现边界：

1. **Intercepted**：最终请求的 URL 是否匹配任务正则，HTTP method 是否一致；
2. **Reward**：DeepSeek V4 Pro 在温度 0 下读取 instruction 和被拦截请求，判断 body 是否满足用户要求。

V2 Judge 默认不看截图、视频和完整人工参考轨迹。输入是 instruction，以及压缩后的 URL、method、body；headers 和 body 总长度还会截断到 4 KB 左右。

这套设计便宜、可复现，也能区分“到达正确 endpoint”和“payload 真的正确”。例如，当前榜单中 OpenRouter Owl Alpha 的 Intercepted 是 14.6%，Reward 却是 0%，说明触发某类终态接口并不等于提交内容满足要求。

但它与 V1 Judge 回答的不是完全相同的问题：

**表 4：论文 V1/OpenClaw 与官网 V2/Hermes 的 Judge 输入、模型与判定对象对比**

| 维度                 | 论文 V1 Agent-as-Judge                 | 当前 V2 payload Judge             |
| -------------------- | -------------------------------------- | --------------------------------- |
| Judge 模型           | Claude Sonnet 4.6                      | DeepSeek V4 Pro                   |
| 主要输入             | 任务、人工轨迹、Agent 全轨迹、最终请求 | 任务、URL、method、body           |
| 是否看截图和动作     | 是                                     | 否                                |
| 是否依赖人工参考轨迹 | 是                                     | 默认否                            |
| 判定对象             | 整体任务是否完成                       | 最终 payload 是否满足 instruction |

所以，论文的 84.97%–93.46% raw agreement 不能转移成 V2 Judge 的可靠性证明。V2 需要自己的人工混淆矩阵和稳定性实验。

## 应该怎样阅读一个 ClawBench 分数

ClawBench 最有价值的地方，不是产生了一个新的模型排行榜，而是把“看起来会操作网页”和“真正完成真实任务”之间的差距暴露出来了。

但一个 ClawBench 分数实际测量的是：

```text
模型 × harness × 浏览器观察 × 动作接口 × prompt × Judge × 当时的网站状态
```

阅读排行榜时，可以按下面的顺序检查：

1. 先确认是 V1 还是 V2，任务数和平台是否相同；
2. 再确认使用 OpenClaw、Hermes、Codex 还是其他 harness；
3. 确认主指标是 trajectory PASS、Intercepted、Reward 还是 strict Reward；
4. 检查 Judge 模型、prompt 和输入证据是否相同；
5. 最后再讨论模型排名、成本和领域强弱。

如果其中任何一项发生变化，分数差异都不能简单归因于模型。

## 总结

ClawBench 测到的不是“模型会不会浏览网页”，而是一条很长的可靠性链：

**读取用户数据 → 理解约束 → 规划步骤 → 操作动态页面 → 保持字段准确 → 处理登录和校验 → 发起最终提交 → 用服务器侧证据确认完成。**

当前模型最常见的失败也不只是规划错误。它们会编造字段、在动态 DOM 中迷路、陷入重复操作、过早退出，或者已经站在 Place Order 按钮前，却没有走完最后一步。

论文中的 Agent-as-Judge 为这些复杂轨迹提供了可扩展、可追溯的判分方式。它比相信 Agent 自报成功可靠，也比只看最后一张截图更完整。但可审计不等于已经被充分证明可靠：Sonnet 组的人工一致性证据很强，GPT-5.4 组的 raw agreement 却被大量共同负例抬高，正例判断实际上完全错位。

因此，ClawBench 给出的最重要提醒有两个：

一是浏览器 Agent 离“可靠代办日常事务”还有明显距离；二是当 benchmark 本身依赖 Agent 判分时，我们也必须像审计被评模型一样审计 Judge。否则，排行榜上的小数点很精确，背后的“通过”却未必同样清楚。

## 参考资料

- [ClawBench 论文，arXiv v2，2026-07-20](https://arxiv.org/abs/2604.08523)：论文版本、V1 任务集、模型结果与 Judge 人工一致率。
- [ClawBench 官网排行榜](https://claw-bench.com/)：V2/Hermes 的任务规模、两阶段评分和 2026-05-20 排行榜快照。
- [`eval/agentic_eval.md`](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/eval/agentic_eval.md)：V1 Agent-as-Judge 的输入、rubric 与轨迹判定边界。
- [`eval/README.md`](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/eval/README.md)：批量 evaluator 与 supervisor 的执行方式。
- [`eval/scoring.md`](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/eval/scoring.md)：V2 的 Intercepted、Reward、strict Reward 及 payload Judge 规则。
- V1 任务示例：[Uber Eats #1](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/001-daily-life-food-uber-eats/task.json)、[Greenhouse #86](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/086-job-search-hr-cv-autofill-greenhouse-meta/task.json)、[Doodle #137](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/137-office-secretary-tasks-calendar-doodle/task.json)、[Trello #142](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/142-office-secretary-tasks-collab-trello/task.json)与 [Overleaf #215](https://github.com/TIGER-AI-Lab/ClawBench/blob/main/test-cases/v1/215-academia-research-paper-tables-overleaf/task.json)。