ExplorationBench 測 AI 如何探索陌生規則：知道答案，和能設計實驗是兩種能力
ExplorationBench 用兩個人造規則世界測試 AI 的自主探索。本文解讀環境回饋、發現規則與實際運用的差異，以及企業可以如何驗證代理學習。
AI 在熟悉題目上答得很好，並不代表遇到陌生系統時會知道怎麼查證。ExplorationBench 把測試焦點放在這個問題：模型能否提出假設、設計探測、讀取環境回饋，再把新發現用在後續任務。這和單純延長思考或提供更多檔案，是不同的能力。
研究使用兩個人造規則世界，避免模型只靠已有知識回答，也讓結果能夠由程式明確判定。它提供的是探索能力的受控測試，不能直接寫成模型已經能夠獨立完成真實科學發現。對企業讀者，更值得帶走的是如何檢查代理有沒有根據證據修正判斷，而不是只讓它不斷說得更有信心。
兩個陌生世界，讓規則可以被客觀核對
官方介紹的 AlienCode 改動三十一項程式規則，AlienLogic 改動二十四項邏輯規則，合計一百四十道測試題。模型從有錯誤的手冊與固定例子開始，經過四輪探測，使用工具取得回饋。結果由執行與證明檢查機制判定，不依賴另一個語言模型當裁判。
研究比較十個系統，並保留不同探索軌跡。主要結果使用三次軌跡中的最佳分數，也提供平均與細節。這個統計選擇很重要，因為最佳表現與穩定表現回答不同問題，不能只用一個最高分描述日常可靠性。
研究發現環境回饋有助於探索，但說對規則仍不一定能在任務中正確運用。這些結論適用於所設計的環境。它們能啟發代理評估，卻不能直接推算所有行業、工具與真實實驗都具有相同效果。
熟悉知識與陌生規則，需要不同測試
傳統問答容易測到模型已經學過的內容。即使題目很難，模型也可能透過訓練資料中的模式作答。若想知道它能否面對新的規則，就需要讓答案無法直接從已有知識取得。
人造環境的優勢是可以清楚控制規則與評分。研究者知道正確行為，模型則需要探索。這樣比較容易判斷它是否從回饋獲得新資訊，而不是只是說出聽起來合理的解釋。
缺點是環境與真實世界仍有距離。現實系統可能有噪音、延遲與不完整資料，實驗成本也不同。因此，基準適合測某種能力，實際應用還需要自己的情境測試。兩者互補，不應互相替代。
只多想幾輪，不一定帶來新證據
如果模型一直使用相同資料繼續推理，可能重新整理已有資訊，也可能反覆強化錯誤假設。沒有新證據時，長篇解釋不一定讓結論更可靠。探索則需要主動取得能夠區分假設的觀察。
例如一個服務返回錯誤，模型可以猜測許可權、格式或網路問題。真正有幫助的下一步，是查錯誤碼、測試最小請求或讀取目前狀態。每個動作都應能排除某種可能，而不只是增加文字。
企業評估代理時，可以觀察它提出的動作是否有明確目的。若每次失敗都換一種說法重試，卻沒有檢查回饋，就很難說它正在學習。能夠根據結果調整下一步，才比較接近有效探索。
好的探測，應能區分多個解釋
假設一個系統對相同輸入返回不同結果，可能來自狀態、時間或引數。一次改變多個條件，很難知道原因。比較清楚的探測是固定其他條件，只改變一個因素，讓結果對假設有區分力。
這和一般工程診斷的方法相通。先建立最小可重現例子，再逐步加入變化，比直接在複雜流程中反覆嘗試更容易找到規則。代理能否採取這種方式，是值得單獨檢查的能力。
探測也要控制成本。如果一個動作耗費很久，卻無法回答目前問題，未必是合理選擇。評估不只看最後分數，也應看代理使用多少工具、花多少時間與取得什麼證據。
用一個陌生內部工具設計測試
以下是企業測試示例。團隊可以建立一個不影響正式資料的模擬工具，讓它有幾項明確但未直接告知的規則。代理需要透過查詢與少量嘗試，理解輸入條件，再完成後續任務。
例如工具只接受某種日期格式，或不同狀態只能進行特定轉換。任務應有固定正確結果，讓檢查能夠獨立於代理的自我說明。測試環境也應清楚隔離，避免探索過程碰到真實客戶資料或正式操作。
觀察重點是代理有沒有讀回饋、形成可驗證解釋，以及把發現用到新題目。只在同一個例子上成功，可能只是記住輸出。換一個相近但不同的案例仍然正確，才更能支援規則理解。
發現規則，與執行規則應分開評分
代理可能能說出系統接受某種格式，卻在實際操作時仍送出錯誤值。也可能正確解釋狀態順序，卻在後續任務跳過步驟。語言說明與工具行為不同，不能只因為解釋漂亮就判定任務透過。
可以分別評估規則報告與執行結果。前者檢查代理是否理解條件，後者檢查它是否正確使用。兩項分開，能讓團隊知道瓶頸是發現、記憶還是操作，也更容易安排修正。
若代理發現正確規則後仍反覆犯錯，可以在工具介面或流程加入明確檢查。不要只要求它更仔細。把可確定的條件交給程式驗證，能讓模型的推理與系統的約束配合。
多次軌跡，才能看見探索穩定性
一次成功可能來自恰好提出了好的探測，一次失敗則可能來自錯誤起點。若只展示最好的一次，讀者容易高估日常表現。重複執行能觀察同樣預算下結果是否一致。
團隊可以保留幾次獨立測試的結果，同時報告最好、平均與失敗情況。最好表現說明潛力，平均表現說明典型情況，失敗紀錄則說明可能需要接手的條件。不同數字應服務不同決策。
如果結果差異很大，可以分析哪些早期動作造成分岔。某個探測可能迅速找到關鍵規則，另一個則耗掉預算卻沒有新資訊。這樣的過程分析，比只比較終點分數更有助於改進。
錯誤經驗，也可能被繼續使用
代理從一次結果推導規則時，可能誤把偶然情況當成一般規律。若之後沒有重新驗證，錯誤經驗會影響更多工。長期工作不僅需要記住，也需要知道什麼時候應該懷疑舊判斷。
可以要求重要規則附上支援證據與適用範圍。某次格式測試成功，只支援該格式在目前條件可用，不自動證明所有輸入都適用。把範圍寫清楚，能夠減少經驗被過度推廣。
若新回饋與舊規則衝突，代理應保留衝突而不是忽略。進一步測試可能發現環境改變、原假設錯誤或資料不完整。能夠處理矛盾，是探索過程中的重要能力，也應進入評估。
工具回饋品質，影響學習方向
如果工具只返回失敗，卻沒有可用狀態，代理很難判斷原因。如果錯誤訊息不穩定，探索也可能朝錯誤方向進行。模型能力與工具回饋應一起設計，不應把所有學習困難都歸給模型。
可用回饋應描述發生什麼，例如引數不符、資料不存在或目前狀態不允許，而不是只給一段模糊訊息。回饋不必直接告訴答案，但應讓合理探測能夠取得區分資訊。
評估時可以先確認工具本身的結果穩定。若環境隨機變化，卻沒有把這種變化納入規則，代理表現就難以解釋。受控測試的價值，正是讓能力比較有清楚條件。
記憶資料，要保留來源與有效時間
把探索經驗儲存下來，有機會減少重複工作，但記憶也可能過期。內部工具升級後，舊格式與舊流程未必仍然成立。經驗紀錄應包含來源、版本與驗證時間，讓代理知道何時需要重新檢查。
可以把確認過的規則與暫時假設分開。前者有重複證據，後者仍需要驗證。若兩者都寫成確定事實，未來任務可能把尚未證實的猜測當成依據。
長期記憶的品質也不只看數量。少量可靠、範圍清楚的規則，可能比大量雜亂日誌更有用。企業應觀察記憶是否改善任務，而不是只觀察代理儲存了多少文字。
探索預算，應和任務價值連在一起
不是所有問題都值得進行長時間探索。簡單格式錯誤可以用小測試解決，複雜系統規則則可能需要更多步驟。團隊可以為不同任務設定合理的工具次數、時間與停止條件。
達到預算後，代理應交代已取得證據、仍不確定的部分與下一步需要什麼。這樣的交接讓人工能夠繼續，而不是留下一個看似完整卻未經驗證的答案。預算控制也能避免無效反覆。
比較不同模型時，預算應儘量一致，並記錄實際使用量。若一個系統使用更多時間與工具，較高分數不能只歸因於模型更強。效率與結果需要同時觀察。
真實科學任務，還需要領域證據
ExplorationBench 採用人造環境，是為了讓規則與答案能夠及時判定。真實科學問題通常沒有這種即時檢查，實驗還可能涉及昂貴裝置、複雜資料與領域知識。因此，不能把基準成功直接寫成獨立科學發現能力。
它可以提供一些基礎觀察，例如模型是否會提出可檢驗假設、使用回饋與處理矛盾。真正的科學應用則需要對應領域的研究設計與驗證。把基準與應用分層，能夠避免過度宣傳，也能保留研究本身的價值。
對企業而言，最實用的啟發是建立可核對回饋與過程紀錄。代理面對陌生業務規則時，能否逐步取得證據，比它是否會使用科學術語更重要。
這項研究改變了哪些評估問題
ExplorationBench 把焦點從模型現在知道什麼，移到它如何從互動取得新能力。它提醒使用者，資訊進入上下文、規則被說出來與任務實際完成，是不同階段。
團隊可以據此檢查自己的代理：動作有沒有目的，回饋有沒有被使用，規則有沒有被驗證，後續任務有沒有正確執行。把這些過程看清楚，才能知道一個系統是在探索，還是只不斷產生更長解釋。
這項研究的價值，不必靠誇大成通用科學能力來成立。它提供了一套更細緻觀察學習與探索的方法，也讓代理評估更接近長期真實工作的需要。
測試報告還可以儲存關鍵轉折：哪一次回饋讓代理修正了假設，修正後哪些任務成功，哪些仍失敗。這些紀錄能幫助團隊理解能力如何形成，也讓下一次改進有方向。若只儲存最後回答，就很難看出探索過程是否真的帶來新證據。
