2026.07.21 —— 今日 10 則
TODAY'S THREAD 今天一邊是 AI 把「驗證」這件事同時變難也變強——從 arXiv 代筆比例的量測陷阱、coding agent 的沙箱逃逸，到拿 Claude 加定理證明器揪出藏了三年的 nftables 漏洞；另一邊，有人仍在單核 GEMM、64-bit 指標與 DDR5 記憶體這些底層，一寸一寸把極限與真相逼出來。
32% 的 arXiv 論文疑似 AI 代筆——但這個數字自己也會壞掉
有人用文本偵測器掃過 arXiv，估出近期約 32% 的論文疑似機器代筆、2026 年初一度逼近 39%，相較 ChatGPT 出現前的 0.4% 基準是整整跳了一個量級。分領域看差距極大：電腦科學高達 65%，數學卻只有 0.7%。但作者自己點破了關鍵陷阱——數學論文滿是符號、散文極少，本來就落在偵測器的分布之外，低分到底是「沒人用 AI」還是「偵測器根本看不出來」，這份資料無法分辨。
讓模型少想一點：控制 LLM 推理花費的幾種做法
當推理模型動輒吐出上千個 thinking token，怎麼讓它「該想多久就想多久」就變成一個真實的成本問題。這篇把目前的做法整理成幾條線：最省事的是把 effort 直接寫進 system prompt（GPT-5.6、gpt-oss 就這樣做），進階一點的是在 RLVR 訓練時對不同 effort 模式給不同的 per-token 成本、用長度懲罰把推理壓短，或用標好 effort 的 SFT 資料教模型在被截斷的推理裡也能收斂，Qwen3 甚至同時給了軟硬兩種開關。重點是效益會飽和——最高 effort 常常只換來成本上升、準確率卻打平。
多代理系統什麼時候才有用？一個 information bottleneck 的解釋
多代理（MAS）到底比單代理（SAS）好在哪，實務上表現時好時壞，這篇用 information bottleneck 給了個乾淨的解釋：SAS 把完整推理軌跡放在同一份共享脈絡，MAS 則靠有限的 relay 訊息串起各自隔離的脈絡——頻寬無限時兩者等價，真正的優勢只在頻寬受限、壓縮掉冗餘時才出現。結論很反直覺：relay 幾乎足夠時 MAS 穩定有幫助（對弱模型尤其明顯），但 relay 一旦有資訊損失，較強的模型反而因壓縮而變差。跨五個 benchmark、三種模型規模的實驗支持這個框架。
單核 Zen 3 榨到 85.3 GFLOPS：一場 FP32 GEMM 的極限逼近
一份 repo 把單顆 AMD Zen 3 核心上的 FP32 矩陣乘法，從最樸素的 ijk 三重迴圈約 1.5 GFLOPS，一路推到 85.3 GFLOPS——理論峰值 134.4 GFLOPS 的 63.5%。過程試了 28 種配置：先靠分塊與暫存器 blocking 把資料留在快取，再用 FMA chain-4 藏住相依延遲，最後靠開機時即時打包 B 區塊補上最後一哩。失敗的嘗試同樣有價值——stream store 只剩 1.24 GFLOPS，8-line blocking 因暫存器溢位掉到 12 GFLOPS。
InvisiCaps：用一般 64-bit 指標做出記憶體安全的 C
Fil-C 是把 C／C++ 變成記憶體安全的實作，靠 capability 在執行期動態擋掉越界存取。新一代的 InvisiCaps 最大突破是：在 64 位系統上就用標準 64-bit 指標、維持原本 ABI，把 capability 的邊界資訊藏在物件外的 aux 配置裡，程式只看得到指標的整數部分。代價是約 4 倍執行開銷——比早期 SideCaps 的約 200 倍、MonoCaps 的約 10 倍好得多，也換來 CHERI 那種 128-bit 硬體指標做不到的 ABI 相容與 union 支援。
用 Claude 加 Rocq 形式驗證 nftables，揪出藏了三年的防火牆漏洞
Basis Research 讓 Claude Opus 4.8 在 Rocq 定理證明器裡形式化並驗證 nftables 的 userspace，靠一個「一個 LLM 生成、另一個 LLM 挑錯」的對抗迴圈，覆蓋了約 90% 的規則語言。結果揪出兩個從 2022 年起存在於每個 Linux 版本的 bug：一個把 tcp flags 的位元遮罩最佳化成精確比對，悄悄把「拒絕」變成「放行」；另一個在合併位址範圍時產生重疊區間、讓 ruleset 被拒。關鍵是那個 bitmask bug——純靠 LLM 亂槍打鳥找不到，非得形式驗證才逼得出來。
ECC 與 DDR5：on-die ECC 不是你以為的那個 ECC
DDR5 內建的 on-die ECC 常被誤會成「終於人人有 ECC」，但作者點明它每 128 bit 只做 8 bit 的 Hamming 修正，是為了補救 DDR5 自身新問題的緩解，而不是取代主機板端那種能擋 DIMM 接觸不良與晶片故障的真 ECC。他引 Mozilla 的資料指出約 15% 的 Firefox 當機源自 RAM 硬體錯誤，而最完整的公開研究卻還停在 2009 年的 DDR／DDR2。實務建議很直接：買二手伺服器汰下來的 ECC RDIMM，別碰非 ECC 或 EC4 的 DDR5。
Jelly UI：把軟體物理塞進原生表單元件
Jelly UI 用一句話講完自己：「real form controls meet soft-body physics」——把原生表單控制項接上軟體物理的回彈感。它是一套無相依的 Web Components，一包 40 個自訂元件、接一個 script 標籤就能用，還內建 WCAG AA 色彩 token、深色模式與 RTL 支援。把觸感做進表單的嘗試不新，但用標準 Web Components 封裝又顧到無障礙，算是把這類玩法往「可用元件」推了一步。
四家 coding agent、七個沙箱逃逸：能寫檔案就等於沒被關住
Pillar Security 一口氣揭露橫跨四家 coding agent（Cursor、Codex CLI、Gemini CLI、Antigravity）的七個沙箱逃逸，核心模式驚人地一致：agent 本身不用直接突圍，只要能寫出檔案、讓某個「不受沙箱管卻信任這些檔案」的宿主元件之後去執行，就等於逃逸。實例包括改 virtualenv 直譯器、塞惡意 .git metadata 觸發 fsmonitor、寫 VSCode task 當「定時炸彈」，還有透過 Docker socket 拿到 RCE（GHSA-v4xv-rqh3-w9mc）。一句話：一旦 agent 能寫下系統未來的輸入，它從一開始就沒被沙箱關住。
MCP、A2A、ACP：三套 agent 溝通協定各自解決什麼
ByteByteGo 把三個常被混為一談的 agent 協定擺在一起講：MCP 管的是 agent 對「工具」的呼叫，A2A 管的是 agent 對 agent 的委派與協作（透過發佈在固定 URL 的 Agent Card 探索彼此），ACP 則是走 REST-first 的 agent 溝通、現已併入 A2A。重點是它們處理的是不同層、在生產環境裡是互補而非互斥。對正在拼 agent 系統的人，這是一張把「該用哪個」講清楚的分層地圖。