2026.08.09 —— 今日 10 則
TODAY'S THREAD 今天大半的題目都在問同一件事：一個介面到底有沒有把話講清楚。WebMCP 讓網站直接宣告自己有哪些工具，agent 不必再從給人看的頁面猜；RFC 10023 讓網域在 DNS 裡直說自己願意賣，不必先把首頁換成停放頁；而 The Bitter Lesson of Tool Calling 主張模型填 JSON 表格這個介面本身就是瓶頸，改成讓它寫程式在 14 個模型中的 11 個上追平或勝出。反面教材同樣清楚——eMicro 指出單看一跳合法看不出整條呼叫路徑違規，Eufy 門鈴那把解設定檔的金鑰全從韌體常數推導，作者推測各裝置間應該相同，隱藏網路的「隱藏」也就跟著失效，而 Assembly Hall of Shame 提醒你：指令延遲表上那個數字，從來不是那道指令唯一可能的成本。
別再填 JSON，讓模型寫程式
這篇把兩種工具呼叫介面放到同一把尺上量：一種是原生的 JSON tool calling，另一種是把工具寫成帶型別的 Python stub、讓模型用程式碼去呼叫，執行與取回結果都在同一個 agent turn 內完成。在 BFCL v4 上跨 14 個模型比較，programmatic tool calling 在其中 11 個追平或勝出，GPT-5.6 家族相對 JSON 基準線是 10.6% 的改善。兩個邊界條件把差距拉得更開：平行 fan-out 時 13 個模型追平或勝出，而在 context rot 條件下基準線平均退化 2.3%，程式碼那條路維持穩定。
三天的颱風預報，追上兩天的準度
DeepMind 的 WeatherNext 把路徑、強度與風場結構收進同一個模型，訓練資料是將近 20 TB 的全球大氣資料加上 IBTrACS 裡近 5,000 場歷史風暴，用 Functional Generative Networks 產生系集，一個氣旋可以跑出 1,000 種可能情境。官方給的說法是「我們的三天預報，跟先前模型只能提供的兩天預報一樣好」，等於整整多出 24 小時的前置時間，而一次 15 天的預報在 TPU 上不到一分鐘。它跑在 28×28 公里這種相對粗的解析度上，DeepMind 自己也說為什麼還能這麼準「仍是尚待理解的開放研究問題」。
單流全模態：MiniMax-H3 的取捨
MiniMax-H3 架構上刻意走「不分模態」的路線：33B 參數的 dense 單流 Transformer，其中約 13B 落在 AdaLN 相關分支，attention 與 FFN 層裡沒有任何模態專屬結構，位置編碼用三維的 MM-RoPE。視覺與音訊各自走 VAE 進來，H3-VisualVAE 是 16 倍空間、4 倍時間壓縮，H3-AudioVAE 處理 32 kHz 立體聲，輸出可以到 15 秒、24 FPS 的影片配 32 kHz 立體聲。長序列的 sparse attention 沒有包在這次開源裡，官方說會另外發布；SGLang 的部署範例用的是 4 張 GPU。
一道指令，跑六十二秒
指令延遲分析通常是為了最佳化，這個 repo 把方向倒過來，去找單一指令效能的絕對地板：setup 隨你怎麼鋪，但只有一道指令列入計分，時間以 CPU base clock 正規化，硬體必須是原廠出廠狀態。榜上的每一筆都對應一個具體的微架構理由——idiv 用 128 位元被除數把除法器的 microcode 走滿是 77 cycles，mfence 在 write-combining buffer 塞滿時是 326 cycles，rdrand 在熵池耗盡時是 5,579 cycles，Zen 上對 MCG_CTL 下 wrmsr 是 34,304 cycles。冠軍是 fxrstor64：512 位元組的狀態從高延遲 MMIO 載入，同時用其他核心把 PCIe root complex 打滿，量到 198,002,498,236 cycles，也就是 62 秒。
Nixpkgs core team 自己解散了
成立約十個月的 Nixpkgs core team 在 8 月 7 日宣布解散，職掌涵蓋專案方向、決策、與 NixOS Foundation Board 的協調以及團隊的建立與管理。公告把原因說得很直接：這個角色與實際的技術貢獻難以並存，加上他們形容 Steering Committee 這個機構「缺乏授權的本能直覺」、溝通長期不良，以及「對於我們是否被信任能自主做決定的普遍不確定」。招募也接不上——公開徵人只有一個人主動應徵。現在這塊的事務「目前沒有直接的負責人，SC 一如既往作為最後的後盾」，而 SC 改選在即。
從門鈴走進你家內網
研究者把 Eufy 視訊門鈴與 HomeBase Station 2 的整條鏈打通：先靠 90:bf:d9 這個 OUI 掃出 HomeBase，送 500 個廣播 deauth 把門鈴踢離 HomeBase 的隱藏網路，影像改成只錄在本機、不再上傳；再從 dump 出來的韌體逆出用聲波傳配對憑證的協定，19 個頻率、150 Hz 間距、每個符號約 65 到 70 毫秒，前段用 Reed-Solomon、最後一段用 CRC-16；最後用 Raspberry Pi 接上測試點，透過 SPI0 把門鈴的快閃記憶體讀出來。真正致命的是金鑰推導：一段寫死的 64 位元組字串與 0x01、0x04、0x06 的重複樣式 XOR 之後取 MD5，就是解開 es_config 的 AES-128-ECB 金鑰；因為推導過程全靠寫死的資料，作者判斷這把金鑰在各裝置間應該是同一把。
網域可以在 DNS 裡說自己要賣
RFC 10023 定義了一筆放在 _for-sale 底下的 TXT 記錄，格式從 v=FORSALE1 這個版本標籤開始，後面帶 ftxt、furi、fval 或 fcod 其中一個。它解的是規格書自己講的那個缺口：願意賣的人沒有辦法讓有興趣的買家知道，除非對方寄冷信給多半已被隱私遮蔽移除的 WHOIS 聯絡人。和停放頁不同的地方在於它不取代任何東西，「首頁繼續服務，郵件繼續流動」，靠的是 RFC 8552 的底線節點命名慣例，TTL 建議壓在 3600 秒以內。規格也直說沒簽 DNSSEC 的記錄「是別人偽造起來很舒服的東西」，而 ftxt 與 furi 都是攻擊者可控的內容，顯示前要消毒。
張量該有自己的一層
現在的 LLM 基礎設施裡，權重載入、KV cache 管理、checkpoint 同步各自和執行引擎、網路與儲存深度綁在一起，作者的觀察是這種專用化把策略鎖進彼此隔離的孤島，沒辦法重用。TensorCast 提出的是 Tensor-as-a-Service：一層分散式張量管理，給出「第一級的張量抽象、可程式化的生命週期原語，以及把張量管理策略與執行機制分開的 runtime」，已經接上 vLLM 與 SGLang，涵蓋權重具現化、同步、KV cache 與請求路由。論文回報在高併發多輪 agent 工作負載下，一組用 TensorCast 寫出來的可程式化策略讓中位數 TTFT 最多改善 93.2%。
讓網站自己長出 agent 介面
WebMCP 是「一個新的瀏覽器標準，在 Chrome 146 實驗性推出，在頁面裡以 document.modelContext 出現」，網站用 registerTool() 註冊工具，型別直接沿用 MCP 自己的 Tool 與 CallToolResult。Cloudflare 這一側的實作只有一個開關：打開之後用 HTMLRewriter 在每份 HTML 回應裡插一行 bridge script 的參照，origin 完全不用改。安全邊界寫得清楚——這個預覽版裡「每個工具都完全跑在訪客的瀏覽器裡，不會繞到我們的伺服器」，要接自家 MCP server 時也是從頁面上用訪客既有的 session 直連。差別在於 agent 不必再從給人看的頁面猜路，token 花在任務而不是導覽上。
每一跳都合法，整條路徑不合法
傳統的微服務存取控制一次只看一組服務對服務的呼叫，於是出現這種攻擊：「每一跳看起來都合法，整條路徑卻違反了安全意圖」。eMicro 的做法是讓執行點意識到路徑本身——追蹤呼叫順序、把策略編成 DFA 來快速驗證、用 eBPF 在 kernel 層攔請求。回報的數字是策略檢查 1 微秒、5,000 萬條策略只佔 100 MB、傳遞開銷降低 90%，評估用的是 Uber、Alibaba 與 ByteDance 數以百萬計的真實工作流程。論文已被 CCS 2026 接受。