Hermes Agent /learn + agent-skills：AI Agent 的技能革命

一句話摘要：NousResearch 推出 /learn 讓 Hermes Agent 從任何原始碼/文件自動蒸餾出可重複使用的 skill；Addy Osmani 公佈 agent-skills 工程 SOP 包。兩者結合，標誌著 AI agent 從「靜態訓練資料」走向「持續從活文件學習」的轉折點。

背景：兩個同時發生的事件

2026 年 6 月 23 日，兩個獨立事件在同一天匯聚：

NousResearch 在 X 宣布 Hermes Agent 的 /learn 功能——餵入任何目錄（程式碼、API 文件、手冊、PDF、設定檔），agent 會自動蒸餾成可驗證、可重複使用的 skill。推文 24 小時內獲得 74.3 萬次觀看。
Addy Osmani（Google Chrome 工程副總裁）公開 agent-skills repo——23 個結構化工程技能，覆蓋軟體開發全生命週期（Define → Plan → Build → Verify → Review → Ship）。

/learn 是什麼？

跟手動建立 skill（從零寫 SKILL.md）不同，/learn 讓 Hermes 自己讀完整個目錄樹、理解檔案間的結構與關係，然後產出完整結構的 skill——含觸發條件、逐步流程、驗證清單。

這讓任何 GitHub repo、任何內部文件都變成 AI agent 的「教材」。從此不再需要手寫 skill 文件——把 repo 餵進去，skill 自動生出來。

agent-skills：23 個工程 SOP

階段	核心技能	數量
Define	interview-me, idea-refine, spec-driven-development	3
Plan	planning-and-task-breakdown	1
Build	TDD, incremental-implementation, source-driven, doubt-driven, frontend-ui, api-design, context-engineering	7
Verify	browser-testing-with-devtools, debugging-and-error-recovery	2
Review	code-review, code-simplification, security-hardening, performance-optimization	4
Ship	shipping-launch, ci-cd, git-workflow, deprecation-migration, docs-and-adrs	5

每個 skill 不是模糊建議，而是結構化流程——具體步驟、驗證要求、防呆清單，確保 agent 不會跳過關鍵工程紀律。

我們落地了什麼？

分析完 23 個 skill 後，發現許多在我們的 Hermes 生態系已有對應版本（TDD、code review、debugging 等）。我們挑了 3 個帶來實際新價值的：

1. Source-Driven Development（新建）

管線：DETECT（從 package.json/requirements.txt 讀取框架版本）→ FETCH（擷取官方文件，不用 Stack Overflow）→ IMPLEMENT（使用確切 API 簽名）→ CITE（在註解中標註來源 URL）。

這是我們 Hermes 生態中完全沒有的技能。它解決 AI agent 根據過時訓練資料寫程式的問題——例如專案跑 React 19 卻寫出 React 18 的 deprecated API。

2. Doubt-Driven Development（整合進既有 skill）

五步循環：CLAIM（陳述決策）→ EXTRACT（隔離最小審查單元）→ DOUBT（fresh-context reviewer + 對抗性提示）→ RECONCILE（四分類：合約誤讀 / 有效+可行 / 有效取捨 / 雜訊）→ STOP（3 輪後或只剩 trivial 發現）。

我們沒有另建 skill，而是直接整合進現有的 multi-model-code-review（本來就用 4 模型交叉驗證）。Hermes 的 4 模型審查本身就比原版 doubt-driven（只用 1 個 reviewer）更強，所以只補了「對抗模式」——在程式碼定稿前就審查，不是事後才看。

3. Deprecation & Migration（跳過）

這個 skill 我們直接跳過。理由：低頻率操作（一年不到 5 次），不值得建立專用 skill。我們的原則是：只自動化真正重複發生的事。

Ponytail 紀律 vs 工程嚴謹度

一個有趣觀察：我們的 Ponytail 紀律（懶惰資深工程師：不必要的不寫、內建優先、刪除優於新增）看似與 agent-skills 的嚴謹對立——但實際上是互補的。

Ponytail 紀律	agent-skills 嚴謹
只寫真正需要的程式碼（YAGNI）	先寫 spec 再寫 code（spec-driven）
用標準庫，避免新依賴	引用官方文件，驗證版本（source-driven）
刪除多餘程式碼，保持最少檔案	五軸審查，對抗壞模式（code-review）
「你真的需要 X，還是 Y 就夠了？」	「這個設計的哪個假設會崩潰？」（doubt-driven）

交會點：兩者都反對盲目寫程式。Ponytail 問「需要寫嗎」，agent-skills 問「寫對了嗎」。結合兩者：只寫需要的，而且第一版就寫對。

意義

Hermes /learn 與 agent-skills 的結合，標誌著一個轉折點：AI agent 不再受限於靜態訓練資料。它們可以從活的文件持續學習——最新 API 文件、內部 coding convention、團隊部署流程——並自動轉化為一致的行為。

核心教訓：不需要整包進口。讀懂、篩選、整合進現有體系。一個為你的生態系量身打造的 skill，勝過 10 個複製貼上的 skill。