论文链接：

• AskStream: When and What to Ask Proactively under Uncertainty in Streaming Video Understanding (arXiv:2610.38678)
• Co-Design Bench: Multimodal Collaborative Coding Evaluation for Agentic Models (arXiv:2610.35138) 项目主页：Co-Design Bench；AskStream 的 Website/Code/Data 链接见论文首页 发表时间：均于 2026 年 10 月下旬提交 arXiv（AskStream v1 于 10 月 28 日、Co-Design Bench v1 于 10 月 26 日） 机构：
• AskStream：中科院自动化所（认知与决策智能复杂系统重点实验室）+ 北京人工智能研究院（BAAI）+ 湖南师范大学 + 中央民族大学
• Co-Design Bench：复旦大学 + 阿里巴巴 Token Hub + 浙江大学 + 香港中文大学 + 上海交通大学 + 南洋理工大学 领域标签：cs.CV / cs.AI / 评测基准（流式视频主动交互、Agentic 编码评测）

一、引言：模型什么时候「该问」，什么时候「算做完」

大模型能力评测正在经历一场静悄悄的范式转移。早期的基准问的都是「这道题你会不会」：给一段完整视频、一个明确问题、四个选项，模型选一个，答对得分。后来的基准开始问「你什么时候答」：视频在流式到达，证据够不够就动手，时机本身就是能力。而 2026 年 10 月底出现的这两篇论文，把问题又往前推了两步：

• AskStream 问的是：当回答所需的信息永远等不到时，模型知不知道自己该开口要？——流式视频理解中，模型面对的不再只是「wait 还是 answer」的二选一，而是「wait、ask、answer」的三选一。什么时候问（when to ask）、问什么（what to ask）、什么时候答（when to answer），三个决策都要考。
• Co-Design Bench 问的是：一个编码 Agent 把用户需求做到了几成？——它不满足于「任务完成/未完成」的二值判定，而是把每个真实用户请求拆解成逐条可审计的验收标准，逐条打分，然后揭示一个尴尬的事实：最强的模型平均能通过 69.9% 的标准，却只有 26.4% 的任务能把所有标准全部满足。

两篇论文一篇来自视觉交互领域、一篇来自编码智能体领域，表面上毫无交集，但读完全文会发现它们在做同一件事：把评测的颗粒度从「最终输出」下沉到「过程行为与证据链」。AskStream 评的是模型在时间轴上的每一步行为（等待、追问、作答的时机与内容），Co-Design Bench 评的是模型交付物背后每一条主张的证据（源码、渲染截图、浏览器操作日志）。一个是时间维度的过程审计，一个是证据维度的过程审计。

更有意思的是，两篇论文都给出了一个「看起来不差、实际上很远」的诊断结论：AskStream 最强模型 Ask-F1 52.18%（看似及格，但 oracle 分析显示仅补上「何时问」这一项就能涨 21.13 点）；Co-Design Bench 最强模型标准通过率 69.9%（看似不错，但全过率仅 26.4%）。平均分掩盖了结构性短板——这是两篇论文共同的方法论主张，也是本篇精读要把它们放在一起读的理由。

第一篇：AskStream——主动追问作为第三动作

二、论文一：题目与背景

2.1 题目拆解

论文标题「AskStream: When and What to Ask Proactively under Uncertainty in Streaming Video Understanding」信息量很大：

• AskStream：名字本身就是命题——让「ask」（追问）成为流式（stream）交互的一等公民动作；
• When and What to Ask：追问本身被拆成两个正交能力——时机与内容，这也是 Ask-F1 指标的设计依据；
• Proactively：主动，不是被动等用户澄清，而是模型自己意识到信息缺口并开口；
• under Uncertainty：不确定性是问题之源，且论文会把它系统性地分类；
• Streaming Video Understanding：场景是连续到达的视频流，不是看完再答的离线视频。

2.2 背景：交互范式三部曲与那个被忽略的假设

论文用 Figure 1 勾勒了视频交互范式的演化：

1. 离线范式（Offline）：模型看完整个视频再回答。任务核心是「怎么答」（how to answer）。
2. 流式范式（Streaming）：视频连续到达，模型要实时理解、维护记忆、即时交互。但仍以实时响应为主，不适合异常告警、流程指引这类需要「等时机」的场景。
3. 主动范式（Proactive）：模型持续监控视频，自己决定「何时答」（when to answer）。ProactiveVideoQA、ProReady-QA、IPIBench 等基准沿这条路把响应时机越做越细。

但现有主动范式有一个共同的隐含假设：回答所需的信息都完整地包含在流里，只是还没到，模型终归等到。于是动作空间只剩 wait 和 answer 二选一。现实世界并不配合——信息可能因为视频侧或用户侧的不确定性而永久缺失：关键实体被遮挡、视角看不到、用户的指代含糊、用户的问题本身有错、偏好根本没说过。此时只会 wait 的模型将永远等下去，只会硬答的模型产出高幻觉响应。

2.3 一个先导实验：问一问，值多少分

在立论之前，作者先做了一个量化实验（附录 A.3）：在 Qwen3.5 9B 上分析 78 个视频的 130 个五选一事件，追踪模型对五个候选答案的概率分布与归一化熵。三组对照：

• 正确揭示（Correct reveal）：把模型该问的那个关键证据在提问后 1 秒给出；
• 错误揭示（Mismatched reveal）：给一个同时段无关实体的证据；
• 基线：模糊（Blurred，关键实体被遮）与全清晰（Full）两种输入。

