有一種好特別嘅感覺：兩個獨立嘅研究團隊，各自做各自嘅，結果撞到同一個令人唔太舒服嘅結論。
嗨，我係 Lena。當我將 EvoSkills 同 EvoSkill 兩篇論文連住讀完之後，我停低咗。唔係因為結果有幾出人意料——而係因為兩篇論文都冇迴避數據真正揭示嘅嘢：人類為 AI agent 編寫嘅技能存在天花板，而 agent 可以靠自己進化突破呢個上限。
呢個唔係一個小結論。而跟住嘅問題——噉我哋應該點做？——我到依家都停唔到去諗。
EvoSkills 同 EvoSkill 到底證明咗啲乜
兩篇獨立研究論文，同一個結論：人工編寫嘅技能存在上限，agent 可以自主進化突破佢。
人機認知錯位問題
呢一部分令我有啲措手不及。
EvoSkills 唔淨止證明咗進化出嚟嘅技能表現更好，仲量化咗點解人工編寫嘅技能表現唔理想——答案比大多數人以為嘅更加結構性。人類設計者傾向於按照我哋思考問題嘅方式嚟編寫工作流：線性步驟、清晰嘅抽象、整齊嘅決策樹。但 LLM 嘅推理方式唔係噉嘅。
喺 SkillsBench 上面——呢個專門為測試呢一點而建嘅基準測試——差距唔係微乎其微。人工精選嘅技能同大語言模型實際處理多步驟任務嘅方式之間存在可量化嘅認知錯位。呢啲技能本身冇錯——只係佢哋嘅形態唔適合執行佢哋嘅推理引擎。
我反覆返到呢一點。唔係人類唔識寫指令，而係我哋為人類可讀性做緊優化，唔係為 LLM 嘅執行模式做優化。呢兩個係唔同嘅優化目標。
自我進化到底產出咗啲乜
呢啲數字值得慢慢睇：
| 指標 | 基線（冇技能） | 人工精選技能 | 進化技能（第 5 輪） |
|---|---|---|---|
| EvoSkills 通過率 | ~34.5% | ~60%（約） | 75% |
| 超越人類所需輪數 | — | — | 第 3 輪 |
| 相對冇技能增益 | — | — | +40.5pp |
| EvoSkill OfficeQA | baseline | — | 0.073 |
| EvoSkill SealQA | baseline | — | 0.121 |
由 32% 起步，agent 喺五輪進化之後去到 75% 嘅通過率。到第三輪，佢已經超過咗人工精選嘅上限。呢一點令我真係好難用其他理由解釋：agent 唔淨止喺度縮小差距——佢喺反方向拉開緊差距。
EvoSkill 喺唔同嘅任務領域（辦公文件 QA 同基於網絡嘅研究）上顯示咗相同方向嘅結果。絕對增益細啲，但方向一致。OfficeQA 上 +7.3%，SealQA 上 +12.1%。全部都超過咗人工編寫嘅基線。
跨模型同跨任務遷移
呢個細節我差啲就掃過咗，但唔應該。
為一個 LLM 進化出嚟嘅技能喺六個唔同模型之間遷移時攞到 +35pp 到 +44pp 嘅增益。呢個唔係一個細細嘅可移植性優勢——呢個係話畀你聽技能編碼咗關於任務結構嘅某啲嘢，而唔淨止係某個特定模型嘅特性。
仲有更加有趣嘅：SealQA 技能零樣本遷移到 BrowseComp 時攞到 +5.3% 嘅增益。呢個技能從未為 BrowseComp 設計過，但佢就係喺嗰度起作用。呢個暗示被進化出嚟嘅嘢更加接近一種可泛化嘅執行策略，而唔係一個狹窄嘅 prompt 微調。
我仲未完全確定應該點樣理解呢件事。但我記低咗。
兩篇論文都撞到嘅邊界
去到呢度我明顯放慢咗速度。
兩篇論文都展示咗真實嘅、可複現嘅增益。而兩篇論文細心讀落去，都大致喺同一個位置撞咗牆。呢堵牆唔完全係技術性嘅——佢係架構性嘅。
單 Agent 範圍
兩項研究入面每個進化出嚟嘅技能都存在於單個 agent 嘅執行上下文入面。具體嚟講：agent 本地檔案系統上面嘅一個資料夾，一個作用域限定喺嗰個 agent 會話入面嘅版本化產物。
當 agent 被替換、更新或重新部署時，進化成果唔會自動繼承——除非有人手動遷移。研究設置入面冇內置繼承機制。進化係真嘅，但持久性係脆弱嘅。
冇網絡傳播
兩篇論文入面，每個新 agent 都由零開始自己嘅進化循環。
諗吓喺任何合理嘅部署規模下呢個意味住乜。十個 agent 行 EvoSkill 風格嘅進化循環，就產出十份獨立嘅進化歷史。呢啲歷史唔會合併，唔會做衝突解決。嗰個令單 agent 內部結果如此驚人嘅複合增益——由 32% 到 75% 嘅軌跡——對每個新啟動嘅 agent 都歸零重嚟。
改進係局部嘅。起點永遠一樣。
論文明確留低嘅開放問題
EvoSkill 直接將呢個標記為未來工作，而非疏忽：共享技能庫，令喺一個任務上面發現嘅技能可以畀其他 agent 同用戶瀏覽、組合同複用。
呢句說話好重要。研究者唔係冇睇到呢個問題——佢哋明確指出咗佢。呢個係一個開放嘅研究問題，唔係一個等住發佈嘅實現細節。生成問題（agent 能唔能夠進化出更好嘅技能？）而家有咗強有力嘅經驗證據。傳播問題（經過驗證嘅進化技能點樣喺 agent 之間大規模流動？）仲未有。
論文喺系統層面留低嘅空白
我想喺呢度謹慎啲，因為呢一節好容易被誤讀為產品推銷。唔係嘅。呢個係一個工程問題，我認為值得由工程本身嘅角度認真對待。
局部進化同共享繼承之間嘅鴻溝
自我進化技能乾淨利落噉解決咗一個問題：對於一個重複執行任務嘅單 agent，自動進化產出嘅執行產物優於人工編寫。呢一點而家有咗充分嘅支撐。
佢冇解決嘅係：傳播問題。一個經過驗證嘅進化技能點樣喺 agent 之間流動？網絡點樣評估一個技能係咪可靠，然後先至允許佢傳播？適應度信號——證明技能確實喺多樣化嘅任務同模型上面有效嘅證據——點樣喺超出單個 agent 會話歷史嘅尺度上面積累？
呢啲唔係反問句。佢哋係研究成果同可部署基礎設施原語之間嘅鴻溝。
網絡級協議需要處理啲乜
如果你要設計基礎設施嚟彌合呢個鴻溝——我係講真正去設計，唔係做市場推廣——你至少需要：
- 驗證層：進化技能喺傳播之前進行質量評估，而唔係之後
- 生命週期模型：跨技能歷史嘅晉升、拒絕同撤銷追蹤
- 獲取機制：agent 檢索已驗證嘅能力，而唔使由頭再建
- 衝突解決方案：當兩個獨立進化出嚟嘅技能針對同一任務產生分歧時，系統點樣仲裁？
呢啲全部都唔係 EvoSkills 或 EvoSkill 架構所解決嘅問題。兩篇論文都明確講咗呢一點。Model Context Protocol 喺 agent 介面層解決咗工具連接問題，但佢冇定義技能進化或繼承嘅生命週期。呢啲確實係技術棧唔同層面上嘅唔同問題。
關於 agent 能力共享嘅更廣泛探索，Google 嘅 Agent-to-Agent（A2A）協議規範值得一讀——佢定義咗 agent 之間嘅通訊模式，但技能傳播語義仍然唔喺佢嘅範圍入面。
點解呢個鴻溝對構建者團隊好重要
一個團隊部署十個行 EvoSkill 風格進化循環嘅 agent，就會攞到十個獨立嘅技能倉庫。喺目前嘅研究入面，冇明確定義嘅方式嚟：
- 合併呢啲倉庫
- 浮現邊啲進化技能最可靠
- 防止低質素嘅進化技能擴散到其他 agent
- 追蹤當底層模型或任務上下文變化時，邊個版本嘅技能仍然有效
呢個係一個未解決嘅基礎設施問題。唔係一個細問題。
呢個對你而家建構 Agent 工作流意味住乜
我唔覺得面對呢一切嘅正確反應係癱瘓。研究喺某啲方面已經夠清晰，可以即刻行動。
停止為複雜任務手寫技能
呢一點我都算有信心嘅。
對於多步驟嘅專業任務——文件分析、網絡研究、結構化推理鏈——EvoSkills 同 EvoSkill 嘅結果表明，自動進化產出嘅執行產物優於人工編寫。唔係微小嘅優勢，而係實質性嘅，跨越多個模型，仲能遷移到新任務。
LangChain 關於 agent 記憶同技能腳手架嘅文檔提供咗一個合理嘅基礎，幫你諗吓喺邊度可以將進化循環引入現有嘅 agent 架構入面。簡短版本：如果你仲喺度為複雜任務手動調優技能指令，同時困惑點解效能遇到咗樽頸，嗰個樽頸可能係結構性嘅，唔係靠反覆迭代能修復嘅。
諗吓進化出嚟嘅技能應該住喺邊
一個局部進化出嚟、只喺本地留住嘅技能係一個私有資產。有用，但有邊界。
研究社區正在積極探索下一步：經過驗證嘅、可共享嘅、可繼承嘅能力，喺網絡尺度上面運作。微軟研究院嘅 AutoGen 框架係探索多 agent 協作模式嘅較成熟嘅開源項目之一，尤其值得留意佢點樣處理 agent 之間嘅進化能力遷移。
目前嘅實際啟示係：喺設計你嘅進化循環時就考慮可移植性，即使可移植性基礎設施仲未完全存在。呢個意味住記錄進化出嚟嘅技能版本、追蹤佢哋通過咗邊啲評估基準，同時將進化產物同 agent 運行時分開保存。
喺構建之前值得諗吓嘅問題
喺你為一個新項目確定特定嘅 agent 架構之前，我覺得呢啲問題值得好好諗吓：
- 進化出嚟嘅技能喺會話結束後住喺邊？ 如果答案係「喺 agent 嘅本地檔案系統入面，冇匯出路徑」，噉你建構嘅係一個冇複合價值路徑嘅私有資產。
- 喺其他 agent 使用之前，邊個嚟驗證佢哋？ 自動化驗證基準係一種答案；人工審核關卡係另一種。兩種都唔係零成本嘅。
- 你點樣追蹤邊個版本嘅技能仲可靠？ 隨住底層模型更新、任務上下文變化，一個喺二月有效嘅技能到八月可能就失效咗。如果你喺度建構任何打算行幾個月嘅嘢，版本追蹤同重新評估唔係可選項。
OpenAI 關於工具使用同函數呼叫模式嘅研究喺呢度好有參考價值，可以幫你理解技能呼叫點樣喺 API 層面被記錄同追蹤——呢個係任何有意義嘅技能可靠性追蹤嘅前提條件。
常見問題
喺 agent 系統入面，工具（tool）同技能（skill）嘅分別係乜？
工具通常係一個離散嘅能力，有明確嘅輸入/輸出介面——一次函數呼叫、一個 API 端點、一個代碼執行器。技能係更高階嘅產物：一個結構化嘅工作流、推理策略或多步驟執行模式，用嚟編排工具嘅使用。工具係原子嘅，技能係組合嘅。EvoSkills 同 EvoSkill 論文專門針對技能層——決定 agent 點樣處理任務嘅部分，而唔淨止係佢能呼叫咩能力。
EvoSkills 同 EvoSkill 有乜分別？
EvoSkills 聚焦於任務無關嘅技能進化，喺 SkillsBench 上面進行評估——呢個係一個覆蓋多種專業任務嘅多領域基準測試。佢展示咗五輪進化入面通過率由 32% 提升到 75%，並證明進化技能喺第三輪就超過咗人工精選水平。EvoSkill 更專注於知識密集型 QA 任務（OfficeQA、SealQA），著重強調零樣本跨任務遷移——即為 SealQA 進化出嚟嘅技能唔使重新訓練就遷移到咗 BrowseComp。兩篇論文都證明咗自動進化優於人工編寫；佢哋喺範圍同所刻畫嘅特定遷移屬性上面有所不同。
EvoSkills 或 EvoSkill 進化出嚟嘅技能可以同任何 agent 一齊用嗎？
跨模型遷移結果（喺六個 LLM 上面 +35pp 到 +44pp）表明，進化技能編碼咗可跨唔同模型架構泛化嘅任務結構資訊。實際上，「任何 agent」講得太絕對——兩篇論文都喺特定框架同基準測試入面操作。更準確嘅講法係：喺一個模型下面進化出嚟嘅技能喺受控評估入面有意義噉遷移到咗其他模型。喺唔同 agent 運行時之間嘅真實世界可移植性仍然係一個開放嘅實現問題。
乜嘢係 SkillsBench？佢嘅結果有幾可靠？
SkillsBench 係 EvoSkills 論文入面引入嘅基準測試，旨在評估 agent 喺多步驟專業任務入面嘅技能質素。佢嘅結構設計唔淨止衡量任務完成度，仲衡量技能產物本身嘅質素——唔淨止睇 agent 係咪攞到正確答案，仲睇佢用嘅技能係咪能夠泛化。同任何研究基準一樣，結果應該喺上下文入面解讀：SkillsBench 由建構 EvoSkills 嘅同一團隊設計，喺評估獨立性方面值得留意。跨基準驗證（SealQA → BrowseComp 遷移）提供咗一啲外部信號，但呢個領域將受益於更多多樣化嘅、獨立建構嘅評估框架。
一個共享技能庫要喺網絡規模上面運作，實際需要啲乜？
至少需要：一個喺進化技能傳播之前測試佢哋嘅驗證機制，一個追蹤晉升同撤銷嘅版本控制同生命週期系統，一個語義索引層令 agent 唔使窮舉搜索就能識別相關技能，以及一種喺獨立進化出嚟嘅技能針對同一任務產生分歧時進行衝突解決嘅方案。更難嘅問題係治理（邊個決定一個技能「夠好」可以共享？）同質量衰減（點樣檢測一個之前可靠嘅技能喺上下文變化後退化咗？）。兩篇論文都冇回答呢啲問題——佢哋被明確標記為未來工作。
喺 EvoSkill 嘅語境入面，零樣本技能遷移係乜意思？
零樣本遷移意味住為一個任務進化出嚟嘅技能被直接應用於另一個唔同嘅任務，唔使任何額外訓練、微調或適配。喺 EvoSkill 嘅案例入面：為 SealQA 進化出嚟嘅技能被直接應用於 BrowseComp——一個具有唔同結構同領域嘅網絡研究任務——並喺冇任何任務特定重新訓練嘅情況下產生咗 +5.3% 嘅增益。呢度嘅「零樣本」指嘅係技能產物，而唔係底層模型。模型冇被微調；技能嘅 prompt/工作流被原樣複用。複用產生正向增益，呢個暗示嗰個技能編碼咗關於研究任務結構嘅某啲可泛化嘅嘢，而唔係 SealQA 格式所特有嘅狹窄內容。
往期文章：
