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