结果非常干净：正确证据让归一化答案熵在三个交互轮次中持续下降、把概率质量推向正确答案；错误证据几乎不降熵。落到最终数字上：模糊输入下准确率 42.3%、金答案平均概率 25.8%；问过并拿到关键证据后准确率升到 62.3%、金答案概率 36.8%；而全清晰输入也不过是 63.1% 与 36.6%。也就是说，「问对了」几乎等价于「本来就看清楚了」。这个实验为「值得为 ask 建一个基准」提供了实证地基。

三、论文一：定位与问题定义

3.1 定位：第一个引入 ask 动作的流式多轮基准

AskStream 自我定位为首个在流式视频主动范式中纳入 ask 动作的多轮基准。与既有工作的差异在 Table 1 里一目了然：ProactiveVideoQA、ProReady-QA、IPIBench 等主动基准要么只标时间戳不标时间窗、要么不支持帧级标注（FL）、要么没有 ask 动作、要么不做多轮（MT）交互——AskStream 是唯一全项打勾的，且同时支持多选（MC）与开放（OE）两种评测设定，平均选项数 9.44、平均时长 11.0 分钟。

与它最接近的两个工作都局限在静态图像：ClearVQA 处理视觉歧义、ProactiveBench 支持移除遮挡等动作，但都不区分不确定性的来源，流式视频上的主动信息获取此前是空白。

3.2 问题形式化：POMDP 与三类时间窗

任务被建模为部分可观测马尔可夫决策过程（POMDP）：隐状态刻画视频流与用户流中缺失的信息，模型在每个决策点只依据已观察视频、用户查询与历史交互，从 WAIT / ASK / ANSWER 三个动作中选一个，每秒一次决策机会。

基准的精髓在时间窗标注。视频流被切分为多个事件，事件 i 从查询 qᵢ 到达开始、到下一个查询 qᵢ₊₁ 结束。根据不确定性何时可被识别，事件分两类：

• Type I（先等后问）：初始观测不足以识别不确定性，必须等到相关证据出现才能意识到「我该问」。此时只标 WAIT 窗 [qᵢ, sᵢ) 与 ANSWER 窗 [sᵢ, eᵢ)，有效的 ASK 必须落在 ANSWER 窗内（aᵢ ∈ W^answer）——即证据出现之后、答案窗口关闭之前。
• Type II（先问后等）：初始观测已足以识别不确定性（比如问题里提到的私有概念 {Noni} 是谁，第一秒就该问）。此时标注 ASK 窗 W^ask ⊆ [qᵢ, sᵢ) 与 ANSWER 窗，模型应在 ASK 窗内发问，然后等证据到达再答。

一个回合成功当且仅当：模型在合法窗口内发出内容正确的 ASK，随后在 ANSWER 窗内给出正确答案。每回合至多一次 ASK 与一次 ANSWER（主设定），正确的 ASK 会触发用户提供缺失信息。

3.3 不确定性分类学：2 大类 4 中类 8 子任务

这是基准的组织骨架，也是论文最有 taxonomic 价值的部分：

视频不确定性（Video Uncertainty）

• 显式（证据本身缺失）：
  • KVEM（Key Visual Evidence Missing）：关键实体被高斯模糊遮挡，模型应请求展示该实体的清晰视频；
  • VIM（Viewpoint Information Missing）：当前视角看不到答案所需证据，模型应请求切换到能看到的视角；
• 隐式（证据在但概念缺失）：
  • ICM（Individual Concept Missing）：视频清晰，但用户提到的私有实体别名（如 {Noni}、{Buddy}）模型不认识，应向用户索要概念定义；
  • PACM（Personalized Action Concept Missing）：用户自定义的动作概念（如「Vexalia」）不在模型先验里，应索要动作演示视频。

用户不确定性（User Uncertainty）

• 意图不确定：
  • AUQ（Ambiguous User Question）：指代含糊（「穿西装的男人」而画面里有两个），应请求消歧；
  • WUQ（Wrong User Question）：问题含错误前提（说戴棒球帽而视频里是毛线帽），应指出并纠正前提；
• 偏好不确定：
  • UPM（User Preference Missing）：答案依赖未知偏好，应询问具体偏好维度；
  • UPC（User Preference Conflict）：历史偏好已过时（搬了新家），应确认当前偏好。

八个子任务的交互时机各有归属：显式视频不确定走 Type I（先等证据出现才知该问），隐式视频与用户偏好走 Type II（一开始就该问），用户意图则横跨两型。这个分类学的价值在于：它把「信息缺口」从模糊概念变成了可枚举、可单独计分的八个槽位。

四、论文一：解法（基准与指标设计）

4.1 Ask-F1：时机与内容的联合度量

评测指标 Ask-F1 借鉴了时机感知评测的思路，但把 ask 与 answer 两个阶段一起纳入。对回合 i，aᵢ 与 ρᵢ 是 ASK 与 ANSWER 的时刻，W^a、W^ρ 是各自合法窗口，I^a、I^ρ 指示内容是否正确。核心构件：

• 时间衰减函数 T(t; [s,e)) = 𝕀[s≤t<e) · (1 − (t−s)/(e−s))——落在窗口内才有分，且越早得分越高（线性衰减到窗口末端为零）。作者的理由很实际：窗口起点意味着信息已备齐，无谓拖延不产生效用。
• S^ask：全部回合上「内容正确」的 ASK 的时间加权平均分；
• S^ans：条件分数——只在成功发出正确 ASK 的回合（N^ask 个）上计算 ANSWER 的时间加权平均分。

最终 Ask-F1 = 2·S^ask·S^ans / (S^ask + S^ans)，谐波聚合。

两个设计决策值得细品（附录 A.2 有专门论证）：

