Cloudflare 公開 Meerkat：用 QuePaxa 演算法打造的全球共識實驗
Cloudflare Research · 2026-07-08
原本的問題
Cloudflare 在全球超過 330 個資料中心維運控制平面，需要一套能在廣域網路（WAN）環境下同時維持強一致性與容錯能力的共識機制。傳統作法如 Raft 仰賴單一 leader 與逾時（timeout）機制來偵測故障，一旦 leader 失效或所在網路路徑劣化，整個叢集就會陷入不可用狀態，等待選舉逾時、重新選出新 leader。這種「保守逾時」的設計在區域網路內問題不大，但放到跨洲際的高延遲、不穩定連線上，代價會被放大。Cloudflare Research 團隊因此想找一套不靠逾時、也不強制單一 leader 的共識演算法。
採用的方法
Meerkat 是 Cloudflare Research 打造的實驗性全球共識服務，核心採用 2023 年由 EPFL 等機構研究者於 SOSP（ACM Symposium on Operating Systems Principles）發表的 QuePaxa 演算法。QuePaxa 論文作者包含 Pasindu Tennage、Bryan Ford 等人，其設計精神是不再依賴保守逾時偵測故障，改用「短暫的 hedging delay」取代長逾時，並允許多個 proposer 同時提案而不會互相破壞（no destructive interference）。論文形容這是把「leader 選擇」與「hedging 延遲」當成一個 multi-armed-bandit 最佳化問題來動態調整。在正常情況下，QuePaxa 提供與 Multi-Paxos、Raft 相當的單一 round trip 快速路徑；一旦網路出現異常（例如 DoS 攻擊），則退回一個隨機化的非同步共識核心來維持活性（liveness）。
Meerkat 的架構讓叢集內任何一個副本都能直接處理客戶端的寫入請求，而不必先繞經固定的 leader。共識的最終結果體現在一份由多個「slot」組成的分散式日誌上，每個 slot 的值必須經過多數決（在 2f+1 台機器中容忍 f 台故障）才能確立，藉此提供跨全球副本的線性一致性（linearizability），讓上層的 key-value 儲存、租約（lease）系統等應用可以直接建構在其上。
實際效果
Cloudflare 目前將 Meerkat 定位為概念驗證（proof-of-concept），尚未投入生產環境，測試規模為 50 個分佈全球的副本節點。文章指出在正常路徑下，leader 發起的提案只需要 1 個 round trip，非 leader 發起的提案則需要 3 個以上的 round trip；相較之下，在網路條件不佳時 QuePaxa 相對 Raft 能維持約 10 倍的吞吐量。QuePaxa 原始論文則報告在區網環境下可達每秒 60 萬指令、廣域網路環境下每秒 25 萬指令的吞吐量，且在遭受 DoS 攻擊時 WAN 中位延遲仍能維持在 380 毫秒以下。Cloudflare 也在文章中對照了 一致性模型（consistency models）的概念，說明為何選擇線性一致性作為 Meerkat 的目標保證等級。
原始來源：Cloudflare Blog：Introducing Meerkat、QuePaxa 論文（SOSP 2023）
Microsoft Agent Framework 的編排模式正式進入 1.0 穩定版
Microsoft DevBlogs (Agent Framework) · 2026-07-08
背景
Microsoft Agent Framework 用來描述多個 agent 之間如何協作的一組「編排模式（orchestration patterns）」，先前一直帶著 [Experimental] 標籤存在於 .NET 與 Python 兩個 SDK 中。隨著 dotnet-1.9.0（2026 年 6 月 3 日發布）將 .NET 版的 Orchestrations 移除實驗標籤，加上 Python 端的 agent-framework-orchestrations 套件同步升級至 1.0.0，兩個語言生態系的編排能力終於達到功能對等（parity），正式宣告進入穩定版本。
核心改動
這次穩定版涵蓋五種協作模式，開發者可依照任務型態挑選：
- Sequential：多個 agent 依序串接處理，前一個的輸出是下一個的輸入。
- Concurrent：多個 agent 平行處理同一輸入，再彙整（fan-out/fan-in）結果。
- Group Chat：由一個協調者管理多個 agent，進行類似會議式的討論協作。
- Handoff：依角色將任務轉交給不同專責 agent，適合客服類的分流場景。
- Magentic：由 manager agent 自行規劃任務並動態指派給團隊成員，不需要手動搭建執行圖（graph）。
其中 Magentic 被官方形容為「手動接線最少的模式」——開發者只需要提供目標（goal）、一個 manager agent 與一組專家 agent，manager 就會自行決定團隊如何分工，不必像其他模式一樣手動定義每個節點與邊。同時 dotnet-1.10.0（2026 年 6 月 10 日）也同步更新了 GroupChatManager 的語意，讓它與其他編排模式的行為保持一致。
影響範圍
官方文件釋出了 Python 版的完整範例，其中一個示範用 MagenticBuilder 組成一個由 researcher、coder 與 manager 三種 agent 組成的工作流程，處理一項能源效率分析任務，全程不需要手動連接執行節點：
workflow = (
MagenticBuilder()
.participants(researcher=researcher_agent, coder=coder_agent)
.manager(manager_agent)
.build()
)由於編排模式已脫離 [Experimental] 狀態，代表 API 簽章（signature）與行為語意進入穩定承諾階段，適合直接用在生產環境的多 agent 系統中，而不必擔心下個版本出現破壞性變更。Workflow Outputs 也在同批次改動中支援標記（tagging）與過濾 agent 輸出，方便在多步驟編排中追蹤各階段的產出。
原始來源：Microsoft DevBlogs：Agent Framework's Orchestration Patterns Reach 1.0、GitHub：orchestrations 範例程式碼
Windows 控制流程防護的合體招式：把「驗證」與「呼叫」揉進同一段組合語言
Raymond Chen · The Old New Thing · 2026-07-08
原本的問題
Windows 的控制流程防護（Control Flow Guard，CFG）要求程式在透過函式指標呼叫函式之前，先呼叫驗證函式（如 LdrpValidateUserCallTarget）確認該位址是一個合法的呼叫目標，通過後才能真的跳過去執行。Raymond Chen 指出，實務上幾乎每一次驗證呼叫，緊接著下一步動作就是真的呼叫那個函式指標——兩段組合語言幾乎永遠成雙出現。既然模式如此固定，與其讓編譯器產生「驗證＋呼叫」兩段獨立指令，不如提供一個合體版本的函式，把驗證和呼叫合併成一次呼叫。
採用的方法
問題出在暫存器配置（register allocation）上。原本單純驗證用的函式，在 x86-64 上是用 rcx 傳入要驗證的位址，用 rax、rdx 當作暫存的 scratch 暫存器；但呼叫慣例（calling convention）規定，真正呼叫目標函式時，rcx、rdx 這些暫存器裡必須放的是「要傳給目標函式的參數」，不能被驗證過程中的中間值污染。因此合體版的驗證＋呼叫函式改用 rax 傳入要驗證的位址，把 r10、r11 當作 scratch 暫存器，讓 rcx、rdx 等參數暫存器全程保持乾淨，一路帶著參數活過驗證階段，直到最後用 jmp rax 直接跳進目標函式；驗證失敗時則把 r10d 清零後跳到錯誤處理路徑。
在 AArch64 架構上邏輯完全相同，只是暫存器代號不同：單純驗證版本用 x15 傳入待驗證位址，合體版則改用 x9，兩者都借用 xip0、xip1 作為 scratch 暫存器；驗證成功後，合體版用 br x9 直接跳轉到目標函式，而不是像單純驗證版那樣用 ret 返回呼叫端讓呼叫端自己再去跳。整篇文章的重點在於：兩個版本的組合語言邏輯完全一樣，差別純粹是暫存器分工方式，用來避開與呼叫慣例的參數暫存器衝突。
實際效果
透過把「驗證」與「呼叫」合併成一個函式，編譯器產生的程式碼可以省去一趟額外的間接跳轉與相關的暫存器搬移動作，讓 CFG 檢查的額外負擔更接近於零成本。這也是 Raymond Chen 系列文章一貫的寫作模式：先拆解單一機制的組合語言實作，再說明系統設計者如何針對「幾乎必然連續出現的兩個步驟」做合體優化，而不需要更動上層呼叫者感知到的行為語意。
原始來源：The Old New Thing：The other kind of control flow guard check