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 的实际求解流程。

模型负责提出和调整设计，专业程序负责计算与判定，验证结果则决定哪些修改可以进入下一版有效设计。04Physical 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/