1. 为什么用谐波平均：成功的主动交互要求「会问」与「会答」同时在线。算术平均会让一个只会答题（等信息喂到嘴边后答对）但从不主动问的模型拿到体面的分数；谐波平均强烈惩罚两阶段的失衡——S^ask 很小时，无论 S^ans 多高，Ask-F1 都被压死。这与分类里 precision/recall 的 F1 同构，但语义换成了「获取信息的能力」与「使用信息的能力」。
2. 为什么 S^ans 条件于正确的 ASK：若不条件化，一次失败的 ASK 会连带 ANSWER 一起被记失败，两个决策阶段的失败源就被混淆了。条件化之后，S^ask 度量「能不能可靠要到信息」，S^ans 度量「要到信息后能不能用对」——失败归因从此可以分锅。当 N^ask = 0（一次都没问对）时直接定义 S^ans = 0、Ask-F1 = 0。

附录 A.2 还做了指标的鲁棒性检查：把线性衰减换成对数或指数衰减，七个 API 模型的绝对分数有变化，但排序完全不变（Spearman ρ = 1.00），结论不依赖衰减函数的具体形状。

4.2 数据构造：五阶段管线

438 个视频、1401 个问题、2714 个帧级人工标注时间戳，视频来自 YouTube、既有数据集（COIN、Ego-Exo4D、PEARL、StreamArena、StreamingBench）与 Blender 合成，覆盖九个领域，时长从 16.72 秒到 118 分钟，平均每视频 3.2 轮交互。三类时间窗总时长：wait 33.92 小时、ask 30.47 小时、answer 12.00 小时。

构造五步：(1) 收集/合成视频；(2) 自建网页标注工具，人工标注查询、时间窗、关键实体与证据，帧级精度；(3) 用 Grounded SAM 2 分割追踪实体做选择性高斯模糊、用 PySceneDetect 辅助切分，再做换视角、改查询、隐藏或篡改个性化概念等干扰注入；(4) 用 GPT-5.6-Sol 生成动作与答案选项；(5) 人工逐条验证——验证标准相当严格：人类在缺失证据时不能唯一确定答案、拿到证据后必须能唯一确定，且每个动作/答案候选集里恰好有一个正确项。

两个子任务的构造尤其见功夫：PACM 用 Blender 设计 25 个原子动作、组合成带新命名的个性化动作、并构造只改一个原子成分的难负样本，回答演示用无纹理白色人形渲染以避免外观线索泄漏；WUQ 则要求错误前提的不一致只能在证据出现后才可检测（不能在开头就穿帮）。附录 A.7.3 的标注一致性检查也做了：两人独立重标 160 个实例，ASK 窗平均 tIoU 0.962、边界误差 0.21/0.27 秒，ANSWER 窗 tIoU 0.971——时间监督本身是可靠的。

4.3 StreamHarness：让离线大模型公平参赛的分层记忆

现有流式基准常对离线模型做稀疏均匀采样（可能漏掉密集时序信息）或滑窗（丢掉早期上下文）。论文为此设计了 StreamHarness 分层记忆框架：

• 短期：保留最近 10 帧（1 fps）；
• 中期：每 10 帧摘要成 1 条中期记忆；
• 长期：每 4 条中期记忆合并为 1 个长期块，最多保留 8 个。

多轮之间只共享视频记忆——问题、选项、动作历史每轮清空，保证各回合独立评测。原生流式模型则用自带记忆机制。评测以每秒一次动作机会进行，容差 ±1 秒。

五、论文一：实验证据

5.1 主结果：离线与流式的 45 点鸿沟

多选设定下（Table 2），三组模型的表现：

四个关键观察：

1. 最强离线模型也只有 52.18%——Gemini-3.8 Flash 在 KVEM 37.17%、WUQ 43.10%、UPC 81.36%，子任务间差异巨大；
2. 流式主动模型几乎全军覆没：多数子任务得零分，三个模型总分为 0，最好的 AURA 也只有 7.22%——与离线最强差了 45 点。这些模型会「等待时机作答」，但基本不会「主动要信息」；
3. S^ask 普遍显著低于 S^ans（强模型上尤其明显）：44.63 对 62.80——问比答难，ASK 是瓶颈；
4. 开放设定（Table 6）全面更差：Gemini-3.8 Flash 跌到 29.19%，AURA 跌到 4.01%，多数流式模型全零——生成合适的追问文本比从候选里选难得多。

5.2 错误解剖：Early ASK 是头号错误

论文把错误分成六型：E-ASK/E-ANS（过早）、W-ASK/W-ANS（内容错）、M-ASK/M-ANS（错过）。Figure 5 的雷达图显示：early ASK 是离线模型的主要错误类型——模型往往意识到了需要额外信息，但问得太早（证据还没出现、歧义还无法确认），或者问错了内容。「知道要问」与「知道何时问、问什么」之间隔着整条鸿沟。

5.3 Oracle 消融：+21.13 点锁定 when-to-ask

这是全文诊断力最强的实验（Figure 6，KVEM 子任务、Gemini-3.8 Flash、多选设定）。逐步给模型提供 oracle 信息：

「何时问」是单项收益最大的 oracle（37.17% → 58.30%，+21.13 点），与主实验中 early ASK 主导错误类型相互印证。问什么（+3.79%）与何时答（+2.23%）的边际收益小一个量级。结论：当前模型主动信息获取的瓶颈排序是 when-to-ask ≫ what-to-ask > when-to-answer。

5.4 记忆与预算：两个补充分析

