git.kernel.org 真實流量只剩 2%,其餘全是 AI 爬蟲
people.kernel.org (Konstantin Ryabitsev) · 2026-08-29
Linux 基礎設施維護者 Konstantin Ryabitsev 在 8 月 29 日的部落格文章中公布了 git.kernel.org 目前的流量結構:五個分散節點、總共約 90 顆 CPU 核心裡,經常有 14 到 16 顆核心整天只做一件事——把 commit 逐筆渲染成 HTML 網頁。他估計,扣掉這些自動化請求後,真正的人類與合法用途流量大概只佔全站流量的 2%。
流量有多誇張
Ryabitsev 給出的具體數字包括:
- 每天約 600 萬次請求打到 git.kernel.org
- 其中 66% 被 Anubis 的驗證挑戰擋下,33% 成功解題後放行
- linux.git 本身有 148 萬筆 commit、922 個 fork,組合出「1.2 metric bajillion」個有效 URL 可供爬
- 光是應付這些請求,就長期吃掉全站約 20% 的運算資源
擋不住的 Anubis
kernel.org 用的防線是 Anubis——要求瀏覽器先算出一個帶有特定數量前導零的 SHA256 雜湊值才能放行,本質是工作量證明(proof-of-work)。Ryabitsev 一度把難度從 4 級調到 5 級,想靠計算成本擋住機器人,但爬蟲很快就跟上了新的難度設定,挑戰通過率並沒有明顯下降。
笨方法為什麼還在用
文章裡最讓人意外的一點是這些爬蟲效率極差:與其 git clone 一次整個 repo,它們選擇一頁一頁地把每個 commit 當成獨立網頁去要,對隨機的舊 commit、甚至冷門 fork 也照樣掃。Ryabitsev 連結到 spur.us 一篇談「智慧電視 App 內建住宅代理 SDK」的文章,暗示部分流量背後是把一般使用者裝置當成代理節點的商業模式,這也解釋了為何來源 IP 如此分散、難以直接封鎖。
Debian 投票落幕:八個 AI 提案中,「負責任使用生成式 AI」出線
debian.org 官方投票頁 · 2026-08-28
Debian 專案在 8 月 15 日至 28 日就「LLM 是否能用於 Debian 開發」舉行了 general resolution 投票,討論期則從 7 月 23 日就已展開。這次投票罕見地一次擺出 八個並列提案,從全面禁止到有條件開放都有,最終由編號 E 的「Responsible Use of Generative AI」勝出。
八個提案在爭什麼
| 提案 | 立場 |
|---|---|
| A | 透過 Social Contract 明文禁止 LLM 貢獻(需 3:1 絕對多數) |
| B | 有條件允許 AI 協助,要求檢查授權與可課責性 |
| C | 盡可能拒絕 LLM,修改行為準則要求揭露 |
| D | 僅接受 Debian 專屬工作中的 AI 貢獻 |
| E | 不鼓勵也不禁止,責任回歸貢獻者本人(勝出) |
| F | 謹慎態度,建議能避免就避免 |
| G | 禁止 AI 直接產出內容,但允許人類用 AI 輔助工作 |
| H | 以氣候成本為由,主張應避免使用 LLM |
除了 A 需要 3:1 絕對多數,其餘七案只需簡單多數並互相比較排序。根據 LWN 與 Phoronix 的報導,兩個明確反 AI 的提案(A、C)都沒能贏過「以上皆非」(NOTA)這個否決門檻,顯示反對聲音雖然存在(約三成投票者傾向禁用選項),但不足以形成多數共識。
E 案寫了什麼
勝出的 E 案明確寫道:「Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian.」換句話說,AI 輔助產出的內容與人類手寫內容適用同一套品質、正確性與法律合規標準,是否揭露使用了 AI 則不強制。專案機密資訊未經授權不得餵給第三方 AI 服務。
反對的聲音:Joey Hess
離開 Debian 十二年的前開發者 Joey Hess 在自己的部落格發文批評這個結果。他以自己當年寫的 debhelper 為例——即使把打包流程精簡到只剩極少量的樣板程式碼,那些剩下的樣板仍因為官方政策卡死而無法再刪。他認為 LLM 只會讓開發者更有效率地繞過這些過時規則,而不是推動政策本身被修掉,結果是 Debian 相對於 Guix 這類新一代發行版在依賴管理上的落後會被進一步鎖死,而不是被解決。
想幫 AI 代理人做記憶體工具,結果一頭撞進百年沒解的哲學難題
Substack (arbusto em chamas) · 2026-08-29
一位以「arbusto em chamas」為筆名的開發者在 Substack 發文,記錄自己嘗試用 Rust 寫一套給 AI coding agent 用的長期記憶系統的過程。原本只是想做個能跨 session 存取事實、支援矛盾偵測的本地資料庫,最後卻一路撞進「命題同一性(proposition identity)」這個自 1892 年就沒解開的哲學問題。
設計:事實只會被取代,不會被刪除
這套系統的核心是一個常駐的 Rust daemon,負責儲存 agent 學到的事實並跨 session 檢索。設計哲學是事實永遠不刪除,只會被新事實取代,藉此保留完整的信念變化歷史。檢索端則結合四種不同策略的結果,再交給本地小模型做 rerank。
野心:讓系統自己抓出矛盾
作者真正想做的是自動矛盾偵測,為此設計了一個「推理委員會」:溯因(abduction)負責提出可能原因,演繹(deduction)負責驗證,歸納(induction)負責學新規則。技術堆疊一路疊加:
- 四值 Belnap 邏輯格,用來區分「沒有記錄」與「已被反駁」
- 用 Agda 與 Cubical Agda 寫形式化證明
- Petri net 子系統模型
- 打算加入具有可證明重放性質的規劃語言
- 用 ASP(Answer Set Programming)自動生成規則
撞牆:命題同一性問題
系統上線後,矛盾偵測規則卻抓不到真正的矛盾。作者用 Claude 幫忙除錯,得到的解釋是:「你的衝突規則是靠語法上的相等在觸發……所以求解器根本沒有真的去判斷兩則記憶是不是互相矛盾」,因為「是不是同一個命題」這個判斷,發生在把自然語言轉成符號的那一步,而不是推理那一步。這個問題可以一路追溯到 Frege 1892 年討論「金星」與「晨星」(Hesperus/Phosphorus)是否為同一指稱的經典論文,後續在 Quine 的《Word and Object》(1960)以及當代「hyperintensionality」研究中持續被討論,至今沒有公認解法。
留下的書單
Claude 為此整理了一份跨領域閱讀清單,涵蓋 Stanford Encyclopedia of Philosophy 裡關於命題的條目、McCarthy 的情境形式化(context formalization)、Lenat 與 Guha 的 CYC microtheories、開放知識庫規範化(canonicalization)相關論文,以及 s(CASP)、STAR、NeurASP、ILASP 等 LLM 結合 ASP 的規則學習系統。
作者最後承認,這套記憶工具目前只做到「堪用」,矛盾偵測功能因為卡在命題同一性問題,始終沒有真正做出來。他在文中寫下:「cheap code does not translate into systems design prowess」「You can't Claude your way out of Problems」。