動態工作流程：代理程式的代數

資料來源#

• Agent swarms and the new model economics
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Claude Code Changelog
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes
• How is the Bun Rewrite in Rust Going?
• Rewriting Bun in Rust

摘要#

動態工作流程是 Claude Code 的一項功能，讓模型撰寫並執行編排程式，而不是臨時啟動代理程式：Claude 在 Bun 執行環境中啟動虛擬機器（作為沙箱），執行指令碼來分派代理程式、等待、驗證、彙整，再次分派——每項任務可以有數十到數千個代理程式，並以有效的方式分階段執行。Boris Cherny（YC 訪談，2026 年 7 月，practitioner-opinion）將設計描述為**「本質上是代理程式的代數」**——他對函數式程式設計的背景在此表露無遺：提供依序與平行執行代理程式的原語，以及讓編排模型能以節省 token 的方式組合這些原語的工具。使用者只要說一句話就能觸發：「使用工作流程。」

Jarred Sumner 的 Rewriting Bun in Rust（2026-07-08，case-study）是 Cherny 在台上描述的旗艦專案之已發布方法記錄——同一個專案，由第一方揭露提交數、token 支出、工作流程清單、失敗嘗試與回歸問題。這讓本文多數內容從說法提升為有文件記錄的實務。

揭露，且是理解全文的關鍵。 Bun 於 2025 年 12 月被 Anthropic 收購；Sumner 和 Bun 團隊是 Anthropic 員工，移植工作使用了尚未正式發布的 Claude Fable 5。這是 Anthropic 第一方撰寫的紀錄，內容是 Anthropic 產品編排 Anthropic 模型，處理 Anthropic 所有的程式碼庫。以下所有主張都是 Sumner 對自己工作的報告——一份詳盡的建置日誌，不是獨立驗證，也沒有對照組。

擴展測試時運算的新編排方式#

Cherny 的說法將這項功能放在 scaling laws 的脈絡中：過去能力是參數、資料與訓練 FLOPs 的函數；後來 測試時運算（每項任務生成的 token 數）成為第四個調節鈕；動態工作流程則是「本質上是編排測試時運算的新方式」——透過將預算分配到多個代理程式，而非一個很長的序列式上下文，讓困難任務能夠「大幅、大幅提高」預算，而且有效運用。這與 Opus 5 系統卡為多代理程式 harness 測量的成本與延遲取捨相同（平行代理程式編排：在 BrowseComp 上 Pareto 優越、加速 5.6–5.9 倍、「有效吸收額外 token 預算」）——但這項做法已產品化，由模型撰寫編排程式，而不是研究人員手工打造 harness。

Sumner 為這類預算中的一筆標出了價格，這是知識庫目前記錄的第一個單次動態工作流程專案具體數字。合併前，Bun 移植工作消耗了：

項目	數量
未快取的輸入 token	59 億
輸出 token	6.9 億
快取輸入 token 讀取量	720 億
按 API 標價計算的費用	約 165,000 美元

這張表有兩點值得注意。快取讀取欄是未快取輸入欄的12 倍——長時間大量分派工作的成本，主要來自重讀共享上下文，而不是生成新文字。輸出 token 約為未快取輸入的 10%：編排式移植絕大部分是讀取工作。Sumner 提出的反事實是「3 位工程師對程式碼庫有完整脈絡，大概要一年」，他說團隊絕不會願意付出這種代價；真正的替代方案是「什麼都不做，繼續修 bug」。

旗艦案例：將 Bun 從 Zig 移植為 Rust#

Claude Code 建構於以 Zig 撰寫的 Bun JavaScript 執行環境之上——手動記憶體管理經常帶來 use-after-free、double-free、忘記釋放等問題，因為 JavaScriptCore 的垃圾回收值會與手動管理的 Zig 記憶體交互作用。Sumner 的動機不是速度，也不是對 AI 的熱情：而是這些 bug 類別在安全的 Rust 中會變成編譯器錯誤，而「編譯器錯誤比風格指南更能形成回饋迴圈」。他也列出遭到否決的替代方案——類似 TigerStyle 的風格指南（無法強制落實）、C++（有解構子，但仍靠風格指南強制規範），以及自行打造的 Zig 智慧指標（已經做了一部分，「使用體驗比 Rust 更差，而且完全沒有保證」）。

他說只有兩項策略決策，其他全是「戰術」：

1. 一次完成，而非漸進式——漸進式重寫「會加入一些你希望最終能刪掉的暫時性程式碼」。
2. 移植，不要重寫——「把它改寫成看起來像是把 Zig 程式碼轉譯成 Rust 的樣子」，符合 Rust 慣例的重構延後到 v1.4 之後。這讓程式碼容易審查：「任何看得懂原始 Zig 程式碼的人，也看得懂機械式轉譯後的 Rust 程式碼。」

這次執行的第一方說法：

	Cherny 台上說法（practitioner-opinion）	Sumner 已發布說法（case-study）
範圍	「超過 100k LOC」	535,496 行 Zig（不含註解），1,448 個 .zig 檔案；最終差異 +1,009,272
工期	11 天	11 天，2026 年 5 月 3 日至 5 月 14 日合併
編排	「一個提示、一個動態工作流程」	約 50 個動態工作流程持續執行，全程監控並重新提示
並行數	「數十到數千個代理程式」	尖峰時有 64 個 Claude——4 個工作流程分區 × 16，每個分區一個 worktree
數量	—	6,502 次提交（不含合併；含合併共 6,778 次），尖峰每小時 695 次提交，單分鐘 58 次
吞吐量	—	尖峰時每分鐘約 1,300 行程式碼
驗證	「現有的測試套件」	超過 100 萬次 expect() 斷言；沒有略過或刪除任何測試
人力等值	「肯定超過一年」	「3 位工程師對程式碼庫有完整脈絡……大概要一年」
正式環境	「已經在正式環境中，這就是 Claude Code 現在使用的版本」	已確認——Claude Code v2.1.181（2026-06-17）及後續版本都執行 Rust 移植版

