最强企业 Agent 也只考了 0.663 分：一个从真实公司会话里"挖"出来的基准
你有没有过这种体验：一个 Agent demo 看着特别能打，在公开榜单上分数也漂亮，结果真接到自己公司的活儿——读一堆乱七八糟的内部文件、调几个工具、最后要交一份能直接发给老板的 PPT 或者 Excel——立刻露馅。
我自己踩过这个坑。榜单分数和"真能干活"之间，隔着一条很宽的河。
这篇 EnterpriseClawBench 干的事，就是把那条河量出来给你看。它不是又造了一批人工编的题，而是直接从一家真实公司三个月的 Agent 使用记录里，把任务"考古"出来，做成可复现的基准。结论很扎心：在这套基准上，最强的组合（Codex + GPT-5.5）也只拿到 0.663 分。企业 Agent 离"能用"，还差得远。
核心摘要
现在的 Agent 评测有个老毛病——把一切压缩成一个分数。但企业场景里，"好不好"根本不是一个数能说清的：同一个模型换个框架（论文叫 harness）分数能差 0.2，交付的文件能不能打开、PPT 渲染出来好不好看、跑一次花多少钱多少时间、从一个任务里学到的技能能不能迁移到同类任务——这些全是耦合在一起的结果。
EnterpriseClawBench 从一家百人 AI 创业公司 2026 年 3-5 月的真实工作会话出发，经过一条自动化流水线，把 5,291 条原始任务实例提炼成 852 个可复现任务（外加 120 个人工精审的 Lite 子集）。因为数据含企业内部内容，论文不开源数据集，开源的是这套构建与评估协议。它强迫你同时报告：harness-model 组合、产物交付、文本/视觉语义质量、成本、运行时间、技能迁移行为。
我的判断：数据不开源确实让"基准"二字打了折扣，复现性存疑。但它提出的多维评估范式和"技能作为迁移单元"的思路，是真的戳中了企业 Agent 评测的痛点。值得一读，尤其如果你在做 Agent 产品落地。
论文信息
- 标题：EnterpriseClawBench: Benchmarking Agents from Real Workplace Sessions
- 作者：Jincheng Zhong、Weizhi Wang、Che Jiang、Kai Tian、Zhenzhao Yuan、Junlin Yang、Dianqiao Lei、Kaiyan Zhang（共 8 人）
- arXiv：2606.23654 [cs.CL]，提交于 2026 年 6 月 22 日
- 代码：https://github.com/FrontisAI/EnterpriseClawBench （仅协议，不含数据）
🎯 为什么需要又一个 Agent 基准？
坦率讲，Agent 基准已经一大堆了。SWE-Bench、各种 ClawBench、WorkspaceBench……再出一个，凭什么？
论文给的理由是它盯上了三个现有基准没填好的缺口，我觉得这三个点确实站得住：
缺口一：真实性和可扩展性总是二选一。 要么任务是真实的但量很小（人工标几十条就到头了），要么任务量大但全是人工编的、模拟的，或者基于公开环境造的。真实企业里那种"读 12 个附件、跨群聊澄清需求、最后交一份带公司特定口径的财务分析"的脏活儿，公开基准里基本见不到。
缺口二：性能不是模型一个人的事。 这点我特别有感触。同一个模型，套不同的 Agent 框架，表现能差出一大截。框架管不管审批、能不能自主探索环境、会不会在产物写完前就截断执行——这些都直接决定成败。把这些因素糊成一个"模型分数"，等于把锅全甩给模型，不公平也不准。
缺口三：技能能不能迁移，没人正经测。 大家都在讲"Agent 可以沉淀技能、复用技能"，但一个从任务 A 里提炼出来的技能，真放到同类任务 B 上，到底是涨分还是掉分？这事儿得有任务分类法（taxonomy）才能系统地测——你得先知道哪些任务是"同一类"的。
把"框架"（论文里叫 claw / harness，比如 OpenClaw、Codex 这种脚手架）当成和模型平起平坐的一级评测对象——这个视角，是我觉得这篇最清醒的地方。
🏗️ 怎么从"聊天记录"里挖出一个基准
先看整体流水线。这张图把"从企业会话到基准任务"的四个阶段讲得挺清楚：
流水线四阶段：① 企业 Agent 会话（工作空间 + 持久化 Linux 沙箱 + 上传的文件/聊天记录）→ ② 任务恢复与并行机械检查（5,291 条原始实例经过滤得到 3,813 条机械可用候选）→ ③ 基准任务构建与打包（自包含过滤、单轮 prompt 改写、角色类/技能子类分类、硬规则、语义评分标准，最终 852 个任务 + Lite 120）→ ④ 评估分析（独立沙箱运行、harness-model 组合、产物收集、规则检查、Sonnet 4.6 文本+视觉评判）。
数据从哪来
来自一家百人规模 AI 创业公司自己内部持续在用的企业 Agent 系统，覆盖 2026 年 3 月到 5 月。员工在企业协作平台上（私聊或群聊）跟 Agent 说需求、丢文件，期望产物出现在一个持久化的 Linux 工作空间里——输入挂在 input 目录，生成的东西写到 output 目录。
这就是真实工作流，不是实验室里编的。
怎么把噪声会话变成可复现任务
原始会话是真的脏：多轮对话、群聊时间戳、账号哈希、系统噪声、被遮蔽的 URL……直接拿来当任务根本没法跑。论文设计了一条流水线来"洗"：
第一步先做任务候选恢复，把会话回合拆开或合并成候选任务实例。然后是一组机械门槛串行过滤——长度过滤（剔空消息和极短消息，用户字符少于 10 个直接扔）、fixture 查找（必须能恢复出可复现的输入文件，恢复不出来就不要）、编辑恢复（靠上下文把被打码的 URL/路径还原，只在高置信度时接受）、网络依赖检查（外部链接挂了的任务剔掉）。
这一关下来，5,291 条原始实例只剩 3,813 条机械可用候选。
接着是自包含判定：这个任务能不能改写成一句话就说清楚的独立 prompt？如果原始会话里 Agent 当时还反过来追问用户澄清，说明任务本身信息不全，剔除。然后把杂乱的多轮原始请求改写成单轮基准 prompt，再打上 role classes（角色类） 和 skill subclasses（技能子类） 的标签，检测预期交付物，附上 hard rules（硬规则） 和 semantic rubrics（语义评分标准），最后做沙箱预检——上传能不能成、Agent 能不能跑、产物能不能下载、评判能不能正确路由。
全套跑完，852 个任务，外加人工精审的 Lite 120 子集。
这 852 个任务长什么样
四个面板：A. 角色类分布——产品/项目 220（26%）、工程/IT 174（20%）、HR/行政 102（12%）、高管 89（10%）、销售/客户 88（10%）、营销 77（9%）、财务/运营 64（8%）、其他 38（5%）；B. 各角色下的技能子类结构，工程/IT 有 9 个子类最多，其余多为 6 个，共 45 个；C. 输入 fixture 文件 719 个，MD 占 29%、DOC 18%、图片 16%、PDF 8%……类型高度异构；D. 预期交付物 887 项，MD 39%、TXT 32%、HTML 9%、DOC 6%、PPT 3%、图片 1%……
我看到这张图第一反应是：输入输出的模态是真的杂。输入里有 Markdown、Word、图片、PDF、表格、代码、压缩包；输出要的东西从纯文本到 HTML 页面到幻灯片都有。这种异构性，恰恰是真实办公场景的样子——你不可能指望员工只丢纯文本给 Agent。
双层评分：客观规则 + 语义评判
评分分两层，这个设计挺实在。
Hard rules（硬规则） 管客观交付属性：文件类型对不对、数量够不够、是不是空文件、能不能打开、有没有报错 traceback、有没有没替换掉的占位符。这些是硬指标，不达标直接扣。
Semantic judges（语义评判） 管质量，按产物模态路由：能提取文本的产物走文本评判器；HTML/幻灯片/PDF/电子表格/图像这类，先渲染成截图或页面图，再走视觉评判器。语义打分沿五个维度：
- grounded accuracy（基于证据的准确性，说人话就是别瞎编）
- task relevance（任务相关性）
- substantive depth（实质深度）
- practical utility（实用价值）
- communication quality（沟通质量）
这五个维度后面会发现一个很有意思的规律，先按下不表。
📊 实验：最强组合也才 0.663
重点来了。先看主排行榜——在 Lite 120 个任务上，跑了 32 个 harness-model 组合，用 Sonnet 4.6 同时当文本和视觉评判器。
横轴是 32 个 harness-model 组合，柱高为分数（%），柱顶标注成本（人民币）和每任务平均运行时间。最高 66.3（Codex/GPT-5.5），最低 20.0，平均仅 48.6。颜色区分 5 个框架：Codex、DeepAgents、ClaudeCode、Hermes、OpenClaw。
最高分 66.3 分（也就是 0.663，Codex + GPT-5.5），平均才 48.6 分。这说明什么——企业产物任务离"被刷爆"差得远，还有大把空间。
框架能把模型坑得很惨
这是我觉得全文最有价值的发现。
Sonnet 4.6 这个模型，在 Claude Code、DeepAgents、OpenClaw 三个框架下都稳定在 0.62–0.64 区间，挺能打。但一换到 Hermes 框架，直接掉到 0.458。
为什么？论文给的解释是：Hermes 通过审批检查，把 Agent 主动探测环境、跑脚本、多步修复的路给堵了；或者在产物写入循环还没完成时就把执行轨迹截断了。
这就是框架和模型的兼容性问题，不是模型能力不行。你想想看，如果只报一个"Sonnet 4.6 = 0.458"的分数，你会以为是模型菜，实际上是框架拖了后腿。这个 case 把"必须报告 harness-model 组合"这个核心主张，论证得明明白白。
成本和分数：花得多不一定考得好
成本-分数大致是个对数形的非线性关系——中端往上，多花的钱边际收益递减。最离谱的异常值还是 Hermes/Claude 系列：钱花了不少，分数没上去。这进一步坐实了上面那个兼容性问题。
角色类和产物类型的差异
- GPT-5.5 是最稳的通才，在多个角色类上领先；
- 营销和财务/运营最难——这俩需要重度文档理解 + 公司特定的业务口径，泛化模型容易抓瞎；
- 产物类型上，GPT-5.5 在 HTML、code/JSON 等交付密集类别最强，但 Opus 4.6 在电子表格上反超；
- 一个要警惕的点：视觉评判对电子表格和演示文稿存在系统性虚高——这个坑后面校准实验会兑现。
五个维度里，最差的是"准确性"
还记得前面那五个语义维度吗？跨模型看下来，系统普遍在沟通质量和任务相关性上表现好，但在 grounded accuracy（基于证据的准确性）上明显偏弱。
翻译一下：Agent 很会"说得漂亮、答得切题"，但经常在大堆上传文件里定位不到关键信息，或者在长流程执行中把信息搞丢。
说实话，这个发现一点都不意外，但被量化出来还是挺有冲击力的。这不就是我们用 Agent 时最头疼的事吗——它特别会包装，但你得逐字核对它有没有真的读懂你给的材料。
852 全量集：排序稳住了
Lite 只有 120 题，会不会是小样本的偶然？论文在全量 852 任务上、用 DeepAgents 框架又跑了一遍可扩展性检查：
| Model | Score | Text | Visual | Rule |
|---|---|---|---|---|
| GPT-5.5 | 0.766 | 0.813 | 0.642 | 0.959 |
| Sonnet 4.6 | 0.749 | 0.793 | 0.634 | 0.957 |
| Haiku 4.5 | 0.632 | 0.666 | 0.542 | 0.963 |
| GPT-4.1-mini | 0.336 | 0.383 | 0.213 | 0.817 |
表：全量 852 任务集在 DeepAgents 框架下的可扩展性检查
排序和 Lite 子集一致，而且即便最强模型也没饱和。注意一个细节：所有模型的 Visual 分都明显低于 Text 分（GPT-5.5 文本 0.813 但视觉只有 0.642）——视觉产物是公认的硬骨头。
🔬 技能能迁移吗？高方差，看人下菜
这是论文第三个卖点，也是我觉得最有想象空间的部分。
实验聚焦一个子类：前端页面生成。流程是这样——拿 10 个域内任务收集执行轨迹，让一个 skill creator 模型从中提炼出"技能"，再把这个技能注入回 consumer 模型，最后在 5 个留出任务上看注入前后的分数变化。
矩阵每个单元报告"无技能分数 → 技能注入分数"及 delta，颜色编码增益（蓝色为正、橙色为负）。按 creator 模型看平均迁移 delta：GPT-5.5 最强 +0.068（无负 delta），Kimi K2.6 平均为正 +0.052，Haiku 4.5 最弱、均值为负 -0.094。
几个有意思的结论：
会创建技能 ≠ 会消费技能。 一个模型擅长从任务里提炼技能，不代表它用别人的技能也用得好，反过来也一样。
技能注入是高方差操作。 同一个 HTML 任务，正向迁移的案例能从 0.756 涨到 0.844（+0.088），负向的案例却能从 0.756 掉到 0.555（-0.201）。结果取决于 creator 质量、consumer 行为、creator 和 consumer 匹不匹配、以及 consumer 的基线分数。
我对这块的判断是：思路很对，但 5 个留出任务实在太少，方差这么大的情况下，这些 delta 数值我只敢当趋势看，不敢当定论。论文自己也承认是高方差。这个方向值得做，但需要更大规模的验证。
⚠️ 评判器靠谱吗？视觉评判翻车了
用 LLM 当裁判，最容易被质疑的就是"裁判自己准不准"。论文做了校准，而且没有藏着掖着——结果有点尴尬但很诚实。
先看 LLM 之间的一致性：GPT-5.4-text 和主文本评判器 Sonnet 4.6 的相关系数 ρ=0.918（1,853 个案例），视觉评判 ρ=0.866（1,428 个案例）。看着不错。
但跟人类一比，问题就出来了：
| Scope | n | Human | Sonnet | MAE | Spearman |
|---|---|---|---|---|---|
| Overall | 48 | 0.571 | 0.498 | 0.219 | 0.263 |
| Text | 24 | 0.476 | 0.504 | 0.134 | 0.790 |
| Visual | 24 | 0.666 | 0.492 | 0.303 | -0.259 |
表：Sonnet 4.6 评判器的人类校准审计（48 个 packet）
文本路由和人类对得很齐（MAE 0.134，Spearman 0.790）——这块可信。
但视觉评判明显拉胯：MAE 高达 0.303，更要命的是 Spearman 相关系数是 负的 0.259（-0.259）。负相关说明，模型给视觉产物打的高低分，和人类的判断几乎是反着来的。
这就兑现了前面那个"视觉评判系统性虚高"的伏笔。多模态产物的自动评估，目前真的还不成熟。论文敢把这个负相关明明白白写进表格，我得给它点个赞——很多论文遇到这种数据会想办法藏掉。
📌 跟其他基准比，它站在哪
论文用一张对比表给自己定位：
| 基准 | 任务数 | 真实来源 | 多模态 | 技能评估 | 成本/时间 | 组合数 |
|---|---|---|---|---|---|---|
| Workspace-Bench | 388/100 | ✓ | ✓ | ✗ | 部分 | 28 |
| EnterpriseBench | 500 | ✗ | ✗ | ✗ | 部分 | 10 |
| WildClawBench | 60 | ✗ | ✓ | ✓ | ✓ | 31 |
| ClawBench | 153 | ✗ | ✓ | ✗ | ✗ | 7 |
| Claw-SWE-Bench | 350/80 | ✓ | ✗ | ✗ | 部分 | 17 |
| SkillsBench | 87 | ✗ | ✓ | ✓ | 部分 | 18 |
| EnterpriseClawBench | 852/120 | ✓ | ✓ | ✓ | ✓ | 32 |
表：EnterpriseClawBench 与相关基准的对比定位
从表上看，它确实是少数几个在"真实来源 + 多模态 + 技能评估 + 成本/时间"四项上全勾的，组合数也最多（32 个）。当然，这种自家做的对比表，勾叉标准多少有点"主场优势"，看看就好。
💡 我的判断
先说我喜欢的地方。
把 harness 抬到一级评测对象，这个视角是对的。 Hermes 把 Sonnet 从 0.62 拖到 0.458 那个 case，足够说服我了。我们平时讨论"哪个模型做 Agent 强"，其实问错了问题——应该问"哪个模型配哪个框架强"。
多维报告比单一分数诚实得多。 成本、时间、文件交付、文本/视觉质量分开报，逼着你看清一个 Agent 到底贵在哪、慢在哪、错在哪。这对做产品落地的人来说，比一个榜单排名有用一百倍。
敢公开视觉评判的负相关。 这种诚实在 benchmark 论文里不多见。
再说我的保留意见。
数据不开源，是这篇最大的硬伤。 "Benchmark"这个词，核心就是可复现、可对比。它开源了协议，但数据锁死。别人没法用同一批任务复现你的 0.663，也没法在你的任务上测自己的新模型。这更像是"一份评估方法论 + 一份内部测评报告"，而不是一个社区能共建的基准。当然，企业内部数据合规我理解，但代价是真实的。
技能迁移实验太单薄。 5 个留出任务、还是高方差，这些 delta 我只能当方向性证据看。
视觉评判既然这么不准，那基于视觉评判的那些结论（比如 Opus 在电子表格上强、视觉分系统性虚高）就得打个问号。 论文自己也意识到了这个矛盾，但没完全解决。
放到行业坐标里看：它不是底层方法突破，是一次评估范式的整合与升级——把"真实数据 + 框架维度 + 多维报告 + 技能迁移"打包成一套协议。价值在视角和方法论，不在某个新算法。
如果你在做企业 Agent 产品，我的建议是：不必纠结于它具体的分数（反正你也复现不了），但它的评估维度清单值得抄作业——下次评测你自己的 Agent，别只看一个总分，把框架、成本、时间、文件能不能打开、视觉质量分开来看。光是这一点，就够这篇论文值回票价了。
最后留个开放问题：当框架（harness）对结果的影响能大到 0.2，我们是不是该重新想想——所谓"模型能力"的评测，到底有多少是模型的，多少是脚手架的？这条线，可能比我们以为的要模糊得多。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我