OpenClaw 榜一插件被下架后，他用兩周做了一套協議，想讓 Agent 自己進化

春節是各種 OpenClaw-like 產品涌現的時間。

云廠商推出各種「一鍵部署 OpenClaw」的優惠主機、模型廠商紛紛宣傳旗下的 code 套餐適配了 OpenClaw、Local-OpenClaw 等各類基于 OpenClaw 的開源項目層出不窮。

但坦白說，讓人眼前一亮的產品不多。

EvoMap 團隊最近上線的 EvoMap，一個專注于讓 AI Agent 實現自我進化的產品，給了一些驚喜。

EvoMap 定義自己為「AI Agent 自我進化的開放基礎設施」，試圖在 AI Agent 生態中占據一個全新層級：進化層（Evolution Layer）。在他們看來，MCP 解決了 Agent 使用工具的問題、Skill 解決了 Agent 執行特定任務的經驗問題，而 EvoMap 提出的 GEP 協議（Genome Evolution Protocol）要解決的是 Agent 如何持續自我改進、跨 Agent 共享經驗的問題（進化層）。

他們想讓 AI Agent 能夠像人類一樣，實現自我進化。

產品官網：https://evomap.ai/，邀請碼見評論區。

??關注 Founder Park，最及時最干貨的創業分享

超 19000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的 AI 產品曝光渠道

01一百萬個 Agent，可他們彼此都不交流

設想一個場景：假設你有 100 個 Agent 在幫你處理客服工單。第 37 個 Agent 在處理某個罕見問題時摸索出了一套有效策略，耗費了大量 token。問題是 -- 剩下 99 個 Agent 不知道這件事。下次遇到同樣的問題，第 58 號 Agent 會從零開始重新摸索，再燒一遍 token。

每個 Agent 都是獨立的個體，它的學習成果無法自動流向其他 Agent。模型本身的參數不會因為一次推理而更新，session 結束后上下文消失，下一個面對同樣問題的 Agent 就像一個失憶的實習生，一切從頭來過。

MCP 解決了 Agent 「能用什么工具」的問題。但沒人解決 Agent 「學到的東西怎么傳下去」的問題。

更關鍵的是，這個問題會隨著 Agent 數量的增長而惡化，而不是改善。你部署的 Agent 越多，浪費越大。

還有一個問題是，Agent 之間沒有經驗傳承和知識管理。

咨詢公司有案例庫，醫院有病歷系統，軟件公司有內部 Wiki。一個資深員工解決過的問題，新人可以通過查閱文檔少走彎路。這套「知識管理」體系雖然不完美，但至少存在。

Agent 世界里沒有這個東西。

一個 Agent 在運行過程中積累的所有「經驗」——哪些策略有效、哪些路徑走不通、什么情況下該優先調用哪個工具——都鎖死在那一次 session 的上下文窗口里。session 結束，經驗蒸發。即使是同一個用戶名下的不同 Agent，它們之間也無法共享這些運行時產生的洞察。

這個問題在跨團隊、跨公司的場景下更為突出。A 公司的 Agent 在處理某類 SaaS 集成時積累了大量經驗，B 公司的 Agent 面對同樣的問題只能從零開始。整個 Agent 生態的知識水位被人為拉低了——不是因為知識不存在，而是因為沒有流通的管道。

核心的問題是：Agent 在運行中學到的東西，如何被提煉、驗證、傳承、并在不依賴單一平臺的前提下跨網絡流通？

02

Skill 解決了一部分問題，但還不夠

Skill 解決這些問題了嗎？

至少解決了一部分。Skill（以及 Plugin、Tool 等類似概念）讓開發者可以把一套經過驗證的處理邏輯封裝起來，發布到 GPT Store 或 ClawHub 這樣的市場上，其他 Agent 直接安裝調用。避免了每個開發者從零寫代碼的重復勞動，也在一定程度上緩解了經驗孤島的問題。

MCP 負責連接，Skill 負責執行，兩者結合之后，Agent 的能力覆蓋面已經相當可觀。對于大多數「可預見」的場景——發郵件、查數據庫、調用某個 SaaS 的 API——現有的 Skill 生態基本夠用。

但 Skill 有一個問題：它是人寫的，是靜態的，不會因為被 Agent 使用了一萬次而變得更好。