• 跨轮上下文记忆（Figure 7a）：主设定每轮清空历史以保独立评测，若保留交互历史，对视频不确定性子任务几乎无益（KVEM −2.85%、PACM −0.40%），但对用户不确定性显著有帮助（AUQ +4.40、UPM +5.38 点）——用户意图与偏好跨轮延续，历史交互提供了理解当前请求的线索。记忆的价值取决于不确定性的来源。
• ASK 预算（Figure 7b）：把每回合允许的 ASK 次数从 1 放宽到 16，KVEM 上 Gemini-3.8 Flash 的 Ask-F1 从 27.61% 升至 52.35%——多问几次确实有用，但边际收益递减，约在 K=8 后饱和。「多问」补不了「问得准」。
• StreamHarness 消融（Table 5）：去掉分层记忆只剩滑窗，52.18% → 41.70%；均匀采样 128 帧跌到 26.72%、64 帧跌到 16.99%——密集近期观测 + 压缩历史对主动决策至关重要。

5.5 局限

作者自己列了四条：每回合至多一次 ASK（现实可能需要连环澄清）；不考虑具身 VLA 场景的感知-询问-行动协同；交互都由用户显式查询发起（更自主的 Agent 应能无人提问时也发现信息不足）；时间窗尚不能表达重叠、不连续或动态变化的机会结构。

六、论文一：知识反推——复现它你需要知道什么

领域层：

• 流式视频评测的三条谱系（离线/流式/主动）及其代表基准（Video-MME、StreamingBench、ProactiveVideoQA、IPIBench 等）——不知道 ProReady-QA 等工作的时间窗设计，就理解不了 Ask-F1 「时机+内容联合」的增量；
• POMDP 建模中「隐状态 = 流中缺失信息」的抽象方式：不确定性不是噪声，而是可被动作（ask）显式消解的隐变量；
• 帧级时间窗标注的工程含义：每秒一个决策点、±1 秒容差、tIoU 一致性协议——时机监督要细到什么程度才够用；
• Ego-Exo4D 的多视角同步流、PEARL 的个性化概念、Grounded SAM 2 的实体追踪——这些上游资产是八个子任务能低成本构造的原因。

方法论层：

• 谐波聚合的条件化设计：S^ans 条件于正确 ASK，实现「信息获取失败」与「信息使用失败」的分锅——任何多阶段 pipeline 的指标都可以借鉴这种「条件化 + 调和」组合；
• Oracle 消融作为诊断工具：把 when/what 分开供给，直接量化各决策阶段的边际瓶颈——比笼统的「模型还不行」结论有用得多；
• 时间衰减函数的敏感性检查：换衰减形状、验排序稳定性（Spearman ρ = 1.00），证明结论不是指标的 Artifact；
• judge 可靠性验证：开放设定用 Gemini-3.8 Flash 当裁判，人工抽 300 回合双人标注对照，总体一致率 93.50%，且对 Gemini 自己与非 Gemini 输出的一致率相当（93.75% vs 93.27%）——无明显自我偏好，LLM 裁决才站得住。

融合关键节点：把「主动追问」从一个口语概念落地为三件事的可计算组合——动作空间扩展（wait→wait/ask/answer）、不确定性分类学（视频/用户 × 显式/隐式 × 4 中类 = 8 子任务）、时机内容联合指标（时间窗 × 谐波平均）。三者互相咬合：没有分类学就没有干净的子任务分数，没有时间窗就没有时机评分，没有 ask 动作前面全是空中楼阁。

七、论文一：通用灵感

1. 信息缺口的可枚举性。「用户没说清楚」这种模糊抱怨，可以拆成指代歧义、错误前提、偏好缺失、偏好过时四个可独立计分的槽位。产品设计里的「兜底话术」往往只有一种（「请再说一遍」），而 AskStream 证明缺口有结构，追问也应有结构。
2. 平均分是结构性短板的遮羞布。52.18% 的总分下藏着 UPC 81.36% 与 PACM 0% 的天壤之别；S^ask 与 S^ans 的失衡进一步把锅定位到「问」。评测设计者应该默认追问：总分之下，哪个环节在拖后腿？
3. Oracle 消融是性价比最高的诊断。不需要训练任何东西，只把理想信息逐步喂给模型，就能画出一张「瓶颈优先级图」。任何多阶段系统（检索-生成、规划-执行）都可以做。
4. 条件化评分分离能力维度。S^ans 只在问对之后才算——「拿到信息后会不会用」与「会不会要信息」从此是两份成绩单。流水线评测里，下游能力的测量应该条件于上游成功。
5. 最强的能力往往是「知道自己不知道」。流式模型全零的根源不是答不对，而是从不怀疑信息不完备。这对所有 Agent 系统都是警训：在信息可能永久缺失的环境里，校准的自我怀疑比更强的推理更稀缺。

第二篇：Co-Design Bench——把「做完了吗」拆成 2331 个可审计的小问题

八、论文二：题目与背景

8.1 题目拆解

「Co-Design Bench: Multimodal Collaborative Coding Evaluation for Agentic Models」：

• Co-Design：人机协同设计——真实用户与编码 Agent 在同一个应用上反复「查看-请求修改-评估结果」的迭代循环（论文引用 Schön 1983 年的反思性实践者理论开篇，颇具人文气息）；
• Multimodal：请求可携带图像、音频、视频、文档附件；
• Collaborative Coding：考的不是从零写应用，而是把用户的修改请求翻译成可运行的应用修订；
• Evaluation for Agentic Models：评测对象是能检查视觉上下文、改源码、执行应用的智能体，评测方式本身也是 agentic 的。

8.2 背景：单发评测的饱和与真实会话的空白

