谷歌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里有一项三维机电协调任务，要求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 的实际求解流程。模型负责提方案、调设计，专业程序负责算和判，验证结果则决定哪些改动能进入下一版有效设计。

这套架构对机器人和工业设备开发是实打实有用的。机械臂一改连杆结构，刚度、振动和驱动负载都可能受牵连，原来的仿真结果得重新过一遍；驱动器或电池配置一变，散热、装配和电气设计也要跟着同步更新。

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