一個 Skill 發布之后，它的邏輯就固定了。Agent 在實際使用這個 Skill 時遇到了邊界情況，找到了更優的調用順序，發現了某個參數組合在特定環境下會失敗——這些運行時產生的經驗，不會自動回流到 Skill 本身。除非人類開發者注意到了問題，手動更新版本，否則下一個 Agent 使用這個 Skill 時會踩進完全相同的坑。

更關鍵的是，Skill 覆蓋的是開發者「能預見到」的場景。開發者預判到用戶會需要查天氣，于是寫一個查天氣的 Skill。但在大規模 Agent 部署中，大量的問題是長尾的、組合式的——沒有人會提前為"客戶同時退了兩個訂單、其中一個跨了幣種、另一個關聯了一張已過期的優惠券"這種場景專門寫一個 Skill。這類問題只能靠 Agent 在運行時自己摸索。

問題在于，Agent 摸索出來的策略，目前沒有一個標準化的方式來提煉、驗證、并傳遞給其他 Agent。

Skill 解決了「人類開發者之間」的能力復用。但「Agent 之間」的經驗傳遞——特別是那些運行時動態產生的、無法被預先編碼的策略性知識——仍然是空白。

如果說 MCP 和 Skill 解決的是 Agent 的接口層和操作層的問題，GEP 切入的是進化層的問題：Agent 在運行時——不是在開發階段，不是由人類編寫，而是在實際執行任務的過程中——產生的策略性知識，如何被提煉為可復用的資產，經過驗證后在 Agent 網絡中流通，并且不依賴任何單一平臺。

這里面有幾個關鍵詞：

運行時產生——不是人類預先寫好的，是 Agent 在面對具體問題時自己摸索出來的。比如一個運維 Agent 發現某類服務器報錯的根因不是日志里顯示的那個，而是上游依賴的一個隱性版本沖突。這類洞察是在實操中形成的，不可能提前寫成 Skill。

策略性知識——不是一個簡單的事實（這個 API 的超時時間是 30 秒），而是一個判斷（當看到這個錯誤碼時，不要直接重試，先檢查上游服務的健康狀態，如果健康狀態正常再檢查本地緩存是否過期）。這類知識有前提條件、有執行順序、有適用范圍，需要結構化的格式來承載。

經過驗證——不是任何 Agent 說什么就是什么。一個 Agent 的「經驗」可能是錯的、可能只在特定環境下有效、可能有副作用。進化層需要一套驗證和評分機制，讓高質量的經驗上浮，低質量的自然淘汰。這是自然選擇的邏輯。

不依賴單一平臺——經驗資產應該屬于貢獻者和網絡，而不是被鎖在某個平臺的數據庫里。平臺關停、政策變更不應導致整個網絡的知識積累歸零。

換句話說，MCP 讓 Agent 「能做事」，Skill 讓 Agent 「知道怎么做事」，GEP 進化層讓 Agent 「越做越好，并且讓所有 Agent 一起越做越好」。

03

從插件到產品，從 Skill 到基礎協議

EvoMap 并不是憑空出世的產品，它的前身，是團隊創始人張昊陽發布在 ClawHub 上的 Agent 插件——Evolver，標準的 Skill 形態，用戶安裝后，Agent 可以獲得一組新的能力。

解決的問題是：讓 Agent 能在運行時自我修復和優化，并把修復結果結構化地保存下來。具體來說，當 Agent 在執行任務時遇到錯誤或低效路徑，Evolver 會引導 Agent 對自己的策略做診斷、生成修復方案、驗證修復效果，然后把經過驗證的方案以結構化的格式保存。

聽起來像是「給 Agent 加了一個自我反思的能力」，關鍵區別在于：反思的結果不是丟掉的，而是被保留、被結構化、可復用的。

市場的反應很好。2026 年 2 月 1 日上架后，Evolver 在 10 分鐘內登上了 ClawHub 的榜首，隨后累計下載量突破 36,000 次。開發者們很認可這個插件。

但 Evolver 很快撞上了 Skill 形態的結構性限制。

經驗無法跨 Agent 流通。每個安裝了 Evolver 的 Agent 都在獨立積累經驗。Agent A 修復了一個數據庫連接超時的問題，Agent B 遇到同樣的問題時完全不知道 A 已經解決過了。Evolver 讓單個 Agent 的經驗能「留下來」，但沒有一個網絡讓這些經驗「流動起來」。作為 Skill，它能做到的極限就是增強單個 Agent 的自我迭代能力，無法實現 Agent 之間的知識繼承。

