四天前 arXiv 收了 SlackBench，编号 2611.05512。作者八位，第一作者 Mingxuan Li，Gonzalez 和 Dimakis 也在名单里。我冲着作者点开看了一眼，没抱什么期待。
过去见过的协作类 benchmark，拆开看多数是让 LLM 生成几个角色，在模板对话里假装开会、假装改需求。那种“协作”是语言模型的排练，不是协作。所以看到摘要说自己基于真实学术项目重演，我第一反应是，又换了个说法。
读到方法描述那段才确认这篇值得点。它不是合成角色聊天，是把真实学术项目的协作历史重演了一遍。对话、代码、文档的变更，都对应到真实的 GitHub 仓库和 Google Docs 上。角色不是生成的，是历史里真发生过的，只不过做了隐私保护。这个区别很关键。
关键在时序。协作中真正难的，不是听完对话回答问题，而是你得同时知道对话进行到那一刻，仓库里代码长什么样，文档改到哪一版。这些状态会变，而且相互牵连。一个只拿聊天记录喂给模型的评测，根本测不出这种能力。
我拿一个项目的聊天记录导出，灌进一个简单的 RAG，问它“为什么那个 merge 回滚了”。它给了一段挺像样的回答，但完全没提中途有人改了需求文档——因为它只读了聊天记录，读不到文档变更。这不是 RAG 的错，是我给它的输入就不完整。SlackBench 把代码、文档、对话同时喂进去，就是冲着这个缺口来的。
我最想看的其实是拒答类任务。一个协作智能体如果能在有人提出一个基于过期需求的问题时，回一句“这个前提已经变了”，比给出一个漂亮的幻觉答案有用得多。摘要里专门列了这类查询，说明作者知道真实协作里最危险的不是不会答，是答得太顺。
140 个查询不算多，但类型不糊。有不可回答问题拒答、目标导向摘要、长对话情境推断，都要求模型先判断哪些对话重要、追踪线程、再查仓库状态，然后才找证据。静态语料问答在这些任务上会漏掉关键证据，不是多塞几份 PDF 就能补上的。
分数分布也是加分项。33 个模型和框架跑下来，最好的约 80%，多数低于 66%。这个分布比一堆 90 分的榜单诚实多了，它没有把题目出到让所有模型都好看的程度，也没遮掩多数不到 66% 这个事实。
这篇我没跑。数据集链接在论文页面有，但把 33 个模型和框架对齐一遍，不是顺手跑一下能干的。我读到分数表格的时候还想着要不要先拿一个开源 agent 框架试一条查询，后来想想这周已经废在环境配置上了，放弃了。 所以我这篇是只读不跑，先说清楚，免得有人以为我跑过那 33 个基线还逐一比过分数——我没有。
作者说这是个可扩展的框架，我半信半疑。一个基于真实项目重演的基准，要扩展就得再重演另一个项目，成本不低。但至少这 140 条查询是实打实的，不是纯合成，这点我没法装没看见。
不点论文也能带走的一句：给智能体测协作，别只丢给它一份聊天记录。把代码仓库、文档版本、决策演进都放进去，它答不对，才说明测到了协作。这篇值得点。