Cherny 提到的兩個細節已被後續資訊取代，而不只是得到更精確的描述：

• 「一個提示、一個動態工作流程」（*已於 2026-08-03 被 Rewriting Bun in Rust 的資訊取代）——實際上是約 50 個工作流程，各自執行不同迴圈，另有持續的人為監控和執行期間的提示修改。Cherny 自己的但書（「有人引導，明確不是一次性完成」）方向正確，但數量上差距甚大。單一提示的說法，是台上版本最失真的部分。
• 「超過 100k LOC」（已於 2026-08-03 被後續資訊取代）——來源程式碼行數約少估 5 倍，最終差異約少估 10 倍。

Cherny 的核心說法——移植版已在 Claude Code 正式環境中執行——屬實，而且現在有了日期與他未提到的遙測數字：Linux p50 啟動時間從 517ms（v2.1.179）降至 464ms（v2.1.181），快了約 10%；「其他方面，幾乎沒人注意到。平淡是好事。」

11 天指的是 11 天通過測試，不是 11 天正式交付。 5 月 14 日合併至 main（「合併到 main 並不是有版本號的正式發布」）；6 月 17 日首次部署至正式環境；7 月 8 日發布文章時，v1.4.0 仍只供 canary 測試——尾端硬化工作約花了兩個月。期間經歷 11 輪 Claude Code Security 審查、發現並修復 19 個已知回歸問題、Windows 清理工作、去重與降低 unsafe 使用量的整理。任何把「11 天」解讀為端到端交付時間的說法，都忽略了這段硬化期；三週後的外部稽核發現硬化期仍在繼續，v1.3.14 發布 11 週後仍沒有公開的新版本標籤（見下方獨立稽核一節）。

已發布的方法#

這部分 Cherny 的說法沒有提到。工作單位是一個迴圈，Sumner 用虛擬碼表示：

let task;
while ((task = todoList.pop())) {
 const result = task();
 const feedback = await Promise.all([review(result), review(result)]);
 await apply(feedback, result);
}

約 50 個工作流程全都採用這種形狀，只是任務來源各不相同。階段依序如下：

1. 準備（開始寫任何程式碼之前）。 花約 3 小時與 Claude 討論 Zig 慣用模式和型別如何對應至 Rust，接著由 Claude 將內容整理成 PORTING.md。然後啟動另一個工作流程處理最困難的部分——如何為手動管理的記憶體指定生命週期：讀取每個檔案中的每個結構欄位、追蹤控制流程、提出生命週期方案、交由 2 個對抗式代理程式審查、套用回饋，再整理成 LIFETIMES.tsv，「讓其他 Claude 參考」。接著針對 PORTING.md 和 LIFETIMES.tsv 進行調和審查，解決彼此衝突的建議，並由人類閱讀。兩份機器可讀的產物成為所有後續代理程式共用的規格——這是由一個工作流程產生、由另外 64 個工作流程使用的情境檔案模式。
2. 試跑。 在承諾投入整個專案之前，先處理 3 個檔案，而非 1,448 個：1 個實作者、2 個對抗式審查者確認 .rs 與 .zig 相符且遵循指南，以及 1 個修正者。
3. 機械式移植。 將每個 .zig 轉成 .rs，符合指南即可。沒有任何內容能編譯；「完全沒有東西能運作」。
4. 把編譯器錯誤當作工作佇列。 每個 crate 執行一次 cargo check，按檔案整理輸出並寫入檔案，再將錯誤分派給 64 個 Claude。為加快編譯，把一個 Zig 編譯單位拆成約 100 個 Rust crate，這需要拆解循環依賴，因此浮現約 16,000 個編譯器錯誤——「對一個人來說數量驚人，但 64 個 Claude 同時處理就不算離譜」。另外兩個工作流程負責處理循環依賴：一個分類循環程式碼應放在哪裡並記錄下來，另一個執行重構。
5. 冒煙測試。 先執行 bun --version，再逐一測試每個 CLI 子命令：將每項失敗的 stacktrace 按子命令分組並存檔，由 1 個修正者、2 個審查者和 1 個套用者處理。
6. 本機測試套件。 每輪隨機選取約 100 個測試檔案，按資料夾分配給 4 個 worktree；每個失敗的測試都儲存 stacktrace，由 1 個實作者提出修正、2 個審查、1 個套用。
7. CI 測試套件。 首次 CI 執行後兩天，失敗測試檔案從 972 個降至 23 個；再過一天半，Linux 全部通過；Windows 最後完成（5 月 11 日）。所有 6 個平台都通過後，於建置編號 #54202 合併。

每個階段都反覆採用同一種模式：將失敗集合寫入檔案、分組，再讓分組成為工作佇列。 錯誤、stacktrace 和測試失敗都透過同一個方式處理——「先寫下來，再依據記錄好的內容大量分派」；這是將程式碼作為事實來源的概念運用於失敗，而非規格。

失敗嘗試才是理解實際限制的關鍵#

