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 中的构件属性，以及电子表格中的设备参数，可能描述同一套系统的不同部分。如果验证程序无法建立对象关联，就只能分别检查文件，很难判断设计结果之间是否一致。