別再做一堆沒用的工具函數(shù)了Agent技能體系應(yīng)該這樣設(shè)計。聊一聊我最近在梳理的 agent-skills 這個事直接說幾個核心觀點Agent的能力上限其實不取決于模型本身有多聰明而取決于你給它配了什么樣的技能。一套設(shè)計良好的技能體系能讓一個普通模型做出驚艷的效果反之技能定義得一塌糊涂再強的模型也會表現(xiàn)得像個只會說廢話的呆子。我在實際項目中踩過不少坑一開始也是把各種工具函數(shù)堆在一起結(jié)果Agent經(jīng)常調(diào)用錯函數(shù)、參數(shù)傳錯、上下文混亂后來重新整理了技能體系效果提升非常明顯。這篇文章就把我在設(shè)計和落地 agent-skills 技能體系時的完整思路、操作方法、踩坑記錄都分享出來希望能給正在做Agent開發(fā)的你一些參考。1. 整體設(shè)計思路拆解為什么Agent需要一套“技能體系”1.1 從“工具函數(shù)”到“技能體系”的思維轉(zhuǎn)變很多人做Agent應(yīng)用時第一反應(yīng)是給模型準(zhǔn)備一堆函數(shù)。比如要做一個文檔助手就寫個read_file、write_file、search_keyword、summarize_text……然后一股腦塞給模型。這種做法在Demo階段沒問題但一旦場景稍微復(fù)雜問題就全冒出來了。我做過一個模擬項目X是個企業(yè)內(nèi)部的知識庫問答助手。最早版本掛了30多個工具函數(shù)模型經(jīng)常選錯工具有時候明明該調(diào)用搜索它偏偏去讀文件有時候兩個函數(shù)功能重疊模型不知道該選哪個。調(diào)試過程極其痛苦后來我才意識到問題不在模型而在“工具”這個概念太底層了。工具是機械的、單一的而技能應(yīng)該是場景化的、體系化的。技能 工具 場景 約束條件 輸入輸出規(guī)范。它不是一個孤立的函數(shù)而是一整套可以被模型理解、調(diào)用、協(xié)作的完整能力單元。打個比方工具像是廚房里的一把刀、一個鍋、一塊砧板而技能則是一道菜的完整做法什么時候用刀、什么時候開火、什么時候下料這些決策本身已經(jīng)內(nèi)置在技能里。你給廚師的不是一堆散亂的廚具而是一本寫清楚“怎么做出一道菜”的菜譜這樣廚師才能穩(wěn)定復(fù)現(xiàn)好吃的結(jié)果。1.2 技能體系設(shè)計的三條核心原則在重構(gòu) agent-skills 時我給自己定了三條原則第一技能即接口。每個技能必須有清晰、唯一、無歧義的接口定義包括技能名稱、功能描述、參數(shù)Schema、返回值規(guī)范。模型通過接口理解技能接口定義的質(zhì)量直接決定模型能否正確調(diào)用。第二技能可組合。單一技能解決單一問題復(fù)雜場景通過多個技能的組合來完成。就像積木一樣小技能可以搭出大能力。比如“生成周報”這個技能可以組合“獲取本周工作記錄”、“分析完成度”、“生成報告”三個子技能。第三技能可觀測。每個技能的執(zhí)行過程、調(diào)用參數(shù)、返回結(jié)果、耗時、錯誤信息都應(yīng)有日志記錄這樣才能在模型調(diào)用出錯時快速定位問題。我見過太多團隊在Agent出錯時根本不知道是模型選錯了技能還是技能本身邏輯有bug就是因為沒有可觀測性設(shè)計。1.3 技能體系的分層架構(gòu)在設(shè)計 agent-skills 時我把技能體系分成四層底層是原子技能對應(yīng)單一、不可再拆分的操作比如“讀取文件”、“執(zhí)行SQL查詢”、“調(diào)用外部API”第二層是場景技能在原子技能基礎(chǔ)上封裝特定業(yè)務(wù)場景比如“查找相似文檔”、“提取合同關(guān)鍵條款”第三層是編排技能負(fù)責(zé)組合調(diào)度多個場景技能比如“生成項目總結(jié)報告”會依次調(diào)用“獲取項目數(shù)據(jù)”、“分析進度風(fēng)險”、“生成報告文本”頂層是策略層定義Agent在什么業(yè)務(wù)場景下優(yōu)先采用哪種技能組合以及技能執(zhí)行失敗后的降級策略。這個分層的價值在于底層技能穩(wěn)定通用可以在不同項目中復(fù)用場景技能貼近業(yè)務(wù)是團隊積累的核心資產(chǎn)編排技能和策略層則讓Agent具備了處理復(fù)雜任務(wù)的能力。我目前維護的 agent-skills 項目就是用這個架構(gòu)實踐證明比平鋪一堆工具函數(shù)要清晰得多。2. 核心模塊拆解技能注冊、技能描述、參數(shù)Schema與調(diào)度引擎2.1 技能注冊中心一切技能的統(tǒng)一入口技能注冊中心是整個體系的“戶口本”所有技能上線前都要在這里登記。每個技能注冊時至少包含以下字段字段說明是否必填skill_id技能唯一標(biāo)識必填name技能名稱需簡短且無歧義必填description功能描述說明技能用途及適用條件必填parameters_schema參數(shù)JSON Schema必填returns_schema返回值JSON Schema必填tags技能標(biāo)簽用于檢索分類選填version技能版本號必填enabled是否啟用必填這里有個細節(jié)值得注意name 和 description 是給大模型看的而不是給人看的。很多開發(fā)者習(xí)慣用英文命名函數(shù)或使用過于簡短的描述結(jié)果模型理解不到位。我見過一個項目把“查詢用戶訂單”寫成qry_ord模型經(jīng)常把它當(dāng)作訂單狀態(tài)查詢之外的用途后來改成query_user_orders并配了詳細的描述誤用率立刻降了一半。我建議在注冊階段就建立一套規(guī)范description的寫法可以套用固定模板“當(dāng)用戶需要[場景描述]時使用此技能。[輸入說明][輸出說明][特殊注意事項]。”比如當(dāng)用戶需要查詢訂單物流信息時使用此技能。 輸入訂單編號order_id必填、手機號phone用于校驗身份選填。 輸出物流軌跡列表包含時間、地點、狀態(tài)描述。 注意訂單編號不存在時返回錯誤碼404不要嘗試自行推斷。這種結(jié)構(gòu)化的描述模型命中率會明顯高于“查詢物流”這種籠統(tǒng)的寫法。2.2 技能描述的質(zhì)量直接決定模型調(diào)用的準(zhǔn)確率我在實際調(diào)試中發(fā)現(xiàn)一個規(guī)律模型選技能靠的是語義匹配描述寫得越精準(zhǔn)匹配的準(zhǔn)確率越高。這里分享幾個實測有效的技巧第一描述中要包含觸發(fā)場景的關(guān)鍵詞。比如“當(dāng)用戶詢問天氣/氣溫/降雨概率時”就比“天氣查詢功能”更能讓模型找到對應(yīng)技能。第二描述中要寫清楚邊界條件。比如“本技能只能查詢已發(fā)貨的訂單未發(fā)貨訂單請調(diào)用order_create技能”這樣能有效減少模型判斷模糊的情況。第三描述中要區(qū)分主用途和附帶能力。很多技能其實能做多件事但模型理解核心用途就夠了。我通常把主用途放在前面附帶能力如果跟其他技能有交叉就干脆不提避免給模型造成干擾。舉個例子同樣是文件處理技能這樣寫就不合格處理文件。而這樣寫效果就好很多當(dāng)用戶需要對本地文本文件進行讀取、寫入或內(nèi)容追加時使用此技能。支持.txt和.md格式輸入為文件路徑和操作類型輸出為操作結(jié)果或文件內(nèi)容。注意不支持二進制文件和圖片文件。第二種寫法明確說了“什么時候用”、“支持什么”、“不支持什么”模型幾乎不會用錯。2.3 參數(shù)Schema用規(guī)范化定義給模型“填空”參數(shù)Schema是技能體系中最容易被忽視、但出錯率最高的部分。模型在調(diào)用技能時本質(zhì)上是根據(jù)用戶的自然語言輸入生成一個符合Schema的參數(shù)JSON。Schema定義得越清晰模型“填空”的準(zhǔn)確率就越高。我有幾個常用的Schema設(shè)計經(jīng)驗參數(shù)名要直觀不要用縮寫。比如user_phone就不要寫成u_ph模型很容易對縮寫產(chǎn)生誤解。每個參數(shù)都要寫description說明參數(shù)的含義、格式、取值范圍。模型不是人它不會自己“猜”參數(shù)是什么意思。必填參數(shù)和選填參數(shù)要嚴(yán)格區(qū)分。如果有一個參數(shù)大部分情況下存在默認(rèn)值就盡量設(shè)為選填降低模型填錯的概率。對于枚舉類型的參數(shù)把所有可選項和對應(yīng)含義都寫清楚。這里給一個實際的參數(shù)Schema示例是某個Agent項目里的“發(fā)送定時消息”技能{ type: object, properties: { recipient: { type: string, description: 接收消息的聯(lián)系人名稱必須是用戶通訊錄中已存在的聯(lián)系人, minLength: 1 }, content: { type: string, description: 消息正文內(nèi)容支持純文本和鏈接長度不超過2000字, maxLength: 2000 }, send_time: { type: string, description: 消息發(fā)送時間格式為YYYY-MM-DD HH:mm:ss不填則立即發(fā)送, format: datetime }, priority: { type: string, enum: [high, normal, low], description: 消息優(yōu)先級high為立即通過強提醒發(fā)送normal為普通通知low為合并到摘要中發(fā)送, default: normal } }, required: [recipient, content] }注意priority這個字段如果你只寫“優(yōu)先級”三個字模型可能填一個“緊急”進去Schema校驗直接報錯。但你把每個枚舉值的含義和效果寫清楚模型就知道該填high而不是“緊急”了。2.4 技能調(diào)度引擎讓Agent知道“先做什么、后做什么”單體技能容易做難的是讓Agent在復(fù)雜場景中按正確的順序調(diào)度多個技能。我的做法是給每個技能增加兩個元信息字段prerequisites前置技能條件和conflicts沖突技能。比如“生成項目周報”技能prerequisites里可以聲明“需要先調(diào)用get_project_data獲取項目數(shù)據(jù)”。當(dāng)模型決定使用該技能時調(diào)度引擎會自動檢查前置技能是否已經(jīng)執(zhí)行如果未執(zhí)行會先觸發(fā)前置技能的調(diào)用而不是等模型在對話中自行決策。conflicts字段用來聲明哪些技能不能同時使用。比如“修改文件”和“發(fā)送文件”在同一輪任務(wù)中同時出現(xiàn)可能會引發(fā)文件內(nèi)容不一致的問題。聲明沖突后調(diào)度引擎會提示模型做出選擇或先征求用戶確認(rèn)。這兩個機制幫我解決了一個老大難問題多步任務(wù)中的順序控制。在沒有這套機制之前模型經(jīng)?！跋氲侥淖龅侥摹庇辛嗣鞔_的前置依賴聲明Agent的執(zhí)行順序明顯穩(wěn)定了。3. 實操過程從零構(gòu)建一個技能體系并接入Agent3.1 第一步梳理業(yè)務(wù)場景劃定技能邊界我在構(gòu)建 agent-skills 時第一步不是寫代碼而是花了兩天時間梳理業(yè)務(wù)的全部使用場景。這個模擬項目是一個面向某公司內(nèi)部的智能客服需要支持問題解答、工單創(chuàng)建、知識庫檢索、人工客服轉(zhuǎn)接等能力。梳理場景時我會把用戶在對話中可能提出的各種請求列出來然后逐條歸類哪些請求可以直接由一個原子技能滿足哪些需要編排組合哪些其實不適合當(dāng)前Agent處理比如涉及隱私或權(quán)限的操作。這個過程中自然就劃定了技能的邊界。這里有個重要的實操心得技能的粒度不是越細越好也不是越粗越好而是要匹配模型的理解能力和業(yè)務(wù)的需要。粒度過細模型需要在一次任務(wù)中調(diào)用十幾個技能容易亂粒度過粗技能本身變成一個小業(yè)務(wù)系統(tǒng)復(fù)用性又很差。我的經(jīng)驗是讓每個技能的輸入輸出盡量控制在3-5個參數(shù)以內(nèi)這樣模型最容易理解和生成。3.2 第二步定義技能清單與優(yōu)先級場景梳理完之后我整理了一份技能清單并給每個技能標(biāo)注了優(yōu)先級。這一步看似簡單其實很關(guān)鍵優(yōu)先級決定了Agent在能力重疊時首選哪個技能。比如我的項目里有兩個技能都和“用戶訂單”相關(guān)“查詢訂單信息”和“修改訂單信息”。雖然它們參數(shù)類似但在實際客服場景中70%以上的請求都是查詢所以我給查詢技能的優(yōu)先級設(shè)為P0修改設(shè)為P1。調(diào)度引擎在處理模糊請求時如果模型無法確定用戶意圖是修改會默認(rèn)按查詢來處理避免誤操作。我當(dāng)時整理的技能清單大致長這樣技能名稱優(yōu)先級類型說明retrieve_knowledgeP0原子技能基于關(guān)鍵詞檢索知識庫answer_common_questionP0場景技能回答高頻常見問題create_ticketP0場景技能創(chuàng)建工單并通知對應(yīng)人員query_order_statusP0場景技能查詢訂單狀態(tài)modify_orderP1場景技能修改訂單信息需用戶身份驗證transfer_humanP0編排技能轉(zhuǎn)接人工客服并附上對話摘要3.3 第三步實現(xiàn)技能的注冊與核心代碼注冊中心的實現(xiàn)其實不復(fù)雜用Python FastAPI可以很快搭起來。核心邏輯就是一個字典存儲技能定義再加一些API用于注冊、查詢、更新技能元信息。# 技能注冊中心核心代碼簡化版 class SkillRegistry: def __init__(self): self._skills {} def register(self, skill_meta: dict, handler: callable): skill_id skill_meta[skill_id] if skill_id in self._skills: raise ValueError(f技能 {skill_id} 已存在) self._skills[skill_id] { meta: skill_meta, handler: handler } def get_handler(self, skill_id: str): return self._skills.get(skill_id, {}).get(handler) def list_skills(self): return [ {skill_id: s[meta][skill_id], name: s[meta][name], description: s[meta][description]} for s in self._skills.values() ]技能實現(xiàn)本身就是一個普通函數(shù)接收參數(shù)JSON執(zhí)行后返回JSON。我建議所有技能函數(shù)保持統(tǒng)一的簽名def retrieve_knowledge(params: dict, context: dict) - dict: 根據(jù)關(guān)鍵詞在知識庫中檢索相關(guān)信息。 keyword params.get(keyword, ) top_k params.get(top_k, 5) results knowledge_base.search(keyword, top_ktop_k) return {results: results, total: len(results)}這里的context參數(shù)用于傳遞對話上下文、用戶身份信息、權(quán)限標(biāo)識等。技能函數(shù)不需要自己管理全局狀態(tài)統(tǒng)一通過context讀寫避免多個技能之間產(chǎn)生隱式依賴。3.4 第四步設(shè)計系統(tǒng)提示詞教會模型使用技能有了一套技能還得讓模型知道怎么用。很多人以為把技能列表塞進system prompt就行其實遠遠不夠。我踩過這個坑直接塞列表的結(jié)果是模型經(jīng)常自由發(fā)揮編造不存在的技能名。我的方案是在system prompt中明確告訴模型三件事第一有哪些技能可用每個技能一句最簡描述 第二調(diào)用規(guī)則必須嚴(yán)格遵循skill_id參數(shù)必須符合Schema定義 第三能力邊界當(dāng)技能無法滿足用戶請求時不要編造結(jié)果明確告知用戶。實際使用的提示詞模板我簡化一下你是某公司智能客服助手你可以調(diào)用以下技能 - retrieve_knowledge知識庫檢索適用于具體問題查詢 - create_ticket創(chuàng)建工單適用于需要后續(xù)跟進處理的情況 - query_order_status訂單狀態(tài)查詢適用于用戶詢問訂單進度 - transfer_human轉(zhuǎn)人工適用于用戶明確要求人工或本助手無法解決時 調(diào)用規(guī)則 1. 每次調(diào)用前先評估用戶意圖是否匹配技能描述匹配才調(diào)用 2. 參數(shù)必須按技能定義的JSON Schema填寫缺失的必填參數(shù)要向用戶詢問 3. 技能調(diào)用結(jié)果如果無法滿足用戶需求要如實說明不得編造信息 4. 一次對話中如需多步操作按依賴順序依次調(diào)用這段提示詞的寫法其實借鑒了“規(guī)則引擎”的思想明確、簡潔、無歧義。我在多次測試中發(fā)現(xiàn)模型對這類指令式的說明遵從度相當(dāng)高比“你可以自由調(diào)用以下工具”這種寬松表述效果好得多。3.5 第五步技能測試與調(diào)優(yōu)閉環(huán)技能接入后不能直接上線需要先跑一輪系統(tǒng)的測試。我自己常用的測試方法是準(zhǔn)備一批“用戶問題樣例集”覆蓋每個技能的典型場景、邊界場景和干擾場景然后自動運行Agent記錄每次技能調(diào)用的正確性。測試時重點關(guān)注三個指標(biāo)命中率用戶問題對應(yīng)的正確技能被調(diào)用的比例參數(shù)準(zhǔn)確率調(diào)用技能時參數(shù)填寫的正確比例失敗恢復(fù)率技能執(zhí)行失敗后Agent能否走降級路徑或明確告知用戶。調(diào)優(yōu)時優(yōu)先處理命中率低的問題。如果正確技能沒被調(diào)用先檢查技能描述是否足夠清晰再檢查描述中的關(guān)鍵詞跟用戶問題中的表達方式是否匹配。有一個案例我印象很深用戶的表達是“我的訂單什么時候到”技能描述里寫的是“查詢物流軌跡”模型一開始匹配不到后來我把描述改成“當(dāng)用戶詢問訂單何時送達/物流進展/快遞到哪了時使用”命中率一下子就上去了。這就是為什么我說技能描述是一等公民它的質(zhì)量直接決定Agent的可用性而不是可有可無的注釋。4. 常見問題與排查技巧實錄4.1 技能調(diào)用失敗模型選擇技能時“差之毫厘謬以千里”這是最常遇到的問題?，F(xiàn)象是用戶明明問的是A場景模型卻調(diào)用了B技能或者直接不調(diào)用技能自己編答案。我排查這類問題的思路是先看模型在對話中的思考過程如果模型平臺支持輸出推理過程確認(rèn)模型是理解錯了技能描述還是理解對了但選擇了錯誤的skill_id還是根本沒意識到需要調(diào)用技能。針對不同的原因?qū)?yīng)的解決辦法也不同問題原因特征解決方式技能描述與用戶表達脫節(jié)正確技能未被調(diào)用模型選了語義相近的其他技能重寫技能描述融入更多目標(biāo)的表達說法技能描述過于寬泛多個技能的觸發(fā)條件重疊模型無法區(qū)分明確邊界條件在描述中寫死“不做”的場景技能沒有出現(xiàn)在提示詞中模型“不知道有這個技能”檢查注冊狀態(tài)和提示詞中的技能列表確保包含參數(shù)Schema不清晰技能調(diào)用成功但參數(shù)必定填錯重寫參數(shù)description補充枚舉值和格式示例還有一個高頻場景模型調(diào)用技能后因為參數(shù)校驗失敗報錯然后它開始自己“修正”參數(shù)重試結(jié)果越改越錯。我建議在實現(xiàn)技能時對參數(shù)校驗做兩級設(shè)計第一級是Schema硬校驗參數(shù)類型不對或缺少必填字段直接報錯第二級是業(yè)務(wù)軟校驗比如查詢某個不存在的訂單ID返回明確錯誤碼。這樣模型收到錯誤碼后能根據(jù)提示信息進行下一步而不是盲目重試。4.2 上下文污染技能A的結(jié)果變成技能B的錯誤輸入這是做多技能編排時很容易踩的坑。在測試模擬項目X時我遇到過一個問題Agent先調(diào)用了知識檢索技能獲取了一堆文檔片段接著要調(diào)用工單創(chuàng)建技能結(jié)果工單的內(nèi)容字段里被填入了文檔片段整個工單正文完全不可讀。排查后發(fā)現(xiàn)問題出在上下文管理我把所有技能的返回結(jié)果都原封不動地丟回了對話歷史模型在看到“當(dāng)前有哪些信息可用”時誤把文檔片段當(dāng)作了工單內(nèi)容。解決辦法是在技能返回值中增加metadata字段標(biāo)記數(shù)據(jù)類型和使用范圍{ data: {content: 工單正文內(nèi)容}, metadata: { type: ticket_content, source: user_input, usage: for_create_ticket } }同時在提示詞里明確告訴模型“不同技能的返回信息歸屬于不同用途如果下一任務(wù)需要的信息來源不明優(yōu)先基于用戶原話生成而不是使用其他技能的輸出?！边@套規(guī)范加上之后上下文污染的問題明顯減少。4.3 性能瓶頸技能數(shù)量大了之后上下文越塞越多、調(diào)用越來越慢技能數(shù)量從十幾個增長到幾十個后你會發(fā)現(xiàn)一個問題技能描述和規(guī)則占用的上下文越來越多留給對話和業(yè)務(wù)內(nèi)容的空間越來越少。而且模型在幾十個技能里做決策耗時和出錯率也會上升。我的對策是分級“技能提示”常用的核心技能放主提示詞低頻長尾技能從注冊中心動態(tài)加載由模型在需要時主動查詢技能列表再決定調(diào)用。具體來說我實現(xiàn)了一個search_skills技能當(dāng)主提示詞中的技能列表無法匹配用戶意圖時模型可以調(diào)用這個技能基于關(guān)鍵詞在注冊中心檢索對應(yīng)技能。這個設(shè)計有個附帶好處長尾技能不會被遺忘。如果你的所有技能都一股腦放在主提示詞里模型可能只記得前面的幾個后面的幾乎不會被使用。而動態(tài)檢索模式天然保證了技能被“按需喚起”。4.4 安全問題權(quán)限校驗必須在技能層嚴(yán)格把關(guān)技能體系還有一個常被忽略的點安全。Agent可以調(diào)度技能就意味著你開放了一個“可執(zhí)行操作的入口”。如果沒有權(quán)限校驗可能會出現(xiàn)越權(quán)操作比如普通用戶通過Agent修改了管理員才有的配置。我的經(jīng)驗是三條鐵律技能注冊時必須聲明所需權(quán)限等級技能執(zhí)行前由調(diào)度引擎統(tǒng)一做權(quán)限校驗而不是在技能函數(shù)內(nèi)部自行校驗高風(fēng)險技能如刪除、修改、對外發(fā)送消息必須在執(zhí)行前讓用戶二次確認(rèn)。這里的第三點尤其重要。實際運營中很多用戶習(xí)慣性地說“幫我處理一下”如果Agent真的自動執(zhí)行了刪除操作出了問題很難挽回。我見過一個項目因為Agent自動發(fā)送了一封內(nèi)容不完整的郵件導(dǎo)致客戶投訴。后來他們給“發(fā)送郵件”技能加上了二次確認(rèn)機制風(fēng)險就完全可控了。提示二次確認(rèn)不是讓Agent問“你確定嗎”這樣簡單的重復(fù)而是要把即將執(zhí)行的操作內(nèi)容重新概括給用戶確認(rèn)比如“我將向某地址發(fā)送內(nèi)容為X的消息是否執(zhí)行”這種形式模型執(zhí)行起來更可靠用戶也更容易感知風(fēng)險。5. 進階方向從“能用”到“好用”的幾條經(jīng)驗5.1 讓技能具備自描述能力讓模型自己“發(fā)現(xiàn)自己需要什么”傳統(tǒng)的技能調(diào)用是模型從固定列表里選擇但這樣受限嚴(yán)重。更進一步的思路是把技能本身當(dāng)成可檢索的知識庫讓模型先“查找該用什么技能”再“調(diào)用該技能”。我在實際項目中測試過這個模式效果很理想。做法是給注冊中心增加一個文本索引技能描述和標(biāo)簽被向量化存儲。模型在遇到用戶問題后先在索引中做相似度檢索返回最相關(guān)的3-5個技能候選并附帶每個技能的詳細描述。這樣既節(jié)省了上下文空間又提高了技能發(fā)現(xiàn)的靈活性。這個模式也有代價一次檢索多一次模型調(diào)用延遲會增加幾百毫秒。但如果你的技能庫里有大量長尾技能這個代價完全值得。5.2 建立技能反饋閉環(huán)每次調(diào)用都是一次學(xué)習(xí)機會技能體系不是一次建完就結(jié)束的它需要持續(xù)迭代。我在項目里建立了一個簡單的調(diào)用日志表記錄每次調(diào)用的用戶原始輸入、模型選擇技能、參數(shù)內(nèi)容、執(zhí)行結(jié)果、用戶后續(xù)反饋比如是否追問、是否投訴。每周做一次日志分析找出那些“模型選錯技能”或“用戶對結(jié)果不滿意”的案例更新對應(yīng)的技能描述或調(diào)整技能的優(yōu)先級。堅持下來技能體系會越用越順手。這里再分享一個小技巧條件允許時可以在測試階段同時跑兩套技能描述A/B測試對比同一批用戶問題的命中率選擇效果更好的那版發(fā)布。我就是用這個辦法把“查詢訂單狀態(tài)”技能的描述改了四個版本最終定下來的是包含“物流/配送/簽收/在途”多個同義詞表達的那版命中率從73%提升到91%。5.3 圍繞“技能市場”思路沉淀團隊資產(chǎn)最后說一個團隊協(xié)作層面的思考。很多團隊的項目是短期、可復(fù)用的但技能往往和個人經(jīng)驗綁定。我建議項目里把技能定義獨立于代碼倉庫單獨維護形成團隊內(nèi)部的“技能市場”。每個技能定義、描述、參數(shù)Schema、測試樣例、踩坑記錄都可以沉淀下來新項目直接復(fù)用現(xiàn)成技能而不是重新發(fā)明輪子。在維護 agent-skills 項目的過程中我最深的體會是Agent開發(fā)重的不是模型調(diào)參而是把業(yè)務(wù)拆解成模型能理解的一等公民。技能描述寫得好不好參數(shù)Schema定義得規(guī)不規(guī)范編排邏輯是否清晰這些細節(jié)的累積決定了你的Agent是“能用”還是“好用”。如果你正在疲憊于跟模型的對話調(diào)來調(diào)去不妨回頭看看自己的技能體系也許問題根本不在模型而在于你給它的工具和規(guī)則還不夠清晰。