← 最新论文
🤖 AI

BC-Bench: Evaluating Agentic Engineering in a Domain-Specific Language for ERP

本文介绍了 BC-Bench,这是一个包含 101 个针对 Microsoft Dynamics 365 Business Central 的 AL 特定领域语言的真实世界任务的新型基准测试,旨在证明智能体工程在通用基准测试上的性能并不能可靠地转化为企业级 ERP 上下文中的表现,并强调了对特定领域进行评估的紧迫需求。

原作者: Haoran Sun, Klaus Marius Hansen

发布于 2026-08-24
📖 1 分钟阅读☕ 轻松阅读

原作者: Haoran Sun, Klaus Marius Hansen

原始论文采用 CC BY 4.0 许可(http://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明

在现代软件的世界里,一种新型的劳动者已经出现:一种能够自主编写代码、修复错误并构建程序的智能人工智能。这些被称为“编程智能体”(coding agents)的系统,通过对大量人类编写的指令进行训练,已在通用编程语言(如 Python)中展现出了卓越的技能。它们能够解决曾经需要人类工程师耗费数小时才能攻克的难题。然而,现实世界的商业软件很少如此简单。支撑全球商业运转的大量关键基础设施依赖于为特定行业设计的专业语言,在这些领域,规则各异,工具独特,且风险极高。其中一个典型的环境是企业资源计划(ERP)领域,公司通过它来管理从库存到薪资的一切事务。在这里,软件使用的是一种被称为 AL 的语言,这是一种用于运行微软 Business Central 系统的专业方言。多年来,人们一直不确定这些强大的 AI 智能体是否能够驾驭这种复杂且专有的领域,或者它们在通用编程上的成功是否只是在面对真实的业务约束时便会消退的现象。

为了回答这个问题,微软的研究人员创建了一个新的测试场,名为 BC-Bench。他们并没有发明一个理论性的谜题;相反,他们深入挖掘了驱动真实业务的两套庞大软件仓库中的实际、活生生的代码。研究人员从这些数字档案中,精心挑选了 101 个过去由工程师解决的具体任务。这些并非虚构的例子,而是真实的难题:一个导致客户记录失败的漏洞,销售报告中缺失的功能,或者是一个旨在捕捉错误的测试。随后,研究人员要求世界上最先进的几个 AI 智能体尝试完成这些相同的任务。这些智能体被赋予了原始的问题描述(有时包含错误截图)以及修复前代码的快照。它们的目标是编写出实现问题所需的精确代码变更,就像人类工程师所做的那样。随后,系统会在模拟环境中运行该软件,以观察新代码是否真的修复了问题,同时没有破坏其他部分。

结果揭示了一个这样的景象:AI 模型本身的身份,比它用来工作的具体工具更为重要。当研究人员比较不同版本的智能体时,他们发现,底层大脑——即大语言模型——的选择对成功率的影响,远大于引导它的软件封装器(或称“脚手架/harness”)的选择。例如,最新版本的 Claude Opus 4.6 在与标准工具配合时,解决了近 69% 的漏洞修复任务,而同一模型的旧版本解决率仅约为 58%。相比之下,在保持模型不变的情况下更换工具,产生的差异微乎其微,在统计学上并不显著。这表明,对于这些复杂的业务任务而言,模型的智能程度是成功的核心驱动力,而非它访问代码的具体界面。

最令人震惊的发现或许是,在通用编程测试中看到的进步,并不一定会自动转化为这种专业领域的优势。在更广泛的软件工程领域,较新的模型通常会比其前任表现出稳定且可预测的提升。然而,在这个特定的业务环境中,一个在通用基准测试中表现明显优于前任的模型,在此处并未展现出同样的优势。一个在通用任务中显著进步的模型,在面对这些业务逻辑谜题时,并未比其旧版本表现得更好。这表明,修复一段通用的 Python 脚本所需的技能,与修正专业业务系统中一个财务计算公式所需的技能并不相同。这种专门化语言的特性——即关于数据流向和业务逻辑验证的严格规则——构成了一道仅靠通用训练无法轻易逾越的障碍。

研究人员还仔细观察了智能体失败的原因。他们发现,机器很少是因为无法构建软件或代码无法编译而失败;这些技术障碍很容易被克服。相反,失败几乎总是源于对问题的理解。在近一半的失败尝试中,智能体完全看错了代码部分,编辑了与错误毫无关系的文件的内容。在另一组大规模的失败案例中,智能体找到了正确的文件和正确的代码段,但仍然应用了错误的逻辑,实现了一个看起来正确但并未真正修复业务规则的方案。例如,智能体可能正确识别出客户订单号缺失,但随后编写的代码却分配了错误类型的编号,导致系统依然处于损坏状态。这些错误表明,智能体难以理解定义公司运作方式的深层且相互关联的业务规则网络,它们往往会忽略人类工程师能立即领悟到的微妙上下文。

任务的复杂度也起到了决定性作用。当修复工作仅涉及修改单个文件或少量行数时,智能体的成功率相当高。然而,一旦解决方案需要修改多个文件或编写超过几十行代码,成功率就会大幅下降。这种下降非常剧烈,当任务涉及多个文件时,准确率下降了超过二十个百分点。看来,虽然这些智能体可以处理小型、孤立的修复,但它们在协调大型互联系统中的变更方面仍显吃力。此外,业务领域的类型也至关重要:智能体在处理库存管理方面的故障时比在处理仓库物流方面更为成功,这表明它们的训练数据在某些业务领域可能比其他领域更丰富。

研究结论指出,尽管人工智能在通用编程方面取得了惊人的进步,但在专业业务环境中实现完全自主工程的路径尚不明朗。工具已经存在,模型也非常强大,但通用能力与领域特定精通度之间的差距依然巨大。研究人员强调,要向前迈进,行业需要专注于这些专门的基准测试,而不是仅仅依赖通用测试。他们还指出,目前的局限性不仅在于原始智能水平,还在于理解上下文、导航复杂代码库以及应用正确业务逻辑的能力。随着这些系统的演进,人们希望它们最终能够像现在处理通用编程那样,轻松驾驭复杂的业务软件规则,但目前来看,人类工程师对于引导它们穿越现实世界的复杂性仍然不可或缺。

您所在领域的论文太多了?

获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。

试用 Digest →