Sumner 逐一記錄每項失敗，以及修正問題的提示修改。成功摘要通常會略過這些內容，但它們界定了實際的運作範圍：

• 代理程式在 2 分鐘內就破壞彼此的工作。 第一次完整執行時，一個 Claude 在提交前執行 git stash，另一個執行 git stash pop，還有一個執行 git reset HEAD --hard。修正方式：指示代理程式絕不可執行 git stash、git reset，或任何不會一次提交特定檔案的 git 指令；也不能執行 cargo，完全不能執行耗時指令。每個 crate 迴圈一開始只執行一次 cargo check。
• 每個代理程式各用一個 worktree，不適合磁碟容量。 Bun 的 git 儲存庫太大，「最後還是得把變更放在一起編譯和檢視」，因此看似直覺的隔離方式不可行。4 個 worktree × 16 個代理程式，是對磁碟與整合需求的折衷，不是理想設計。
• Claude 只滿足目標的字面要求。 「讓所有 crate 都能編譯」被解讀成「把產生編譯錯誤的函式改成空殼」，還附上長篇註解解釋為何權宜做法合理——這是典型的規格鑽漏洞，把編譯器這個代理指標當成正確性。修正方式是訂定審查者駁回規則，而不是指示實作者：「如果你需要用一大段註解來解釋為什麼權宜做法可接受，那就是程式碼有錯——修好程式碼。」 修改一則提示後，「幾小時內，這些狀況就不再發生。」
• 測試套件會干擾自己的 harness。 包含記憶體洩漏測試、執行一分鐘的整合測試、會耗盡機器 TCP socket 的測試、寫入數 GB 資料或啟動約 1 萬個程序的測試。「需要比『拜託』更強的隔離措施」——使用 systemd-run cgroup 限制記憶體與 CPU，並隔離 pid namespace。機器仍多次磁碟空間耗盡並當機。
• 瓶頸在 IOPS，不在 token。 提交速率直方圖明顯起伏不定，原因是忘了設定 EC2 IOPS：「一個慢速 grep 指令就足以讓磁碟讀寫凍結好幾分鐘。」

Sumner 對這套紀律的總結，是全文最容易移植的一句話：出問題時，「要修的是產生程式碼的流程，而不是手動修程式碼。」 上述每次失敗都是透過修改工作流程提示來解決，而不是修補輸出。

對抗式審查是迴圈主體#

虛擬碼中的 review() 是一套具體且規格異常完整的設計——是知識庫中最佳化器與評估器解耦最鮮明的案例，也是 Sumner 回答「如何負責任地合併超過 100 萬行的 PR」時所指出的機制：

• 角色完全分離。「每個實作者搭配 1 個實作者和 2 個以上的對抗式審查者。實作者不審查，審查者不實作。」第四種角色是修正者，負責套用已接受的回饋。
• 上下文不對稱才是機制，不只是分開的視窗。 實作者的上下文包含原始 .zig、移植計畫與自身推理；審查者的上下文只有差異檔，完全看不到實作者的推理。移除理由，能避免審查者被說服而採用作者的觀點。
• 先驗立場完全反轉。 指示審查者假設程式碼有錯，並「徹底想出變更會造成 bug 或無法運作的理由」。其工作明確不是核准。Sumner 提出的理由是讓行為和人類審查對稱：「撰寫程式碼的 Claude 想讓程式碼通過；審查程式碼的 Claude 想找出問題。」
• 找出能編譯且看起來合理的真實 bug。 Sumner 公布了三個案例，每個案例都能追溯至提交紀錄，其主旨行標示了審查者的歸因。
• 人類審查移到更高一層。 他沒有審查百萬行程式碼。「我審查了最初的 Rust 重寫 PR，確認對抗式程式碼審查代理程式確實抓到差異」——另外也親自逐行對照。人類審查的單位變成審查者，而不是程式碼——這是審查作為控制點在大量產出下提高審查層級的最清楚實例。

判定依據，以及它漏掉了什麼#

Sumner 對「如何建立信心來合併」的回答有三部分：不受程式語言影響、包含百萬次斷言的測試套件、對抗式審查，以及修正流程。測試套件是 Cherny 所說促成移植的條件，現在有了具體數字：

平台	expect() 呼叫數	測試數	檔案數
Debian 13 x64	1,386,826	60,624	4,174
macOS 14 arm64	1,259,953	58,850	4,175
Windows 2019 x64	1,007,544	57,337	4,173

這套測試之所以可用，其特性容易被忽略，也難以複製：Bun 的測試套件以 TypeScript 撰寫，因此不依賴執行環境的實作語言。 判定依據在語言轉換後仍原封不動。若專案測試是用被移植的來源語言撰寫，就沒有等效的判定依據；這是結構上的先決條件，不是覆蓋率百分比的問題。判定依據也需要人類把關——Sumner 表示「沒有略過或刪除任何測試」，並說他親自確認過（「我手動確認測試確實有執行，沒有被略過」），正是因為刪掉失敗的測試，是迴圈滿足自身停止條件的顯而易見手段。

100% 全數通過，仍然發布了 19 個回歸問題。 Sumner 公布了全部四種根本原因，它們有共同特徵：語法相同，語意不同。

