這個(gè)系列寫到第 10 期我發(fā)現(xiàn)一個(gè)特別常見的現(xiàn)象很多朋友已經(jīng)能熟練地寫提示詞也跑通了檢索增強(qiáng)生成可一旦要讓大模型“真正把一件事辦成”就卡住了。聊天流利辦事拉胯。問題通常不在模型本身而是缺了一層叫Agent Skills智能體技能的東西。簡單說技能就是把某一類任務(wù)的專業(yè)做法打包成一個(gè)可調(diào)用、可復(fù)用、可量化的執(zhí)行單元讓大模型在對話過程中按需調(diào)用。它解決的不只是“模型會說什么”而是“模型能做什么”。這一期我不打算泛泛講概念而是從調(diào)用現(xiàn)成技能、自定義技能到性能優(yōu)化和安全加固的完整鏈路把 Agent Skills 從入門到進(jìn)階一次講透。如果你已經(jīng)會寫基本的提示詞也了解大模型 API 的調(diào)用方式這篇內(nèi)容可以直接落地到你的項(xiàng)目里。1. Agent 技能層為什么大模型有了對話能力還不夠1.1 從“能聊天”到“能辦事”的關(guān)鍵一躍大模型本質(zhì)上是一個(gè)概率語言模型它最擅長的是把文字接得通順、接得像樣。但它天生不具備穩(wěn)定執(zhí)行外部操作的能力——它不會真的去查數(shù)據(jù)庫不會真的去發(fā) HTTP 請求也不會真的去操作系統(tǒng)里的文件。為了防止它“亂來”多數(shù)場景下我們限制它只能輸出文本。可一旦你希望大模型變成一個(gè)能完成實(shí)際工作的智能體就必須給它外掛一套“可執(zhí)行的手腳”這就是技能層存在的意義。我常拿新入職員工打比方一個(gè)名校畢業(yè)生大模型腦子聰明、表達(dá)清晰但沒經(jīng)過崗位培訓(xùn)他不知道你們公司內(nèi)部系統(tǒng)怎么操作不知道報(bào)銷流程怎么走也不知道數(shù)據(jù)庫里哪張表才是最新的。技能層就是給他的一本本“崗位 SOP”——每一份 SOP 對應(yīng)一個(gè)具體場景寫明“當(dāng)遇到某類需求時(shí)按這個(gè)流程去做輸入輸出長什么樣”。所以 Agent 和普通聊天機(jī)器人的分水嶺就在這里普通聊天機(jī)器人只有語言能力而 Agent 在語言能力之外還有一個(gè)“可操作的工具箱”并且能根據(jù)當(dāng)前任務(wù)自主決定打開哪個(gè)箱子。1.2 技能、工具、插件這套概念到底怎么分現(xiàn)在各家平臺都喜歡包裝新詞工具Tool、技能Skill、插件Plugin、函數(shù)調(diào)用Function Calling經(jīng)常被混著說。其實(shí)它們的本質(zhì)很接近但在工程上有細(xì)微差別理解清楚能避免后續(xù)設(shè)計(jì)走彎路。以下是基于當(dāng)前主流實(shí)現(xiàn)的一套相對清晰的區(qū)分方式概念核心含義典型形態(tài)側(cè)重點(diǎn)工具函數(shù)Tool / Function一個(gè)可以被模型調(diào)用、有明確輸入輸出定義的函數(shù)單個(gè)函數(shù)包含名稱、描述、參數(shù) Schema偏底層一個(gè)工具解決一個(gè)原子動作技能Skill一組工具 提示說明 執(zhí)行邏輯的封裝面向一個(gè)完整任務(wù)場景技能包含技能描述、多個(gè)工具、后處理邏輯偏任務(wù)層一個(gè)技能解決一類問題插件Plugin通常是某個(gè)外部服務(wù)/應(yīng)用接入能力的統(tǒng)一包裝REST API 規(guī)范、認(rèn)證方式、調(diào)用清單偏集成層強(qiáng)調(diào)與外部系統(tǒng)的連接也就是說技能通常是建立在工具之上的“組合拳”。一個(gè)技能內(nèi)部可以包含多個(gè)工具調(diào)用甚至包含一個(gè)小的決策流程。舉例來說“客戶信息查詢技能”可能內(nèi)部拆成“客戶 ID 解析”“訂單表查詢”“聯(lián)系方式查詢”三個(gè)工具但模型在外部看來只需要調(diào)用一個(gè)技能三條數(shù)據(jù)統(tǒng)一返回。理解這個(gè)分層的好處在于當(dāng)你要給 Agent 擴(kuò)展能力時(shí)優(yōu)先考慮“任務(wù)場景”而不是“單點(diǎn)功能”。很多初學(xué)者一開始就把所有能力拆成幾百個(gè)細(xì)小工具函數(shù)模型面對一長串工具列表會非常迷茫選擇困難、誤調(diào)用頻發(fā)而把相近功能組織成若干個(gè)高內(nèi)聚的技能模型的決策負(fù)擔(dān)會小很多。1.3 技能調(diào)用的完整生命周期一次執(zhí)行背后發(fā)生了什么一次技能調(diào)用從用戶提問到返回答案通常走這么幾步意圖解析模型讀取當(dāng)前對話判斷“用戶這個(gè)需求要不要動用技能”。技能選擇模型從可用的技能清單里挑選一個(gè)或多個(gè)匹配的標(biāo)準(zhǔn)通常來自“技能名稱 技能描述”。參數(shù)抽取模型把用戶自然語言里的關(guān)鍵信息填進(jìn)技能的輸入?yún)?shù)。這一步最容易出錯(cuò)比如用戶說“查一下上周華東區(qū)的訂單”模型需要把“上周”換算成具體日期把“華東區(qū)”映射成區(qū)域代碼。動作執(zhí)行Agent 運(yùn)行時(shí)接收到結(jié)構(gòu)化的調(diào)用指令真正去執(zhí)行對應(yīng)的工具函數(shù)或者 API。結(jié)果回填執(zhí)行結(jié)果成功或失敗被拼回上下文交給模型。最終應(yīng)答模型結(jié)合技能結(jié)果和原始問題組織出自然語言答案。你會發(fā)現(xiàn)這本質(zhì)上是一個(gè)“模型負(fù)責(zé)判斷和表達(dá)外部系統(tǒng)負(fù)責(zé)執(zhí)行”的閉環(huán)。每一個(gè)環(huán)節(jié)都可能成為瓶頸。比如參數(shù)抽取錯(cuò)了執(zhí)行肯定失敗技能描述寫得不清楚模型可能壓根不調(diào)用結(jié)果回填太長上下文一下就爆了。我們要做的所有優(yōu)化都圍繞這六步展開。2. 入門實(shí)操把現(xiàn)成技能接到你的 Agent 上2.1 先盤點(diǎn)一個(gè)團(tuán)隊(duì)里常用的技能長什么樣很多人第一次接觸技能以為必須自己寫。其實(shí)大多數(shù)成熟的 Agent 平臺和框架都會自帶一批現(xiàn)成技能你先學(xué)會“怎么用”比“怎么造”更重要。常見的現(xiàn)成技能包括代碼執(zhí)行技能模型動態(tài)生成 Python/JavaScript 代碼在沙箱里執(zhí)行直接跑完返回結(jié)果。適合數(shù)學(xué)計(jì)算、數(shù)據(jù)處理、文件轉(zhuǎn)換。網(wǎng)頁搜索技能把模型的問題轉(zhuǎn)成搜索詞去搜索引擎抓取摘要和鏈接再讓模型綜合出答案。文檔處理技能讀取上傳的 PDF、Word、Excel抽取指定頁面的內(nèi)容必要時(shí)做表格結(jié)構(gòu)還原。API 對接技能封裝企業(yè)內(nèi)部的訂單、CRM、人事系統(tǒng)等 HTTP 接口模型可以通過它查數(shù)據(jù)、發(fā)通知。這些技能的共性是它們都把“模型不擅長的確定性操作”外包給了外部執(zhí)行器。模型負(fù)責(zé)描述目標(biāo)技能負(fù)責(zé)精確完成。接入現(xiàn)成技能時(shí)你需要做的三件事是開通對應(yīng)服務(wù)的訪問權(quán)限、在配置里聲明技能參數(shù)、對技能返回結(jié)果設(shè)置合理的超時(shí)時(shí)間。2.2 最小接入示例從定義到執(zhí)行一步步來我用一個(gè)極簡的“單位換算技能”來演示最小接入流程。不管你是用哪家的 Agent 框架核心要素都是下面這些字段技能名稱、技能描述、輸入?yún)?shù)定義。{ name: unit_converter, description: 將長度、重量、溫度等數(shù)值在不同單位之間進(jìn)行換算。當(dāng)用戶詢問類似“5公里等于多少英里”時(shí)使用。, input_schema: { type: object, properties: { value: {type: number, description: 待換算的數(shù)值}, from_unit: {type: string, description: 原始單位}, to_unit: {type: string, description: 目標(biāo)單位} }, required: [value, from_unit, to_unit] } }接入時(shí)你把這段 Schema 和大模型的接口文件放在一起模型看到它就會在合適的時(shí)機(jī)輸出一個(gè)類似下面的調(diào)用指令{ action: unit_converter, parameters: { value: 5, from_unit: km, to_unit: mile } }你的后端只要識別到action字段就路由到對應(yīng)的換算函數(shù)執(zhí)行再把結(jié)果塞回給模型讓它繼續(xù)組織回答。這一步跑通了你就已經(jīng)具備 Agent Skills 的基礎(chǔ)能力了。這里我想強(qiáng)調(diào)一個(gè)容易忽略的細(xì)節(jié)description里那句“當(dāng)用戶詢問類似……”不是可有可無的廢話它直接影響模型會不會在合適的時(shí)機(jī)調(diào)用這個(gè)技能。描述越具體召喚準(zhǔn)確率越高。2.3 多技能編排一次任務(wù)調(diào)動三個(gè)技能的協(xié)作模型真實(shí)場景很少只用一個(gè)技能。比如用戶說“幫我總結(jié)一下今天郵件里提到的兩個(gè)項(xiàng)目并按優(yōu)先級生成待辦清單”這個(gè)需求至少牽涉郵件讀取、文本總結(jié)、待辦生成三個(gè)能力。多技能編排有兩種常見模式串行模式先調(diào)用 A拿到結(jié)果后喂給 B再把結(jié)果喂給 C。適合有明顯步驟依賴的任務(wù)。并行模式同時(shí)調(diào)用 A、B、C匯總各自結(jié)果后統(tǒng)一處理。適合互不依賴的多路信息獲取。編配時(shí)最關(guān)鍵的是“誰來決定調(diào)度順序”。我見過不少半成品把調(diào)度邏輯寫死在代碼里一旦用戶表述稍有變化就掛。更穩(wěn)妥的做法是讓模型先輸出一個(gè)“技能調(diào)用計(jì)劃”Agent 運(yùn)行時(shí)再根據(jù)計(jì)劃做并行或串行執(zhí)行。繼續(xù)拿上面那個(gè)例子來說模型可能會生成這樣的計(jì)劃調(diào)用email_reader解析今日未讀郵件得到正文調(diào)用project_extractor從正文中提取兩個(gè)項(xiàng)目的關(guān)鍵信息調(diào)用todo_generator根據(jù)信息生成待辦清單代碼里你只需要維護(hù)一個(gè)簡單的循環(huán)順著計(jì)劃逐步執(zhí)行每一步的返回結(jié)果放入共享上下文。這一套看起來簡單但非常實(shí)用足以解決 80% 的多技能協(xié)作場景。2.4 參數(shù)、超時(shí)與重試技能接入時(shí)的三個(gè)基本設(shè)置接入技能時(shí)有三個(gè)基礎(chǔ)參數(shù)我建議每個(gè)技能都要配置別偷懶。超時(shí)時(shí)間外部 API 請求很可能因?yàn)榫W(wǎng)絡(luò)或者服務(wù)端異常而卡住。不要設(shè)無限超時(shí)一般默認(rèn) 10-30 秒。代碼執(zhí)行類技能因?yàn)榭赡苡袕?fù)雜計(jì)算可以放寬到 60 秒但必須設(shè)上限。重試策略對于冪等的查詢類技能遇到超時(shí)或 HTTP 5xx 錯(cuò)誤可以自動重試一到兩次但對于“發(fā)郵件”“轉(zhuǎn)賬”“創(chuàng)建訂單”這類有副作用的操作重試必須極其謹(jǐn)慎否則可能產(chǎn)生重復(fù)動作。錯(cuò)誤返回格式技能執(zhí)行失敗后不要只返回一個(gè) HTTP 狀態(tài)碼應(yīng)該返回一段模型可以讀懂的錯(cuò)誤信息。比如“查詢超時(shí)數(shù)據(jù)庫連接池?zé)o空閑連接請稍后再試”。模型才能基于這段描述向用戶給出合理說明而不是硬編造一個(gè)結(jié)果。你會發(fā)現(xiàn)這三個(gè)設(shè)置本質(zhì)上都在處理同一個(gè)問題技能調(diào)用的不確定性。大模型天然不會穩(wěn)定地每次調(diào)用成功我們要用工程手段把失敗概率攤薄而不是默認(rèn)它一定成功。3. 進(jìn)階開發(fā)從零寫好一個(gè)自定義技能3.1 技能的三段式定義指令、Schema、執(zhí)行體現(xiàn)成技能用得很順之后你很快會遇到定制需求公司內(nèi)部的業(yè)務(wù)邏輯不可能有現(xiàn)成技能直接覆蓋。這時(shí)候就需要自己寫技能了。一個(gè)高質(zhì)量技能由三部分組成指令I(lǐng)nstruction/Description告訴模型這個(gè)技能是干什么的什么情況下該調(diào)用什么情況下不該調(diào)用。這是最容易因?yàn)椤皩懙锰獭睂?dǎo)致模型誤用的地方。Schema嚴(yán)格定義輸入輸出的結(jié)構(gòu)盡量做字段級說明。模型通過 Schema 來理解參數(shù)怎么填。執(zhí)行體Executor真正干活的代碼。它接收 Schema 里定義好的參數(shù)返回結(jié)構(gòu)化結(jié)果。一個(gè)常見誤區(qū)是很多人在指令里寫得很空比如“數(shù)據(jù)處理技能”對我見過就五個(gè)字然后抱怨模型總在不該觸發(fā)的時(shí)候觸發(fā)。你要記住模型看不到你的執(zhí)行體它只靠“技能名 描述 Schema”來做判斷。描述寫得不清楚就跟產(chǎn)品說明書缺失差不多。3.2 實(shí)戰(zhàn)我做了一個(gè)“數(shù)據(jù)周報(bào)整理技能”前幾天項(xiàng)目里有個(gè)需求每周要整理各個(gè)渠道的數(shù)據(jù)產(chǎn)出匯總成內(nèi)部分享的 Markdown 周報(bào)。原先都是人工復(fù)制粘貼我干脆把它做成了一個(gè)技能。先看技能描述部分我是這么寫的技能名稱weekly_report_writer 技能描述 當(dāng)用戶提供多段運(yùn)營數(shù)據(jù)或者要求“匯總周報(bào)”“整理本周數(shù)據(jù)報(bào)告”時(shí)使用。 它接收原始數(shù)據(jù)文本和匯報(bào)周期輸出一份結(jié)構(gòu)化的 Markdown 周報(bào)。 如果用戶只是在提問概念、閑聊請勿調(diào)用本技能。再看輸入 Schema{ type: object, properties: { raw_data: { type: string, description: 用戶提供的各渠道原始數(shù)據(jù)可以包含多段文字或表格結(jié)構(gòu) }, period: { type: string, description: 匯報(bào)周期例如 本周、上周、2025-11-03 至 2025-11-09 }, focus: { type: string, description: 重點(diǎn)分析方向如 留存率、轉(zhuǎn)化率、新增用戶多個(gè)重點(diǎn)用逗號分隔 } }, required: [raw_data, period] }執(zhí)行體代碼的邏輯大致是先按渠道分組整理關(guān)鍵指標(biāo)再按focus字段生成分析摘要最后拼裝成 Markdown 輸出。這里有個(gè)執(zhí)行體層面的小技巧不要在函數(shù)里直接拼接一大段格式復(fù)雜的文本而是先返回一個(gè)中間數(shù)據(jù)結(jié)構(gòu)把 Markdown 的排版工作交給模型。這樣模型可以根據(jù)上下文調(diào)整語氣和詳略而你的代碼只需保證數(shù)據(jù)準(zhǔn)確。最終這個(gè)技能跑了一個(gè)月識別準(zhǔn)確率從最初的 82% 提升到 95% 以上靠的就是反復(fù)調(diào)整描述和補(bǔ)充邊界條件。3.3 觸發(fā)調(diào)優(yōu)讓模型在該用的時(shí)候一定用不該用的時(shí)候不亂用觸發(fā)問題是做技能進(jìn)階時(shí)最磨人的一個(gè)點(diǎn)。你可能會遇到兩種情況該調(diào)用的不調(diào)用以及不該調(diào)用的亂調(diào)用。先解決“該用不用”。原因通常是技能描述里的觸發(fā)場景和用戶實(shí)際說法對不上。用戶可能說“幫我算一下這個(gè)月傭金”而你的技能描述只寫了“當(dāng)用戶要求生成月度報(bào)告時(shí)使用”。這時(shí)候需要在描述里增加同義觸發(fā)詞“結(jié)算傭金”“收益統(tǒng)計(jì)”“傭金明細(xì)”都可以算觸發(fā)詞。注意不要盲目疊加觸發(fā)器那樣反而會讓模型想太多。再解決“不該用亂用”。一個(gè)很有效的寫法是在描述里顯式寫否定條件。比如上面的周報(bào)技能里我加了“如果用戶只是在提問概念、閑聊請勿調(diào)用本技能”。這句話看著普通但實(shí)測非常管用能把誤觸發(fā)率降低一半以上。還有一個(gè)進(jìn)階手段給技能設(shè)置“前置條件判斷”。比如“只有當(dāng)前對話包含至少 5 條數(shù)據(jù)時(shí)才調(diào)用”這個(gè)條件也可以寫進(jìn)描述模型通常會自覺地評估自己手里信息夠不夠。觸發(fā)調(diào)優(yōu)是慢功夫建議上線后每天看一次調(diào)用日志把錯(cuò)誤的觸發(fā)樣本收集起來反哺描述。4. 性能與質(zhì)量優(yōu)化技能好用和能用是兩回事4.1 提示側(cè)技能描述怎么寫模型才看得懂我在實(shí)戰(zhàn)中總結(jié)了一個(gè)技能描述的四要素模板照這個(gè)寫基本不會走樣功能邊界一句話說明這個(gè)技能做什么不做什么。觸發(fā)條件出現(xiàn)哪些關(guān)鍵詞、句式、場景時(shí)調(diào)用。禁用條件出現(xiàn)哪些情況時(shí)不要調(diào)用。返回特征返回的結(jié)果是表格、文本還是結(jié)構(gòu)化數(shù)據(jù)有多少字。舉個(gè)例子一個(gè)“客戶標(biāo)簽查詢技能”的描述可以是這樣當(dāng)用戶詢問某個(gè)客戶的屬性標(biāo)簽如行業(yè)、規(guī)模、意向等級時(shí)調(diào)用。 注意本技能只能查詢已授權(quán)客戶庫中的數(shù)據(jù)不負(fù)責(zé)更新或刪除標(biāo)簽。 如果用戶只是詢問標(biāo)簽的定義應(yīng)該直接回答不要調(diào)用。 返回格式一個(gè) JSON 對象包含客戶 ID、標(biāo)簽列表、最近更新時(shí)間。這里最有價(jià)值的是“返回特征”。因?yàn)槟Ｐ驮谡{(diào)用技能之前需要知道“接下來我能拿到什么”清晰的返回特征能讓模型決定是否需要繼續(xù)追問參數(shù)也能讓模型在后面組織答案時(shí)更有底氣。4.2 執(zhí)行側(cè)并行、緩存、流式返回的取舍技能多了之后性能瓶頸主要是兩個(gè)調(diào)用耗時(shí)和上下文占用。并行如果一個(gè) Agent 在一輪里決定調(diào)用三個(gè)查詢技能而這三個(gè)技能彼此之間沒有依賴那么完全可以并行發(fā)起。這不需要改動模型調(diào)度邏輯而是在你的執(zhí)行引擎里把模型輸出的“技能調(diào)用計(jì)劃”先解析成一個(gè)有向無環(huán)圖DAG然后按拓?fù)漤樞驁?zhí)行。沒有依賴關(guān)系的節(jié)點(diǎn)同時(shí)跑能把總耗時(shí)壓縮到原來的三分之一。緩存很多查詢類技能相同參數(shù)在短時(shí)間內(nèi)返回結(jié)果幾乎一樣。這時(shí)可以加一層緩存緩存鍵直接使用參數(shù)哈希值有效期按數(shù)據(jù)更新頻率設(shè)定。但注意金融行情、庫存數(shù)量這類高頻變化的數(shù)據(jù)緩存會帶來“看起來是實(shí)時(shí)其實(shí)是舊數(shù)據(jù)”的壞體驗(yàn)。一般只對靜態(tài)或準(zhǔn)靜態(tài)數(shù)據(jù)開緩存。流式返回如果技能執(zhí)行時(shí)間很長比如跑一個(gè)機(jī)器學(xué)習(xí)模型不要硬等它執(zhí)行完再讓模型回復(fù)。比較合理的方式是先把“正在執(zhí)行技能”的狀態(tài)告訴用戶執(zhí)行完再把結(jié)果增量返回。很多框架已經(jīng)支持這種“流式中間事件”別忽略它用戶的等待體驗(yàn)會好很多。4.3 驗(yàn)收側(cè)技能成功率怎么統(tǒng)計(jì)、怎么回歸一個(gè)技能上線后不能只靠“感覺好像還不錯(cuò)”來評估。我在團(tuán)隊(duì)內(nèi)部會建一個(gè)簡化的驗(yàn)收體系調(diào)用率在一百次相關(guān)提問中技能被正確調(diào)用的次數(shù)占比。反映觸發(fā)調(diào)優(yōu)的效果。成功率技能被調(diào)用后執(zhí)行體成功返回內(nèi)容的次數(shù)占比。反映技能本身的穩(wěn)定性。有效返回率在成功返回的結(jié)果里能被模型正確吸收進(jìn)最終答案的比例。這一步常常被忽略但核心價(jià)值恰恰體現(xiàn)在這里畢竟執(zhí)行成功不意味著模型用得好。每次優(yōu)化技能我都建議配一組回歸用例涵蓋正常場景、邊緣場景、錯(cuò)誤場景至少各五條。跑一遍記錄上述三個(gè)指標(biāo)再對比優(yōu)化前后的差值。用數(shù)據(jù)說話你會少走很多彎路。5. 落地避坑從 10 個(gè)技能到 100 個(gè)技能會遇到什么5.1 返回內(nèi)容太大上下文被撐爆的解法技能剛上線時(shí)返回幾百字沒啥問題?？僧?dāng)數(shù)據(jù)量變大技能可能一次性返回?cái)?shù)千行日志模型的上下文窗口一下就滿了不僅費(fèi)錢還會讓模型在后續(xù)對話中變得“健忘”。解法有幾個(gè)層級按優(yōu)先級排序技能內(nèi)先聚合在執(zhí)行體里做一次預(yù)聚合只返回摘要。比如日志分析技能不要返回每一行日志而是統(tǒng)計(jì)出錯(cuò)誤率、TOP5 錯(cuò)誤類型、時(shí)間分布即可。分頁拉取如果用戶明確要看明細(xì)就提供一個(gè)支持分頁參數(shù)的技能變體。模型可以自行決定調(diào)用第幾頁。外部存儲引用當(dāng)內(nèi)容實(shí)在太大可以把完整結(jié)果寫入臨時(shí)存儲然后只返回一個(gè)“內(nèi)容地址”給模型。模型可以說“我把結(jié)果放在附件里了”用戶再點(diǎn)擊附件查看全文。第 3 種方式最容易被忽略但它是處理大文件場景的正確姿勢。不要指望模型“通讀全文”它更適合“讀摘要抓重點(diǎn)必要時(shí)用工具繼續(xù)查”。5.2 技能之間互相干擾命名空間與權(quán)限設(shè)計(jì)技能少的時(shí)候還不覺得一旦超過 20 個(gè)你會發(fā)現(xiàn)模型開始“張冠李戴”查詢訂單金額的時(shí)候調(diào)用了庫存查詢技能明明有兩個(gè)相似技能模型怎么都不選正確的那一個(gè)。這時(shí)候要做兩件事第一檢查技能名是否夠獨(dú)特。技能名盡量帶上業(yè)務(wù)前綴比如order_query和inventory_query不要都用data_query這種模糊名字。模型在茫茫技能列表里快速找“哪個(gè)最像”名字就是它的第一直覺。第二收斂相似技能。如果你發(fā)現(xiàn)多個(gè)技能的描述大片重疊不如把它們合并成一個(gè)“萬能技能”內(nèi)部再按參數(shù)分流。模型只需要記住一個(gè)入口負(fù)擔(dān)更小。比如把“查詢訂單”“查詢退款”“查詢售后”合并成“交易記錄查詢”再用query_type參數(shù)區(qū)分。還有一點(diǎn)容易被忽視在技能列表里給每個(gè)技能加“優(yōu)先級/hot 程度”權(quán)重。某些高頻場景的技能可以排在最前面模型選擇命中率會上升不少。這是各家框架配置里都能看到的項(xiàng)別嫌麻煩值得認(rèn)真調(diào)一調(diào)。5.3 高危操作哪怕是本地工具也要做授權(quán)校驗(yàn)一個(gè)安全的 Agent絕不能用戶說什么就做什么。尤其是那些涉及郵件發(fā)送、文件刪除、交易操作、數(shù)據(jù)修改的高級技能必須設(shè)計(jì)一層獨(dú)立的授權(quán)保護(hù)。我見過一個(gè)反面案例開發(fā)環(huán)境里把“數(shù)據(jù)庫刪除”功能做成了技能測試時(shí)用戶隨口說了一句“把測試數(shù)據(jù)清掉”模型二話不說調(diào)用了技能。幸好指向的是測試庫要是生產(chǎn)環(huán)境后果不堪設(shè)想。給高危技能加防護(hù)至少要做到敏感動作二次確認(rèn)當(dāng)模型識別到要調(diào)用高危技能時(shí)在返回給用戶最終執(zhí)行前先輸出一條確認(rèn)提示“即將執(zhí)行刪除操作是否確認(rèn)”參數(shù)白名單校驗(yàn)在執(zhí)行體內(nèi)部對參數(shù)值做合法性校驗(yàn)。比如批量刪除的 ID 必須是數(shù)字最大刪除條數(shù)不能超過 100。權(quán)限級別檢查每個(gè)技能打上權(quán)限標(biāo)簽不同會話、不同用戶只能調(diào)用標(biāo)簽匹配的技能。這條不是可選項(xiàng)而是底線。哪怕只是一個(gè)本地實(shí)驗(yàn)項(xiàng)目也建議養(yǎng)成好習(xí)慣技能可以很聰明但用起來必須守規(guī)矩。5.4 我最后留下的技能自查清單做過的項(xiàng)目多了每次新上一個(gè)技能之前我都會過一遍這張清單節(jié)省了大量踩坑時(shí)間。分享出來你可以直接抄作業(yè)[ ] 技能名是否唯一、具體、容易理解[ ] 描述里是否包含觸發(fā)條件、禁用條件、返回特征[ ] 輸入 Schema 是否每個(gè)字段都有說明必填項(xiàng)是否正確[ ] 執(zhí)行體是否做了參數(shù)校驗(yàn)和異常捕獲[ ] 技能是否有明顯的副作用是否需要二次確認(rèn)[ ] 超時(shí)時(shí)間是否合理重試策略是否考慮冪等性[ ] 返回內(nèi)容是否過長是否有摘要或分頁方案[ ] 是否已在測試集上記錄調(diào)用率、成功率、有效返回率[ ] 新增技能后是否和已有相似技能做過名稱與描述去重這一整套檢查下來一個(gè)技能的質(zhì)量基本就穩(wěn)了不會出現(xiàn)那種上線三天被用戶罵“人工智障”的尷尬局面。我自己做過的一百多個(gè)技能里最后活得最久的往往不是邏輯最炫酷的那個(gè)而是邊界最清楚、失敗回應(yīng)最友好的那個(gè)。Agent 的技能本質(zhì)上是把“大模型的判斷力”和“外部系統(tǒng)的執(zhí)行力”粘在一起粘得牢不牢取決于你有沒有把每一條邊界都寫到。希望這一期能幫你把 Agent Skills 這條鏈路真正跑通剩下的就是在自己的場景里一點(diǎn)點(diǎn)打磨了。