最近半年我陸陸續(xù)續(xù)在電腦上裝了不下十個(gè)AI編程相關(guān)的工具從大家熟悉的對(duì)話式編程助手到跑在終端里的命令行Agent再到各種帶圖形界面的編輯器插件。工具一多問(wèn)題就來(lái)了每個(gè)工具都有自己的“技能”體系有的用Markdown文件有的用規(guī)則目錄有的干脆是代碼模塊。我在A工具里磨好的技能切到B工具就完全失效只能重新配置一遍。被折騰煩了之后我決定動(dòng)手做一個(gè)叫Skills Manager的桌面應(yīng)用思路很簡(jiǎn)單——把所有AI編程工具的Agent技能統(tǒng)一收進(jìn)一個(gè)跨平臺(tái)的桌面中樞里管理再按需分發(fā)到各個(gè)工具。這篇文章就把整個(gè)項(xiàng)目的來(lái)龍去脈、架構(gòu)取舍和踩坑過(guò)程完整記錄下來(lái)。項(xiàng)目一開始的目標(biāo)就很明確統(tǒng)一管理54個(gè)AI編程工具的技能讓技能的定義、存儲(chǔ)、轉(zhuǎn)換、下發(fā)都在一個(gè)應(yīng)用里完成。聽起來(lái)是個(gè)小工具真做起來(lái)牽扯的東西非常多包括技能格式標(biāo)準(zhǔn)化、多端適配、沖突處理、安全邊界這些問(wèn)題。我把項(xiàng)目從零到可用的完整過(guò)程拆開講一遍適合手里同時(shí)用多個(gè)AI編程工具的人、在團(tuán)隊(duì)里負(fù)責(zé)Agent配置的人以及想系統(tǒng)學(xué)習(xí)技能開發(fā)的朋友參考。1. 為什么需要一個(gè)Skills Manager從54工具的技能亂局說(shuō)起1.1 Agent技能生態(tài)的現(xiàn)狀與痛點(diǎn)先說(shuō)說(shuō)我自己的實(shí)際場(chǎng)景。我的日常工作會(huì)同時(shí)接觸三類AI編程工具一類是自帶規(guī)則體系的編輯器插件一類是跑在終端里的自主Agent框架還有一類是偏向?qū)υ捠?、但也能掛載自定義技能包的助手。三者的共同點(diǎn)是都在強(qiáng)調(diào)“技能”這個(gè)概念但實(shí)現(xiàn)方式完全不同。我在終端Agent里維護(hù)的“代碼審查”技能是一份包含詳細(xì)檢查清單的Markdown指令同樣的功能到編輯器插件里要寫成一堆規(guī)則片段換到另一個(gè)框架又變成由多個(gè)腳本和提示詞模板組成的目錄結(jié)構(gòu)。這種割裂帶來(lái)的直接后果有三個(gè)。第一是重復(fù)勞動(dòng)每個(gè)工具都要重新寫一遍技能表面上是在配置本質(zhì)上是在重復(fù)造輪子。第二是維護(hù)成本技能更新時(shí)要同步到所有工具漏掉一個(gè)行為就不一致Agent在前一個(gè)工具里能正確執(zhí)行在另一個(gè)工具里還拿著舊指令做事。第三是難以沉淀個(gè)人慢慢積累的技能庫(kù)沒(méi)法跨工具遷移換工具等于從零開始。GitHub上跟Agent技能相關(guān)的資料已經(jīng)非常多各種框架都在提skills、提提示詞工程但大家都在各搞各的格式生態(tài)非常碎片化。Skills Manager想做的就是在這個(gè)碎片化生態(tài)的上層加一個(gè)統(tǒng)一的調(diào)度面讓技能的定義只寫一次。1.2 桌面中樞要解決的三個(gè)核心問(wèn)題圍繞這個(gè)目標(biāo)項(xiàng)目拆成了三個(gè)核心問(wèn)題統(tǒng)一存儲(chǔ)、格式轉(zhuǎn)換、一鍵同步。統(tǒng)一存儲(chǔ)是先把散落在各個(gè)工具目錄里的技能收攏到一個(gè)地方。我在本機(jī)建了一個(gè)獨(dú)立的技能倉(cāng)庫(kù)目錄所有工具都從這個(gè)倉(cāng)庫(kù)讀取配置而不是各自維護(hù)一份。格式轉(zhuǎn)換是讓一份技能能夠渲染成不同工具認(rèn)識(shí)的“方言”。同一份“代碼審查”技能到A工具是SKILL.md到B工具是rules片段到C工具是帶Schema的模塊轉(zhuǎn)換邏輯全部收在適配層里。一鍵同步是改動(dòng)一處之后按需分發(fā)給所有目標(biāo)工具支持項(xiàng)目級(jí)和全局級(jí)兩種作用范圍。這三個(gè)問(wèn)題解決完工具本身的邊界還是要講清楚Skills Manager不替代Agent不替代各編程工具自己的技能引擎它只管定義、轉(zhuǎn)換、下發(fā)。邊界搞清楚之后后面很多設(shè)計(jì)決策都會(huì)順暢很多因?yàn)槟阒滥男┦虏辉撟约焊伞?. 核心架構(gòu)設(shè)計(jì)與技能格式標(biāo)準(zhǔn)化2.1 技能的最小公約數(shù)統(tǒng)一中間格式怎么定任何涉及“統(tǒng)一”的系統(tǒng)第一步一定是定義中間格式。這個(gè)格式要能表達(dá)幾乎所有工具技能里的共有信息又不能被某一家工具的方言帶偏。我最后定的中間格式叫“技能三要素”元信息名稱、版本、作者、描述、觸發(fā)詞、標(biāo)簽。執(zhí)行體核心指令文本、提示詞模板、腳本或動(dòng)作序列。依賴與資源引用的知識(shí)庫(kù)文件、外部工具命令、MCP服務(wù)聲明、環(huán)境變量占位。用生活里的類比來(lái)說(shuō)把技能理解成一份菜譜就很好懂。元信息是菜名和簡(jiǎn)介告訴別人這道菜是什么、適合什么場(chǎng)合端上來(lái)執(zhí)行體是做法步驟是Agent真正照著做的那部分依賴與資源是食材清單和廚具要求缺了哪樣菜都做不成。任何工具的技能本質(zhì)都是“給Agent的一份菜譜”區(qū)別只是菜譜寫在哪、用什么格式表達(dá)。為什么不能直接用某一家工具的格式當(dāng)標(biāo)準(zhǔn)我試過(guò)后果是其他工具的適配器會(huì)越寫越別扭因?yàn)橐w就那套格式里的隱含假設(shè)。比如某個(gè)框架的技能格式強(qiáng)制要求目錄結(jié)構(gòu)和特定腳本另一家則完全是扁平指令。中間格式越中立適配反而越簡(jiǎn)單。這也是整個(gè)項(xiàng)目里最早定下來(lái)、后期幾乎沒(méi)改過(guò)的設(shè)計(jì)。2.2 技能倉(cāng)庫(kù)目錄規(guī)范與SKILL.md設(shè)計(jì)技能的物理載體我選的是目錄 SKILL.md目錄結(jié)構(gòu)大致如下skill-hub/ skills/ changelog/ SKILL.md templates/ release.md.j2 scripts/ parse_git_log.py code-review/ SKILL.md guides/ checklist.md db-migrate/ SKILL.md registry.json config.toml每個(gè)技能一個(gè)獨(dú)立目錄目錄名就是技能名SKILL.md放在根目錄。SKILL.md的格式是“YAML頭 Markdown正文”也就是frontmatter風(fēng)格。頭部放機(jī)器可讀的元信息正文放Agent需要執(zhí)行的指令內(nèi)容下面是一個(gè)簡(jiǎn)化示例--- name: code-review version: 1.2.0 description: 在提交MR前使用輸入git diff輸出按正確性、性能、安全、可維護(hù)性四類給出問(wèn)題清單每條附文件行號(hào)和修復(fù)建議 trigger: [code review, 審查代碼, review this MR] tags: [dev, quality] dependencies: commands: [git, rg] --- !-- 正文指令 -- 0. 先讀取當(dāng)前分支的完整diff全貌。 1. 按優(yōu)先級(jí)檢查明顯bug 安全問(wèn)題 性能隱患 可維護(hù)性問(wèn)題。 2. 每個(gè)問(wèn)題必須給出文件路徑和行號(hào)。 ...選擇Markdown而不是純JSON或YAML核心原因是“雙重可讀”。Agent被訓(xùn)練成非常擅長(zhǎng)消費(fèi)Markdown指令人類維護(hù)起來(lái)也直觀同時(shí)頭部的YAML又能兼顧機(jī)器解析。這套設(shè)計(jì)思路在現(xiàn)在很多Agent技能包里已經(jīng)能看到影子本質(zhì)都是同一套邏輯。唯一要注意的是frontmatter的解析必須嚴(yán)格后面會(huì)講我在這上面踩過(guò)的坑。2.3 多工具適配層從統(tǒng)一格式到各工具方言有了中間格式和倉(cāng)庫(kù)規(guī)范接下來(lái)就是整個(gè)項(xiàng)目最核心的適配層。這里的架構(gòu)是經(jīng)典的適配器模式每種目標(biāo)工具對(duì)應(yīng)一個(gè)適配器輸入是統(tǒng)一技能對(duì)象輸出是該工具認(rèn)識(shí)的形態(tài)。目標(biāo)工具類型技能載體示例適配器輸出同步方式規(guī)則型編輯器項(xiàng)目規(guī)則目錄 / .rules規(guī)則片段文件寫入項(xiàng)目根目錄Skill型AgentSKILL.md技能目錄目錄拷貝 索引登記拷貝到Agent技能目錄上下文型工具AGENTS.md / 全局指令文檔拼接后的指令文檔寫文件或追加片段函數(shù)調(diào)用型框架技能模塊函數(shù)簽名與參數(shù)Schema生成代碼骨架這張表看起來(lái)簡(jiǎn)單實(shí)際每個(gè)適配器里都有不少細(xì)節(jié)。規(guī)則型編輯器要求片段必須附加在特定文件后面不能覆蓋已有內(nèi)容Skill型Agent要求目錄名與技能名嚴(yán)格一致否則不識(shí)別函數(shù)調(diào)用型框架更麻煩要把技能的執(zhí)行體拆成可調(diào)用的函數(shù)結(jié)構(gòu)并生成對(duì)應(yīng)的參數(shù)Schema。現(xiàn)在市面上已經(jīng)有人開始分發(fā)各種技能包比如網(wǎng)盤下載的Skill包、某個(gè)安全方向的技能包合集但下載下來(lái)往往只能給特定工具用。把這類外部技能包裝進(jìn)Skills Manager正是適配層最有價(jià)值的地方——你不用關(guān)心它原來(lái)是哪個(gè)工具的格式導(dǎo)進(jìn)來(lái)轉(zhuǎn)一下就能推給其他工具。3. 實(shí)操過(guò)程從零搭建Skills Manager桌面端3.1 桌面端技術(shù)選型為什么選Tauri項(xiàng)目的載體我最終選的是桌面應(yīng)用而不是純Web服務(wù)原因很直接技能管理涉及本地文件讀寫、目錄監(jiān)聽、編輯級(jí)操作體驗(yàn)放本地最自然。而且技能本身可能包含個(gè)人偏好的指令和腳本路徑本地處理能避免把敏感配置傳到遠(yuǎn)端。在Electron和Tauri之間我猶豫過(guò)一陣但實(shí)測(cè)完一個(gè)Electron原型后果斷放棄空殼內(nèi)存占用輕松超過(guò)200MB而我電腦上常年開著幾個(gè)IDE實(shí)在扛不住。Tauri的做法是后端用Rust、前端套系統(tǒng)WebView內(nèi)存占用低很多打包體積也比較小。初始化項(xiàng)目很簡(jiǎn)單幾條命令的事npm create tauri-applatest skills-manager cd skills-manager npm install npm run tauri devTauri v2的權(quán)限模型比v1嚴(yán)格這點(diǎn)我反而喜歡。所有文件系統(tǒng)訪問(wèn)都要在capabilities里顯式聲明比如只允許讀寫skill-hub目錄不允許全盤掃描。這種“最小授權(quán)”的思路和后面講技能權(quán)限設(shè)計(jì)是完全一致的。如果你只是想跑通流程記得在capabilities里加上對(duì)應(yīng)目錄的讀寫權(quán)限否則前端怎么調(diào)都沒(méi)反應(yīng)。3.2 技能注冊(cè)表與索引構(gòu)建桌面端跑起來(lái)之后第一件要做的事是構(gòu)建技能注冊(cè)表。啟動(dòng)時(shí)掃描skill-hub/skills目錄逐個(gè)解析SKILL.md的frontmatter生成一份registry.json索引。解析邏輯用Rust實(shí)現(xiàn)配合gray_matter和serde_yaml核心代碼大概是這樣的#[derive(Deserialize)] struct SkillMeta { name: String, version: String, description: String, trigger: VecString, tags: VecString, } fn parse_skill(path: Path) - ResultSkillMeta, Error { let raw std::fs::read_to_string(path)?; let matter gray_matter::Matter::new().parse(raw)?; let meta: SkillMeta serde_yaml::from_str(matter.data.as_str())?; Ok(meta) }索引構(gòu)建完之后能做很多直接在文件系統(tǒng)層面做不了的事情。按工具過(guò)濾快速看這個(gè)技能當(dāng)前哪些工具可用按標(biāo)簽分組把“代碼生成”“數(shù)據(jù)庫(kù)”“測(cè)試”“文檔”分類整理好。很多人反映“技能包里沒(méi)有OCR類技能”本質(zhì)上不是沒(méi)有而是技能庫(kù)沒(méi)有做好分類和發(fā)現(xiàn)裝完就沉在目錄里了。Skills Manager在索引層就解決了這個(gè)問(wèn)題搜索結(jié)果直接展示技能描述和適用工具。全文檢索也很有用不只是匹配標(biāo)簽description和指令正文都進(jìn)檢索引擎哪怕你只記得一句指令里的關(guān)鍵詞也能把整個(gè)技能撈出來(lái)。3.3 跨平臺(tái)與同步機(jī)制跨平臺(tái)這件事說(shuō)實(shí)話比預(yù)想的坑多。Windows、macOS、Linux三個(gè)系統(tǒng)間的路徑分隔符、大小寫敏感、換行符全是細(xì)節(jié)問(wèn)題。我的處理原則是注冊(cè)表里一律存相對(duì)路徑運(yùn)行時(shí)再拼當(dāng)前平臺(tái)的實(shí)際路徑文件監(jiān)聽用Rust生態(tài)的notify crate但每次都加上debounce否則批量寫技能時(shí)會(huì)觸發(fā)一大波事件白白浪費(fèi)性能。同步是項(xiàng)目的主菜。整個(gè)同步管線可以概括成下面這段偽代碼邏輯for each enabled_target in config.targets: for each skill in registry: renderer get_adapter(target.kind) output renderer.render(skill) write_with_atomic(output, target.path)這里有個(gè)很關(guān)鍵的小細(xì)節(jié)寫入必須用“原子寫”也就是先寫臨時(shí)文件再改名替換。為什么要這樣因?yàn)锳gent可能在任何時(shí)刻讀取技能文件如果它讀到半截寫入的內(nèi)容輕則技能加載失敗重則執(zhí)行出莫名其妙的結(jié)果。同類的教訓(xùn)還很多經(jīng)驗(yàn)就是凡是給Agent提供的文件寫入操作都要保證一致性不能讓讀端見到中間態(tài)。沖突處理最初只有“覆蓋”后來(lái)發(fā)現(xiàn)不行。兩個(gè)技能包都提供code-review版本不一樣盲覆蓋會(huì)把另一份有效技能弄丟?，F(xiàn)在改成以版本號(hào)和修改時(shí)間為依據(jù)沖突時(shí)在界面上列出兩份技能的差異由用戶決定保留哪邊或者干脆兩邊都留著、隨時(shí)切換。這個(gè)交互雖然多了一步但換來(lái)了安心。4. 技能編排實(shí)戰(zhàn)讓Agent真正“會(huì)用”技能4.1 技能描述與觸發(fā)詞的寫法格式轉(zhuǎn)換解決的是工具“認(rèn)得出”技能但真正決定Agent“想不想用”的是技能描述和觸發(fā)詞的質(zhì)量。這一部分我花的時(shí)間最多也最想分享。先說(shuō)description。很多人寫的是“Performs code review”這種一句話太籠統(tǒng)了Agent看到根本不知道什么時(shí)候該用。我推薦寫成“場(chǎng)景 輸入 輸出 規(guī)范”的結(jié)構(gòu)什么時(shí)候用、輸入是什么、輸出是什么格式、必須遵守什么規(guī)則。比如在提交MR之前使用。輸入是當(dāng)前分支相對(duì)主干分支的git diff 輸出按正確性、性能、安全、可維護(hù)性四類給出一份問(wèn)題清單 每條必須包含文件路徑、行號(hào)和可執(zhí)行的修復(fù)建議。這樣的描述放到技能列表里Agent一讀到就知道哦這個(gè)技能是干這件事的現(xiàn)在這個(gè)場(chǎng)景匹配上了該調(diào)用它。觸發(fā)詞也不是死匹配幾個(gè)關(guān)鍵詞那么簡(jiǎn)單?，F(xiàn)實(shí)里用戶說(shuō)話千奇百怪說(shuō)“幫我看看這段代碼”的時(shí)候意圖可能正是代碼審查。所以觸發(fā)詞要把常見等價(jià)問(wèn)法都寫上別只寫“code review”。我維護(hù)技能時(shí)有個(gè)習(xí)慣每次在聊天里看到Agent沒(méi)調(diào)起預(yù)期技能就回去把用戶的原話補(bǔ)進(jìn)觸發(fā)詞一兩個(gè)星期下來(lái)命中率提升非常明顯。4.2 參數(shù)校驗(yàn)、權(quán)限與安全邊界技能一旦帶了腳本輸入校驗(yàn)就變得極其關(guān)鍵。一段來(lái)自用戶的文本如果直接拼進(jìn)shell命令后果可大可小。我在Skills Manager里做三層防護(hù)參數(shù)模板聲明每個(gè)參數(shù)的類型、枚舉值、正則約束不匹配就不執(zhí)行。預(yù)檢機(jī)制執(zhí)行前先檢查依賴命令是否存在、目標(biāo)路徑是否合理、是否在沙盒允許的范圍內(nèi)。最小權(quán)限技能在元信息里聲明自己需要哪些權(quán)限管理器按聲明授權(quán)沒(méi)聲明的一律拒絕。聊到沙盒就繞不開“agent execution terminated due to error”這個(gè)經(jīng)典報(bào)錯(cuò)。我一開始以為這是Agent能力問(wèn)題后來(lái)排查多了發(fā)現(xiàn)絕大多數(shù)是技能執(zhí)行環(huán)境缺東西目錄不在白名單里、命令不存在、沒(méi)有網(wǎng)絡(luò)訪問(wèn)權(quán)限。這些問(wèn)題完全能在預(yù)檢階段提前暴露而不是等Agent跑到一半才報(bào)錯(cuò)。Skills Manager在技能激活前會(huì)跑一遍預(yù)檢把缺的命令、缺失的依賴直接列出來(lái)省掉了大量無(wú)意義的排障時(shí)間。安全邊界還有一條容易被忽略不要把密鑰和Token寫進(jìn)技能文件。技能是會(huì)被同步到多個(gè)工具、甚至?xí)环胚M(jìn)Git倉(cāng)庫(kù)的東西一旦密鑰進(jìn)去泄露面就不可控了。我自己的做法是技能里只留環(huán)境變量占位符真實(shí)密鑰由運(yùn)行時(shí)代管注入。4.3 技能調(diào)試的通用套路技能調(diào)試現(xiàn)在有一套相對(duì)固定的流程遇到問(wèn)題按順序排查基本都能定位打開Agent的verbose模式先確認(rèn)技能有沒(méi)有被加載、有沒(méi)有被調(diào)用、輸出斷在哪一步。做最小復(fù)現(xiàn)把技能內(nèi)容截?cái)嗟阶詈?jiǎn)確認(rèn)問(wèn)題是指令本身還是腳本問(wèn)題。看日志和退出碼沙盒報(bào)錯(cuò)要區(qū)分是超時(shí)、缺依賴還是權(quán)限不足。用dry-run模式跑一遍技能輸出檢查生成的目標(biāo)文件是否符合預(yù)期。這套流程里最容易被人忽略的是“技能文件編碼和換行符”。我踩過(guò)一個(gè)大坑技能文件在Windows上編輯后換行符變成CRLF拿到Linux下給Agent用某些解析frontmatter的庫(kù)直接罷工技能從頭到尾沒(méi)被加載。你在界面上看技能列表里明明有它但Agent那邊就是沒(méi)反應(yīng)查了半天才發(fā)現(xiàn)是換行符的鍋。這種問(wèn)題不進(jìn)排查清單真的很難想到。5. 常見問(wèn)題與排查技巧實(shí)錄5.1 技能加載失敗的幾種典型情況現(xiàn)象可能原因處理辦法Agent完全不認(rèn)技能目錄名或SKILL.md位置不符合規(guī)范檢查命名規(guī)范SKILL.md必須放在技能根目錄技能在列表里但調(diào)用不到description太泛觸發(fā)詞覆蓋不夠按4.1的結(jié)構(gòu)重寫描述與觸發(fā)詞加載時(shí)提示yaml解析錯(cuò)誤frontmatter縮進(jìn)、引號(hào)有問(wèn)題用解析器本地校驗(yàn)別等Agent報(bào)錯(cuò)中文內(nèi)容亂碼或被截?cái)辔募皇荱TF-8或存在BOM頭統(tǒng)一UTF-8無(wú)BOM檢查編輯器默認(rèn)編碼5.2 路徑、權(quán)限與編碼的隱藏坑路徑問(wèn)題在同步時(shí)特別突出。技能里寫死絕對(duì)路徑是最危險(xiǎn)的因?yàn)槟阋詾榈穆窂胶湍繕?biāo)工具的工作目錄可能完全不一樣。我的習(xí)慣是所有內(nèi)部引用一律相對(duì)路徑適配器輸出時(shí)再根據(jù)目標(biāo)工具的現(xiàn)狀做轉(zhuǎn)換。路徑帶空格和中文也要注意操作系統(tǒng)層面通常沒(méi)問(wèn)題但某些工具的解析器在空格處理上很敏感。權(quán)限聲明不匹配是另一個(gè)常見坑。Tauri里capabilities配置不完整技能目錄寫了卻沒(méi)有任何效果前端調(diào)用后端文件操作全部靜默失敗。排查這類問(wèn)題要養(yǎng)成看控制臺(tái)日志的習(xí)慣特別是權(quán)限相關(guān)的錯(cuò)誤它往往不會(huì)彈窗提示。文件監(jiān)聽漏事件也值得一提。批量同步時(shí)如果不對(duì)監(jiān)聽事件做debounce會(huì)把一次同步拆成幾十次觸發(fā)前端界面卡頓后端還要反復(fù)重建索引。加一個(gè)200毫秒的合并窗口問(wèn)題立刻消失。5.3 技能沖突與優(yōu)先級(jí)管理同名技能沖突是多人協(xié)作場(chǎng)景最常見的麻煩。兩個(gè)團(tuán)隊(duì)分別維護(hù)了一套“數(shù)據(jù)庫(kù)遷移”技能版本號(hào)還都是1.0合到一起就打架。我的處理原則是這樣的項(xiàng)目級(jí)技能優(yōu)先于全局級(jí)技能因?yàn)轫?xiàng)目?jī)?nèi)配置的針對(duì)性更強(qiáng)高版本優(yōu)先于低版本但要在界面里標(biāo)注來(lái)源讓用戶知道這是自動(dòng)選擇真沖突時(shí)保留兩個(gè)版本應(yīng)用內(nèi)提供顯式切換絕不偷偷覆蓋。這里還要把技能和記憶的關(guān)系講清楚。很多人把Agent的長(zhǎng)期記憶和技能混為一談其實(shí)邊界很明確記憶存的是對(duì)話狀態(tài)和事實(shí)比如“這個(gè)項(xiàng)目的測(cè)試命令是pytest”技能存的是方法的可復(fù)用定義比如“如何系統(tǒng)性地寫測(cè)試”。Skills Manager只管理技能不碰記憶。一旦把這兩個(gè)職責(zé)耦合進(jìn)同一個(gè)系統(tǒng)狀態(tài)同步和數(shù)據(jù)一致性會(huì)變得極其復(fù)雜最后維護(hù)成本會(huì)吃掉所有收益。6. 后續(xù)擴(kuò)展方向MCP、版本管理與技能市場(chǎng)6.1 Skills與MCP的邊界與互補(bǔ)MCP這個(gè)概念火起來(lái)之后有朋友問(wèn)我技能是不是要被MCP替代了我的理解是兩者解決的問(wèn)題并不一樣。MCP解決的是Agent怎么調(diào)用外部工具和數(shù)據(jù)源是一套連接協(xié)議技能解決的是Agent在特定任務(wù)里怎么組織自己的行為是一套指令與流程的封裝。實(shí)際使用中兩者經(jīng)常配合一個(gè)技能的執(zhí)行體里完全可以聲明“這個(gè)步驟通過(guò)MCP調(diào)用某個(gè)服務(wù)”。Skills Manager在技能模型里加了一層MCP聲明讓技能在需要外部能力時(shí)能自動(dòng)掛載對(duì)應(yīng)的MCP連接。這樣一來(lái)項(xiàng)目從“管理指令”升級(jí)成了“管理Agent的完整工作方式”但兩者的邊界依然清晰。6.2 技能版本管理與團(tuán)隊(duì)共享技能本質(zhì)上是一份會(huì)持續(xù)演進(jìn)的資產(chǎn)版本管理就必不可少。我現(xiàn)在的做法是直接用Git倉(cāng)庫(kù)托管整套技能集CI里跑格式校驗(yàn)和渲染測(cè)試任何改動(dòng)能自動(dòng)驗(yàn)證“這份技能在所有目標(biāo)工具下都能正常渲染”。技能版本號(hào)跟隨語(yǔ)義化版本規(guī)則主版本號(hào)變化代表行為不兼容次要版本代表新增能力補(bǔ)丁版本就是修修補(bǔ)補(bǔ)。團(tuán)隊(duì)共享的另一個(gè)關(guān)鍵是評(píng)審機(jī)制。技能變更走M(jìn)R和改代碼一樣有人看、有人評(píng)審、有記錄。這聽起來(lái)很重但技能是對(duì)Agent行為影響最大的東西一次壞的技能變更會(huì)讓整個(gè)團(tuán)隊(duì)的Agent集體抽風(fēng)。經(jīng)過(guò)這幾輪折騰我現(xiàn)在最大的體會(huì)是不要一開始就追求支持54個(gè)工具挑兩三個(gè)主力工具先把流程跑通再慢慢擴(kuò)展適配器技能維護(hù)的頻率比數(shù)量重要一個(gè)持續(xù)更新的核心技能集遠(yuǎn)比一百個(gè)吃灰的舊技能有價(jià)值。最后分享一個(gè)小技巧如果不知道從哪個(gè)技能開始沉淀就做“生成CHANGELOG”。這個(gè)技能幾乎在所有編程工具里都用得上跨工具遷移價(jià)值最高用它把整個(gè)管線的各個(gè)環(huán)節(jié)調(diào)通之后再往倉(cāng)庫(kù)里加別的技能就順了。