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/