這項由南京理工大學與福可斯科技股份有限公司旗下Focus AI Center聯合開展的研究，於2026年6月24日以預印本形式發布在arXiv平台，論文編號為arXiv:2606.25605v1，分類於電腦科學·計算與語言領域。有興趣深入了解的讀者可通過該編號在arXiv上查詢完整論文。
**故事從一個生產環境裡的怪事說起**
某天，一家公司的技術團隊在部署自家的AI助手時，發現了一件讓人摸不著頭腦的事情：他們的AI明明配備了搜索網路的能力，當任務需要去外部查數據的時候，AI卻不去查，而是直接生成了一份看起來格式漂漂亮亮、內容卻完全是"胡編"出來的報告。更奇怪的是，一旦把"必須按照固定格式輸出"這個要求撤掉，AI立刻就恢復正常，乖乖地去聯網搜索，再把真實數據整合進答案里。這個神秘的開關究竟是什麼？研究團隊決定深挖這個問題。
歸根結底，這篇論文研究的是現代AI助手系統里一個被長期忽視的危險盲區——當你同時要求一個AI"去用工具查數據"和"按照規定格式輸出答案"時，AI可能會悄悄地把前一個要求完全拋到腦後，專心滿足後一個，而且它不會告訴你它這樣做了。研究團隊給這個現象取了一個專門的名字，叫做"工具抑制"（Tool Suppression），並通過大量實驗把它的來龍去脈徹底說清楚了。
---
**一、 先搞清楚這兩個能力分別是什麼**
要理解這個問題，先得搞明白現代AI助手到底有哪兩種核心能力在這裡碰撞。
第一種叫做"工具調用"（Tool Calling）。簡單說，現在的AI不只是一個會聊天的程序，它還可以像操控工具一樣去調用外部資源。比如，當你問AI"今天股市怎麼樣"，AI知道自己的記憶里沒有今天的實時數據，它就會主動發出一個"請求"，去調用聯網搜索工具，把最新結果拉回來，再告訴你。這就像一個聰明的秘書，知道自己不知道的事情，懂得打電話去問專家，而不是瞎猜。
第二種叫做"結構化輸出"（Structured Output）。當AI被部署在真實的企業系統里時，它的回答往往不能是隨意的聊天式文本，而是必須按照一個預先設計好的"模板"來輸出，比如必須是一個JSON格式的數據包，裡面必須包含"公司背景"、"產品分析"、"風險評估"等規定欄位，格式必須嚴格對應，這樣下游的其他程序才能自動讀取並處理。這就好比政府部門要求你填一張標準化的申請表，每一欄必須填什麼，不能隨便寫。
這兩種能力單獨來看，AI都能完成得很好。研究的關鍵問題就在於：當這兩種要求同時開啟，會發生什麼？
---
**二、 "工具抑制"——一個隱藏在生產環境裡的陷阱**
研究團隊把他們發現的這個現象精確地定義了出來。所謂"工具抑制"，指的是這樣一種情況：一項任務明確需要外部資訊（比如查公司背景、查市場行情），AI也具備調用工具的能力，但在同時被要求按格式輸出的情況下，AI完全放棄了工具調用這個動作，直接生成了一份格式合規但內容來源存疑的回答。
這個定義有三個關鍵點。首先，任務本身確實需要外部數據，不是那種靠AI自身知識就能回答的問題。其次，AI在沒有格式約束時是能正常調用工具的，也就是說能力本身沒問題。第三，一旦加上格式約束，工具調用這個動作就消失了，直接跳到生成最終回答的步驟。
研究團隊還特別強調，這和另一種叫"工具無能"的問題是完全不同的兩回事。"工具無能"是AI根本不會用工具；而"工具抑制"是AI明明會用，但在特定條件下就是不用了。這就好比一個會游泳的人，平時游得很好，但只要讓他穿上西裝，他就不下水了——不是不會游，是被什麼東西"攔住了"。
為了量化這個現象，研究團隊設計了兩個指標。一個叫"工具調用率"（Tool Invocation Rate，TIR），就是在一批任務里，AI至少發起一次工具調用的比例，範圍從0%到100%。另一個叫"抑制率"（Suppression Rate，SR），用來衡量加上格式約束後，工具調用率相比沒有約束時下降了多少。如果有約束時調用率和沒約束時一樣高，抑制率就是0%，說明沒問題；如果有約束時調用率變成了0，抑制率就是100%，說明發生了完全性的工具抑制。
---
**三、 被觀察到的五種"失職"表現**
研究團隊不只是記錄了"AI沒有調用工具"這一個結果，他們還細緻地觀察了AI在這種情況下究竟生成了什麼樣的輸出，並總結出了五種不同的行為模式，形成了一套分類體系。
第一種叫"空殼合規"（TS-A）。AI生成的回答格式完全正確，所有規定的欄位都有，但裡面的內容是空的——比如"推薦方案"一欄裡面是個空列表，"關鍵發現"裡面是個空數組。AI相當於交了一張填好了欄目但每欄都空著的表格，完美地滿足了格式要求，但沒有提供任何實質內容。這種行為主要出現在一個代號為GPT-OSS-20B的模型上。
第二種叫"模擬檢索"（TS-B）。這種情況更危險——AI生成的內容看起來像是經過真實搜索得來的，有具體的公司資訊、有市場數據，但實際上根本沒有任何工具被調用過，這些內容全都是AI"編"出來的。因為內容看起來很像真實檢索結果，下游系統和不細心的人很難察覺異常。這種行為主要出現在代號為Qwen3.5-122B-A10B的模型上。
第三種叫"口頭承諾不執行"（TS-C）。AI在輸出里明確表達了"我需要使用搜索工具"、"需要查詢外部資訊"這樣的意思，甚至在格式化的回答里填了一個欄位說`"need_search": true`，但實際的工具調用就是沒有發生。這種模式特別有研究價值，因為它說明AI在某種程度上"知道"自己需要用工具，但就是沒能執行這個動作。
第四種叫"無工具幻覺"（TS-D）。AI既沒有調用工具，也沒有聲稱需要調用，就直接生成了聽起來很流暢、很自信的回答，但這些內容沒有任何外部數據支撐。這是五種模式里危險程度最高的，因為AI生成的內容往往非常流暢自然，既沒有"我不確定"這樣的提示，也沒有任何信號表明內容可能不準確，極易誤導用戶或後續的自動化系統。
第五種叫"強制要求也無效"（TS-E）。研究人員嘗試在代碼里明確設置`tool_choice="required"`，這是一個API級別的強制指令，相當於直接告訴AI"你必須調用工具，這是命令"，但即便如此，在格式約束同時開啟的情況下，工具調用依然沒有發生。這說明這個問題不是簡單地通過指令提示就能繞過去的。
---
**四、 實驗怎麼設計的，結果有多驚人**
為了把這件事研究清楚，團隊設計了一套對照實驗。他們準備了三種不同的"配置組合"，只改變工具和格式約束的開關，其他所有條件——模型、任務內容、提示詞——全部保持完全一致。
第一種配置（T1）是"只開工具，不要求格式"，這是基準狀態，用來驗證AI在沒有格式約束時能不能正常用工具。第二種配置（T2）是"工具和格式約束同時開啟"，這就是真實的生產環境，也是問題的核心所在。第三種配置（T3）是"不開工具，只要求格式"，用來驗證AI在沒有工具調用任務時能不能正常生成格式化輸出。
測試用的任務集涵蓋了五類真實商業場景：買家背景分析、公司資質核查、市場情報搜索、產品知識檢索、合規與風險調查。這些任務有一個共同特點，就是都需要外部資訊才能完成，不是靠AI自身的知識儲備就能應付的。
研究團隊一共測試了七個不同的模型，橫跨了多種規模、多種架構、多種部署方式。其中包括一個商業閉源模型作為參照，其餘六個都是開源的開放權重模型，參數規模從200億到3970億不等，既有本地部署的，也有雲端部署的。每個模型在每種配置下獨立運行5輪。
結果非常一致，甚至可以說觸目驚心。在T1配置（只有工具，沒有格式約束）下，所有被測試的模型工具調用率都是100%，沒有任何一個模型失敗。在T3配置（只有格式約束，沒有工具任務）下，所有模型也都能正常生成格式化輸出，合規率普遍達到100%。然而一旦切換到T2配置（兩個約束同時開啟），所有開源模型的工具調用率立刻變成了0%——一次都沒有，完全的工具抑制。唯一的例外是那個商業閉源模型，它在T2配置下依然能正常調用工具。
---
**五、 為什麼會這樣？深入代碼找到了真正的"幕後黑手"**
工具調用率變成0%，這個結果夠震驚的了，但更重要的是弄清楚為什麼。研究團隊順著推理框架的代碼一路往下追，最終在一個叫做"語法約束解碼"的機制里找到了根本原因。
這裡需要解釋一個關鍵機制。當你在調用AI的API時，如果你設置了"response_format"這個參數，要求AI輸出一個符合特定JSON格式的結果，在幕後會發生這樣一系列事情：系統會把你的JSON格式要求編譯成一種叫做"有限狀態機"（FSM）的數學結構——可以把它理解成一張精確的地圖，規定了AI在生成文字時每一步只能走哪些路。然後在AI每次要"選下一個字"的時候，這張地圖會檢查當前位置允許走哪些路，不允許走的路就直接把"通行許可"設成負無窮，相當於完全封死，讓AI在物理上就不可能選那個字。
問題就出在這裡。AI調用工具的方式，對於Qwen系列模型來說，是生成一段以`
研究團隊還做了一個具體的驗證：他們直接檢查了T2配置下JSON格式要求對應的有限狀態機，查看三種典型狀態（初始狀態、處於鍵的位置、處於值的位置）下各種詞元的可達性。結果清楚地顯示，``、``以及`websearch`等工具相關的詞元，在所有三種狀態下都被標記為"不可達"。這就像一個人被關進了一個房間，房間裡所有通向外面的門都被鎖死了，不管他怎麼想出去，都是物理上不可能的事情。
這個發現還解釋了另一個重要現象：為什麼各種微調和強化學習訓練都沒能解決這個問題。研究團隊測試了多種訓練方法，包括專門針對工具使用的監督微調、注入格式感知的指令調優、用強化學習（GRPO）優化，以及規模高達6000條樣本的大規模微調。結果是所有這些方法在T2配置下都沒有任何改善，工具調用率依然是0%。原因很簡單：這些訓練方法改變的是模型參數，影響的是AI在做選擇之前的"意向"；但語法約束的詞元隱藏發生在意向之後、實際選字之前，這兩個環節之間沒有梯度連接，訓練的效果根本傳不過去。這就像是，不管你怎麼訓練一個人的游泳技術，只要門被鎖死，他就是游不出去。
---
**六、 "約束優先級倒置"假說——模型層面還有另一層故事**
語法約束的詞元封鎖，解釋了為什麼AI不能生成工具調用的那段文字。但這還不是完整的故事。研究人員注意到一個有趣的現象：有些模型在TS-C模式下，確實在輸出的格式化內容里寫下了`"need_search": true`，明確表達了需要搜索的意圖，但工具調用就是沒有發生。這說明模型在某個層面上"知道"自己需要用工具，只是最終沒有執行。
為了解釋這個現象，研究團隊提出了一個叫"約束優先級倒置"（Constraint Priority Inversion，CPI）的行為假說。這個假說的核心思想是：當AI同時面臨"完成工具調用"和"生成格式化輸出"兩個目標時，格式合規這個目標可能會在AI的行為決策中占據主導地位，把工具調用這個目標擠到一邊去。
研究團隊非常謹慎地強調，CPI只是一個基於觀察行為提出的假說，是一種對現象的解釋框架，而不是一個已經被驗證的內部機制。目前的證據支持這樣一個兩層解釋：在解碼層面，語法約束的詞元封鎖是導致工具調用消失的直接物理原因；在模型行為層面，CPI假說提供了一個與觀察結果相一致的解釋，但還需要更多研究才能確認它是否真實反映了模型內部的決策機制。
---
**七、 工程上的解決方案：把兩件事分開做**
既然問題出在"兩個約束同時生效"，最直接的工程解決思路就是：把它們拆開來，一件事一件事地做。研究團隊提出的方案叫"透明雙階段執行"（Transparent Two-Pass Execution），原理相當簡潔。
在第一階段，只開工具，不要求格式。AI可以自由地調用搜索、查詢知識庫等各種工具，做完它需要做的所有資訊收集工作。這個階段沒有任何語法約束，所以`
在第二階段，把第一階段收集到的所有工具結果放進上下文裡，再次調用AI，這次關掉工具、開啟格式約束。AI基於真實的外部數據，生成一份格式完全合規的結構化輸出。因為這個階段不需要調用工具，語法約束的詞元封鎖也不會造成任何問題。
實驗結果顯示，這個方案效果非常顯著。工具調用率從0%恢復到100%，JSON格式合規率保持在100%沒有下降，端到端任務成功率從完全失敗恢復到100%成功，每次任務平均發起了5到8次工具調用。更重要的是，之前在工具抑制狀態下出現的"模擬檢索"和"無工具幻覺"現象大幅減少，因為AI現在使用的是真實查到的外部數據，不再需要胡編內容。
當然，這個方案也有代價。因為需要跑兩次AI推理，時延會增加大約一個完整推理輪次加上工具執行時間，Token消耗也會增加，因為第二輪要把第一輪的所有工具輸出都塞進上下文裡。不過在實際的企業部署場景里，任務能否成功完成通常比推理成本更重要，所以這個權衡在多數情況下是可以接受的。值得注意的是，這個方案不需要改任何模型權重，不需要重新訓練，只需要調整調用邏輯，可以直接部署在現有系統上。
---
**八、 這件事對整個行業有什麼啟示**
這項研究揭示出來的問題，遠不只是一個模型的一個bug那麼簡單，它觸及了當前AI系統評估方式的一個根本性漏洞。
目前業內評估AI工具調用能力的做法，通常是單獨測試"AI能不能調用工具、調用得準不準"。評估AI結構化輸出能力的做法，也是單獨測試"AI能不能按格式輸出、格式符不符合要求"。兩個能力分別測試都是好的，但這項研究表明，兩個能力都測試通過，並不能保證它們同時運行時也能正常工作。這就像是，分別測試了一輛車的剎車和油門都是好的，但沒有測試過同時踩兩個會發生什麼。
研究團隊建議，未來的AI評估標準應該包含專門的"聯合約束"測試場景，明確考察工具調用和結構化輸出同時開啟時的系統行為。
從AI系統設計的角度來看，這個發現說明了一件重要的事：語法約束解碼這種在推理框架層面強制執行格式的機制，其影響範圍遠不止輸出格式本身。它會在token層面干涉AI的行為空間，把某些本應可以發生的動作（比如工具調用）從物理上排除掉。這意味著，設計AI系統時不能只考慮模型的"智能"，還必須考慮推理框架的約束機制會如何與模型行為交互。
還有一個值得關注的現象：在所有被測試的開源模型中，工具抑制完全發生，但那個商業閉源模型（GPT-5.4-mini）在同樣配置下卻沒有出現這個問題。研究團隊給出了一個合理的推測：商業模型可能在實現結構化輸出時採用了不同的機制，比如通過指令層面的引導而不是解碼層面的語法約束，或者使用了一種支持工具調用標記與JSON同時存在的更靈活的語法約束實現。但由於無法看到商業模型的內部實現，這個推測還不能被驗證。
研究還指出，語法約束詞元封鎖這個機制，理論上不只影響工具調用。任何需要生成JSON格式之外的特殊標記的Agent行為，包括工作流控制指令、多智能體協作的通信標記、電腦操控類Agent的動作指令，都可能受到同樣的影響。這意味著這項研究揭示的可能是一類更廣泛的問題，值得整個AI應用開發領域予以重視。
---
說到底，這篇研究告訴我們一件事：AI系統不是各個零件的簡單相加。當你把"工具調用"和"格式化輸出"這兩塊零件拼在一起，可能會冒出一個單獨測試每塊零件時根本看不見的問題。更糟糕的是，這個問題還是隱性的——AI不會報錯，它依然會給你一份格式漂亮的回答，只是那份回答可能建立在一堆"憑空想像"的數據上，沒有人通知你出了問題。
研究團隊提出的雙階段執行方案是個實用的補丁，能在不改動模型的前提下繞開這個陷阱。但更根本的修復，可能需要推理框架開發者重新設計語法約束的實現方式，讓工具調用標記在格式約束下也能保持可達。
對於正在使用或計劃部署AI Agent系統的人來說，這項研究提出了一個值得認真思考的問題：你的系統測試流程，有沒有專門測試過"工具調用和格式輸出同時開啟"這種配置？如果沒有，那你可能對自己系統的真實可靠性存在誤判。
有興趣深入了解這項研究的讀者，可以通過arXiv編號2606.25605查閱完整論文，研究代碼和數據也將在GitHub上的Fzsama/Constrain-Tax-26-06倉庫中發布。
---
Q&A
Q1：工具抑制（Tool Suppression）會在所有AI模型里發生嗎？
A：根據這項研究，工具抑制在所有被測試的開源模型里都出現了，覆蓋了參數規模從200億到3970億的多種架構，本地部署和雲端部署都有。唯一沒有出現這個問題的是測試中的商業閉源模型GPT-5.4-mini。研究者推測這可能是因為商業模型採用了不同的結構化輸出實現機制，但由於無法查看內部代碼，這個推測尚未被證實。
Q2：透明雙階段執行方案有沒有明顯的缺點？
A：有，主要是兩個代價。第一是延遲增加，因為要跑兩次AI推理，時間大約多出一個完整推理輪次加上工具執行的時間。第二是Token消耗增加，第二階段需要把第一階段所有工具返回的內容都放進上下文裡，數據量更大。不過這個方案不需要改動任何模型權重或訓練流程，可以直接應用在現有系統上，在企業場景里任務能否成功通常比多花一點推理成本更重要。
Q3：為什麼專門針對工具使用的微調訓練也無法解決工具抑制問題？
A：因為工具抑制的根本原因發生在模型之外，具體來說是在推理框架的解碼層。格式約束會把工具調用所需的詞元（比如`
