1. 從會聊天的模型到能交付的智能體Agent Skills 到底在解決什么很多人第一次接觸 Agent 這個概念腦子里浮現(xiàn)的是一個能對話的機器人。但真正做過 Agent 項目的人都知道對話只是最表層的東西。一個能真正干活的 Agent核心難點從來不是它能不能理解你說的話而是它能不能在正確的時機、用正確的方式、調(diào)用正確的工具把一件事從頭到尾做完。這中間的差距就是 Skills 存在的意義。我先把結(jié)論擺在前面Agent Skills 本質(zhì)上是把技能從 Agent 的推理邏輯里剝離出來做成可獨立描述、可獨立加載、可獨立復(fù)用的能力單元讓 Agent 變成一個技能調(diào)度器而不是什么都得自己現(xiàn)學(xué)現(xiàn)賣的全能選手。這個思路聽起來簡單但它帶來的架構(gòu)變化是根本性的。為什么這么說你可以把沒有 Skills 的 Agent 想象成一個剛?cè)肼殹⑹裁炊嫉每颗R場發(fā)揮的員工。你問他幫我處理一下這張圖片他得自己琢磨用什么庫、走什么流程、輸出什么格式。每次遇到類似任務(wù)他都要重新推理一遍。而有了 Skills 之后相當(dāng)于給這個員工配了一本隨時可查的操作手冊庫每本手冊對應(yīng)一類任務(wù)的標(biāo)準(zhǔn)做法他只需要判斷這是哪類任務(wù)然后翻開對應(yīng)手冊照著執(zhí)行就行。這個轉(zhuǎn)變帶來的直接好處有三個。第一是穩(wěn)定性標(biāo)準(zhǔn)做法被固化下來不會因為模型每次推理的隨機性導(dǎo)致結(jié)果飄忽。第二是可維護性某個技能要升級只改那個技能文件不用動 Agent 的核心邏輯。第三是可組合性復(fù)雜任務(wù)可以拆成多個技能串聯(lián)像搭積木一樣拼出工作流。從熱詞里能看到大量相關(guān)信號——claude code 怎么手動裝 github 上的 skills、codex skills、opencode skills、常用 skills 源網(wǎng)站、skills 技能庫網(wǎng)址。這說明一個很現(xiàn)實的需求已經(jīng)出現(xiàn)了大家不再滿足于有個 Agent 能用而是想要有一套技能庫能裝、能換、能共享。這跟當(dāng)年前端從手寫 jQuery進化到npm 裝包是同一個邏輯——能力要被工程化、被標(biāo)準(zhǔn)化、被分發(fā)。所以這篇內(nèi)容我想聊的不是Agent 是什么這種入門問題而是Skills 架構(gòu)下的 Agent 到底該怎么理解、怎么設(shè)計、怎么落地。適合已經(jīng)動手寫過 Agent、或者正準(zhǔn)備把 Agent 從 Demo 推向生產(chǎn)的人看。如果你還在糾結(jié)要不要用 Agent那可能先補一下基礎(chǔ)會更順。2. Skills 與 Agent 的職責(zé)邊界誰負責(zé)思考誰負責(zé)執(zhí)行2.1 一個常見的架構(gòu)誤區(qū)把所有邏輯塞進 Prompt我見過太多 Agent 項目打開一看系統(tǒng)提示詞寫了三千字里面塞滿了當(dāng)用戶要求 A 時你要這樣做當(dāng)用戶要求 B 時你要那樣做。這種寫法在 Demo 階段能跑通但一旦技能數(shù)量超過十個就會徹底失控。原因很簡單Prompt 是線性的文本而技能是并行的能力集合用線性結(jié)構(gòu)去管理并行能力必然爆炸。正確的做法是把職責(zé)切開。Agent 的核心職責(zé)只有三件事理解用戶意圖、判斷需要哪些技能、編排技能的執(zhí)行順序。至于這個技能具體怎么實現(xiàn)完全交給 Skill 自己描述。這就是 Skills 架構(gòu)的第一性原則——關(guān)注點分離。打個比方Agent 像是一個項目經(jīng)理Skills 像是各個專業(yè)工種的作業(yè)指導(dǎo)書。項目經(jīng)理不需要會砌墻、會布線、會刷漆他只需要知道這個活需要瓦工、電工、油漆工然后按順序把人叫來。如果項目經(jīng)理非要把所有工種的細節(jié)都背在腦子里那他不是項目經(jīng)理他是個累死的全棧工人。2.2 Skill 描述文件應(yīng)該包含哪些字段一個能被 Agent 正確調(diào)度的 Skill它的描述文件至少要回答四個問題這個技能是干什么的description、什么時候該用它when to use、用的時候需要什么輸入inputs、會產(chǎn)出什么結(jié)果outputs。這四個字段缺一不可。我實測下來最容易出問題的是when to use這個字段。很多人只寫這個技能用于處理圖片太模糊了。Agent 面對幫我壓縮一下這張圖和幫我把這張圖轉(zhuǎn)成素描風(fēng)格兩個請求時如果技能描述不夠精確它可能兩個都匹配到同一個技能或者兩個都匹配不上。好的寫法應(yīng)該是把觸發(fā)條件寫具體比如當(dāng)用戶需要對圖片進行格式轉(zhuǎn)換、尺寸調(diào)整、質(zhì)量壓縮時使用把邊界劃清楚。下面是一個技能描述的結(jié)構(gòu)示例用 YAML 表達比較直觀name: image-resize description: 對圖片進行尺寸調(diào)整和格式轉(zhuǎn)換 when_to_use: | 當(dāng)用戶提出以下需求時使用 - 修改圖片的寬高尺寸 - 轉(zhuǎn)換圖片格式如 png 轉(zhuǎn) jpg - 按比例縮放圖片 不適用于風(fēng)格遷移、濾鏡處理、內(nèi)容識別 inputs: - image_path: 源圖片路徑 - target_width: 目標(biāo)寬度可選 - target_height: 目標(biāo)高度可選 - format: 目標(biāo)格式可選 outputs: - output_path: 處理后的圖片路徑注意when_to_use里我特意寫了不適用于的部分。這一點非常關(guān)鍵明確排除項比明確包含項更能提升調(diào)度準(zhǔn)確率。因為 Agent 在匹配時模糊地帶才是誤判的高發(fā)區(qū)。2.3 為什么技能粒度決定了整個架構(gòu)的上限技能拆得太粗一個技能干十件事那 Agent 調(diào)度時就沒法靈活組合等于沒拆。技能拆得太細一個技能只干一件微不足道的小事那 Agent 光調(diào)度開銷就壓垮了而且技能之間的依賴關(guān)系會變得極其復(fù)雜。我的經(jīng)驗是一個 Skill 應(yīng)該對應(yīng)一個完整的、有明確交付物的動作。比如讀取 Excel 并解析成結(jié)構(gòu)化數(shù)據(jù)是一個合理的粒度打開文件和讀取第一行就太細了處理所有辦公文檔又太粗。判斷標(biāo)準(zhǔn)很簡單如果這個技能產(chǎn)出的東西是下一個技能可以直接消費的那粒度就對了。從熱詞里harness 和 agent 區(qū)別、harness 架構(gòu)langchainlanggraph智能體開發(fā)案例這些搜索能看出很多人正在糾結(jié)框架層面的選型。但我想說的是框架只是承載 Skills 的容器真正決定 Agent 好不好用的是技能怎么切分、怎么描述、怎么編排?？蚣苓x錯了可以換技能設(shè)計爛了換什么框架都救不回來。3. 技能加載與調(diào)度機制Agent 怎么知道自己會什么3.1 技能注冊的兩種模式全量加載與按需檢索Agent 要調(diào)用技能首先得知道有哪些技能可用。這里有兩種主流模式各有適用場景。全量加載是把所有技能的描述一次性塞進上下文讓模型在推理時自己選。這種模式實現(xiàn)簡單適合技能數(shù)量少比如 20 個以內(nèi)的場景。但它的致命問題是上下文占用——每個技能描述按 200 字算50 個技能就是一萬字還沒開始干活上下文就被吃掉一大塊而且模型在長列表里的選擇準(zhǔn)確率會明顯下降。按需檢索是先做一個技能索引用戶請求進來后先用檢索關(guān)鍵詞匹配或向量相似度篩出最相關(guān)的幾個技能再把這幾個技能的詳細描述喂給模型。這種模式擴展性好技能上百上千都不怕但多了一層檢索就多了一層誤召回的風(fēng)險。我實際項目里的做法是混合模式把技能按領(lǐng)域分組先做粗粒度的領(lǐng)域路由再在領(lǐng)域內(nèi)做細粒度的技能匹配。比如用戶說幫我處理一下這個表格先路由到數(shù)據(jù)處理領(lǐng)域再在這個領(lǐng)域里匹配到Excel 解析或CSV 清洗等具體技能。這樣既控制了上下文長度又保證了匹配精度。3.2 技能匹配失敗時的兜底策略再好的匹配機制也會有失手的時候。用戶的需求千奇百怪總有技能庫覆蓋不到的情況。這時候 Agent 該怎么辦直接說我不會是最差的體驗。我的做法是設(shè)置三級兜底。第一級是近似技能推薦匹配不到精確技能時返回最接近的幾個讓用戶確認是不是想要這個。第二級是通用能力降級如果確實沒有對應(yīng)技能但任務(wù)本身在模型的基礎(chǔ)能力范圍內(nèi)比如簡單的文本總結(jié)就直接用模型原生能力處理不強行套技能。第三級是技能缺口記錄把匹配失敗的請求記下來作為后續(xù)補充技能庫的依據(jù)。這個兜底鏈路看起來是小事但它直接決定了 Agent 是越用越好用還是永遠就那幾招。技能庫的迭代靠的就是這些失敗案例的積累。3.3 多技能編排串行、并行與條件分支單個技能調(diào)用只是起點真實任務(wù)往往是多個技能的組合。這里就涉及到編排邏輯。串行編排是最常見的技能 A 的輸出作為技能 B 的輸入一條鏈走到底。比如下載圖片 → 壓縮圖片 → 上傳到指定位置。并行編排適合互不依賴的子任務(wù)比如同時處理多個文件能顯著縮短總耗時。條件分支則是根據(jù)中間結(jié)果決定下一步走哪條路比如如果圖片是豎版就按豎版規(guī)則處理否則按橫版規(guī)則處理。編排邏輯寫在哪里我的建議是寫在 Agent 的調(diào)度層而不是寫在某個技能內(nèi)部。技能應(yīng)該保持單一職責(zé)編排是調(diào)度層的事。這樣技能才能被不同流程復(fù)用否則每個技能里都嵌一套流程判斷復(fù)用性就沒了。從熱詞agent execution terminated due to error能看出執(zhí)行中斷是大家常遇到的問題。編排層必須處理異常某個技能失敗了是重試、跳過、還是終止整個流程這個策略要在編排時就定義清楚不能等出錯了再臨時想。我一般會給每個技能調(diào)用設(shè)置重試次數(shù)上限和超時時間超過就按預(yù)設(shè)策略走避免整個流程卡死。4. 從零搭一個 Skills 架構(gòu) Agent 的實操路徑4.1 環(huán)境與依賴準(zhǔn)備中最容易忽略的細節(jié)動手之前先把基礎(chǔ)環(huán)境理清楚。這里我不綁定具體框架講通用的準(zhǔn)備邏輯。首先是運行環(huán)境。Agent 要調(diào)用技能技能可能要執(zhí)行代碼、訪問文件、發(fā)起網(wǎng)絡(luò)請求所以運行環(huán)境需要有相應(yīng)的權(quán)限和依賴。我踩過的一個坑是本地開發(fā)時一切正常部署到服務(wù)器后技能全部失敗排查半天發(fā)現(xiàn)是服務(wù)器上沒有裝某個技能依賴的系統(tǒng)庫。技能依賴要顯式聲明不能靠本地碰巧有。其次是技能目錄結(jié)構(gòu)。建議按領(lǐng)域分目錄每個技能一個文件夾里面放描述文件和實現(xiàn)代碼。這樣加載時按目錄掃描新增技能就是新增文件夾非常清晰。下面是一個我常用的目錄結(jié)構(gòu)skills/ >