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