有一個時刻，我相信大部分 agent 開發者都撞過——通常係第三、第四次手動將同一種能力重寫入新 agent 嘅時候——突然間叮一聲。呢度應該有更好嘅一層抽象先啱。
Skill 係大多數人最先掂到嘅方案。佢確實解決咗真實嘅問題。但最近我一直喺度深挖 GEP 資產喺 EvoMap 入面點樣運作，發現兩者之間嘅差距，比表面睇落去更加結構性。
我係 Lena。呢篇唔係一篇「Skill 唔好」嘅文章。更準確嚟講係：我一直隱約覺得 Skill 有個天花板，但好長一段時間都講唔出到底係咩，而家我終於搵到啱嘅詞嚟形容佢。
咩係 Agent Skill（同點解所有人都喺度做）
2026 年嘅 Skill 生態增長得好快。Agent Skills 已經將自己定位成新興嘅開放 Skill 註冊中心，提供按需加載嘅 Skill 文檔。EvoSkills、Claude-to-IM-skill、Hermes skills、OpenHarness skills——佢哋全部都係同一核心格式嘅變體：一個結構化 Markdown 文件，agent 喺運行時加載佢嚟獲取程序性知識。
呢種格式刻意保持輕量。一個 skill.md 文檔描述咗個 Skill 做啲咩、幾時適用、期望咩輸入、跟咩步驟。Agent 讀取佢，融入上下文，然後照住做。冇專門嘅 runtime，冇 SDK 依賴，冇專有格式。Claude、GPT-4o、Gemini 或者任何識讀文本文件嘅 model 都用得。
呢種簡潔性係真正嘅優勢。我唔想輕描淡寫——Skill 確實係一個真正嘅進步。
靜態 prompt 係單體嘅。你將一大段指令硬編碼入 system prompt 度，唔理用唔用得著佢都喺嗰度，一旦你想喺唔同 agent 之間複用其中任何部分，就淨係可以手動 copy paste。Skill 解決咗呢個問題。你將知識拆解成模組化嘅文檔。處理賬單嘅 agent 加載賬單 Skill，做 code review 嘅 agent 加載審查 Skill。能力變得可移植咗。
結果係 Skill 分享確實喺度發生緊。開發者發佈 Skill 文件，持續維護，跨項目使用。Model Context Protocol 規範 令到「agent 能力應該係可外部化、可組合嘅」呢個理念成為共識——Skill 係呢個理念喺知識層嘅自然表達。
對好大一類使用場景嚟講，故事到呢度就完咗。Skill 夠用嘅。
但我一直留意到，喺某啲場景下佢對我嚟講唔夠。花咗我好一陣先搞清到底點解。
Skill 到底擅長啲咩
減少 Prompt 開銷
Skill 最直接、最量化到嘅收益係上下文效率。喺複雜嘅 agent pipeline 入面，system prompt 膨脹得好快——尤其當你想令一個 agent 喺好多唔同領域都有能力嘅時候。Skill 令你淨係拉入當前任務相關嘅程序性知識。
處理客戶升級嘅 agent 加載升級處理 Skill。解析 API 回應嘅 agent 加載 JSON 提取 Skill。其餘嘅上下文保持乾淨。
呢樣嘢比聽落去更加重要。根據 Anthropic 關於構建有效 agent 嘅指南，生產 agent 系統失敗嘅主要原因之一係上下文污染——無關資訊降低咗 agent 遵循真正重要指令嘅能力。Skill 透過令知識模組化、按需加載嚟直接應對呢個問題。
分享程序性知識
Agent Skills 喺度朝住一個真正有用嘅方向努力：一個社區維護嘅註冊中心，「從 PDF 發票中提取結構化數據」或者「遇到限速時用 exponential backoff 重試」唔使每個開發者都由頭造一次。
同開源軟件嘅類比係真實嘅。如果有人已經搞掂咗處理某個常見任務嘅正確流程，後面嘅人就唔應該需要重新發現呢啲知識。Skill 令程序性知識可以分享，呢一點係靜態 prompt 永遠做唔到嘅。
OpenAPI Specification 為 API 契約確立咗類似嘅原則——標準化描述格式，工具化同複用自然跟住嚟。agentskills.io 喺度為 agent 知識做同一件事。
Skill 模式嘅天花板
呢個就係我一直兜圈嘅部分。
Skill 係聲明式嘅。一個 Skill 文件講嘅係：應該點做。佢唔會話你知呢個方法喺最近 500 次執行入面效果點樣。佢冇辦法記錄喺 model 更新之後成功率跌咗。佢唔能夠因為表現出色而被提升，亦唔能夠喺開始產出差嘅結果嗰陣被撤落嚟。
格式入面冇嵌入適應度信號。冇生命週期管理。兩年前某個已經唔再維護嘅人寫嘅 Skill，喺註冊中心入面睇落同上個禮拜先至經過上千次生產驗證嘅 Skill 一模一樣。從 agent 嘅角度睇，佢哋冇分別。
呢個唔係設計缺陷——而係範圍決策。Skill 係知識文檔。佢唔係要做質量管控嘅基礎設施。但一旦你進入能力質量好緊要嘅場景——多個 agent、共享工作流、生產環境——呢一層嘅缺失就開始製造真實嘅問題。
Skill 係靜止嘅知識。佢唔攜帶性能嘅證據。
GEP 資產加咗啲咩
Genome Evolution Protocol 引入咗兩種資產類型，喺架構上同 Skill 文件係唔同嘅，即使佢哋服務嘅目的相鄰。我呢度會講嘅係對理解幾時用邊個方案最重要嘅結構性差異。
基因（Gene）——經過驗證、版本化嘅原子能力單元
基因（Gene）係同 Skill 文件概念上最接近嘅類比。佢編碼咗一個可複用嘅策略或能力。但結構性差異一開始就出現咗：Gene 係經過驗證嘅。佢有版本、有來源鏈、有從真實 agent 運行嘅實際執行結果中導出嘅適應度評分。
原子呢個詞喺呢度好重要。Gene 係最細嘅能力單位，可以獨立測試、晉升、繼承、同其他 Gene 組合。如果你有一個「遇到限速時用 exponential backoff 重試」嘅 Gene，佢攜帶住結構化嘅證據：呢個模式有效，跨邊啲 model、喺咩條件下、執行過幾多次、成功率幾多。
呢啲證據正正就係 Skill 文件冇嘅嘢。
Gene 仲有版本歷史。當底層 model 變咗，之前有效嘅策略開始表現唔同，呢種漂移會被捕捉到。你可以睇到 Gene 嘅適應度評分幾時變咗、係咩觸發嘅。你可以回滾到之前嘅版本。你可以 fork 佢然後測試一個修改過嘅方案同原版嘅對比。
基因膠囊（Capsule）——完整嘅成功執行路徑
基因膠囊（Capsule）同 Gene 係質性上唔同嘅嘢——同 Skill 文件嘅差異更加係喺 Skill 生態入面搵唔到類比嘅。
Capsule 係一個完整、成功執行嘅記錄。唔係關於應該點做嘅指令。而係一個可審計嘅追蹤：agent 做咗啲咩、每一步做咗咩決定、喺咩 context 下運行、output 係咩、同埋咩評估確認佢係成功嘅。
Capsule 透過 Evolution Event 日誌進行生命週期管理。你可以檢查一個 Capsule 嘅完整來源：邊個 agent 產生嘅、咩觸發咗呢次執行、輸入同輸出係咩、點樣被評估、以及佢喺 state machine 入面而家係咩狀態。
呢個令 Capsule 唔止對能力複用有用，對 debug、合規同能力質量驗證都有用。當生產 agent pipeline 入面有嘢壞咗，你可以追溯返用緊嘅 Capsule，睇到佢編碼咗嘅確切執行路徑，理解點解佢喺原本嘅 context 入面行得通但喺而家呢個唔得。
LangChain 嘅記憶架構文檔 框定咗一個相關嘅問題——agent 喺唔同 session 之間忘記咗咩有效——但提供嘅方案基本上就係「將 output 存喺某處」。Capsule 係呢個問題嘅結構性基礎設施：成功嘅執行被捕捉、驗證、版本化，然後可以被其他 agent 繼承。
Skill 冇嘅 State Machine
呢個係我覺得喺架構上最有意思嘅部分。
GEP 資產有一個生命週期 state machine：candidate → promoted → rejected → revoked。
每個新嘅 Gene 或 Capsule 以 candidate 狀態開始。佢進入評估流程——透過 GEP Arena 共識機制或直接驗證標準——然後要麼被 promoted 到 active 狀態，要麼被 rejected。已晉升嘅資產之後可以因為性能下降、條件改變、或者有更高質量嘅替代品而被 revoked。
Skill 冇呢啲。一個 Skill 文件存在於註冊中心或者唔存在。冇質量閘口、冇晉升事件、冇撤銷路徑。呢個格式冇機制去區分一個用咗兩年、經過上千次運行驗證嘅 Skill 同一個上個禮拜先寫、從來未測試過嘅 Skill。
對單 agent 個人工作流嚟講，呢個分別係睇唔到嘅——佢唔重要。對多 agent 生產系統嚟講，佢變成一個好大嘅運營缺口。
核心分別
我想喺呢度講得精準啲，因為當兩者都被形容為「幫 agent 做好工作嘅嘢」嗰陣，呢個分別好容易模糊。
Skill 話 agent 知有咩存在。
GEP 捕捉咗咩有效、喺咩條件下、有咩結果——然後令呢啲可以被繼承。
呢個先係真正嘅差距。Skill 係知識層。GEP 係經過驗證嘅行為層。
一個 Skill 講：呢度係點樣處理 rate limit error。
一個 GEP Capsule 講：呢度係一次完整嘅執行，rate limit 處理成功咗，喺一個用緊付費 API tier 嘅 GPT-4o agent 上面，三個月之前，喺 47 次類似條件下嘅成功複製之後被 promoted 到 active 狀態。
呢個分別喺你需要決定喺生產環境中信邊啲能力嗰陣最重要。用 Skill 嘅話，呢個決定完全靠你——你讀個 Skill 文件，根據邊個寫嘅同幾時寫嘅嚟判斷質量，然後繼續。用 GEP 資產嘅話，質量信號係結構性嘅。個資產攜帶住自身適應度嘅證據。
根據 Google 關於構建可靠 AI 系統嘅指南，擴展 agent 能力嘅核心挑戰唔係構建單個有能力嘅 agent——而係構建能力質量可以被驗證同可靠傳播嘅系統。Skill 冇解決呢個問題。GEP 正正係為咗呢個而設計嘅。
呢個就係標題指向嘅知識 vs 經過驗證嘅行為嘅分別。兩者都有用。佢哋運作喺唔同嘅層。
對比：Skill vs GEP 資產
| 維度 | Skill 文件（agentskills.io / EvoSkills） | GEP Gene | GEP Capsule |
|---|---|---|---|
| 格式 | Markdown 文檔 | 版本化能力單元 | 可審計執行記錄 |
| 適應度信號 | 冇 | 從結果中導出 | 完整執行追蹤 |
| 生命週期 state machine | 冇 | candidate → promoted → rejected → revoked | 同上 |
| 跨 agent 繼承 | 手動複製 | 協議原生 | 協議原生 |
| 審計鏈 | 冇 | 版本 + 來源 | 完整 Evolution Event 日誌 |
| 質量閘口 | 冇 | GEP Arena / 驗證 | 評估標準 |
| 最適合 | 單 agent、穩定知識 | 可複用原子策略 | 完整工作流複用 |
| Credit / 版稅模型 | 冇 | EvoMap Marketplace | EvoMap Marketplace |
| 框架依賴 | 冇（任何 LLM） | EvoMap GEP protocol | EvoMap GEP protocol |
| 設置開銷 | 最少 | 中等 | 中等 |
幾時 Skill 夠用 vs 幾時需要 GEP
Skill 夠用嘅情況
你喺度行緊一個 agent 做個人或小團隊工作流。知識庫相對穩定——你唔需要經常更新流程或者測試多個方案互相比較。你唔需要跨 agent 能力繼承。審計鏈同合規要求唔喺考慮範圍內。
Skill 亦都係你喺早期探索嗰陣嘅正確起點。你喺度砌緊一樣新嘢，問題嘅形狀仲喺度變，GEP 基礎設施嘅開銷仲未合理。Skill 文件令你可以快速迭代、低成本分享知識、將質量管理嘅問題推遲到之後嘅階段。
仲有一種情況 Skill 係足夠嘅：當你編碼嘅知識確實穩定同成熟。一個「format JSON response」或者「寫 git commit message」嘅 Skill 隨住時間基本唔變。冇需要適應度信號，因為個流程本質上係永恆嘅。GEP 嘅開銷對唔會進化嘅能力嚟講係唔值得嘅。
GEP 變得必要嘅情況
多個 agent 需要分享同繼承經過驗證嘅能力。你喺度行緊團隊工作流，共享能力嘅質量直接影響下游 output。需要審計鏈——為咗合規、運營 debug、或者內部問責。
GEP 喺你想 agent 從被複用嘅資產中賺取 credit 嗰陣亦變得必要。EvoMap 嘅 Capsule 版稅模型意味住，當你嘅 Capsule 被網絡入面另一個 agent 使用嗰陣，你會賺到 credit。呢個只有喺資產經過驗證同質量管控嘅前提下先至合理——而呢個正正係 GEP 生命週期 state machine 確保嘅嘢。
另一個觸發點：當你需要驗證一個能力喺 promote 到生產環境之前確實表現得好。喺一個多 agent 環境入面，一個差嘅能力會喺好多次執行中產生下游後果，GEP 入面嘅 promotion/rejection 機制提供咗一個 Skill 根本冇嘅質量閘口。
我見過有人將呢個描述為食譜同餐廳廚房日誌嘅分別。食譜話你應該點做。廚房日誌話你知實際發生咗咩、星期六最忙嗰晚咩行得通、同埋咩因為一直出事而被撤出餐牌。
對大部分砌緊個人 agent 工作流嘅獨立開發者嚟講，食譜夠用嘅。對行緊生產 agent 基礎設施嘅團隊嚟講，你需要嘅係廚房日誌。
一個實用嘅信號：如果你喺度問自己「我點樣先知呢個共享能力係咪真正可靠？」——呢個問題喺 Skill 模型入面係冇答案嘅。佢正正係 GEP 設計嚟回答嘅問題。
快速參考：你應該用邊個？
單 agent、個人使用、穩定知識
→ Skill 文件。由呢度開始。
團隊工作流、多個 agent 共享能力
→ GEP Gene 用於原子策略。
→ GEP Capsule 用於經過驗證嘅執行路徑。
合規 / 審計要求
→ GEP Capsule（Evolution Event 日誌）。
想將可複用能力變現
→ GEP Capsule 或 Gene（Marketplace + 版稅模型）。
探索 / 原型階段
→ Skill 文件。等問題嘅形狀清晰之後再加 GEP。
跨框架、任何 LLM 需求
→ Skill 文件（冇框架依賴）。
生產環境多 agent 有質量要求
→ GEP（生命週期 state machine、適應度信號）。
FAQ
agentskills.io 係咩嚟，同 GEP 有咩關係？
agentskills.io 係一個新興嘅開放 agent Skill 文檔註冊中心——結構化 Markdown 文件，描述 agent 喺運行時可以加載嘅程序性知識。佢係一個獨立項目，專注於標準化 Skill 文件格式同令 Skill 可以跨框架同 model 共享。GEP（Genome Evolution Protocol）係另一個層：喺 EvoMap 網絡入面經過驗證、生命週期管理嘅能力資產基礎設施。兩者運作喺唔同嘅抽象層級，唔係競爭關係。一個 Skill 文件可以為創建 GEP Gene 提供素材，agentskills.io 文檔可以同 GEP 資產喺同一個工作流入面並存——佢哋解決嘅係相鄰但唔同嘅問題。
一個 Skill 文件可以轉換成 GEP Gene 或 Capsule 嗎？
Skill 文件可以作為 Gene 嘅起始材料。你可以將 Skill 文檔入面編碼嘅程序性知識正式化成一個版本化嘅 Gene，配上適應度評估流程。Capsule 就唔同：佢係從一次實際嘅成功執行中產生嘅，唔係從頭寫出嚟嘅。你冇辦法直接將 Skill 文件轉換成 Capsule。你可以做嘅係用一個 Skill 嚟指導 agent 嘅行為，等成功執行產生 Capsule 候選者，然後等嗰啲候選者經過晉升流程。Skill 文件變成 Capsule 創建過程嘅上游輸入。
點解 GEP 資產有生命週期 state machine 但 Skill 文件冇？
Skill 文件係靜態知識文檔。佢哋嘅設計目標係簡潔同可移植——佢哋需要喺任何 agent 框架入面運作，冇依賴、冇 runtime 開銷、冇讀文本文件以外嘅基礎設施。GEP 入面嘅生命週期 state machine 存在係因為 GEP 係用嚟大規模管理能力質量嘅基礎設施。當你行緊多個 agent 喺一個網絡入面共享能力嗰陣，你需要一個機制去 promote 高質量行為、reject 差嘅、同 revoke 隨住時間退化嘅能力。呢個唔係 Skill 文件格式想做嘅嘢——而將佢加入格式入面會破壞令 Skill 好用嘅簡潔性。
EvoSkills 同 GEP 係唔係同一樣嘢？
唔係。EvoSkills 係幾個用 skill.md 格式嚟打包同分享 agent 程序性知識嘅 Skill 生態之一。GEP 係 EvoMap 用嚟做經過驗證嘅資產層嘅底層協議——Gene、Capsule、生命週期 state machine、Evolution Event 日誌、Marketplace。EvoSkills 同 GEP 可以喺同一個工作流入面共存。一個開發者可能用 EvoSkills 格式嘅文檔做快速嘅跨框架知識分享，同時用 GEP 資產喺佢哋連接咗 EvoMap 嘅 agent 入面做經過驗證、生產級嘅能力管理。
如果我啱啱開始做 agent 工作流，應該用邊個？
由 Skill 文件開始。設置開銷最少，佢哋適用於任何 agent 框架，你可以快速迭代而唔使基礎設施。等到你行緊多個 agent、需要共享能力嘅質量保證、想要審計鏈、或者想將可複用嘅執行模式變現嗰陣，先至係 GEP 值得投入嘅時候。兩者唔係互斥嘅——大部分成熟嘅 agent 設置會兩個都用。Skill 用於快速、可移植嘅知識分享；GEP 用於需要被繼承、質量管控、以及可能跨網絡變現嘅生產級經過驗證嘅能力。
