舊手機主機板重生：以手機叢集打造低碳雲端運算平台
Google Research Blog · 2026-06-12
加州大學聖地牙哥分校與 Google 合作的研究團隊，正將退役智慧型手機的主機板拆解重用，建立稱為「手機叢集運算」（phone cluster computing）的低碳資料中心架構。計畫中的 2,000 支手機叢集預計於 2026 年秋季正式上線，鎖定教育科技、程式評分等大學雲端工作負載。Jennifer Switzer 與 Google Fellow David Patterson 於 2026 年 6 月 12 日發表此研究成果。
原本的問題
現代智慧型手機壽命平均僅 2–4 年，大量廢棄裝置進入回收流程，但製造過程所排放的碳已無法回收。主機板佔整機碳足跡約 50%，若直接報廢，等同浪費已排放的製造碳排量。研究團隊觀察到，手機處理器在單執行緒效能上已可比肩資料中心伺服器，這讓重利用舊機成為可行選項。
採用的方法
團隊從退役手機中取出主機板，刷掉原廠 Android 系統並改裝標準 Linux，使其能以容器化方式執行雲端服務。25 至 50 支手機的運算力等同一台現代伺服器，並以 Kubernetes 統一調度整個叢集。整套系統刻意避免採購新硬體，直接繼承舊裝置已消耗的製造碳排放量，達到真正的再利用。
實際效果
初期以 20 支手機組成的測試叢集，在 75 個以上學生班級的程式評分峰值負載下，延遲低於預設的 AWS 後端。研究人員預期 2,000 支手機的正式環境可同時支援一百個班級規模的工作負載。這種「以廢料做基礎設施」的模式，若能推廣至企業退役設備，將為資料中心碳排放帶來結構性影響。
原始來源：Google Research Blog — A low-carbon computing platform from your retired phones
不擴充硬體、掃描速度提升十倍：Cloudflare 安全掃描系統的優化歷程
Cloudflare Blog · 2026-06-12
Cloudflare 工程師 Dave Baxter 在 2026 年 6 月 12 日發表的技術文章中，記錄了 Security Insights 掃描系統如何在不增加硬體的前提下，將吞吐量從每秒 10 次提升至超過 120 次，實現十倍成長。此次優化同時讓免費帳號也能享有自動掃描，並大幅提高各方案的掃描頻率。
原本的問題
原始系統每隔 1–2 週才執行一次安全掃描，弱點往往在下次掃描前已被利用。系統瓶頸散落在四個層面：Kafka 消費、資料庫寫入、跨區 API 延遲，以及排程器設計。各環節看似獨立，卻形成複合效應，共同壓低整體吞吐量。
採用的方法
針對 Kafka，團隊改用批次消費搭配 goroutine 平行處理，並引入「快車道／慢車道」消費者群組，避免複雜任務阻塞簡單任務。資料庫端以 UNNEST 與 COPY 混合策略取代逐筆插入，消除 50 萬次單筆往返的開銷。API 架構從 active-active 雙區部署改為 active-passive，將請求對齊主資料庫所在地，解決跨洲 50ms 延遲導致的連線池耗盡問題。排程器則引入自適應速率限制與隨機時間戳，讓各 zone 獨立排程，避免請求峰值集中爆發。
實際效果
優化後系統峰值吞吐量穩定維持在每秒 120 次以上，掃描頻率更新如下：
- 免費方案：每 7 天
- Pro / Business 方案：每 3 天
- Enterprise 方案：每日
所有免費帳號均已納入自動掃描覆蓋範圍，並開放細粒度的隨選掃描功能。此案例示範了透過深層程式碼與查詢分析「工程解題」，而非直接採購資源的系統優化思路。
AI 代理測試不是 E2E 的替代品：Slack 的四層測試金字塔實驗
Slack Engineering Blog · 2026-06-11
Slack Staff Software Engineer Sergii Gorbachov 於 2026 年 6 月 11 日發表實驗報告，探討 AI 代理（agent）在端對端（E2E）測試堆疊中的定位。團隊透過 200 次以上自動化執行，比較三種測試執行模式，提出「代理測試」應作為測試金字塔的第四層，而非取代傳統 E2E 測試。
原本的問題
傳統 E2E 測試強制執行固定操作路徑，難以應對動態 UI 變動與複雜場景的探索式驗證。工程師開始嘗試以 AI 代理執行瀏覽器測試，但缺乏實驗數據說明代理應在何時、以何種方式介入測試流程。Slack 團隊設計了兩種測試流程（Thread Reply：15–20 步驟；Search Discovery：25–30 步驟），分別以自然語言與結構化 YAML 作為輸入，對三種執行模型各跑 20 次進行比較。
採用的方法
三種執行模型分別為：Agent + Playwright MCP、Agent + Playwright CLI，以及 AI 生成的 Playwright 測試腳本。測試模型採用 Claude Sonnet 4.5 與 Claude Opus 4.6。MCP 模式保持持久 DOM 快照狀態，CLI 模式則每步驟重建快照，兩者在互動效率與穩定性上存在結構性差異。
實際效果
| 指標 | MCP | CLI | 生成測試腳本 |
|---|---|---|---|
| 簡單流程失敗率 | 0% | ~12% | ~8% |
| 複雜流程失敗率 | ~12% | ~20% | ~48% |
| 平均執行時間 | 5–8 分鐘 | 9–11 分鐘 | ~3 分鐘 |
實驗發現，僅約 20% 的執行次數走過完全相同的操作序列，但最終都達到相同目標，說明代理具備固定腳本無法企及的適應性。成本主要由對話歷史重傳驅動，而非模型推理本身，CLI 模式平均需要 85 次對話輪次，MCP 僅需 40–60 次。
原始來源：Slack Engineering — Agentic Testing: Where Agents Fit in the E2E Testing Stack