2026年初，如果你去問任何一個做AI智能體訓練的團隊："你們現在最頭疼的事情是什麼？"得到的答案大概率不是"模型不夠聰明"，而是"題目不夠好"。
這話聽起來有點反常識。畢竟我們平時的印象是，AI能力的瓶頸在算法、在算力、在數據規模。但對於訓練能操作電腦終端的AI智能體來說，真正卡脖子的環節變成了：怎麼給它出一道"可靠"的練習題。
這篇論文叫FACET
，來自中國科學技術大學和上海AI實驗室的聯合團隊。它要解決的問題說起來很樸素：讓AI自己給自己出題、自己解題、自己判卷，這個閉環里到底會出什麼岔子，以及怎麼把這些岔子一個個堵上。
**核心問題：一道題的四個部分，只要有一個對不上，整道題就廢了**
先說清楚，訓練一個"終端智能體"到底需要什麼樣的練習題。
**終端智能體**：指能夠操作命令行界面完成任務的AI系統，比如幫你安裝軟體、整理文件、跑數據處理腳本，它需要像人類工程師一樣在電腦終端里敲命令、看反饋、解決報錯。
一道合格的終端任務，長得不像我們熟悉的選擇題或者填空題。它是一個"四件套"：一段任務說明（告訴AI要做什麼）、一個初始化好的運行環境（提前裝好的電腦系統，裡面有該有的文件和軟體）、一份參考答案（證明這道題真的能被解出來）、一套自動判分程序（用來檢查AI做得對不對）。
這四個部分必須嚴絲合縫地對上。任務說明里提到"處理銷售數據.csv"，環境裡就真的要有這個文件；參考答案里用了某個Python庫，環境裡就得裝好這個庫；判分程序檢查的狀態，必須是解題過程真能達到的狀態。
論文裡給出的一個數字很能說明問題：在沒有優化的對照流程里，AI生成了449個看起來完整的任務包，但真正能通過"環境能跑、答案能過關、判分程序認可"這套完整驗證的，只有139個，合格率27.8%。換句話說，超過七成的題目看著像那麼回事，實際一跑就崩。
這就好比你去買家具，說明書寫著"A零件插入B孔"，結果拆開箱子發現根本沒有B孔，或者B孔是給別的型號留的。說明書本身寫得挺像樣，可就是裝不起來。如果廠家從不實際組裝一遍就出貨，這種貨不對板的情況只會越來越多，最後消費者收到的不是家具，是一堆互相不兼容的木板。
論文識別出兩個具體的病根。第一個是"資訊在傳遞中丟失"：原始的技能素材里其實包含很多細節，比如某個操作依賴什麼工具、中間會產生什麼臨時文件、有什麼步驟上的限制，但是經過多輪AI生成加工，這些細節會被逐漸簡化掉，最後剩下的題目又淺又干。第二個是"各部分自說自話"：任務說明可能提到一個文件，但環境裡沒建這個文件；參考答案假設用某種數據格式，但判分程序按另一種格式檢查。就算把文字說明在各個生成步驟間傳遞，也沒法保證大家用的是同一個"真實世界"。
**FACET的解法：先想清楚故事，再動手布置場景，最後才寫考題**
面對這兩個問題，FACET沒有走"多生成幾遍然後挑好的"這條捷徑，而是重新設計了整個流程的順序。
它把整個任務生成拆成三個階段。
第一階段是**素材收集**。團隊從OpenClaw、ClawHub和GitHub上收集了超過7.1萬個公開的"智能體技能包"（可以理解成一個個打包好的操作教學，比如"如何用ffmpeg壓縮影片"、"如何用SQL清洗一批髒數據"）。這些技能會先經過安全過濾，剔除涉及隱私、需要訪問私有網站的內容，然後被結構化整理，記錄清楚每個技能需要什麼工具、輸入輸出是什麼。
接著系統會給每個技能設想可能的應用場景，把語義相近的場景聚在一起，湊出"技能組合"。比如"讀取Excel表格"和"生成可視化圖表"這兩個技能，很可能會被識別為經常一起出現的組合，因為現實中用戶往往是先處理數據再畫圖。
第二階段是這篇論文裡我覺得最有意思的設計，叫**場景重構**。
**場景重構**：不直接把技能組合翻譯成任務描述，而是先通過五個維度（目標、場景背景、能力關係、狀態變化、輸入輸出與工具）重新理解這組技能之間到底應該怎麼配合，恢復出一個完整連貫的用戶使用故事，再把這個故事轉成正式的任務文檔。
為什麼要多這一步？直接翻譯不好嗎？
論文給出的理由是，如果直接把技能組合轉成任務描述，生成出來的東西往往只用到每個技能最表面的功能，技能之間真正的依賴關係、生成過程中的中間狀態、需要遵守的約束條件，全都被壓扁抹平了。就像你請了兩位專業廚師來做一頓飯，一位擅長燉湯一位擅長烤肉，如果不給他們討論菜單的機會，直接各自隨便做一道菜端上桌，那頓飯大概率是兩道互不相干的菜，而不是一頓有主次搭配的完整晚餐。真正好的晚餐，得先有人想清楚"這頓飯想給客人什麼體驗"，然後再分派任務，燉湯要燉成什麼口味要跟烤肉的調味呼應，上菜順序怎麼安排。場景重構做的就是這個"想清楚整頓飯該怎麼做"的工作。
具體來說，場景重構分五步走：先分析每個技能有什麼能力和限制，再設想這些技能可能被用在什麼真實場景里，然後篩掉那些技能之間關聯性不強、只是硬湊在一起的組合，接著把留下的技能編排成一個有邏輯先後的工作流程，恢復出技能之間的依賴和中間產物，最後把這個流程用具體的文件格式、資源、約束條件填充豐滿。
這五步跑完，會產出一份"五維場景表示"，包括目標、背景、能力關係、狀態、輸入輸出與工具這五個方面的描述，最終整合成一段完整的自然語言場景說明。基於這份說明，系統先生成"解決方案參考"（記錄該怎麼一步步解決問題），再依據解決方案參考生成"指令參考"（記錄任務到底要求什麼）。這兩份參考文檔生成完，還有個專門的模型去檢查它們是不是在講同一件事：初始狀態一致不一致、指令里提的每個要求解決方案里有沒有對應、解決方案產生的每個效果最終狀態里能不能觀察到。
這個先講故事、再定文檔、後核對一致性的順序，本身就是在做"防止各說各話"這件事。
**第三階段是這篇論文的另一個核心創新，我把它稱為"先搭好房子再寫房產證"。**
具體來說，這個階段先根據前面整理出的場景說明，規劃出需要哪些文件、哪些服務、哪些依賴包，然後真的動手在一個容器里把這些東西全部造出來，包括必要時聯網抓取真實的公開資源，把它們本地化，甚至對收集到的數據做適當擴充和干擾（比如往一份結構化數據表里加一些額外記錄、干擾欄位），讓環境看起來不那麼像模板化的空殼。
環境搭建完之後，會先啟動這個環境，驗證它能不能正常跑起來。跑不起來就報錯回退給"環境修復"環節，最多允許修三次。修復的時候特意會帶上原始的場景說明，防止AI圖省事，直接把有難度的任務要求刪掉換取"能跑起來"的假成功，那樣雖然環境能跑但已經不是原來想要的那道題了。
環境真的搭好之後，系統才開始生成任務說明、解決方案代碼和判分程序，而且這三者都能讀取同一個已經跑起來的真實容器狀態。
**容器狀態共享**：環境搭建成功後，把這個真實運行的系統狀態（有哪些文件、什麼路徑、哪些服務在跑、依賴版本是什麼）當作一個共享的參考基準，讓指令、解決方案、判分程序這三個生成步驟都對照同一份真實資訊去寫，而不是各自憑空想像。
這一步的價值在哪裡？想像你在裝修房子，如果水電工、木工、油漆工完全不看現場實際情況，只是分別照著圖紙各干各的，最後大概率會出現油漆工的開關面板位置和水電工實際布線對不上的尷尬。真正可靠的做法是，水電走完線之後，把實際走線圖給後面的工種看，讓大家照著"真實發生的情況"而不是"最初的設想"去繼續幹活。FACET就是讓指令、答案、判分程序都對照這份"真實發生的容器狀態"去寫，誰也不會寫出一個環境裡根本不存在的文件。
生成完指令後，系統會拿指令和解決方案參考去生成具體的解決方案代碼，然後真的執行這份代碼，觀察執行完之後環境變成了什麼樣子。判分程序是最後生成的，它能同時看到指令、解決方案、執行前狀態和執行後狀態，這樣寫出來的判分邏輯更貼近"檢查行為和最終狀態"而不是死板地比對某一條具體命令，這樣即便AI用了另一種同樣正確的解法，也能通過驗證。
整個任務包最後要經過一套完整的驗證：環境能不能正常構建、判分程序在初始狀態下是不是正確地判定為"未完成"、參考解法能不能順利跑完、判分程序在解法跑完之後是不是正確判定為"已完成"。如果哪一步失敗了，系統會有一個專門的"路由器"去判斷問題出在哪個部件，是環境、解決方案還是判分程序，然後只修那一個部件，而不是推倒重來。最多允許修五輪，修不好就直接丟棄這道題。
這種"哪壞修哪"的策略聽起來簡單，但背後是個很實際的效率考量。如果每次驗證失敗都整體重新生成一遍任務，成本會指數級增長，而且很可能把已經正確的部分也改壞了。
**數據說話：題目變難了，但訓練效果反而更好**
理論說完了，實際效果怎麼樣？論文給出了一系列對比數據，我把關鍵幾組列出來。
首先是和其他現有終端智能體數據集的比較。
| 數據集 | 軌跡數 | 平均交互輪數 | 任務數 | 每任務測試點數 | P@1 | P@3 |
|---|---|---|---|---|---|---|
| Nemotron-Terminal | 5K | 6.12 | 15K | 6.18 | 40.67 | 48.00 |
| Endless-Terminals | 200 | 4.53 | 2,492 | 5.51 | 83.00 | 87.00 |
| Terminal-Lego | 32K | 5.77 | 15K | 16.60 | 47.00 | 49.00 |
| TerminalWorld | 200 | 11.94 | 1,530 | 3.98 | 57.00 | 82.00 |
| Tmax | 500 | 11.14 | 15K | 3.29 | 80.00 | 86.00 |
| **FACET（本文）** | 1.2K | **11.86** | 6K | **22.77** | 27.00 | 35.00 |
**P@1**：模型第一次嘗試就成功解出任務的概率。**P@3**：三次嘗試中至少成功一次的概率。
這張表最有意思的地方是，FACET在訓練軌跡數量上明顯偏少（1.2K，別人動輒幾千上萬），單個任務的測試點數量卻是所有數據集裡最多的，達到22.77個，是排名第二的Terminal-Lego（16.60）的將近1.4倍。與此同時，FACET數據集上的解題成功率（P@1隻有27%）是所有數據集裡最低的。
這不是bug，是feature。測試點數量多，意味著一道題里塞進了更多個獨立檢查項，AI必須把所有要求都滿足才能算通過，只完成主線任務但漏掉一兩個細節要求，照樣判失敗。這就好比一場考試，別的卷子只考三道大題答對方向就給分，FACET這份卷子拆成了二十多個小項逐一打鉤，漏一項就扣分，整體通過率自然會被拉低。
真正決定這份"難題"有沒有價值的，是拿它訓練出來的模型表現如何。
論文團隊用DeepSeek-V4-Pro跑了大約6千道FACET生成的驗證過任務，收集了1200條完整成功的解題軌跡，拿這些軌跡去微調三個不同規模的Qwen3.5模型，然後在權威的Terminal-Bench 2.1基準上測試效果。
| 模型 | 參數規模 | 微調前 | 微調後 | 提升幅度 |
|---|---|---|---|---|
| Qwen3.5-4B | 4B | 17.60 | 24.72 | +7.12 |
| Qwen3.5-9B | 9B | 27.34 | 35.58 | +8.24 |
| Qwen3.5-27B | 27B | 40.82 | **47.57** | +6.75 |
三個規模的模型都獲得了實打實的提升，9B模型的絕對漲幅最大，4B模型的相對漲幅最猛（40.5%的相對提升）。更值得說道的是，27B模型微調之後達到47.57分，只比參數量是它15倍的Qwen3.5-397B（在相同評測設置下拿到49.06分）低了1.49分。用1.2K條精心構造的訓練軌跡，追平了近乎大十幾倍的模型規模差距，這說明數據質量本身能在一定程度上替代模型規模。
**"幾乎做對了但沒完全對"，才是終端智能體最大的敵人**
論文還挖出了一個挺扎心的現象。研究團隊統計了那6千多個任務的解題過程，發現單個檢查項的通過率高達89.40%，但整體任務的完全成功率只有20.94%。
這意味著什麼？意味著AI在絕大多數細節上都做對了，但只要漏掉一兩個小要求，整道題依然記作失敗。進一步細分發現，在所有失敗的嘗試里，有54%只是差了一兩個檢查項沒通過。
這就好比你考駕照科目二，五個項目里前四個都精準無誤，最後一個倒車入庫壓了一點點線，整體結果依然是不及格。你可能覺得自己已經開得很不錯了，但規則不認這個賬。這種設計不是為了刁難，而是終端任務本身的真實性質決定的：現實世界裡讓電腦執行一個操作，只要有一處細節沒做對，整個流程就是失敗的，不存在"大部分對就算過"這回事。
論文特別強調，任務的難度並非來自單一步驟的複雜性，而是來自"要求的數量和相互關聯性"。指令越長，涉及的文件和約束條件越多，牽扯的中間依賴越複雜，一次性把所有要求都精準滿足的難度就呈非線性增長。這也解釋了為什麼處理結構化數據的任務通常比處理長篇文檔的任務更容易被AI做對，因為前者的檢查點相對獨立，後者往往環環相扣。
**先寫答案還是先寫判分標準？順序真的很重要**
論文裡做了一個特別紮實的對照實驗，專門驗證生成順序對任務質量的影響。他們用同樣的100組場景素材，分別測試了三種生成順序：正序（先生成指令，再生成解決方案，最後生成判分程序，這是FACET採用的方式）、逆序（先生成指令，再生成判分程序，最後才生成解決方案）、以及聯合生成（三樣東西一次性生成完）。
結果差異非常明顯。
正序方式的初始有效率是46.5%，逆序只有24.2%，聯合生成是37.5%。
為什麼先寫判分程序再寫解決方案會出問題？道理其實不複雜：判分程序是根據一份還不存在的解決方案憑空想像出來的檢查標準，就像老師在還沒批改學生作業之前，先按照自己腦補的"理想答案"定好評分細則，等真正的學生作業交上來，很可能和腦補的答案對不上號，甚至根本沒有標準答案里假設的那種解法。逆序生成失敗原因里，"跨部件契約不匹配"占到56.5%，正是這個道理在數據上的體現。
聯合生成則把契約不匹配的比例壓到了13.3%，但代價是"文件路徑和數據結構錯位"的比例飆升到38.3%。原因也不難理解，一次性生成三樣東西，模型很容易在細節上前後不一致，比如指令里提的文件名和解決方案代碼里用的文件名對不上。
論文還做了一個更嚴格的配對檢驗，只挑出88組同時通過三種流程驗證階段的場景，兩兩比較成敗情況。正序方案戰勝逆序方案的場景有29組，逆序反過來戰勝正序的只有9組，用統計檢驗算出來的p值是0.0017，這個數字小得足以說明這不是偶然。正序對聯合生成的勝負比是27比18，統計上沒有那麼顯著（p=0.233），說明這兩種方式的差距不算特別懸殊，但正序仍然在初始有效率和最終修復成功率上都占優。
**這套流程真的比現有方案強嗎？一場公平的正面對決**
論文最後還做了一個端到端的橫向對比，拿FACET和另外兩條流程在完全相同的500組技能對輸入上做比較：一條是沒有場景重構環節的簡化版基線流程，另一條是團隊復現的TerminalWorld風格構建流程（這是另一篇相關論文提出的方法）。
結果是這樣的：基線流程生成了437個看起來完整的任務包，真正通過驗證的只有78個，成功率15.6%；TerminalWorld風格流程生成了449個，驗證通過139個，成功率27.8%；FACET生成的完整包數量反而最少，只有395個，但通過驗證的多達350個，成功率高達70.0%。
這個數字對比很說明問題。FACET沒有在"生成數量"上取巧，反而是三者里生成包最少的，卻在"能真正跑通"這件事上遠遠甩開了另外兩條流程。350個通過驗證的任務里，有182個是第一次就通過驗證，另外168個是經過針對性修復才通過的，修復機制在這裡發揮了實打實的作用。
更值得注意的是，FACET產出的這些任務並不是靠"簡單"取巧換來的高通過率。用DeepSeek-V4-Pro實際去解這些任務，FACET版本的P@1隻有25.1%，是三者里最低的，平均需要的終端命令數量高達21.5條，也是三者里最多的。換句話說，FACET生成的任務不僅通過率高，難度也沒有被稀釋，依然是貨真價實的高質量、高複雜度任務。
寫在後面
讀到這篇論文的時候，最觸動我的其實不是那些提升幾個百分點的實驗數字，而是那個89.40%對20.94%的對比。一個AI系統能把接近九成的細節做對，最後卻因為剩下的一成而被判定"完全失敗"，這種落差揭示了一件我們平時容易忽略的事：智能體任務的評價標準和人類日常做事的評價標準是完全不同的兩套邏輯。人類做事講究"抓大放小"，容錯率高；機器執行任務講究的是"全對或全錯"，一步都不能鬆懈。這也許正是為什麼讓AI真正勝任嚴肅的自動化工作，比讓它寫一篇看起來還不錯的文章要難得多。
另一個讓我反覆琢磨的細節是那個生成順序實驗。先寫答案再寫判分標準，和先定判分標準再湊答案，看起來只是流程步驟顛倒了一下，結果卻是接近兩倍的成功率差距。這多少提醒我們，很多系統性問題的根源，可能不在算法本身夠不夠聰明，而在於最基礎的"先做什麼後做什麼"這種流程設計上。
論文裡還有一個沒有深入展開的問題，就是這套流程目前依賴的是公開的技能包和場景素材，如果換成某個高度專業化、素材極其稀缺的垂直領域，場景重構這一步還能不能重構出足夠豐富的故事？這大概是留給後續研究者的一道真正的考題。
Q&A
Q1：FACET是什麼？
A：FACET是中國科學技術大學和上海AI實驗室團隊提出的一套自動生成終端任務的框架，用來給AI智能體製造訓練用的練習題，核心解決的是任務說明、運行環境、參考答案、判分程序四部分互相對不上的問題。
Q2：FACET生成的任務和其他數據集比有什麼不同？
A：FACET生成的任務平均每個任務有22.77個獨立檢查點，遠高於同類數據集，雖然導致解題成功率看起來偏低（P@1隻有27%），但拿這些任務訓練出來的模型在Terminal-Bench 2.1基準上提升明顯，27B模型微調後從40.82分提升到47.57分。
Q3：為什麼先生成解決方案再生成判分程序比反過來更好？
A：論文實驗顯示，先寫判分程序再寫解決方案的方式初始有效率只有24.2%，而先寫解決方案再寫判分程序的正序方式有效率達到46.5%，因為判分程序如果脫離真實解法憑空設計，很容易和實際解法對不上號。
