Agent 的技術瓶頸出現了？2026年，Skills 才更重要！

如果從技術演進的角度復盤最近一年的 Agent 項目，一個越來越清晰的事實是：

問題正在從“模型夠不夠強”，轉向“系統如何承載判斷”。

Claude、GPT 這類模型在生成能力上已經高度成熟，至少在大多數工程場景中，“能不能生成”早已不是主要限制。

真正開始拖慢系統演化速度的，是我們把大量本該被工程化、被結構化的判斷，持續交給模型在運行時即興完成。

這個問題在系統早期往往不明顯。Agent 的第一個原型通常表現良好，一個 prompt，加上一點工具調用，就能跑通完整流程。

但隨著場景增多、上下文變復雜、需求開始疊加歷史約束，系統會逐漸進入一種工程上非常危險的狀態：

行為開始變得不可預測，但你卻很難準確定位問題發生在哪一層。

模型參數沒有變，數據來源也沒有明顯變化，業務邏輯看起來仍然成立，但結果卻開始呈現出“有時對，有時不對”的不穩定特征。

關鍵并不在于模型是否足夠穩定，而在于系統結構是否在回避一個更基礎的問題：

哪些判斷應該被固化為系統能力，哪些判斷才值得在每一次調用中重新推理。

當所有判斷都被交給模型即時完成，系統規模越大，不確定性就會被放大得越快。

從這個角度再回頭看 Claude Skills，會發現它并沒有試圖解決“更強智能”的問題，而是在解決一個更底層、更工程化的難題：

如何把已經被反復驗證過的能力，從不透明的 prompt 行為中拆解出來，變成可管理、可復用、可回收的系統組件。

Skill 的價值，并不在于能力本身，而在于它讓經驗第一次具備了長期資產的形態。

這也是為什么當系統里的 Skills 從十幾個增長到幾十個、上百個時，能力管理本身會迅速成為瓶頸。

最近看到的特贊科技 atypica.AI 發了一個( http://skill0.io/)，正是圍繞這一問題給出的一個具體實踐：

當能力規模擴大，如何讓不同團隊知道哪些能力已經被驗證、哪些仍處在試驗階段，以及如何避免在系統內部反復造輪子。

如果缺少這樣一層能力承載機制，所謂的 Agent 架構，最終很容易退化回 prompt 的堆疊。

在這一過程中，Agent 的角色也在悄然發生變化。

與其讓 Agent 承擔越來越多“會做什么”的職責，不如讓它回到一個更克制的位置：理解上下文、做路徑選擇、判斷是否調用某種能力。

執行的確定性盡可能被 Skills 吸收，不確定性才留給推理層處理。到這個階段，系統關注的重點自然會從“輸出是否漂亮”，轉向“判斷是否正確”。

從行業整體來看，這并不是某一家團隊的獨立選擇，而是一種越來越普遍的工程收斂方向。

當 Agent 真正進入復雜系統、長期運行環境之后，判斷如何被工程化、被治理，正在取代模型能力本身，成為新的技術分水嶺。