91% ≈ 0%？谷歌最新研究，戳破工程 Agent 的高正确率泡沫

Google 与 Mercor 近期发布的 Physical-Engineering's Last Exam（PLE）基准，通过 85 项机械、电气、土木与结构工程任务，量化了这一落差。

测试显示，Claude Opus 5.5 搭配 Claude Code 在隐藏测试中得分为 48.3%。在共同创作任务中，其单项约束满足率平均为 91%，但仅有 41.3% 的交付设计项同时满足所有硬性安全与可行性要求。

剩余的 9% 缺陷往往无法仅靠提升模型计算能力解决，因为工程约束相互关联，解决一个问题可能引发新问题。PLE 揭示了当局部能力足够强时，工程 Agent 的核心缺失。

工程 Agent 遭遇可行域瓶颈

传统 Agent 评测多采用逐项累积评分，容易掩盖关键失败：模型可能满足绝大多数要求，但遗漏一条决定方案可用性的关键约束。

PLE 引入“硬约束门控”（Hard-Constraint Gating）机制。在评价体系中，40% 分数取决于单项检查通过比例，60% 取决于成本或性能优化。但前提是必须通过所有硬性安全与可行性约束。若违反任一硬约束，即便成本降低也无法获得优化分数。

该机制防止模型通过牺牲可行性换取低成本，或通过过量配置轻松合规。工程设计中的优化受限于约束间的耦合。例如，缩小管径虽节省材料费，但可能增加水力阻力，导致水泵能耗上升，总成本反而增加。

“可行域”指所有约束同时成立的设计范围，受连续参数和离散条件（如设备型号）限制。Agent 需判断哪些条件接近边界，以及修改变量对其它约束的影响（即活跃约束）。91% 的单项通过率表明模型具备局部处理能力，但在多约束共存及后续优化上存在缺口。

长流程能力演变为状态一致性问题

PLE 任务环境包含大量非结构化文件（PDF、CAD、BIM 等），且存在版本迭代。Agent 需从杂乱资料中提取生效参数。工程文件间引用复杂，设备表、计算书与设计图若不同步，模型易组合错误信息。

这超出了普通对话上下文的管理范畴。以三维机电协调为例，调整桥架路径会影响线路长度和压降，进而影响设备选型和相邻管线布局。每一步操作都改变后续条件，已完成的检查可能失效。

工程 Agent 需维护带有依赖关系的设计状态，实现增量计算与状态失效传播。当某变量变化时，系统应识别受影响部分并重新核算，保留未受影响结果。修改应先保存候选版本，通过关联检查后再接受，失败则回退。

PLE 实验显示，同一模型在相同环境下多次运行，得分波动达 15.4 个百分点，表明执行路径显著影响交付质量。单纯扩大上下文无法解决版本同步问题，长流程能力需发展为维护有效设计状态，并配备独立验证机制。

验证器成为工程 Agent 核心基础设施

PLE 采用两种任务构建路径：专家编写和 Creator–Solver 机制。后者由 Creator Agent 生成任务、参考设计及验证器，Solver Agent 在隔离环境中求解。若 Solver 找到捷径或任务存在漏洞，Creator 需修正规则，最终由专家审核。

此机制确保验证程序无漏洞，防止 Agent 生成表面合规实则无效的交付物。共同创作任务要求注明约束来源，区分硬性安全要求与软性格式要求，验证器对照文件核查规范条款和数值。

工程约束需包含适用对象、参数范围、计算条件及依据。验证器需建立跨文件对象关联（如 CAD 几何路径、BIM 属性与表格参数），指出违反要求的具体对象及参数，而非仅返回失败结果。

这种反馈机制使 Agent 能围绕具体约束问题重新生成局部方案，逐步收敛至可行范围。未来架构应将检查程序封装为可调用服务，支持按变更范围重新验证，并将结果绑定至设计版本。

验证方式需多样化：物理计算和几何碰撞使用确定性程序，开放设计说明由 LLM-Judge 辅助。PLE 数据显示，语言模型判定一致性较高，但仍需保存计算输入、规范来源与程序版本以便复核。

Physical AI 需要可签核的设计闭环

该架构对机器人和工业设备开发意义重大。若工程 Agent 能接入 CAD、CAE 及 PLM 系统，自动识别受影响计算并调用专业工具验证，AI 生成设计即可进入现有审查流程。

PLE 虽为受控评测，但将工程 Agent 能力衡量推向实际交付层面。未来 Physical AI 的竞争焦点，在于模型能否持续生成满足约束的设计，并为关键修改提供可复核的计算与验证依据。

参考链接：https://www.mercor.com/blog/introducing-physical-engineering-s-last-exam-ple-with-google-cloud-ai-research/