1. 從“技能”這個(gè)詞說起為什么我們需要重新理解Agent的能力邊界“agent-skills”這個(gè)標(biāo)題看起來簡(jiǎn)單但它背后指向的是一個(gè)正在快速演化的技術(shù)方向——如何讓智能體Agent具備可復(fù)用、可組合、可擴(kuò)展的技能體系。如果你最近在關(guān)注AI應(yīng)用開發(fā)大概率已經(jīng)注意到一個(gè)趨勢(shì)大家不再滿足于讓模型“回答問題”而是希望它能“做事”。而“做事”的核心就是技能。我最初接觸這個(gè)概念時(shí)也走過彎路。當(dāng)時(shí)我以為所謂的Agent技能無非就是給模型掛幾個(gè)API、寫幾段提示詞讓它能查天氣、能算數(shù)學(xué)題。但真正動(dòng)手做項(xiàng)目之后才發(fā)現(xiàn)事情遠(yuǎn)沒有這么簡(jiǎn)單。一個(gè)真正可用的Agent技能體系需要解決三個(gè)層面的問題技能如何定義、技能如何調(diào)度、技能如何組合。這三個(gè)問題不解決你的Agent就永遠(yuǎn)停留在“玩具”階段。這篇文章適合誰看如果你是正在做AI應(yīng)用開發(fā)的工程師或者是對(duì)Agent架構(gòu)感興趣的產(chǎn)品經(jīng)理又或者是想把自己的業(yè)務(wù)能力封裝成Agent技能的技術(shù)負(fù)責(zé)人那接下來的內(nèi)容應(yīng)該能幫你少走不少彎路。我會(huì)從技能的定義方式講起一直聊到多技能協(xié)同的實(shí)戰(zhàn)細(xì)節(jié)中間會(huì)穿插我自己踩過的坑和總結(jié)出來的經(jīng)驗(yàn)。先給一個(gè)最直觀的理解Agent技能就像給一個(gè)剛?cè)肼毜膶?shí)習(xí)生配了一套工具箱。工具箱里有什么、怎么用、什么時(shí)候用哪個(gè)這些都需要你提前設(shè)計(jì)好。而“agent-skills”這個(gè)項(xiàng)目標(biāo)題本質(zhì)上就是在探討這套工具箱的設(shè)計(jì)方法論。2. 技能的定義方式從硬編碼到聲明式描述2.1 為什么硬編碼技能是條死路我最早做Agent技能的時(shí)候采用的是最直接的方式——在代碼里寫死。比如用戶問天氣我就寫一個(gè)get_weather函數(shù)然后在提示詞里告訴模型“你可以調(diào)用get_weather”。這種方式在技能數(shù)量少于5個(gè)的時(shí)候還能湊合一旦超過10個(gè)問題就來了。首先是提示詞會(huì)變得極其臃腫。每個(gè)技能都需要描述、需要參數(shù)說明、需要調(diào)用示例這些內(nèi)容全部塞進(jìn)系統(tǒng)提示詞里很快就會(huì)撐爆上下文窗口。其次是維護(hù)成本極高每加一個(gè)技能就要改一次提示詞改完還要重新測(cè)試所有已有技能是否還能正常工作。最要命的是模型在技能數(shù)量多了之后選擇準(zhǔn)確率會(huì)明顯下降——它經(jīng)常在該用A技能的時(shí)候選了B技能。后來我意識(shí)到硬編碼的本質(zhì)問題是把“技能的定義”和“技能的調(diào)度”混在了一起。技能的定義應(yīng)該是獨(dú)立的、自包含的而調(diào)度應(yīng)該是動(dòng)態(tài)的、按需加載的。這個(gè)認(rèn)知轉(zhuǎn)變是我做Agent技能體系的一個(gè)關(guān)鍵轉(zhuǎn)折點(diǎn)。2.2 聲明式技能描述的結(jié)構(gòu)設(shè)計(jì)轉(zhuǎn)向聲明式之后每個(gè)技能都變成一個(gè)獨(dú)立的結(jié)構(gòu)化描述。我目前用的格式大致是這樣的{ name: search_knowledge_base, description: 在內(nèi)部知識(shí)庫中搜索相關(guān)文檔適用于需要查詢產(chǎn)品文檔、技術(shù)規(guī)范、歷史工單的場(chǎng)景, parameters: { query: { type: string, description: 搜索關(guān)鍵詞建議使用具體的名詞短語而非完整句子, required: true }, max_results: { type: integer, description: 返回結(jié)果數(shù)量上限默認(rèn)5最大20, required: false, default: 5 } }, returns: { type: array, description: 匹配的文檔列表每項(xiàng)包含標(biāo)題、摘要、相關(guān)度評(píng)分 } }這個(gè)結(jié)構(gòu)看起來簡(jiǎn)單但每個(gè)字段都有講究。description不能只寫“搜索知識(shí)庫”而要寫清楚“什么時(shí)候該用這個(gè)技能”。這一點(diǎn)非常關(guān)鍵——模型選擇技能的依據(jù)很大程度上就是看這個(gè)描述是否匹配當(dāng)前任務(wù)場(chǎng)景。我試過把描述寫得很簡(jiǎn)短結(jié)果模型經(jīng)常在不需要搜索的時(shí)候也去調(diào)搜索技能浪費(fèi)了大量token。parameters里的description同樣重要。特別是query參數(shù)我明確寫了“建議使用具體的名詞短語而非完整句子”這是因?yàn)閷?shí)測(cè)發(fā)現(xiàn)模型如果直接把用戶的原話塞進(jìn)去搜索效果往往不好。加上這句提示之后模型會(huì)主動(dòng)做一次查詢改寫把“我想知道那個(gè)關(guān)于數(shù)據(jù)同步的問題怎么解決”改成“數(shù)據(jù)同步 問題 解決方案”召回率明顯提升。2.3 技能描述的粒度控制另一個(gè)容易踩坑的地方是技能粒度。我一開始把技能拆得很細(xì)比如“讀取文件”“寫入文件”“列出目錄”各算一個(gè)技能。結(jié)果模型在執(zhí)行一個(gè)簡(jiǎn)單任務(wù)時(shí)需要連續(xù)調(diào)用五六個(gè)技能中間任何一步出錯(cuò)都會(huì)導(dǎo)致整個(gè)任務(wù)失敗。后來我調(diào)整了策略按“用戶意圖”而不是“底層操作”來劃分技能。比如把文件操作合并成一個(gè)manage_files技能通過action參數(shù)來區(qū)分具體操作。這樣模型只需要調(diào)用一次內(nèi)部邏輯由技能自己處理。當(dāng)然粒度也不能太粗否則參數(shù)會(huì)變得極其復(fù)雜模型很難正確填充。我的經(jīng)驗(yàn)法則是如果一個(gè)技能需要超過5個(gè)參數(shù)或者描述超過200字就說明粒度太粗了應(yīng)該考慮拆分。反過來如果兩個(gè)技能在80%的場(chǎng)景下都是一起被調(diào)用的那它們就應(yīng)該合并。3. 技能調(diào)度的核心機(jī)制讓模型學(xué)會(huì)“什么時(shí)候用什么”3.1 基于語義匹配的技能召回技能定義好了之后下一個(gè)問題就是當(dāng)用戶提出一個(gè)請(qǐng)求時(shí)如何從幾十甚至上百個(gè)技能中快速找到最相關(guān)的幾個(gè)最樸素的做法是把所有技能描述都塞進(jìn)提示詞讓模型自己選。但前面說過技能多了之后這樣做效果很差。我目前采用的方案是兩階段召回。第一階段用向量相似度做粗篩把用戶請(qǐng)求和所有技能的描述分別向量化取相似度最高的前10個(gè)技能。第二階段再把這10個(gè)技能的完整描述放進(jìn)提示詞讓模型做最終選擇。這樣既控制了提示詞長度又保證了選擇準(zhǔn)確率。這里有個(gè)細(xì)節(jié)值得注意向量化的時(shí)候不要只用技能名稱而要用“技能名稱描述典型使用場(chǎng)景”拼接后的文本。我試過只用名稱召回效果很差加上描述之后召回率提升了將近40%。另外如果技能數(shù)量超過200個(gè)可以考慮先用關(guān)鍵詞做一次硬過濾再做向量召回速度會(huì)快很多。3.2 多技能協(xié)同的編排邏輯單個(gè)技能調(diào)用相對(duì)簡(jiǎn)單真正復(fù)雜的是多個(gè)技能協(xié)同完成一個(gè)任務(wù)。比如用戶說“幫我查一下上個(gè)月的銷售數(shù)據(jù)然后生成一份報(bào)告發(fā)給團(tuán)隊(duì)”這至少涉及三個(gè)技能查數(shù)據(jù)、生成報(bào)告、發(fā)送郵件。我一開始的做法是讓模型自己決定調(diào)用順序結(jié)果經(jīng)常出現(xiàn)順序錯(cuò)亂——比如還沒查到數(shù)據(jù)就開始生成報(bào)告。后來我引入了一個(gè)簡(jiǎn)單的編排層把常見任務(wù)模式抽象成“技能鏈”。每個(gè)技能鏈定義了技能的調(diào)用順序和數(shù)據(jù)傳遞方式。模型只需要識(shí)別出當(dāng)前任務(wù)屬于哪個(gè)技能鏈然后按預(yù)定義的流程執(zhí)行。當(dāng)然技能鏈不能覆蓋所有情況。對(duì)于技能鏈覆蓋不到的任務(wù)我還是讓模型自由編排但加了一個(gè)約束每個(gè)技能的輸出必須經(jīng)過一個(gè)校驗(yàn)步驟確認(rèn)數(shù)據(jù)格式正確后才能傳給下一個(gè)技能。這個(gè)校驗(yàn)步驟看起來多余但實(shí)際上避免了很多“垃圾進(jìn)垃圾出”的問題。3.3 技能執(zhí)行失敗的降級(jí)策略技能調(diào)用失敗是常態(tài)不是異常。網(wǎng)絡(luò)超時(shí)、參數(shù)錯(cuò)誤、權(quán)限不足、返回結(jié)果為空這些情況我都遇到過。如果每次失敗都直接報(bào)錯(cuò)給用戶體驗(yàn)會(huì)非常差。我的做法是為每個(gè)技能定義一個(gè)降級(jí)策略。比如搜索技能失敗時(shí)降級(jí)為“告知用戶搜索暫時(shí)不可用建議稍后重試”數(shù)據(jù)查詢技能失敗時(shí)降級(jí)為“返回緩存中的最近一次數(shù)據(jù)并標(biāo)注數(shù)據(jù)可能不是最新”。降級(jí)策略寫在技能定義里由調(diào)度層統(tǒng)一處理。還有一個(gè)技巧對(duì)于關(guān)鍵技能我會(huì)配置重試機(jī)制。但不是簡(jiǎn)單重試而是帶參數(shù)調(diào)整的重試。比如第一次搜索用原始查詢?cè)~如果返回結(jié)果為空第二次自動(dòng)放寬搜索條件第三次嘗試同義詞替換。這樣能把很多“假失敗”救回來。4. 技能組合的實(shí)戰(zhàn)場(chǎng)景從單點(diǎn)能力到完整工作流4.1 信息檢索類技能的串聯(lián)模式信息檢索是最常見的Agent應(yīng)用場(chǎng)景也是最能體現(xiàn)技能組合價(jià)值的場(chǎng)景。一個(gè)完整的檢索流程通常包含查詢理解、多源檢索、結(jié)果融合、摘要生成四個(gè)環(huán)節(jié)。查詢理解環(huán)節(jié)我會(huì)用一個(gè)專門的技能來做意圖識(shí)別和查詢改寫。這個(gè)技能接收用戶原始問題輸出結(jié)構(gòu)化的查詢意圖和改寫后的查詢?cè)~。多源檢索環(huán)節(jié)根據(jù)查詢意圖并行調(diào)用多個(gè)檢索技能——比如同時(shí)查內(nèi)部知識(shí)庫、查工單系統(tǒng)、查產(chǎn)品文檔。結(jié)果融合環(huán)節(jié)把多個(gè)來源的結(jié)果去重、排序、合并。摘要生成環(huán)節(jié)基于融合后的結(jié)果生成自然語言回答。這套流程聽起來順理成章但實(shí)操中有個(gè)關(guān)鍵點(diǎn)并行檢索的結(jié)果返回時(shí)間不一致。有的源快有的源慢。如果等所有源都返回再融合整體延遲會(huì)很高。我的做法是設(shè)置一個(gè)超時(shí)窗口比如2秒超過2秒還沒返回的源就先用已有結(jié)果后續(xù)如果返回了再補(bǔ)充。這樣在延遲和完整性之間取一個(gè)平衡。4.2 數(shù)據(jù)處理類技能的錯(cuò)誤傳播控制數(shù)據(jù)處理類任務(wù)對(duì)錯(cuò)誤特別敏感。一個(gè)環(huán)節(jié)算錯(cuò)了后面全錯(cuò)。我在做數(shù)據(jù)清洗和轉(zhuǎn)換的Agent時(shí)踩過一個(gè)典型的坑某個(gè)技能返回了空值但下游技能沒有做空值檢查直接把空值當(dāng)0處理最后生成了完全錯(cuò)誤的報(bào)表。從那以后我在技能定義里強(qiáng)制要求每個(gè)技能聲明它的輸出約束。比如“返回字段X必須為非空字符串”“返回?cái)?shù)組長度必須在1到100之間”。調(diào)度層在把數(shù)據(jù)傳給下一個(gè)技能之前會(huì)先校驗(yàn)這些約束。不滿足約束就觸發(fā)降級(jí)或報(bào)錯(cuò)而不是讓錯(cuò)誤數(shù)據(jù)繼續(xù)往下流。另外對(duì)于數(shù)據(jù)處理鏈路我會(huì)在關(guān)鍵節(jié)點(diǎn)保存中間結(jié)果。這樣如果最后一步出錯(cuò)不需要從頭重跑可以從最近的檢查點(diǎn)恢復(fù)。這個(gè)做法在調(diào)試階段特別有用能快速定位到底是哪個(gè)環(huán)節(jié)出了問題。4.3 人機(jī)協(xié)作類技能的交互設(shè)計(jì)有些技能不是全自動(dòng)的需要人工介入。比如“發(fā)送郵件”這個(gè)技能在正式發(fā)送前應(yīng)該讓用戶確認(rèn)收件人和內(nèi)容。這類技能的設(shè)計(jì)要點(diǎn)是在自動(dòng)流程中插入確認(rèn)節(jié)點(diǎn)但確認(rèn)節(jié)點(diǎn)不能太頻繁否則用戶會(huì)覺得煩。我的做法是把確認(rèn)節(jié)點(diǎn)放在“不可逆操作”之前。查詢、計(jì)算、生成草稿這些可逆操作不需要確認(rèn)直接執(zhí)行。發(fā)送、刪除、修改這些不可逆操作才需要確認(rèn)。而且確認(rèn)信息要足夠具體不能只問“是否繼續(xù)”而要展示“即將發(fā)送給張三、李四主題是XXX內(nèi)容摘要如下”。還有一個(gè)細(xì)節(jié)確認(rèn)超時(shí)怎么處理。如果用戶一直不確認(rèn)任務(wù)不能永遠(yuǎn)掛在那里。我會(huì)設(shè)置一個(gè)合理的超時(shí)時(shí)間比如5分鐘超時(shí)后自動(dòng)取消任務(wù)并通知用戶。如果用戶后續(xù)想繼續(xù)可以從任務(wù)列表里重新發(fā)起。5. 技能體系的維護(hù)與演進(jìn)上線只是開始5.1 技能使用數(shù)據(jù)的采集與分析技能上線之后如果不采集使用數(shù)據(jù)你根本不知道哪些技能在被用、哪些技能有問題。我一開始只記錄了調(diào)用次數(shù)后來發(fā)現(xiàn)這遠(yuǎn)遠(yuǎn)不夠?，F(xiàn)在我會(huì)記錄每個(gè)調(diào)用的完整鏈路用戶原始請(qǐng)求、召回的候選技能、最終選擇的技能、傳入?yún)?shù)、返回結(jié)果、執(zhí)行耗時(shí)、是否成功。這些數(shù)據(jù)能回答很多關(guān)鍵問題。比如某個(gè)技能調(diào)用成功率突然下降可能是上游數(shù)據(jù)源出了問題。某個(gè)技能經(jīng)常被召回但很少被選中說明它的描述可能不夠準(zhǔn)確。某個(gè)技能的平均執(zhí)行時(shí)間越來越長可能需要優(yōu)化內(nèi)部實(shí)現(xiàn)。分析的時(shí)候我特別關(guān)注兩個(gè)指標(biāo)技能選擇準(zhǔn)確率和端到端任務(wù)完成率。前者衡量模型是否選對(duì)了技能后者衡量整個(gè)任務(wù)是否成功完成。這兩個(gè)指標(biāo)結(jié)合起來看能快速定位問題是出在調(diào)度層還是執(zhí)行層。5.2 技能版本的灰度發(fā)布策略技能更新不能一次性全量發(fā)布風(fēng)險(xiǎn)太大。我采用的是灰度發(fā)布策略新版本技能先只對(duì)10%的流量生效觀察一段時(shí)間沒問題再逐步擴(kuò)大比例。灰度發(fā)布的關(guān)鍵是做好版本隔離。每個(gè)技能調(diào)用請(qǐng)求都要帶上版本標(biāo)識(shí)確保同一個(gè)任務(wù)鏈路里的所有技能調(diào)用都使用同一版本。否則如果A技能用了新版本、B技能用了舊版本可能會(huì)出現(xiàn)兼容性問題?；貪L機(jī)制也要提前準(zhǔn)備好。一旦發(fā)現(xiàn)新版本有問題要能在一分鐘內(nèi)切回舊版本。我一般會(huì)保留最近三個(gè)版本的技能定義確保隨時(shí)可以回滾。5.3 技能廢棄與遷移的處理技能也會(huì)“死亡”。有些技能隨著業(yè)務(wù)變化不再需要了有些技能被更好的實(shí)現(xiàn)替代了。廢棄技能不能直接刪掉因?yàn)榭赡苓€有歷史任務(wù)在引用它。我的做法是先把技能標(biāo)記為“已廢棄”在描述里注明替代技能是什么。調(diào)度層看到已廢棄的技能時(shí)會(huì)自動(dòng)重定向到替代技能。這樣運(yùn)行一段時(shí)間后確認(rèn)沒有任務(wù)再引用舊技能了才真正刪除。遷移的時(shí)候要注意參數(shù)兼容性。如果新舊技能的參數(shù)結(jié)構(gòu)不同需要在重定向?qū)幼鰠?shù)轉(zhuǎn)換。這個(gè)轉(zhuǎn)換邏輯最好寫在配置里而不是代碼里方便隨時(shí)調(diào)整。6. 我踩過的那些坑技能體系構(gòu)建中的真實(shí)教訓(xùn)6.1 技能描述過于抽象導(dǎo)致的調(diào)度混亂早期我寫技能描述的時(shí)候喜歡用比較抽象的語言。比如“處理用戶請(qǐng)求”“管理數(shù)據(jù)”這種。結(jié)果模型完全不知道該什么時(shí)候用這些技能經(jīng)常在不該調(diào)用的時(shí)候調(diào)用。后來我強(qiáng)制自己遵守一個(gè)規(guī)則技能描述里必須包含至少一個(gè)具體的名詞和一個(gè)具體的動(dòng)詞。比如“在內(nèi)部知識(shí)庫中搜索相關(guān)文檔”就比“處理搜索請(qǐng)求”好得多。另外描述里要明確寫出“不適用場(chǎng)景”。比如搜索技能要注明“不適用于實(shí)時(shí)數(shù)據(jù)查詢”這樣能避免模型在需要實(shí)時(shí)數(shù)據(jù)時(shí)錯(cuò)誤地選擇搜索技能。6.2 參數(shù)校驗(yàn)缺失引發(fā)的連鎖故障前面提到過空值問題這里再展開說一下。參數(shù)校驗(yàn)缺失導(dǎo)致的故障往往不是單個(gè)技能的問題而是整個(gè)鏈路的雪崩。我遇到過一次某個(gè)技能返回了格式錯(cuò)誤的日期字符串下游技能解析失敗再下游技能因?yàn)槟貌坏饺掌诰陀昧四J(rèn)值最后生成了一份日期完全錯(cuò)誤的報(bào)表。修復(fù)方案是在每個(gè)技能的入口和出口都加校驗(yàn)。入口校驗(yàn)參數(shù)是否符合定義出口校驗(yàn)返回值是否符合聲明。校驗(yàn)不通過就立即中斷當(dāng)前鏈路返回明確的錯(cuò)誤信息。雖然這樣會(huì)增加一些開發(fā)工作量但比起線上出故障的代價(jià)這點(diǎn)投入完全值得。6.3 技能粒度過細(xì)帶來的性能問題前面提過粒度控制這里補(bǔ)充一個(gè)性能角度的考量。技能調(diào)用是有開銷的——每次調(diào)用都需要一次模型推理用于選擇技能和填充參數(shù)再加上技能本身的執(zhí)行時(shí)間。如果粒度太細(xì)一個(gè)任務(wù)需要調(diào)用十幾次技能總耗時(shí)可能達(dá)到幾十秒用戶體驗(yàn)很差。我的優(yōu)化經(jīng)驗(yàn)是對(duì)于高頻出現(xiàn)的技能組合考慮合并成一個(gè)復(fù)合技能。比如“搜索摘要”經(jīng)常一起出現(xiàn)就合并成一個(gè)search_and_summarize技能。這樣模型只需要調(diào)用一次內(nèi)部串行執(zhí)行兩個(gè)步驟省去了一次模型推理的開銷。6.4 忽視技能執(zhí)行環(huán)境的差異性最后一個(gè)坑比較隱蔽技能執(zhí)行環(huán)境的差異性。我在開發(fā)環(huán)境測(cè)試技能時(shí)一切正常上線后卻頻繁失敗。排查后發(fā)現(xiàn)是生產(chǎn)環(huán)境的網(wǎng)絡(luò)策略更嚴(yán)格某些外部API調(diào)用被限制了。從那以后我在技能定義里增加了一個(gè)environment_requirements字段聲明技能運(yùn)行所需的環(huán)境條件。比如“需要訪問外部網(wǎng)絡(luò)”“需要讀取本地文件系統(tǒng)”“需要特定權(quán)限”。部署的時(shí)候會(huì)根據(jù)這些聲明做環(huán)境檢查不滿足條件的技能會(huì)被標(biāo)記為不可用而不是等到調(diào)用時(shí)才報(bào)錯(cuò)。7. 寫給正在構(gòu)建Agent技能體系的你如果你正在著手構(gòu)建自己的Agent技能體系我的建議是從小處著手但把架構(gòu)想清楚。先實(shí)現(xiàn)三五個(gè)核心技能把定義、調(diào)度、執(zhí)行的完整鏈路跑通。這個(gè)過程中你會(huì)遇到各種預(yù)料之外的問題但正是這些問題能幫你把架構(gòu)打磨得更健壯。技能描述的質(zhì)量直接決定了整個(gè)體系的上限。花時(shí)間打磨每個(gè)技能的描述確保它清晰、具體、無歧義。這件事的投入產(chǎn)出比極高值得反復(fù)迭代。不要追求一步到位。技能體系是演化出來的不是設(shè)計(jì)出來的。先上線采集數(shù)據(jù)根據(jù)實(shí)際使用情況持續(xù)調(diào)整。我現(xiàn)在的技能體系和最初版本相比幾乎每個(gè)技能都經(jīng)過了至少三輪重構(gòu)。最后分享一個(gè)我最近在用的技巧定期做“技能審計(jì)”。把所有技能列出來逐個(gè)問三個(gè)問題——這個(gè)技能最近30天被調(diào)用了多少次調(diào)用成功率是多少如果刪掉它哪些任務(wù)會(huì)受影響回答完這三個(gè)問題你就知道哪些技能該優(yōu)化、哪些該合并、哪些該廢棄了。這個(gè)習(xí)慣幫我保持了技能體系的精簡(jiǎn)和高效。