91% ≈ 0%？谷歌最新研究，戳破工程 Agent 的高正确率泡沫

41.3% 的设计项跨过安全门槛，复杂工程仍困于约束耦合。

作者丨郑佳美

编辑丨岑 峰

在工程世界里，91% 的正确，有时和 0% 的交付能力没有区别。

一条电缆桥架在机房顶部穿过消防管线，就能让几十页正确的计算书失去交付价值。载流量算对了，电压降符合要求，设备选型也有依据，但进入三维空间后，几套系统争夺同一段净空，工程师只能退回方案。

AI Agent 能快速完成局部计算，工程项目却不会按计算题的边界运转：一处调整牵动另一处，刚核验过的结果也可能随修订失效。

Google 与 Mercor 近日发布的 Physical-Engineering's Last Exam（PLE），以 85 项机械、电气、土木与结构工程任务量化了这种落差。

在 56 项隐藏测试中，Claude Opus 5.5 搭配 Claude Code 得分 48.3%，而在共同创作任务中，它平均满足 91% 的单项约束，只有 41.3% 的交付设计项满足全部硬性安全与可行性要求。

更棘手的是，剩下的 9% 往往无法靠继续提高模型的计算能力解决。因为工程设计中的要求彼此关联，解决一个问题，可能又会产生新的问题。

PLE 的技术设计恰好揭示了这一困境：当局部能力已经足够强，工程 Agent 究竟还缺少什么？

01

工程 Agent 正在遭遇可行域瓶颈

此前很多 Agent 评测采用逐项累积分数的方式，只要完成更多要求，就能取得更高评价。这适合衡量知识理解和单点执行能力，却会掩盖工程设计中的一类关键失败：模型可能满足了绝大多数要求，但剩下一条恰好决定方案能否投入使用。

PLE 在 41 项人机共同创作任务中，将工程约束与设计优化放进同一套评价体系。其中 37 项采用约束评分，在统一评分机制下，40% 的评分空间取决于单项检查通过比例，另外 60% 则与成本或性能优化有关。不过，优化部分存在一个前提：全部硬性安全与可行性约束必须通过。

研究团队将其称为硬约束门控（Hard-Constraint Gating）。

这个机制有一处关键设计。即使某个方案能够显著降低材料费用，只要违反了一项硬约束，就无法获得成本优化部分的分数。系统仍然记录它已经完成的检查，但不会允许经济收益抵消工程缺陷。

PLE 同时设置了合规但未经充分优化的基线方案，以及合规成本的下界。前者用于判断 Agent 是否产生了实际优化收益，后者则为成本改善提供衡量尺度。这样，模型既不能通过选用过量设备轻松满足规范，也无法靠牺牲可行性获得漂亮的成本数字。

这种评分方式让一个长期存在的问题变得清晰：工程设计中的优化空间受到约束限制，并且约束之间往往存在联系。

例如，在冷却系统设计中，管径决定水力阻力，水力阻力影响水泵工作点，而实际流量又决定换热能力。Agent 如果只根据材料成本缩小管径，后续可能需要更高扬程的水泵，原本节省的费用反而转移到设备和运行能耗上。

工程上把所有约束同时成立的设计范围称为可行域。它包含连续变化的参数，也受到设备型号、标准尺寸等离散条件限制。模型每修改一个变量，其他参数能够选择的范围便可能发生变化。

这给 Agent 带来一种与普通推理不同的要求。生成候选方案之后，还需要判断当前哪些条件已经接近允许边界，以及下一次修改会影响哪些约束。工程优化中，这些限制进一步调整空间的条件通常被称为活跃约束。

PLE 没有直接为 Agent 提供可行域搜索算法，但硬约束门控让这种能力缺口可以被测量。91% 的单项约束满足比例说明，模型已经能够处理大部分局部要求，剩余困难集中在多个条件共同成立，以及满足条件后继续优化。

而当设计从单次求解进入长时间、多轮修改时，问题还会继续扩大：此前满足的约束，未必在下一轮操作后仍然有效。