论文的动机实验（Figure 1a）颇具冲击力：在 WebCompass-edit 的 150 个任务上，把 qwen3.7-plus 从单发执行（single-shot，一次给出搜索/替换块）切到智能体执行（可检查、修改、运行应用），同样的评分规则、裁判与渲染管线之下，平均特征完成度从 73.6% 涨到 95.1%（+21.5 点），全过率从 32.7% 涨到 69.3%；opus-4-8 智能体执行更是达到 99.4%。既有编辑基准在 agentic 执行下已经饱和——分数不再能区分模型，因为「照着预定义编辑操作打分」的任务对能跑代码、能看渲染结果的 Agent 来说太容易了。

与此同时，既有基准的题目来源都有局限（Table 1）：Design2Code/WebSight/WebRenderBench 做参考重建（截图转代码）、MT-Web2Code 合成损坏再修复、DesignBench 从版本历史抽相邻版本、SWE-bench 系做仓库 issue——没有一个是来自真实用户编码会话的复合修订请求，也没有一个同时覆盖局部多模态编辑与仓库级协同修改，更没有对判定结果做对抗性复核。Co-Design Bench 补的就是这块：真实会话来源 + 可运行起点 + 双轨任务 + 对抗验证的免参考验收。

8.3 一个具体的例子

Figure 1b 给了基准任务的直观感受：一个体育集锦剪辑器，用户请求「增加片段并限制数量与时长上限；缩放时保持时间轴锚点对齐；删除/分割片段后要能重新插入」。这个请求把计数上限、时长限制、缩放下的时间轴对齐、删除/分割后的状态恢复耦合在同一个行为里——成功与否取决于被编辑的应用在多条互相作用的需求下的整体行为。这正是真实用户请求的典型形态：不是「把这个按钮改成红色」，而是「让这个产品变成我想要的样子」。

九、论文二：定位与问题定义

9.1 定位：免参考、双轨、真实会话来源的 agentic 基准

Co-Design Bench 包含 273 个任务、2331 条专家撰写的隐藏验收标准，从 39,325 条生产查询、26,314 个真实编码会话中去重出 37,463 条候选后精选而来。两个赛道：

• Multimodal Editing（ME，100 任务，553 条标准）：局部视觉/结构/内容编辑，附可选的图像（4）、视频（27）、音频（32）、文档（17）或无附件（20）输入；
• Repository Editing（RE，173 任务，1778 条标准）：跨组件、路由、状态、数据流的协同修订，其中 96% 的任务涉及多种编辑类型。

任务形式化为 t = (S, I, C)：S 是可运行的编辑前基线 B 及其容器化环境 E；I 是规范化请求 q、可选多模态附件 X、保留的会话历史 K；C 是隐藏的专家标准集。Agent 在 harness H 下通过执行轨迹 τ 把 S 编辑成 Ŝ，验收只看最终应用状态。「免参考」的含义：不需要 gold 代码或目标截图，编辑前基线就是验收的锚——要求变了什么、要保留什么，都相对基线可查。

任务横跨三大能力维度：Grounded Understanding（接地理解，92 任务）、UI Transformation（UI 变换，55）、Functional Implementation（功能实现，126），多标签标注下 97.1% 的任务带多个能力标签、63.7% 跨维度——真实请求天然是复合的。

9.2 数据构造：从 26,314 个会话到 273 个任务

构造管线分两段（Figure 2）：

回收可运行起点：从会话日志、仓库归档或 HTML 包重建应用；候选必须过依赖解析、构建、容器启动、Playwright 渲染四道检查；不可恢复的服务直接剪除，可修的经脚本化/智能体修复后重过同样的门。每个任务包 = 基线 + 环境清单 + 请求与附件 + 验证日志。

选题与出标准：内容哈希 + Jaccard > 0.8 近邻去重；规范化（解码附件、改写粘贴图片引用、可选隐私筛查）；F1–F6 硬过滤（环境阻塞、闲聊、含糊、非编辑请求全删）；按 r = d + v + f 排名（d 结构难度 0–5，v 可验证性 0–3，f 历史失败信号 0–2——失败信号看用户改写次数与回滚）；每会话至多取 3 条查询合并为一个有界任务，专家撰写隐藏标准。

这个「历史失败信号」入排名的细节很妙：用户反复改口或干脆回滚的请求，正是把人类开发者也逼得够呛的难题，优先收录。

十、论文二：解法（Method）——judge-then-refute 评测协议

10.1 协议全景

评测协议是论文最大的方法学贡献，流程分两段（Figure 3）：

（A）证据提取与初评：

1. 候选应用在隔离沙箱中构建并渲染（Vite 构建 / 静态 HTML 管线，启动服务，无头 Chrome）；
2. 提取证据：源码 diff、DOM 树、页面正文、视口截图、源码到入口的可达性日志；启用交互检查时，Playwright 记录动作序列与网络遥测；
3. 固定的 agentic 评委对每条隐藏标准给出 PASS / PARTIAL / FAIL。

证据必须匹配主张类型是铁律：静态属性可用源码检查确立；视觉主张必须有成功渲染与截图；交互主张必须有录制下来的浏览器动作及其引发的状态迁移。源码里有一个 handler 不能证明用户能通过界面触达并操作该功能；构建失败或 DOM 节点缺失直接令渲染相关标准失效。缺证据不能拿弱代理凑数。

（B）对抗复核与归因：

1. 独立反驳（refute）：一个独立的 LLM 验证器拿到初评判定与全部证据，专攻推翻 PASS 与 PARTIAL——检查 stub（桩实现）、硬编码输出、不可达入口、换输入即挂、请求错位五类问题。它只负责打击虚假完成分，不为 FAIL 翻案；
2. 证据审计（audit）：视觉主张查截图、交互主张查浏览器日志，违规在分数聚合之前中止评测；
3. 评分与归因：见下节。

