SlackBench评测多模态协作智能体，跨代码与对话推理仍是短板

摘要：SlackBench构建了一个面向真实协作项目的智能体评测环境，将Slack式多线程对话、GitHub代码变更与Google Docs决策记录关联起来，覆盖异构来源检索、不可回答问题拒答、目标摘要和长对话情境推断等140项任务。评测涵盖33个前沿模型与智能体框架，最佳系统得分约80%，多数低于66%，说明单纯检索文件或扩大上下文已不足以完成跨来源证据协调。数据集采用隐私保护的真实项目重演，为企业知识检索、研发协作智能体和长程任务编排提供了比静态问答更贴近实际工作的评测层。

---

SlackBench把协作智能体评测从静态语料拉回动态工作现场

SlackBench不再把智能体评测简化为“给定文档、回答一个问题”。其核心变化是构造出带有时间演化和多方协作痕迹的环境：Slack式对话记录、GitHub仓库状态、代码修改与Google Docs文档彼此关联，智能体需要先判断信息位于何处，再沿线程恢复上下文，最后结合代码现状完成证据综合。

该基准包含140项查询，覆盖四类任务：跨异构来源的智能体搜索、针对不可回答或错误前提问题的拒答、围绕明确目标的摘要，以及基于长对话推断情境。由于任务依赖不断变化的仓库和讨论状态，单纯扩大上下文窗口并不能消除检索、归因与冲突处理难点。

评测机制：从“找到文本”升级为“重建工作状态”

一个典型任务可能涉及这样的链路：智能体先在频道列表中筛选相关项目，再进入话题线程定位关键讨论；随后检查消息发生时的代码分支、提交记录或测试结果，核对后续文档是否推翻早期决定，最后给出带上下文限定的答案。

这意味着SlackBench评估的不是单一问答准确率，而是一套端到端工作流：

1. 相关性判断：区分项目讨论、闲聊、已失效决策和当前有效约束；
2. 长程上下文恢复：从分散的群聊、私信和线程回复中重建事件链；
3. 代码状态核验：检查仓库文件、提交和变更，而不是只引用聊天中的口头描述；
4. 证据冲突处理：识别过期陈述、错误前提与相互矛盾的信息；
5. 受约束生成：在证据不足时拒答，或明确限定结论所依赖的时点与范围。

相较静态RAG基准，这种设计更接近企业知识助手和研发智能体的真实难点：答案通常不是由单个文档片段直接支持，而是由多个带时间戳、权限边界和权威层级的证据共同拼合而成。

140项任务仍不足以代表完整企业工作流

SlackBench的主要优势是环境可复现，并且将通信记录与代码变更绑定，而不是让模型在模拟文本中做静态阅读。不过，它仍然更接近“协作信息检索与综合”，而不是完整的自主执行。

真实研发智能体还需要修改代码、运行测试、处理失败、根据工具反馈调整策略，甚至协调多个角色。SlackBench可以评估这些系统的前置能力——能否找对上下文并形成可靠判断——但不能单独证明其规划、执行和错误恢复能力。

140个查询对于细粒度误差分析也可能偏小。特别是拒答任务和情境推断任务容易受到标注粒度、答案可接受范围以及提示策略影响；若不同系统采用不同检索预算、工具权限和上下文窗口，分数不应被简单解释为模型推理能力的纯差异。

最佳约80%，暴露跨证据协调的结构性缺口

在33个前沿模型与智能体框架上，SlackBench的最佳系统得分约80%，多数系统低于66%。这一差距表明，模型已经能够完成相当一部分搜索与摘要，但在以下环节仍不稳定：

• 判断某条消息是否仍代表当前项目状态；
• 将讨论中形成的决策映射到具体代码变更；
• 在证据陈旧或相互冲突时避免过早下结论；
• 对不可回答或错误前提问题执行可靠拒答；
• 在长对话中区分事实、提议、假设和最终结论。

这也提醒评测团队：总分容易掩盖能力结构。一个系统可能在常规检索问题上得分很高，却因错误前提问题中的迎合倾向而降低可靠性；另一个系统的摘要能力一般，但更善于表达不确定性。部署选型应同时查看任务分层成绩，而非只看聚合分数。

工程落地：优先建设证据链，而不是继续堆叠提示词

对于正在开发Slack、Teams、GitHub或企业文档智能体的团队，SlackBench提供了较明确的工程方向。

第一，保留来源与时间元数据。 每条消息、提交、文档段落都应携带作者、时间、项目、状态和引用关系。没有这些字段，模型即使能读到正确文本，也难以判断其权威性与时效性。

第二，把检索与状态核验拆成两个阶段。 检索层负责召回候选线程、文件和提交，核验层再检查当前分支、后续提交和决策文档。直接在向量数据库中拼接文本，会把历史陈述与当前事实混为一谈。

第三，为结论建立证据账本。 每项关键断言应链接到原始消息、代码位置和有效时间；遇到冲突时显式保留备选解释，而不是让生成模型自行压平矛盾。

第四，将拒答纳入训练和验收。 对证据不足、假前提和权限不可见的问题设置独立指标，并按错误类型统计：漏检、误拒、过期证据使用和冲突证据未披露。

第五，控制工具预算。 智能体应先进行小范围线程定位，再按需访问仓库和文档；无差别抓取整个工作区不仅增加token成本，还会提高无关上下文干扰。

基准价值与使用边界

SlackBench的价值不在于提供又一个“最高分模型”榜单，而在于把协作智能体的评测对象从孤立答案扩展为可追溯的工作状态。对于企业知识助手、研发助理和长程智能体团队，它适合用于验证三类能力：跨模态证据发现、随时间变化的上下文重建，以及不确定信息下的受约束回答。

但该基准不应被直接等同于真实生产环境的SLA。隐私保护重演仍可能弱化真实组织中的权限、噪声、临时任务和复杂人际关系；模型与agent harness的表现也会受到检索器、工具接口、token预算和提示模板影响。后续若能扩展任务数量、发布细粒度失败标签，并加入代码修改、测试执行和失败恢复任务，SlackBench将更接近端到端研发智能体评测标准。

结论

SlackBench揭示了协作智能体距离真正“数字同事”仍有明显差距：主要瓶颈不是生成答案，而是从动态、多来源、带冲突的工作环境中重建可信上下文。最高约80%的成绩说明现有系统已有基础能力，而多数低于66%的结果则表明，检索增强、长上下文和工具调用必须被组织成带时间语义、证据追踪和拒答机制的完整工作流。

---

消息来源：ArXiv AI (cs.AI) (2026-11-05)

—— 完 ——

主题标签： #SlackBench 关注 #协作智能体 关注 #Agent评测 关注 #多源检索 关注 #长程推理 关注