谷歌PLE评测：工程Agent单项满足91%，交付合格仅41.3%

机房顶部一条电缆桥架只要和消防管线撞上，几十页算得没问题的计算书就白做了。载流量对、电压降达标、设备选型也有出处，可一进三维空间，几套系统抢同一段净空，工程师只能把方案退回去。

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里有一项三维机电协调任务：机房含128个设备机柜，Agent要为其布置电缆桥架、母线、冷冻水管和消防喷淋。位置从平面图取，尺寸从设备表读，标高依据剖面信息确定，最后输出能通过碰撞和净距检查的三维模型。

真正的技术难点出现在连续修改的过程中。假设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 的求解方式也会跟着变：它可以围着相关参数重新生成局部方案，再跑一遍检查。

连续参数可以借助超限程度来调整方向，设备型号这类离散变量则重新筛出满足要求的候选配置。验证结果一轮轮反馈回来，设计搜索会慢慢收拢到可行范围内。不过 PLE 现在的 Solver 在执行时拿不到隐藏验证器，也得不到实时评分。独立检查复杂交付成果这件事它已经做到了，可要让验证器直接进到 Agent 的设计循环里，还得另加系统架构。

具体来说，要把检查程序封装成可调用的服务，支持按变更范围重新验证，并把检查结果绑定到具体的设计版本上。这样 Agent 改完局部设计，就知道哪些条件要重新核算、哪些已有结果还能用。

检查方式本身也该分开。物理计算、数值边界、几何碰撞，交给确定性程序或专业求解器合适；比较开放的设计说明，可以让 LLM-Judge 帮忙审阅。PLE 对 1159 次涉及语言模型判定的运行重新打过评分，同一模型逐项判断一致的比例是 98.7%，但换了判定模型，差异依然存在。落到实际工程里，验证结果还该留下计算输入、规范来源和程序版本，让工程师能逐条复核关键结论。

这些能力建起来之后，验证器就不只是交付后的检查工具，会一步步走进 Agent 的实际求解流程。模型负责提出和调整设计，专业程序负责计算与判定，验证结果决定哪些修改能进入下一版有效设计。

这种架构对机器人和工业设备开发有直接意义。机械臂改了连杆结构，刚度、振动和驱动负载都可能受影响，原来的仿真结果要重新检查；驱动器或电池配置一变，散热、装配和电气设计也得跟着更新。

工程 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/