所有判定、证据、反驳日志都保留归档，每条结论都能回溯到支撑它的观测。

10.2 评分：三个指标量出「覆盖」与「交付」的差

任务 t 有 nₜ 条标准，vᵗᵢ 是反驳与审计后的判定：

• Strict Completion R̄：只数 PASS（R_t = 通过比例）；
• Graded Completion Ḡ：PARTIAL 记半分（g(PASS)=1, g(PARTIAL)=0.5, g(FAIL)=0）；
• Full-Pass Rate F：所有标准全 PASS 的任务占比。

任务级归一化防止长标准任务垄断均值；[0,1] 尺度上恒有 F ≤ R̄ ≤ Ḡ。R̄ − F 的_gap 就是「散布在众多任务里的未完成标准」——高 R̄ 可以与低 F 共存，而这正是论文要暴露的现象。

10.3 失败归因：低分不是模型的错怎么办

对低分案例（G_t < 0.8）且独立渲染的基线通过启动门禁时，触发归因：一个并行可解性探针在隔离沙箱中打最小补丁（桩掉不可达网络端点、保留核心业务逻辑），区分模型局限、环境阻塞、混合原因、起点工件缺陷四类。原始分数与分母不动；补充的环境调整分只在确认基础设施失败时给归因信用。这个设计承认一个现实：基准里跑不起来的环境不该让模型背锅，但也不能悄悄放水——两本账分开记。

10.4 人类复核

两名前端专家对 200 个任务-模型输出的标准评分做了人工核查（含必要的浏览器交互），确认每条 PASS/PARTIAL/FAIL 判定是否反映输出对该标准的真实满足情况——给自动协议上了一层人类保险。

十一、论文二：实验证据

11.1 主结果：69.9% 覆盖 vs 26.4% 交付

固定 Claude Code harness、容器清单、系统提示、工具接口，评十个模型端点（2730 对模型-任务）。合并榜（Table 5）：

头条结论：最强的 gpt-6-astra 平均每任务通过 69.9% 的标准，但只有 26.4% 的任务全部达标——73.6% 的任务至少剩一条未完全满足的标准。分轨看：ME 上 R̄=0.754 / F=41.0%，RE 上 R̄=0.667 / F=17.9%——仓库级协同修改的完整交付远比局部编辑难。

11.2 排名与画像：赛道特异性

两轨排名相关但不一致（Spearman ρ = 0.818）：kimi-k3 从 ME 第 4 掉到 RE 第 6，qwen3.8-27b 从 ME 第 5 升到 RE 第 2（R̄=0.645，以 0.003 之差压过 opus-5）。端点间分差 ME 达 28.7 点、RE 13.0 点——合并榜会掩盖赛道特异的强弱。

执行画像的差异也有信息量：ME 视频任务中位数 44 轮 vs 纯文本 27 轮；图像检查调用 ME 平均 14.47 次/运行 vs RE 2.78 次；Edit/Write 调用占比从 ME 的 7.3% 升到 RE 的 27.6%。有趣的工具生态：OpenCV 出现在 68.5% 的视频轨迹中、ffmpeg 出现在 31.5% 的视频与 25.0% 的音频运行中；更有五个端点会主动从 HuggingFace 下载预训练感知模型（AST 音频分类、CLAP 音文相似度、Whisper 转写、OWLv2 检测、Qwen2-Audio 描述）来「读懂」附件再动手——Agent 自己长出了感知工具箱。

11.3 任务分组分析

附件模态（Figure 4a）：纯文本任务 qwen3.8-27b 最强（0.779），图像任务 opus-5 最强（0.891），视频/音频/文档任务 gpt-6-astra 最强。池化后文档附件任务平均分最高（0.652），但全过率只有 18.2%，反而不带附件的任务全过率最高（37.0%）——「平均好做」与「整体做完」是两回事，覆盖与交付给出了任务难度的两幅不同图景。音频任务池化最低（0.584），全过率 20.3%、零过率 0.3%。

编辑广度（Figure 4b）：RE 任务按涉及编辑类型数分组，1–2 类（53 任务）R̄=0.654，3–4 类（120 任务）R̄=0.591——6.3 点的落差，且十个端点无一例外全部下降；全过率却相近（9.1% vs 9.7%），零过率从 0.9% 升到 5.8%。复合修订不必然让任务「全盘做不成」，但系统性地压低每条标准的满足率。

能力维度（Table 3）：Functional Implementation 是最大组（126 任务、46.2%），Strict 最高（0.619）但全过率最低（10.3%）；Grounded Understanding 全过率最高（20.2%）。gpt-6-astra 三个维度全部领先（0.738 / 0.692 / 0.673）。功能实现「最容易拿到部分分、最难全部做完」的形态再次印证覆盖-交付鸿沟。

11.4 消融与鲁棒性

• 执行制度（附录 A）：即动机实验——单发 73.6% vs agentic 95.1%，agentic 循环是必需品；
• 裁判敏感性（附录 C）：换 GLM-5.2 / kimi-k3 / Qwen3.8-27B 三个裁判重评两个端点的存量输出，绝对分最多移 0.053，四配置下 kimi-k3 与 qwen3.8-27b 的两轨相对位次完全稳定——跨赛道排序结论对裁判选择稳健；
• 跨 harness 敏感性（附录 H）：同一 solver 换 codex / opencode / qwen-code 三套 harness，ME 上 harness 排序在两个 solver 间完全反转（ρ = −1.00），kimi-k3 与 qwen3.8-27b 的差距在 ME 上浮动 10.0 点、RE 上 16.2 点——模型×harness 交互强烈，模型对比必须固定 harness。这也是主实验全部共用 Claude Code harness 的原因。