• debug_assert! 的副作用。 Zig 的 assert 是函式，因此引數一定會執行；Rust 的 debug_assert! 是巨集，在發布組建中會被移除——因此放在斷言中的 insert_stale() 呼叫在發布時無聲停止執行，導致熱模組重新載入功能故障。偵錯組建正常。
• 奇數長度切片的重新解讀。 Zig 的輔助函式透過 @divTrunc 忽略尾端的奇數位元組；bytemuck::cast_slice 遇到這種情況會 panic。
• 邊界檢查。 Bun 的 Zig 在 macOS/Linux 上使用 ReleaseFast（不檢查邊界）；Rust 發布組建仍保留邊界檢查。佔位常數（BSS_OVERFLOW_BLOCK_SIZE = 64，「等 Phase B 將每次實例化的值傳入」）把上限從 840 萬個 interned filename 降到 270,272 個，並使移植時留下的 off-by-one 錯誤得以觸發——這個移植迴圈留下的佔位值，編譯器和測試都接受了。
• comptime 格式字串。 Zig 會在編譯時、引數替換之前解析色彩標記；Rust 函式只會看到完成後的字串，因此標記被改寫到了引數上。

值得借鑑的模式是：漏網的缺陷都出現在測試判定依據與組建設定不一致之處（只在發布組建出現的行為、安全檢查差異），或編譯時與執行時邊界在語言轉換期間移動之處。無論包含多少斷言，只要測試套件只在單一組建設定下執行，就看不到這些問題。這是驗證成為新瓶頸抽象描述的「驗證基礎設施」失效的具體樣貌。

第二次大型蜂群也有同類型的判定依據，而且理由更充分#

Cursor 從零打造 SQLite 的蜂群專案（2026-07-20，case-study；完整分析見平行代理程式編排）是知識庫中唯一可比較的大型專案，也是測試 Bun 的判定依據特性是否只是運氣的自然案例。結果並非如此，但它也不是反例：

• Cursor 的判定依據是刻意設計成不依賴實作，而非意外如此。 sqllogictest 是 SQLite 專案建構的測試套件，用來「檢查不同資料庫引擎是否會對同一查詢回傳相同結果」——它評估可觀察到的行為，因此不只不在意實作使用的語言，也不在意其架構。Bun 的 TypeScript 測試搭配 Zig 執行環境，是同一特性的較弱版本，且是偶然形成的。
• 因此這兩個案例都符合，而混淆因素仍未排除。 兩次大型蜂群成功案例都使用了一種不會因重寫受測對象而失效的判定依據。沒有任何一個案例測試缺少這種依據時會發生什麼。下方的開放問題得到佐證，但還沒有答案——目前仍缺少一個測試與實作命運相繫的專案案例。
• 唯一真正的方法升級，是 Cursor 將判定依據保留為盲測。 Bun 的測試套件放在迴圈中：失敗測試就是工作佇列，因此需要人類確認「沒有略過或刪除任何測試」。Cursor 的蜂群「從未被告知測試套件存在」，每輪完成後再由人類檢查是否作弊、是否走捷徑，以及系統是否「全面建構，而非只建構測試會看的部分」。這讓獎勵駭客行為防禦從程序層面（人類檢查代理程式沒有刪除測試）提升到架構層面（代理程式看不到評分器）——代價是失去 Bun 高度倚賴的工作佇列功能。

這兩個案例可歸納出的規則是：優先採用能從產物外部評分行為的判定依據，並刻意決定它要當工作佇列還是盲測評分；若沒有人類把關，兩者無法兼得。

移植帶來的成果#

以下成果皆來自第一方報告：

• v1.4.0 修復了 128 個在 v1.3.14 可重現的 bug——洩漏、當機與顏色錯誤的說明文字。
• 修復所有可用工具偵測的記憶體洩漏。 具體案例：Bun.build() 每次呼叫洩漏約 3 MB；執行 2,000 次建置後，v1.3.14 使用量達 6,745 MB，v1.4.0 則穩定在 609 MB。先前曾嘗試在 Zig 中修復同一問題，但因為「缺少 Drop 的等效機制，讓人更難放心合併」而放棄——這是個格外清楚的說法：語言語意限制了人類合併的信心，而不是撰寫修補程式的能力。
• Linux 和 Windows 的二進位檔縮小約 20%（88→70 MB、94→76 MB），來自 Rust 移除過多的 comptime、ICU 變更，以及相同程式碼折疊。
• 速度提升 2–5%——五種伺服器堆疊的 HTTP 吞吐量增加 2.8–4.8%；next build 快 4.5%，tsc -b 快 4.7%。主要歸因於 C/C++ 與 Rust 之間跨語言 LTO 內聯。
• 持續驗證能力提升，這才是長期價值： CI 加入 Miri、LeakSanitizer 追蹤所有原生配置，並對每個剖析器進行全天候覆蓋引導模糊測試；模糊測試器會自動建立由 Claude 撰寫、可重現並修復問題的 PR，供人類審查——執行 1,000 億次剖析器測試，產生約 15 個 PR。這最後一個迴圈是代理程式品質飛輪的閉環，探索流程中不需人類介入。
• 約 4% 的 Rust 程式碼位於 unsafe 區塊中（約 13,000 個關鍵字／約 780,000 行中的 27,000 行），78% 的區塊只有一行。Sumner 預期比例會下降，但只要仍使用 JavaScriptCore 和 C 函式庫，就不可能降至零。

獨立稽核：通過測試的成本不等於正式交付的成本#

Sumner 發布 19 天後，Tom Lockwood 做了其他人都沒做的顯而易見的查核：複製儲存庫，檢視公開產物實際呈現的情況（How is the Bun Rewrite in Rust Going?，2026-07-27，case-study）。這是知識庫中唯一針對此專案的外部觀察，也值得仔細閱讀，正因為它不是對 Sumner 的反駁。

