AI 交付的东西，人类到底用没用？Kolab 用 115 小时录屏戳破了自动化基准的盲区

你有没有想过一个很尴尬的问题：Agent 在聊天窗口里洋洋洒洒输出了一个方案，用户回了句"好的谢谢"，然后呢？然后用户关掉窗口，打开 Revit、DaVinci Resolve 或者 LexisNexis，把 AI 给的东西改得面目全非——或者干脆扔进了回收站。这一切，Agent 一无所知。

这两年 agentic benchmark 卷得厉害，但几乎全在测同一件事：给一条指令，Agent 能不能一口气把活干完。可真实的专业工作压根不这么运转——需求会变，中途要改，AI 的产出只是漫长流水线里的一环。明尼苏达大学的这篇 Kolab（arXiv:2610.21109）做的就是把镜头从"AI 能不能独立完成"挪到"人和 AI 协作时到底发生了什么"，顺手给前沿模型出了一道它们集体考砸的题。

核心摘要：Kolab 是一个真实专业工作流数据集——50 位来自 40 种职业的专业人士，用自己的真实工作任务和 AI Agent 协作，留下 115 小时以上的屏幕录屏、508 个工作步骤、692 条"采纳/修改/拒绝"标注。基于这些数据，作者定义了两个自动化基准从不测试的能力：预测自己的产出离开聊天窗口后会被怎么处置，以及在没有人类反馈的情况下判断协作质量。结果相当打脸：GPT-6 预测采纳行为的 F1 只有 0.513，Gemini 3.1 Pro 更低到 0.391；预测协作满意度的斯皮尔曼相关系数最好的也只有 0.38，好几个模型甚至跑不赢"永远猜 5 分"的众数基线。我的判断：这不是一篇刷榜论文，数据集本身比 benchmark 结果更值钱，它给"协作型 Agent 的过程奖励信号"这个真空地带填了第一块砖。

📖 论文信息

• 标题：Kolab: Benchmarking Human-Agent Collaboration in Long-Horizon Workflows
• 作者：Shirley Anugrah Hayati, Patricia Anugrah Setiani, Ruizi Wang, Zhouyi Li, Khanh Chi Le, Young-Jun Lee, Dongyeop Kang
• 机构：University of Minnesota（计算机科学系、经济系）
• 链接：https://arxiv.org/abs/2610.21109 ，项目页 https://minnesotanlp.github.io/kolab/
• 提交时间：2026 年 10 月 15 日

🎯 问题动机：自动化高分 ≠ 协作好用

现有的长程 Agent 基准——GDPVal、TheAgentCompany、Agents' Last Exam 这批——都在回答"AI 能不能自己把活干完"。这个设定有一个隐含假设：人类的角色就是出题和打分，中间过程不需要存在。

但真实工作不是单回合游戏。建筑师让 Claude 出一个户型布局，拿到手之后在 Revit 里重建墙体、保留喜欢的分区、修掉不合理的动线；律师让 AI 起草条款，逐句改写后才敢用。这些"采纳之后的动作"发生在聊天窗口之外，自动化基准完全看不见。

之前也有做人机协作的，但要么用模拟用户，要么只有聊天记录没有屏幕操作，要么局限在软件工程单一领域。Kolab 的差异点在于：任务来自参与者自己的真实工作（不是研究者编的），有完整录屏（能拍到 AI 界面之外的操作），还有逐步的人工评分。这个组合在现有数据集里确实是独一份。

🏗️ 数据集：115 小时录屏里长出的工作流图

数据采集的方式值得细说。50 位专业人士通过 Prolific、Upwork 和熟人介绍招募，每人 100 美元报酬加超时补贴，用 Claude 作为默认 Agent 完成自己真实工作中的长程任务，录两次、每次 1 小时的屏幕。任务必须满足四条硬标准：来自真实工作、需要领域专业知识、至少 1 小时且至少 5 个相互依赖的步骤、有可交付的最终产物。

图 2：50 位参与者覆盖 10 个行业 40 种职业——艺术设计占 26%、建筑工程占 20%，用的软件从 Photoshop、Revit、Ansys 到 Stata、Filevine、HubSpot，跨度相当大

数据规模：100 个工作流、508 个步骤、90 多款软件、平均每段录屏 69 分钟、每段平均 5.24 个步骤。协作满意度评分明显偏高——54.9% 的会话打了满分 5 分，29.7% 打 4 分，3 分及以下只有 15.3%。记住这个分布，后面实验部分它会变成一个大坑。

工作流图：把"人机接力"画成有向图

这是整篇论文我最喜欢的部分。作者把每段录屏切成步骤，每步表示成一张时序图 \(G = (V, E, a, w, \tau)\)：节点是人或 AI 的动作，带时间区间，有向边表示动作间的先后依赖。然后标注员沿着图找三种关键节点——触发 AI 生成的源节点、产出被使用的目标 AI 节点、以及人后续处置该产出的节点，处置方式打三分类标签：