02

长流程能力正在变成状态一致性问题

PLE 的任务环境没有将设计条件整理成一份完整说明。85 项任务累计包含 5170 份文件，平均每项约 61 份，涉及 PDF、电子表格、邮件、CAD 和 BIM 模型，其中还混有已经作废的设计版本。

Agent 需要在这些材料中确认当前生效的参数和规范，再将它们用于计算与交付。麻烦在于，工程文件之间存在大量引用关系。设备表修改了容量，计算书可能还沿用旧值，设计图更新了布局，材料清单却未必同步调整。模型即使能够准确读取每份文件，也可能将不同版本的信息组合在一起。

对于长流程 Agent，这意味着任务状态已经超出普通对话上下文的管理范围。

在软件开发中，修改一个模块后，可以根据依赖关系决定哪些代码需要重新构建。工程设计也需要类似能力，但对象更加复杂。它不仅涉及文件之间的引用，还包含物理参数、空间关系以及规范的适用条件。

PLE 中有一项三维机电协调任务，要求 Agent 为包含 128 个设备机柜的机房布置电缆桥架、母线、冷冻水管和消防喷淋。系统需要从平面图获得位置，从设备表读取尺寸，再根据剖面信息确定标高，最终输出能够通过碰撞和净距检查的三维模型。

这里的技术难点发生在连续修改过程中。假设 Agent 为了消除一处空间冲突调整桥架路径，线路长度随之增加，原有的压降计算可能失效。如果随后重新调整设备位置，桥架路径和相邻管线又需要修改。

每一步操作会改变下一步使用的设计条件，而此前已经完成的检查也可能需要重新执行。因此，工程 Agent 需要维护一套带有依赖关系的设计状态。

在这种架构下，设备、管线、构件和计算结果具有明确的对象标识，参数还关联来源文件、修订版本和适用工况。当某个设计变量发生变化，系统能够识别受到影响的计算和交付文件，只重新检查相关部分。

这背后对应的是增量计算与状态失效传播机制。例如，设备容量发生变化后，与其相关的配电回路需要重新核算，而没有受到影响的结构计算可以保留。对于管网流量与阻力这类相互影响的参数，系统还需要调用求解器进行迭代，直到相关物理条件重新成立。

设计修改也不能立即覆盖原有结果。更合理的处理方式，是先保存候选版本，在关联检查通过后再接受修改。如果检查失败，则保留问题位置和相关参数，重新调整或回退。

这种状态管理能够减少重复计算，也能防止旧版设计结论继续进入新交付文件。PLE 的实验显示，同一模型在相同环境下对同一任务运行 3 次，单任务得分的平均跨度达到 15.4 个百分点。

研究并没有将波动归结为某一种错误，但结果表明，执行路径会显著影响交付质量。仅仅扩大上下文或允许更多工具调用，并不能自动解决设计版本与计算结果之间的同步问题。

长流程能力因此需要从记住操作过程，进一步发展到维护有效设计状态。而要判断一次状态修改能否被接受，就需要能够独立检查工程结果的验证机制。

03

验证器将成为工程 Agent 的核心基础设施

PLE 在验证机制上采用了两条任务构建路径。44 项任务由专业工程师直接编写，并根据专家评分标准检查交付成果，另外 41 项则采用 Creator–Solver 机制，让 Agent 参与任务环境、参考设计和可执行验证程序的构建。

在后一种机制中，工程师先给出实际工作需求，Creator Agent 据此寻找工程资料，生成任务文件、参考交付物和验证器。随后，独立的 Solver Agent 在隔离环境中尝试求解，无法查看参考答案和评分程序。

研究团队通常让 Solver 进行 3 次尝试，再由 Creator 分析执行轨迹。如果 Solver 找到了绕过工程计算的捷径，或者任务本身缺少必要约束，Creator 就需要修改任务与验证规则。完成这些步骤后，专业工程师还会检查任务要求、参考设计和验证器是否一致。

这套机制解决的是工程评测中一个容易被忽略的问题：验证程序本身也可能存在漏洞。

