Cloudflare Workflows 新增 Saga 回滾機制，讓分散式工作流程失敗時能自動補償
Cloudflare Blog · 2026-06-25
Cloudflare 於 2026 年 6 月 25 日宣布，其 Workflows 產品正式支援 Saga 風格回滾（saga-style rollback）。開發人員現在可以為每個工作流程步驟指定補償函式，當後續步驟失敗時，系統會自動以反向順序執行這些補償動作，有效回復已完成的操作。
原本的問題
在分散式系統中，一個工作流程往往包含多個跨越不同服務的步驟。以銀行轉帳為例：Step 1 從帳戶 A 扣款成功，Step 2 向帳戶 B 入帳卻失敗。傳統的資料庫交易無法跨越微服務邊界做 ACID 回滾，開發人員必須手動撰寫補救邏輯，容易出錯且難以維護。
Saga 模式（Saga Pattern）是解決這類問題的既有方案：每個步驟搭配一個「補償動作」，失敗時透過這個新操作語意上撤銷前一步的效果，而非直接反轉資料庫狀態。過去在 Cloudflare Workflows 上，開發人員若要實現這個模式，需要自行追蹤哪些步驟已完成、並手動在 catch 區塊中處理回滾順序，十分繁瑣。
採用的方法
Cloudflare 工程團隊在 step.do() 的選項物件中新增了 rollback 參數。開發人員只需在宣告步驟時一併提供補償函式，框架本身就會在工作流程發生終端失敗時，以步驟「啟動順序」的逆序執行這些補償動作。
await step.do("debit-bank-a",
() => bankA.debit(from, amount),
{
rollback: async ({ output }) =>
bankA.credit(from, amount, output.id)
}
);API 設計上，團隊考慮過 fluent 鏈式呼叫與 builder 模式，但最終選擇了選項物件形式。原因在於 Promise pipelining 語意會被 fluent API 破壞，而且步驟時序在並行工作流程中會更難推理。選項物件讓「回滾」成為附加在已知工作單元上的元資料，與 Workflows 現有抽象層一致。
回滾處理器透過 Workers RPC stubs 保存可呼叫的參考，並在 Workflow 重啟後透過 replay 模式恢復。補償函式接收原始錯誤、步驟上下文及步驟輸出作為參數，並支援透過 rollbackConfig 設定重試次數與逾時行為。
實際效果
補償動作的執行順序採用反向步驟啟動順序（而非完成順序），確保並行工作流程的行為可預測。已失敗的步驟只要有登記補償函式，同樣符合回滾資格。回滾只在整個工作流程發生終端失敗時才會觸發，避免在暫時性錯誤時觸發不必要的補償。
工程師特別強調補償函式的冪等性（idempotency）要求——補償動作應像一般 Workflow 步驟一樣設計為可安全重試，例如善用付款服務商的冪等鍵機制。目前已支援 step.do() 的逐步回滾處理器與循序執行；後續計畫包含 waitForEvent 回滾支援、並行回滾執行，以及 Python Workflows 整合。
原始來源：Cloudflare Blog — How we built saga rollbacks for Cloudflare Workflows
IBM 發表全球首款次 1 奈米晶片技術，以垂直堆疊奈米片延續摩爾定律
IBM Newsroom · 2026-06-25
IBM 於 2026 年 6 月 25 日在紐約奧爾巴尼的半導體研究設施正式發表全球首款 0.7 奈米（7 埃）節點晶片技術。這項突破採用三維堆疊奈米片架構（Nanostack），讓單一指甲大小的晶片容納近 1000 億個電晶體，密度約為 IBM 2021 年 2nm 晶片的兩倍。
原本的問題
半導體業界長期面臨的難題是：平面縮放（2D scaling）已接近物理極限。傳統電晶體的閘極長度縮短到一定程度後，量子穿隧效應導致漏電流劇增，功耗和發熱問題使進一步縮小尺寸的邊際效益持續遞減。業界普遍認為，以傳統路徑維持摩爾定律已愈來愈困難。
IBM 的 2nm 製程已使用閘極全包覆（Gate-All-Around, GAA）奈米片結構，但若繼續壓縮至 1nm 以下的節點，單層平面結構的晶片面積縮減空間極為有限。如何在不增加晶片佔位的情況下大幅提升電晶體數量，成為核心工程挑戰。
採用的方法
IBM 研究人員提出 Nanostack 架構，核心思路是向垂直方向延伸：將互補場效電晶體（CFET, Complementary Field-Effect Transistor）跨兩層矽基板堆疊，上層電晶體相對下層錯位排列，以簡化導線佈局並提升原子尺度的對準精度。
每個電晶體通道包含三片奈米薄片（nanosheets），每片厚度僅 15 個原子，片與片之間距離 9nm。垂直堆疊設計還帶來額外優勢：不同層可採用不同材料組合，讓工程師得以針對每個電晶體獨立優化性能與功耗，而無需對整個晶圓使用同一種材料。
此項研究發表於 VLSI 2025 及 VLSI 2026 兩場頂級學術研討會，相關論文分別為 Reboh 等人的〈NanoStack Transistor Architecture for CMOS 7A Node and Beyond〉以及 Chen Zhang 等人的〈Area and Performance of Staggered-Channel Nanostack SRAM Bitcells〉。
實際效果
量化結果方面，Nanostack 技術對比 2nm 節點可提供高達 50% 的運算性能提升，或在相同工作負載下節省 70% 能耗。SRAM 方面則達到 40% 的面積縮減，對於資料中心 AI 工作負載所需的高頻寬記憶體存取尤為重要。
製造挑戰方面，多層製程需將所有步驟控制在 400°C 以下，以避免損壞下層結構，同時需在原子尺度維持對準精度，導致良率仍有待提升。IBM Research 總監 Jay Gambetta 表示：「這不僅是漸進式進步，而是實質性的躍進。」技術分析機構 TechInsights 的 Dan Hutcheson 則評估，此技術可為晶片路線圖再延續 10 至 15 年。
IBM 預計這項技術最快需要 5 年才能進入量產階段，目前屬研究示範性質。由於 AI 訓練與推論對算力和能效的需求持續攀升，若 Nanostack 架構順利量產，將對未來一代 GPU、CPU 及資料中心加速器帶來根本性影響。
原始來源：IBM Newsroom — IBM Debuts World's First Sub-1 Nanometer Chip Technology；MIT Technology Review — IBM has unveiled chip technology that could help extend Moore's Law another decade
讓 AI 代理人互相辯論：LY Corporation 以多代理人審查重新設計開發流程
LY Corporation Tech Blog · 2026-06-25
LY Corporation 工程師 Mac Van Duy 與 Ngo Xuan Trinh 在 2026 年 6 月 25 日發表於 Tech-Verse 2026 的文章中，描述一套以多代理人辯論機制取代傳統人工審查的開發流水線。這套系統將每個開發階段拆分為「提案方（Proposer）」與「挑戰方（Challenger）」兩個 AI 代理人角色，強制讓 AI 在提交給人類之前先自我驗證工作成果。
原本的問題
隨著 AI 程式碼生成能力日趨成熟，真正的瓶頸已從「取得程式碼」轉移到「協調意圖、規格、實作、驗證與審查」之間的人工交接。開發人員花費大量時間在來回確認需求、審查 AI 產出是否真的滿足需求，以及處理「A 修了再改成 B、B 又打回 A」的迴圈問題。
單一代理人的另一個弱點是共同盲點（shared blind spots）：同一個模型在生成程式碼和審查自己的程式碼時，往往會忽略相同的問題。純粹依賴單一 AI 的輸出，難以在進入人工審查前過濾掉系統性缺陷。
採用的方法
LY Corporation 的解法是三階段流水線，每個階段都配對一組扮演對立角色的代理人：
- Spec 階段：提案方彙整需求，挑戰方僅能以蘇格拉底式提問（Socratic questioning）點出歧義，不能直接否決。
- Build 階段：提案方設計測試並實作，挑戰方必須以有具體證據支撐的反對意見（evidence-backed objections）驗證測試覆蓋率。
- Delivery 階段：提案方準備 PR 套件，挑戰方核實交付準備度，最終由協調者（Orchestrator）扮演評審角色做出裁決。
Orchestrator 是整個系統的中介裁決者，根據累積的證據決定是要求修改、升級問題，或推進到下一階段，避免憑直覺做決策。代理人之間的溝通採用嚴格的 JSON 協議，挑戰方的每一條反對意見都必須包含嚴重程度評級、證據類別與信心分數，要求「提供關於測試、程式碼或執行的具體證明」，而非模糊斷言。
系統還內建振盪偵測（Oscillation Detection）：當目前的失敗與兩步之前的失敗相符時，判定為修復迴圈，自動升級要求重新設計，而非重複無效迭代。過去學習到的教訓會壓縮成具備 schema 約束的顧問信號（structured priors），讓系統在保留模式識別能力的同時，避免引入未經查核的偏差。
實際效果
系統目前部署於日常 CI 驅動的工作流程，適用於有明確驗收標準的中小型任務，例如 Issue 轉 PR 自動化、可重現失敗的 Bug 修復，以及安全性與效能敏感的變更。對於探索性需求或「正確」無法透過具體證據驗證的任務，工程師建議繼續採用傳統人工主導流程。
成本方面，多代理人模式消耗的 token 數量多於單一代理人，每個任務耗時達到分鐘級別。系統透過複雜度路由（Complexity Routing）緩解這個問題：依風險層級將任務分類，瑣碎變更走輕量化審查，安全敏感修改才觸發完整辯論輪次。整套方法的核心洞察是：AI 的槓桿點不在於更快生成程式碼，而在於強制 AI 在人類花費注意力之前先證明自己的工作，讓人工審查聚焦在真正需要人類判斷的決策上。