• Adopt：原样采纳，占比 65.9%（456 条）
• Modify：改完再用，占比 19.1%（132 条）
• Reject：看完弃用，占比 15.0%（104 条）

图 1：一位建筑师开发住宅平面方案的完整工作流。第 2 步"Ask"是源节点，触发 Claude 交付面积规范（目标 AI 节点）；第 3 步建筑师把 AI 给的平面 v1 与一层参考合并——这是 Modify；第 5 步在 Revit 里定稿，标注为 Adopt，而这个动作发生在聊天窗口之外，Agent 自己根本看不到

表格 2 里几个真实例子很有画面感：音乐制作人在 ElevenLabs 生成 Afrobeats 伴奏后直接导入 DaVinci Resolve（Adopt）；建筑师拿到 Claude 的大堂动线布局后在 Revit 里重建隔断（Modify）；视频剪辑师发现 Kling AI 生成的校园片段音频没法用、积分又耗尽了，只能弃用（Reject）。

说实话，这套 Adopt/Modify/Reject 标注是全文最有工程价值的东西——它实际上就是一条天然的、不需要人类额外打分的过程级奖励信号。作者在 RQ1 里也明确点了这个动机：如果模型能自己识别产出被怎么处置了，录屏就能直接变成训练反馈。

📊 协作动力学：三个有点反直觉的发现

作者定义了三个指标来刻画协作模式。协作突发性借用 Goh 和 Barabási 的经典公式：

其中 \(\mu_\tau\) 和 \(\sigma_\tau\) 是交互间隔的均值和标准差。\(B\) 趋近 1 表示交互很"扎堆"（长时间独立工作，中间插几段密集对话），趋近 -1 表示交互均匀分布，等于 0 类似泊松过程。工作流拓扑 \(W\) 用出度大于 1 的分支节点占比来衡量"人在 AI 生成时并行干活"的程度。AI 保留率则统计采纳和修改的占比。

三个发现：

图 3(a)：突发性 B 与 solo lead-in（首次找 AI 之前独立完成步骤的时间占比）的散点图，\(\rho = 0.35\)，p \(\lt\) 0.001，点的颜色深浅代表参与者自报的计划清晰度

发现一：交互越扎堆的人，先自己闷头干的时间越长。突发性与 solo lead-in 相关 0.35，自报"用 AI 前已有清晰计划"的人 solo lead-in 也更长（\(\rho = 0.53\)）。而且突发性在同一个人的两次会话间相当稳定（\(\rho = 0.59\)）——这更像个人工作风格，不是任务随机性。我的解读：专业用户把 AI 当"阶段性外包"，而不是"全程陪聊"。这对 Agent 产品设计是个提醒——别老想着刷存在感，人家可能压根不想被打断。

发现二：并行越多，协作体验越差。分支节点占比与协作评分负相关（\(\rho = -0.24\)，p \(\lt\) 0.05）。相关系数不大，但方向符合直觉：AI 在后台跑、人在前台干，听起来高效，实际带来了协调成本——回来收货时得重新对齐上下文。

发现三：行业差异真实存在。法律行业修改率高达 41%，是第二名艺术与体育（22%）的近两倍；直接采纳率从法律的 57% 到理科和计算机数学的 79% 不等。律师不直接采纳 AI 产出，这和之前 Schwarcz 等人对法律行业的观察一致——出了事要担责的行业，AI 的产出只能当草稿。

坦率地讲，这部分的统计功效有限：50 个人、每人两段会话，相关系数也都在 0.2-0.5 的中等区间。作者自己也说明这些分析是描述性的，不做群体层面的行业对比结论。这个克制是加分的。

🧪 基准任务：两道自动化基准从不考的题

这是论文的核心贡献。作者把"协作型 Agent 需要什么"拆成两个研究问题：

1a 和 1b 的区别值得强调：1a 让模型看着人类后续操作录像判断"这是采纳还是修改"，1b 则要求模型在 AI 刚交付完、人还没反应时就预判结果。1b 才是真正部署时有用的能力——Agent 如果预判自己的方案大概率被拒，就该主动追问澄清或者标注风险，而不是交完货就跑。

被测模型阵容：Gemini 3.1 Pro、Gemini 3.8 Flash、GPT-6 Astra、Claude Code Opus 5.5，加上两个开源视频模型 Qwen3-VL-30B-A3B 和 Qwen3-VL-32B。注意一个坑：GPT-6 因为成本只评了部分样本（1a 用 279 条、1b 用 349 条，而非完整的 692 条），所以它的高分要打个问号，附录里有公共子集的对比。

📉 实验结果：前沿模型集体不及格

视频输入下的主结果：

几个值得咀嚼的点。即便给了人类后续操作的录像，最好的模型识别 F1 也只有 0.68-0.71；到了真正有用的预测设定，全线掉到 0.5 以下。所有模型都严重偏向预测 Adopt——废话，训练语料里 AI 的产出大概率被采纳，这个先验太强了。Gemini 3.1 Pro 把 52% 的真实 Modify 和 71% 的真实 Reject 都猜成了 Adopt。