如果只检查某些容易提取的数值，Agent 可能生成一份表面符合要求、实际却不完整的交付物。Creator–Solver 通过独立求解检验这些漏洞，使任务要求与评分条件能够反复校准。

PLE 在这里还加入了一个技术细节：共同创作任务中的约束需要注明来源，并区分硬性安全与可行性要求，以及文档格式等软性要求。Solver 也需要列出使用过的规范条款和具体数值，验证程序会对照相关文件核查。

这相当于把原本散落在工程规范里的要求，转换为能够由程序执行的检查条件。

一条工程约束需要包含适用对象、参数范围、计算条件和来源依据。验证器只有明确这些信息，才能判断某个交付结果是否符合要求。例如，相同的电缆规格在不同敷设条件下可能对应不同的容量限制，直接抽取规范中的单个数值，并不足以完成可靠检查。

进一步看，这种方法还需要解决跨文件的对象对应问题。CAD 中的几何路径、BIM 中的构件属性，以及电子表格中的设备参数，可能描述同一套系统的不同部分。如果验证程序无法建立对象关联，就只能分别检查文件，很难判断设计结果之间是否一致。

因此，面向生产环境的验证器，需要能够识别具体工程对象，并将物理计算、规范条件和交付文件关联起来。这样，当某项检查失败时，系统能够指出违反要求的对象、对应条件及其当前参数，而不只是返回一个失败结果。

这会进一步改变 Agent 的求解方式。如果验证器能够反馈具体的约束问题，Agent 就可以围绕相关参数重新生成局部方案，再次执行检查。

对于连续参数，可以利用超限程度辅助调整，对于设备型号等离散变量，则重新筛选满足要求的候选配置。随着验证结果不断反馈，设计搜索会逐渐收敛到可行范围。

需要注意，PLE 目前的 Solver 在执行期间无法访问隐藏验证器，也不会得到实时评分。它已经实现了独立检查复杂交付成果的能力，但让验证器直接进入 Agent 的设计循环，还需要额外的系统架构。

其中包括将检查程序封装为可调用服务，支持按变更范围重新验证，并把检查结果绑定到具体设计版本。这样，Agent 修改局部设计后，就能知道哪些条件需要重新核算，哪些已有结果仍然有效。

验证器本身还需要采用不同的检查方式。物理计算、数值边界和几何碰撞适合交给确定性程序或专业求解器，较开放的设计说明可以由 LLM-Judge 辅助审阅。PLE 对 1159 次涉及语言模型判定的运行重新评分，同一模型的逐项判断一致比例达到 98.7%，但更换判定模型后仍存在差异。

对于实际工程，验证结果还应当保存计算输入、规范来源与程序版本，使工程师能够复核每项关键结论。

随着这些能力建立，验证器就可以从交付后的检查工具，逐渐进入 Agent 的实际求解流程。模型负责提出和调整设计，专业程序负责计算与判定，验证结果则决定哪些修改可以进入下一版有效设计。

04

Physical AI 需要可签核的设计闭环

这种架构对机器人和工业设备开发具有直接意义。机械臂修改连杆结构后，刚度、振动和驱动负载可能受到影响，原有仿真结果需要重新检查，驱动器或电池配置变化后，散热、装配与电气设计也需要同步更新。

如果工程 Agent 能够接入 CAD、CAE 和产品生命周期管理系统，在设计修改时自动识别受影响的计算，调用专业工具验证，并保留完整的修订依据，那么 AI 生成的设计就有条件进入现有工程审查流程。

PLE 目前仍是受控环境中的评测，不能替代制造试验与正式签核。但它已经将工程 Agent 的能力衡量推进到更接近实际交付的位置。

未来 Physical AI 的竞争，将逐渐体现在模型能否持续生成满足约束的设计，并为每次关键修改提供工程师可以复核的计算和验证依据。

参考链接：https://www.mercor.com/blog/introducing-physical-engineering-s-last-exam-ple-with-google-cloud-ai-research/

未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！

公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。