最近在整理 AI Agent 相關(guān)技術(shù)方案時(shí)頻繁看到 Addy Osmani 這個(gè)名字。作為 Google Chrome 團(tuán)隊(duì)的前端工程經(jīng)理他出品的不少技術(shù)資料在 GitHub 上都相當(dāng)有分量。這次要拆解的項(xiàng)目是一個(gè) GitHub 上 7.9 萬(wàn) Star 的生產(chǎn)級(jí) agent skill 合集排在本月熱門 S2 榜單第 6 位可以說(shuō)是 AI 工程化領(lǐng)域不可忽略的參考資源。本文將圍繞這個(gè)項(xiàng)目展開先講清楚 agent 與 skill 的關(guān)系再拆解生產(chǎn)級(jí) skill 應(yīng)當(dāng)具備的結(jié)構(gòu)最后基于項(xiàng)目思路給出可復(fù)用的實(shí)戰(zhàn)流程。無(wú)論你是剛接觸 AI Agent 的開發(fā)者還是已經(jīng)在做企業(yè)級(jí)智能體落地的工程師這篇文章都能提供一條清晰的行動(dòng)路徑。1. 背景與核心概念為什么 agent skill 會(huì)火起來(lái)1.1 什么是 agent skillAgent skill 可以理解為給 AI 智能體準(zhǔn)備的“可復(fù)用能力包”。它通常包含一份結(jié)構(gòu)化的說(shuō)明文檔、若干示例、約束規(guī)則以及可選的工具調(diào)用框架目的是讓 Agent 在特定業(yè)務(wù)場(chǎng)景下能穩(wěn)定、可預(yù)期地完成一類任務(wù)。舉個(gè)例子如果希望 AI 助手能幫團(tuán)隊(duì)完成代碼審查不需要每次都寫一段很長(zhǎng)的“請(qǐng)你檢查代碼”提示詞而是準(zhǔn)備一個(gè)code-review-skill目錄里面寫好審查規(guī)范、檢查清單、輸出格式甚至附上幾個(gè)歷史案例。Agent 在執(zhí)行任務(wù)時(shí)會(huì)讀取這個(gè) skill像專業(yè)工程師一樣按照固定流程完成工作。之所以說(shuō)它是“生產(chǎn)級(jí)”核心在于它不僅關(guān)注單次對(duì)話效果還關(guān)注輸入輸出穩(wěn)定性、失敗處理、可維護(hù)性和團(tuán)隊(duì)協(xié)作效率。相比臨時(shí)拼湊的提示詞生產(chǎn)級(jí) skill 更接近代碼工程。1.2 Agent、Skill 與 Prompt 之間的關(guān)系這里有必要區(qū)分幾個(gè)容易被混用的概念概念定位舉例Prompt一段指令文本“請(qǐng)寫一個(gè) Python 函數(shù)”Skill結(jié)構(gòu)化的能力包代碼審查規(guī)則 示例 輸出模板Agent會(huì)調(diào)用 skill 的智能體能根據(jù)任務(wù)自動(dòng)選擇 code-review-skill 的助手可以這么理解Prompt 是一次性的對(duì)話輸入Skill 是可復(fù)用的“領(lǐng)域插件”Agent 是真正思考、規(guī)劃、執(zhí)行的主體。Skill 是 Agent 與具體業(yè)務(wù)之間的橋梁讓 Agent 不用每次從零理解需求。在 Addy Osmani 的項(xiàng)目中skill 被整理得非常規(guī)范每個(gè) skill 都像一個(gè)小型 npm 包有元信息、核心邏輯、測(cè)試用例這給團(tuán)隊(duì)內(nèi)部沉淀 AI 能力提供了很好的參考。1.3 為什么開發(fā)者需要掌握生產(chǎn)級(jí) skill在一次生產(chǎn)環(huán)境 AI 項(xiàng)目落地中我遇到過(guò)這樣的情況讓 AI 自動(dòng)生成數(shù)據(jù)庫(kù)變更腳本開發(fā)者在提示詞里寫了很多要求但 AI 仍然會(huì)偶爾生成不帶 WHERE 條件的 DELETE 語(yǔ)句。這就是只依賴 Prompt 的典型風(fēng)險(xiǎn)。生產(chǎn)級(jí) skill 的價(jià)值就在這里它把約束前置、把驗(yàn)證閉環(huán)、把失敗兜底真正讓 AI 在可控范圍內(nèi)工作。這也是 Addy Osmani 這個(gè)項(xiàng)目能收獲近 8 萬(wàn) Star 的根本原因——它不是講概念而是提供了可以直接拿到業(yè)務(wù)里用的工程化方案。2. 環(huán)境準(zhǔn)備與版本說(shuō)明在實(shí)際操作項(xiàng)目之前需要先準(zhǔn)備本地的運(yùn)行環(huán)境。這個(gè)項(xiàng)目主要依賴 Git、Node.js 以及一個(gè)支持 skill 機(jī)制的 AI Agent 客戶端比如 Claude Code、Cursor 或結(jié)合 OpenClaude 這類工具。這里的版本信息需要特別說(shuō)明項(xiàng)目迭代較快AI 工具鏈的兼容性變化也比較頻繁所以不要追求固定版本。以我當(dāng)前使用的環(huán)境為例操作系統(tǒng)macOS 15.x / Ubuntu 22.04 / Windows 11 均可 Git2.30 以上 Node.js18 或 20 LTS 版本 AI Agent 客戶端Claude Code 或兼容 skill 機(jī)制的客戶端在開始前請(qǐng)確認(rèn) Git 已經(jīng)正常配置git --version node -v如果系統(tǒng)里還沒(méi)有安裝相關(guān)工具建議先完成安裝再繼續(xù)。項(xiàng)目倉(cāng)庫(kù)本身并不復(fù)雜核心是理解它目錄組織方式而不是必須運(yùn)行復(fù)雜的構(gòu)建流程。3. 項(xiàng)目結(jié)構(gòu)拆解一個(gè)生產(chǎn)級(jí) skill 長(zhǎng)什么樣3.1 項(xiàng)目整體目錄劃分從 GitHub 倉(cāng)庫(kù)的根目錄看這個(gè)項(xiàng)目遵循了非常清晰的“分類 獨(dú)立模塊”組織方式。目錄結(jié)構(gòu)大致如下agent-skills/ ├── README.md ├── skills/ │ ├── code-review/ │ │ ├── SKILL.md │ │ ├── examples/ │ │ └── checks/ │ ├──>--- name: code-review description: Perform a systematic code review for pull requests version: 1.0.0 --- ## Objective Review the given diff and provide actionable feedback. ## Steps 1. Read the diff carefully. 2. Check for security issues, performance problems, and correctness. 3. Validate against the teams coding standards. 4. Write feedback with severity levels. ## Constraints - Do NOT modify the source code directly. - If the diff contains credentials, stop and report immediately. ## Output Format \\\markdown ## Review Summary - Overall: PASS / NEEDS_CHANGES ## Issues - [HIGH] description - [MEDIUM] description ## Suggestions - suggestion \\\這種結(jié)構(gòu)看起來(lái)簡(jiǎn)單但實(shí)際落地時(shí)效果特別明顯。它把標(biāo)準(zhǔn)、流程、輸出都固定下來(lái)了即使不同的人來(lái)用AI 產(chǎn)出的結(jié)果風(fēng)格也高度一致。3.3 為什么這套結(jié)構(gòu)能稱為“生產(chǎn)級(jí)”生產(chǎn)級(jí)并不是說(shuō)代碼寫得多么高深而是指它考慮了真實(shí)業(yè)務(wù)環(huán)境中會(huì)遇到的問(wèn)題。第一容錯(cuò)性。Skill 里明確寫了“如果 diff 中包含憑據(jù)立即停止并上報(bào)”這就是把 P0 級(jí)事故擋在發(fā)生之前。第二可測(cè)試性。項(xiàng)目里為每個(gè) skill 都附帶了校驗(yàn)?zāi)_本或檢查清單Agent 執(zhí)行完會(huì)自動(dòng)對(duì)照檢查減少“看起來(lái)不錯(cuò)但實(shí)際不能用”的尷尬。第三可維護(hù)性。因?yàn)?skill 的輸入、輸出、步驟都是結(jié)構(gòu)化定義的后續(xù)更新只需要改對(duì)應(yīng)模塊而不需要大規(guī)模重寫提示詞。第四知識(shí)沉淀。每個(gè) skill 可以附帶多個(gè) examples這些 examples 實(shí)際上是團(tuán)隊(duì)業(yè)務(wù)經(jīng)驗(yàn)的編碼化表達(dá)。老工程師的審查思路、運(yùn)維專家的排查順序都可以這樣傳承。4. 實(shí)戰(zhàn)篇用 skill 機(jī)制構(gòu)建一個(gè)代碼審查助手4.1 場(chǎng)景設(shè)定假設(shè)你所在的團(tuán)隊(duì)每周有大量 Pull Request 需要人工審查審查質(zhì)量參差不齊。我們希望基于 Addy Osmani 項(xiàng)目的 skill 思路在本地搭建一個(gè)“代碼審查助手”讓 Agent 能自動(dòng)完成大部分機(jī)械性審查工作同時(shí)把風(fēng)險(xiǎn)控制在一定范圍內(nèi)。這不是一個(gè)完整的商業(yè)系統(tǒng)而是一個(gè)伸手就能跑通的本地原型。如果你只需要審查單個(gè)文件甚至可以把完整流程壓縮為幾步。4.2 創(chuàng)建項(xiàng)目結(jié)構(gòu)我們先在本地創(chuàng)建一個(gè)項(xiàng)目目錄mkdir my-agent-skills cd my-agent-skills mkdir -p skills/code-review/examples接著在skills/code-review目錄下創(chuàng)建SKILL.md內(nèi)容可以直接復(fù)用第 3 節(jié)給出的模板也可以按團(tuán)隊(duì)風(fēng)格做調(diào)整。這里我提供一個(gè)稍完整的版本--- name: code-review description: Review a JavaScript or Python code diff for common issues version: 1.0.0 --- ## Context This skill helps an AI agent review code diffs for quality, security, and performance issues. ## Workflow 1. Identify the programming language from the diff. 2. Check for the following categories: - Security risks - Potential runtime errors - Code style violations - Performance bottlenecks 3. Classify each issue by severity: HIGH, MEDIUM, LOW. 4. Return a concise report. ## Rules - Always quote the exact code snippet when reporting an issue. - Propose a concrete fix for each HIGH issue. - If the diff contains API keys or passwords, mark it as BLOCKER. - Do not rewrite the whole file, only highlight issues. ## Output Format Report in the following structure: ### Summary {APPROVE | REQUEST_CHANGES} ### Findings | Severity | Location | Issue | Suggestion | | --- | --- | --- | --- | | HIGH | line 12 | SQL injection risk | Use parameterized queries |4.3 編寫一個(gè)簡(jiǎn)單的 skill 加載器接下來(lái)寫一個(gè)小工具讓 Agent 在啟動(dòng)時(shí)能加載這個(gè) skill 內(nèi)容。這里用 Node.js 實(shí)現(xiàn)一個(gè)最小加載器便于在本地驗(yàn)證機(jī)制// 文件路徑tools/skill-loader.js const fs require(fs); const path require(path); /** * 從 skills 目錄加載一個(gè) skill 的 SKILL.md * param {string} skillName - 技能名稱 * returns {string} skill 文件內(nèi)容 */ function loadSkill(skillName) { const skillPath path.join(__dirname, ../skills, skillName, SKILL.md); try { return fs.readFileSync(skillPath, utf-8); } catch (err) { console.error([skill-loader] Failed to load skill: ${skillName}); process.exit(1); } } const skillName process.argv[2]; if (!skillName) { console.error(Usage: node skill-loader.js skill-name); process.exit(1); } const content loadSkill(skillName); console.log( Loaded skill ); console.log(content);運(yùn)行方式node tools/skill-loader.js code-review如果一切正常你會(huì)在控制臺(tái)看到完整的SKILL.md內(nèi)容。這個(gè)加載器雖然簡(jiǎn)陋但它體現(xiàn)了 skill 機(jī)制的核心——把能力包以文件形式組織按需加載。4.4 模擬 Agent 調(diào)用 skill 的流程真實(shí)場(chǎng)景中Agent 會(huì)通過(guò)客戶端工具讀取SKILL.md然后結(jié)合 diff 內(nèi)容執(zhí)行審查。這里我們用一個(gè)模擬腳本演示完整流程// 文件路徑scripts/run-code-review.js const fs require(fs); const skillLoader require(../tools/skill-loader); const fakeDiff const db require(db); const userId req.query.userId; const sql SELECT * FROM users WHERE id userId; db.query(sql, (err, result) { res.send(result); }); ; function reviewWithSkill(skillContent, diff) { // 真實(shí)場(chǎng)景中這里會(huì)調(diào)用 LLM API // 這里僅模擬結(jié)果 console.log(--- Reviewing diff with skill ---); console.log(skillContent.split(\n)[0]); console.log(--- Diff content ---); console.log(diff); const hasPotentialInjection diff.includes(req.query) diff.includes( userId); if (hasPotentialInjection) { console.log(Result: REQUEST_CHANGES); console.log(Issue: Potential SQL injection detected, use parameterized queries.); } else { console.log(Result: APPROVE); } } const skillContent skillLoader.loadSkill(code-review); reviewWithSkill(skillContent, fakeDiff);運(yùn)行node scripts/run-code-review.js這里并不真正調(diào)用 LLM而是把 diff 傳入后模擬規(guī)則判斷。實(shí)際落地時(shí)你可以將SKILL.md內(nèi)容拼接到用戶提示詞前面或者通過(guò)支持工具調(diào)用的 Agent 框架直接加載。4.5 接入真實(shí) AI Agent如果要接入 Claude Code 這類工具思路是類似的。你可以把 skill 文件路徑配置到 Agent 的上下文目錄然后在對(duì)話開始時(shí)先輸入請(qǐng)加載 skills/code-review 下的 SKILL.md然后按該 skill 的要求審查以下代碼 diffAgent 會(huì)讀取規(guī)則再按規(guī)則輸出。如果 Agent 客戶端支持 skill 插件機(jī)制也可以直接把 skill 注冊(cè)為可調(diào)用工具。這樣后續(xù)每次審查都能保持同一種格式和檢查標(biāo)準(zhǔn)。這也回答了很多人關(guān)心的一個(gè)問(wèn)題skill 并不是某個(gè)特定平臺(tái)的專屬功能而是一種通用的結(jié)構(gòu)化思想只要你能讓 Agent 穩(wěn)定讀取并遵守規(guī)則任何客戶端都可以落地。5. 進(jìn)階實(shí)戰(zhàn)從零編寫你自己的生產(chǎn)級(jí) skill5.1 確定 skill 邊界動(dòng)手寫 skill 之前最重要的一步是劃定邊界。建議一個(gè) skill 只負(fù)責(zé)一個(gè)完整子任務(wù)。比如“代碼審查”是一個(gè) skill“數(shù)據(jù)庫(kù)遷移腳本生成”是另一個(gè)不要把兩件事混在一起。邊界清晰的 skill 有這些好處容易測(cè)試單獨(dú)驗(yàn)證成功率。容易定位問(wèn)題失敗時(shí)能快速知道是哪個(gè)環(huán)節(jié)出了問(wèn)題。方便團(tuán)隊(duì)協(xié)作不同人負(fù)責(zé)不同 skill。5.2 編寫模板與示例創(chuàng)建templates/basic-skill/SKILL.md作為團(tuán)隊(duì)模板這能讓后續(xù)新增 skill 保持一致質(zhì)量。模板可以這樣寫--- name: {skill-name} description: {short description of what this skill does} version: 0.1.0 --- ## Objective {Describe the exact goal of this skill.} ## When To Use {Define the trigger conditions.} ## Workflow 1. {Step one} 2. {Step two} 3. {Step three} ## Input Requirements {What information is required from the user or environment.} ## Output Requirements {Define the exact output format.} ## Failure Handling {What to do if the task cannot be completed.} ## Examples - {Example 1} - {Example 2}每次創(chuàng)建新 skill 時(shí)直接復(fù)制模板再填寫內(nèi)容比從零開始快很多也更容易讓團(tuán)隊(duì)養(yǎng)成統(tǒng)一習(xí)慣。5.3 高質(zhì)量 skill 的檢查清單寫完 skill 后可以用下面的檢查清單自查檢查項(xiàng)說(shuō)明目標(biāo)是否單一一個(gè) skill 只解決一類問(wèn)題步驟是否可執(zhí)行Agent 按步驟走不會(huì)產(chǎn)生歧義是否包含失敗處理出現(xiàn)異常情況時(shí)有兜底邏輯輸出格式是否明確結(jié)果能被后續(xù)流程穩(wěn)定解析是否有示例至少一個(gè)正例和一個(gè)反例是否包含安全邊界遇到敏感信息時(shí)如何反應(yīng)如果以上都滿足這個(gè) skill 才算具備了“生產(chǎn)級(jí)”的底子可以投入到真實(shí)項(xiàng)目中使用。5.4 從 skill 到業(yè)務(wù)閉環(huán)單一 skill 只是第一步。生產(chǎn)環(huán)境往往需要一個(gè)“skill 集合”覆蓋需求分析、編碼、審查、測(cè)試、部署運(yùn)維等環(huán)節(jié)。把這些 skill 組合起來(lái)配合 Agent 編排流程才真正形成了企業(yè)級(jí) AI 智能體。從這個(gè)角度看Addy Osmani 的項(xiàng)目給我們提供的不只是一些現(xiàn)成 skill更是一套值得長(zhǎng)期復(fù)用的組織方法論。6. 常見問(wèn)題與排查思路在實(shí)踐過(guò)程中我整理了一些出現(xiàn)頻率較高的問(wèn)題和對(duì)應(yīng)的解決方案。這里按“現(xiàn)象—原因—解決思路”列出方便你快速排查。問(wèn)題現(xiàn)象常見原因解決思路從 GitHub 拉取倉(cāng)庫(kù)時(shí)速度很慢或超時(shí)倉(cāng)庫(kù)體積大、網(wǎng)絡(luò)波動(dòng)使用鏡像入口比如git clone https://gitclone.com/github.com/xxx/xxx或先下載壓縮包再解壓Skill 內(nèi)容加載后格式混亂Markdown 編碼或換行符問(wèn)題統(tǒng)一使用 UTF-8 編碼并確保文件以 LF 換行符保存Agent 讀了 SKILL.md 后仍然不按規(guī)則執(zhí)行Prompt 中沒(méi)有明確要求“必須嚴(yán)格遵守”在用戶指令里顯式指出“請(qǐng)按 SKILL.md 的規(guī)則執(zhí)行不要跳過(guò)約束”相同 diff 每次審查結(jié)果不一致沒(méi)有固定輸出規(guī)范或溫度參數(shù)過(guò)高在 skill 中強(qiáng)化輸出模板并在 Agent 配置中降低溫度Skill 文件多后難以維護(hù)缺少模塊化管理按第 3 節(jié)的目錄結(jié)構(gòu)組織每個(gè) skill 獨(dú)立目錄、獨(dú)立版本這里特別說(shuō)一下 GitHub 訪問(wèn)問(wèn)題。很多開發(fā)者會(huì)遇到倉(cāng)庫(kù)無(wú)法克隆或者下載慢的情況。穩(wěn)妥的做法是設(shè)置 Git 代理如果本機(jī)有可用 HTTP 代理。使用國(guó)內(nèi)鏡像站例如把github.com替換為gitclone.com或hub.fastgit.xyz這類鏡像的可用性會(huì)隨時(shí)間變化。直接在瀏覽器下載 zip 包再上傳到服務(wù)器避免命令行克隆超時(shí)。不要輕信來(lái)路不明的“加速工具”更不要在辦公環(huán)境嘗試?yán)@過(guò)網(wǎng)絡(luò)安全策略。安全合規(guī)永遠(yuǎn)是第一位的。7. 最佳實(shí)踐與工程建議7.1 從業(yè)務(wù)場(chǎng)景反推 skill 設(shè)計(jì)很多團(tuán)隊(duì)在引入 agent skill 時(shí)會(huì)踩一個(gè)坑先去大而全地整理一堆 prompt卻發(fā)現(xiàn)業(yè)務(wù)方根本用不上。正確的做法是反推場(chǎng)景。列出當(dāng)前業(yè)務(wù)里最痛、最重復(fù)、最需要標(biāo)準(zhǔn)化的環(huán)節(jié)優(yōu)先為這些環(huán)節(jié)做 skill。比如新需求評(píng)審讓 Agent 按固定模板生成需求遺漏點(diǎn)清單。代碼審查讓 Agent 執(zhí)行規(guī)范檢查、安全掃描、性能提醒。故障排查讓 Agent 按時(shí)間線收集日志、定位異常、輸出根因假設(shè)。數(shù)據(jù)報(bào)表生成讓 Agent 從數(shù)據(jù)庫(kù)查詢固定口徑的數(shù)據(jù)并生成報(bào)表說(shuō)明。抓準(zhǔn)場(chǎng)景后再考慮這個(gè) skill 的結(jié)構(gòu)、輸入輸出、校驗(yàn)方式。這樣既能快速見效也能在團(tuán)隊(duì)內(nèi)積累信任。7.2 給 Skill 加上版本管理和灰度策略生產(chǎn)級(jí) skill 不該是“寫一版用一年”的靜態(tài)文件。AI 大模型能力在升級(jí)、業(yè)務(wù)規(guī)則在變化skill 也需要持續(xù)迭代。建議把 skill 納入 Git 管理用版本號(hào)標(biāo)記每次變更。大型改動(dòng)可以先在測(cè)試環(huán)境里跑一段時(shí)間確認(rèn)效果后再全量推廣。如果 Agent 平臺(tái)支持“同時(shí)掛載新版舊版”做對(duì)比也可以采用灰度策略讓一部分請(qǐng)求走新版另一部分走舊版用數(shù)據(jù)判斷是否回滾。7.3 安全邊界與敏感數(shù)據(jù)處理涉及企業(yè)生產(chǎn)環(huán)境的 skill必須把安全放在首位。這里有幾點(diǎn)建議skill 中明確禁止輸出真實(shí)密碼、Token、密鑰等敏感字段。如果任務(wù)需要讀取數(shù)據(jù)庫(kù)務(wù)必強(qiáng)調(diào)只允許 SELECT且限制查詢條件。涉及刪除、更新操作時(shí)skill 必須要求先備份并提示風(fēng)險(xiǎn)。對(duì)“無(wú)法確認(rèn)的數(shù)據(jù)”要求 Agent 停止操作并請(qǐng)求人工確認(rèn)。這些規(guī)則不能只停留在文檔里而要寫進(jìn)SKILL.md的 Constraints 部分并且通過(guò)示例告訴 Agent 遇到什么情況必須剎車。7.4 構(gòu)建團(tuán)隊(duì)級(jí) skill 知識(shí)庫(kù)當(dāng) skill 數(shù)量多起來(lái)之后可以考慮建設(shè)團(tuán)隊(duì)級(jí)知識(shí)庫(kù)。做這件事有幾個(gè)關(guān)鍵點(diǎn)統(tǒng)一命名規(guī)范比如{領(lǐng)域}-{場(chǎng)景}-{技能名}。統(tǒng)一文檔結(jié)構(gòu)每個(gè) skill 遵循同一個(gè)模板。建立 review 機(jī)制新 skill 需要經(jīng)過(guò)至少一人復(fù)核。統(tǒng)計(jì)使用數(shù)據(jù)定期關(guān)注成功率、失敗原因、修改次數(shù)。這套機(jī)制本身并不復(fù)雜但堅(jiān)持下來(lái)后團(tuán)隊(duì)的 AI 應(yīng)用水平會(huì)明顯區(qū)別于那種“每個(gè)人自己寫 prompt”的粗放階段。8. 總結(jié)與下一步學(xué)習(xí)方向Addy Osmani 這個(gè) 7.9 萬(wàn) Star 的項(xiàng)目本質(zhì)上是在推動(dòng)一件事把 AI Agent 從“好玩”推向“可用”從“偶爾正確”推向“穩(wěn)定交付”。它沒(méi)有依賴復(fù)雜平臺(tái)而是選擇了一種極輕量的文件結(jié)構(gòu)——這恰恰是最容易復(fù)制到任何團(tuán)隊(duì)的方式。對(duì)于開發(fā)者而言現(xiàn)在最值得做的第一步是動(dòng)手創(chuàng)建屬于你自己的第一個(gè) skill?？梢韵葟淖詈?jiǎn)單的場(chǎng)景入手比如把團(tuán)隊(duì)的代碼審查標(biāo)準(zhǔn)整理成一個(gè)SKILL.md放進(jìn)倉(cāng)庫(kù)然后讓 Agent 在下一個(gè) PR 審查中試跑。跑通之后再逐步擴(kuò)展。后續(xù)可以繼續(xù)關(guān)注的方向包括skill 的自動(dòng)評(píng)估與回歸測(cè)試、多 skill 組合編排、RAG 與 skill 的結(jié)合、以及大模型能力升級(jí)后 skill 的兼容性管理。這些方向中我建議優(yōu)先研究“自動(dòng)評(píng)估”和“組合編排”因?yàn)槎咧苯記Q定生產(chǎn)環(huán)境里 Agent 的上限。AI Agent 的時(shí)代才剛剛開始基于 skill 的工程化方法會(huì)是這一波浪潮里非常核心的技能。現(xiàn)在就打開 GitHub拉取這個(gè)項(xiàng)目選擇一個(gè)你最有感的 skill 開始實(shí)踐吧。相信我跑通一個(gè)真正能用的 skill 之后回不去的。