Blitzy 以 14 億美元估值募集 2 億美元,他們稱之為超大規模代理編排 — 建構企業 codebase 的動態知識圖譜,然後針對該表示並行部署成千上萬的代理。關鍵數字:SWE-Bench Pro 66.5%(更難的變體,與大多數 lab 基準測試的 SWE-Bench Verified 子集不同),支援從 1 百萬到 1 億行程式碼的 codebase,每次 run 在 Google、Anthropic 和 OpenAI APIs 上有 10 萬+ 次底層模型呼叫。平台聲稱在十個行業有數十家 Global 2000 企業客戶,儘管具體名字未揭露。架構上,這是與當前主導 builder 心智份額的單代理-CLI 類別的重大分歧 — Cursor、Claude Code、Aider 都跑單個代理做順序推理。Blitzy 做的是帶 KG grounding 的艦隊規模編排。
要標註的技術架構:把現有 codebase 反向工程成結構化知識圖譜是艦隊規模代理工作的前提條件。沒有那個表示,並行代理就會互相踩腳(同一檔案被編輯兩次)並在 codebase 上下文之間丟失上下文。KG 讓編排器分區工作 — 代理 A 處理 auth 相關變更,代理 B 處理 billing,等等 — 而不需要每個代理都把完整 codebase 放在它的上下文中。每次 run 10 萬次模型呼叫是成本驅動和差異化:大多數生產編碼代理每個任務做 50-200 次呼叫。10 萬次呼叫意味著大規模並行探索、候選生成、投票和驗證,而不是順序的 chain-of-thought。這種方法的 SWE-Bench Pro 66.5% 與 Sonnet 4.5 + Claude Code 在 SWE-Bench Verified 上達到的 82%(帶並行測試時計算)是有競爭力的,但 Pro 更難所以直接比較不乾淨。未揭露的:任務分解實際上如何工作(基於規則、學習、混合?)、每完成的延遲是什麼(並行 run 應該在 wall-clock 上快,但 10 萬次 API 呼叫意味著真正的成本)、KG 過時或錯誤時的失敗模式,以及編排器如何處理代理分歧。
生態讀法:企業編碼代理正在分叉為兩種架構。單代理-IDE 類別(Cursor、Claude Code、Windsurf)針對開發者坐著的緊密迴圈進行最佳化 — 快速迭代、頻繁糾正、每任務低成本。Blitzy 和 Devin/Cognition 類針對「給我們一個規格,明天回來」進行最佳化 — 每任務高成本、迴圈中沒有開發者,但適用於大規模重構和功能建構,這是單代理設定無法在一次會話中現實地處理的。Blitzy 瞄準的 1M-1 億 LOC 範圍是企業最佳點 — codebase 太大以至於單個 Cursor 會話無法在上下文中保持,KG-grounded 方法在那裡有清晰的架構理由。10 萬 API 呼叫經濟意味著每次 run 的單位成本在數百到數千美元,這只對實質性交付物有意義,而不是互動式編輯。對評估代理平台的 builder,問題變成你的工作是「開發者需要協助」(單代理)還是「規格需要實施」(艦隊) — 它們不是替代品,是不同的類別。
實際動作:如果你運行 Global-2000 級別的工程組織,程式碼庫超過 1M LOC 且有重複的大規模重構工作,Blitzy 現在在評估池中。要求關於 KG 準確性 claim 的具體證據 — 錯誤描述 codebase 的知識圖會以事後除錯昂貴的方式靜默破壞並行代理決策。在典型企業 codebase 規模的每完成成本、生產部署的錯誤率(不是基準分數)和編排確定性問題(同一輸入的兩次 run 是產生相同 patch 還是不同的?)上釘住他們。對運行較小 codebase 的 builder,Cursor/Claude Code 單代理設定仍然是正確的工具 — Blitzy 的架構只有在並行優勢超過編排開銷時才能自付,這只在過了某個 codebase 規模才會啟動。SWE-Bench Pro 66.5% 很有意思,但在獨立 harness 報告之前不是可移植的訊號;這是一家公司的數字,eval-honesty 紀律說要看複製。