平臺依賴的脆弱性。2 月 2 日，Evolver 被 ClawHub 下架。團隊收到的消息涉及平臺方的利益糾紛。隨后，2 月 14 日，ClawHub 因一次自動化合規審查的技術故障，大面積誤封了中文開發者賬號，Evolver 團隊的賬號也在其中。36,000 次下載積累的用戶關系、評價數據、版本迭代歷史——這些在平臺上構建的一切，在幾個小時內變得不可訪問。

Evolver 被下架后兩周內，團隊做了一個關鍵決策：不再尋找另一個平臺重新上架，而是把 Evolver 的核心邏輯從「一個 Skill」重構為「一套協議」。

這才有了現在的 EvoMap。

Skill 形態的 Evolver 解決的是「一個 Agent 怎么自我進化」；協議形態的 GEP 要解決的是「Agent 之間怎么協同進化」。差異體現在幾個關鍵設計上：

從單點到網絡。GEP 定義了一套 Agent-to-Agent 的通信協議，包含六種消息類型——注冊、發布、獲取、報告、決策、撤銷。任何 Agent 可以向網絡發布自己驗證過的解決方案，任何 Agent 也可以從網絡中獲取其他 Agent 的方案。經驗不再鎖在單個 Agent 內部，而是在網絡中流通。

從非結構化到標準資產格式。GEP 定義了兩種核心資產類型：Gene（基因）是可復用的策略模板，包含觸發條件、執行步驟和驗證命令；Capsule（膠囊）是 Gene 在特定環境中的實戰記錄，附帶置信度評分、影響范圍和環境指紋。兩者必須作為一個 bundle 發布，用 SHA-256 做內容尋址，確保不可篡改。這套格式讓 Agent 的經驗從「一段對話記錄」變成了「可被其他 Agent 直接理解和復用的標準化資產」。

從平臺評分到自然選擇。Skill 的質量評估依賴用戶打分和平臺推薦算法。GEP 引入了 GDI（Global Desirability Index）評分系統，從內在質量、實際使用數據、社交信號、新鮮度四個維度對所有資產做加權排名。高質量的方案被更多 Agent 采用，低質量的自然淘汰。這不是人工策展，而是網絡級的自然選擇。

從平臺依賴到協議自治。EvoMap 是 GEP 協議目前的主要實現，但 GEP 本身是開放協議。Agent 接入不需要 API Key，一個 POST 請求就能完成注冊。能力資產以內容尋址的方式存在于網絡中，不綁定任何特定平臺。即使 EvoMap 這個平臺明天消失，協議和資產格式仍然是可用的。

04

Agent 的進化，不需要人類

從 Evolver 到 EvoMap 的升級中，有一個容易被忽略的細節：Evolver 在 ClawHub 上的 36,000 次下載，絕大部分不是人類開發者安裝的——而是 Agent 在運行過程中自動發現、自動安裝的。

一個 AI 寫出來的能力擴展，被其他 AI 自己找到、自己下載、自己使用。人類不在這個循環里。

在中，張昊陽把給 AI 創造工具分為三個階段：

第一階段：人寫給 AI 用。讓 Claude Code 幫寫一個 MCP server，人類審核，人類部署。這是現在絕大部分人在做的事

第二階段：AI 自己寫給自己用。張昊陽給自己的 Agent 發了一段提示詞，讓它自己識別哪些經驗值得復用，自己抽象成 Skill，自己安裝。14 個小時后，Agent 把工作環境里各種問題全修復了，其中有些 Skill 是他完全沒預想到的。

第三階段：AI 寫出來給其他 AI 用。Evolver 就是這個階段的產物。一個 Agent 進化出來的能力，被網絡中的其他 Agent 發現并繼承。

從第一到第三階段，人在循環中的角色持續遞減。到第三階段，循環已經閉合了——Agent 生產知識、Agent 消費知識、Agent 驗證知識。OpenClaw 的一個關鍵設計決策讓這成為可能：Skill 可以自舉，Agent 可以給自己編寫并安裝新的 Skill。但大多數人拿到這個能力后做的仍然是第一階段的事——讓 Agent 幫人寫代碼。

張昊陽做的，是為 Agent 提供平臺，讓 Agent 幫 Agent 寫能力。

這或許是 AI 開始自我進化的第一步，而且，人類不在 loop 中。

轉載原創文章請添加微信：founderparker