怎麼讓 Agent Skills 真正有效？OpenAI 與 Anthropic 官方評估指南及自動化迭代最佳實踐
整理版優先睇
總結OpenAI同Anthropic官方指南，提出一套系統化嘅Agent Skills評估同自動化迭代方法，核心係先用3-5條yes/no評分標準定義「好」，再用確定性檢查加LLM評分雙層評估，最後透過自動化循環持續優化。
呢篇文章嘅作者係一個技術愛好者，佢重讀咗OpenAI Codex、Anthropic Claude官方對Agent Skills測試評估嘅文章，同埋兩個開源項目（Skillgrade同autoresearch-skill），整理出一套「點樣令Agent Skills更有效」嘅心得。整體結論係：要令Skill有效，最關鍵係先定義清楚乜嘢叫「好」，建立系統化嘅評估體系，再用自動化迭代不斷改進。具體方法包括：為常用Skill寫3-5條yes/no評分標準，加入反例防止誤觸發，用確定性檢查覆蓋硬性要求、LLM Rubric覆蓋風格要求，記錄每次迭代變更。作者認為評估唔單止係質量檢查，仲係判斷Skill有冇存在必要嘅手段。
另外，作者指出幾點值得關注嘅方向。第一，Skill觸發精度係被嚴重低估嘅問題，name同description直接決定是否正確調用。第二，評估數據集唔需要大，10-20條測試prompt已足夠，關鍵係覆蓋顯式、隱式、帶噪音同反例。第三，評估基礎設施正在標準化，例如OpenAI嘅codex exec --json、Skillgrade嘅通用框架、Claude嘅skill-creator。第四，Skill可能演化為純規格說明，由模型自行決定實現路徑。
實操建議係：為常用Skill寫3-5條yes/no評分標準，呢個係投入產出比最高嘅第一步。在eval集中加入至少一條不應觸發嘅反例。用確定性檢查覆蓋硬性要求，LL…
- 結論：要令Agent Skills有效，最關鍵係先定義「好」，建立系統化評估體系，再用自動化迭代改進。
- 方法：採用「確定性檢查 + LLM Rubric」雙層評估，先用快速硬性檢查定位失敗，再用模型評分覆蓋模糊質量維度。
- 差異：能力增強型Skill隨模型進步可能失效，偏好編碼型更持久但需持續驗證保真度；評估體系本身可判斷Skill有無存在必要。
- 啟發：Skill觸發精度被嚴重低估，eval集需包含正例和反例；評估數據集10-20條足夠，關鍵係針對性。
- 可行動點：立即為每個常用Skill寫3-5條yes/no評分標準，開始記錄每次迭代變更日誌，並加入至少一條反例。
先定義「好」，再寫 Skill
OpenAI 嘅 eval 指南將成功標準分為四類：結果目標、過程目標、風格目標同效率目標。Anthropic 進一步區分兩類 Skill：能力增強型同偏好編碼型。前者隨模型進步可能失效，後者更持久但需持續驗證保真度。
評估唔單止係質量檢查，亦係判斷一個 Skill 是否有存在必要嘅手段。
能力增強型係模型本身做唔好嘅事，偏好編碼型係模型做到但需要特定流程。你應該先諗清楚你想解決邊類問題。
確定性檢查 + LLM 評分嘅雙層評估
三套工具都採用相同嘅分層結構：第一層係確定性檢查，第二層係 LLM Rubric 評分。
確定性檢查速度快、可解釋、可復現。
例如檢查文件是否存在、命令是否執行、輸出格式是否正確。OpenAI 通過解析 JSONL trace 嘅 command_execution 事件實現；Skillgrade 直接輸出 JSON 格式嘅 score + checks。
LLM Rubric 評分用模型對風格、流程合規性等定性維度打分。
OpenAI 使用 --output-schema 約束輸出為可比較嘅結構化 JSON；Skillgrade 用加權方式將兩層分數合併（如確定性 70% + LLM rubric 30%）。關鍵原則：先用快嘅硬性檢查定位明確失敗，再用模型評分覆蓋模糊質量維度。
自動化迭代循環（Autoresearch）
Ole Lehmann 將 Karpathy 嘅 autoresearch 思路應用到 Skill 優化，形成一個閉環：測試當前 Skill → 評分 → 分析失敗點 → 做一個小改動 → 重新測試 → 得分提升則保留，否則回滾 → 重複。
評分標準用 yes/no 清單，而非模糊嘅 1-10 打分，保證一致性。
例如「標題是否包含具體數字」而非「標題質量如何」。每次只改一個變量，確保歸因清晰；保留完整變更日誌，記錄每次嘗試嘅改動、原因同結果。
呢份日誌本身係可複用嘅優化知識。
Ole Lehmann 嘅案例：一個 landing page 文案 Skill 從 56% 通過率提升到 92%，4 輪改動中 3 次保留、1 次回滾，全程無人工幹預。
值得關注嘅四個方向
呢四個方向係作者認為最值得留意嘅趨勢。
Skill 觸發精度係被嚴重低估嘅問題。
Anthropic 同 OpenAI 都強調 SKILL.md 中嘅 name 同 description 直接決定 Skill 是否被正確調用。OpenAI 建議 eval 集同時包含正例同反例（should_trigger=true/false），Anthropic 嘅 skill-creator 新增觸發描述優化功能，改善咗 5 個 Skill 嘅觸發準確率。
評估數據集唔需要大，但需要有針對性。
OpenAI 明確建議 10-20 條測試 prompt 足夠，關鍵係覆蓋顯式調用、隱式調用、帶噪聲嘅上下文調用同反例。Skillgrade 都話 3-5 個精心設計嘅 task 勝過 50 個粗糙嘅。
- 評估基礎設施正喺度標準化：OpenAI 嘅 codex exec --json 原生 trace 捕獲，Skillgrade 嘅通用評估框架，Claude 嘅 skill-creator 內置 eval 生成同 A/B 對比。
- Skillgrade 嘅 eval.yaml 格式值得關注：將 workspace 文件準備、grader 定義、權重分配同 CI 集成統一到一個聲明式配置，降低門檻。
Skill 可能會演化為純規格說明。
Anthropic 提出 SKILL.md 可能從詳細操作指令演變為描述期望結果嘅規格說明，由模型自行決定實現路徑。而 eval 框架本身已經喺描述「乜嘢係好嘅結果」——未來 eval 可能就係 Skill。
「重讀OpenAI Codex、Anthropic Claude官方關於Agent Skills測試評估同提升嘅文章，以及兩位開源作者嘅Skills測試提升開源項目，整體重新梳理一次「點樣先可以令Agent Skills更有效？」」
開始之前先將參考嘅四篇文章同開源項目貼喺度，有興趣嘅朋友可以深入瞭解：
Testing Agent Skills Systematically with Evals
https://developers.openai.com/blog/eval-skillsImproving skill-creator: Test, measure, and refine Agent Skills
https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills"Unit tests" for your agent skills
https://github.com/mgechev/skillgradeautoresearch-skill
https://github.com/olelehmann100kMRR/autoresearch-skill
實操建議太長唔讀版本
為常用嘅Skill寫3-5條yes/no評分標準，呢個係投入產出比最高嘅第一步 喺eval集中加入至少一條唔應該觸發嘅反例，防止Skill被過度匹配 用確定性檢查覆蓋硬性要求，用LLM rubric覆蓋風格要求，分層評估比單一評分更加可靠 記錄每次迭代嘅變更同結果，呢份日誌嘅長期價值超過Skill本身
梳理開始
三條核心方法論
「1. 先定義「好」，再寫Skill」
OpenAI嘅eval指南將成功標準分為四類：
結果目標：任務是否完成，例如app能否運行 過程目標：是否按預期路徑執行，例如是否調用咗正確嘅skill 風格目標：輸出是否符合約定，例如係咪用Tailwind而唔係CSS modules 效率目標：是否存在浪費，例如不必要嘅重複命令、token消耗過高
Anthropic進一步區分咗兩類Skill：能力增強型（模型本身做唔好嘅事）同偏好編碼型（模型做到但需要按特定流程執行）。前者隨住模型進步可能失效，後者更持久但要持續驗證保真度。呢意味住評估唔單止係質量檢查，亦係判斷一個Skill係咪仍然有存在必要嘅手段。
「2. 確定性檢查 + LLM評分嘅雙層評估」
三套工具採用咗相同嘅分層結構：
第一層：確定性檢查 — 文件是否存在、命令是否執行、輸出格式係咪正確。速度快、可解釋、可復現。Skillgrade直接輸出JSON格式嘅score + checks，OpenAI透過解析JSONL trace入面嘅command_execution事件實現。 第二層：LLM Rubric評分 — 對風格、流程合規性等定性維度用模型打分。OpenAI使用--output-schema約束輸出為可比較嘅結構化JSON；Skillgrade用加權方式將兩層分數合併為最終得分（例如確定性70% + LLM rubric 30%）。
關鍵原則：先用快速嘅硬性檢查定位明確嘅失敗，再用模型評分覆蓋模糊嘅質量維度。
「3. 自動化迭代循環（Autoresearch）」
Ole Lehmann將Karpathy嘅autoresearch思路應用到Skill優化上，形成咗一個閉環：
測試當前Skill → 評分 → 分析失敗點 → 做一個小改動 → 重新測試 → 得分提升就保留，否則回滾 → 重複
呢度最有價值嘅設計決策：
評分標準用yes/no清單，而唔係模糊嘅1-10打分，保證一致性（例如「標題係咪包含具體數字」而唔係「標題質量如何」） 每次只改一個變量，確保歸因清晰 保留完整變更日誌，記錄每次嘗試嘅改動、原因同結果，呢份日誌本身就係可複用嘅優化知識
Ole Lehmann嘅案例：一個landing page文案Skill從56%通過率提升到92%，4輪改動中3次保留、1次回滾，全程無人工幹預。
「1. Skill觸發精度係被嚴重低估嘅問題」
Anthropic同OpenAI都強調：SKILL.md入面嘅name同description直接決定Skill係咪被正確調用。 OpenAI建議喺eval集中同時包含正例同反例（should_trigger=true/false），用嚟捕捉誤觸發。 Anthropic嘅skill-creator新增咗觸發描述優化功能，喺6個公開Skill中改善咗5個嘅觸發準確率。
「2. 評估數據集唔需要大，但係需要有針對性」
OpenAI明確建議：10-20條測試prompt足夠，關鍵係覆蓋顯式調用、隱式調用、帶噪聲嘅上下文調用同反例。隨住真實失敗案例嘅積累逐步擴展。 Skillgrade都推薦「3-5個精心設計嘅task勝過50個粗糙嘅」。
「3. 評估基礎設施正在標準化」
codex exec --json：原生trace捕獲 + 結構化輸出 Skillgrade：通用評估框架，含Docker沙箱 skill-creator：Claude內置eval生成 + benchmark + A/B對比
Skillgrade嘅eval.yaml格式值得關注：佢將workspace文件準備、grader定義、權重分配同CI集成統一到一個聲明式配置中，降低咗門檻。
「4. Skill可能會演化為純規格說明」
Anthropic喺文章末尾提出咗一個方向性判斷：隨住模型能力提升，SKILL.md可能從「詳細嘅操作指令」演變為「描述期望結果嘅規格說明」，由模型自行決定實現路徑。而eval框架恰好已經在描述「乜嘢係好嘅結果」——未來eval本身可能就係Skill。
資訊卡提示詞系列
「重讀 OpenAI Codex、Anthropic Claude 官方對 Agent Skills 測試評估和提升的文章，以及兩位開源作者的 Skills 測試提升的開源項目，整體重新梳理一下「怎麼才能讓 Agent Skills 更有效？」」
開始前先把參考的四篇文章和開源項目貼在這，感興趣的朋友可以深入去了解：
Testing Agent Skills Systematically with Evals
https://developers.openai.com/blog/eval-skillsImproving skill-creator: Test, measure, and refine Agent Skills
https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills"Unit tests" for your agent skills
https://github.com/mgechev/skillgradeautoresearch-skill
https://github.com/olelehmann100kMRR/autoresearch-skill
實操建議太長不讀版本
為常用的 Skill 寫 3-5 條 yes/no 評分標準，這是投入產出比最高的第一步 在 eval 集中加入至少一條不應觸發的反例，防止 Skill 被過度匹配 用確定性檢查覆蓋硬性要求，用 LLM rubric 覆蓋風格要求，分層評估比單一評分更可靠 記錄每次迭代的變更和結果，這份日誌的長期價值超過 Skill 本身
梳理開始
三條核心方法論
「1. 先定義 "好"，再寫 Skill」
OpenAI 的 eval 指南將成功標準分為四類：
結果目標：任務是否完成，比如 app 能否運行 過程目標：是否按預期路徑執行，比如是否調用了正確的 skill 風格目標：輸出是否符合約定，比如是否用 Tailwind 而非 CSS modules 效率目標：是否存在浪費，比如不必要的重複命令、token 消耗過高
Anthropic 進一步區分了兩類 Skill：能力增強型（模型本身做不好的事）和偏好編碼型（模型能做但需按特定流程執行）。前者隨模型進步可能失效，後者更持久但需持續驗證保真度。這意味着評估不僅是質量檢查，也是判斷一個 Skill 是否仍有存在必要的手段。
「2. 確定性檢查 + LLM 評分的雙層評估」
三套工具採用了相同的分層結構：
第一層：確定性檢查 — 文件是否存在、命令是否執行、輸出格式是否正確。速度快、可解釋、可復現。Skillgrade 直接輸出 JSON 格式的 score + checks，OpenAI 通過解析 JSONL trace 中的 command_execution 事件實現。 第二層：LLM Rubric 評分 — 對風格、流程合規性等定性維度用模型打分。OpenAI 使用 --output-schema 約束輸出為可比較的結構化 JSON；Skillgrade 用加權方式將兩層分數合併為最終得分（如確定性 70% + LLM rubric 30%）。
關鍵原則：先用快速的硬性檢查定位明確的失敗，再用模型評分覆蓋模糊的質量維度。
「3. 自動化迭代循環（Autoresearch）」
Ole Lehmann 將 Karpathy 的 autoresearch 思路應用到 Skill 優化上，形成了一個閉環：
測試當前 Skill → 評分 → 分析失敗點 → 做一個小改動 → 重新測試 → 得分提升則保留，否則回滾 → 重複
這裏最有價值的設計決策：
評分標準用 yes/no 清單，而非模糊的 1-10 打分，保證一致性（如"標題是否包含具體數字"而非"標題質量如何"） 每次只改一個變量，確保歸因清晰 保留完整變更日誌，記錄每次嘗試的改動、原因和結果，這份日誌本身就是可複用的優化知識
Ole Lehmann 的案例：一個 landing page 文案 Skill 從 56% 通過率提升到 92%，4 輪改動中 3 次保留、1 次回滾，全程無人工干預。
「1. Skill 觸發精度是被嚴重低估的問題」
Anthropic 和 OpenAI 都強調：SKILL.md 中的 name 和 description 直接決定 Skill 是否被正確調用。 OpenAI 建議在 eval 集中同時包含正例和反例（should_trigger=true/false），用來捕捉誤觸發。 Anthropic 的 skill-creator 新增了觸發描述優化功能，在 6 個公開 Skill 中改善了 5 個的觸發準確率。
「2. 評估數據集不需要大，但需要有針對性」
OpenAI 明確建議：10-20 條測試 prompt 足夠，關鍵是覆蓋顯式調用、隱式調用、帶噪聲的上下文調用和反例。隨着真實失敗案例的積累逐步擴展。 Skillgrade 也推薦"3-5 個精心設計的 task 勝過 50 個粗糙的"。
「3. 評估基礎設施正在標準化」
codex exec --json：原生 trace 捕獲 + 結構化輸出 Skillgrade：通用評估框架，含 Docker 沙箱 skill-creator ：Claude 內置 eval 生成 + benchmark + A/B 對比
Skillgrade 的 eval.yaml 格式值得關注：它將 workspace 文件準備、grader 定義、權重分配和 CI 集成統一到一個聲明式配置中，降低了門檻。
「4. Skill 可能會演化為純規格說明」
Anthropic 在文章末尾提出了一個方向性判斷：隨着模型能力提升，SKILL.md 可能從"詳細的操作指令"演變為"描述期望結果的規格說明"，由模型自行決定實現路徑。而 eval 框架恰好已經在描述"什麼是好的結果"——未來 eval 本身可能就是 Skill。
信息卡提示詞系列