Spotify Honk 系列（第四部）：背景編碼代理如何自動化處理 1,800 條資料管道的遷移工作
Spotify Engineering · 2026-04-22
Spotify 工程部落格的 Honk 系列第四篇記錄了他們如何使用以 Claude 為基礎的背景編碼代理 Honk，在 Backstage 和 Fleet Management 的支援下，自動處理約 1,800 個下游資料管道的遷移工作，最終部署 240 個自動化 Pull Request，估計節省約 10 個工程師週的手動工作量。
系統架構
Honk 的運作依賴三個系統的整合：
- Backstage：Spotify 的開發者入口平台，透過 Codesearch 插件提供資料血緣（data lineage）視覺化和跨儲存庫的程式碼搜尋能力，讓 Honk 能夠識別所有需要遷移的下游依賴管道
- Fleet Management / Fleetshift：大規模跨儲存庫作業的協調平台，負責追蹤 Honk 在各個儲存庫的遷移進度、管理 PR 建立和狀態監控
- Honk Agent（Claude 基礎）：執行具體程式碼轉換的 AI 代理，根據準備好的 context 檔案進行程式碼修改
Context 工程
此次資料集遷移案例的關鍵挑戰在於 context 準備：當時的 Honk 版本沒有 MCP 工具或自主的 context 蒐集能力，因此工程師必須手動為每種框架類型準備詳細的 context 檔案，包含明確的欄位映射表格。對於需要人工判斷的欄位，指令是「保持欄位不變，但在其上方添加含遷移指引連結的注釋」，而非讓 Honk 猜測。
三種框架類型的差異結果
遷移涉及三種不同的資料框架：BigQuery Runner 和 dbt 因其高度標準化的結構，非常適合代理自動化處理；Scio（Spotify 的 Scala-based 資料管道框架）因各團隊的使用方式差異過大，使代理難以處理大量邊界情況，自動化成效有限。240 個成功部署的 PR 主要來自前兩種框架。
測試基礎設施的缺口
此次實作揭露了一個重要的規模化瓶頸：大多數 BigQuery Runner 和 dbt 儲存庫缺乏建置時的單元測試，導致 Honk 無法在建立 PR 後自動驗證修改的正確性，需要依賴下游團隊在合併前進行手動驗證。規模化 AI 代理遷移的前提條件是標準化的程式碼結構以及跨儲存庫的自動化測試覆蓋。
未來方向
Honk 的下一步是加入自主 context 蒐集能力——讓代理能夠獨立讀取文件和問題追蹤系統，在執行程式碼修改前自行建立完整的理解上下文，而非依賴工程師預先準備的 context 檔案。
重新定義雲端計算：exe.dev 以 CPU 池取代虛擬機，針對 AI 代理工作負載設計新雲端架構
crawshaw.io · 2026-04-23
David Crawshaw（前 Tailscale 工程師）在 這篇長文中，以建造者的視角剖析了現有雲端計算平台的三個根本性架構缺陷，並說明他正在建造 exe.dev——一個以 AI 代理工作負載需求為出發點、從根本上重新設計計算資源抽象的雲端平台。
三個根本性架構缺陷
第一：虛擬機抽象。現有雲端廠商以「虛擬機實例」為基本單位販售計算資源，使用者先選擇特定規格（2 vCPU + 4GB RAM）再啟動 VM，並以「實例小時」計費。Crawshaw 認為這種抽象源於機房管理的便利性而非使用者需求，導致資源碎片化（小型工作負載無法有效利用大型實例的資源）和嵌套虛擬化開銷（在 VM 中跑 Kubernetes 需要額外的嵌套虛擬化層）。exe.dev 改為將機器的 CPU/記憶體作為共享池，使用者分配計算資源並按需運行任意數量的 Linux VM，VM 被當作 cgroup 中的一個進程而非離散的資源單位。
第二：儲存架構。主要雲端廠商的儲存設計以網路附加區塊裝置（EBS、Persistent Disk）為核心，這一設計源於 HDD 時代——當磁碟尋軌時間為 10ms 時，1ms 的網路延遲是可以接受的附加代價。但現代 NVMe SSD 的延遲為 20 微秒（0.02ms），網路存取的相對開銷超過 10 倍。exe.dev 以本地 NVMe 作為主要儲存，並以非同步區塊複製（asynchronous block replication）提供冗餘和持久性，而非以遠端區塊裝置作為主要 I/O 路徑。
第三：網路定價。雲端廠商的出口流量費用（egress pricing）約為實際資料中心互聯成本的 10 倍，Crawshaw 認為這是刻意設計的廠商鎖定機制，使遷移成本在財務上難以承受。
exe.dev 的技術設計
除計算和儲存重新設計外，exe.dev 的網路層採用 Anycast 全球接入點提供低延遲入口，並透過內建的 TLS 和認證代理防止工作負載直接暴露於公共網際網路。
AI 代理的驅動力
Crawshaw 認為 AI 代理的興起是此時建造新型雲端平台的關鍵時機：代理工作負載的特性（突發性高、生命週期短、需要大量並發小型計算單元）與現有以 VM 為中心的雲端計算模型存在根本性的不匹配，為重新設計計算資源抽象提供了市場動機。
原始來源：crawshaw.io