谷歌PLE评测揭示工程Agent交付瓶颈

工程项目中，局部计算正确并不等于方案可以交付。电缆桥架若与消防管线争夺同一段净空，即使载流量、电压降和设备选型均正确，进入三维协调阶段仍可能被迫返工。谷歌与Mercor推出的Physical-Engineering's Last Exam（PLE），用85项机械、电气、土木和结构任务检验了这一问题。

在56项隐藏测试中，Claude Opus 5.5结合Claude Code取得48.3%的得分；在人机共同创作任务中，模型平均满足91%的单项约束，但只有41.3%的设计项同时满足全部硬性安全与可行性要求。剩余问题往往不是单纯增加算力就能解决，因为修正一个条件可能破坏另一个条件。

PLE在41项共同创作任务中采用硬约束门控：37项使用统一约束评分，40%考察单项检查通过率，60%评估成本或性能优化，但后者只有在所有硬约束通过后才计入。研究还设置合规基线和合规成本下界，避免模型靠堆设备满足规范，或牺牲可行性换取低成本。

工程设计的优化空间本质上是“可行域”。例如冷却系统中，管径会影响阻力、泵工作点和换热能力，单独压低材料成本可能转化为更高的设备与能耗成本。模型还必须识别接近边界的活跃约束，并处理设备型号、标准尺寸等离散选择；多轮修改后，原本通过的检查也可能失效。

PLE的85项任务包含5170份文件，平均每项约61份，涵盖PDF、表格、邮件、CAD和BIM模型，并混有过期版本。Agent必须判断当前生效的参数和规范，但设备表、计算书、图纸与材料清单可能不同步，单纯准确读取文件仍可能拼接出错误版本。

在一项包含128个机柜的三维机电协调任务中，Agent要布置桥架、母线、冷冻水管和喷淋系统，并结合平面位置、设备尺寸和剖面标高通过碰撞及净距检查。调整桥架路径可能改变线路长度并使压降计算失效，设备位置变化又会牵动相邻管线，因此系统需要维护带依赖关系的设计状态。

理想架构应为设备、管线、构件和计算结果建立对象标识，记录来源文件、修订版本及适用工况；变量变化后，仅重新检查受影响的计算和交付文件。增量计算、失效传播、求解器迭代以及候选版本回退机制，都能减少重复计算并阻止旧结论进入新文件。

同一模型在相同环境下运行同一任务3次，单任务得分平均相差15.4个百分点，说明执行路径会明显影响交付质量。仅扩大上下文或增加工具调用，不能自动解决版本同步问题。

PLE的验证任务中，44项由工程师编写并按专家标准检查，41项采用Creator–Solver机制：Creator生成任务、参考交付物和验证器，Solver在隔离环境中独立尝试，通常运行3次，再由工程师检查规则漏洞。约束还需注明来源，并区分安全可行性硬要求与格式等软要求；验证器要核对规范条款、数值及CAD、BIM、表格中的对象对应关系。

面向生产的验证器应绑定具体工程对象、物理计算、规范条件和设计版本，在变更后按范围重新检查，并反馈违规对象及参数。这样Agent才能针对连续变量的超限程度或离散设备选型持续调整。当前PLE的Solver执行时不能访问隐藏验证器，也没有实时评分；将验证服务接入设计循环，仍需完善可调用服务、增量复核和版本管理等系统架构。