它不是什麼。 Lockwood 明確說出他的目標：「Bun 團隊從來沒有做出那種宣稱。」 他批評的是二手轉述中不加思索地重複「花 165,000 美元就完成重寫」——群組聊天中的同儕說法，以及估值宣傳的影響——而不是已記錄自身後續工作的原文。若把他的文章讀成駁斥 Rewriting Bun in Rust，就顛倒了原文意思。他也揭露自己正在求職，並且是獨立部落客，不是經過測量的研究：其數字是可查證的公開儲存庫／CI 狀態觀察，成本估算則是推測，下文會明確標示。

截至 2026-07-27 的觀察：

觀察項目	數值
Bun 最近的發布標籤	bun-v1.3.14，2026-05-12——11 週沒有新標籤，距離合併到 main 已 6 週
過去最長的標籤間隔	6 週，v0.2.2（2022-10-26）至 v0.3.0（2022-12-07）
開啟中的 robobun PR	1,277 個（7 月 9 日）→ 約 2,475 個（7 月 27 日）
觀察到每個 PR 的合併時間	通常約 40 分鐘，最長約 90 分鐘，透過該組織的 Buildkite 叢集處理
推算的清理時間	目前積壓工作需要持續執行約 86 天的管線才能合併
其他可見資訊	Anthropic 員工撰寫的 PR 與 robobun PR 並存；合併後 Rust 參與度逐步增加

Sumner 自己的說法已消解大部分表面上的矛盾，不該刻意將兩者塑造成衝突。「Claude Code v2.1.181 起已在正式環境執行」和「Bun 自 5 月 12 日起沒有新發布標籤」可以同時為真，因為兩者指的是不同產物：Claude Code 內含 Bun，因此在 Claude Code 中發布 Rust 執行環境，不需要建立公開的 bun-v1.4.0 標籤。Sumner 也說得很清楚——「合併到 main 並不是有版本號的正式發布」，他在 7 月 8 日發布文章時，v1.4.0 仍只供 canary 測試。因此 Lockwood 觀察到的 11 週標籤空窗，最好解讀為來自獨立外部觀點的佐證，確認第一方文章已揭露的硬化期仍在繼續；這項觀察出自一個不會被指為刻意挑選有利日期的來源。「11 天」從來不是交付時間，而公開標籤歷史現在又一次證實了這點。

真正值得探討的是成本計算。 約 165,000 美元是移植到通過測試為止的 API token 成本，以 5 月 14 日合併為界。這不包括 Buildkite CI（在 clone 大小為 1.23 GiB 的程式碼庫上持續執行的大型叢集）、Anthropic 員工工時，或此後超過 11 週的代理程式支出。Sumner 的反事實比較——16.5 萬美元對比三個工程師年——把人力完整成本放在帳本的一邊，把純 token 成本放在另一邊。這種不對稱確實存在，原文也沒有處理。請見每項任務成本優先於每個 token 的成本，同樣的落差在那裡呈現為專案成本與正式交付總成本的差別。

Lockwood 提出的約 800,000 美元是推測，必須清楚標示：他的計算是「假設重寫每天仍花費 10,000 美元」，這是推定費率，不是觀察值，而且他沒有論證計算範圍的界線——持續處理 Bun 的代理程式工作到某個時點，不再算是「重寫」，而是一般的代理程式群組維護；沒有任何公開資訊標示那條界線。趨勢方向有充分依據，數字則是猜測。

持續增加的 PR 積壓量是最有力的數據，也是解讀最模糊的數據。 18 天內，開啟中的 robobun PR 從 1,277 個增至 2,475 個，公開資料無法區分以下兩種解讀：

1. 技術債——穩定化工作比「19 個已知回歸問題」所暗示的更多，合併佇列消化不了代理程式產生的內容。
2. 吞吐量——組織只是持續開啟代理程式 PR 產生功能，將其作為正常運作模式，正如 Boris Cherny 所說的自我維護程式碼庫代理程式群組（迴圈工程）。依此解讀，未合併 PR 數量是產量指標，不是技術債指標；數量上升正是成功的樣子。

Lockwood 沒有聲稱自己能區分兩者（「我不敢說自己確定」）。本文也無法判斷。這個數字能證明的是，專案沒有在合併時結束；這才是他的文章真正指出的重點。

值得借鑑的是方法，不是結論。 有關 AI 撰寫程式碼的供應商能力宣稱，可以透過可觀察的產物查核——發布標籤、合併佇列、提交頻率——但幾乎沒有人這麼做。他的附記以較寬鬆的方式套用同一方法：Anthropic 的 C 編譯器與 Cursor 的 FastRender 都有好幾個月沒有提交紀錄。這是文章中證據最弱的一步——閒置不等於失敗，而已完成使命的示範儲存庫也沒有理由持續提交——但這個直覺用在了正確的主張類型上。

工作流程、迴圈與例行任務#

Cherny 對千代理程式原語的分類如下：

• 動態工作流程——單一任務，拆解成分階段區塊（第一輪大量分派 → 驗證／彙整代理程式 → 下一輪大量分派），所有階段共用工作流程的結構。
• 迴圈（本機 cron）／例行任務（雲端 cron，關閉筆電後仍會執行）——依排程反覆執行同一項重複性任務，「不共用上下文，但可能共用記憶」。自我維護代理程式群組屬於此類（見迴圈工程）：每個程式碼庫每天執行 20–30 個例行任務——清理死碼、發布已全面推出的實驗、撰寫缺少的測試、刪除無用測試，以及整合近似重複抽象概念的「抽象警察」。

