Agent 意圖釐清實作課：動手前先問對問題
今日主題：Agent 意圖釐清
2026-11-03 | 資料來源：MAC、Knowing but Not Showing、CondAmbigQA、Abg-CoQA
前言：最貴的錯誤，是把錯的任務執行得很漂亮
Agent 失敗最常見的劇本不是模型不夠聰明，而是使用者一句話裡藏著三種意思，Agent 挑了其中一種，一路做到底，最後交出一份完全正確、但完全不是使用者要的東西。刪錯檔案、寄給錯的人、用錯的預算跑完一整批任務——這些錯誤的事後成本，遠高於事前多問一句話的成本。
弔詭的是，模型其實認得出模糊。2026 年一篇研究發現，模型被直接問「這句話模不模糊」時，往往答得出來；但在實際問答場景裡，它們幾乎總是直接作答，寧可猜也不問。更麻煩的是，給模型更多檢索到的上下文後，它問問題的機率反而更低——上下文讓答案看起來更可答，卻沒有讓意圖更清楚。結論很直接：釐清不能只靠模型的自覺，必須做成系統裡的一道閘門。
本篇談的就是這道閘門：模糊怎麼分類、什麼時候該問、好問題怎麼寫、以及如何用程式把它固定下來。
一、模糊有四種，先分清楚再問
不是所有不清楚都一樣，問法也不一樣。實務上可以先分成四種，如圖一。
第一種是實體模糊：話裡的名詞指涉不明。「把那份報告寄給他」——哪份報告、哪個他？這種模糊通常有客觀答案，優先用檢索或比對解決，查不到再問。
第二種是目標模糊：要的是產出還是行動？「處理一下這封客訴信」可能是要摘要、要回信草稿，也可能是要直接回覆並立案。三種理解導向三種不同的工具呼叫，必須問。
第三種是約束缺失：任務本身清楚，但邊界沒給。預算上限、期限、適用範圍、品質標準缺了任何一項，Agent 只能用預設值硬跑，跑完才發現預設值不對。
第四種是權限模糊：Agent 能不能真的動手？「幫我把這筆訂單取消」在技術上很簡單，但它是一次不可逆的外部承諾，缺的不是資訊，而是授權。這種情況不該用釐清問題帶過，而要走批準流程。
分類的價值在於：前三種用問題解決，第四種用批準解決，混在一起處理，問再多都問不到點上。
二、問不問的決策規則：看決策價值，不看信心
很多團隊把「要不要問」寫成提示詞裡的一句話：「不清楚就問。」結果是 Agent 要嘛什麼都問，把使用者問煩，要嘛什麼都不問，直接猜。更好的規則是決策價值：這個未知數的答案，會不會改變下一步的行動？
問，當兩個合理的解讀會導致不同的行動。收件人不同、金額不同、要動的系統不同，都是該問的訊號。
不問，直接做並說明假設，當答案不影響行動，或影響微小且可逆。報告用三段還是四段、摘要先放結論還是先放背景，都屬於這一類——選一個慣例、寫清楚假設，讓使用者可以一秒糾正。
先查再問，當答案是事實而不是選擇。貨幣代碼、訂單編號、檔案版本都應該先翻授權範圍內的資料，問使用者一個自己查得到的問題，是最浪費信任的行為。
必須問或必須取得批準，當行動不可逆、成本高或涉及外部承諾。寄出、付款、刪除、對外發言，都不該用猜的通過。
這條規則還有一個推論：問問題之前，先把競爭解讀寫下來。如果兩個解讀導向同一個安全下一步，那就直接走那一步，不必打擾使用者。
三、好問題的寫法：一次一題，給選項，綁定決策
釐清問題的品質，決定了使用者願不願意回答。實務上有三條寫法，如圖二。
第一，一次只問一個決定。「請問這份報告的對象、期限和格式是？」看起來有效率，實際上使用者只會回答其中一項，剩下的還要再追一輪。拆成一次一題，總輪次反而更少。多智能體釐清框架 MAC 的實驗也印證了這一點：把釐清做好，任務成功率從 54.5% 提升到 62.3%，平均對話輪次反而從 6.53 輪降到 4.86 輪。
第二，給選項，不要問開放式問題。「你希望什麼時候完成？」不如「這份報告要趕今天下班前，還是週五前就可以？」選項把回答成本從思考降到點頭，也順便揭露了 Agent 目前的理解，使用者一看就知道它想偏了沒有。
第三，問題要綁定決策，而不是要更多背景。「可以多說一點嗎？」不是釐清，是把工作推回給使用者。好的問題長這樣：「這份報告是要寄給客戶（對外口徑），還是內部檢討用（可以寫未確認數字）？」答案一出，下一步的寫法與工具就都定了。
最後還有一個容易漏掉的步驟：確認迴路。使用者回答後，把理解寫回一句話——「確認一下：這份報告對外寄給客戶，今天下班前交，我先出草稿給你過目再寄。」——請對方點頭。釐清的終點不是問完，而是雙方對同一句話達成一致。
四、實作架構：檢測、提問、確認、執行
把上面三節做成程式，架構可以分成四段。
第一段是模糊檢測。收到指令後，先列出競爭解讀：每個解讀對應不同的工具參數或行動序列；如果只有一種解讀，直接執行；如果多種解讀但導向同一行動，選安全的那條並說明假設。
第二段是提問閘門。這是關鍵設計：讓模型輸出結構化決策，而不是自由文字。決策只有三種：執行、提問、請求批準。提問時必須同時輸出「缺失的決定」與「不問會造成的後果」，後果寫不出來，就代表這個問題不值得問。
第三段是確認迴路。把使用者的回答合併回任務描述，重新跑一次檢測，直到沒有會改變行動的未知數為止。實務上要設停損：同一任務最多釐清兩輪，超過就先做一個可逆的草稿版本交差，而不是無限追問。
第四段是評測。釐清能力是可以量化的：AmbigQA 指出自然語言問題中超過一半帶有歧義；Abg-CoQA 的對話式評測裡，最好的系統在釐清後問答的 F1 只有 40.1%，落後人類表現 35 個百分點；CondAmbigQA 則顯示，模型在回答前先明確考慮各種條件，表現可以提升約 20%。這些數字說明同一件事：釐清不是禮貌，是能力缺口。
五、最小可跑骨架：把決策價值寫成程式
不需要複雜框架，先把第二節的規則寫成一個函式，讓它在每次工具呼叫前跑一次：
# 決策價值閘門：會改變行動的未知數才問，否則用預設值並說明假設
def clarify_or_act(task, interpretations, reversible=True):
distinct_actions = {interp.next_action for interp in interpretations}
if len(distinct_actions) == 1:
return {"decision": "act",
"assumption": "各解讀導向同一行動，採預設值並明示"}
if not reversible:
return {"decision": "ask_approval",
"question": "此行動不可逆，請確認目標與範圍"}
missing = pick_decision_changing_question(interpretations)
return {"decision": "ask",
"question": missing.question,
"options": missing.options}
這個函式的重點不在程式碼本身，而在它強迫團隊回答一個問題：每一個未知數，到底會不會改變行動？答不出來的未知數，就不應該出現在使用者面前。
結論：問得少，問得準
好的 Agent 不是問得多的 Agent，也不是從不問的 Agent，而是把問題花在刀口上的 Agent：先分類模糊，再用決策價值決定問不問，問的時候一次一題、給選項、綁定決策，最後用確認迴路把共識寫下來。釐清做得好，使用者感覺到的不是被打擾，而是被理解——因為 Agent 問的每一個問題，都剛好是他本來就想先說清楚的那一個。
參考來源
- MAC: A Multi-Agent Framework for Interactive User Clarification in Multi-turn Conversations, arXiv: https://arxiv.org/html/2512.13154v1/
- Knowing but Not Showing: LLMs Recognize Ambiguity but Rarely Ask Clarifying Questions, arXiv: https://arxiv.org/html/2605.25284v1
- CondAmbigQA: A Benchmark and Dataset for Conditional Ambiguous Question Answering, arXiv: https://arxiv.org/abs/2502.01523v1
- Abg-CoQA: Clarifying Ambiguity in Conversational Question Answering, AKBC 2021: https://www.akbc.ws/2021/assets/pdfs/SlDZ1o8FsJU.pdf
- How to Make an AI Agent Ask Clarifying Questions: https://www.mariusmanolachi.com/blog/how-to-make-an-ai-agent-ask-clarifying-questions
- When an AI Agent Should Ask for Missing Information: https://www.digitalapplied.com/blog/ai-agent-clarification-missing-information
