1. Agent Skills是什么先從一個(gè)翻車的項(xiàng)目說起去年年中我接手了一個(gè)企業(yè)內(nèi)部知識庫助手需求聽起來不復(fù)雜員工在飛書里問一句上季度的報(bào)銷流程是什么機(jī)器人就得給出準(zhǔn)確答復(fù)順便把相關(guān)表單鏈接甩出來。最開始我走的是當(dāng)時(shí)最流行的路子——把所有業(yè)務(wù)規(guī)則、文檔索引、問答邏輯全部塞進(jìn)一個(gè)巨大的System Prompt里再配上幾個(gè)function calling接口。初版跑起來確實(shí)像那么回事demo演示的時(shí)候管理層還點(diǎn)頭了。但上線第三周就出事了。隨著業(yè)務(wù)文檔從二十篇漲到兩百篇Prompt從三千字膨脹到八千字模型開始頻繁出現(xiàn)幻覺把去年的報(bào)銷標(biāo)準(zhǔn)答成前年的甚至?xí)研菁偕暾埡驼{(diào)休規(guī)則混著答。我試著繼續(xù)往Prompt里加約束結(jié)果就像往沙子里摻水越多越散。后來我徹底放棄了增量修Prompt的方案把架構(gòu)重構(gòu)成基于Agent Skills的技能編排模式——三個(gè)星期后準(zhǔn)確率從76%拉到了94%維護(hù)成本還降了一半。今天這篇就聊聊一個(gè)合格的Agent Skills體系應(yīng)該怎么搭哪些坑我是真金白銀踩出來的。這篇文章適合誰看如果你手上正在做AI客服、Copilot工具、知識庫機(jī)器人或者任何一個(gè)大模型要執(zhí)行多步任務(wù)的項(xiàng)目并且已經(jīng)感受到大Prompt方案越來越難維護(hù)那這篇文章正好解決你的問題。我會先講清楚Skill的底層架構(gòu)邏輯再給出一套能落地的實(shí)現(xiàn)方案最后把我排查過的幾個(gè)真實(shí)翻車現(xiàn)場攤開給你看。2. 為什么大Prompt硬調(diào)這條路必然走死2.1 上下文窗口再大也裝不下整個(gè)業(yè)務(wù)系統(tǒng)很多人的第一反應(yīng)是模型上下文窗口不是有兩百萬token了嗎把所有東西都塞進(jìn)去不就行了這個(gè)想法我在項(xiàng)目里也試過但實(shí)踐下來有三個(gè)繞不開的硬傷。第一個(gè)硬傷是注意力稀釋。模型對Prompt頭部和尾部的內(nèi)容記憶最強(qiáng)中間部分最容易丟失。當(dāng)一份業(yè)務(wù)手冊被塞進(jìn)上下文中間位置時(shí)模型對它的關(guān)注度會顯著下降表現(xiàn)出來就是——規(guī)則明明寫在Prompt里模型卻像沒看見一樣自由發(fā)揮。第二個(gè)硬傷是更新成本。業(yè)務(wù)規(guī)則每個(gè)月都在變每次修改都是對Prompt的一次大手術(shù)改一行字可能引起系統(tǒng)其他部分行為異常而且無從排查。第三個(gè)硬傷最致命——你沒法測試。Prompt越長輸出越不穩(wěn)定同樣的輸入今天能答對明天就答錯回歸測試根本沒法做。2.2 推理與執(zhí)行混在一起必然互相污染我在重構(gòu)前好好想了想為什么大Prompt方案這么脆弱根子上是因?yàn)樗?*推理該做什么和執(zhí)行怎么做**攪在了一起。舉個(gè)例子。知識庫助手的任務(wù)是查報(bào)銷規(guī)則并舉一反三給出注意事項(xiàng)。在舊架構(gòu)里模型要先理解這個(gè)任務(wù)屬于哪個(gè)業(yè)務(wù)域然后在八百行Prompt里定位相關(guān)規(guī)則再決定要不要調(diào)用接口拿最新數(shù)據(jù)最后還要組織語言答給用戶。這四層思考全都發(fā)生在一次推理里任何一個(gè)環(huán)節(jié)狀態(tài)不好整條鏈路就歪了。Agent Skills的思路是把這四層拆開第一步模型只負(fù)責(zé)判斷這問題歸哪個(gè)Skill管第二步Skill內(nèi)部預(yù)先定義好了該怎么辦。判斷是模型的活執(zhí)行是代碼的活兩者不再互相干擾。用大白話說大Prompt模式是讓AI當(dāng)全才實(shí)習(xí)生——每個(gè)任務(wù)都要現(xiàn)場想一遍流程Skill模式是讓AI當(dāng)調(diào)度員——它只負(fù)責(zé)把工單派給合適的老師傅。2.3 可觀測性與可維護(hù)性的鴻溝還有一個(gè)經(jīng)常被忽略的問題是排查故障的效率。大Prompt方案里用戶問一句報(bào)銷比例多少模型答錯了你根本不知道它是在哪一步想錯的是沒定位到規(guī)則是規(guī)則太長讀漏了還是定位對了但輸出時(shí)表達(dá)錯了這不是玄學(xué)這就是架構(gòu)缺陷——你拿不到中間過程的日志能看到的只有輸入和輸出。Skill架構(gòu)天然具備日志切面。模型判斷這個(gè)問題屬于Query_LeavePolicy然后Skill執(zhí)行體去數(shù)據(jù)庫撈數(shù)據(jù)——每一步都有明確的日志節(jié)點(diǎn)。用戶投訴一條答錯的消息我打開鏈路追蹤一眼就能定位是模型選錯了Skill還是Skill里的數(shù)據(jù)查詢出了問題。這個(gè)差異在調(diào)試期還不明顯等業(yè)務(wù)量上來之后就是天壤之別。3. 一個(gè)可用的Agent Skill到底長什么樣3.1 解剖四個(gè)核心組成部分很多人理解的Skill就是給模型多一個(gè)工具這個(gè)認(rèn)知太淺了。一個(gè)真正可用的Skill要包含四個(gè)層次的內(nèi)容缺一個(gè)都容易在生產(chǎn)環(huán)境出問題。第一層是元數(shù)據(jù)Skill Definition。這層負(fù)責(zé)向模型描述這個(gè)Skill叫什么、管什么用、什么情況下該用它、不該用它。這是模型做意圖路由的最關(guān)鍵依據(jù)也是整個(gè)體系里最需要打磨的部分。我見過太多團(tuán)隊(duì)把description寫得太籠統(tǒng)比如處理請假相關(guān)查詢模型根本分不清我明天想休息一天和幫我看看我的年假余額該走哪個(gè)Skill。第二層是輸入Schema。也就是這個(gè)Skill接收哪些參數(shù)每個(gè)參數(shù)的類型、格式、約束條件是什么。這一層決定了模型猜你的接口參數(shù)時(shí)有多容易出錯。我實(shí)測下來的經(jīng)驗(yàn)是參數(shù)越少越好命名越貼合自然語言越好必填項(xiàng)之外的都盡量給默認(rèn)值。第三層是執(zhí)行邏輯。這是Skill真正干活的代碼體——可能是調(diào)用內(nèi)部API可能是拼裝查詢語句可能是觸發(fā)下游工作流也可能只是做一次模板化回答。要注意的是執(zhí)行邏輯里頭還要包含輸入校驗(yàn)和結(jié)果檢查不能假設(shè)模型給的參數(shù)永遠(yuǎn)是合法的。第四層是失敗處理。這是最容易被人忽略、但生產(chǎn)環(huán)境最要命的環(huán)節(jié)。Skill調(diào)用了外部API結(jié)果服務(wù)掛了這時(shí)候是返回兜底回答、重試三次、還是把錯誤反饋給模型讓它換個(gè)思路沒有這層設(shè)計(jì)Skill體系會在真實(shí)流量下被沖垮。3.2 一個(gè)可直接參考的Skill定義示例以我項(xiàng)目里的查假期余額Skill為例它的定義是這樣寫的{ name: query_leave_balance, description: 查詢員工當(dāng)前可用的年假、調(diào)休、病假余額。當(dāng)用戶詢問我還有多少天假年假剩幾天能不能休兩天調(diào)休等涉及具體假期余額數(shù)值的問題時(shí)必須使用本技能。注意本技能只查余額不處理請假申請流程。, parameters: { type: object, properties: { employee_id: { type: string, description: 員工的工號可以從對話上下文中提取若無法確定則默認(rèn)為當(dāng)前會話用戶 }, leave_type: { type: string, enum: [annual, compensatory, sick, all], description: 要查詢的假期類型若用戶未指明則設(shè)為all } }, required: [employee_id] } }注意這個(gè)Skill里我寫了注意本技能只查余額不處理請假申請流程這不是廢話這是在模型路由時(shí)給它一把尺子——防止用戶問我要請假兩天時(shí)模型誤調(diào)用這個(gè)只讀類Skill。在模型能力不夠強(qiáng)的階段這種正向反向約束非常管用。代碼運(yùn)行效果如何需要加入你自己的真實(shí)項(xiàng)目場景來驗(yàn)證。在我實(shí)際系統(tǒng)中Skill執(zhí)行業(yè)務(wù)流程圖如下用戶提問 -- [意圖路由模型] -- 匹配到query_leave_balance -- [參數(shù)抽取] -- employee_id10023, leave_typeall -- [執(zhí)行體] -- 調(diào)用HR系統(tǒng)API -- 獲取結(jié)果 -- [模板化組裝] -- 您的年假余額為7天調(diào)休余額為2天 -- [失敗重試兜底] -- 若API超時(shí)則回復(fù)系統(tǒng)繁忙請稍后再試3.3 路由層怎么選型模型判斷還是規(guī)則優(yōu)先Skill的執(zhí)行邏輯寫好了接下來要解決的問題是模型怎么知道該調(diào)用哪個(gè)Skill這里有兩個(gè)主流方案——純模型路由和規(guī)則兜底模型路由。純模型路由最省事讓大模型讀一遍所有Skill的description然后輸出自己該調(diào)用哪個(gè)。缺點(diǎn)是模型會有概率性抽風(fēng)Skills一多還會互相搶生意。我目前的線上方案是混合式先用非常輕量的規(guī)則層做前置過濾比如會話中檢測到余額剩幾天這類強(qiáng)關(guān)鍵詞直接把候選Skill范圍縮小到兩三個(gè)再把縮小后的候選列表交給模型裁決。這么做的實(shí)測效果是路由準(zhǔn)確率從88%提升到96%而且規(guī)則層邏輯簡單出了問題容易調(diào)。4. 從零構(gòu)建一個(gè)技能庫五步落地實(shí)操4.1 第一步盤點(diǎn)高頻任務(wù)劃清邊界不要一上來就寫代碼先用一個(gè)周末的時(shí)間把業(yè)務(wù)方的歷史提問記錄翻一遍。我當(dāng)時(shí)的做法是把三個(gè)月內(nèi)所有用戶問句拉出來按主題聚類統(tǒng)計(jì)頻率然后給每個(gè)主題寫一句話定義。這里有個(gè)關(guān)鍵經(jīng)驗(yàn)Skill的粒度寧可粗一點(diǎn)也不要切太碎。我剛開始把查年假查調(diào)休查病假拆成了三個(gè)Skill結(jié)果模型頻繁把問題路由錯。后來合并成query_leave_balance一個(gè)Skill、內(nèi)部用參數(shù)區(qū)分假期類型準(zhǔn)確率立刻上來了。Skill粒度怎么判斷我給你一個(gè)標(biāo)準(zhǔn)如果你發(fā)現(xiàn)自己要寫超過三句話來解釋這個(gè)Skill的邊界那它大概率太碎了反過來如果這個(gè)Skill里要寫一排switch case分五六種邏輯那它太胖了應(yīng)該拆。一鏟子下去邊界清清楚楚的才是好Skill。4.2 第二步把description寫成給陌生人看的產(chǎn)品說明這回是Skill工程里最考驗(yàn)功力的環(huán)節(jié)。很多技術(shù)出身的朋友容易把description寫成技術(shù)文檔風(fēng)格——調(diào)用此接口可獲取員工假期余額數(shù)據(jù)但關(guān)鍵問題是模型不是人它要用這段描述來判斷意圖描述寫得好不好直接決定路由質(zhì)量。我總結(jié)了一個(gè)description寫作公式觸發(fā)場景 具體例句 反向排除。觸發(fā)場景是當(dāng)用戶詢問XX時(shí)具體例句是例如我還有多少天假年假剩幾天——例句寧可多寫因?yàn)槟Ｐ蛯唧w句子的理解力遠(yuǎn)比對抽象規(guī)則的理解力強(qiáng)。反向排除是注意本技能只查余額不處理XX情況這個(gè)能顯著降低模型把相似意圖誤判到這個(gè)Skill的概率。4.3 第三步參數(shù)Schema設(shè)計(jì)要克制參數(shù)設(shè)計(jì)的核心思想就兩個(gè)字克制。我踩過的坑是給Skill設(shè)計(jì)了七八個(gè)參數(shù)期望模型一次性把信息全抽出來。結(jié)果模型在抽取時(shí)頻繁出錯缺這個(gè)漏那個(gè)。后來我把參數(shù)縮減到只留關(guān)鍵的兩三個(gè)其余信息交給執(zhí)行體內(nèi)部從上下文或數(shù)據(jù)庫補(bǔ)全。比如查假期余額這個(gè)Skill其實(shí)只有一個(gè)必填參數(shù)——employee_id。leave_type給了默認(rèn)值all。這樣的話模型就算沒聽清用戶要查哪種假也不會調(diào)用失敗。記住每個(gè)必填參數(shù)都是一次潛在的意圖誤判點(diǎn)能省則省。4.4 第四步執(zhí)行體要帶防呆設(shè)計(jì)執(zhí)行體是Skill真正干活的代碼很多人都寫得很直給——拿到參數(shù)直接請求API拿到結(jié)果直接返回。這在真實(shí)生產(chǎn)環(huán)境是大忌。我在重構(gòu)后給所有Skill的執(zhí)行體加了三個(gè)標(biāo)準(zhǔn)件第一個(gè)是輸入預(yù)校驗(yàn)。模型抽出來的employee_id可能帶空格、可能是中文數(shù)字甚至可能跟用戶提的不是同一個(gè)人的工號。我在校驗(yàn)層做了格式清洗、白名單校驗(yàn)不合法就進(jìn)失敗分支。第二個(gè)是結(jié)果結(jié)構(gòu)校驗(yàn)。外部API返回的數(shù)據(jù)未必是預(yù)期的格式特別是HTTP 200但body里是個(gè)錯誤碼這種情況需要顯式判斷。第三個(gè)是降級分支。API超時(shí)、限流、異常都應(yīng)該有對應(yīng)的溫和回復(fù)不能直接把堆棧拋給用戶。這里用Python寫一個(gè)執(zhí)行體骨架你可以直接參考def execute(employee_id: str, leave_type: str) - Result: # 輸入預(yù)校驗(yàn) employee_id validate_employee_id(employee_id) if not employee_id: return Result( statusfailed, reply抱歉我沒有識別到您的工號請確認(rèn)是否已綁定賬戶。 ) # 核心調(diào)用 res hr_api_client.get_leave_balance(employee_id, leave_type) # 結(jié)果結(jié)構(gòu)校驗(yàn) if res.code ! 200 or res.data is None: log.warning(fHR API返回異常: {res}) if res.code 504: return Result(statusfailed, reply系統(tǒng)查詢超時(shí)了請稍后重試) return Result(statusfailed, reply暫時(shí)無法獲取假期余額請稍后再試) # 模板化組裝 balance res.data reply build_reply_message(balance, leave_type) return Result(statusok, replyreply)加的每一層看起來都多余但生產(chǎn)環(huán)境的數(shù)據(jù)辣不辣眼睛只有上線后才知道。沒有這層防呆一個(gè)API偶發(fā)超時(shí)就能讓整個(gè)Agent體系被用戶罵上熱搜。4.5 第五步建立Skill回歸測試集Skill體系的優(yōu)勢之一就是可以做回歸測試。我建了一個(gè)意圖金標(biāo)集從歷史真實(shí)用戶問句里挑出200條人工標(biāo)注好每條應(yīng)該路由到哪個(gè)Skill。每次改完一個(gè)Skill的描述或路由規(guī)則就跑一遍這批測試數(shù)據(jù)看看路由準(zhǔn)確率是升了還是降了。沒有這套機(jī)制你就永遠(yuǎn)不知道改完一個(gè)Skill是不是把另一個(gè)Skill搞掛了。這里有個(gè)實(shí)操細(xì)節(jié)金標(biāo)集需要每隔一兩周補(bǔ)充新問句。用戶總會用你意想不到的話術(shù)提問把帶回來的新case加入測試集路由準(zhǔn)確率才會持續(xù)提升。維護(hù)這個(gè)測試集是我認(rèn)為整個(gè)Skill體系里性價(jià)比最高的一件事。5. 實(shí)測中的翻車現(xiàn)場與排查鏈路5.1 事故一兩個(gè)Skill怎么也分不清上線第一周就出現(xiàn)了一個(gè)詭異現(xiàn)象用戶問報(bào)銷打完款了嗎系統(tǒng)一會兒走查報(bào)銷進(jìn)度Skill一會兒走查報(bào)銷規(guī)則Skill。我在日志里追蹤發(fā)現(xiàn)路由模型在兩個(gè)Skill的description之間反復(fù)橫跳相同的問題今天走A明天走B。排查鏈路是這樣的首先打開鏈路日志確認(rèn)問題確實(shí)出在路由環(huán)節(jié)而不是執(zhí)行環(huán)節(jié)——兩個(gè)Skill都執(zhí)行成功了但選錯的那個(gè)答案牛頭不對馬嘴。然后我把兩個(gè)description拿出來并排看問題立刻暴露了——查報(bào)銷進(jìn)度的description里寫的是處理報(bào)銷相關(guān)查詢而查報(bào)銷規(guī)則寫的是回答報(bào)銷標(biāo)準(zhǔn)相關(guān)問題。模型會認(rèn)為報(bào)銷打完款了嗎既跟進(jìn)度有關(guān)又跟規(guī)則沾邊于是兩邊都在候選區(qū)。修復(fù)方案很簡單把description改成互斥的強(qiáng)烈觸發(fā)詞。查報(bào)銷進(jìn)度只回答錢到哪了、款有沒有打、審批走到哪一步了查報(bào)銷規(guī)則只回答能報(bào)多少、范圍是什么、流程怎么走。改完之后相同問題的路由準(zhǔn)確率從82%升到了99%。教訓(xùn)描述Skill時(shí)痛痛快快地把這個(gè)Skill的場景邊界鎖死不要用模糊的領(lǐng)域詞匯。5.2 事故二模型抽參數(shù)時(shí)過擬合到了錯誤語義有一次用戶問我想用調(diào)休抵半天你看看我這周還能不能請假——這個(gè)問句其實(shí)包含兩個(gè)訴求查調(diào)休余額、順便確認(rèn)能不能請假。我的路由模型正確選到了query_leave_balance但是參數(shù)抽取環(huán)節(jié)把leave_type抽成了sick因?yàn)檎埣賰蓚€(gè)字觸發(fā)了病假聯(lián)想。結(jié)果系統(tǒng)一本正經(jīng)地回答您的病假余額為5天用戶當(dāng)場無語。這個(gè)問題的根因在于參數(shù)抽取的提示詞里給的枚舉含義不夠清晰。我給enum值寫了annual年假、compensatory調(diào)休、sick病假模型確實(shí)沒有理由把請假理解成調(diào)休。修復(fù)辦法是在description里把每個(gè)枚舉值的語義都寫了跨場景例句——當(dāng)用戶提到調(diào)休換休時(shí)使用compensatory——效果立竿見影。參數(shù)枚舉命名的偏差是Agent體系里最容易忽略但實(shí)際頻繁翻車的地方。5.3 事故三Skill內(nèi)部的循環(huán)請求燒穿預(yù)算還有一個(gè)讓我后怕的事故。某個(gè)Skill的執(zhí)行體在調(diào)用外部搜索API時(shí)如果第一次結(jié)果為空代碼里寫了一個(gè)for循環(huán)自動換關(guān)鍵詞重試三次。結(jié)果某個(gè)高峰期搜索API響應(yīng)變慢一批請求全部觸發(fā)了循環(huán)重試單次用戶請求最多發(fā)了12次外部API直接導(dǎo)致合同額度超支。排查鏈路從成本監(jiān)控告警開始拉出計(jì)費(fèi)日志定位到一批search_skill的調(diào)用鏈看到每個(gè)鏈路里都掛了七八次API記錄。修復(fù)方案是給所有外部重試加上總次數(shù)上限、單次超時(shí)和熔斷開關(guān)同時(shí)在Skill執(zhí)行體入口加了一層高峰期限流。這里要提醒一句給執(zhí)行體寫重試邏輯之前一定先做一次極端情況推演——如果外部系統(tǒng)延遲百分之五十我的重試策略會把流量放大幾倍5.4 一套通用的排查方法鏈路日志 回放測試踩了這么多坑之后我沉淀了一套自己的排查流程分享一下先看路由日志確認(rèn)模型選的是不是對的Skill。不是的話問題在意圖路由層。再看參數(shù)日志確認(rèn)抽出來的參數(shù)合不合理。參數(shù)錯了問題在抽取層?？磮?zhí)行日志確認(rèn)執(zhí)行體內(nèi)部的每一步是否按預(yù)期走。用金標(biāo)集回放把出錯的用戶問句喂給同一個(gè)系統(tǒng)確認(rèn)修復(fù)是否生效、有沒有副作用。這四步走一遍大部分問題都能精準(zhǔn)定位。如果你發(fā)現(xiàn)始終定位不到問題那就要回頭檢查是不是Skill的description寫得太模糊導(dǎo)致模型行為本身不穩(wěn)定——這種情況改了日志也查不出花來。6. 從能用到好用技能調(diào)優(yōu)與體系演進(jìn)6.1 多輪對話里的狀態(tài)與記憶是Skill體系的隱藏難點(diǎn)單個(gè)Skill調(diào)好了還不夠多輪對話場景才是真正的分水嶺。用戶說幫我查一下張三年假接著又補(bǔ)了一句順便看看他的調(diào)休——這句話在系統(tǒng)里怎么處理最自然的設(shè)計(jì)是讓上一輪的Skill狀態(tài)延續(xù)下來把第二輪的兩個(gè)參數(shù)合并進(jìn)第一輪的查詢上下文里。我的實(shí)現(xiàn)思路是引入一個(gè)輕量級的會話狀態(tài)槽位第一輪Skill執(zhí)行完后我把參數(shù)和結(jié)果摘要寫回會話槽位第二輪路由模型先看槽位里有啥再決定是新建Skill調(diào)用還是基于槽位信息增量執(zhí)行。說實(shí)話這個(gè)模塊目前還沒有標(biāo)準(zhǔn)答案各家都有自己的實(shí)現(xiàn)方式。我的建議是第一階段別追求通用記憶機(jī)制先把業(yè)務(wù)強(qiáng)相關(guān)的狀態(tài)槽位做好就夠了——比如剛才那種查詢類場景一個(gè)skill_result_slot就能覆蓋絕大多數(shù)需求。6.2 Skill版本管理與團(tuán)隊(duì)協(xié)作當(dāng)你的技能庫超過二十個(gè)Skill并且是三四個(gè)人一起維護(hù)時(shí)版本問題就浮出水面了。我們今天上午剛改完A Skill的路由描述下午發(fā)現(xiàn)B Skill的準(zhǔn)確率掉了——這種狗血劇情我經(jīng)歷了不止一次。落地方案非常樸素但好用每個(gè)Skill的變更必須走Pull Request路由金標(biāo)集測試必須過90%才能合并。Skill的description變更看似是個(gè)小改動但影響的可能是所有路由的決策分布。把改了Skill描述必須附帶金標(biāo)集通過率寫進(jìn)代碼評審清單能擋掉至少一半的踩坑。另外執(zhí)行體代碼和Skill描述文件一定要放在同一個(gè)倉庫同一次發(fā)布里分開管理會出現(xiàn)描述已經(jīng)寫好了代碼還沒部署的中間態(tài)觸發(fā)各種離奇錯誤。6.3 跨Agent的技能共享——下一步的擴(kuò)展方向目前我正在嘗試把Skill抽象成團(tuán)隊(duì)級的共享資產(chǎn)。思路是建一個(gè)內(nèi)部的技能注冊中心每個(gè)Skill定義成一個(gè)帶契約的聲明式文件任何Agent實(shí)例都可以通過注冊中心拉取。這樣新開一個(gè)Agent項(xiàng)目不用從零維護(hù)一套技能庫直接注冊需要的現(xiàn)有Skill即可更多時(shí)間去沉淀新的業(yè)務(wù)技能。這里做一個(gè)小預(yù)告聲明式Skill定義如果能標(biāo)準(zhǔn)化未來的Agent協(xié)作會變得更像樂高拼裝——不同團(tuán)隊(duì)維護(hù)不同的技能模塊上層Agent通過編排把它們組合成完整工作流。到這個(gè)階段Agent不再是單個(gè)系統(tǒng)的附屬品而是一個(gè)可以跨系統(tǒng)復(fù)用的業(yè)務(wù)能力層。這中間的技術(shù)選型比如用JSON Schema還是YAML做契約、要不要引入語義注冊表還在探索中有進(jìn)展了我再寫一篇繼續(xù)分享。最后再補(bǔ)一句個(gè)人體會我在這個(gè)項(xiàng)目里最大的收獲不是技術(shù)方案的升級而是重新理解了架構(gòu)的意義——把需要猜的部分和不需要猜的部分干凈利落地分開永遠(yuǎn)好過在大Prompt里用更多的文本去掩蓋不確定性。Agent Skills的本質(zhì)就是這條原則的工程化落地。