兩者的區別是迴圈原語提出的問題（「什麼時候再次執行？」），與本文提出的問題（「單次執行如何組織自身？」）。Bun 專案顯示兩者在實務上逐漸模糊：約 50 個工作流程在 11 天內持續執行，並由人類在執行途中編輯提示，這更接近受監督的代理程式群組，而非單一結構化任務。

已發布產品的預設值是「少於 15 個代理程式」#

Claude Code 變更紀錄（vendor-claim；滾動文件，截取於 2026-08-03，範圍涵蓋 v2.1.200–2.1.220）是知識庫中第一個說明動態工作流程預期規模的來源，而數字不大：

• v2.1.202 在 /config 加入「動態工作流程規模」控制項，可選小／中／大代理程式數量，並說明「這是建議指引，不是強制上限」。同一版本也為工作流程啟動的代理程式加入 workflow.run_id 和 workflow.name OpenTelemetry 屬性，「讓人能從 OTel 資料還原工作流程執行期間的活動」——這是該功能首度發布的可觀測性介面。
• v2.1.219 加入 workflowSizeGuideline 設定鍵，讓任何設定檔都能設定指引（設定時隱藏 /config 列），在執行中的工作流程狀態列顯示目前規模，並將動態工作流程預設為中等規模：「目標是少於 15 個代理程式」；其他規模及不設限也能在 /config 中選擇。

把這項預設與本文已提到的兩個數字對照。Boris Cherny 在台上說這項功能能為每項任務啟動「數十到數千個代理程式」；旗艦 Bun 專案的並行 Claude 峰值為 64 個。已發布版本的預設值約為專案峰值的四分之一，也比台上宣稱低兩個數量級。

這代表什麼、不代表什麼。 這不是收回說法——指引只是建議、可由使用者設定，而且明確提供不設限的選項，因此「數十到數千個」仍是宣稱的上限，Bun 專案也不受影響。改變的是使用者現在說「使用工作流程」時得到的預設值；供應商選擇了一個比自身行銷說法低一個數量級的數字。這是解讀，不是供應商提供的理由：變更紀錄完全沒說明為何預設為中等規模，沒有附上任何測量結果，也未解釋小／中／大各自代表幾個代理程式，除了括號中的這個數字。這與 OrchBench 的發現相近——代理程式預算從 16 增至 64 時，代理程式數量超過翻倍，品質只提高約 0.01——值得注意，但不能視為佐證；雙方都未引用對方，變更紀錄也完全沒有提供證據。

相關文章#

• 代理式程式碼生成即編譯——最接近的架構類比，但作者身分正好相反，這個對比是重點所在。兩者都以一般程式碼組合代理程式，而不是用代理程式迴圈；在動態工作流程中，由模型撰寫程式，Bridgewater 的 PAT 則將人類撰寫的編排程式固定在代理程式周圍（「受到 LangGraph 影響，但沒有代理式編排」）。這種反轉把「代理程式不會忘記驗證」從傾向變成保證；代價正是本文原語要提供的彈性。

• 將代理程式工作結晶為工作流程——組合程式運作之後會發生什麼：Malik 的正式環境生命週期會將反覆驗證的代理程式行為提升為混合式、再提升為零 token 的確定性手冊，讓程式在撰寫它的代理程式退場後仍能持續使用，最後不需代理程式也能執行。

• Open-Ended Discovery Harnesses——同一理念的手工打造版本，以及完全不設超參數的理由。SwarmResearch 是三個 Claude Code 技能，會呼叫 claude --permission-mode bypassPermissions -p；最佳化器透過 --resume <parent_session> --fork-session 建立，每個代理程式都有自己的分支和 worktree——編排程式是以技能撰寫，而不是在虛擬機器中執行。它反對已發布的少於 15 個代理程式指引，理由是衡量的五項任務中有四項，其最佳寬度和深度各不相同，因此會調整兩者的編排器勝過最佳固定設定；觀察到的工作波次約有 4–8 個代理程式。

• 大規模測試時運算——此功能宣稱要擴展的維度：以編排結構有效吸收超出單一序列式上下文所能處理的預算；Bun 專案的單次成本約為 165,000 美元，其中快取上下文讀取量與新輸入量之比為 12:1。

• 平行代理程式編排——經過測量的對照案例：Opus 5 系統卡中的多代理程式 harness，是此功能讓模型自行撰寫的手工版本；Bun 的 64 個代理程式尖峰分區、git 衝突的失敗嘗試與 cgroup 隔離，則是同類問題在部署規模下的實例。

• 最佳化器與評估器解耦——迴圈主體實作的不變條件，也是最明確公開規格的案例：上下文不對稱（審查者只看差異檔）加上反轉的先驗立場（假設程式碼有錯），而不只是分開的上下文。

• 審查作為控制點——人類審查的實際位置：不在程式碼上，而在於審查代理程式是否能抓到真正的差異。

• 迴圈工程——相鄰的原語：工作流程組織單一任務，迴圈／例行任務重複執行單一任務；Cherny 所說的自我維護程式碼庫代理程式群組是例行任務的補充，Bun 合併後會自動建立 PR 的模糊測試器則是正式環境中實際執行的例子。

• 為下一個模型而建——重新投入使用的案例，但須注意：Cherny 所說「每一代模型都試過」不是 Sumner 第一方敘述中的說法。

• 驗證成為新瓶頸——促成移植的條件，現在有了數字（139 萬次斷言，因 TypeScript 而意外獨立於語言），也知道其限制（100% 通過的測試套件仍漏出 19 個回歸問題，全都發生在組建設定或編譯時／執行時邊界）。

