建可復(fù)用智能體技能體系)
agent-skills這個詞最近在AI圈子里被反復(fù)提起。我做智能體開發(fā)也有兩三年了從最早的提示詞堆砌到后來的函數(shù)調(diào)用再到現(xiàn)在圍繞技能skills來構(gòu)建智能體最大的感受是智能體的能力上限早就不是模型本身了而是你給它配備了多少高質(zhì)量、可復(fù)用的技能。如果你正打算做AI Agent相關(guān)的項目或者在為現(xiàn)有的智能體產(chǎn)品能力發(fā)愁——感覺模型什么都能聊但一落到具體任務(wù)上就漏洞百出——那我強烈建議你認真研究一下agent-skills這個方向。這篇文章會把我在實際項目中關(guān)于技能設(shè)計、技能編排、以及如何把一套技能系統(tǒng)真正落地的經(jīng)驗全部拆開來講包括踩過的坑和最終沉淀下來的方法論希望對你有用。1. agent-skills 到底是什么從瑣碎動作到復(fù)合能力1.1 技能不是會調(diào)用工具而是會完成一件事很多人一開始會把技能skills和工具調(diào)用function calling / tool use混為一談。工具調(diào)用是智能體調(diào)用一個外部API或函數(shù)比如查詢天氣打開網(wǎng)頁發(fā)送郵件這是原子操作顆粒度非常細。而技能不一樣技能是一個面向目標的能力封裝它內(nèi)部可能包含多個步驟、多個工具、多輪自我校驗。我用一個生活化的例子解釋工具是拿起鍋鏟技能是炒一盤番茄炒蛋。拿起鍋鏟只需要一個動作但炒一盤菜需要你判斷番茄熟度、控制火候、決定什么時候放鹽、最后還要嘗味道確認咸淡。技能就是這個炒菜的完整流程而不是某一個單一動作。在實際的Agent開發(fā)中這兩者的區(qū)別直接決定了智能體是像個工具人還是像個幫手。我見過太多項目把十幾個API一股腦兒塞給大模型以為模型會自動把事情辦好。結(jié)果模型確實會調(diào)用API但它不知道什么時候該調(diào)、調(diào)完該做什么、結(jié)果異常怎么辦。這就是典型的只有工具沒有技能。1.2 agent-skills 項目的核心價值能力資產(chǎn)化agent-skills作為一個項目主題核心要解決的事情很明確把智能體執(zhí)行復(fù)雜任務(wù)的能力變成一個可以被定義、復(fù)用、共享、升級的資產(chǎn)。你可以把技能理解成智能體的職業(yè)能力證書。一個客服智能體可以擁有處理退款單查詢物流狀態(tài)安撫不滿用戶升級投訴工單等技能一個代碼助手可以擁有理解倉庫結(jié)構(gòu)運行測試用例修復(fù)單元測試失敗生成提交信息等技能。每個技能都不是憑空來的它是業(yè)務(wù)知識和工程實現(xiàn)的結(jié)晶。我把這個過程中的關(guān)鍵價值歸納成三點可復(fù)用一次開發(fā)多處使用。同樣的語義檢索技能既可以用在問答機器人里也可以用在文檔助手、客服質(zhì)檢系統(tǒng)里?？山M合復(fù)雜任務(wù)由簡單技能編排而來。比如寫周報技能 收集本周提交記錄 分析代碼變更 生成周報文檔。可進化技能是獨立模塊可以單獨迭代升級不影響智能體的其他部分。今天把生成SQL查詢技能升級了不必改動整個Agent邏輯。1.3 這套思路適合誰來用說實話agent-skills的受眾比我預(yù)想的要寬得多。我一開始以為這是開發(fā)者專屬的東西后來發(fā)現(xiàn)產(chǎn)品經(jīng)理、業(yè)務(wù)運營、甚至獨立開發(fā)者都在用類似的思路設(shè)計他們的智能體。如果你是開發(fā)者你可以從代碼層面實現(xiàn)一套技能框架定義好技能的結(jié)構(gòu)、加載方式、調(diào)度邏輯如果你是產(chǎn)品經(jīng)理你可以用技能的思路來規(guī)劃Agent的功能邊界——一個智能體該具備哪些技能每個技能的輸入輸出是什么優(yōu)先級怎么排如果你是業(yè)務(wù)方你可以把團隊的SOP標準作業(yè)流程轉(zhuǎn)成技能描述讓智能體嚴格按SOP執(zhí)行。無論你在哪個位置agent-skills這套思維都能讓你手頭的智能體從能聊天變成能干活。2. 技能系統(tǒng)設(shè)計的底層邏輯為什么說技能不是簡單的函數(shù)2.1 技能的三大組成意圖描述、執(zhí)行流、驗收標準當(dāng)我們把技能當(dāng)作一個工程對象來看待時它絕不是一段提示詞或者一個函數(shù)那么單薄。我在實際設(shè)計技能時要求每個技能必須包含三個部分意圖描述Intent、執(zhí)行流Flow、驗收標準Acceptance Criteria。意圖描述是給大模型看的說明書告訴模型什么情況下該使用這個技能、這個技能能解決什么問題、使用前需要準備什么信息。執(zhí)行流是技能內(nèi)部的步驟編排可以是一個固定的工作流也可以是一個讓模型自主決策的策略框架。驗收標準則是技能質(zhì)量的底線——步驟跑完不算完必須通過驗收標準才算是真正完成了任務(wù)。舉個例子。我在做一個電商客服Agent時設(shè)計了一個處理退貨申請技能。它的意圖描述會寫明當(dāng)用戶明確表達退貨訴求并且訂單處于已簽收狀態(tài)時啟用本技能。執(zhí)行流是核實訂單號→核對退貨原因→檢查是否在退貨窗口期→生成退貨碼→告知用戶退貨流程。驗收標準是用戶拿到了退貨碼且系統(tǒng)日志中記錄了退貨申請單號。這套三件套的設(shè)計讓我在后期排查Agent為什么沒按預(yù)期工作時省了無數(shù)時間。因為每一層都可以單獨驗證是模型沒識別出該用技能還是執(zhí)行流里某一步做錯了還是技能完成質(zhì)量不達標問題是發(fā)生在哪個環(huán)節(jié)一目了然。2.2 技能的顆粒度太大太小都會出事我剛做技能設(shè)計時犯的最嚴重的錯誤是技能顆粒度掌握不好。一開始我把顆粒度設(shè)計得特別細每個技能只做一件極小的事比如提取訂單號判斷退貨窗口期結(jié)果一個退貨任務(wù)要串聯(lián)七八個技能模型在步驟間切換時頻繁出錯上下文也被拖得很長后來我又把顆粒度放大整個退貨流程做成一個技能結(jié)果模型試圖下雨天收衣服——什么都想管反而經(jīng)常在不必要的環(huán)節(jié)上較勁。最終的平衡點在于技能應(yīng)該能獨立完成一個有明確產(chǎn)出的業(yè)務(wù)動作。判斷退貨窗口期沒有獨立產(chǎn)出它只是中間步驟不適合做技能處理退貨申請有明確產(chǎn)出退貨碼流程指引且能獨立執(zhí)行適合做技能。如果流程太長可以拆成處理退貨申請和監(jiān)督退貨退款進度兩個技能前者負責(zé)發(fā)退貨碼后者負責(zé)追蹤退款到賬。這個判斷標準在實際操作中非常有用你設(shè)計好一個技能后問自己一句——這個技能執(zhí)行完后用戶或系統(tǒng)能拿到一個明確的結(jié)果嗎能就說明顆粒度合適不能就把技能繼續(xù)外擴。2.3 技能之間如何協(xié)同編排層是靈魂單有技能還不行Agent拿到的是一個任務(wù)它得能判斷該用哪個技能先做哪個后做哪個多個技能的結(jié)果怎么合并。這一層我管它叫編排層Orchestration它才是整個Agent的魂。編排思路主流有兩種。一種是靠模型自主判斷也就是讓大模型根據(jù)用戶輸入從技能列表里挑一個來調(diào)用。這種方式靈活度高但可靠度一般尤其當(dāng)技能數(shù)量超過20個以后模型的選擇準確率明顯下降。另一種是靠確定性規(guī)則我們預(yù)先定義好業(yè)務(wù)處理流程什么場景走什么技能鏈。這種方式穩(wěn)定但靈活性差遇到規(guī)則外的場景就傻眼。我現(xiàn)在做項目采用的是混合編排核心業(yè)務(wù)路徑用確定性規(guī)則兜底邊緣場景交給模型自主決策。比如客服Agent用戶明確說我要退貨就直接走退貨技能鏈用戶說這個商品我不滿意模型自主判斷用戶可能想退貨或換貨再引導(dǎo)到具體技能。這樣既穩(wěn)又不死板。3. 實操搭建一套可擴展的 agent-skills 技能框架3.1 技能描述文件的標準化進入工程實現(xiàn)環(huán)節(jié)第一步是定義技能的描述格式。用過Anthropic的Claude Skills或者OpenAI的自定義Agent的話你會發(fā)現(xiàn)它們都不約而同采用了一個技能一個目錄的物理組織方式目錄里放一個描述文件外加若干腳本和資源文件。我的標準目錄結(jié)構(gòu)大致長這樣skills/ └── handle-refund/ ├── SKILL.md # 技能描述、使用條件、執(zhí)行步驟 ├── run.py # 技能執(zhí)行腳本可選 ├── refund_template.md # 給用戶回復(fù)的話術(shù)模板 └── requirements.txt # 技能運行時的依賴SKILL.md是技能的核心。我會要求團隊必須嚴格按照以下模板來寫--- name: handle-refund description: 處理用戶的商品退貨申請生成退貨碼并指導(dǎo)用戶寄回商品。 使用條件 - 用戶明確表達退貨訴求 - 訂單狀態(tài)為“已簽收” - 有有效訂單號 輸入?yún)?shù) - order_id: string訂單號 執(zhí)行步驟 1. 調(diào)用 check_order_status 確認訂單狀態(tài) 2. 核對退貨原因是否在支持范圍內(nèi) 3. 調(diào)用 generate_return_code 生成退貨碼 4. 使用 refund_template.md 生成用戶回復(fù) 驗收標準 - 返回退貨碼 - 系統(tǒng)日志寫入退貨申請記錄 --- # 處理退貨申請技能 技能細節(jié)說明可以寫一些給執(zhí)行模型看的注意事項比如某些特殊情況怎么處理、有哪些坑要避開……印象中這個格式一旦標準化下來后面的迭代效率會大幅提升。以前我們用純自然語言寫的技能描述每個風(fēng)格都不同模型一會兒能讀懂一會兒讀不懂標準化的YAML頭部加自然語言主體之后模型對技能觸發(fā)條件的識別穩(wěn)了很多。3.2 技能加載機制別把所有技能都塞進上下文接下來是關(guān)鍵工程問題——技能怎么加載進大模型。如果Agent有20個技能每個SKILL.md平均800字那就是16000字全部塞進上下文會讓系統(tǒng)提示詞變得又長又貴還會降低模型對關(guān)鍵指令的注意力。我在項目中采用了兩級加載機制。第一級是技能清單每個Agent只加載一份技能索引里面是每個技能的名字、一行描述、參數(shù)要求。這份索引控制在幾百字內(nèi)讓模型知道有哪些技能可用。第二級是按需加載當(dāng)模型決定要調(diào)用某個技能時系統(tǒng)再去把對應(yīng)技能目錄下的完整SKILL.md和腳本動態(tài)讀取進來。這樣做的好處非常明顯上下文占用從所有技能的全文變成了清單全文 當(dāng)前要用的技能全文。如果一共20個技能、每次任務(wù)最多用到3個上下文開銷能減少70%以上。而且技能數(shù)量可以持續(xù)擴張不再受上下文窗口制約。這個方案可以用很簡單的Python函數(shù)實現(xiàn)動態(tài)檢索def load_skill(skill_name: str) - Optional[Skill]: 按需加載技能目錄返回技能對象 skill_path SKILLS_DIR / skill_name if not skill_path.exists() or not (skill_path / SKILL.md).exists(): return None description (skill_path / SKILL.md).read_text(encodingutf-8) return Skill(nameskill_name, descriptiondescription, pathskill_path)實際用下來這種懶加載模式讓整體響應(yīng)延遲也降低了——因為不需要每次請求都把20多個技能文件全部讀一遍I/O開銷小了很多。3.3 技能注冊表與運行時調(diào)度技能文件只是靜態(tài)資源運行時還需要一個調(diào)度核心。我會維護一個技能注冊表skill registry把所有的技能元信息集中登記起來同時負責(zé)加載、校驗和執(zhí)行。調(diào)度核心的核心邏輯其實不復(fù)雜接收用戶的自然語言請求找出適合的技能執(zhí)行技能并返回結(jié)果。但這里有幾個必須在工程上處理的細節(jié)。第一個是技能參數(shù)校驗。模型生成的參數(shù)經(jīng)常不完整——用戶沒說訂單號怎么辦參數(shù)格式不對怎么辦我的做法是在調(diào)用技能前增加一層參數(shù)校驗邏輯缺什么參數(shù)先向用戶補齊而不是直接把殘缺參數(shù)丟給技能去執(zhí)行。這里校驗邏輯可以用JSON Schema來描述參數(shù)約束讓模型按照Schema補全參數(shù)。第二個是執(zhí)行結(jié)果反饋。技能執(zhí)行完以后結(jié)果要回傳給模型讓模型根據(jù)結(jié)果決定下一步動作。這個閉環(huán)如果不做Agent就會出現(xiàn)技能執(zhí)行完了但模型還在那邊自顧自地說話的情況。我一般會把執(zhí)行結(jié)果、狀態(tài)碼、耗時等結(jié)構(gòu)化信息一并返回給模型。def execute_skill(skill_name: str, params: dict) - ExecutionResult: # 1. 加載技能并校驗參數(shù) skill load_skill(skill_name) if skill is None: return ExecutionResult(successFalse, error技能不存在) # 2. 補全缺失參數(shù)向模型或用戶索取 fill_params complete_params(skill, params) # 3. 執(zhí)行技能邏輯記錄日志 result run_skill_fn(skill, fill_params) # 4. 將執(zhí)行結(jié)果封裝交給編排層判斷下一步 return result調(diào)度層還有一個容易被忽略的點并發(fā)與超時。技能里有外部API調(diào)用時必須設(shè)置超時時間。我之前遇到過技能內(nèi)部調(diào)第三方接口卡死整個Agent跟著一起卡住的情況。后來把技能的超時和重試機制做進調(diào)度層每個技能默認超時10秒超過則返回錯誤信息給模型模型可以選擇換一個技能或者告知用戶稍后再試。3.4 讓技能具備自我修復(fù)能力光能把技能跑通不算完生產(chǎn)環(huán)境中的技能一定會因為各種原因失敗上游API返回格式變了、數(shù)據(jù)庫里沒有對應(yīng)數(shù)據(jù)、網(wǎng)絡(luò)閃斷……所以我的技能框架里一定會加一層失敗處理機制。失敗處理我設(shè)計了三個層次第一層技能內(nèi)部重試主要應(yīng)對超時和瞬時錯誤第二層模型介入糾偏當(dāng)技能返回明確錯誤碼時把錯誤信息回傳給模型讓模型嘗試修正參數(shù)后重新調(diào)用第三層用戶兜底前兩層都失敗了就如實告訴用戶這個操作我完成不了原因是什么并提供人工處理的入口。這套三級策略讓我的Agent在生產(chǎn)環(huán)境中的任務(wù)完成率從剛上線時的67%提升到了91%。雖然離完美還很遠但至少大部分異常場景下用戶得到的不是一句干巴巴的出現(xiàn)錯誤而是有信息量的反饋和后續(xù)路徑。4. 技能工程中的常見問題與排查實錄4.1 模型就是不調(diào)用技能怎么辦這是所有做Agent開發(fā)的人都會遇到的頭號問題——技能寫得挺好的規(guī)則也都清楚但模型就是不用。常見的場景是模型直接根據(jù)參數(shù)算了個假結(jié)果繞過了你的技能。我先說排查路徑。第一步確認技能描述里的使用條件是否寫清楚了觸發(fā)條件模糊模型就無法準確識別。第二步檢查技能的description字段是否足夠直白模型選技能主要看這個字段寫得太抽象容易讓模型拿不準。第三步看模型實際看到的上下文——是不是技能清單被其他指令淹沒在上下文中了。在實踐中我用的最有效的辦法是把技能描述寫成一個使用示例。與其寫當(dāng)用戶需要退貨時調(diào)用本技能不如寫如果用戶說我要退貨商品不合適怎么退幫我申請退款調(diào)用本技能返回退貨碼和寄回地址。給模型看具體例子它的判斷準確率會有肉眼可見的提升。另外還有一個非常實用的小技巧在系統(tǒng)提示詞里加一句在回答之前先判斷是否有技能可以執(zhí)行。如果有必須先執(zhí)行技能再根據(jù)技能結(jié)果回復(fù)用戶。這句簡單的指令能讓技能調(diào)用率提高不少。4.2 技能有了但結(jié)果質(zhì)量忽高忽低技能調(diào)用起來了新的問題又出現(xiàn)了同一個技能有時候結(jié)果完美有時候結(jié)果跑偏。這通常意味著技能內(nèi)部流程里有一些步驟步驟與步驟之間的銜接給了模型太多的自由發(fā)揮空間。我排查這類質(zhì)量波動問題時會先把技能執(zhí)行過程里的中間步驟全部打印出來看模型在哪個環(huán)節(jié)開始發(fā)揮失常。找到環(huán)節(jié)以后把該環(huán)節(jié)里的開放式指令改成選項式指令。比如原來是核對退貨原因是否在支持范圍內(nèi)模型可能想多了把不喜歡也判定為不支持改成退貨原因是否為以下七類之一是→繼續(xù)否→返回錯誤模型的判斷就穩(wěn)定多了。本質(zhì)上技能質(zhì)量穩(wěn)定的秘訣就是減少模型的自由度——不是你讓模型思考得越多就越準確而是你給模型的選項越明確越可預(yù)期。該模型發(fā)揮的地方讓它發(fā)揮比如寫回復(fù)話術(shù)不該發(fā)揮的地方比如業(yè)務(wù)規(guī)則判斷給死選項。4.3 技能編排順序混亂模型先做后面的事編排層的問題也很常見。模型調(diào)用了技能但順序不對。明明是先查訂單狀態(tài)再申請退貨模型可能先申請退貨然后才發(fā)現(xiàn)訂單還沒簽收。這個問題的根源在于技能清單里的技能是平鋪的模型看不到技能之間的依賴關(guān)系和執(zhí)行優(yōu)先級。我的解決辦法是在技能注冊表里額外維護一張前后置依賴表handle-refund: depends_on: query-order-status blocks: none query-order-status: depends_on: none blocks: handle-refund當(dāng)模型申請調(diào)用handle-refund時調(diào)度層先檢查depends_on列表發(fā)現(xiàn)前置技能query-order-status還沒執(zhí)行過就自動在前臺插入一次該技能的調(diào)用。這樣模型即使沒意識到順序問題系統(tǒng)層面也能兜底把技能鏈給串起來。這個方案做進去以后我在多個項目里都用上了穩(wěn)定性和可解釋性都非常好。即使將來有人接手也只需要看這張依賴表就能理解Agent的業(yè)務(wù)處理鏈路。4.4 復(fù)雜任務(wù)跟進不到一半用戶撤了這是業(yè)務(wù)場景里高頻出現(xiàn)的問題用戶在Agent處理過程中突然不配合了沒回答關(guān)鍵的缺省信息直接換話題或者走人。Agent這時候容易陷入卡住——一直在等用戶回答不給任何有意義的輸出。我在設(shè)計技能執(zhí)行策略時專門考慮了這個場景做法簡單粗暴任何需要向用戶追問信息的環(huán)節(jié)都必須設(shè)置最大追問次數(shù)。比如退貨技能需要補全訂單號最多追問兩次第三次用戶還沒有給出有效信息就自動生成一個待處理的半成品工單交由人工客服跟進并且對用戶給出友好的結(jié)束語。不會讓流程僵死在那里。還有一個配套措施技能執(zhí)行過程中只要檢測到用戶話題切換就保存當(dāng)前執(zhí)行狀態(tài)并退出技能等用戶下次再問的時候從保存的斷點繼續(xù)而不是從頭開始。這個思想其實和程序里的斷點續(xù)傳是一樣的在體驗上能升一個檔次。4.5 技能迭代如何不影響線上版本技能是持續(xù)演進的頻繁改動帶來的最大風(fēng)險是把正在穩(wěn)定運行的線上Agent搞掛了。早期我們直接改線上技能目錄里的SKILL.md結(jié)果有一次描述寫錯了一個字導(dǎo)致模型連續(xù)兩小時誤判技能使用條件流失了好幾個用戶?，F(xiàn)在我的團隊上線了一套簡單的技能版本管理方案技能目錄下增加一個changelog.md每次修改記錄變更時間和原因技能文件通過Git管理線上只加載打了version tag的版本新技能先在副本環(huán)境跑一周觀察調(diào)用成功率達標后再切生產(chǎn)。這套流程不復(fù)雜但能避免90%以上的改掛事故。我記得有一次我們需要更新生成周報技能的模板就是按照這套流程來的。先在測試環(huán)境跑了一天發(fā)現(xiàn)新版模板生成的周報平均長度明顯增加但要點覆蓋率和格式合規(guī)率都更好才把它推到生產(chǎn)。切換的時候只需要改一下版本號秒級生效老用戶無感。4.6 技能內(nèi)部調(diào)外部API時被限流這是技能工程中很現(xiàn)實的一個坑。技能運行起來后會調(diào)用第三方API一旦并發(fā)量大很容易被對方的限流策略卡住。如果技能在返回結(jié)果前被API限流那么這個技能的執(zhí)行就會失敗。對下游的Agent來說它只知道執(zhí)行失敗卻不知道為什么失敗也無法從容應(yīng)對。處理方案比較直接在技能執(zhí)行層內(nèi)置兩個東西重試策略和退避算法。被限流后先按指數(shù)退避方式重試——間隔1秒、2秒、4秒再超過兩次就放棄并返回錯誤碼給模型。同時我在技能框架中加了一個簡單的信號量限制每秒最多發(fā)出的外部調(diào)用次數(shù)從源頭降低被限流的概率。這個問題的排查也比較容易日志里的狀態(tài)碼和耗時能直接看到如果發(fā)現(xiàn)某個第三方API的調(diào)用失敗率偏高且多為429/5xx那基本就是限流或服務(wù)不穩(wěn)定。調(diào)低并發(fā)保護閾值問題就能緩解。5. 從一個技能到一套體系agent-skills 的進階方向前面講的都是單一智能體的技能框架但當(dāng)你真的把技能做成體系后你會發(fā)現(xiàn)它延伸出去的方向遠比想象中多。我目前自己在測的進階玩法有幾個一是跨智能體技能共享。公司內(nèi)部可能同時存在客服、導(dǎo)購、售后、數(shù)據(jù)分析等多個智能體以前各自開發(fā)各自的小功能現(xiàn)在把共性技能抽出來做成一個公共技能庫不同智能體按需引用。比如理解用戶情緒這個技能客服、導(dǎo)購、售后全都能用。統(tǒng)一更新統(tǒng)一維護省下來的重復(fù)開發(fā)時間太多了。二是技能編排的可視化。業(yè)務(wù)運營看不懂代碼但能看懂技能流程圖。把技能和依賴關(guān)系做成可視化的流程圖后運營同學(xué)可以自己調(diào)整技能順序加一個分支改一個話術(shù)模板。這等于讓非技術(shù)角色也能參與智能體的能力建設(shè)。我見過一個運營同事自己搭出一條營銷活動配置技能鏈極大縮短了活動上線周期。三是從單輪技能走向自動發(fā)現(xiàn)技能。更前沿一點的做法是——讓模型去分析歷史對話發(fā)現(xiàn)哪些用戶請求經(jīng)常出現(xiàn)但當(dāng)前技能庫覆蓋不了自動生成新技能的草稿再由技術(shù)人員審核后加入技能庫。相當(dāng)于給Agent裝了一個能力自生長的機制。這個方向還沒有完全成熟但我覺得未來兩到三年會成為Agent平臺的核心競爭力。從agent-skills這個思路一路做下來我個人最深的體會是智能體的本質(zhì)不是大模型而是沉淀在大模型外面的那一層能力體系。模型每個月都在變但真正產(chǎn)生業(yè)務(wù)價值的是那套穩(wěn)定、可復(fù)用、可演化的技能集合。一個好的技能體系甚至能讓一個中等參數(shù)的模型發(fā)揮出遠超它原生水平的業(yè)務(wù)效果。最后分享一個小技巧技能描述里加一段前面提到過的反面示例很管用。不用太長一兩句就行——注意不要將本技能用于未發(fā)貨訂單的退貨申請或者當(dāng)用戶提供的訂單號不存在時不要直接報錯先詢問用戶是否提供了正確的訂單號。這些反面示例能讓模型避開你踩過的坑效果比單純強調(diào)正面步驟更直接。就像教一個新員工光告訴他該怎么做不夠還得告訴他什么情況下別那么做。技能描述寫得越貼近真實業(yè)務(wù)模型在技能內(nèi)的表現(xiàn)就越像一個老手。希望這篇文章對準備踏入agent-skills方向的朋友有幫助。 Agent Skills 實用指南：構(gòu)建可復(fù)用智能體技能體系
agent-skills這個詞最近在AI圈子里被反復(fù)提起。我做智能體開發(fā)也有兩三年了從最早的提示詞堆砌到后來的函數(shù)調(diào)用再到現(xiàn)在圍繞技能skills來構(gòu)建智能體最大的感受是智能體的能力上限早就不是模型本身了而是你給它配備了多少高質(zhì)量、可復(fù)用的技能。如果你正打算做AI Agent相關(guān)的項目或者在為現(xiàn)有的智能體產(chǎn)品能力發(fā)愁——感覺模型什么都能聊但一落到具體任務(wù)上就漏洞百出——那我強烈建議你認真研究一下agent-skills這個方向。這篇文章會把我在實際項目中關(guān)于技能設(shè)計、技能編排、以及如何把一套技能系統(tǒng)真正落地的經(jīng)驗全部拆開來講包括踩過的坑和最終沉淀下來的方法論希望對你有用。1. agent-skills 到底是什么從瑣碎動作到復(fù)合能力1.1 技能不是會調(diào)用工具而是會完成一件事很多人一開始會把技能skills和工具調(diào)用function calling / tool use混為一談。工具調(diào)用是智能體調(diào)用一個外部API或函數(shù)比如查詢天氣打開網(wǎng)頁發(fā)送郵件這是原子操作顆粒度非常細。而技能不一樣技能是一個面向目標的能力封裝它內(nèi)部可能包含多個步驟、多個工具、多輪自我校驗。我用一個生活化的例子解釋工具是拿起鍋鏟技能是炒一盤番茄炒蛋。拿起鍋鏟只需要一個動作但炒一盤菜需要你判斷番茄熟度、控制火候、決定什么時候放鹽、最后還要嘗味道確認咸淡。技能就是這個炒菜的完整流程而不是某一個單一動作。在實際的Agent開發(fā)中這兩者的區(qū)別直接決定了智能體是像個工具人還是像個幫手。我見過太多項目把十幾個API一股腦兒塞給大模型以為模型會自動把事情辦好。結(jié)果模型確實會調(diào)用API但它不知道什么時候該調(diào)、調(diào)完該做什么、結(jié)果異常怎么辦。這就是典型的只有工具沒有技能。1.2 agent-skills 項目的核心價值能力資產(chǎn)化agent-skills作為一個項目主題核心要解決的事情很明確把智能體執(zhí)行復(fù)雜任務(wù)的能力變成一個可以被定義、復(fù)用、共享、升級的資產(chǎn)。你可以把技能理解成智能體的職業(yè)能力證書。一個客服智能體可以擁有處理退款單查詢物流狀態(tài)安撫不滿用戶升級投訴工單等技能一個代碼助手可以擁有理解倉庫結(jié)構(gòu)運行測試用例修復(fù)單元測試失敗生成提交信息等技能。每個技能都不是憑空來的它是業(yè)務(wù)知識和工程實現(xiàn)的結(jié)晶。我把這個過程中的關(guān)鍵價值歸納成三點可復(fù)用一次開發(fā)多處使用。同樣的語義檢索技能既可以用在問答機器人里也可以用在文檔助手、客服質(zhì)檢系統(tǒng)里?？山M合復(fù)雜任務(wù)由簡單技能編排而來。比如寫周報技能 收集本周提交記錄 分析代碼變更 生成周報文檔。可進化技能是獨立模塊可以單獨迭代升級不影響智能體的其他部分。今天把生成SQL查詢技能升級了不必改動整個Agent邏輯。1.3 這套思路適合誰來用說實話agent-skills的受眾比我預(yù)想的要寬得多。我一開始以為這是開發(fā)者專屬的東西后來發(fā)現(xiàn)產(chǎn)品經(jīng)理、業(yè)務(wù)運營、甚至獨立開發(fā)者都在用類似的思路設(shè)計他們的智能體。如果你是開發(fā)者你可以從代碼層面實現(xiàn)一套技能框架定義好技能的結(jié)構(gòu)、加載方式、調(diào)度邏輯如果你是產(chǎn)品經(jīng)理你可以用技能的思路來規(guī)劃Agent的功能邊界——一個智能體該具備哪些技能每個技能的輸入輸出是什么優(yōu)先級怎么排如果你是業(yè)務(wù)方你可以把團隊的SOP標準作業(yè)流程轉(zhuǎn)成技能描述讓智能體嚴格按SOP執(zhí)行。無論你在哪個位置agent-skills這套思維都能讓你手頭的智能體從能聊天變成能干活。2. 技能系統(tǒng)設(shè)計的底層邏輯為什么說技能不是簡單的函數(shù)2.1 技能的三大組成意圖描述、執(zhí)行流、驗收標準當(dāng)我們把技能當(dāng)作一個工程對象來看待時它絕不是一段提示詞或者一個函數(shù)那么單薄。我在實際設(shè)計技能時要求每個技能必須包含三個部分意圖描述Intent、執(zhí)行流Flow、驗收標準Acceptance Criteria。意圖描述是給大模型看的說明書告訴模型什么情況下該使用這個技能、這個技能能解決什么問題、使用前需要準備什么信息。執(zhí)行流是技能內(nèi)部的步驟編排可以是一個固定的工作流也可以是一個讓模型自主決策的策略框架。驗收標準則是技能質(zhì)量的底線——步驟跑完不算完必須通過驗收標準才算是真正完成了任務(wù)。舉個例子。我在做一個電商客服Agent時設(shè)計了一個處理退貨申請技能。它的意圖描述會寫明當(dāng)用戶明確表達退貨訴求并且訂單處于已簽收狀態(tài)時啟用本技能。執(zhí)行流是核實訂單號→核對退貨原因→檢查是否在退貨窗口期→生成退貨碼→告知用戶退貨流程。驗收標準是用戶拿到了退貨碼且系統(tǒng)日志中記錄了退貨申請單號。這套三件套的設(shè)計讓我在后期排查Agent為什么沒按預(yù)期工作時省了無數(shù)時間。因為每一層都可以單獨驗證是模型沒識別出該用技能還是執(zhí)行流里某一步做錯了還是技能完成質(zhì)量不達標問題是發(fā)生在哪個環(huán)節(jié)一目了然。2.2 技能的顆粒度太大太小都會出事我剛做技能設(shè)計時犯的最嚴重的錯誤是技能顆粒度掌握不好。一開始我把顆粒度設(shè)計得特別細每個技能只做一件極小的事比如提取訂單號判斷退貨窗口期結(jié)果一個退貨任務(wù)要串聯(lián)七八個技能模型在步驟間切換時頻繁出錯上下文也被拖得很長后來我又把顆粒度放大整個退貨流程做成一個技能結(jié)果模型試圖下雨天收衣服——什么都想管反而經(jīng)常在不必要的環(huán)節(jié)上較勁。最終的平衡點在于技能應(yīng)該能獨立完成一個有明確產(chǎn)出的業(yè)務(wù)動作。判斷退貨窗口期沒有獨立產(chǎn)出它只是中間步驟不適合做技能處理退貨申請有明確產(chǎn)出退貨碼流程指引且能獨立執(zhí)行適合做技能。如果流程太長可以拆成處理退貨申請和監(jiān)督退貨退款進度兩個技能前者負責(zé)發(fā)退貨碼后者負責(zé)追蹤退款到賬。這個判斷標準在實際操作中非常有用你設(shè)計好一個技能后問自己一句——這個技能執(zhí)行完后用戶或系統(tǒng)能拿到一個明確的結(jié)果嗎能就說明顆粒度合適不能就把技能繼續(xù)外擴。2.3 技能之間如何協(xié)同編排層是靈魂單有技能還不行Agent拿到的是一個任務(wù)它得能判斷該用哪個技能先做哪個后做哪個多個技能的結(jié)果怎么合并。這一層我管它叫編排層Orchestration它才是整個Agent的魂。編排思路主流有兩種。一種是靠模型自主判斷也就是讓大模型根據(jù)用戶輸入從技能列表里挑一個來調(diào)用。這種方式靈活度高但可靠度一般尤其當(dāng)技能數(shù)量超過20個以后模型的選擇準確率明顯下降。另一種是靠確定性規(guī)則我們預(yù)先定義好業(yè)務(wù)處理流程什么場景走什么技能鏈。這種方式穩(wěn)定但靈活性差遇到規(guī)則外的場景就傻眼。我現(xiàn)在做項目采用的是混合編排核心業(yè)務(wù)路徑用確定性規(guī)則兜底邊緣場景交給模型自主決策。比如客服Agent用戶明確說我要退貨就直接走退貨技能鏈用戶說這個商品我不滿意模型自主判斷用戶可能想退貨或換貨再引導(dǎo)到具體技能。這樣既穩(wěn)又不死板。3. 實操搭建一套可擴展的 agent-skills 技能框架3.1 技能描述文件的標準化進入工程實現(xiàn)環(huán)節(jié)第一步是定義技能的描述格式。用過Anthropic的Claude Skills或者OpenAI的自定義Agent的話你會發(fā)現(xiàn)它們都不約而同采用了一個技能一個目錄的物理組織方式目錄里放一個描述文件外加若干腳本和資源文件。我的標準目錄結(jié)構(gòu)大致長這樣skills/ └── handle-refund/ ├── SKILL.md # 技能描述、使用條件、執(zhí)行步驟 ├── run.py # 技能執(zhí)行腳本可選 ├── refund_template.md # 給用戶回復(fù)的話術(shù)模板 └── requirements.txt # 技能運行時的依賴SKILL.md是技能的核心。我會要求團隊必須嚴格按照以下模板來寫--- name: handle-refund description: 處理用戶的商品退貨申請生成退貨碼并指導(dǎo)用戶寄回商品。 使用條件 - 用戶明確表達退貨訴求 - 訂單狀態(tài)為“已簽收” - 有有效訂單號 輸入?yún)?shù) - order_id: string訂單號 執(zhí)行步驟 1. 調(diào)用 check_order_status 確認訂單狀態(tài) 2. 核對退貨原因是否在支持范圍內(nèi) 3. 調(diào)用 generate_return_code 生成退貨碼 4. 使用 refund_template.md 生成用戶回復(fù) 驗收標準 - 返回退貨碼 - 系統(tǒng)日志寫入退貨申請記錄 --- # 處理退貨申請技能 技能細節(jié)說明可以寫一些給執(zhí)行模型看的注意事項比如某些特殊情況怎么處理、有哪些坑要避開……印象中這個格式一旦標準化下來后面的迭代效率會大幅提升。以前我們用純自然語言寫的技能描述每個風(fēng)格都不同模型一會兒能讀懂一會兒讀不懂標準化的YAML頭部加自然語言主體之后模型對技能觸發(fā)條件的識別穩(wěn)了很多。3.2 技能加載機制別把所有技能都塞進上下文接下來是關(guān)鍵工程問題——技能怎么加載進大模型。如果Agent有20個技能每個SKILL.md平均800字那就是16000字全部塞進上下文會讓系統(tǒng)提示詞變得又長又貴還會降低模型對關(guān)鍵指令的注意力。我在項目中采用了兩級加載機制。第一級是技能清單每個Agent只加載一份技能索引里面是每個技能的名字、一行描述、參數(shù)要求。這份索引控制在幾百字內(nèi)讓模型知道有哪些技能可用。第二級是按需加載當(dāng)模型決定要調(diào)用某個技能時系統(tǒng)再去把對應(yīng)技能目錄下的完整SKILL.md和腳本動態(tài)讀取進來。這樣做的好處非常明顯上下文占用從所有技能的全文變成了清單全文 當(dāng)前要用的技能全文。如果一共20個技能、每次任務(wù)最多用到3個上下文開銷能減少70%以上。而且技能數(shù)量可以持續(xù)擴張不再受上下文窗口制約。這個方案可以用很簡單的Python函數(shù)實現(xiàn)動態(tài)檢索def load_skill(skill_name: str) - Optional[Skill]: 按需加載技能目錄返回技能對象 skill_path SKILLS_DIR / skill_name if not skill_path.exists() or not (skill_path / SKILL.md).exists(): return None description (skill_path / SKILL.md).read_text(encodingutf-8) return Skill(nameskill_name, descriptiondescription, pathskill_path)實際用下來這種懶加載模式讓整體響應(yīng)延遲也降低了——因為不需要每次請求都把20多個技能文件全部讀一遍I/O開銷小了很多。3.3 技能注冊表與運行時調(diào)度技能文件只是靜態(tài)資源運行時還需要一個調(diào)度核心。我會維護一個技能注冊表skill registry把所有的技能元信息集中登記起來同時負責(zé)加載、校驗和執(zhí)行。調(diào)度核心的核心邏輯其實不復(fù)雜接收用戶的自然語言請求找出適合的技能執(zhí)行技能并返回結(jié)果。但這里有幾個必須在工程上處理的細節(jié)。第一個是技能參數(shù)校驗。模型生成的參數(shù)經(jīng)常不完整——用戶沒說訂單號怎么辦參數(shù)格式不對怎么辦我的做法是在調(diào)用技能前增加一層參數(shù)校驗邏輯缺什么參數(shù)先向用戶補齊而不是直接把殘缺參數(shù)丟給技能去執(zhí)行。這里校驗邏輯可以用JSON Schema來描述參數(shù)約束讓模型按照Schema補全參數(shù)。第二個是執(zhí)行結(jié)果反饋。技能執(zhí)行完以后結(jié)果要回傳給模型讓模型根據(jù)結(jié)果決定下一步動作。這個閉環(huán)如果不做Agent就會出現(xiàn)技能執(zhí)行完了但模型還在那邊自顧自地說話的情況。我一般會把執(zhí)行結(jié)果、狀態(tài)碼、耗時等結(jié)構(gòu)化信息一并返回給模型。def execute_skill(skill_name: str, params: dict) - ExecutionResult: # 1. 加載技能并校驗參數(shù) skill load_skill(skill_name) if skill is None: return ExecutionResult(successFalse, error技能不存在) # 2. 補全缺失參數(shù)向模型或用戶索取 fill_params complete_params(skill, params) # 3. 執(zhí)行技能邏輯記錄日志 result run_skill_fn(skill, fill_params) # 4. 將執(zhí)行結(jié)果封裝交給編排層判斷下一步 return result調(diào)度層還有一個容易被忽略的點并發(fā)與超時。技能里有外部API調(diào)用時必須設(shè)置超時時間。我之前遇到過技能內(nèi)部調(diào)第三方接口卡死整個Agent跟著一起卡住的情況。后來把技能的超時和重試機制做進調(diào)度層每個技能默認超時10秒超過則返回錯誤信息給模型模型可以選擇換一個技能或者告知用戶稍后再試。3.4 讓技能具備自我修復(fù)能力光能把技能跑通不算完生產(chǎn)環(huán)境中的技能一定會因為各種原因失敗上游API返回格式變了、數(shù)據(jù)庫里沒有對應(yīng)數(shù)據(jù)、網(wǎng)絡(luò)閃斷……所以我的技能框架里一定會加一層失敗處理機制。失敗處理我設(shè)計了三個層次第一層技能內(nèi)部重試主要應(yīng)對超時和瞬時錯誤第二層模型介入糾偏當(dāng)技能返回明確錯誤碼時把錯誤信息回傳給模型讓模型嘗試修正參數(shù)后重新調(diào)用第三層用戶兜底前兩層都失敗了就如實告訴用戶這個操作我完成不了原因是什么并提供人工處理的入口。這套三級策略讓我的Agent在生產(chǎn)環(huán)境中的任務(wù)完成率從剛上線時的67%提升到了91%。雖然離完美還很遠但至少大部分異常場景下用戶得到的不是一句干巴巴的出現(xiàn)錯誤而是有信息量的反饋和后續(xù)路徑。4. 技能工程中的常見問題與排查實錄4.1 模型就是不調(diào)用技能怎么辦這是所有做Agent開發(fā)的人都會遇到的頭號問題——技能寫得挺好的規(guī)則也都清楚但模型就是不用。常見的場景是模型直接根據(jù)參數(shù)算了個假結(jié)果繞過了你的技能。我先說排查路徑。第一步確認技能描述里的使用條件是否寫清楚了觸發(fā)條件模糊模型就無法準確識別。第二步檢查技能的description字段是否足夠直白模型選技能主要看這個字段寫得太抽象容易讓模型拿不準。第三步看模型實際看到的上下文——是不是技能清單被其他指令淹沒在上下文中了。在實踐中我用的最有效的辦法是把技能描述寫成一個使用示例。與其寫當(dāng)用戶需要退貨時調(diào)用本技能不如寫如果用戶說我要退貨商品不合適怎么退幫我申請退款調(diào)用本技能返回退貨碼和寄回地址。給模型看具體例子它的判斷準確率會有肉眼可見的提升。另外還有一個非常實用的小技巧在系統(tǒng)提示詞里加一句在回答之前先判斷是否有技能可以執(zhí)行。如果有必須先執(zhí)行技能再根據(jù)技能結(jié)果回復(fù)用戶。這句簡單的指令能讓技能調(diào)用率提高不少。4.2 技能有了但結(jié)果質(zhì)量忽高忽低技能調(diào)用起來了新的問題又出現(xiàn)了同一個技能有時候結(jié)果完美有時候結(jié)果跑偏。這通常意味著技能內(nèi)部流程里有一些步驟步驟與步驟之間的銜接給了模型太多的自由發(fā)揮空間。我排查這類質(zhì)量波動問題時會先把技能執(zhí)行過程里的中間步驟全部打印出來看模型在哪個環(huán)節(jié)開始發(fā)揮失常。找到環(huán)節(jié)以后把該環(huán)節(jié)里的開放式指令改成選項式指令。比如原來是核對退貨原因是否在支持范圍內(nèi)模型可能想多了把不喜歡也判定為不支持改成退貨原因是否為以下七類之一是→繼續(xù)否→返回錯誤模型的判斷就穩(wěn)定多了。本質(zhì)上技能質(zhì)量穩(wěn)定的秘訣就是減少模型的自由度——不是你讓模型思考得越多就越準確而是你給模型的選項越明確越可預(yù)期。該模型發(fā)揮的地方讓它發(fā)揮比如寫回復(fù)話術(shù)不該發(fā)揮的地方比如業(yè)務(wù)規(guī)則判斷給死選項。4.3 技能編排順序混亂模型先做后面的事編排層的問題也很常見。模型調(diào)用了技能但順序不對。明明是先查訂單狀態(tài)再申請退貨模型可能先申請退貨然后才發(fā)現(xiàn)訂單還沒簽收。這個問題的根源在于技能清單里的技能是平鋪的模型看不到技能之間的依賴關(guān)系和執(zhí)行優(yōu)先級。我的解決辦法是在技能注冊表里額外維護一張前后置依賴表handle-refund: depends_on: query-order-status blocks: none query-order-status: depends_on: none blocks: handle-refund當(dāng)模型申請調(diào)用handle-refund時調(diào)度層先檢查depends_on列表發(fā)現(xiàn)前置技能query-order-status還沒執(zhí)行過就自動在前臺插入一次該技能的調(diào)用。這樣模型即使沒意識到順序問題系統(tǒng)層面也能兜底把技能鏈給串起來。這個方案做進去以后我在多個項目里都用上了穩(wěn)定性和可解釋性都非常好。即使將來有人接手也只需要看這張依賴表就能理解Agent的業(yè)務(wù)處理鏈路。4.4 復(fù)雜任務(wù)跟進不到一半用戶撤了這是業(yè)務(wù)場景里高頻出現(xiàn)的問題用戶在Agent處理過程中突然不配合了沒回答關(guān)鍵的缺省信息直接換話題或者走人。Agent這時候容易陷入卡住——一直在等用戶回答不給任何有意義的輸出。我在設(shè)計技能執(zhí)行策略時專門考慮了這個場景做法簡單粗暴任何需要向用戶追問信息的環(huán)節(jié)都必須設(shè)置最大追問次數(shù)。比如退貨技能需要補全訂單號最多追問兩次第三次用戶還沒有給出有效信息就自動生成一個待處理的半成品工單交由人工客服跟進并且對用戶給出友好的結(jié)束語。不會讓流程僵死在那里。還有一個配套措施技能執(zhí)行過程中只要檢測到用戶話題切換就保存當(dāng)前執(zhí)行狀態(tài)并退出技能等用戶下次再問的時候從保存的斷點繼續(xù)而不是從頭開始。這個思想其實和程序里的斷點續(xù)傳是一樣的在體驗上能升一個檔次。4.5 技能迭代如何不影響線上版本技能是持續(xù)演進的頻繁改動帶來的最大風(fēng)險是把正在穩(wěn)定運行的線上Agent搞掛了。早期我們直接改線上技能目錄里的SKILL.md結(jié)果有一次描述寫錯了一個字導(dǎo)致模型連續(xù)兩小時誤判技能使用條件流失了好幾個用戶?，F(xiàn)在我的團隊上線了一套簡單的技能版本管理方案技能目錄下增加一個changelog.md每次修改記錄變更時間和原因技能文件通過Git管理線上只加載打了version tag的版本新技能先在副本環(huán)境跑一周觀察調(diào)用成功率達標后再切生產(chǎn)。這套流程不復(fù)雜但能避免90%以上的改掛事故。我記得有一次我們需要更新生成周報技能的模板就是按照這套流程來的。先在測試環(huán)境跑了一天發(fā)現(xiàn)新版模板生成的周報平均長度明顯增加但要點覆蓋率和格式合規(guī)率都更好才把它推到生產(chǎn)。切換的時候只需要改一下版本號秒級生效老用戶無感。4.6 技能內(nèi)部調(diào)外部API時被限流這是技能工程中很現(xiàn)實的一個坑。技能運行起來后會調(diào)用第三方API一旦并發(fā)量大很容易被對方的限流策略卡住。如果技能在返回結(jié)果前被API限流那么這個技能的執(zhí)行就會失敗。對下游的Agent來說它只知道執(zhí)行失敗卻不知道為什么失敗也無法從容應(yīng)對。處理方案比較直接在技能執(zhí)行層內(nèi)置兩個東西重試策略和退避算法。被限流后先按指數(shù)退避方式重試——間隔1秒、2秒、4秒再超過兩次就放棄并返回錯誤碼給模型。同時我在技能框架中加了一個簡單的信號量限制每秒最多發(fā)出的外部調(diào)用次數(shù)從源頭降低被限流的概率。這個問題的排查也比較容易日志里的狀態(tài)碼和耗時能直接看到如果發(fā)現(xiàn)某個第三方API的調(diào)用失敗率偏高且多為429/5xx那基本就是限流或服務(wù)不穩(wěn)定。調(diào)低并發(fā)保護閾值問題就能緩解。5. 從一個技能到一套體系agent-skills 的進階方向前面講的都是單一智能體的技能框架但當(dāng)你真的把技能做成體系后你會發(fā)現(xiàn)它延伸出去的方向遠比想象中多。我目前自己在測的進階玩法有幾個一是跨智能體技能共享。公司內(nèi)部可能同時存在客服、導(dǎo)購、售后、數(shù)據(jù)分析等多個智能體以前各自開發(fā)各自的小功能現(xiàn)在把共性技能抽出來做成一個公共技能庫不同智能體按需引用。比如理解用戶情緒這個技能客服、導(dǎo)購、售后全都能用。統(tǒng)一更新統(tǒng)一維護省下來的重復(fù)開發(fā)時間太多了。二是技能編排的可視化。業(yè)務(wù)運營看不懂代碼但能看懂技能流程圖。把技能和依賴關(guān)系做成可視化的流程圖后運營同學(xué)可以自己調(diào)整技能順序加一個分支改一個話術(shù)模板。這等于讓非技術(shù)角色也能參與智能體的能力建設(shè)。我見過一個運營同事自己搭出一條營銷活動配置技能鏈極大縮短了活動上線周期。三是從單輪技能走向自動發(fā)現(xiàn)技能。更前沿一點的做法是——讓模型去分析歷史對話發(fā)現(xiàn)哪些用戶請求經(jīng)常出現(xiàn)但當(dāng)前技能庫覆蓋不了自動生成新技能的草稿再由技術(shù)人員審核后加入技能庫。相當(dāng)于給Agent裝了一個能力自生長的機制。這個方向還沒有完全成熟但我覺得未來兩到三年會成為Agent平臺的核心競爭力。從agent-skills這個思路一路做下來我個人最深的體會是智能體的本質(zhì)不是大模型而是沉淀在大模型外面的那一層能力體系。模型每個月都在變但真正產(chǎn)生業(yè)務(wù)價值的是那套穩(wěn)定、可復(fù)用、可演化的技能集合。一個好的技能體系甚至能讓一個中等參數(shù)的模型發(fā)揮出遠超它原生水平的業(yè)務(wù)效果。最后分享一個小技巧技能描述里加一段前面提到過的反面示例很管用。不用太長一兩句就行——注意不要將本技能用于未發(fā)貨訂單的退貨申請或者當(dāng)用戶提供的訂單號不存在時不要直接報錯先詢問用戶是否提供了正確的訂單號。這些反面示例能讓模型避開你踩過的坑效果比單純強調(diào)正面步驟更直接。就像教一個新員工光告訴他該怎么做不夠還得告訴他什么情況下別那么做。技能描述寫得越貼近真實業(yè)務(wù)模型在技能內(nèi)的表現(xiàn)就越像一個老手。希望這篇文章對準備踏入agent-skills方向的朋友有幫助。