1. Agent技能的本質(zhì)為什么一定要有技能系統(tǒng)這層抽象1.1 從會(huì)聊天到會(huì)干活差的不只是模型能力做過Agent落地項(xiàng)目的人應(yīng)該都有同感模型推理能力再強(qiáng)如果它只能空談不能動(dòng)手那離真正解決業(yè)務(wù)問題還差著十萬八千里。我們團(tuán)隊(duì)做客服、知識(shí)庫、內(nèi)部效率工具這類Agent時(shí)早期最頭疼的瓶頸反而不是模型本身而是怎么讓模型安全、穩(wěn)定、可控地調(diào)用外部能力。你直接給模型一個(gè)Python執(zhí)行環(huán)境讓它隨便寫代碼十個(gè)里有九個(gè)會(huì)在邊界情況上翻車你給它接一堆亂七八糟的API它可能連哪個(gè)接口能買菜都分不清。所以業(yè)界逐步形成了Agent技能Skill這個(gè)概念也是agent-skills這類工具集出現(xiàn)的背景。技能層做的事情說簡(jiǎn)單也簡(jiǎn)單把模型可以調(diào)用的能力做成一整套有名字、有描述、有參數(shù)約束、有邊界控制的標(biāo)準(zhǔn)化模塊。模型不直接接觸底層API和代碼而是通過技能這個(gè)中間層來完成具體動(dòng)作。這樣既保住了模型的理解能力又把失控風(fēng)險(xiǎn)鎖在可控范圍內(nèi)。技能體系和傳統(tǒng)RPA、普通腳本調(diào)度有一個(gè)本質(zhì)區(qū)別RPA是預(yù)先編排好的固定流程而Agent技能是由模型在對(duì)話中動(dòng)態(tài)選擇的。這意味著技能的門面描述和參數(shù)說明必須設(shè)計(jì)得足夠好模型才能在合適的場(chǎng)景主動(dòng)找到它。這個(gè)門面設(shè)計(jì)的功夫在實(shí)際項(xiàng)目里往往比技能內(nèi)部實(shí)現(xiàn)更影響成敗后面我會(huì)詳細(xì)展開。1.2 agent-skills的核心注冊(cè)表、調(diào)用協(xié)議、安全護(hù)欄回到agent-skills這個(gè)標(biāo)題本身它如果要成為一個(gè)真正有用的工程化項(xiàng)目核心得解決四件事。第一是技能的注冊(cè)與發(fā)現(xiàn)。Agent運(yùn)行時(shí)有幾十上百個(gè)技能不能靠一堆if else硬編碼去判斷該調(diào)誰。需要一套注冊(cè)表機(jī)制讓技能開發(fā)者聲明我這個(gè)技能叫什么、干什么、什么時(shí)候該用然后由調(diào)度層根據(jù)模型的意圖匹配最合適的技能。第二是統(tǒng)一的調(diào)用協(xié)議。所有技能無論內(nèi)部實(shí)現(xiàn)是什么語言、什么框架對(duì)外都得遵循相同的入?yún)?、出參、錯(cuò)誤碼規(guī)范。這樣模型側(cè)只需要學(xué)會(huì)一套調(diào)用語法切換技能時(shí)不會(huì)產(chǎn)生認(rèn)知負(fù)擔(dān)。協(xié)議統(tǒng)一還有個(gè)好處可以集中做日志、限流、審計(jì)不用每個(gè)技能各搞一套。第三是安全護(hù)欄。技能能碰什么資源、不能碰什么資源必須由平臺(tái)層面做白名單控制。比如一個(gè)發(fā)送郵件技能它只能發(fā)到企業(yè)內(nèi)部域名且同一收件人一分鐘最多一封。這些策略不能指望模型自覺遵守必須在技能執(zhí)行層硬性卡住。第四是技能的組合編排。單個(gè)技能解決單點(diǎn)問題但真實(shí)任務(wù)往往要多個(gè)技能協(xié)作。比如幫我整理本周所有項(xiàng)目周報(bào)并提取風(fēng)險(xiǎn)項(xiàng)需要檢索技能、讀取文檔技能、結(jié)構(gòu)化輸出技能協(xié)同。而agent-skills這類系統(tǒng)需要在技能之上提供編排能力讓模型能按步驟調(diào)用多個(gè)技能并把上下文串聯(lián)起來。這四件事做扎實(shí)了Agent才真正從聊天機(jī)器人進(jìn)化為數(shù)字員工。很多人覺得技能開發(fā)就是寫個(gè)函數(shù)加個(gè)注解那是把問題想淺了。真正的技能工程化要在一開始就把描述規(guī)范、參數(shù)校驗(yàn)、錯(cuò)誤恢復(fù)、觀測(cè)日志這幾層全部考慮進(jìn)去否則技能數(shù)量一多系統(tǒng)立刻變成一團(tuán)亂麻。2. 技能開發(fā)的核心環(huán)節(jié)與設(shè)計(jì)要點(diǎn)2.1 技能描述怎么寫模型才聽得懂我開始做技能時(shí)踩過最大的坑就是寫技能描述時(shí)太開發(fā)化總把描述寫成給人類同事看的接口文檔。結(jié)果模型經(jīng)常在錯(cuò)誤的場(chǎng)景下調(diào)用技能或者在正確場(chǎng)景下壓根不調(diào)用。后來我慢慢摸到規(guī)律技能描述本質(zhì)上寫在給大模型看的提詞它的核心目標(biāo)是讓模型在意圖匹配階段就建立清晰的觸發(fā)條件。一個(gè)高質(zhì)量技能描述至少要包含三層信息這個(gè)技能做什么、什么時(shí)候該用、什么時(shí)候不該用。光說獲取天氣信息遠(yuǎn)遠(yuǎn)不夠要補(bǔ)充僅在用戶詢問當(dāng)前天氣或未來天氣預(yù)報(bào)時(shí)使用不要將歷史天氣數(shù)據(jù)用于氣候分析。模型對(duì)否定性條件的理解能力很強(qiáng)主動(dòng)寫清不要做什么能大幅減少誤調(diào)用。另外技能名稱也大有講究。不要用內(nèi)部代號(hào)要用自然語言中用戶和模型都容易理解的名字。比如calc_engine_v3這種命名就要改叫數(shù)學(xué)計(jì)算器或calculator更直白。模型在意圖匹配時(shí)對(duì)名稱的語義非常敏感一個(gè)清晰的名字比什么配置都管用。下面是我常用的一張技能注冊(cè)對(duì)照表能幫助你在設(shè)計(jì)階段就自查描述質(zhì)量項(xiàng)目反面示例正面示例說明技能名稱data_proc_util銷售額數(shù)據(jù)匯總助手名稱要語義化避免縮寫和版本號(hào)做什么處理數(shù)據(jù)按月份匯總各渠道銷售額返回表格型結(jié)果說明輸入輸出形態(tài)何時(shí)觸發(fā)用戶需要數(shù)據(jù)時(shí)用戶要求匯總統(tǒng)計(jì)近一段時(shí)間的銷售額時(shí)明確觸發(fā)場(chǎng)景何時(shí)禁用無用戶要求預(yù)測(cè)未來銷售趨勢(shì)時(shí)不使用本技能主動(dòng)劃定邊界我建議每個(gè)技能的描述控制在120到200個(gè)中文字符之間。太短說不清楚上下文太長(zhǎng)模型在意圖匹配時(shí)會(huì)分散注意力。如果確實(shí)需要大量說明把補(bǔ)充信息放到參數(shù)描述里而不是堆在技能主描述里。2.2 參數(shù)Schema設(shè)計(jì)的坑與對(duì)策參數(shù)Schema是整個(gè)技能系統(tǒng)里最容易偷懶、也最容易出問題的地方。模型調(diào)用技能時(shí)參數(shù)要靠LLM從對(duì)話里抽取填充如果Schema設(shè)計(jì)不合理模型就頻繁傳錯(cuò)類型、漏傳必填項(xiàng)或者把含義相近的參數(shù)搞混。參數(shù)Schema設(shè)計(jì)有幾條實(shí)務(wù)經(jīng)驗(yàn)值得拿出來說第一參數(shù)數(shù)量寧少勿多。一個(gè)技能超過6個(gè)參數(shù)模型填參的錯(cuò)誤率會(huì)明顯上升。遇到復(fù)雜需求寧可拆成兩個(gè)技能也不要把12個(gè)參數(shù)塞到一個(gè)技能里。比如創(chuàng)建報(bào)銷單技能不要同時(shí)包含費(fèi)用明細(xì)、審批人、預(yù)算科目、附件路徑等全部字段可以把上傳附件拆成獨(dú)立技能用組合的方式完成完整流程。第二該用枚舉的地方絕不用自由文本。模型對(duì)開放輸入的把握能力不穩(wěn)定但對(duì)枚舉值的理解相當(dāng)準(zhǔn)確。比如費(fèi)用類型直接列出餐飲、交通、住宿、辦公用品、其他模型幾乎不會(huì)選錯(cuò)如果放開讓它填就會(huì)出現(xiàn)飯錢打車費(fèi)買文具和枚舉對(duì)不上的情況。第三參數(shù)與參數(shù)的依賴關(guān)系要顯式聲明。有些技能里B參數(shù)只在A參數(shù)等于某值時(shí)才有意義這種關(guān)系如果只寫在文檔里模型根本不會(huì)看正確做法是利用JSON Schema里的oneOf或allOf做條件約束讓模型在結(jié)構(gòu)上就無法生成非法組合。下面給一個(gè)參數(shù)Schema的示例這是我在實(shí)際開發(fā)中沉淀的較穩(wěn)健的寫法用來定義一個(gè)創(chuàng)建工單技能{ type: object, properties: { title: { type: string, minLength: 5, maxLength: 50, description: 工單標(biāo)題需概括問題核心 }, priority: { type: string, enum: [P0, P1, P2, P3], description: 工單優(yōu)先級(jí)P0為最高 }, category: { type: string, enum: [網(wǎng)絡(luò)故障, 賬號(hào)權(quán)限, 硬件報(bào)修, 軟件使用, 其他], description: 問題分類 }, description: { type: string, maxLength: 2000, description: 問題詳細(xì)描述包含時(shí)間、影響范圍、復(fù)現(xiàn)步驟 }, contact: { type: string, description: 提交人聯(lián)系方式工號(hào)或分機(jī)號(hào) } }, required: [title, priority, category, contact], additionalProperties: false }minLength和maxLength不是擺設(shè)能有效過濾掉模型生成的空字符串和超長(zhǎng)垃圾文本。additionalProperties: false要記得加上否則模型偶爾會(huì)自作主張多傳字段導(dǎo)致服務(wù)端校驗(yàn)失敗。參數(shù)里的description同樣要按告訴模型該怎么填的標(biāo)準(zhǔn)來寫而不是簡(jiǎn)單羅列字段含義。2.3 技能內(nèi)部的穩(wěn)定性閉環(huán)技能被模型調(diào)用只是開始執(zhí)行過程中的穩(wěn)定性才是真正決定用戶體驗(yàn)的地方。我見過太多Agent項(xiàng)目模型意圖理解都挺好結(jié)果技能一執(zhí)行就超時(shí)、報(bào)錯(cuò)、返回格式混亂用戶對(duì)Agent的信任瞬間崩塌。技能的穩(wěn)定性通常要圍繞四個(gè)維度做閉環(huán)。第一個(gè)是超時(shí)控制。Agent交互本身有實(shí)時(shí)性要求一個(gè)技能如果5秒內(nèi)沒返回對(duì)話就明顯卡頓。技能代碼里必須設(shè)置合理的超時(shí)閾值并設(shè)計(jì)降級(jí)策略。比如檢索類技能超時(shí)后返回暫時(shí)無法訪問知識(shí)庫請(qǐng)稍后重試而不是讓用戶對(duì)著轉(zhuǎn)圈界面干等。第二個(gè)是冪等性。技能被重試時(shí)要保證不產(chǎn)生重復(fù)副作用。以創(chuàng)建工單為例如果模型第一次調(diào)用超時(shí)后重試了兩次系統(tǒng)就創(chuàng)建了三張一模一樣的工單用戶來投訴時(shí)你都沒法解釋。解決辦法是在技能入口做去重根據(jù)對(duì)話上下文里的關(guān)鍵內(nèi)容生成請(qǐng)求指紋相同指紋的請(qǐng)求直接返回已有結(jié)果。第三個(gè)是異常分類。技能報(bào)錯(cuò)時(shí)返回的錯(cuò)誤碼要盡量語義化因?yàn)锳gent需要根據(jù)錯(cuò)誤信息決定下一步動(dòng)作。比如區(qū)分參數(shù)校驗(yàn)失敗模型可以自己調(diào)整參數(shù)再試一次、外部服務(wù)不可用應(yīng)該告訴用戶過會(huì)再試、權(quán)限不足要提示用戶聯(lián)系管理員。如果所有錯(cuò)誤都返回一個(gè)籠統(tǒng)的失敗Agent的恢復(fù)能力就是一句空話。第四個(gè)是可觀測(cè)性。每個(gè)技能調(diào)用都應(yīng)該記錄輸入、輸出、耗時(shí)、錯(cuò)誤便于復(fù)盤模型是不是在正確的場(chǎng)景下做了正確的調(diào)用。這一步在當(dāng)前Agent應(yīng)用的Debug階段尤其重要因?yàn)槟Ｐ托袨橛须S機(jī)性沒有日志你根本沒法定位問題出在意圖理解還是技能實(shí)現(xiàn)。3. 實(shí)操過程從零開發(fā)一個(gè)周報(bào)匯總技能并接入Agent3.1 需求拆解先劃清楚技能邊界為了把前面講的原理落到地上我完整走一遍開發(fā)周報(bào)匯總技能的過程。這個(gè)技能要完成的事情是用戶丟進(jìn)來幾段零散的周報(bào)文字技能自動(dòng)提煉出本周關(guān)鍵進(jìn)展、風(fēng)險(xiǎn)與阻塞、下周計(jì)劃三個(gè)板塊并按統(tǒng)一模板輸出。在寫代碼之前先做兩件重要的事。第一是劃定技能邊界輸入是純文本的周報(bào)片段輸出是結(jié)構(gòu)化匯總不涉及寫文件、不發(fā)送郵件、不查詢其他系統(tǒng)。第二是設(shè)計(jì)參數(shù)參數(shù)越少越好這個(gè)概念我最終確定只暴露兩個(gè)參數(shù)report_text必填待匯總的原始周報(bào)原文和tone可選可選值formal/concise控制匯總風(fēng)格。這里有個(gè)容易被忽略的點(diǎn)為什么不把生成匯總直接用提示詞讓模型做而要包成技能因?yàn)橹軋?bào)匯總在真實(shí)業(yè)務(wù)里有固定格式約束和后續(xù)處理需求技能可以把模板校驗(yàn)、敏感信息過濾、格式規(guī)范化這些邏輯固化下來不依賴于每次對(duì)話的隨機(jī)發(fā)揮。比如我們公司要求周報(bào)里的客戶名稱必須用脫敏后的代號(hào)這種規(guī)則就必須在技能代碼里做硬處理不能指望模型每次記得。3.2 代碼實(shí)現(xiàn)與注冊(cè)接入技能代碼用Python寫框架上不依賴具體Agent平臺(tái)核心邏輯就兩部分技能函數(shù)本體和注冊(cè)聲明。# skill_weekly_report.py import re import json from typing import Literal def summarize_weekly_report( report_text: str, tone: Literal[formal, concise] formal ) - dict: 周報(bào)匯總技能核心函數(shù)。 使用規(guī)則 1. 僅在用戶提供多段周報(bào)草稿并要求匯總、整理時(shí)調(diào)用 2. 不要將多段文字做簡(jiǎn)單拼接必須按照固定模板重新結(jié)構(gòu)化 # 敏感信息過濾手機(jī)號(hào)脫敏后再進(jìn)入后續(xù)處理 cleaned_text re.sub(r(?\d{3})\d{4}(?\d{4}), ****, report_text) # 這里在真實(shí)項(xiàng)目中會(huì)調(diào)用LLM做信息抽取和重組。 # 技能函數(shù)內(nèi)部調(diào)用LLM時(shí)需要帶上自己的結(jié)構(gòu)化輸出約束 # 要求模型嚴(yán)格輸出如下字段 # - highlights: 本周關(guān)鍵進(jìn)展 # - risks: 風(fēng)險(xiǎn)與阻塞 # - next_plan: 下周計(jì)劃 extracted _call_internal_llm(cleaned_text, tone) # 輸出格式必須固定方便Agent在后續(xù)對(duì)話中引用 return { summary: { highlights: extracted[highlights], risks: extracted[risks], next_plan: extracted[next_plan] }, source_length: len(cleaned_text), tone: tone } # 注冊(cè)描述這部分是給模型看的重要性等同于函數(shù)實(shí)現(xiàn) SKILL_DEFINITION { name: weekly_report_summarizer, description: 周報(bào)匯總與結(jié)構(gòu)化整理技能。當(dāng)用戶提供零散的周報(bào)段落 要求提煉進(jìn)展、風(fēng)險(xiǎn)或整理為規(guī)范周報(bào)時(shí)使用。 不適用于生成全新周報(bào)場(chǎng)景。, parameters: { type: object, properties: { report_text: { type: string, description: 用戶提供的原始周報(bào)內(nèi)容可包含多段、多個(gè)項(xiàng)目信息 }, tone: { type: string, enum: [formal, concise], description: 輸出風(fēng)格formal為完整句式concise為精簡(jiǎn)條目 } }, required: [report_text], additionalProperties: False } }真正的Agent平臺(tái)接入時(shí)技能注冊(cè)的過程就是把你寫好的SKILL_DEFINITION傳給注冊(cè)中心再把函數(shù)掛到執(zhí)行runtime上。注冊(cè)中心會(huì)為技能分配一個(gè)唯一ID并同步到模型側(cè)的tool列表里。做完注冊(cè)之后模型才會(huì)在對(duì)話中感知到周報(bào)匯總技能的存在。3.3 聯(lián)調(diào)測(cè)試與效果評(píng)估這是整個(gè)流程里最花時(shí)間的部分很多人以為技能寫完就完事了實(shí)際聯(lián)調(diào)才是決定質(zhì)量的關(guān)卡。我一般會(huì)準(zhǔn)備一套覆蓋正常與異常路徑的測(cè)試用例逐個(gè)檢查模型是否按預(yù)期調(diào)度技能。測(cè)試場(chǎng)景輸入示例期望行為關(guān)鍵檢查點(diǎn)正常匯總兩段周報(bào)草稿一段寫已完成工作一段寫遇到一個(gè)供應(yīng)商延遲問題調(diào)用技能返回三板塊結(jié)構(gòu)化匯總風(fēng)險(xiǎn)項(xiàng)是否被正確識(shí)別邊界禁止用戶說幫我寫一份下周的新品發(fā)布計(jì)劃不調(diào)用周報(bào)匯總技能模型是否理解不適用邊界缺參處理用戶只說匯總周報(bào)但沒給內(nèi)容追問用戶索要周報(bào)原文是否出現(xiàn)空參數(shù)調(diào)用風(fēng)格參數(shù)用戶說簡(jiǎn)短一點(diǎn)匯總調(diào)用技能并傳toneconcise參數(shù)映射是否準(zhǔn)確異常輸入傳入內(nèi)容全是亂碼技能返回規(guī)范錯(cuò)誤不崩潰錯(cuò)誤信息是否可理解聯(lián)調(diào)期間要尤其關(guān)注模型的參數(shù)填充質(zhì)量。我實(shí)測(cè)中發(fā)現(xiàn)模型對(duì)于枚舉參數(shù)的把握力不錯(cuò)但只要參數(shù)描述里有歧義它就會(huì)按自己理解隨意填。比如tone字段如果描述寫成匯總語氣模型就會(huì)傳簡(jiǎn)短精簡(jiǎn)輕松等超出枚舉范圍的值。把描述改成可選值為formal完整正式句式或concise精簡(jiǎn)關(guān)鍵詞列表當(dāng)用戶要求簡(jiǎn)短時(shí)使用concise準(zhǔn)確率立刻上來了。另一個(gè)聯(lián)調(diào)時(shí)容易忽略的是技能輸出太大。周報(bào)匯總技能如果輸入幾千字模型輸出結(jié)構(gòu)化摘要時(shí)token消耗很厲害。要在大模型返回前做好截?cái)喾駝tAgent上下文很快被撐爆后續(xù)對(duì)話質(zhì)量直線下降。我在技能函數(shù)里對(duì)highlights、risks、next_plan各限定了最多10條超出部分合并為其他事項(xiàng)這樣既保持信息完整又控制上下文占用。4. 常見問題與排查技巧實(shí)錄4.1 Agent不調(diào)用技能或者老調(diào)錯(cuò)技能遇到這種情況先別懷疑模型能力九成是技能門面出了問題。排查時(shí)我會(huì)按順序做三件事第一檢查技能描述里是否寫清了觸發(fā)條件和禁用條件。描述寫的過于寬泛模型就會(huì)猶豫要不要調(diào)用描述太具體模型在其他相關(guān)場(chǎng)景又識(shí)別不出來。理想狀態(tài)是讓技能描述和業(yè)務(wù)里用戶最常說的那幾句話對(duì)齊。比如用戶習(xí)慣說把這幾段話理一理那描述里就應(yīng)該包含整理理一理規(guī)范化這類口語觸發(fā)詞而不是只寫匯總這種書面詞。第二檢查技能名稱是否和平臺(tái)內(nèi)已有技能沖突或產(chǎn)生歧義。一個(gè)經(jīng)典案例系統(tǒng)里同時(shí)有發(fā)送郵件和郵件草稿助手兩個(gè)技能模型很容易混淆。遇到這種情況要合并技能或在描述中明確分工比如郵件草稿助手用于創(chuàng)建郵件內(nèi)容發(fā)送郵件用于最終投遞后者依賴前者生成的草稿ID。把技能間的關(guān)系講清楚誤調(diào)用會(huì)大幅減少。第三檢查是不是上下文里信息不充分。模型無法從對(duì)話里提取技能所需的必填參數(shù)時(shí)會(huì)傾向于不調(diào)用技能。比如用戶只說幫我匯總一下但沒有給任何素材模型不知道拿什么填report_text。這時(shí)候技能側(cè)可以做善意引導(dǎo)把參數(shù)改成可選技能內(nèi)部用提示詞反問用戶補(bǔ)充素材而不是讓模型直接放棄調(diào)用。4.2 參數(shù)頻繁傳錯(cuò)有必要上參數(shù)校驗(yàn)三連參數(shù)層面的問題我的經(jīng)驗(yàn)是做三層校驗(yàn)缺一不可。第一層是Schema硬校驗(yàn)用前面提到的enum、minLength、additionalProperties: false擋掉那些明顯的類型錯(cuò)誤。第二層是語義校驗(yàn)在技能函數(shù)入口寫一些檢查邏輯比如report_text長(zhǎng)度少于10個(gè)字就判定輸入無效因?yàn)檎嬲闹軋?bào)不可能這么短。第三層是修正引導(dǎo)校驗(yàn)不通過時(shí)返回給模型的信息必須是正確填法示例而不只是參數(shù)錯(cuò)誤這幾個(gè)字。舉個(gè)例子實(shí)際測(cè)試中模型曾經(jīng)把contact字段要求填工號(hào)填成了用戶的手機(jī)號(hào)。單純報(bào)錯(cuò)只會(huì)讓模型下一次繼續(xù)猜。后來我在錯(cuò)誤信息里加了正則要求工號(hào)為5位數(shù)字您填寫的值不匹配請(qǐng)?jiān)儐栍脩艄ぬ?hào)后重試模型就能準(zhǔn)確引導(dǎo)用戶補(bǔ)齊信息。說白了給模型的錯(cuò)誤反饋要像給實(shí)習(xí)生反饋一樣具體、可執(zhí)行。4.3 技能執(zhí)行太慢拖垮了整個(gè)對(duì)話Agent場(chǎng)景下用戶可沒有耐心等一個(gè)技能跑10秒。技能耗時(shí)長(zhǎng)主要兩個(gè)原因一是內(nèi)部調(diào)用外部服務(wù)沒做超時(shí)二是返回?cái)?shù)據(jù)量過大序列化傳輸開銷高。處理手段上第一優(yōu)先級(jí)是緩存。我們項(xiàng)目里知識(shí)檢索類技能結(jié)果緩存了15分鐘完全不影響使用體驗(yàn)卻把平均響應(yīng)時(shí)間從4秒壓到不足1秒。第二優(yōu)先級(jí)是異步化。耗時(shí)不敏感的技能可以走異步通道先給用戶一句話正在處理約需要20秒處理完成后主動(dòng)推送結(jié)果很多內(nèi)部工具型Agent都適合這種交互。第三是做好輸出裁剪返給模型的只保留最精煉信息冗余字段一律在技能內(nèi)部消化掉。4.4 技能權(quán)限邊界安全底線不能省技能開發(fā)里還有一個(gè)經(jīng)常被低估的環(huán)節(jié)就是權(quán)限控制。絕對(duì)不能所有技能一個(gè)權(quán)限級(jí)別必須做到最小權(quán)限原則。我見過一個(gè)項(xiàng)目因?yàn)槲臋n管理技能權(quán)限過大模型被誘導(dǎo)讀取了不該訪問的目錄教訓(xùn)很深刻。安全實(shí)踐上技能平臺(tái)層要做三層隔離身份隔離技能調(diào)用者是誰、資源隔離技能能訪問哪些服務(wù)、動(dòng)作隔離技能能執(zhí)行哪些操作寫操作是否需要二次確認(rèn)。像發(fā)送郵件刪除文件轉(zhuǎn)賬這類高風(fēng)險(xiǎn)動(dòng)作應(yīng)該在技能描述里顯式聲明執(zhí)行前必須與用戶確認(rèn)并在技能實(shí)現(xiàn)里強(qiáng)制做二次確認(rèn)邏輯不能只依賴模型自覺。這個(gè)習(xí)慣趁早養(yǎng)成比出事之后補(bǔ)救靠譜得多。關(guān)于技能的迭代我體驗(yàn)最深的一點(diǎn)是不要追求一次性把技能設(shè)計(jì)得完美技能這種東西天生就是要跟模型、跟用戶一起打磨的。上線后盯著日志里的調(diào)用成功率、誤調(diào)用率、參數(shù)錯(cuò)誤率每周迭代一次描述和校驗(yàn)邏輯比憋大招管用得多。等你把一套技能的門面打磨到位會(huì)發(fā)現(xiàn)Agent的整體表現(xiàn)比換更大參數(shù)的模型提升得還明顯——很多團(tuán)隊(duì)總是迷信模型選型卻忽略了下半場(chǎng)的技能工程質(zhì)量這才是Agent落地真正的分水嶺。