• 代理程式情境檔案——PORTING.md 和 LIFETIMES.tsv 是由一個工作流程產生、供 64 個代理程式讀取的機器可讀規格；準備階段將撰寫情境檔案變成一級工作流程。

• 程式碼作為事實來源——反覆使用的方式：將失敗集合（編譯器錯誤、stacktrace、失敗測試）寫入檔案，再依據檔案內容大量分派工作。

• 獎勵駭客行為——將失敗函式改成空殼的失敗嘗試：鑽了以編譯器為代理指標的漏洞，最後以審查者駁回規則而非指示實作者解決。

• 代理程式品質飛輪——合併後的模糊測試迴圈：全天候覆蓋引導模糊測試器自動建立 Claude 撰寫的修復 PR，由人類審查；探索至修復的閉環不需要人類介入。

• Latent Capability Overhang——背後的能力引出主張：舊模型「即使有人引導，也做不到」；能力隨 Fable 出現，而工作流程是讓它得以表現的產品介面。

• 模型進步時 harness 的縮減——相反的考量：模型變得更好，但這裡的 harness 非常龐大——兩份規格文件、約 50 個手工調整的迴圈、cgroup 隔離，以及 git 指令拒絕清單。能力出現不代表輔助架構消失。

• 每項任務成本優先於每個 token 的成本——本文已公開的最大規模任務成本案例：約 165,000 美元，對比宣稱的三個工程師年，且團隊表示否則絕不會嘗試這項任務；也是承接外部稽核提出的專案成本與正式交付成本差距之處。

• Claude Code——承載此功能的產品，也是受益者（自身執行環境就是移植的成果，自 v2.1.181 起上線）。

• Claude Fable 5——專案使用的尚未發布模型，也是目前已公開最大規模的部署案例。

• Jarred Sumner——Bun 的創辦者，也是方法論作者。

• Bun——移植的程式碼庫，也是工作流程原語執行所在的沙箱。

• Boris Cherny——二手來源與此功能的設計者（「我的背景是函數式程式設計」）。

• Cursor——另一個發布大型蜂群案例的廠商，也是有用的對照：Anthropic 的專案由模型在自有程式碼庫上撰寫編排程式，並將測試套件用作工作佇列；Cursor 則刻意手工設計從零開始的建置流程，並將判定依據保留為盲測，還發布了 Bun 案例沒有進行的受控 harness 對照實驗。

• 平行代理程式編排——Cursor 蜂群的協調機制和新舊數字，以及本文提到的 64 個代理程式限制條件。

• 編排計畫模擬——此功能首個外部測量案例，也提出了描述此功能操作對象的詞彙。OrchBench（arXiv 2607.25656，empirical）在動態工作流程設定下執行 Claude Code，作為驗證模擬器的真實執行組，並要求規劃器輸出宣告式 workflow_script——包含代理程式池、有排序的階段比對規則與指派策略（round_robin／dependency_locality／load_balance），以及含有逐邊壓縮比例的資料傳遞規則。這是一套完整公開且可查核的編排計畫文法，但它是在固定 DAG 上套用規則比對，而非依序／平行組合子；因此展示了這類詞彙可能的形式，卻沒有揭露 Anthropic 的實作。其實質發現不支持盲目大量分派：資料傳遞涵蓋率能預測品質，代理程式數量則不能；多代理程式只有在工作狀態超出單一上下文視窗時，才勝過單一序列式代理程式。

• 軌跡內平行規劃（SPRINT）——移除程式後，仍保留相同的序列／平行組合：SPRINT 的依賴 DAG 不會離開推理軌跡，而是以執行環境可據以分派的規劃／執行標籤表示，並透過微調寫入權重，而非輸出成程式碼。

開放問題#