11.5 执行开销

高分不靠蛮力：ME 上 gpt-6-astra 用 32 轮中位、1.24M token 拿到 0.754，glm-5.2 用 69 轮、7.29M token 只有 0.572；RE 上 gpt-6-astra 48 轮 2.33M token（0.667）对 qwen3.8-27b 57 轮 6.72M token（0.645）——更高的完成度并不需要更多的执行开销。每个轨迹限 3 小时墙钟与 120 轮；全部轨迹共 135,370 次工具调用。

十二、论文二：知识反推——复现它你需要知道什么

领域层：

• Web 编码基准的四个家族（参考重建、损坏修复、版本历史抽取、issue/自由职业实现）及各自来源——理解「真实会话复合修订」这个空位为什么值钱；
• 前端工具链的实操知识：Vite 构建、静态 HTML 服务、无头 Chrome、Playwright 的动作录制与网络遥测——judge-then-refute 的证据层全建在这套栈上；
• agentic harness 的构成（容器清单、系统提示、工具接口、仓库 staging）与 Claude Code / codex / opencode / qwen-code 的差异——跨 harness 实验说明这些「脚手架变量」不是噪声而是强交互项；
• 媒体处理工具生态：ffmpeg、OpenCV、faster-whisper 以及 HuggingFace 上的 AST/CLAP/OWLv2/Qwen2-Audio——Agent 们自发用它们把多模态附件转成可操作证据。

方法论层：

• judge-then-refute 的对抗结构：初评只负责「有证据地判」，反驳器专攻「打假」——职责分离让两个 LLM 各自做最擅长的事。它承认 LLM 评审会犯错，于是用第二个 LLM 的敌意来对冲第一个的善意，再用证据审计兜底。这与 AskStream 用条件化评分分离「问」与「答」的失败，是同一哲学的不同投影；
• 免参考验收的锚定技巧：不造 gold 答案，用编辑前基线锚定「该变什么、该保什么」——既避免多解被判错，又把「保留约束」变成可审计标准；
• 三指标组（R̄/Ḡ/F）的任务级归一化：等权任务均值 + 全过率 + 半分制，专门为暴露「部分满足 vs 完整交付」的 gap 而设计；
• 条件性失败归因：低分触发、基线须过启动门、最小补丁探针、四分类归因、原始分与调整分双账本——环境问题不冤枉模型、也不偷偷放水的两全做法；
• 排序稳定性检验：换裁判验排名（附录 C）、换 harness 验差距（附录 H）——基准作者对自己排名结论的脆弱性主动做压力测试，这种自觉值得进入所有评测工作的 checklist。

融合关键节点：把「任务完成」这个布尔量分解为证据链上的可审计原子。请求 → 专家标准（隐藏 rubric）→ 逐条判定（PASS/PARTIAL/FAIL）→ 判定必须挂证据（截图/动作日志/源码 diff）→ 正向判定要过对抗复核 → 分数可逐条回溯。整条链的每一环都在把「看起来做完了」与「真的做完了」分开。一旦评测的单位从「任务」变成「标准-证据对」，69.9% 与 26.4% 的鸿沟才会现形。

十三、论文二：通用灵感

1. 把验收拆成原子标准，是把模糊需求工程化的通用手法。「把应用改好」不可测，「时长上限生效 + 删除后可再插入 + 缩放时锚点对齐」可测。写需求文档、验收测试、Done 定义时，都值得问：这条能不能变成一条可挂证据的判定？
2. 平均完成度会撒谎，全过率不会。69.9% 的覆盖听起来接近可用，26.4% 的交付才是用户真实体验——用户不会因为你完成了 8/10 条需求就交付 80% 的价值。任何多需求项目（软件、装修、文案）都存在这个「最后一公里」的悬崖。
3. 给正向判定安排一个专门的反对者。人类评审天然有确认偏误，LLM 评审再加自我偏好。judge-then-refute 的启示是：与其追求一个更聪明的裁判，不如安排一个只负责说不的角色，专查 stub、硬编码、不可达——对抗比权威更便宜也更可靠。
4. 执行条件是评测的一部分。单发 73.6% 与 agentic 95.1% 的 21.5 点落差、跨 harness 的 10–16 点浮动都在提醒：报告模型能力时，harness、轮数、工具集必须与模型名一起写进结论，否则排名不可复现。
5. 历史失败信号是免费的难度标注。用户改写三次、回滚两次的请求，天然是难任务——产品与评测的选题都可以从真实使用日志里挖这种「人类也翻车」的信号，比人工标难度便宜且更真实。

十四、两篇对比与交汇：评测基准从静态打分到过程与证据审计

14.1 一张表看清两篇的坐标系

14.2 交汇点一：把评测单位做小——时间窗与验收标准

两篇论文的第一个共同动作都是把评测的原子单位从「任务」缩小。AskStream 把一次交互切成帧级的时间窗：wait 33.92 小时、ask 30.47 小时、answer 12.00 小时，每秒一个决策点——「答对了」不够，还要「在对的时间问了在对的事」。Co-Design Bench 把一个请求拆成平均 8.5 条标准（ME 均值 5.5、RE 均值 10.3、最多 46 条）——「应用能跑」不够，还要「每条要求都有证据地满足」。

这是同一个趋势的两个切面：当模型的能力强到能在粗颗粒指标上得分相近时，基准的区分力只能来自更细的颗粒度。52.18% 与 7.22% 的差距、69.9% 与 26.4% 的落差，都只有把尺子刻度做细才能量出来。

14.3 交汇点二：从「结果打分」到「过程行为与证据链审计」

