本文來自微信公眾號： 碳基智 ，作者：碳基智
之前也寫過關(guān)于skill本質(zhì)的文章，其實它就相當于一個給Agent用的system prompt，告訴模型“你是誰、該怎么做、什么不能做”這些事情，從Harness的角度看，邊界圍欄設立得清清楚楚，理論上Agent的輸出效果會更好。
理論上……
但當我把自己的各類工作流抽象成skill以后，卻發(fā)現(xiàn)：除了那些有著我鮮明個人特色需求的skill，不加載skill純模型輸出的效果也沒想象中差。雖然從skill benchmark測試的結(jié)果看，skill輸出的平均分往往要高于純模型輸出，但這背后的原因可能跟大家想的都不太一樣。
1
大部分人迭代skill的流程通常是這樣的：
先寫完初版，上線試跑??發(fā)現(xiàn)問題，添加新約束??繼續(xù)迭代，各種禁止詞出現(xiàn)??最終skill行數(shù)從開始的400行，膨脹到近2000行。
但輸出效果還是不夠穩(wěn)定。
越強調(diào)，文檔越長；文檔越長，注意力越分散；注意力越分散，違反越多；違反越多，再追加一遍。一個完美的惡性循環(huán)。
這里的技術(shù)原理，說白了其實就是模型的注意力機制問題。Stanford的經(jīng)典論文《Lost in the Middle》里提到：
大模型對輸入序列的注意力分布不是均勻的，開頭和末尾的內(nèi)容獲得最多關(guān)注，中間區(qū)域容易被遺忘，呈U形曲線。
數(shù)據(jù)上看，開頭指令的遵循率能達到73%，末尾會略低一些，到了中間區(qū)域遵循率就會驟降30%–50%。原因也很簡單，Transformer的位置編碼機制決定了，兩個token距離越遠，注意力越弱。
2
我最近正好讀到了一篇新的論文《The Regression Tax:Decomposing Why Skills Help and Hurt LLM Agents》，它用相對還算嚴謹?shù)膶嶒灲o了我一些解答。我發(fā)現(xiàn)，傳統(tǒng)的skill benchmark評測里面有一個大家都忽略了的地方。傳統(tǒng)評測把一套skill加到Agent上，重新跑benchmark，然后比較平均成功率。比如無Skill通過100道題中的60道，加Skill后通過65道，結(jié)論通常寫成提升5個百分點。
但那65道正確答題可能來自兩條完全不同的路徑：
新做對5道，原來會做的題一題沒錯；
新做對20道，同時弄錯15道舊題。
兩套系統(tǒng)的平均分都從60漲到65，可靠性卻不在一個檔次。第一套Skill擴大了能力邊界，第二套Skill對能力做了大規(guī)模換血。作為用戶，你很難分清楚，你的skill究竟是第一套還是第二套。
作者選了486個辦公自動化任務，把每個配對任務分成四類：
| 無Skill | 有Skill | 分類 | 人話解釋 |
|---|---|---|---|
| 失敗 | 成功 | Gain | Skill新救回來的題 |
| 成功 | 失敗 | Regression | Skill弄壞的舊能力 |
| 成功 | 成功 | Retained | 原能力被保住 |
| 失敗 | 失敗 | Residual failure | Skill也沒補上的短板 |
凈提升的公式：
通過率變化=（Gains?Regressions）÷任務總數(shù)
通過這樣設置的對照實驗，來看skill是否起到了應有作用。
486個辦公自動化任務，其中94個來自OfficeQA-Pro，要求Agent閱讀美國財政文件、表格與長PDF；392個來自SpreadsheetBench，要求Agent修改真實Excel工作簿。
每個任務放進三套model–harness組合：
OpenCode×MiniMax-M2.7
Codex×GPT-5.4-mini
Claude Code×Claude Sonnet 4.6
每套組合再跑四種條件：不裝Skill，以及Anthropic、OpenAI、作者自建的三套Skill庫。486×3×4得到5,832次task-condition runs。
3
論文核心數(shù)據(jù)如下：
553次gain，對應324次regression。新增失敗抵消了毛收益的59%，最后留下229次凈增成功。Skill幫你新救回10道題的同時，大約又弄壞了原本會做的6道。
18個Skill條件全部出現(xiàn)regression，范圍為2到41次。論文里沒有一套Skill庫做到“只加能力、不傷舊能力”。
OfficeQA-Pro的81次回歸中，59次屬于grounding displacement（輸入錨定偏移），占72.8%。多數(shù)時候算法沒算錯，Agent讀錯了表、年份、定義或?qū)ο蟆?/p>
SpreadsheetBench的243次回歸中，70次被歸為osmosis，占28.8%。這些任務沒有調(diào)用Skill正文，常駐description已經(jīng)改變了行為。
接下來是一些印證我真實體驗的結(jié)論。
Skill沒調(diào)用也可能產(chǎn)生影響。
一個典型Skill可以拆成兩層。description負責告訴Agent這項能力解決什么問題、什么時候應該觸發(fā)；body放著詳細步驟、腳本與參考資料。許多Agent框架采用漸進加載，body只在命中任務后讀取，description卻會常駐系統(tǒng)上下文，方便模型做路由。
問題就出在這張常駐目錄上。
大模型生成答案時，會綜合當前上下文中的詞匯、指令與示例。description即使沒有給出完整流程，也可能給模糊任務提供一個解釋方向。論文把這種presence-only influence稱為skill-description osmosis。osmosis原意是滲透，作者想表達的意思很直白：Skill正文雖然沒打開，描述里的概念已經(jīng)滲進了Agent的判斷。
Grounding displacement（輸入錨定偏移）
Grounding在大模型語境里常被譯成“語義落地”“事實錨定”或“輸入對齊”。它解決的問題是：用戶說的這句話，究竟對應現(xiàn)實世界里的哪個對象、哪份數(shù)據(jù)和哪一種口徑。
比如用戶說“計算1934年和1946年公共工程支出的差額”，Agent需要完成幾次錨定：找到正確文件、進入正確表格、確認兩個年份、選中修訂后的統(tǒng)計口徑、識別單位。前面這些動作都屬于grounding。
Grounding在這篇論文里指Agent能不能把任務落到正確輸入上，說人話就是能不能讀懂題，而不是像我們文科生一樣即使不會做都能寫個800字出來。
對應到用戶體感上，你會發(fā)現(xiàn)Agent加了SOP后回答變得更完整、更“像”行家，但有時候卻連問題本身都理解歪了。它進入了“按照手冊完成任務”的模式，對用戶輸入中的具體限定反而不夠敏感。
Verification displacement（驗證環(huán)節(jié)被擠占）
Verification指的是模型交付前的結(jié)果檢查。它需要拿最終產(chǎn)物重新對照用戶要求，或者讓真實工具執(zhí)行比如：絕對值有沒有保留正號，Excel公式能否重算，代碼測試是否通過，文件格式是否符合交付標準。
Skill提供一套完整procedure后，Agent可能把“流程走完”當成“任務完成”，原本會做的結(jié)果檢查被削弱。
作者把663個含公式的失敗任務交給完整表格引擎重算，226個公式原本就是正確的，占34%。原評分器不會算部分函數(shù)，正確答案被判成錯誤。它提醒我們兩件事：Agent需要可執(zhí)行驗證，評測Agent的系統(tǒng)也得先證明自己有檢驗能力。
4
最后，我們可以看到，Agent的能力管理正在重復軟件工程走過的路。
這篇論文提醒大家的是，新增依賴一定要跑回歸測試，不然你就會交回歸稅。Skill進入生產(chǎn)環(huán)境也需要回歸預算、灰度和可撤銷機制，一整個萬變不離控制論了。
那么，工程上的解法大概有這幾種：
分層架構(gòu)：將Skill視為有層次結(jié)構(gòu)的文檔，位置決定優(yōu)先級。
消除隱性沖突，規(guī)則要做到無歧義，讓優(yōu)先級顯式化。
劃重點：用正向指令替代否定指令，多項研究表明，模型對"不要做X"的遵循率顯著低于"只做Y"。
結(jié)構(gòu)化格式，降低模型的理解成本，推薦每個人都去學習下怎么用markdown寫文檔和表格。
試一下吧，朋友們！