1. Skill 為什么突然值得被單獨(dú)拿出來評(píng)測先說一個(gè)這兩年 Agent 圈特別擰巴的現(xiàn)象大家都在做 AgentDemo 跑得飛起一聊到這個(gè) Agent 到底好不好用、那個(gè) Skill 靠不靠譜基本都是體感還行試了幾個(gè) case 挺順這種模糊說法。問成功率是多少答不上來問哪些場景會(huì)崩也說不清楚。Agent 的測評(píng)多少還有個(gè)通用榜單能對(duì)一對(duì)Skill 呢基本處于三不管地帶。Skill 在 Agent 體系里是很重要的一層它本質(zhì)上是讓大模型完成某一個(gè)特定子任務(wù)的封裝能力。拆下來看它可以是一個(gè)工具調(diào)用的完整邏輯可以是一段可復(fù)用的 Prompt 模板也可以是一個(gè)帶前置校驗(yàn)、后置兜底的流程編排。一個(gè)復(fù)雜的 Agent 往往要串聯(lián)五六個(gè)甚至十幾個(gè)這樣的 Skill。問題就來了Agent 整體跑得好不代表每個(gè) Skill 都好整體跑崩了你也不一定能快速定位是哪一環(huán)出了問題。這就必須把 Skill 單獨(dú)拎出來測。阿里開源的 skill-up 做的正是這件事把 Agent Skill 當(dāng)作獨(dú)立的評(píng)測對(duì)象用一套標(biāo)準(zhǔn)化的流程給它打分、找問題、盯回歸。它不是一個(gè)炫技的項(xiàng)目而是一個(gè)研發(fā)流程里的基礎(chǔ)工具。我的理解是想讓 Agent 從能跑走向靠譜Skill 評(píng)測是躲不開的一步。這篇文章我打算把它講透——Skill 和 Agent 的邊界到底怎么分、評(píng)測該看哪些數(shù)、用 skill-up 跑一輪評(píng)測要經(jīng)歷什么以及我在實(shí)際整理評(píng)測集時(shí)踩過的幾個(gè)真實(shí)大坑。2. 拆清楚Skill 和 Agent 到底是什么關(guān)系很多剛開始接觸 Agent 的朋友看到搜索引擎里天天掛著agent skillskill 和 agent 的區(qū)別說明這個(gè)基本概念的確擋了不少人。我在帶團(tuán)隊(duì)做 Agent 項(xiàng)目時(shí)被問得最多的問題也是我寫了個(gè)工具函數(shù)它算 Skill 嗎我起了個(gè) Agent它能算好幾個(gè)任務(wù)里面是藏著多個(gè) Skill 嗎2.1 一個(gè)被低估的概念邊界先說結(jié)論Agent 是決策和執(zhí)行的主體它負(fù)責(zé)理解目標(biāo)、拆解計(jì)劃、調(diào)用資源、判斷結(jié)果、決定下一步做什么Skill 則是 Agent 可以調(diào)用的、封裝好的能力單元解決的是某一個(gè)具體任務(wù)怎么做好這件事。打個(gè)比方。Agent 像是一個(gè)項(xiàng)目經(jīng)理Skill 像是一線工程師。項(xiàng)目經(jīng)理拿到一個(gè)目標(biāo)搭建一個(gè)線上展館他不會(huì)自己把所有活都干完而是把任務(wù)拆成設(shè)計(jì)頁面結(jié)構(gòu)處理用戶登錄寫商品列表接口做數(shù)據(jù)埋點(diǎn)每個(gè)任務(wù)丟給對(duì)應(yīng)的一線工程師。每一個(gè)工程師就是獨(dú)立的 Skill他們各有專攻可以單獨(dú)考核頁面結(jié)構(gòu)能不能按時(shí)交付接口在高并發(fā)下會(huì)不會(huì)掛Skill 評(píng)測就是給每個(gè)一線工程師做 KPI 考核。具體到技術(shù)形態(tài)上一個(gè) Skill 是包含 Prompt 模板、工具調(diào)用約定、輸入輸出 Schema、錯(cuò)誤處理策略的完整單元。它不應(yīng)該被寫死在 Agent 的主流程里而應(yīng)該是可注冊、可復(fù)用、可單獨(dú)調(diào)用的。我見過團(tuán)隊(duì)把大量邏輯堆在 Agent 的 system prompt 里最后 2000 行的 Prompt 根本沒法測出了 bug 只能用重新調(diào)一下 prompt來解決這其實(shí)就是沒有按 Skill 來組織能力的反面教材。2.2 評(píng)測粒度不同帶來的本質(zhì)差異區(qū)分 Skill 和 Agent不只是為了概念上聊得清它直接決定了評(píng)測怎么設(shè)計(jì)Agent 評(píng)測側(cè)重全鏈路能力。給 Agent 一個(gè)開放式目標(biāo)看它能不能自己規(guī)劃、自己糾錯(cuò)、自己達(dá)成目標(biāo)。輸入通常是一個(gè)自然語言任務(wù)輸出是整個(gè)任務(wù)的完成結(jié)果。Agent 評(píng)測關(guān)心的是任務(wù)級(jí)成功率、多輪交互的擬人度、規(guī)劃合理性等偶然性和上下文累積影響很大。Skill 評(píng)測側(cè)重點(diǎn)是單點(diǎn)能力的穩(wěn)定性和邊界。輸入是符合 Skill 定義的調(diào)用請(qǐng)求輸出是 Skill 的執(zhí)行結(jié)果。它關(guān)心的是一百個(gè)同類請(qǐng)求里有多少個(gè)成功、多少個(gè)失敗失敗是集中在某一類輸入上還是隨機(jī)散布遇到邊界輸入時(shí)會(huì)優(yōu)雅拒絕還是直接報(bào)錯(cuò)。兩者測出來的數(shù)據(jù)用途也不一樣。Agent 評(píng)測告訴你這哥們整體能不能處Skill 評(píng)測告訴你他扛事情的時(shí)候哪塊能力是你的短板。2.3 不區(qū)分評(píng)測粒度會(huì)踩什么坑如果評(píng)測不區(qū)分粒度最常見的后果是完美的模糊歸因Agent 最終輸出崩了你可以怪最新的那個(gè)模型 prompt 寫得差也可以怪某個(gè)工具的返回格式變了還可以怪編排邏輯判斷失誤。多個(gè)變量同時(shí)變化根本沒法定位。而把每個(gè) Skill 拆開單獨(dú)測相當(dāng)于給系統(tǒng)裝了獨(dú)立的儀表盤每個(gè) Skill 有自己的成功率和延遲曲線哪個(gè)環(huán)節(jié)劣化數(shù)據(jù)會(huì)告訴你。這也是 skill-up 這類工具存在的意義——做 Skill 粒度的事實(shí)度量。它默認(rèn)你手頭有幾個(gè)編好的 Skill然后幫你回答這個(gè) Skill 到底能不能打。3. 評(píng)測 Agent Skill 到底該看哪些數(shù)評(píng)測工具的價(jià)值一半在流程框架一半在指標(biāo)體系。Skill 評(píng)測如果只盯一個(gè)成功率那跟沒測沒什么區(qū)別。我按自己的實(shí)踐經(jīng)驗(yàn)把指標(biāo)拆成五層每一層解決不同的問題。3.1 核心五層指標(biāo)體系第一層是任務(wù)成功率。這是最基礎(chǔ)的數(shù)定義是所有評(píng)測用例中Skill 按預(yù)期完成任務(wù)的占比。注意按預(yù)期三個(gè)字是靈魂Agent Skill 普遍有 JSON 輸出、有工具調(diào)用輸出格式對(duì)了但業(yè)務(wù)邏輯算錯(cuò)了算不算成功必須通過評(píng)測集的判定邏輯來確定而不能只看模型沒報(bào)錯(cuò)。第二層是魯棒性。一個(gè)成熟的 Skill 不能只在標(biāo)準(zhǔn)輸入下工作。魯棒性評(píng)測要看輸入里帶無關(guān)干擾信息時(shí)能不能提取關(guān)鍵參數(shù)輸入缺失某個(gè)非必填字段時(shí)會(huì)不會(huì)崩輸入是極端長度超短、超長時(shí)表現(xiàn)如何輸入語言混雜時(shí)是否還能穩(wěn)定處理。魯棒性一般用一個(gè)邊界用例集來跑和正常用例分開統(tǒng)計(jì)。第三層是穩(wěn)定性和可復(fù)現(xiàn)性。同一組用例重復(fù)跑多次結(jié)果一致嗎大模型推理有隨機(jī)性完全一致不現(xiàn)實(shí)但一個(gè)負(fù)責(zé)任的 Skill 應(yīng)該在核心決策上保持穩(wěn)定而不是同一道題一會(huì)兒答對(duì)一會(huì)兒答錯(cuò)。穩(wěn)定性通常用三次以上重復(fù)實(shí)驗(yàn)的通過率波動(dòng)幅度來衡量。第四層是資源消耗和延遲。Skill 本質(zhì)上是一個(gè)在線的能力調(diào)用每多一次模型推理就多一分成本和延遲。評(píng)測至少要關(guān)注三個(gè)數(shù)單次調(diào)用平均延遲 P50/P95、Token 消耗總 token 和有效 token 占比、額外工具調(diào)用次數(shù)說明這個(gè) Skill 是否依賴多次重試才成功。第五層是錯(cuò)誤處理質(zhì)量。Skill 面對(duì)不能處理的輸入時(shí)是給出一個(gè)標(biāo)準(zhǔn)化的錯(cuò)誤協(xié)議還是糊里糊涂輸出一堆幻覺內(nèi)容好的 Skill 應(yīng)該知道自己的邊界在哪里遇到符合條件的輸入說我做不了并給出原因而不是硬做一個(gè)錯(cuò)誤結(jié)果。這個(gè)指標(biāo)在常規(guī)評(píng)測里最容易被忽略但在真實(shí)生產(chǎn)環(huán)境里最容易炸雷。3.2 評(píng)測集應(yīng)該長什么樣指標(biāo)體系定完接下來就是評(píng)測集設(shè)計(jì)。這是我認(rèn)為 skill-up 這類工具能不能真正發(fā)揮作用的關(guān)鍵因?yàn)楣ぞ弑旧碇粫?huì)忠實(shí)地執(zhí)行評(píng)測和統(tǒng)計(jì)數(shù)據(jù)評(píng)測集定義得好不好直接影響結(jié)果的可信度。評(píng)測集建議至少包含四類用例正向標(biāo)準(zhǔn)用例60%覆蓋 Skill 設(shè)計(jì)范圍內(nèi)的典型場景數(shù)據(jù)是干凈、完整的。邊界用例15%輸入長度逼近上限、字段值接近空值、字符串包含特殊符號(hào)和轉(zhuǎn)義字符等。異常用例15%輸入不符合 Schema、傳入惡意或攻擊性內(nèi)容、目標(biāo)無法實(shí)現(xiàn)的任務(wù)。對(duì)抗/干擾用例10%輸入包含大量無關(guān)上下文、用戶中途改需求、多輪對(duì)話中信息前后矛盾等考察 Skill 在復(fù)雜對(duì)話流中的定位能力。我?guī)F(tuán)隊(duì)做評(píng)測集時(shí)第一版幾乎全是正向用例結(jié)果一次大版本重構(gòu)之后單測全綠在線一用就崩。后來排查發(fā)現(xiàn)崩的場景全在輸入字段少傳了一個(gè)字符串里有引號(hào)這種邊界情況。自那以后我把邊界用例和異常用例當(dāng)作必選項(xiàng)寧可正向用例少一些也要保證邊界覆蓋。3.3 怎么讀評(píng)測結(jié)果評(píng)測跑完會(huì)得到一張帶指標(biāo)的表。我一般按下面的思路讀數(shù)先看成功率是否高于 90%。低于 90% 的 Skill 不應(yīng)該被合入主流程這是紅線。然后看失敗用例的分布。如果失敗集中在某一種輸入類型上說明這是能力缺陷而不是隨機(jī)波動(dòng)。接著看 P95 延遲和 Token 消耗如果一個(gè) Skill 的正常成功率很高但延遲和 Token 消耗是同類模型平均水平的 1.5 倍以上要考慮是不是 Prompt 里塞了太多無關(guān)內(nèi)容或者依賴多次試錯(cuò)路徑。最后看錯(cuò)誤處理是否規(guī)范失敗時(shí)是否返回了結(jié)構(gòu)化錯(cuò)誤碼是直接拋異常讓上游 Agent 無法處理。4. 用 skill-up 跑一遍真實(shí)的 Skill 評(píng)測理解了指標(biāo)下面進(jìn)入實(shí)操環(huán)節(jié)。skill-up 的大致工作模式是你把一個(gè) Skill 接進(jìn)來定義好評(píng)測集配置好判定方式它就會(huì)批量跑用例、匯總指標(biāo)最后給出一份結(jié)構(gòu)化報(bào)告。整個(gè)過程不需要自己寫一個(gè)評(píng)測調(diào)度框架你只需要專注做一件事把你的 Skill 和你的評(píng)測用例準(zhǔn)備好。4.1 環(huán)境準(zhǔn)備與概念對(duì)應(yīng)我在落地一套評(píng)測環(huán)境時(shí)習(xí)慣先把工具里的核心概念和自己的代碼對(duì)應(yīng)起來?；谖覍?duì)這類工具的通用理解它的核心概念通常包括評(píng)測任務(wù)用例集執(zhí)行器和判定器對(duì)應(yīng)關(guān)系如下工具概念對(duì)應(yīng)你自己的實(shí)現(xiàn)需要準(zhǔn)備的內(nèi)容評(píng)測目標(biāo)被評(píng)測的 Skill把 Skill 的調(diào)用接口包裝成一個(gè)統(tǒng)一的函數(shù)或服務(wù)用例集評(píng)測數(shù)據(jù)集覆蓋正向/邊界/異常/對(duì)抗四類輸入且含預(yù)期結(jié)果或判定規(guī)則執(zhí)行器調(diào)起 Skill 的邏輯決定是本地直接調(diào)用還是通過 HTTP/服務(wù)化方式觸發(fā)判定器校驗(yàn)輸出對(duì)錯(cuò)的邏輯可以是精確匹配、語義相似度、規(guī)則校驗(yàn)或 LLM 裁判報(bào)告輸出指標(biāo)成功率、延遲、Token 消耗、失敗原因聚類等第一次接觸評(píng)測工具的人容易犯一個(gè)錯(cuò)誤直接拿網(wǎng)上現(xiàn)成的數(shù)據(jù)集塞進(jìn)去跑。Skill 評(píng)測不是通用的問答評(píng)測任何一個(gè) Skill 的輸入輸出都和你的具體實(shí)現(xiàn)強(qiáng)相關(guān)。別人評(píng)測集里的用戶輸入對(duì)你來說可能根本不符合 Schema。所以評(píng)測用例集最好基于你上線的真實(shí)場景來構(gòu)造。4.2 綁定 Skill 和用例時(shí)的關(guān)鍵操作先做 Skill 適配。大部分 Skill 對(duì)外是一個(gè)函數(shù)入?yún)⑹墙Y(jié)構(gòu)化的輸入出參是結(jié)構(gòu)化的結(jié)果。評(píng)測框架一般會(huì)要求你把它包裝成一個(gè)可被統(tǒng)一調(diào)用的形式。注意到一個(gè)最常見的坑是Skill 的輸入類型太寬泛。比如你的 Skill 入?yún)⑹怯脩魡栴}看起來很簡單但真正上線時(shí)入?yún)⑦€應(yīng)該包含上下文、用戶身份、時(shí)間、會(huì)話歷史等。如果評(píng)測時(shí)只傳一個(gè)裸的用戶問題測出來的成功率會(huì)明顯高于實(shí)際因?yàn)檎鎸?shí)場景里的干擾上下文完全沒有進(jìn)入評(píng)測。因此我在創(chuàng)建評(píng)測任務(wù)時(shí)一定會(huì)做一件事構(gòu)造一個(gè)輸入工廠它能批量生成符合真實(shí)分布的輸入實(shí)例。比如做一個(gè)客服回復(fù) Skill我的人工用例雖然只有 100 條但每次跑評(píng)測我會(huì)用模板在里面注入不同的用戶名、商品名、時(shí)間字段生成 300 條變體避免 Skill 在固定寫法上過擬合。然后是配置判定器。判定器是評(píng)測可信度的核心。有四種常見選擇精確匹配適合輸出是固定枚舉的場景比如返回一個(gè)狀態(tài)碼。規(guī)則匹配檢查輸出里是否包含/不包含某些關(guān)鍵字段適合格式化輸出。語義相似度適合自然語言回答用嵌入模型算相似度分?jǐn)?shù)超過閾值即判對(duì)。LLM 裁判輸入任務(wù)描述、模型輸出和標(biāo)準(zhǔn)答案讓裁判 LLM 判定結(jié)果對(duì)不對(duì)。我實(shí)際使用時(shí)的經(jīng)驗(yàn)是不要只用一種判定器。舉個(gè)例子一個(gè)工單摘要 Skill精確匹配完全不適用語義相似度能攔住大部分答非所問但對(duì)摘要里漏掉了關(guān)鍵結(jié)論這類問題語義相似度可能仍然因?yàn)檎w句子結(jié)構(gòu)相似而給了高分。這時(shí)候疊加一個(gè) LLM 裁判把是否包含關(guān)鍵要素作為判定標(biāo)準(zhǔn)效果會(huì)好很多。4.3 執(zhí)行評(píng)測與結(jié)果解讀用例和判定器準(zhǔn)備好后就能執(zhí)行評(píng)測了。整個(gè)過程往往需要運(yùn)行幾十到幾百個(gè)用例每個(gè)用例都要走一遍模型推理。執(zhí)行階段主要注意兩點(diǎn)第一并發(fā)控制。如果底層調(diào)用的是大模型 API一次性并發(fā)太高容易被限流導(dǎo)致超時(shí)和重試率飆升污染評(píng)測結(jié)果。我自己一般會(huì)先跑一個(gè) 10 個(gè)用例的小測試確認(rèn)流程通了再開全量評(píng)測并發(fā)數(shù)控制在 API 限量閾值的一半以下。第二記錄原始輸入輸出。評(píng)測報(bào)告只會(huì)給你打分和統(tǒng)計(jì)真正的問題分析必須回到原始日志。我通常會(huì)導(dǎo)出每一條評(píng)測用例的輸入、輸出、判定詳情和耗時(shí)方便失敗之后逐條分析。結(jié)果報(bào)告出來之后重點(diǎn)看三塊總體通過率、按用例類別的分組通過率、失敗樣本列表。如果正向用例通過率高但邊界用例崩了說明 Skill 的主路徑寫得不錯(cuò)但防御性不足如果正向和邊界都行但對(duì)抗用例夸了可能要檢查 Skill 提示詞里有沒有對(duì)輸入來源的約束或者它在面對(duì)一段明顯偏離主題的內(nèi)容時(shí)是否缺少拒答和糾正的機(jī)制。5. 實(shí)際操作中容易翻車的四個(gè)細(xì)節(jié)評(píng)測 Skill 不是把工具串聯(lián)起來就能直接得到好用結(jié)果的事中間有不少零散的坑。這幾條是我在給 Agent 項(xiàng)目搭評(píng)測流程時(shí)踩過或親眼見別人踩過的專門拎出來說。5.1 評(píng)測集污染問題跑過兩輪評(píng)測之后最常見的問題就是評(píng)測集污染。第一輪失敗了幾個(gè) case你為了修復(fù)評(píng)測結(jié)果悄悄調(diào)整了 Skill 的 Prompt加了針對(duì)這些失敗樣例的特化描述。第二次跑這幾個(gè) case 過了通過率從 85% 漲到 95%你很高興但這時(shí)候測試集已經(jīng)不再代表真實(shí)分布了它代表的是你記下來的那幾條歷史考題。這種行為的本質(zhì)是讓模型背題而不是掌握能力。解決思路很簡單用一個(gè)固定開發(fā)集 定期滾動(dòng)的保留集。開發(fā)集可以反復(fù)用來調(diào)試和迭代但最終上線前必須跑一遍保留集——保留集是放在一邊沒被調(diào)試過程用過的數(shù)據(jù)在它上面的通過率才是真正接近線上效果的數(shù)。skill-up 這類工具建議你按業(yè)務(wù)模塊多建幾個(gè)用例集不要永遠(yuǎn)復(fù)用同一個(gè)。5.2 隨機(jī)性導(dǎo)致的短線波動(dòng)大模型推理有隨機(jī)性同一個(gè) Skill 同一批用例今天跑通過率 93%明天可能掉到 88%。這不是 Skill 出現(xiàn)回歸而是模型采樣帶來的正常波動(dòng)。我自己在前 100 條用例的小評(píng)測集上尤其明顯用例少了哪怕只有一兩條結(jié)果波動(dòng)通過率的百分比都會(huì)跳得很厲害。建議是固定隨機(jī)種子如果底層模型支持、溫度調(diào)成 0 或接近 0、在可能的情況下同一用例重復(fù)跑 3 次取多數(shù)票作為判定結(jié)果。同時(shí)在報(bào)告里應(yīng)該記錄每次運(yùn)行的參數(shù)快照模型版本、Prompt 版本、溫度、判定器版本否則兩周之后你看到一份通過率 90% 的報(bào)告根本不知道它是用哪個(gè)版本跑出來的也就失去回歸對(duì)比的價(jià)值。5.3 外部依賴不穩(wěn)定Skill 如果要調(diào)用外部 API——比如查詢天氣、搜索數(shù)據(jù)庫、調(diào)用某個(gè)內(nèi)部服務(wù)——評(píng)測結(jié)果很容易被外部依賴的狀態(tài)帶跑。外部服務(wù)一抖動(dòng)Skill 的成功率就會(huì)假性下跌你以為是自己改壞了白排查半天。應(yīng)對(duì)方法是在評(píng)測環(huán)境里對(duì) Skill 的外部依賴做 Mock 或者錄流重放。只要被測對(duì)象不是外部服務(wù)本身外部服務(wù)就應(yīng)該提供穩(wěn)定的打樁數(shù)據(jù)。Skill 評(píng)測的邊界要畫清楚你測的是Skill 的邏輯在給定外部響應(yīng)下能否正確完成任務(wù)不是外部服務(wù)是否在線。如果你真的要測外部服務(wù)的可用性那是另一套監(jiān)控體系的事情。5.4 判定器本身的誤差LLM 裁判能解決很多傳統(tǒng)判定搞不定的語義問題但它本身也是一個(gè)模型也有誤判率。我在早期就遇到過裁判給分過于寬松的情況模型輸出的回答幾乎完全不含關(guān)鍵信息但句子結(jié)構(gòu)完整流暢裁判給了一個(gè)高分。對(duì)這個(gè)問題我把裁判 Prompt 寫成了強(qiáng)制要求它先列出關(guān)鍵檢查點(diǎn)逐項(xiàng)打勾再給出最終結(jié)論并在評(píng)測集里放了幾個(gè)已知的錯(cuò)誤樣本用來定期核對(duì)裁判自身的準(zhǔn)確率。如果裁判連驗(yàn)證樣本都判不對(duì)就要調(diào)整裁判 Prompt 或者換更強(qiáng)的裁判模型。工具本身不會(huì)提醒你裁判是錯(cuò)的所以這個(gè)檢查你得自己去做。6. 從評(píng)測到改進(jìn)skill-up 在研發(fā)流程里的位置評(píng)測工具最大的價(jià)值不在于測出問題了而在于它把問題變成了結(jié)構(gòu)化的輸入喂給研發(fā)流程。Skill 評(píng)測如果不跟迭代流程綁定那就是一份好看但沒人看的報(bào)告。6.1 評(píng)測結(jié)果如何驅(qū)動(dòng) Skill 迭代拿到評(píng)測報(bào)告后我的處理順序一般是先看失敗模式再看失敗樣本。舉例評(píng)測報(bào)告里異常用例的通過率只有 60%點(diǎn)開失敗樣本發(fā)現(xiàn)所有失敗都是用戶輸入里包含超出上下文窗口的長文本Skill 沒有做好截?cái)嘀苯訄?bào)錯(cuò)。那你要做的不是改 Prompt 里的某個(gè)措辭而是在 Skill 的前置處理里加一層輸入長度超限時(shí)自動(dòng)截?cái)嗖捶謮K處理的邏輯。這類結(jié)構(gòu)性缺陷只靠調(diào)整提示詞是修不好的。比較相鄰版本的數(shù)據(jù)。從第三輪評(píng)測開始我會(huì)把每次報(bào)告的通過率、平均延遲、Token 消耗做成一張簡單的趨勢表。凡是某一個(gè)指標(biāo)連續(xù)兩輪下滑就要立刻排查這期間改了什么。比如 Delay 和 Token 同時(shí)上升大概率是 Prompt 里多了不少檢索回來但沒有被有效壓縮的參考材料。重視一次都沒改過的指標(biāo)。有一種情況某個(gè) Skill 的成功率一直維持在 90% 左右但你在它上面做的各種嘗試都換不來提升。這通常說明瓶頸不在 Skill 自身而在底層模型的能力邊界或者輸入數(shù)據(jù)的質(zhì)量上限。這時(shí)候硬調(diào)的意義不大可以考慮換更強(qiáng)的基礎(chǔ)模型或者在更前端的流程里加一個(gè)預(yù)篩模塊把難處理的輸入提前分流給其他方案。6.2 評(píng)測集也要持續(xù)運(yùn)營評(píng)測集不是建完一次就永久使用的靜態(tài)資產(chǎn)它需要隨真實(shí)業(yè)務(wù)持續(xù)更新。我建議每次上線一個(gè)重要的新功能同步往評(píng)測集里補(bǔ)充對(duì)應(yīng)的用例讓評(píng)測集一直在反映最新的生產(chǎn)語義。同時(shí)定期檢查現(xiàn)有用例是否已經(jīng)過時(shí)。例如業(yè)務(wù)變了、某個(gè)字段廢棄了舊的評(píng)測用例如果不刪Skill 每輪都會(huì)在這些已經(jīng)不可能發(fā)生的場景上扣分白白拉低通過率還誤導(dǎo)改進(jìn)方向。另外線上產(chǎn)生的 bad case 是評(píng)測集最好的素材來源。我在線上 Agent 的日志里定期撈取用戶反饋不靠譜的記錄挑選有代表性的脫敏之后加入評(píng)測集的對(duì)抗用例組。這能讓評(píng)測體系與真實(shí)用戶體驗(yàn)始終保持一致。你不用一天加幾十條一周加 3-5 條高質(zhì)量樣本就夠。6.3 把評(píng)測接入持續(xù)集成的實(shí)際收益對(duì)工程團(tuán)隊(duì)來說把 Skill 評(píng)測接入 CI 流程收益非常直接。每次 Skill 代碼或 Prompt 有變更自動(dòng)觸發(fā)一輪冒煙評(píng)測跑核心用例集的子集通過率低于基線閾值就阻止合并。這相當(dāng)于給改 Prompt這種以前完全靠人工確認(rèn)的操作加了一道自動(dòng)門禁。Prompt 調(diào)優(yōu)是最容易順手破壞其他場景的改動(dòng)手動(dòng)測試很難覆蓋到回歸影響。CI 全量評(píng)測雖然每個(gè)版本都跑會(huì)有點(diǎn)耗時(shí)但我會(huì)分成兩級(jí)提交級(jí)跑核心 30-50 條用例確保大方向不崩發(fā)版前跑完整幾百條用例數(shù)據(jù)歸檔留檔。這樣既保證了迭代速度又不會(huì)漏掉回歸風(fēng)險(xiǎn)。7. 我的幾點(diǎn)真實(shí)體會(huì)回到標(biāo)題上阿里開源 skill-up 這件事本身我認(rèn)為是在一個(gè)正確的時(shí)間點(diǎn)做了一個(gè)正確的工具。Agent 開發(fā)社區(qū)現(xiàn)在最缺的不是更多花哨的 Agent 框架而是把工程化基礎(chǔ)打牢的能力。Skill 評(píng)測正是這個(gè)基礎(chǔ)里很重要的一塊拼圖。從我實(shí)際操作的經(jīng)驗(yàn)看Skill 評(píng)測能不能在你的團(tuán)隊(duì)里落地更多靠的是流程和習(xí)慣而不是工具本身你是否愿意把評(píng)測集當(dāng)作代碼一樣維護(hù)你是否能容忍評(píng)測報(bào)告給出不達(dá)標(biāo)的結(jié)果并以此為準(zhǔn)阻斷發(fā)版你是否能堅(jiān)持在出問題時(shí)先定位數(shù)據(jù)而不是憑感覺去調(diào)整提示詞這些問題工具幫不了你只有自己下決心才能解決。skill-up 這類工具給了你一個(gè)可以開始的基礎(chǔ)框架但評(píng)測集的質(zhì)量、指標(biāo)的解讀、迭代的閉環(huán)這些還是得靠你在真實(shí)業(yè)務(wù)里一點(diǎn)點(diǎn)打磨。把 Skill 測到數(shù)據(jù)可查、回歸可控、問題可定位Agent 的可靠性才算真正有了底線。我希望這篇分享能幫你減少一些起步階段的無從下手感至于后面能把這套流程用到什么深度就看你的項(xiàng)目需要了。