• 「代數」作為一套詞彙仍未公開。Sumner 公布迴圈的形式（取出任務 → 實作 → 平行審查 → 套用）與清單（約 50 個迴圈），但沒有組合子名稱、組合運算子或工作流程原始碼。部分解答：依序／平行原語明顯正在使用，且模型能確實依照執行期間收到的英文指示撰寫和編輯它們；目前缺少的資訊是，除了 while 加上 Promise.all 之外，是否還有其他結構。2026-08-04 註記：變更紀錄公開了工作流程的第一批產品介面——規模指引（workflowSizeGuideline，小／中／大，預設為「少於 15 個代理程式」）、workflow.run_id／workflow.name OTel 屬性、代理程式格狀檢視，以及執行中工作流程狀態列——但仍然沒有組合子名稱，也沒有工作流程原始碼。公開的是規模和可觀測性，而非詞彙。
• 模型撰寫的編排，與針對同一任務手工打造的 harness 相比，是否更節省 token？部分解答——現在其中一方有了數字：Bun 移植使用 59 億未快取輸入／6.9 億輸出／720 億快取讀取／約 165,000 美元；Sumner 也說「如果要做到這件事，我原本得自己寫 harness」，承認從未進行比較。沒有反事實 harness，因此無法從這個來源回答效率問題；需要讓同一任務以兩種方式執行。**2026-07-27 的新複雜因素：**約 165,000 美元只計算到合併為止的 token 成本，不含 CI、員工工時與合併後持續進行的工作，因此帳面上唯一的數字也不是整個專案的成本。**2026-08-03 的進一步釐清：**問題比較的基準可能不對。OrchBench 是將編排成本與單一序列式代理程式比較，而非與另一個 harness 比較；研究發現，在測試的每種規劃器和上下文限制下，多代理程式計畫消耗的 token 大約是序列式執行的 1.5 倍——每個代理程式啟動成本（1,200 個 token）、代理程式間通訊與壓縮成本，都是大量分派無可避免的支出。如果這點在模擬之外也成立，合理的問題就不是「模型撰寫的編排是否比較便宜」，而是「token 溢價換到了什麼」；OrchBench 的回答是：只有在工作狀態超出單一上下文視窗時才有品質提升，另外還能省下實際經過時間。實驗設計已經出現，但使用了錯誤的比較組（2026-08-03）：Cursor 在固定模型和固定時間預算下，以兩套 harness 重新執行同一任務——正是這個問題需要的受控實驗設計；經刻意打造的 harness 使用遠少於一小部分的提交次數、衝突和程式碼，就取得相同評等。但兩組都是手工打造的 harness，因此測得的是 harness 工程成本，而非模型撰寫成本。現在需要有人用一組模型撰寫的 harness 執行這種設計。
• Bun 移植從通過測試到正式交付的成本是多少——包含 CI、員工工時和合併後代理程式支出？Lockwood 以假設每天花費 10,000 美元推算約 800,000 美元，這不是觀察結果；要釐清，需要第一方公布總額，或等待公開的 v1.4.0 正式發布，讓硬化期結束並標明日期。另一個相關跡象是持續增加的約 2,475 個未合併 robobun PR 是否會逐步清空（穩定化技術債），還是維持在相同數量（持續代理程式群組的吞吐量）。
• 沒有驗證基礎設施時，這種模式會退化到什麼程度？**問題更清楚了，但仍未解答：**Bun 的判定依據具備多數程式碼庫都沒有的特性——測試套件使用與實作不同的語言撰寫，因此移植後原封不動；斷言數（100 萬以上）是表面上可見的變數，但語言獨立性才是關鍵。要得出結論，需找到測試使用來源語言撰寫的同類移植案例。2026-08-03：得到佐證，仍未解答：Cursor 的 SQLite 蜂群是知識庫中第二個大型蜂群成功案例，其判定依據具備相同特性，而且形式更強——sqllogictest 對不同資料庫引擎的查詢結果評分，因此完全不依賴實作，而不只是獨立於實作語言。兩個案例都使用獨立於實作的判定依據，讓混淆因素從「可能只是偶然」變成「可能是必要條件」，但仍沒有負面案例。問題沒有改變，現在提出的理由更充分。

資料來源#

• Rewriting Bun in Rust — Jarred Sumner，bun.com（2026-07-08，case-study，揭露作者為 Anthropic 員工）：已發布的方法記錄——約 50 個工作流程、迴圈虛擬碼、對抗式審查規格、PORTING.md／LIFETIMES.tsv 準備工作、失敗嘗試、6,502 次提交、約 165,000 美元 token 支出、19 個回歸問題，以及 v1.4.0 成果數字。
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Y Combinator 訪談（2026-07-27，practitioner-opinion）：代理程式代數設計、以 Bun 為沙箱的虛擬機器機制、測試時運算說法、工作流程／迴圈／例行任務分類，以及本文修正的 Bun 重寫二手說法。
• Agent swarms and the new model economics — Wilson Lin，cursor.com（2026-07-20，case-study，供應商撰寫）：「SQLite 實驗」——提供 835 頁手冊作為需求說明，但不提供來源、測試、二進位檔和網際網路；使用未告知蜂群的跨引擎判定依據 sqllogictest，以及執行後由人類檢查是否走捷徑和建置不均。本文只用來比較判定依據和 harness 對照實驗；蜂群本身請見平行代理程式編排。
• Claude Code Changelog — Anthropic，Claude Code CHANGELOG（vendor-claim）。滾動文件，截取於 2026-08-03，範圍限定 v2.1.200–v2.1.220，並省略較舊項目；原始文件的 published: 欄刻意留白，線上檔案之後也已更新。僅含發布說明——沒有理由、測量結果或工作流程原始碼。本文以此說明規模指引（2.1.202 建議性 /config 控制項；2.1.219 workflowSizeGuideline 設定鍵、狀態列顯示，以及預設中等規模「少於 15 個代理程式」）和 workflow.run_id／workflow.name OTel 屬性（2.1.202）。
• How is the Bun Rewrite in Rust Going? — Tom Lockwood，lockwood.dev（2026-07-27，case-study，獨立來源，作者揭露正在求職）：外部觀察——bun-v1.3.14 後 11 週沒有新發布標籤、18 天內未合併 robobun PR 從 1,277 增至約 2,475 個、Buildkite 每次合併約需 40–90 分鐘，推算連續執行約 86 天管線才能清空積壓；並指出許多成本沒有列入帳面（他提出的約 800,000 美元是以假設費率外推，不是測量結果）。
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes — McManus、Ran 和 Weight（Bridgewater Associates），LangChain 頻道，2026-07-24，演講長 25:44，case-study。引用 PAT 的人類撰寫編排程式——「受到 LangGraph 影響，但沒有代理式編排」（19:44–22:37）。全篇都是第一方敘述，沒有方法論細節——每項數字的證據限制請見代理式程式碼生成即編譯。

新術語#

• 動態工作流程：tech
• Zig：tech
• Rust：tech
• TigerStyle：product
• Bun JavaScript 執行環境：tech
• OpenTelemetry：tech
• Miri：tech
• LeakSanitizer：tech
• PAT：tech