AI Agent 不該只會聽話：XY 問題如何讓修錯走錯路

「網站很慢，能不能先把快取時間從五分鐘改成一天？」這聽起來像一個明確的工程任務。但如果延遲其實來自資料庫鎖定，延長快取可能讓畫面短暫變快，卻把過期資料留得更久。使用者描述的症狀、猜測的原因與提出的修法，不一定是同一件事。

這類溝通落差稱為 XY 問題：使用者詢問如何做 X，真正需要解決的卻是 Y。Google DeepMind 研究員 Been Kim 共同署名的 XYEval 論文於 2026 年 9 月 20 日提交，將這個問題帶進 Agent 評測：當使用者給出一個看似可信、實際上會把任務帶偏的建議，Agent 能否查證、修正方向，並讓使用者理解原因？

把建議當假設，回到任務的成功條件

許多互動系統被訓練得很會配合。這有助於降低操作摩擦，卻可能讓 Agent 把語氣肯定的診斷誤當成已確認的需求。若它直接改錯檔案、選錯工具，或在客服流程中採取多餘動作，最後仍可能看起來很忙，卻沒有解決使用者原本遇到的事。

工程上可以先把請求拆成三層：

1. 觀察到的事實：實際錯誤訊息、重現步驟、日誌、使用者想完成的交易或預期結果。
2. 使用者的假設：可能原因、建議的檔案、要呼叫的工具或希望採用的 workaround。
3. 可驗證的成功條件：測試通過、狀態符合政策、資料正確，或目標流程確實完成。

建議可以提供線索，但它不能取代成功條件。Agent 應先找出哪個觀察能區分「X 是根因」和「X 只是猜測」，再決定要執行、查證或提問。這也延伸了 AI Agent 架構指南談的設計原則：工作流程需要明確狀態、工具邊界與驗證迴圈，不能只靠模型把提示理解得更有信心。

XYEval 怎麼把「壞建議」變成可測試條件

XYEval 是一個把既有基準改造成 XY 問題測試的 meta-evaluation 框架。研究者保留原任務的環境與評分 oracle，再把一段誤導建議加入任務指令；因此，比較的是同一任務在一般提示和加入建議後的表現差異。對部分原本已包含使用者猜測的 SWE-bench Verified 題目，研究者先將客觀問題描述與主觀方向拆開，再用誤導建議替換主觀方向，避免同一提示裡互相衝突。

這些「使用者建議」的來源很重要：在 SWE-bench，Gemini 3.5 Flash 讀取問題與正確 patch 後，透過內部工具 harness 產生錯誤方向；在 Terminal-Bench，生成器會讀取任務、正確解法與驗證測試，有些模型由受測模型自己生成建議；在 HLE，受測模型也替自己生成誤導提示。Tau-bench 則由研究者按航空、零售與電信領域設計規則式建議。它們是受控的模型生成或專家設計測試材料，不是從真實使用者對話隨機抽樣出的發生率。

研究評估 Gemini 3.1 Pro、Gemini 3.5 Flash、Gemini 3.7 Flash、Claude Opus 4.8 與 GPT 5.5，橫跨 τ²-bench、SWE-bench Verified、SWE-bench Pro、Terminal-Bench、Humanity’s Last Exam（HLE）及 MCP-Atlas。這六套基準的任務形式與評分方式並不相同；例如 HLE 是單輪問答，不是會呼叫工具的 Agent 工作流。XYEval 的價值在於把同一種「建議會不會誤導判斷」問題套到多種既有評測，而不是證明所有場景具有相同風險。

46.7% 是什麼分母？

論文報告的最大相對降幅出現在 Terminal-Bench：Gemini 3.1 Pro 的 Pass@1 從原始任務的 67.4% 降到加入建議後的 36.0%。相差 31.4 個百分點；以原始 67.4% 作為分母，才得到 46.7% 的相對分數下降。所以「Agent 在 46.7% 的任務被誤導」不是這個數字的正確解讀。

基準與模型	原始分數	加入建議後	相對變化
Terminal-Bench，Gemini 3.1 Pro	67.4%	36.0%	−46.7%
τ²-bench，Gemini 3.5 Flash	85.6%	53.8%	−37.2%
MCP-Atlas，Gemini 3.1 Pro	79.6%	58.8%	−26.2%

以上是各基準報告分數的相對變化；τ²-bench 用平均任務 reward，MCP-Atlas 用主張覆蓋率，其他基準則主要採 Pass@1 或 accuracy。研究附錄另外計算「只看原本已解出的任務」時的下降，這個 solved-only 分母能更直接觀察受建議影響後失敗的已解題，但不應與全題庫分數混為一談。

