SlackBench（协作项目智能体基准）

据 arXiv:2611.05512 的观察，智能体正逐步成为能浏览网页、写代码、跑实验、长时间协助人类的数字同事，但既有基准与真实知识工作之间有明显落差：不少基准依赖合成数据或孤立任务，缺少协作项目中的多方动态。在真实项目里，一个看似简单的职场问题也可能需要先找出相关频道与私信、从很长的讨论里恢复上下文、查看仓库当前状态、调和已经过期或互相冲突的证据，最后跨多个来源综合出答案。

论文把这类能力称为对「工作场所沟通」与「演进中的仓库状态」的联合推理。它与本站已收录基准的角度不同：AppWorld 在受控应用世界里考察多应用 API 调用，Terminal-Bench 聚焦命令行任务，OSWorld 考察真实操作系统中的计算机操作，SWE-bench 考察代码补丁。SlackBench 不考单点的工具操作是否准确，而考智能体能否在信息不完整、来源异构、结论随时间变化的环境里定位并核验证据——这更接近同事日常面对的工作，也更难用静态题库分数替代。

据该论文摘要，SlackBench 的环境建立在真实学术研究项目的保隐私重演之上：既保留真实的多方对话、逐步演进的决策，也保留与之对应的、落在 GitHub 仓库与 Google Docs 里的代码改动与文档，并保证环境可复现。保隐私重演这一构造选择很关键——它让基准既具备真实项目的信息杂乱度，又不必公开原始参与者的私人数据。

基准含 140 个查询，覆盖四类任务：异构来源的智能体检索、对不可答或错误前提问题的弃答、目标导向的摘要，以及长对话中的情境推断。据摘要强调，这些任务无法化归为静态语料问答：智能体必须自己判断哪些对话与当前问题相关、遍历消息线程、检查仓库状态，并在沟通记录与代码制品之间综合证据。把「弃答」显式列为评测维度尤其值得注意——错误前提问题没有正确答案，若智能体顺着前提编一个答案，检索与推理再流畅也是失败；这与本站事实接地词条所强调的溯源与证据对齐形成呼应，只是从概念层落到了可量化的评测层。

据该论文摘要，在 33 个前沿模型与智能体外壳上评测后，表现最佳的系统得分约为 80%，多数智能体低于 66%，作者据此判断仍有明显提升空间；数据集公开在 Hugging Face 的 HuanzhiMao/SlackBench。这个分布比单一头条分数更有信息量：最佳系统与多数系统之间存在约十几个百分点的差距，说明差距不仅来自底层模型，也来自外壳如何组织检索、如何管理长对话上下文、如何在证据冲突时决定是否弃答。

读这组数需要标注口径。其一，数值来自单篇预印本摘要，为作者自报，发布时点未见独立第三方复现；摘要未展开评分细则、各任务分项得分与外壳配置，因此不宜与其他基准分数直接横比。其二，「33 个前沿模型与智能体外壳」是模型与外壳的混合评测，最佳系统成绩不能单独归因于某个模型。其三，保隐私重演虽然提高了真实感，但重演过程本身可能引入与原项目不同的信息分布，外部效度需后续研究验证。据第三方索引站 ArXivSignals 的标注，该工作附带代码发布、被归为现实协作基准方向；这属于第三方评价，本站未独立复核。

对做「数字同事」类产品的团队，SlackBench 指向一组常被忽略的验收项：跨来源检索时能否识别相关频道与线程、证据过期或冲突时能否察觉而不是照单全收、面对错误前提能否弃答、长对话中能否维持情境而不是只记住最近几轮。这些能力很难靠单轮问答调优补上，往往需要外壳层的检索策略、证据时间戳管理、来源标注与置信度判断共同支撑，也解释了为什么同类基准上「换更强模型」的收益常常不如「改进外壳」。本站 Agent Harness 词条讨论的正是这一层。

对评测体系本身，它代表 2026 年下半年一个可见的走向：评测单位从「单道题、单轨迹」上移到「项目、团队与持续演进的环境」，把过程约束（溯源、弃答、一致性）与结果分数并列。局限也要如实说：单一来源的项目类型（学术研究协作）未必能代表企业里的销售、客服、运维工作流；140 个查询的规模对统计稳定性有限；重演数据与真实生产数据之间仍有距离。因此较合理的用法是把它作为协作类智能体的专项体检，而非通用能力排行榜。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。

把评测单位抬到项目与团队层面之后，下一步很可能是把时间维度做得更实：多轮决策演进、成员加入退出、文档与代码长期漂移，以及跨工具链的状态一致性，都会成为协作类基准的常规变量；弃答、溯源、证据冲突消解这类过程指标也会与最终答案分数并列出现。对产品侧而言，这意味着竞争力越来越多落在检索与证据治理的外壳层，而不只是底座模型选型。需要留意的是，保隐私重演能否覆盖不同行业的工作流、140 题规模下的统计稳定性、以及评分细则的公开程度，都将决定这类基准能否成为被广泛采信的公共尺子。本站将持续跟踪数据集更新与第三方复现结果。