企业软件是另一种考题
9 月 15 日，一篇题为《ERPBench: A State-Grounded Evaluation Paradigm for Computer-Use Agents in Enterprise Software》的论文挂上 arXiv，作者是 Kratika Bhagtani、Kusha Sridhar、Maziyar Baran Pouyan、Yuying Zhao 与 Eugene Siow，投稿目标是 2027 年的 ICASSP。
它要解决的问题不是造一个更强的 computer-use 智能体，而是指出这类智能体目前的考卷出错了。
论文的观察很直接：通过截图操作界面的智能体进步很快，但评测仍锚定在通用桌面与网页任务上。这些任务与 ERP 系统有几处本质差别——界面稠密、需要多步协同，而且最关键的一点：错误不会显现在屏幕上，而是直接改写持久的业务记录。
这句话是整个评测设计的出发点。在网页任务里点错了按钮，通常只是这一轮没完成；在 ERP 里保存了一条错误的采购单，它进了数据库，可能触发下游流程，而且屏幕上什么异常都看不到。
换句话说，通用界面任务里「看得见的失败」比例很高，而企业软件里恰恰相反——失败大多是沉默的。用前者训练出来的评价体系，天然会低估后者的难度。
评测怎么做的
ERPBench 有两处设计值得单独说。
一处是环境与判分。它在一个真实、可复现的 ERP 系统上评测纯截图智能体，也就是只给截图、只给模拟动作的输入输出接口。判分不看向上的界面反馈，而是逐任务对照数据库里的真实值。
另一处是配套的生产级 harness。论文不止给了考卷，还给了一套把智能体动作挡在人工审批之后的门控装置——理由是这类系统要被安全地部署，动作就不能直接落到业务记录上。ERPBench 本身是在这套门控之下自主运行的。
这个设计说明作者的态度：他们不认为当下的截图智能体适合直接接入企业系统。给一套考试工具的同时附带一套刹车，这在评测类论文里并不常见。
那组反差数字
论文评测了六款闭源与开源智能体，得出的核心结论用一句话概括是：通用图形界面上的强表现，并不能迁移到企业级可靠性上。
最能说明问题的是这组数字：即使一个智能体找到了正确的表单并完成了保存，存进数据库的记录依然经常是错的。论文的表述是，有的智能体在最多 85% 的运行里完成了保存，却只在最少 3% 的运行里写对了值。
这里需要标注一处口径。摘要用的是「有的智能体」这种表述，并未说明两个极端值是否来自同一款智能体，也没有在摘要里给出逐款的分项表。因此更稳妥的读法是：保存率与正确率这两个指标在测评中出现了严重脱钩，脱钩的幅度可以大到几十倍。要判断某一款具体产品的表现，需要回到论文正文的表格。
这种脱钩还有一个现实后果：如果采购方只看「任务完成率」这类综合指标，两款表现差异极大的智能体可能拿到相近的分数。指标设计本身会把风险抹平。
为什么「保存成功」并不等于「做对了」
这组脱钩背后是评测方式的问题，而不是模型突然变笨了。
如果考卷只问「任务完成了没有」，那么一次流程走到底、界面回到了列表页，就可以记为成功。企业系统的界面反馈恰好能提供这种「看起来完成了」的信号——表单提交成功、系统弹出保存提示，全都不代表字段值正确。
论文因此把评分锚点从界面移到了数据库。这个改动看着朴素，但它改变了整个评测要回答的问题：不再问智能体会不会用界面，而是问它有没有把事情做对。
这背后是一个更普遍的看法：computer-use 智能体的评测正在从「操作能力」转向「状态正确性」。会点按钮和点对位置，与把正确的结果写进正确的记录，是两种不同的能力；前者可以靠视觉定位解决，后者要求模型理解业务语义——比如「45」填在数量栏和金额栏意味着完全不同的东西。
这也解释了为什么作者要额外提供那套人审批门控。当正确率的最低值只有 3% 时，把动作直接放给智能体的风险不是理论上的。
失败模式里最值得注意的一类
论文提到他们进一步刻画了企业流程特有的失败模式。结合摘要里给出的机制，可以归纳出几类：值写错但保存成功；写到了错误的记录上；任务在界面上看起来完成，但数据库状态与预期不一致。
这几类的共同点是「不可见」。在屏幕层做监控抓不到它们；日志层如果只记录动作而不记录结果值，同样抓不到。要发现它们，必须把评测的基准放在业务记录本身。
对企业来说，这里能延伸出一个更实用的判断：如果要做计算机操作类智能体的验收，验收脚本必须能读业务系统的数据，而不只是回放操作轨迹。回放只能证明「点了什么」，证明不了「改对了什么」。
另一层含义关于人力分工。如果把智能体放在有人审批的门控之后，那审批人就必须看得懂数据库层面的结果，而不只是看界面上的提示。门控装置本身也需要配套的检查能力，否则容易变成一道形式上的签字。
还有一层涉及验收频率。界面层的错误通常能在一次回归测试里暴露；数据库层的错误不会，它会安静地留在记录里，可能几周后才被业务侧发现。这意味着这类智能体的验收不能是一次性的，需要把「定期抽样核对业务数据」做成常规动作，而不是上线前跑一遍就结束。
可以带走的几条
其一，验收标准锚在业务数据上，不锚在界面上。界面的「成功」提示不构成证据。
其二，把保存率与正确率分开测。这两个指标一旦合并成「任务完成率」，问题就会被平均值吞掉。
其三，给写操作加审批门控。论文自己就把 harness 设计成动作前有人工审批。
其四，「通用能力可以迁移到垂直场景」这条经验需要具体验证。这次的数据显示，在通用基准上的强表现与在企业软件上的可靠性，是两件不同的事。
其五，把抽样核对业务数据排进日常流程。静默错误只能靠抽查发现，它不会自己浮到屏幕上来。
需要标注的边界
其一，这是单篇论文的评测结果，样本是六款智能体，投的是会议评审，尚无同行评审结论。
其二，论文使用的是自建的可复现 ERP 系统，与真实企业里高度定制化的 ERP 部署仍有差距。作者选择这条路线的理由是保护商业秘密与保证可复现，代价是外部效度需要更多工作来补齐。
其三，摘要中的极端数字缺少逐款分项，不宜直接用于比较具体产品。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。