传统基准的打分对象是最终输出：一个选项、一段文字、一张截图。这两篇的打分对象已经是过程：

• AskStream 审计的是时间轴上的行为序列——模型在每一秒的选择（等/问/答）构成一条轨迹，Ask-F1 里的时间衰减函数实际上在给「行为的及时性」定价，early ASK 作为主要错误类型只有在这种过程视角下才可见；
• Co-Design Bench 审计的是证据链的完备性——一条 PASS 判定必须挂着匹配主张类型的证据（视觉→截图、交互→动作日志），还要经受专门反驳器的对抗检查，stub 与硬编码在「源码存在」与「用户可达」的区分中现形。

两条审计路线汇合处是一个共同信念：模型说什么不算数，可验证的行为与证据才算数。这与近期 Agent 评测的整体走向（过程奖励、轨迹评审、可验证奖励）同频，但两篇论文分别把「时间维度」与「证据维度」做到了流式视频与编码修订这两个具体领域里最完整的形态。

14.4 交汇点三：诊断式评测——不只排名，还要指出短板在哪

两篇都不是止步于排行榜，而是设计了专门的诊断机制：

• AskStream 的 oracle 消融把 21.13 点的最大单项增益锁定在 when-to-ask，配合六类错误分解（early ASK 主导）与 S^ask/S^ans 失衡，把「模型不行」细化成「问的时机不行」；
• Co-Design Bench 的 R̄−F gap 分析把「模型不行」细化成「复合修订的完整性不行」（3–4 类编辑全体端点掉 6.3 点），失败归因再把环境因素从模型头上摘掉。

诊断式基准对社区的价值高于排名式基准：它告诉后续工作者该往哪使劲——AskStream 之后该做时机建模与不确定性校准，Co-Design Bench 之后该做需求完整性保持与跨文件变更传播。

14.5 交汇点四：真实性与可控性的权衡

两篇在数据来源上走了不同的路，恰好构成光谱的两端：

• AskStream 主动构造：Blur 干扰注入、Blender 合成个性化动作、错误前提注入——每个子任务的不确定性来源与时间窗都精确可控，代价是场景经过设计而非自然发生；
• Co-Design Bench 自然采信：真实会话、真实附件、真实回滚信号——生态效度极高，代价是任务分布不可控（RE 里 96% 是复合编辑）、难度只能靠排名函数事后筛选。

两者都用自己的方式对冲了对应的弱点：AskStream 用标注一致性（tIoU 0.96+）与「无泄露验证」保真实性下限；Co-Design Bench 用专家标准撰写与可运行门禁保可控性下限。做基准设计时，「构造 vs 采集」不是二选一，而是要为自己的领域找到两者的配比与对冲机制。

14.6 交汇点五：评测协议自身的可信度也要被评测

一个容易被忽视的共同点：两篇都花了不少篇幅验证验证者。AskStream 给开放设定的 LLM 裁判做了人工一致率检查（93.5%）与自我偏好检查（93.75% vs 93.27%，无差异）；Co-Design Bench 做了裁判敏感性（换裁判排序稳定）、人类复核（200 例）与跨 harness 敏感性（承认排名对 harness 敏感并固定之）。当 LLM-as-a-judge 成为基准的核心组件，对裁判本身的审计正在从加分项变成必答题——这一条大概是两篇论文给未来所有基准立下的新规矩。

14.7 差异的启发：两个领域互相欠对方什么

放在一起读还会发现有趣的互补：AskStream 的八类不确定性分类（尤其错误前提 WUQ、偏好冲突 UPC）对编码 Agent 同样致命——用户需求里的错误前提与过时偏好，正是 Co-Design Bench 里「request grounding」失败的一大来源，而编码基准目前并不要求模型主动向用户澄清；反过来，Co-Design Bench 的 judge-then-refute 对抗复核，也正可用于 AskStream 开放设定里 LLM 裁判的加固（反驳器专挑「把错误 ASK 判对」的case）。「该问而不问」与「该做而做不全」是同一种能力缺陷（需求完整性感知）在两个领域的不同投影——这大概是可以从这对组合里读出的最远的一层启发。

十五、结语

这两篇论文各自领域不同，但合起来勾勒出了评测基准设计的一条清晰主线：从静态打分到过程行为与证据链审计。

AskStream 的贡献是把「主动追问」变成了可计算的对象：动作空间扩展为 wait/ask/answer、不确定性拆成 8 个可计分子任务、帧级时间窗配上时机-内容联合的 Ask-F1。它诊断出的是：最强的离线模型也只有 52.18% 的 Ask-F1，流式主动模型最好的 7.22%；oracle 消融里「何时问」一项就值 +21.13 点——模型不缺答题的智能，缺的是对自身信息状态的自省。

Co-Design Bench 的贡献是把「做完了」变成了可审计的命题：2331 条隐藏验收标准、证据必须匹配主张、正向判定要过对抗反驳。它诊断出的是：最强端点覆盖 69.9% 标准却只交付 26.4% 任务——从「基本做完」到「全部做完」之间隔着当前编码 Agent 最难跨越的鸿沟。

如果要用一句话概括两篇的公共方法论，那是：别信模型交出来的东西，信它在每个决策点上留下的可验证痕迹——时间轴上每秒的 wait/ask/answer 选择，证据链上每条主张挂着的截图与日志。评测基准的下一次进化，大概率就沿着这条「把过程与证据变成一等评分对象」的路继续走下去。而对模型开发者，两篇论文合起来的行动清单也很明确：教模型在信息永久缺失时开口问（问得早不如问得准），教 Agent 在复合需求下保持完整交付（做完八条不如做全十条）。

（完）