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