还有个微妙的现象：Claude 表现最好，作者推测是因为数据采集用的就是 Claude，它"更懂自己界面里的交互"。这个解释合理但也有点尴尬——言下之意是这些能力可能不泛化，换个 Agent 界面就得重学。

更长的上下文有用吗？基本没有。 把前 1-3 步甚至整个工作流都喂进去，多数设定下 macro-F1 变化不到 0.07。只有 chat log 模态下 Gemini 3.1 Pro 加三步上下文涨了 0.12（p \(\lt\) 0.01），但给全工作流后增益又消失了。Qwen-32B 更惨，全图输入反而从 0.43 掉到 0.32。等等，这个结果其实挺让人皱眉的——如果问题只是"模型看得不够多"，长上下文应该稳定提升才对。没有提升说明瓶颈不在输入长度，而在模型根本没学会从工作流里提取"人接下来会怎么做"的表征。

RQ2：跑不赢"永远猜 5 分"

评分预测的结果更难看：

还记得前面那个评分分布吗——54.9% 的会话打 5 分。于是"永远预测 5 分"的众数基线 MAE 做到 0.682，所有 MLLM 都没跑赢它。Gemini 3.1 Pro 的 0.685 已经是模型里最好的，还是差了一截。

MAE 这个指标在这么偏的分布上本来就意义有限，真正诚实的是斯皮尔曼相关系数：模型能不能把"好协作"和"烂协作"排出正确的相对顺序。答案是不太能——最好的 GPT-6 也只有 0.38 左右，Gemini 两个模型接近 0，等于随机。

失败案例部分揭露了更本质的问题：预测塌缩。Gemini 3.1 Pro 对真实评分为 1 的样本预测 4.83 分，对真实评分为 5 的样本预测 4.95 分——差距 0.12 分，约等于没有区分度。Claude 的预测全部挤在 3.3-3.9 之间，Qwen 挤在 3.04-4.15。如果模型真的在"看"工作流，预测应该随输入变化；现在预测基本不随输入变，说明输出主要由模型自身的先验驱动，而不是由观察到的证据驱动。

只有 GPT-6 在视频输入下能拉开高低分的差距，而且跨模态最稳定。这是全文里唯一一个让我觉得"哦，这个模型好像真的在理解点什么"的信号。

模态消融的结论也比较碎：没有任何模态组合稳定最优。视频对识别任务最好，人工整理的工作流图对预测任务更好（Qwen-32B 加图后从 0.23 涨到 0.37），纯 chat log 会显著伤害 Reject 的识别（F1 降 0.07）——这完全合理，弃用行为大多发生在聊天窗口之外，光看聊天记录当然看不到。

💡 我的判断

这篇论文的价值排序，我会这么排：

数据集本身 > 基准设计 > 实验结论。115 小时真实专业人士的录屏、工作流图、Adopt/Modify/Reject 标注、逐步评分——这套数据形态在公开数据集里没有对手。Table 1 的对比很能说明问题：GDPVal 有 44 个领域但只有文本和文件，Workflow-GYM 有人的轨迹但没有 AI 协作，Kolab 是唯一一个"真人 + 真任务 + 视频 + 协作标注"全占的。作者也承诺公开全部七个组成部分。

实验结论层面，"前沿模型不懂人机协作"这个判断我不意外，但论文把"不懂"拆解得很具体：不是上下文不够（长上下文没用），不是模态不够（加模态没用），而是预测塌缩到先验上。这个失败模式的刻画比"分数低"本身更有信息量。

当然也有几个问题不得不说。GPT-6 只评了部分样本却拿了好几个第一，虽然附录给了公共子集对比，但主表直接混排容易误导。评分任务的 MAE 指标在 55% 满分的分布上基本失效，论文用众数基线点破了这一点，处理得算诚实，但也说明 1-5 分制 + 天花板效应的评分设计本身值得重新考虑。样本量 50 人、相关分析 ρ 普遍在 0.2-0.4，统计结论是"提示方向"而非"铁律"。还有 Claude 的界面熟悉度优势——这提醒我们，"理解协作"的测量里混着"理解自家 UI"的噪声。

对工程的启发很直接：如果你在做协作型 Agent 或者 computer-use Agent，"我的产出被怎么处置了"是一条被严重低估的信号。现在主流的 RLHF/RLVR 奖励都在任务结束时才给，而 Kolab 证明了人类处置 AI 产出的方式（采纳/改/弃）是可观察、可标注、且蕴含丰富偏好的。谁能把这条信号接进训练循环，谁就有机会解决论文暴露的这个"预测塌缩"问题。

一个更远的追问：论文测的是模型"看懂"别人的协作，但部署中的 Agent 需要的是"看懂"自己正在参与的协作。这两者之间隔着自指建模的鸿沟——模型要把自己当成工作流里的一个节点来推理。Kolab 没碰这个问题，但它铺的数据形态刚好是研究这个问题所需要的。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我