結論不是所有模型、任務都會掉 46.7%。模型間差距很大；例如 Claude Opus 4.8 在 Terminal-Bench 的相對下降為 9.1%，而 Gemini 3.7 Flash 在 SWE-bench Pro 甚至增加 2.4%。資料顯示，在這些設定下，錯誤建議可能改變解題路徑；它不等同於對實際使用者的發生率估計。

能在心裡發現問題，還要讓使用者聽懂

XY 問題不只考驗根因分析，也考驗溝通。τ²-bench 的延伸測試讓模擬使用者在 Agent 提出正確反對意見後繼續堅持，直到 Agent 解釋為什麼建議無助於任務。論文發現，這類「難纏使用者」會讓多數領域的表現進一步下降；鼓勵 Agent 說明理由的 system instruction 有幫助，仍留下明顯缺口。

研究者也分析互動軌跡：在 τ²-bench 中，受測 Agent 平均有 92.1% 的軌跡在內部推理中辨認出問題或政策限制；然而，在標準誤導建議條件下，部分模型仍會在對話中沒有說出不同意見。這個結果顯示，「內部看出來」和「清楚告訴使用者」是兩個不同的品質維度。若產品只記錄最終任務成敗，就很難知道是沒有發現問題、沒有執行驗證，還是明明起疑卻沒有解釋。

把異議設計成可驗證的工作流程

對 coding agent，可以把流程做成一組明確的檢查點：

1. 重述目標：確認使用者要看到什麼正確結果，不急著採用其根因猜測。
2. 保留建議來源：記錄某個診斷是使用者提出、檢索取得，還是 Agent 推論，避免之後把假設誤認為觀察事實。
3. 尋找可區分的證據：讀相關程式碼、重現問題、跑針對性測試，或查工具回傳的狀態；避免因為建議聽起來合理，就直接改動。
4. 說明決策與不確定性：如果證據支持另一條路，簡短指出原建議會解決什麼、沒有解決什麼，再提出下一步；若證據不足或涉及高影響操作，先澄清或請求確認。
5. 驗證結果：執行成功條件，把測試結果連回任務，而不是把「照建議做完」當成完成。

這些檢查點也適用於客服或工具代理。客服 Agent 可以先檢查訂單與政策狀態，再決定是否取消訂單，而非只因使用者說「應該取消」就執行；資料 Agent 則可先核對查詢結果是否支持使用者預設的結論。當 Agent 的建議有副作用時，檢查點還應連到工具授權與人工批准，而不是由模型單方面宣告判斷正確。上線評審可以借用 Agentic AI 平台契約的 Evidence、Policy、Judge、Trace 四個面向，將這種能力納入系統控制與回歸測試。

評測時也別只看「拒絕了多少建議」。對每題至少記錄原始任務結果、加入誤導建議後的結果、建議來源、Agent 是否查證、是否找到真實目標、是否清楚說明、工具副作用，以及使用者是否需要進一步追問。否則，過度懷疑所有使用者也可能把原本簡單的任務拖慢，甚至拒絕正確建議。

研究邊界與延伸閱讀

XYEval 是一套有控制條件的 benchmark，不是對真實產品對話的普查。錯誤建議有些由模型根據正確解法生成，有些由專家規則設計；不同資料集的受測模型與建議生成模型也不完全獨立。不同 benchmark 的基線、評分 oracle、任務形式各異，分數只能在各自設定下解讀。作者在論文中表示會釋出 benchmark，但我在 2026 年 9 月 24 日 重新查詢其指定的 GitHub repository 時，GitHub API 回傳 HTTP 404；目前無法驗證或取得可用的公開 artifact。

這篇文章聚焦在實務流程與評測解讀；若要深入看 XYEval 的完整變異方法、模型分析與逐項結果，請讀本站的論文導讀：XYEval——Agent 為什麼會對錯誤建議說好。要延伸到工具推理的域外評測，可讀 AgentEscapeBench：評測 Agent 域外工具推理；要回到 Agent 的基本架構，可從 AI Agent 架構指南開始。

來源

• Wu, Zhengxuan, Yuxuan Li, Oyvind Tafjord, and Been Kim. “XYEval: Agents say yes to bad advice.” arXiv:2609.23939, submitted 2026-09-20. 全文與附錄, CC BY 4.0。
• 論文宣告的程式碼位置：google-deepmind/xyeval（截至 2026-09-24 查核時回傳 HTTP 404，公開可用狀態未能驗證）。