之前說(shuō)過(guò)一句話一直憋到現(xiàn)在很多Agent項(xiàng)目不是死在模型能力上而是死在什么都能聊但什么都做不精。用戶打開(kāi)你的Agent不是來(lái)聽(tīng)它講道理的是來(lái)讓它干活的?？赡惆岩欢涯芰θM(jìn)Prompt里模型就開(kāi)始表演失憶指令一多反而什么都抓不住。一年前我折騰的這個(gè)項(xiàng)目代號(hào)就叫agent-skills核心思路很簡(jiǎn)單把Agent的能力從Prompt里的描述拆成一個(gè)個(gè)可注冊(cè)、可調(diào)用、可編排的技能。這篇把整套設(shè)計(jì)思路、踩坑過(guò)程和代碼實(shí)現(xiàn)都整理出來(lái)給正在搭A(yù)gent的同行做個(gè)參考。1. 為什么我放棄了全知全能Prompt轉(zhuǎn)而給Agent搭技能庫(kù)先說(shuō)幾個(gè)真實(shí)場(chǎng)景你大概率也遇到過(guò)。第一個(gè)是客服類Agent。最開(kāi)始把所有業(yè)務(wù)規(guī)則寫(xiě)進(jìn)system prompt大概兩千字效果還不錯(cuò)。后來(lái)產(chǎn)品要求加退款流程、物流查詢、優(yōu)惠券計(jì)算Prompt漲到五千字模型開(kāi)始答非所問(wèn)用戶問(wèn)A問(wèn)題它能扯到B業(yè)務(wù)上。我把規(guī)則精簡(jiǎn)、重排、加分隔符折騰了整整兩周效果依然不穩(wěn)定。第二個(gè)是內(nèi)部效率工具類的Agent。我給它接了日歷查詢、待辦管理、郵件草稿、周報(bào)生成能力都在一個(gè)Prompt里描述。結(jié)果它經(jīng)常分不清該調(diào)哪個(gè)能力明明有日歷查詢技能用戶問(wèn)明天幾點(diǎn)開(kāi)會(huì)它非要現(xiàn)編一個(gè)答案。更要命的是各個(gè)能力的輸入輸出格式不統(tǒng)一返回結(jié)果堆在上下文里模型自己都不知道哪段數(shù)據(jù)是哪個(gè)請(qǐng)求的。第三個(gè)更典型是把Agent從演示環(huán)境推到生產(chǎn)環(huán)境時(shí)的問(wèn)題。你自己測(cè)試的時(shí)候一個(gè)能力跑通了感覺(jué)一切OK。但真實(shí)用戶會(huì)亂問(wèn)、會(huì)打錯(cuò)別字、會(huì)提邊界條件模型處理不了的時(shí)候不會(huì)說(shuō)我做不到而是硬編一個(gè)讓人哭笑不得的結(jié)果出來(lái)。三個(gè)問(wèn)題指向同一個(gè)根因你根本沒(méi)給Agent定義清楚能做什么和怎么做而是把所有可能性都塞給了一個(gè)概率模型去猜。1.1 單體Prompt的失控過(guò)程你可以把單體Prompt想象成一個(gè)新員工的入職培訓(xùn)手冊(cè)里面寫(xiě)了你要為用戶提供全方位的幫助然后附了五百條業(yè)務(wù)規(guī)則。這個(gè)新員工腦子確實(shí)好使但每處理一個(gè)問(wèn)題它都要把五百條規(guī)則從頭到尾過(guò)一遍。規(guī)則越來(lái)越多它就開(kāi)始混淆把退款規(guī)則套到物流問(wèn)題上把優(yōu)惠券計(jì)算邏輯套到售后場(chǎng)景里。而且單體Prompt還有個(gè)隱藏問(wèn)題所有能力共享一段上下文。日歷查詢的返回結(jié)果、郵件草稿的生成內(nèi)容、周報(bào)的模板這些信息全部混在一起。模型在處理當(dāng)前任務(wù)時(shí)注意力會(huì)被無(wú)關(guān)信息干擾。這就好比一個(gè)程序員同時(shí)開(kāi)著五十個(gè)項(xiàng)目的上下文切換任務(wù)時(shí)很難不串線。另一個(gè)失控點(diǎn)是調(diào)試?yán)щy。Prompt出問(wèn)題你根本定位不了是哪條指令導(dǎo)致的。改一句話可能影響所有場(chǎng)景的表現(xiàn)。加一個(gè)新能力可能把舊能力的觸發(fā)條件擠掉。這種牽一發(fā)而動(dòng)全身的改法在業(yè)務(wù)快速迭代時(shí)基本是災(zāi)難。1.2 技能化架構(gòu)的核心邏輯agent-skills的思路是把每個(gè)能力做成一個(gè)獨(dú)立的技能每個(gè)技能有自己清晰的輸入、輸出、觸發(fā)條件和邊界約束。Agent不再猜測(cè)自己該干什么而是從一個(gè)登記在冊(cè)的技能列表里做選擇和組合。我可以用一個(gè)很土但貼切的比喻單體Prompt像讓一個(gè)萬(wàn)能助理同時(shí)管行政、財(cái)務(wù)、技術(shù)、客服他忙不過(guò)來(lái)技能化架構(gòu)則是給助理配了一堆專門的工具和應(yīng)用每個(gè)工具只解決一類問(wèn)題助理要做的事情是——知道什么場(chǎng)景用哪個(gè)工具并且按順序把工具串起來(lái)。這套架構(gòu)帶來(lái)三個(gè)直接好處邊界清晰。每個(gè)技能只對(duì)自己的輸入輸出負(fù)責(zé)上下文不再大鍋燴。日歷技能返回的數(shù)據(jù)不會(huì)污染郵件技能的判斷。獨(dú)立迭代。技能之間互不干擾。修搜索技能的bug不會(huì)影響周報(bào)生成技能的穩(wěn)定性?？捎^測(cè)可審計(jì)。Agent調(diào)用過(guò)哪些技能、傳了什么參數(shù)、返回了什么結(jié)果全部有日志。出問(wèn)題能回溯到具體環(huán)節(jié)。后面我會(huì)逐層拆解這套技能庫(kù)的完整設(shè)計(jì)以及每一步的代碼實(shí)現(xiàn)邏輯。2. 技能到底長(zhǎng)什么樣拆開(kāi)看一個(gè)Agent技能的五要素我在agent-skills里對(duì)技能的定義經(jīng)歷了三個(gè)版本的迭代。第一版很簡(jiǎn)單就是一個(gè)函數(shù)加一段文字描述跑通后發(fā)現(xiàn)模型經(jīng)常選錯(cuò)技能。第二版加了參數(shù)JSON Schema選對(duì)率明顯提升但遇到邊界情況還是會(huì)翻車。第三版才沉淀出穩(wěn)定的五要素結(jié)構(gòu)這版在多個(gè)項(xiàng)目里都穩(wěn)定運(yùn)行。一個(gè)完整的技能包含五個(gè)部分能力聲明name description技能叫什么、在什么場(chǎng)景下使用、有什么限制。觸發(fā)條件triggers什么樣的用戶意圖應(yīng)該路由到這個(gè)技能。參數(shù)規(guī)范parameters Schema調(diào)用這個(gè)技能需要傳什么參數(shù)每個(gè)參數(shù)的類型和約束。執(zhí)行邏輯execute技能被調(diào)用后實(shí)際執(zhí)行的函數(shù)或接口。邊界約束guardrails超時(shí)時(shí)間、重試策略、失敗后的兜底行為、權(quán)限范圍。這五要素里最容易被人忽略的是邊界約束。很多人定義一個(gè)技能就寫(xiě)個(gè)name和description然后直接接函數(shù)結(jié)果線上跑著跑著某個(gè)技能因?yàn)橥獠拷涌诔瑫r(shí)直接讓整個(gè)Agent掛掉。我后面會(huì)用一整章講這塊踩過(guò)的坑。2.1 五要素各自的作用能力聲明是給Agent看的廣告詞。你描述得越準(zhǔn)確模型選技能的選擇就越準(zhǔn)確。這里有個(gè)容易被忽略的技巧描述里一定要寫(xiě)清楚不適用什么場(chǎng)景負(fù)面示例能大幅提升選擇準(zhǔn)確率。只寫(xiě)正面場(chǎng)景模型容易把相關(guān)但不完全匹配的問(wèn)題也路由過(guò)來(lái)。觸發(fā)條件是給路由模塊看的分流規(guī)則。它可以是關(guān)鍵詞規(guī)則、語(yǔ)義相似度閾值也可以交給模型做意圖判斷。觸發(fā)條件寫(xiě)得越具體路由越穩(wěn)。參數(shù)規(guī)范是給參數(shù)校驗(yàn)器看的合同。模型生成的參數(shù)必須先通過(guò)Schema校驗(yàn)才真正傳給執(zhí)行函數(shù)。這樣能攔截掉大量非法輸入。執(zhí)行邏輯是真正干活的代碼。它不一定要是Python函數(shù)也可以是HTTP接口、SQL查詢、外部服務(wù)調(diào)用。關(guān)鍵是執(zhí)行邏輯必須和參數(shù)規(guī)范嚴(yán)格對(duì)齊。邊界約束是給系統(tǒng)的保險(xiǎn)絲。超時(shí)就斷、失敗就降級(jí)絕不能讓技能執(zhí)行失敗變成Agent的幻覺(jué)素材。2.2 一個(gè)完整的技能定義示例以查詢天氣技能為例第五版的設(shè)計(jì)大概是這樣的skill_weather { name: query_weather, description: 查詢指定城市當(dāng)前天氣及未來(lái)3天預(yù)報(bào)。當(dāng)用戶詢問(wèn)天氣、氣溫、降雨、風(fēng)力等情況時(shí)使用。不適用于查詢歷史天氣、空氣質(zhì)量指數(shù)或臺(tái)風(fēng)路徑這些請(qǐng)使用其他技能。, trigger_keywords: [天氣, 氣溫, 會(huì)不會(huì)下雨, 風(fēng)力, 天氣預(yù)報(bào)], parameters: { type: object, properties: { location: { type: string, description: 城市名或行政區(qū)名如北京、上海浦東 }, days: { type: integer, minimum: 1, maximum: 3, default: 1 } }, required: [location] }, execute: fetch_weather_from_service, timeout: 5, retry: 1, fallback: 天氣服務(wù)暫時(shí)不可用請(qǐng)稍后再試 }這段定義里最值得玩味的是description里的負(fù)面聲明。寫(xiě)了不適用于查詢歷史天氣、空氣質(zhì)量指數(shù)或臺(tái)風(fēng)路徑模型的技能選擇準(zhǔn)確率能提升不少。原因后面會(huì)細(xì)講。2.3 技能分類感知、操作、推理與交互技能不是只有調(diào)用API一種形態(tài)。我跑了幾個(gè)項(xiàng)目后發(fā)現(xiàn)把技能按職責(zé)分類對(duì)后續(xù)編排和復(fù)用非常關(guān)鍵。我最后常用的分類是四類技能類型典型職責(zé)示例交互特點(diǎn)感知類獲取外部信息天氣查詢、新聞檢索、數(shù)據(jù)庫(kù)查詢只讀不改變系統(tǒng)狀態(tài)操作類改變系統(tǒng)狀態(tài)創(chuàng)建工單、發(fā)送郵件、更新訂單有副作用需要授權(quán)確認(rèn)推理類純計(jì)算或邏輯判斷價(jià)格計(jì)算、日程沖突檢測(cè)、代碼執(zhí)行依賴明確參數(shù)無(wú)外部副作用交互類向用戶詢問(wèn)補(bǔ)充信息收集訂單號(hào)、確認(rèn)操作意圖多輪對(duì)話需要掛起恢復(fù)這四類技能在編排時(shí)的待遇完全不同。操作類技能我會(huì)強(qiáng)制增加用戶確認(rèn)步驟交互類技能會(huì)設(shè)計(jì)專門的上下文掛起機(jī)制推理類技能則優(yōu)先用確定的計(jì)算代碼而不是讓模型自己算。這些細(xì)節(jié)直接決定了Agent在生產(chǎn)環(huán)境下的可靠度。3. 從定義到上線的完整鏈路注冊(cè)、編排、調(diào)用與降級(jí)定義好單個(gè)技能只是第一步。真正讓Agent具備干活能力的是一整套從注冊(cè)到調(diào)用的運(yùn)行鏈路。這一章我把a(bǔ)gent-skills運(yùn)行時(shí)核心的幾個(gè)環(huán)節(jié)展開(kāi)講全部是可直接復(fù)用的工程實(shí)踐。3.1 技能注冊(cè)表與模型決策每個(gè)技能定義好之后第一步是注冊(cè)到一個(gè)全局的技能注冊(cè)表里。注冊(cè)表本質(zhì)就是一個(gè)字典key是技能名value是整個(gè)技能定義對(duì)象class SkillRegistry: def __init__(self): self._skills {} self._name_to_keywords {} def register(self, skill: dict): name skill[name] self._skills[name] skill for kw in skill.get(trigger_keywords, []): self._name_to_keywords.setdefault(kw, []).append(name) def match_by_intent(self, user_query: str): # 優(yōu)先關(guān)鍵詞精確匹配 for kw, names in self._name_to_keywords.items(): if kw in user_query: return names return None registry SkillRegistry() registry.register(skill_weather) registry.register(skill_create_ticket) registry.register(skill_calculate_price)這里有個(gè)設(shè)計(jì)取舍值得說(shuō)技能選擇到底用確定性規(guī)則還是讓模型來(lái)選我的實(shí)踐結(jié)論是分層過(guò)濾。先用關(guān)鍵詞和規(guī)則做粗篩得到候選技能列表如果粗篩結(jié)果唯一直接執(zhí)行不浪費(fèi)模型調(diào)用如果粗篩結(jié)果有多個(gè)或?yàn)榭赵僮屇Ｐ蛷暮蜻x列表里做最終選擇。這種方式既省Token又比純規(guī)則或純模型判斷都穩(wěn)定。3.2 參數(shù)校驗(yàn)與失敗兜底模型選擇了技能后緊接著就是參數(shù)校驗(yàn)。這一步必須用JSON Schema嚴(yán)格校驗(yàn)不能依賴模型自覺(jué)傳參數(shù)。我在實(shí)際項(xiàng)目中遇到過(guò)模型把日期傳成明天、把金額傳成帶逗號(hào)的字符串、把必填字段漏掉等情況全是在校驗(yàn)層攔下來(lái)的。校驗(yàn)通過(guò)后執(zhí)行器會(huì)做幾件事記錄調(diào)用日志包含入?yún)?、時(shí)間戳、調(diào)用方會(huì)話ID按技能配置的超時(shí)時(shí)間執(zhí)行函數(shù)默認(rèn)5秒如果超時(shí)或拋異常按retry次數(shù)重試默認(rèn)1次最終失敗時(shí)返回一個(gè)標(biāo)準(zhǔn)錯(cuò)誤信息而不是讓異常直接上拋。錯(cuò)誤信息格式我固定為{ status: error, error_code: weather_service_timeout, message: 天氣服務(wù)暫時(shí)不可用請(qǐng)稍后再試 }之所以用這種結(jié)構(gòu)化錯(cuò)誤格式是為了讓Agent在拿到錯(cuò)誤結(jié)果時(shí)能明確知道技能失敗了而不是把錯(cuò)誤信息誤當(dāng)成正常數(shù)據(jù)繼續(xù)編故事。這一點(diǎn)我會(huì)在踩坑章節(jié)重點(diǎn)解釋。3.3 一次真實(shí)調(diào)用背后的完成流程把完整鏈路串起來(lái)一次用戶請(qǐng)求到最終回應(yīng)的流程是這樣的用戶輸入上海明天會(huì)不會(huì)下雨路由模塊用trigger_keywords粗篩命中query_weather技能。參數(shù)提取器從用戶輸入里抽取出 {location: 上海, days: 2}。這里的抽取可以交給模型但必須有Schema約束。參數(shù)校驗(yàn)器檢查通過(guò)。執(zhí)行器調(diào)用天氣服務(wù)拿到返回?cái)?shù)據(jù)。結(jié)果規(guī)整器把外部數(shù)據(jù)轉(zhuǎn)成Agent友好的格式 根據(jù)天氣服務(wù)上海明天2025-01-15有小雨氣溫5~9℃東南風(fēng)3級(jí)。結(jié)果回填到Agent的上下文窗口Agent基于這段真實(shí)數(shù)據(jù)生成用戶可讀的回復(fù)。這個(gè)流程里第6步經(jīng)常被忽略但特別重要。外部服務(wù)返回的原始JSON通常包含大量無(wú)關(guān)字段直接塞進(jìn)上下文既浪費(fèi)Token又會(huì)干擾模型。我在agent-skills里為每個(gè)技能配了一個(gè)result_formatter函數(shù)負(fù)責(zé)把原始返回精簡(jiǎn)成一段話。這一步做好模型回復(fù)的準(zhǔn)確率能肉眼可見(jiàn)地提升。4. 技能編排實(shí)踐讓多個(gè)技能像團(tuán)隊(duì)一樣協(xié)作單技能場(chǎng)景其實(shí)不太需要Agent參與規(guī)則引擎就夠了。Agent真正體現(xiàn)價(jià)值的地方是多個(gè)技能組合起來(lái)完成一個(gè)復(fù)雜目標(biāo)。這一章講編排的幾種模式以及我在實(shí)戰(zhàn)中的觀察。4.1 四種基礎(chǔ)編排模式在agent-skills里我總結(jié)了四種基礎(chǔ)編排模式順序編排一步做完做下一步上一步的結(jié)果是下一步的輸入。典型場(chǎng)景是查日歷確認(rèn)空閑時(shí)間再創(chuàng)建會(huì)議邀請(qǐng)。條件分支根據(jù)某個(gè)技能的結(jié)果決定走哪條分支。典型場(chǎng)景是查詢庫(kù)存如果低于閾值就去創(chuàng)建補(bǔ)貨工單否則提示用戶一切正常。并行編排多個(gè)技能互不依賴同時(shí)執(zhí)行節(jié)省時(shí)間。典型場(chǎng)景是查天氣和查航班同時(shí)進(jìn)行。循環(huán)編排對(duì)一組數(shù)據(jù)逐個(gè)執(zhí)行同一個(gè)技能。典型場(chǎng)景是批量檢查多個(gè)服務(wù)的健康狀態(tài)。這些模式在代碼層面就是普通的控制流但關(guān)鍵問(wèn)題是誰(shuí)來(lái)編排我試過(guò)兩種策略效果差異巨大。4.2 周報(bào)自動(dòng)生成場(chǎng)景的編排拆解拿我做過(guò)的周報(bào)Agent當(dāng)例子。這個(gè)Agent的核心目標(biāo)用戶說(shuō)幫我生成這周的周報(bào)它要自動(dòng)匯總本周的日程、代碼提交記錄、待辦完成情況然后生成一份結(jié)構(gòu)化的周報(bào)。我最初設(shè)計(jì)為鏈?zhǔn)秸{(diào)用def generate_weekly_report(user_id): # Step 1: 查詢本周日程 events query_calendar(user_id, week) # Step 2: 查詢代碼提交記錄 commits query_code_commits(user_id, week) # Step 3: 查詢待辦完成率 todos query_todo_stats(user_id, week) # Step 4: 匯總生成周報(bào) report generate_report(events, commits, todos) return report第一個(gè)版本就是把四個(gè)技能用Python代碼固定編排好順序執(zhí)行。效果很穩(wěn)但有個(gè)問(wèn)題用戶的需求一旦變化比如只匯總?cè)粘毯痛k不要代碼記錄代碼邏輯就要改。后來(lái)我改成了模型生成計(jì)劃代碼執(zhí)行計(jì)劃的方式。模型先看用戶意圖生成一個(gè)技能執(zhí)行計(jì)劃比如[ {skill: query_calendar, params: {user_id: ..., range: week}}, {skill: query_todo_stats, params: {user_id: ..., range: week}}, {skill: generate_report, params: {}} ]然后一個(gè)計(jì)劃執(zhí)行器按順序執(zhí)行這些技能再把結(jié)果匯總。這種方式靈活度高但穩(wěn)定性比固定代碼差一截需要在編排層加約束。4.3 動(dòng)態(tài)編排讓模型當(dāng)指揮的得失模型動(dòng)態(tài)編排最大的坑在于它會(huì)自作主張。我遇到過(guò)模型在生成周報(bào)計(jì)劃時(shí)自己發(fā)明了一個(gè)不存在的技能叫g(shù)et_weekly_summary注冊(cè)表里根本沒(méi)有。還有一次模型擅自改變了技能執(zhí)行順序先調(diào)生成報(bào)告再查數(shù)據(jù)結(jié)果報(bào)告里全是空的。后來(lái)我加了兩道保險(xiǎn)只允許從注冊(cè)表已有技能中選擇。模型生成的計(jì)劃必須在已注冊(cè)技能集合內(nèi)否則直接拒絕并讓模型重新生成。計(jì)劃校驗(yàn)器。用Schema定義計(jì)劃的格式校驗(yàn)技能名是否存在、參數(shù)是否合法、是否包含必選步驟。加了這兩道保險(xiǎn)之后動(dòng)態(tài)編排的穩(wěn)定性基本趕上了固定代碼編排同時(shí)保留了靈活度。我現(xiàn)在的建議是核心流程用固定代碼非核心或長(zhǎng)尾需求用動(dòng)態(tài)編排兩者結(jié)合的收益最高。5. 實(shí)測(cè)踩坑記錄技能沖突、上下文污染與幻覺(jué)兜底技能化架構(gòu)不是銀彈它只是把一部分不確定性從模型側(cè)轉(zhuǎn)移到了工程側(cè)。工程側(cè)的坑一點(diǎn)也不少。這一章是全文最硬核的部分我把實(shí)測(cè)踩過(guò)、又逐一解決的坑位寫(xiě)清楚。5.1 技能描述寫(xiě)太泛模型總選錯(cuò)這是第一個(gè)版本遇到的問(wèn)題。我一開(kāi)始把query_weather的描述寫(xiě)成查詢天氣信息。結(jié)果用戶問(wèn)上海適合穿什么衣服模型居然把它路由到了query_weather。表面看也沒(méi)錯(cuò)但查詢天氣返回的只有氣溫和降水根本沒(méi)有穿衣建議模型只能硬編一個(gè)。后來(lái)我研究了一下模型選擇技能的行為模式發(fā)現(xiàn)它特別吃邊界描述。所以我給每個(gè)技能的description加了正反兩面描述正面當(dāng)用戶詢問(wèn)天氣、氣溫、降雨、風(fēng)力等情況時(shí)使用。 反面不適用于穿衣建議、空氣質(zhì)量、臺(tái)風(fēng)路徑、歷史氣候統(tǒng)計(jì)這些請(qǐng)使用或路由到其他技能。這個(gè)改動(dòng)讓技能選擇準(zhǔn)確率提升非常明顯。為什么因?yàn)樨?fù)面描述減少了語(yǔ)義空間的不確定性模型在匹配時(shí)有了排除項(xiàng)不再把相似但不等同的意圖拉進(jìn)來(lái)。5.2 上下文污染模型分不清哪個(gè)結(jié)果對(duì)應(yīng)哪個(gè)請(qǐng)求并行編排或連續(xù)編排多個(gè)技能時(shí)所有技能的結(jié)果都堆在上下文里模型經(jīng)常分不清哪段數(shù)據(jù)是哪個(gè)技能的。一開(kāi)始我以為這是小事后來(lái)發(fā)現(xiàn)后果很嚴(yán)重。最典型的一次事故用戶先問(wèn)北京天氣怎么樣再問(wèn)那北京明天呢Agent先調(diào)query_weather(北京, 1)又調(diào)query_weather(北京, 2)兩次結(jié)果都在上下文里。模型在生成回復(fù)時(shí)引用了第一天的數(shù)據(jù)回答第二天的天氣而且語(yǔ)氣非常確定。解決方案是在結(jié)果規(guī)整階段給每段技能結(jié)果加明確的標(biāo)簽前綴[技能: query_weather | 參數(shù): {location: 北京, days: 2} | 時(shí)間: 2025-01-14 10:30:22] 天氣服務(wù)返回北京明天2025-01-15有小雨氣溫5~9℃。這樣一來(lái)模型能清楚區(qū)分哪個(gè)請(qǐng)求的哪個(gè)返回。加標(biāo)簽之后上下文污染導(dǎo)致的錯(cuò)答問(wèn)題基本消失了。5.3 幻覺(jué)兜底技能失敗后模型編答案這是所有坑里最危險(xiǎn)的一個(gè)。技能執(zhí)行失敗返回了錯(cuò)誤信息但模型拿到錯(cuò)誤信息后不會(huì)老實(shí)說(shuō)查詢失敗而是會(huì)基于錯(cuò)誤的上下文猜測(cè)一個(gè)合理答案。比如天氣服務(wù)超時(shí)模型直接回答北京明天多云氣溫8℃——它自己編的語(yǔ)氣還特別篤定。我排查了很久才發(fā)現(xiàn)問(wèn)題出在錯(cuò)誤信息的措辭上。我之前返回的錯(cuò)誤JSON是{ status: error, message: 服務(wù)超時(shí) }模型看到這段文字可能理解成這是用戶的查詢結(jié)果。后面我改成強(qiáng)語(yǔ)義的錯(cuò)誤隔離格式并且在回填上下文時(shí)對(duì)錯(cuò)誤結(jié)果前綴加上明顯的阻斷標(biāo)記[執(zhí)行失敗] 技能 query_weather 調(diào)用異常天氣服務(wù)超時(shí)。請(qǐng)不要猜測(cè)或編造結(jié)果直接告知用戶服務(wù)暫時(shí)不可用。同時(shí)在系統(tǒng)提示里寫(xiě)死一條規(guī)則當(dāng)技能返回狀態(tài)為error時(shí)嚴(yán)禁編造任何數(shù)據(jù)結(jié)果。這一套組合拳下來(lái)才把幻覺(jué)應(yīng)答率壓到可接受的范圍。5.4 常見(jiàn)坑位速查表把這一章踩過(guò)的坑整理成一張表方便直接排查現(xiàn)象根因解決方案技能選擇不準(zhǔn)description缺少負(fù)面示例正反兩面寫(xiě)描述明確排除場(chǎng)景模型傳非法參數(shù)未做Schema校驗(yàn)加JSON Schema嚴(yán)格校驗(yàn)層多個(gè)結(jié)果混淆上下文缺少結(jié)果標(biāo)識(shí)結(jié)果回填前加技能名參數(shù)標(biāo)簽技能失敗后編答案錯(cuò)誤信息被當(dāng)成正常結(jié)果強(qiáng)語(yǔ)義錯(cuò)誤隔離系統(tǒng)提示禁止編造動(dòng)態(tài)編排亂序模型自由度高計(jì)劃Schema校驗(yàn)只允許注冊(cè)表內(nèi)技能一個(gè)技能報(bào)錯(cuò)整站不可用缺少超時(shí)與降級(jí)統(tǒng)一timeoutretryfallback這張表是我每次接入新項(xiàng)目時(shí)都會(huì)拿出來(lái)核對(duì)一遍的清單省了很多線上下排查的時(shí)間。6. 技能庫(kù)的演進(jìn)方向復(fù)用、評(píng)測(cè)與生態(tài)化agent-skills從最初的一個(gè)簡(jiǎn)陋腳本變成一個(gè)勉強(qiáng)能稱為框架的東西中間最大的轉(zhuǎn)折就是我意識(shí)到技能的維護(hù)成本和技能的復(fù)用價(jià)值決定了這套架構(gòu)能不能活下去。技能寫(xiě)得再漂亮如果不可評(píng)測(cè)、不可復(fù)用那它只是又一套一次性代碼。6.1 獨(dú)立評(píng)測(cè)是技能復(fù)用的前提單個(gè)技能在集成到Agent之前必須可獨(dú)立評(píng)測(cè)。我在每個(gè)技能定義里強(qiáng)制加了一個(gè)evaluate函數(shù)負(fù)責(zé)跑一組預(yù)先設(shè)計(jì)的測(cè)試用例。比如query_weather的評(píng)測(cè)集至少包含正常查詢北京明天天氣如何 → 期望命中query_weather且參數(shù)解析正確邊界輸入北京和上海哪個(gè)更冷 → 期望不直接命中單城市天氣技能可能需要對(duì)比邏輯負(fù)面場(chǎng)景推薦一件適合北京的羽絨服 → 期望不路由到query_weather評(píng)測(cè)邏輯很簡(jiǎn)單跑一組輸入看技能路由選擇對(duì)不對(duì)、參數(shù)解析對(duì)不對(duì)、最終輸出質(zhì)量如何。只有通過(guò)評(píng)測(cè)的技能才有資格注冊(cè)到生產(chǎn)環(huán)境的技能庫(kù)里。這套機(jī)制讓我敢放心地加新技能不用怕污染已有的能力。6.2 觀察指標(biāo)調(diào)用成功率、延遲與Token消耗技能上線后監(jiān)控指標(biāo)是另一個(gè)關(guān)鍵環(huán)節(jié)。我每個(gè)技能掛鉤了三個(gè)核心指標(biāo)調(diào)用成功率成功執(zhí)行的次數(shù) / 總調(diào)用次數(shù)。延遲從發(fā)起調(diào)用到返回結(jié)果的耗時(shí)P50和P99都要看。Token消耗技能描述、參數(shù)Schema、結(jié)果回填一共吃掉多少上下文Token。Token消耗是最容易被忽視的。一套大技能庫(kù)每個(gè)技能的description都可能幾百字把這些描述全部塞給模型每次對(duì)話都要消耗大量Token。我后來(lái)采用了一種按需加載的策略——先用粗篩選出候選技能只把候選技能的描述和Schema注入上下文而不是每次把全部技能定義都塞給模型。這招讓每次調(diào)用的Token成本降了將近一半。6.3 從個(gè)人技能庫(kù)到團(tuán)隊(duì)技能市場(chǎng)當(dāng)技能數(shù)量超過(guò)二十個(gè)之后我開(kāi)始有意識(shí)地把它當(dāng)成一個(gè)市場(chǎng)來(lái)運(yùn)營(yíng)。團(tuán)隊(duì)里每個(gè)人都可以提交技能但必須先滿足三件事有完整的五要素定義、通過(guò)評(píng)測(cè)集、有監(jiān)控指標(biāo)的報(bào)告。程序上收窄就會(huì)倒逼質(zhì)量。這里有一個(gè)真實(shí)的體會(huì)少即是多。我曾經(jīng)維護(hù)過(guò)一個(gè)六十多個(gè)技能的庫(kù)里面一半技能一個(gè)月都沒(méi)被調(diào)用一次。這些僵尸技能不僅占用上下文還會(huì)干擾模型的選擇。后來(lái)做了一個(gè)季度清理把所有調(diào)用率低于1%的技能下線Agent的整體回答準(zhǔn)確率反而漲了一截。我現(xiàn)在對(duì)技能庫(kù)的目標(biāo)不再追求數(shù)量而是追求每個(gè)技能都能回答三個(gè)問(wèn)題它能解決什么問(wèn)題、它不能解決什么問(wèn)題、它失敗了會(huì)留下什么可追蹤的痕跡。想通這三點(diǎn)技能的體系就算立住了。