2026.05.27 —— 今日 10 則
TODAY'S THREAD 今天的軸線是「瓶頸到底在哪一層」——agentic AI 把焦點從模型移到外圍的 harness、DOOM 跑在 SQL 上逼出交易與分析的取捨、Itanium ABI 攤開 virtual dispatch 真正的代價，再到 Vera CPU 把記憶體頻寬量到額定峰值的 90%、Chromium 把 embedding 模型搬進瀏覽器——每一則都在問：該被優化、該被搬動、該被量測的，究竟是哪一層。
從 model scaling 到 system scaling——agentic AI 的下一個瓶頸是 harness
Shangding Gu 這篇 position paper 主張，agentic AI 接下來的瓶頸不在模型本身，而在模型外那層結構化執行環境——他稱之為「scaling the harness」，把 memory、retrieval、tool use、orchestration、verification 與 governance 當成第一級的設計對象，而非實作細節。論文點出三個核心瓶頸：context governance、trustworthy memory 與 dynamic skill routing，並主張該用 trajectory quality、memory hygiene、verification cost 這類指標取代「最終任務成功率」。作者放出 CheetahClaws 這個 Python-native 參考 harness，拿來跟 Claude Code 與 OpenClaw 對照。
Language Models Need Sleep——用睡眠鞏固對付長 context 的注意力成本
Transformer 的注意力隨 context 長度暴漲，這篇論文借神經科學的「睡眠鞏固」想法，讓模型在長任務中段做一次 sleep-like consolidation，把累積的 context 壓成更穩定的記憶後再續跑。賣點是用週期性鞏固換掉「把整段歷史都攤在 attention 裡」的成本。對在跑 long-horizon agent、被 context window 與 KV cache 卡住的人，這是一條跟單純加長 window 不同的路。
Gemini 3 Flash 進駐 Gemini CLI——SWE-bench Verified 76%
Google 在 I/O 2026 之後把 Gemini 3 Flash 接進 Gemini CLI：主打 Pro 級的 coding 能力，但延遲與成本都低，官方數字是 SWE-bench Verified 拿到 76%，且在 agentic 任務上勝過前代。對天天在 terminal 裡讓模型改 code 的人，這把「便宜模型只能做簡單事」的假設又往上推了一格。
Itanium C++ ABI 裡的 vtable 到底長怎樣——從 offset-to-top 到 virtual thunk
vptr 並不指向 vtable 的開頭，而是指向 address point——也就是第一個函式項（+16），typeinfo 與 offset-to-top 反而擺在負偏移上。這篇把 Itanium C++ ABI 的 vtable 佈局攤開：單一繼承怎麼原位覆寫、多重繼承為什麼要多個 vptr 加 non-virtual thunk（subq $16, %rdi）把 this 調回完整物件，virtual 繼承又怎麼靠 vcall／vbase offset 與 VTT 在執行期定位虛擬基底。讀完你會知道 dynamic_cast、虛擬解派與那三種解構子（D0／D1／D2）背後到底動了什麼。
C extensions、可攜性與替代編譯器——為什麼 tcc／cproc 老是卡在 glibc
真實世界的 C 程式碼到處依賴非標準擴充——__attribute__((packed))、GCC 風格 inline asm、__has_builtin——而 glibc 的 sys/cdefs.h 只認得「gcc、clang 與相容者」，其餘編譯器一律當成沒有屬性。結果 tcc、cproc、kefir 這些替代編譯器常卡在上游函式庫把進階功能 gate 在 GCC 版本檢查後面，只能下游 patch、裝成 GCC，或被邊緣化。文章用 OpenBSD 的 __only_inline、SDL 的 byteswap 偵測當例子，把「可攜性」的真實代價講清楚。
替 Nintendo 3DS 從零寫一個 async executor——合作式多工下的 Future 與 Waker
這是系列第一篇：在 Nintendo 3DS 上用 Rust 從零寫一個 async executor。3DS 是合作式（非搶佔）多工，thread 只在主動讓出時才暫停，所以作者直接套用標準的 Future／Waker／Context，用一個 mpsc channel 把 wake 請求送回中央 Executor，再用 BTreeMap 輪詢 task。關鍵在於 waker 觸發 re-poll、避免 busy-loop，同時尊重「忘了 yield 就會卡死所有人」的合作式模型。
NVIDIA Vera——88 顆 Olympus 核心、為 agent 而生的第一顆 CPU
NVIDIA 第一顆通用 CPU Vera 用 88 顆自研 Olympus 核心（Armv9.2）、1.2TB/s 記憶體頻寬、450W TDP，Phoronix 實測比上一代 Grace 快 1.6 倍，整體比一顆 128 核 x86 快 1.5 倍、比 AMD EPYC 9575F 高約 10%。最亮眼的是記憶體：STREAM TRIAD 跑到額定峰值的 90%，是受測 CPU 裡最高的，每核頻寬是傳統 x86 的四倍多，單 socket 編一份 Linux kernel 只要 20 秒。
Chromium 提案 Embedding API——把 on-device 向量模型搬進瀏覽器
Chromium 在 blink-dev 丟出 Embedding API 的 Intent to Prototype：讓網頁直接在使用者裝置上生成內容的高維向量 embedding，靠 Chrome 內建的 on-device 模型，而不必每個站台各自下載數百 MB 的 WASM／WebGPU 模型、也不必把敏感資料送上雲。設計是 stateless、不全域保存 embedding，讓瀏覽器能跨來源共用一份最佳化模型。用途指向 note app 的語意搜尋、本地 RAG 問答與即時內容分類。
DoomBench——當 DOOM 的 game loop 變成 SQL，你的 data stack 撐得住嗎
DOOMQL 把一場多人 DOOM 整個塞進 SQL：按鍵 append 進 inputs 表、每秒 35 個 tick 更新世界狀態、渲染端用 recursive CTE 做 raycasting 畫成 ASCII。CedarDB 拿它當壓力測試比較各家資料庫，結果很殘酷——PostgreSQL 只有 0.3 FPS、DuckDB 接 ETL 能到 10 FPS 但畫的是每秒才更新一次的舊資料，而 HTAP 設計的 CedarDB 跑到 30 ticks/s 下的約 30 FPS、中位延遲 44ms。它要講的其實是：交易吞吐與分析吞吐不必二選一。
T-SQL 的 regex 終於吃 LOB 型別——SQL Server 2025 與 Azure SQL
Azure SQL 與 SQL Server 2025 終於讓 T-SQL 的 regex 函式吃 LOB 型別——varchar(max) 與 nvarchar(max)，最大到 2MB 的輸入。在這之前處理大欄位文字得繞 CLR 或搬到應用層；現在 regex 比對、擷取與替換可以直接在資料庫裡對大文本跑。對做日誌、文件、半結構化欄位清洗的人，這是少寫一層膠水的實質改變。
today's deep reads
從 model scaling 到 system scaling——agentic AI 的瓶頸搬到 harness
如果模型不再是限制因素，瓶頸會跑到哪？這篇把焦點移到模型外那層 harness——memory、retrieval、tool use、orchestration、verification、governance——並追問三個真正會卡住長任務的點：context governance、trustworthy memory 與 dynamic skill routing。我們該怎麼量一個 agent 的好壞，如果「最終成功率」根本看不到 trajectory 與記憶衛生的代價？CheetahClaws 拿來跟 Claude Code、OpenClaw 對照又看出了什麼？
Itanium C++ ABI 的 vtable——virtual dispatch 真正的代價
為什麼 vptr 指向的是 vtable 中間而不是開頭？offset-to-top 與 typeinfo 為什麼擺在負偏移？單一繼承怎麼原位覆寫、多重繼承為什麼要靠 thunk 把 this 加減一段、virtual 繼承又得多出 vcall／vbase offset 與一整套 VTT 建構表？一路追到 movq／jmp 的兩條指令解派，與 D0／D1／D2 三種解構子各自負責什麼。
DoomBench——把 DOOM 塞進 SQL，逼出資料庫的真實取捨
一場 DOOM 怎麼用 inputs 表、每秒 35 tick 與 recursive CTE 的 raycasting 整個跑在 SQL 裡？為什麼 PostgreSQL 只有 0.3 FPS、DuckDB 接 ETL 雖到 10 FPS 卻畫著舊資料，而 CedarDB 能在 30 ticks/s 下維持約 30 FPS、44ms 中位延遲？這場遊戲其實在問一件正經事：交易吞吐與分析吞吐，為什麼長年被迫二選一，HTAP 又怎麼把它們縫回一起？