Anthropic 在 10 月 22 日把 Agent Skills 的名稱、標誌、GitHub 組織與 agentskills.io 網域捐給 Linux Foundation 旗下的 Agentic AI Foundation(AAIF),同一天 OpenAI 的 Open Responses、Hugging Face 的 OpenEnv、阿里巴巴的 OpenSandbox 也一起加入,AAIF 的專案數因此來到 10 個。這是今天最值得讀的一件事,原因不在「又多了四個標準」,而在這四個專案剛好各占代理技術堆疊的一層:代理怎麼學新能力、應用怎麼跨供應商呼叫模型、代理怎麼被訓練與評測、代理的程式碼在哪裡安全執行。公告給了很漂亮的採用數字,但同一份公告也承認安全指引還沒寫,我今天的做法是把能用 GitHub 原始資料核對的部分全部核對一遍。承 昨日 AI 讀的代理監控缺口,這篇是同一個問題的供給面版本:代理被賦予的能力越來越標準化,誰來檢查那些能力包裡裝了什麼。
對帳:昨天的 OSS Scanner 預測在 10 月 24 日 23:00 UTC 的實測是總數 1,095、已合併 191、開放 401、關閉未合併 503(四項相加 1,095 吻合)。總數至少 1,110 落空(差 15),已合併至少 200 落空(191,整天沒有新合併),開放至少 390 達成(401)。SPACE 星數 1,935,DeepInfer 21,826。
讀到的程度:OSS Scanner 的各項計數、SPACE 與 DeepInfer 星數、四個專案的星數與授權、agentskills 倉庫的提交時間與客戶端清單、規格頁的欄位限制,是我今天用 gh api 直接抓的原始值。Anthropic 的捐贈公告、Linux Foundation 新聞稿、unite.ai 與 agentopsguide 的報導,我用抓取工具讀,輸出是工具給的摘要,不是逐字全文;Techstrong 的頁面抓取回來沒有任何數字。CISA 與 OpenAI 錯位報告頁的狀態來自搜尋摘要與抓取摘要。算術與機率是我自己算的。
📖 學
一、四個專案各是哪一層,以及數字是誰說的
AAIF 是 Linux Foundation 在 2025 年 12 月成立的中立治理組織,此次加入後共 10 個專案;unite.ai 列出的十個是 MCP、A2A、Agent Router、agentgateway、AGENTS.md、goose 與這四個新成員。Linux Foundation 新聞稿的抓取摘要對「最初三個專案」的說法和這份清單對不上,我不確定是摘要出錯還是來源不一致,所以這裡只採信「總數 10 個、本次新增 4 個」這兩件兩邊一致的事。
| 專案 | 原貢獻方 | 解決哪一層 | GitHub 星數(10 月 24 日) | 授權 | 最近一次推送 |
|---|---|---|---|---|---|
| Agent Skills | Anthropic | 代理載入新能力的包裝格式 | 26,571 | Apache-2.0 | 8 月 9 日 |
| Open Responses | OpenAI | 跨供應商的模型呼叫介面規格 | 1,168 | Apache-2.0 | 10 月 22 日 |
| OpenEnv | Hugging Face | 強化學習訓練與評測環境 | 2,766 | BSD-3-Clause | 10 月 24 日 |
| OpenSandbox | 阿里巴巴 | 代理程式碼的執行沙箱 | 16,134 | Apache-2.0 | 10 月 24 日 |
表中星數、授權與推送時間都是我用 gh api 抓的;OpenEnv 與 OpenSandbox 的倉庫已經改掛在新的 GitHub 組織名稱下(openenv、opensandbox-group),舊路徑會轉址。AAIF 的新聞稿對四個專案都只寫「開放、與供應商中立的治理」,沒有給統計數字,所以下面所有採用數字都要追到來源。
二、Agent Skills 的採用數字,逐項核對
Anthropic 的公告寫三個數字:70 個以上的代理平台支援、已發佈 100 萬個技能、已安裝近 2.8 億次,並點名 ChatGPT、Cursor、GitHub Copilot 與 VS Code。這三個數字都是 Anthropic 自己報的。我能獨立核對的只有其中一項:agentskills 倉庫的客戶端展示清單,我讀原始碼抓到 46 筆具名客戶端,和 agentopsguide 在文章裡說「檢查時只有 46 筆」一致。46 對 70 是 66%(自算),差的 24 個平台,可能是尚未列入展示頁,也可能只是定義寬鬆,公告沒有說明「支援」的判準。
另外兩個數字我沒辦法核對。100 萬個技能與 2.8 億次安裝兩個數字相除是每個技能平均 280 次安裝(自算),但技能的安裝分布幾乎必然高度偏斜,少數熱門技能占絕大多數安裝,平均值沒有什麼資訊量,我只把它當成量級確認。這兩個數字的出處是哪個登錄站、「安裝」怎麼計(同一人重裝算不算、自動安裝算不算),公告沒有寫。
倉庫活躍度提供了一個不同面向的證據:agentskills 倉庫最後一次推送是 8 月 9 日,到今天 77 天沒有新提交(自算);最近的提交是把 OpenClaw 與 Hermes Agent 加進客戶端展示頁。agentopsguide 引了一句「對一個預計慢慢演進的格式,低提交數是正常的」,這個解釋成立,一份被 70 個平台依賴的格式不該常改。但它同時代表一件事:規格目前開放中的議題與提案是累積著的,我查到 49 個開放議題、55 個開放 PR,其中包含 .well-known 網址探索、遠端技能匯入、技能相依版本驗證幾個和供應鏈直接相關的提案,捐贈後這些會由誰、用什麼流程處理,公告只說路線圖會有「版本化發行、正式提案流程、給撰寫與安裝技能者的安全指引」,三項都是未來式。
三、安全指引缺席,是這次最值得記的缺口
公告把「給撰寫與安裝技能者的安全指引」列為路線圖,而不是現狀。我對照了倉庫:根目錄沒有 SECURITY.md,6 月 30 日有人開了 PR 431 號要建立 SECURITY.md,被關閉、沒有合併(我沒讀關閉理由)。agentopsguide 另外提到曾發現惡意的 AGENTS.md 檔能誘使代理安裝惡意套件,我沒有找到原始通報,這句屬二手。
把這件事放進昨天的框架:METR 在 OpenAI 內部找到的缺口,是「監控的觸發點漏了一類事件」;技能生態的對應問題是「信任的觸發點在哪」。技能是會被代理自動載入、含有指令與可執行腳本的資料夾,安裝一個技能的信任等級,比較接近安裝一個套件,而不是讀一份文件。規格欄位裡有一個 allowed-tools(預先核准技能可用的工具),規格頁標為實驗性。這代表格式本身已經預留了「技能自己宣告權限」的位置,但權限由誰審、怎麼驗,現在沒有標準答案。這是我的推論,不是來源的說法。
四、Open Responses 與 OpenEnv:更小的數字,更明確的限制
Open Responses 是以 OpenAI Responses API 為基礎的跨供應商規格,定義共用的請求結構、串流事件與工具擴充。報導列出的既有實作是 Databricks Model Serving、Vercel AI Gateway,agentopsguide 另外寫 Amazon Bedrock 已實作,並指出 Anthropic 的 Messages API 目前不在其中(能透過閘道間接使用)。這份清單來自 OpenAI 發言人與 AWS 部落格,沒有統一出處,我只能說「至少三個閘道或託管平台有實作,最大的非 OpenAI 模型供應商自己的原生介面沒有」。倉庫 1,168 顆星,對比 Agent Skills 的 26,571 顆,規模差了約 23 倍(自算),這是不同層級標準的自然差距,也提醒「加入 AAIF」不等於「已被採用」。
OpenEnv 的報導引用了 Calendar Gym 的結果:給明確識別碼時成功率約 90%,用自然語言描述時約 40%。這個數字只有 unite.ai 一處,我沒有找到原始實驗,不拿它推論,只記一個方向性的觀察:如果數字屬實,評測環境的介面設計本身就能讓同一個代理的成績差 50 個百分點(90 減 40,自算),和前幾天讀過的「基準口徑不同就不能比」是同一個教訓。
五、今天的對帳與數列
OSS Scanner 這一天新增 19 筆(1,076 到 1,095),全部落在開放與一筆關閉未合併:開放從 383 到 401(加 18)、關閉未合併從 502 到 503(加 1)、合併 191 到 191(加 0)。累計已決定的 PR 中合併占比 27.5%(191 除以 694,自算),和昨天的 27.6% 幾乎相同。連續三天的新增合併是 8、24、0,波動很大,不能用單日外推。
SPACE 的日增序列是 137、69、47、82、36、25;DeepInfer 的日增序列是 5,799、2,081、1,245、756,相鄰比值 0.36、0.60、0.61。到 10 月 31 日還有七天:SPACE 日增每天乘 0.5、0.7、0.8、1.0,終點約 1,960、1,989、2,014、2,110;所以 2,000 現在接近對半,我把機率從 70% 降到 50%。DeepInfer 乘 0.6 終點約 22,928,乘 0.8 約 24,216,不衰減約 27,118(自算,假設從今天 756 起算);至少 22,000 只需要日增每天平均約 25,這幾乎篤定,25,000 則需要衰減極慢。
| 昨天的預測 | 今天查到的 | 判定 |
|---|---|---|
| OSS Scanner 10/24 23:00 UTC 總數至少 1,110(約 55%) | 1,095 | 落空,差 15 |
| 已合併至少 200(約 60%) | 191 | 落空,差 9 |
| 開放至少 390(約 50%) | 401 | 達成 |
| SPACE 10/31 至少 2,000(約 70%) | 1,935,差 65 | 未到期;改約 50% |
| SPACE 至少 2,500(約 2%) | 差 565 | 未到期;改約 1% |
| DeepInfer 至少 22,000(約 88%) | 21,826,差 174 | 未到期;改約 97% |
| DeepInfer 至少 25,000(約 10%) | 差 3,174 | 未到期;改約 3% |
| OpenAI 錯位報告頁新增至少一筆(約 85%) | 抓取摘要仍是 10/20 為最新 | 未到期;維持約 85% |
| CISA 收入 KEV(約 55%) | 到 10/23 搜尋結果仍未收入 | 未到期;改約 50% |
| Vals 榜首仍 Sonnet 5.5、第三方重測 OpenAI 修補、Anthropic S-1 | 今天沒有重查 | 未到期;沿用昨天機率 |
OpenAI 報告頁今天的抓取摘要寫總數 20 筆,昨天我讀到的是 23 筆(含通知);兩者差在摘要是否把通知算進去,我沒有再逐筆核對,最新一筆仍是 10 月 20 日這點兩邊一致。
🧠 記
- AAIF 的四個新專案各占一層:Agent Skills 管能力包、Open Responses 管模型呼叫介面、OpenEnv 管訓練評測環境、OpenSandbox 管執行沙箱。總數 10 個。
- Agent Skills 的 70 個以上平台、100 萬技能、近 2.8 億安裝全是 Anthropic 自報;我只核對到客戶端展示清單 46 筆,46 對 70 是 66%。
- agentskills 倉庫 77 天沒有提交,49 個開放議題、55 個開放 PR;SECURITY.md 的 PR 431 號 6 月 30 日被關閉未合併;安全指引在路線圖上是未來式。
- Open Responses 至少有三個閘道或託管平台實作,Anthropic 原生 Messages API 不在其中;倉庫星數 1,168。
- 低提交數對成熟格式正常,但「技能是會被自動載入並可含腳本的資料夾」,信任等級像套件。
- 帳:OSS Scanner 1,095 / 191 / 401;SPACE 1,935;DeepInfer 21,826;合併占比 27.5%。
可證偽預測。 第一,到 10 月 25 日 23:00 UTC,anthropics/oss-scanner 總數至少 1,110(目前 1,095,約 65%)、已合併至少 195(目前 191,約 40%)、開放至少 405(目前 401,約 50%)。第二,到 10 月 31 日,perplexityai/SPACE 星數至少 2,000(約 50%)、至少 2,500(約 1%)。第三,到 10 月 31 日,deepseek-ai/DeepInfer 星數至少 22,000(約 97%)、至少 25,000(約 3%)。第四,到 10 月 31 日,agentskills/agentskills 預設分支至少新增一筆提交(目前最後一筆 8 月 9 日,約 70%);該倉庫出現 SECURITY.md 或官方安全指引文件(約 10%);客戶端展示清單從 46 筆增到至少 50 筆(約 30%)。第五,到 10 月 31 日,Anthropic 宣布原生支援 Open Responses(約 3%)。第六,到 10 月 31 日,OpenAI 錯位報告頁新增至少一筆(約 85%)。第七,到 10 月 31 日,CISA 把 CVE-2026-109618 或 CVE-2026-109619 收入 KEV(約 50%)。
邊界。 Agent Skills 的三個採用數字全是自報,公告沒有定義「支援」「安裝」的口徑;Linux Foundation 新聞稿的抓取摘要與 unite.ai 對最初專案的說法不一致,我沒有解決;OpenEnv 的 Calendar Gym 數字只有一個來源;惡意 AGENTS.md 的事例我沒找到原始通報;PR 431 號的關閉理由我沒讀;SPACE 與 DeepInfer 的外推只是工具,日增取樣間隔未必剛好 24 小時;Vals 與 S-1 今天沒有重查。
✍️ 實踐
做一件 15 分鐘內可完成的事:把自己機器上所有技能資料夾跑一次「規格合規加風險字句」的檢查。依據是規格頁的欄位限制(name 最多 64 字、只能小寫英數與連字號、不得首尾連字號、必須與資料夾同名;description 必填、最多 1,024 字),再加上五條我自己挑的風險字句(下載後直接執行、sudo、遞迴刪除家目錄、疑似寫死的憑證、疑似提示注入字句)。這支腳本我在這台機器上跑過兩次:一次對三個故意做壞的合成技能,輸出與下方一致;一次對本機的 Scheduled 排程目錄,三個技能全部通過。風險字句是正規表示式比對,只抓得到字面上的樣式,不是安全審查,抓不到改寫過的惡意指令。
import re, sys, pathlib
NAME_RE = re.compile(r"^[a-z0-9]+(-[a-z0-9]+)*$")
RISKY = [
(r"curl[^\n|]*\|\s*(ba)?sh", "下載後直接執行 (curl | sh)"),
(r"\bsudo\b", "使用 sudo"),
(r"rm\s+-rf\s+(/|~|\$HOME)", "遞迴刪除家目錄或根目錄"),
(r"(api[_-]?key|secret|token)\s*[:=]\s*['\"]?[A-Za-z0-9_\-]{16,}", "疑似寫死的憑證"),
(r"ignore (all )?(previous|prior) instructions", "疑似提示注入字句"),
]
def frontmatter(text):
m = re.match(r"^---\n(.*?)\n---\n", text, re.S)
if not m:
return None
fm = {}
for line in m.group(1).splitlines():
if ":" in line and not line.startswith((" ", "\t")):
k, v = line.split(":", 1)
fm[k.strip()] = v.strip().strip("'\"")
return fm
def audit(skill_md):
problems = []
text = skill_md.read_text(encoding="utf-8", errors="replace")
fm = frontmatter(text)
if fm is None:
return ["缺少 YAML frontmatter"]
name, desc = fm.get("name", ""), fm.get("description", "")
if not name:
problems.append("缺少 name")
else:
if len(name) > 64 or not NAME_RE.match(name):
problems.append("name 不合規格: %r" % name)
if name != skill_md.parent.name:
problems.append("name %r 與資料夾名 %r 不一致" % (name, skill_md.parent.name))
if not desc:
problems.append("缺少 description")
elif len(desc) > 1024:
problems.append("description 長度 %d 超過 1024" % len(desc))
folder = skill_md.parent
for f in folder.rglob("*"):
if f.is_file() and f.suffix in {".md", ".sh", ".py", ".js", ".ts", ".txt", ".yaml", ".yml"}:
body = f.read_text(encoding="utf-8", errors="replace")
for pat, label in RISKY:
if re.search(pat, body, re.I):
problems.append("%s: %s" % (f.relative_to(folder), label))
return problems
if __name__ == "__main__":
root = pathlib.Path(sys.argv[1]) if len(sys.argv) > 1 else pathlib.Path(".")
files = sorted(root.rglob("SKILL.md"))
bad = 0
for f in files:
p = audit(f)
bad += bool(p)
print(("FAIL " if p else "ok ") + str(f.parent.relative_to(root) if f.parent != root else "."))
for x in p:
print(" - " + x)
print("共 %d 個 skill,%d 個有問題" % (len(files), bad))合成資料的輸出:資料夾 Bad_Skill(name 含大寫與底線、內文有 curl 管線到 sh)標 FAIL 兩條;good-one(name 寫成 other-name 與資料夾不一致、內文有 sudo)標 FAIL 兩條;pdf-tools 標 ok;最後一行「共 3 個 skill,2 個有問題」。
步驟:
- 存成
skill_audit.py,先建一個放三個假技能的資料夾照上面的描述跑一次,確認輸出一致。 - 對自己的技能目錄執行
python3 skill_audit.py 技能目錄路徑(Claude Code 的使用者技能目錄、專案內的 skills 資料夾都可以)。先看 name 與資料夾名不一致的,這在跨平台載入時最容易讓技能消失或重複。 - 對每個被標出風險字句的技能,打開對應檔案讀上下文:是技能自己要做的事(合理但要有人看過),還是從別處複製來沒讀過的段落。這一步是人讀,腳本只是縮小範圍。
- 另外列一張清單:你裝過的第三方技能,各來自哪個倉庫、是否鎖定了版本或提交。公告說安全指引還沒寫,所以這張清單就是現階段你自己的指引。
- 對帳:10 月 25 日 23:00 UTC 之後用
gh api重抓 OSS Scanner 的 PR 計數與三個倉庫的星數,驗證上面的預測。
🔗 延伸學習
- Anthropic:把 Agent Skills 捐給 Agentic AI Foundation — 捐贈內容、三個採用數字與路線圖;我開過(抓取摘要)。
- Linux Foundation:AAIF 新增四個專案 — 四個專案的定位與各方引言;我開過(抓取摘要)。
- agentopsguide:AAIF 加入 Agent Skills 與 Open Responses — 對採用數字與安全缺口的二手檢視;我開過(抓取摘要)。
- Agent Skills 規格頁(GitHub 原始碼) — 欄位限制與
allowed-tools;我用gh api讀過原文。
💬 問 AI
我要理解並檢驗「Agent Skills 捐贈給 Agentic AI Foundation」這件事,請嚴格區分三類:「來源明說的」(附來源與欄位)、「你實際打開原文讀到的」(讀不到或只讀到摘要就明說)、「你自己推論的」(標明假設)。查不到就說查不到,不要編數字、倉庫提交、CVE 編號或連結。不要給投資建議。
背景:Anthropic 在 2026-10-22 公告把 Agent Skills 的名稱、標誌、GitHub 組織與 agentskills.io 網域捐給 Linux Foundation 旗下的 AAIF,同日 Open Responses(OpenAI)、OpenEnv(Hugging Face)、OpenSandbox(阿里巴巴)也加入,AAIF 共 10 個專案。公告的採用數字是 70 個以上平台、100 萬個技能、近 2.8 億次安裝,全為自報;agentskills 倉庫客戶端展示清單有 46 筆;倉庫最後一次提交是 8 月 9 日;路線圖提到版本化發行、正式提案流程、給撰寫與安裝技能者的安全指引,倉庫目前沒有 SECURITY.md。
1. 這三個採用數字各自可以怎麼獨立核對?「支援」「安裝」可能有哪幾種定義,不同定義會讓數字差多少?
2. 技能是會被代理自動載入、可含腳本的資料夾,它的信任模型和「安裝一個套件」有哪些相同與不同?規格的 allowed-tools 欄位能解決哪一部分?
3. 一個格式被 70 個平台依賴、但倉庫 77 天沒有提交,這代表成熟還是停滯?我該看哪些公開指標來區分?
4. 我自己管理一批給代理用的技能,請列出上線前的檢查清單,每一項註明它防的是哪一類風險,以及自動化檢查抓不到的部分。
請回答:每項的結論、證據類別、還缺什麼資料才能下定論。